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?

Andrew Jeffery andrew at
Mon May 11 10:42:03 AEST 2020

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?


> 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:

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:

> 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,


More information about the openbmc mailing list