<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10.5pt" ><div dir="ltr" >Everything I have observed so far has the correct ecc calculation. Another thing that could cause the symptom being see is that the pnor as not been erased.  If the existing value of a pnor 8 byte field is ff ff ff ff ff ff ff ff 00 and new data is written w/o an "erase" then the new data would look fine, except the ecc byte would not be changed from 00.</div>
<div dir="ltr" >When does the erase happen?</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: Douglas Gilbert <dgilbert@us.ibm.com><br>Cc: andrew@aj.id.au, openpower-firmware@lists.ozlabs.org<br>Subject: [EXTERNAL] Re: Re: [OpenPower-Firmware] [POWER8] OCC Firdata over IPMI<br>Date: Sat, May 25, 2019 1:33 PM<br> 
<div><font size="2" face="Default Monospace,Courier New,Courier,monospace" >On Fri, May 24, 2019 at 9:14 PM Douglas Gilbert <dgilbert@us.ibm.com> wrote:<br>><br>> All,<br>> Some additional findings on the OCC FIRDATA collection:<br>> 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.<br>><br>> 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.<br>> 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.<br><br>I assume ECC is correctly computed. Data can be corrupted during writing.<br>May be there are some problems in the SPI driver implementation inside<br>the OpenBMC (AST2400):<br><a href="https://lists.ozlabs.org/pipermail/openbmc/2019-April/015953.html" target="_blank">https://lists.ozlabs.org/pipermail/openbmc/2019-April/015953.html</a><br><br>Artem<br><br>> 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.</font><br> </div></blockquote>
<div dir="ltr" > </div></div><BR>