Unable to read or write from system SPI flash memory.

[Andrew Jeffery]

Hi Akash,

There's a bit to unpack here.

On Wed, 20 Feb 2019, at 15:02, AKASH G J wrote:
> Andrew, Sorry for the inconvenience.
> 
> For flashing the kernel image, I used the command
> 
> $ *pflash -e -a 0 -f -p fitImage.bin
> *
> *
> *
> and for flashing root file system
> *
> *
> *$ *pflash -e -a *8388608* -f -p obmc.rootfs.cpio.lzma.u-boot**
> **
> **
> ** **After power-off I used the command** *bootm 0x30000000 0x30800000* 
> **in u-boot prompt.
> 

What is the error output of the command? Can you copy/paste it?

Also, can you paste the output of `md.l 0x30000000` and the output of
`hexdump -C fitImage.bin | head` ? 

But I have to ask, *why* are you flashing OpenBMC artifacts to memory on SPI1?

I don't know if this helps, but here's a description of the ASPEEDAST2500 flash
architecture:

1. The BMC has 3 flash controllers attached to the AHB:
  a. 0x1e620000 - "Firmware SPI Memory Controller" (FMC): BMC firmware controller
  b. 0x1e630000 - "SPI Flash Controller 1" (SPI1): Host firmware controller 1
  c. 0x1e631000 - "SPI Flash Controller 2" (SPI2): Host firmware controller 2

2. Each of the three flash controllers has multiple chip-select lines
  a. FMC: Up to 3 chip select lines
  b. SPI1: Up to 2 chip select lines
  c. SPI2: Up to 2 chip select lines

3. The AHB has a memory mapping for the chips of each flash controller, with each
region being subdivided to cater to the chip selects. These sub-ranges are
configurable in each flash controller. The controller mappings and their default
sub-ranges are:

  a. 0x00000000 - 0x0fffffff: FMC
  b. 0x20000000 - 0x2fffffff: FMC
    1. 0x20000000 - 0x27ffffff: CS0
    2. 0x28000000 - 0x29ffffff: CS1
    3. 0x2a000000 - 0x2bffffff: CS2
  c. 0x30000000 - 0x37ffffff: SPI1
    1. 0x30000000 - 0x31ffffff: CS0
    2. 0x32000000 - 0x37ffffff: CS1
  d. 0x38000000 - 0x3fffffff: SPI2
    1. 0x38000000 - 0x39ffffff: CS0
    2. 0x3a000000 - 0x3fffffff: CS1

So there are a couple of answers that I can think of to my question about
why you might be flashing OpenBMC artefacts to a chip behind SPI1:

1. You just want to test a new build without disturbing the BMC flash image
2. You want BMC flash redundancy

For 1, there are many ways you can go about testing images without
trying to do something awkward like flash the artefacts to a chip behind
SPI1:

a. Use QEMU: https://github.com/openbmc/docs/blob/master/cheatsheet.md#using-qemu
  1. We have a fork at https://github.com/openbmc/qemu
  2. Most of the patches are upstream, so you can just e.g.
     `sudo apt install qemu-system-arm` on Debian based systems
b. If you're wanting to test kernel changes on hardware, then I recommend
     setting yourself up so you can netboot kernels on the BMC
c. If you're wanting to test userspace changes, then you can just
    drop the binary into an already running userspace

For 2, you need to be populating CS1 of the FMC; this has the benefit
(perhaps?) of the AST2500's auto-failover mechanism where if the
hardware gets a watchdog event on boot it automagically flips CS0 and
CS1 on the FMC (along with the memory mappings) so you fall-back to
booting from the second chip.

Hope that helps?

Andrew