how to use spi flash BIOS/Host firmware??

[www]

Dear Oskar,


thank you very much.


Thanks,
Byron






At 2019-09-16 22:58:33, "Oskar Senft" <osk at google.com> wrote:

Hi Byron


I have not verified that or how exactly this would work.


The idea I heard floating around was to NOT use a kernel driver, but instead use a user-space tool like flashrom to access the BIOS SPI flash from the BMC.


If you (or someone else) does go down this route, it would be great if it was reported back here.


Oskar.


On Mon, Sep 16, 2019 at 5:23 AM www <ouyangxuan10 at 163.com> wrote:

Dear Oskar，


In current BMC kernel, if I add a bios flash partition on dts, it need get bios flash chip ip when loading spi driver, It may have a bad effect on BIOS startup.
Could you explain in detail how this safe flash method is implemented? how can I modify it on bmc kernel(I guess need modify kernel) and user space? 


thanks，
Byron




At 2019-09-11 23:28:27, "Oskar Senft" <osk at google.com> wrote:

One option I heard of (unverified by me) is to use user-space-only implementation (e.g. flashrom) on the BMC to dynamically access the host's SPI "when it is safe to do so", without requiring a kernel driver on the BMC.


The tricky part is "when it is safe to do so", but you could define certain points in time, e.g. when the host is powered off or in reset.


Oskar.


On Tue, Sep 10, 2019 at 7:56 PM Andrew Jeffery <andrew at aj.id.au> wrote:



On Wed, 11 Sep 2019, at 07:16, Milton Miller II wrote:
> On September 10, 2019, Byron <ouyangxuan10 at 163.com> wrote:
>
> >Dear all,
> >
> >    I want to ask a question about how to spi driver flash host/bios
> >firmware? I don't want use mtd mode flash it, because the mtd mode
> >need read spi-id when BMC load spi driver, may be it is risky, it
> >need switch the  system spi to BMC when the host running, It may
> >break host startup. Do we have other solutions to solve this problem?
> >
>
> Indeed, we did have some initial hand-off issues especially as the
> Linux kernel spi nor layer matured.  Over time the assumptions that
> the bios had that the chip would be set to 4-byte addressing by
> default were not met by the kernel driver which switched to using
> 4-byte specific read and write commands.
>
> You probably have a few options:
>
> If you host is read-only, you can allocate a block of dram
> and point the lpc window to the dram.  The aspeed lpc
> controller drivers has ioctl calls for this.
>
> If you host is directly connected to the chip and you are
> using the spi mode mux, then you would need to handshake
> with your bios.
>
> If your host is using lpc to the aspeed chip and programming
> the controller directly, you probably have given full overtake
> of your bmc to the host.

This is the case for ASPEED BMCs, so be conscious of threat models.

>
> In Openpower systems, we have implemented a protocol to map
> sections of the SPI rom into memory, and use IPMI messages
> to page in and out windows from this access window in memory
> to the backing SPI chip. We also have a method.

That sentence looks incomplete :)

Anyway, yes, in OpenPOWER platform designs the BMC owns the flash
and we provide an abstract means for the host to access flash data such
that the BMC always remains in control. If you have questions on what
we've done there, don't hesitate to ask me.

Any other mechanisms will require an explicit handshake as Milton
mentions and there may be some corner cases in the event of ungraceful
shutdowns of the host.

Andrew





 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20190918/456ee5e6/attachment.htm>