<meta http-equiv="Content-Type" content="text/html; charset=GB18030"><div>Hi Mr. Andrew Jeffery</div><div><br></div><div>Thank you very much for your help. I really thanks for your explanations, very detail and very clear.</div><div>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.</div><div>Again, Thanks for your help, really!</div><div><br></div><div>Best Regards!</div><div>Liu Hongwei</div><div><div><br></div>>Hello again!<br>><br>>On Sun, 10 May 2020, at 02:06, 掴勸ムルシエラゴ wrote:<br>>> Hi Mr. Andrew Jeffery<br>>> <br>>> Thank you for your help. Sorry for late response. After getting your </div><div>>> replay, I read AST2500 spec and OpenBMC linux kernel again.<br>>> I found a "SuperIO controller" in AST2500 spec and "aspeed-lpc-ctrl.c" <br>>> in linux kernel.<br>>> <br>>> 1. I found there is a logical device "iLPC2AHB" in SuperIO controller, <br>>> and it is said the register can be accessed by Host CPU through LPC <br>>> bus(I am not sure but I think the SuperIO controller will be used for <br>>> Host CPU, and no BMC driver will use it).<br>><br>>Correct, the iLPC2AHB bridge is driven by host firmware.<br>><br>>> I also found "SIO iLPC2AHB <br>>> address" register in SuperIO controller. Given that this register can <br>>> be accessed by Host CPU, can I think that the Host CPU firstly <br>>> configure the "SIO iLPC2AHB address" register, then if the LPC slave <br>>> controller is configured rightly, Host CPU can access the BMC's memory <br>>> space by using memory reading or writing to the address written to "SIO <br>>> iLPC2AHB address" register?<br>><br>>Yes.<br>><br>>> If I am right, what does SuperIO controller do, is it between Host's <br>>> LPC bus and BMC's LPC slave controller like:<br>>> Host-->LPC bus-->SuperIO controller-->LPC slave controller-->LPC2AHB <br>>> bridge-->SPI Flash mapping<br>>> or SuperIO controller is independent of LPC slave controller like:<br>>> Host-->LPC bus-->SuperIO controller<br>>> Host-->LPC bus-->LPC slave contrller-->LPC2AHB bridge-->SPI Flash <br>>> mapping<br>><br>>I think we need to separate out firmware accesses from what you're<br>>describing above. The iLPC2AHB bridge is slow and is generally not<br>>used to access the host flash. To access the host flash we use the<br>>similarly-named but _different_ LPC2AHB bridge (no "i") that maps<br>>LPC Firmware cycles into the BMC's physical address space. The key<br>>point here is that the iLPC2AHB (with "i") bridge is accessed with LPC<br>>IO cycles instead.<br>><br>>You can read more about different LPC cycle types in the specification:<br>><br>>https://www.intel.com/content/dam/www/program/design/us/en/documents/low-pin-count-interface-specification.pdf<br>><br>>So what is the iLPC2AHB bridge used for? Well, writing a SPI-NOR flash<br>>directly is not possible with just LPC Firmware cycles as, for example,<br>>we need to issue WREN, ERASE and PP commands in order get the data<br>>to stick. In the naive case we use the iLPC2AHB bridge to drive these<br>>commands through the BMC's host flash controller and then write the<br>>data through LPC Firmware cycles.<br>><br>>However, as the iLPC2AHB bridge is unconstrained in what it can access<br>>in the BMC's physical address space, you can do pretty much anything<br>>else you want to the BMC peripherals with it as well. As such it can be<br>>a significant security concern (depending on your threat model), and<br>>there's a CVE that covers it:<br>><br>>https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6260<br>><br>>> <br>>> 2. I found "aspeed-lpc-ctrl.c" in linux kernel source code. Although I <br>>> am not very familar with this driver, I found that by configuring the <br>>> LPC slave controller's host interface control register, this driver can <br>>> decide which BMC's memory space can be mapper to Host CPU.<br>>> And In the picture you draw for me<br>>> Host CPU<br>>>  -> LPC FW<br>>>  -> LPC2AHB Bridge<br>>>  -> SPI flash mapping<br>>>  -> SPI Flash<br>>> Does the "LPC FW" means aspeed-lpc-ctrl driver?<br>><br>>"LPC FW" simply means LPC Firmware cycles as described in the LPC<br>>specification I linked above.<br>><br>>However, yes, LPC FW cycles are related to the aspeed-lpc-ctrl driver<br>>as this driver is what controls the mapping of the firmware cycles onto<br>>the BMC's physical address space. For some context, in OpenPOWER<br>>systems we use the aspeed-lpc-ctrl driver to point the LPC2AHB bridge<br>>at a specific region of BMC RAM that we have reserved (i.e. the BMC<br>>kernel no-longer considers it generally available to applications or the<br>>kernel). In this configuration, all LPC FW read and write cycles issued<br>>by the host access this reserved region of RAM (instead of e.g. the<br>>host flash device).<br>><br>>Hope that helps,<br>><br>>Andrew<br></div>