Re: How can the host access BMC's SPI Flash via LPC and How do BMC's CPU read uboot from SPI Flash when power up?

[Andrew Jeffery]

Hi Liu Hongwei,

On Fri, 24 Apr 2020, at 23:58, 南野ムルシエラゴ wrote:
> Hi, Greetings
>  A BMC usually uses aspeed's chip. To learn BMC I read the spec of 
> aspeed's AST2500. I have long been confused by two questions when I am 
> learning BMC.

>  1. One is that: How can the host access BMC's SPI Flash via LPC? I 
> read from AST2500's spec that the host can update the BIOS stored in 
> the SPI flash via LPC.

Okay first thing to address is separation of concerns: There are separate
SPI controllers for the BMC and host firmware.

> I also seen from AST2500's spec that the SPI 
> controller in AST2500 can be access by host through LPC. It seems like 
> the architecture is as below.
>  Host CPU---->LPC---->SPI controller---->SPI Flash[BIOS]

Roughly, yes. There are a couple of other critical pieces of the puzzle:

1. The SPI-attached storage is mapped into the BMC's physical address
space
2. The BMC's LPC slave controller contains a bridge that allows host
accesses to the LPC FW space to be converted to accesses to the 
BMC's physical address space.

So the picture looks like:

Host CPU
    -> LPC FW
        -> LPC2AHB Bridge
            -> SPI flash mapping
                -> SPI Flash

>  I do not know how it works, does this need to install a LPC driver in 
> host OS and openbmc OS? And does this need software intervention?

The host OS or firmware likely already knows how to drive the LPC bus. The
LPC bus is typically part of the host's boot path, particularly if the BIOS is
stored on SPI flash attached to the BMC (though on Intel systems eSPI
supersedes LPC, but the concepts are roughly the same).

>  2. The other is that: How does BMC's CPU read uboot code from SPI 
> flash when power up? I know that the uboot(act as bootloader) is stored 
> in a SPI flash, and uboot is the first code that is executed by BMC's 
> CPU. I do not know whether it is right or wrong but I think BMC's CPU 
> can only execute the code stored in DRAM.

This is where you're falling down. In theory the BMC can execute
instructions from anywhere in its physical address space. DRAM is
located somewhere in that physical address space (on the AST2500,
it is located at 0x80000000), however there are other areas of interest
in the physical address space, namely the mapping of the BMC flash
to 0x0. This is the reset vector for the ARM core, so when it is released
from reset it starts executing whatever instructions are present at 0x0.
The SoC hardware design handles the fact that the instructions at 0x0
are fetched from the BMC's SPI flash so no driver is needed.

Andrew