<div dir="ltr">Hi Byron<div><br></div><div>I have not verified that or how exactly this would work.</div><div><br></div><div>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.</div><div><br></div><div>If you (or someone else) does go down this route, it would be great if it was reported back here.</div><div><br></div><div>Oskar.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 16, 2019 at 5:23 AM www <<a href="mailto:ouyangxuan10@163.com" target="_blank">ouyangxuan10@163.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="line-height:1.7;color:rgb(0,0,0);font-size:14px;font-family:Arial"><div>Dear <span style="font-family:Helvetica,"Microsoft Yahei",verdana">Oskar，</span></div><div><span style="font-family:Helvetica,"Microsoft Yahei",verdana"><br></span></div><div><span style="font-family:Helvetica,"Microsoft Yahei",verdana">In current BMC kernel, if I add a bios flash partition on dts, it need get bios flash chip ip when loading spi driver, </span><span style="font-family:Helvetica,"Microsoft Yahei",verdana">It may have a bad effect on BIOS startup.</span></div><div><font face="Helvetica, Microsoft Yahei, verdana">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? </font></div><br><div>thanks，</div><div>Byron</div><br><br><div style="zoom:1"></div><div id="gmail-m_-6212424926330754351gmail-m_-2843237972321854470divNeteaseMailCard"></div><br>At 2019-09-11 23:28:27, "Oskar Senft" <<a href="mailto:osk@google.com" target="_blank">osk@google.com</a>> wrote:<br> <blockquote id="gmail-m_-6212424926330754351gmail-m_-2843237972321854470isReplyContent" style="padding-left:1ex;margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)"><div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>Oskar.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 10, 2019 at 7:56 PM Andrew Jeffery <<a href="mailto:andrew@aj.id.au" target="_blank">andrew@aj.id.au</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On Wed, 11 Sep 2019, at 07:16, Milton Miller II wrote:<br>
> On September 10, 2019, Byron <<a href="mailto:ouyangxuan10@163.com" target="_blank">ouyangxuan10@163.com</a>> wrote:<br>
> <br>
> >Dear all,<br>
> ><br>
> >    I want to ask a question about how to spi driver flash host/bios<br>
> >firmware? I don't want use mtd mode flash it, because the mtd mode<br>
> >need read spi-id when BMC load spi driver, may be it is risky, it<br>
> >need switch the  system spi to BMC when the host running, It may<br>
> >break host startup. Do we have other solutions to solve this problem?<br>
> ><br>
> <br>
> Indeed, we did have some initial hand-off issues especially as the <br>
> Linux kernel spi nor layer matured.  Over time the assumptions that <br>
> the bios had that the chip would be set to 4-byte addressing by <br>
> default were not met by the kernel driver which switched to using <br>
> 4-byte specific read and write commands.<br>
> <br>
> You probably have a few options:<br>
> <br>
> If you host is read-only, you can allocate a block of dram <br>
> and point the lpc window to the dram.  The aspeed lpc <br>
> controller drivers has ioctl calls for this.<br>
> <br>
> If you host is directly connected to the chip and you are <br>
> using the spi mode mux, then you would need to handshake <br>
> with your bios.<br>
> <br>
> If your host is using lpc to the aspeed chip and programming <br>
> the controller directly, you probably have given full overtake <br>
> of your bmc to the host.<br>
<br>
This is the case for ASPEED BMCs, so be conscious of threat models.<br>
<br>
> <br>
> In Openpower systems, we have implemented a protocol to map <br>
> sections of the SPI rom into memory, and use IPMI messages <br>
> to page in and out windows from this access window in memory <br>
> to the backing SPI chip. We also have a method.<br>
<br>
That sentence looks incomplete :)<br>
<br>
Anyway, yes, in OpenPOWER platform designs the BMC owns the flash<br>
and we provide an abstract means for the host to access flash data such<br>
that the BMC always remains in control. If you have questions on what<br>
we've done there, don't hesitate to ask me.<br>
<br>
Any other mechanisms will require an explicit handshake as Milton<br>
mentions and there may be some corner cases in the event of ungraceful<br>
shutdowns of the host.<br>
<br>
Andrew<br>
</blockquote></div>
</blockquote></div><br><br><span title="neteasefooter"><p> </p></span></blockquote></div>