Re： 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 very much for your help. I really thanks for your explanations, very detail and very clear.
Now I am clear about the iLPC2AHB bridge. I found the iLPC2AHB bridge device in AST2500, but I do not find the LPC2AHB bridge. I think maybe it is integrated in LPC controller, and about how LPC2AHB work, perhaps I still need some time to study this. Because I run openbmc in qemu, there are some experiments that I can not conduct. After I get a real hardware I will do futher experiment.
Again, Thanks for your help, really!


Best Regards!
Liu Hongwei


>Hello again!
>
>On Sun, 10 May 2020, at 02:06, 南野ムルシエラゴ wrote:
>> 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).
>
>Correct, the iLPC2AHB bridge is driven by host firmware.
>
>> 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?
>
>Yes.
>
>> 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
>
>I think we need to separate out firmware accesses from what you're
>describing above. The iLPC2AHB bridge is slow and is generally not
>used to access the host flash. To access the host flash we use the
>similarly-named but _different_ LPC2AHB bridge (no "i") that maps
>LPC Firmware cycles into the BMC's physical address space. The key
>point here is that the iLPC2AHB (with "i") bridge is accessed with LPC
>IO cycles instead.
>
>You can read more about different LPC cycle types in the specification:
>
>https://www.intel.com/content/dam/www/program/design/us/en/documents/low-pin-count-interface-specification.pdf
>
>So what is the iLPC2AHB bridge used for? Well, writing a SPI-NOR flash
>directly is not possible with just LPC Firmware cycles as, for example,
>we need to issue WREN, ERASE and PP commands in order get the data
>to stick. In the naive case we use the iLPC2AHB bridge to drive these
>commands through the BMC's host flash controller and then write the
>data through LPC Firmware cycles.
>
>However, as the iLPC2AHB bridge is unconstrained in what it can access
>in the BMC's physical address space, you can do pretty much anything
>else you want to the BMC peripherals with it as well. As such it can be
>a significant security concern (depending on your threat model), and
>there's a CVE that covers it:
>
>https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6260
>
>> 
>> 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?
>
>"LPC FW" simply means LPC Firmware cycles as described in the LPC
>specification I linked above.
>
>However, yes, LPC FW cycles are related to the aspeed-lpc-ctrl driver
>as this driver is what controls the mapping of the firmware cycles onto
>the BMC's physical address space. For some context, in OpenPOWER
>systems we use the aspeed-lpc-ctrl driver to point the LPC2AHB bridge
>at a specific region of BMC RAM that we have reserved (i.e. the BMC
>kernel no-longer considers it generally available to applications or the
>kernel). In this configuration, all LPC FW read and write cycles issued
>by the host access this reserved region of RAM (instead of e.g. the
>host flash device).
>
>Hope that helps,
>
>Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200527/1577d596/attachment.htm>