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?

[南野ムルシエラゴ]

Hi Mr. Andrew Jeffery


Thank you for your help. Sorry for late response. After getting your replay, I read AST2500 spec and OpenBMC linux kernel again.
I found a "SuperIO controller" in AST2500 spec and "aspeed-lpc-ctrl.c" in linux kernel.


1. I found there is a logical device "iLPC2AHB" in SuperIO controller, and it is said the register can be accessed by Host CPU through LPC bus(I am not sure but I think the SuperIO controller will be used for Host CPU, and no BMC driver will use it). I also found "SIO iLPC2AHB address" register in SuperIO controller. Given that this register can be accessed by Host CPU, can I think that the Host CPU firstly configure the "SIO iLPC2AHB address" register, then if the LPC slave controller is configured rightly, Host CPU can access the BMC's memory space by using memory reading or writing to the address written to "SIO iLPC2AHB address" register?
If I am right, what does SuperIO controller do, is it between Host's LPC bus and BMC's LPC slave controller like:
Host-->LPC bus-->SuperIO controller-->LPC slave controller-->LPC2AHB bridge-->SPI Flash mapping
or SuperIO controller is independent of LPC slave controller like:
Host-->LPC bus-->SuperIO controller
Host-->LPC bus-->LPC slave contrller-->LPC2AHB bridge-->SPI Flash mapping


2. I found "aspeed-lpc-ctrl.c" in linux kernel source code. Although I am not very familar with this driver, I found that by configuring the LPC slave controller's host interface control register, this driver can decide which BMC's memory space can be mapper to Host CPU.
And In the picture you draw for me
Host CPU
    -> LPC FW
        -> LPC2AHB Bridge
            -> SPI flash mapping
                -> SPI Flash
Does the "LPC FW" means aspeed-lpc-ctrl driver?


Best Regards!
Liu Hongwei


>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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200510/83cc55aa/attachment.htm>