<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10.5pt" ><div dir="ltr" >All,</div>
<div dir="ltr" >Some additional findings on the OCC FIRDATA collection:</div>
<div dir="ltr" >Once the OCC has collected all the firdata, it iterates through the data 8 bytes at a time and adds a 9th ecc byte, Each time 256 bytes of ecc injected data has been generated, it calls whatever method that's "enabled" (HIO/IPMI) to write the chunk to PNOR.  Once the FIRDATA is exhausted, it writes all 0xffffffffffffffff + ecc to fill the remaining PNOR allocated to FIRDATA.</div>
<div dir="ltr" > </div>
<div dir="ltr" >I put stubs around the code that injects the ecc and then generated random FIRDATA to pass to it, and dumped what would have been written to PNOR.</div>
<div dir="ltr" >There is a bug in the code where if the original FIRDATA does not have a size that is a multiple of 8 bytes, it incorrectly processes the trailing data and then overwrites it, but I could not find any use case to cause it to generate incorrect ecc. This code has been around for a while and is used on mulitple platforms, but perhaps this is the first time the FIRDATA size has not been a muliple of 8 and I still don't know if this is the issue.</div>
<div dir="ltr" ><br><br>Thanks,<br>Doug Gilbert<br><br>"For it must needs be, that there is an opposition in all things..." 2 Nephi 2:11</div>
<div dir="ltr" > </div>
<div dir="ltr" > </div>
<blockquote data-history-content-modified="1" dir="ltr" style="border-left:solid #aaaaaa 2px; margin-left:5px; padding-left:5px; direction:ltr; margin-right:0px" >----- Original message -----<br>From: Artem Senichev <artemsen@gmail.com><br>To: Andrew Jeffery <andrew@aj.id.au><br>Cc: openpower-firmware@lists.ozlabs.org, Douglas Gilbert <dgilbert@us.ibm.com><br>Subject: [EXTERNAL] Re: [OpenPower-Firmware] [POWER8] OCC Firdata over IPMI<br>Date: Fri, May 24, 2019 4:36 AM<br> 
<div><font size="2" face="Default Monospace,Courier New,Courier,monospace" >On Fri, May 24, 2019 at 10:10:52AM +0930, Andrew Jeffery wrote:<br>> On Thu, 23 May 2019, at 18:58, Artem Senichev wrote:<br>> > On Thu, May 23, 2019 at 10:10:38AM +0930, Andrew Jeffery wrote:<br>> > > Hi Artem,<br>> > ><br>> > > Snipping somewhat, I'll let Doug dig into the specifics of the OCC issue as he<br>> > > implemented the IPMI HIOMAP support for it.<br>> > ><br>> > > On Wed, 22 May 2019, at 17:13, Artem Senichev wrote:<br>> > ><br>> > > > We have HIOMAP support for our bundle (OpenBMC+OpenPOWER), it looks like<br>> > > > the entire solution works fine except the OCC project, it is the last<br>> > > > component that directly writes data to the PNOR flash.<br>> > ><br>> > > Great to hear the rest works for you. Just for your awareness you may need to<br>> > > pick up a couple of patches depending on what firmwares you're running: [1]<br>> > > to fix a data write corruption issue in skiboot and [2] to resolve a memory leak<br>> > > in OpenBMC. These are the critical issues, but there are further sets of skiboot<br>> > > and OpenBMC patches that I recommend to avoid lockups. I can point you to<br>> > > them if necessary.<br>> ><br>> > Yes, please. May be these patches will solve my second problem :)<br>><br>> Before I do, can you please either push your trees somewhere I can look over them?<br>> That was I can minimise the set of patches I need to look over / recommend.<br><br>The host-side logic is included to skiboot:<br><a href="https://github.com/open-power/skiboot/blob/76f7316bc8fc8a18fdbfcbc0e1fe1bb992d2a7d7/platforms/astbmc/vesnin.c#L298" target="_blank">https://github.com/open-power/skiboot/blob/76f7316bc8fc8a18fdbfcbc0e1fe1bb992d2a7d7/platforms/astbmc/vesnin.c#L298</a><br>Actually, there are some changes in the message format (adaptation to the new<br>IPMI API in OnepBMC), I will commit them as soon as I solve the sending problem.<br><br>BMC-side handler of these IPMI messages:<br><a href="https://github.com/YADRO-KNS/phosphor-pci-inventory" target="_blank">https://github.com/YADRO-KNS/phosphor-pci-inventory</a><br><br>> > We have a (dead?) lock situation in skiboot. I'm not sure that<br>> > this affects other skiboot's code, but I can't send PCI device list<br>> > from skiboot to OpenBMC - the system freezes at ipmi_queue_msg_sync():<br>> ><br>> > <a href="https://github.com/open-power/skiboot/blob/76f7316bc8fc8a18fdbfcbc0e1fe1bb992d2a7d7/core/ipmi.c#L177" target="_blank">https://github.com/open-power/skiboot/blob/76f7316bc8fc8a18fdbfcbc0e1fe1bb992d2a7d7/core/ipmi.c#L177</a><br>> ><br>> > Usually, system hangs after sending 3-5 of my messages. I have added<br>> > trace to core/ipmi.c - it ends up with two calls to 'lock(&sync_lock)',<br>> > one for my message and another one for HIOMAP.<br>> > As workaround, I use asynchronous sending with increased IPMI message queue<br>> > size, but it's not a good solution.<br>><br>> Generally you shouldn't be using ipmi_queue_msg_sync(), and I'm unclear why<br>> async is a bad solution here. What are your requirements that drive the use of<br>> _sync()?<br><br>I send one IPMI message for each end point PCI device. Device iteration is a<br>fast operation, but IPMI queue is too small (10 records). As a result, the<br>IPMI queue is quickly filled and we get lost messages.<br>To avoid this I use synchronous sending. Or, as I<br>mentioned, I can increase the IPMI queue and send the data<br>asynchronously.<br><br>> I don't have any immediate solutions for you. How are you sending down the PCI<br>> data? Are you writing it to the PNOR or sending the PCI devices through as FRUs?<br><br>I send some device information (location, vendor id, etc) via IPMI,<br>it's OEM messages, not a FRU. But in the OpenBMC inventory devices look<br>like FRU records.<br><br>> > > On the skiboot side, master contains all the fixes we have needed so far, and<br>> > > everything except for [3] is contained in the v6.3 tag. OpenBMC master has<br>> > > all its respective fixes included.<br>> > ><br>> > > Bit of a tangent, but I hope it helps.<br>> > ><br>> > > Andrew<br>> > ><br>> > > [1] <a href="https://github.com/open-power/skiboot/commit/7f291166283f" target="_blank">https://github.com/open-power/skiboot/commit/7f291166283f</a><br>> > > [2] <a href="https://github.com/openbmc/hiomapd/commit/fac3689e77d3" target="_blank">https://github.com/openbmc/hiomapd/commit/fac3689e77d3</a><br>> > > [3] <a href="https://github.com/open-power/skiboot/commit/f01cd777adb1" target="_blank">https://github.com/open-power/skiboot/commit/f01cd777adb1</a><br>> ><br>> > We already have these patches in our build, thanks.<br>><br>> Out of interest, do you have this patch included?<br>><br>> <a href="https://github.com/openbmc/btbridge/commit/aa5511d28ff9acee4a404c6397d09f5187812ed8" target="_blank">https://github.com/openbmc/btbridge/commit/aa5511d28ff9acee4a404c6397d09f5187812ed8</a><br>><br>> That might eliminate some other spurious and intermittent problems.<br><br>Yes, we have this patch.<br><br>> Again it would be great if you can point me to your trees so I can check for<br>> myself whether you've included certain patches.<br><br>Unfortunately, we still use an internal git repository for OpenBMC builds.<br>It based on upstream's master 2.7.0-dev-697-g5b03cfc66 (May 17).<br><br>For OpenPOWER firmware we have a GitHub repo:<br><a href="https://github.com/YADRO-KNS/op-build" target="_blank">https://github.com/YADRO-KNS/op-build</a><br>But it's just an our mirror of open-power/op-build with several<br>temporary workarounds.<br><br>--<br>Regards,<br>Artem Senichev<br>Software Engineer, YADRO.</font><br> </div></blockquote>
<div dir="ltr" > </div></div><BR>