<html><body><p><font size="2">One thing to remember is that there is ECC on the image in the seeprom, so you'll need to make sure to strip that off before trying to decode anything. And there is some weird chip-boundary crossing logic to deal with as well. <a href="https://github.com/open-power/hostboot/blob/master/src/usr/sbe/sbe_update.C">https://github.com/open-power/hostboot/blob/master/src/usr/sbe/sbe_update.C</a> has some good info in the absence of real documentation.</font><br><br><font size="2">> </font><tt><font size="2">is 32k in size, but what documentation<br>> I have seen says that the seeprom is 64k in size</font></tt><br><font size="2">There are a total of 8 64K eeproms, which we treat as 2 distinct (primary/backup) SBE images.</font><br><br><br><tt><font size="2">> So, I'm doing some preliminary work on the idea of a coreboot port for<br>> p9 (specifically the talos ii based systems) and have a few questions </font></tt><br><font size="2">Which pieces are you planning on replacing with coreboot?</font><br><font size="2"><br>--<br>Dan Crowell<br>Senior Software Engineer - Power Systems Enablement Firmware<br>IBM Rochester: t/l 553-2987<br>dcrowell@us.ibm.com</font><br><br><img width="16" height="16" src="cid:1__=09BB0EAADFCCED358f9e8a93df938690918c09B@" border="0" alt="Inactive hide details for "Marty E. Plummer" ---07/16/2019 12:21:30 AM---Hello. So, I'm doing some preliminary work on the idea"><font size="2" color="#424282">"Marty E. Plummer" ---07/16/2019 12:21:30 AM---Hello. So, I'm doing some preliminary work on the idea of a coreboot port for</font><br><br><font size="2" color="#5F5F5F">From: </font><font size="2">"Marty E. Plummer" <hanetzer@startmail.com></font><br><font size="2" color="#5F5F5F">To: </font><font size="2">openpower-firmware@lists.ozlabs.org</font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">07/16/2019 12:21 AM</font><br><font size="2" color="#5F5F5F">Subject: </font><font size="2">[EXTERNAL] [OpenPower-Firmware] SBE questions</font><br><font size="2" color="#5F5F5F">Sent by: </font><font size="2">"OpenPower-Firmware" <openpower-firmware-bounces+dcrowell=us.ibm.com@lists.ozlabs.org></font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br><tt><font size="2">Hello.<br><br>So, I'm doing some preliminary work on the idea of a coreboot port for<br>p9 (specifically the talos ii based systems) and have a few questions I<br>can't seem to find a definitive answer for.<br><br>From the bmc, I'm able to dump 8 eeprom images over i2c; it appears that<br>these are combined in some way to produce the 'real' image that executes,<br>but I'm unsure as to how this goes.<br><br>According to aspeed-bmc-opp-talos.dts there are two i2c busses hooked up<br>to the cpu-internal eeproms. i2c0 and i2c1 both have four i2c addresses<br>which hook up to a dumpable eeprom file in sysfs, addresses 0x54-0x57.<br>Each eeprom file dumped from sysfs is 32k in size, but what documentation<br>I have seen says that the seeprom is 64k in size, so I'm unsure what's<br>the correct combination (if any) of these files.<br><br>Further, using the p9_xip_tool report function against a dumped seeprom<br>image returns an error I'm not sure how to resolve:<br><br>```<br>p9_xip_tool 1-0054.eeprom -iv report <br>Image section type : 0x00 "XIP image"<br>Magic number : 0x584950205345504d "XIP SEPM"<br>Header version : 0x3e<br>Link Address : 0xffb0cc1a00000000<br>L1 Loader Address : 0x00ff8002<br>L2 Loader Address : 0x0000ffff<br>Kernel Address : 0x000000ff<br>Image size : 0x00000000 (0)<br>Normalized : Yes<br>TOC Sorted : Yes<br>Build Date : 02/44/0000<br>Build Time : 00:00<br>Build User :<br>Build Host : 1c2b4<br>Build Tag : <br><br>Section Table :<br><br> Name Align DD Start End Size<br><br> .header 0 0 0x00000000 0x00000000 (0)<br> .fixed 0 0 0x0000015c 0xb301015b 0xb3010000 (-1291780096)<br> .fixedtoc 0 0 0x00220000 0x016a07ff 0x01480800 (21497856)<br> .toc 8 0 0x00000000 0x00000000 (0)<br> .strings 0 4 0x00000000 0xf3ffffff 0xf4000000 (-201326592)<br> .loader_text 0 0 0x000b0000 0x00000000 (0)<br> .pibrepr_data 0 0 0x00000000 0x00020041 0x00020042 (131138)<br> .text 0 0 0x04000000 0x33ffffff 0x30000000 (805306368)<br> .data 5 72 0x00000800 0x00000000 (0)<br> .base 0 0 0x01b1f004 0x01b1f0e5 0x000000e2 (226)<br> .baseloader 0 0 0x00000000 0x0007ffff 0x00080000 (524288)<br> .overrides 0 0 0x38730001 0x3f3e0400 0x06cb0400 (113968128)<br> .rings 8 0 0x02be0800 0x02c11850 0x00031051 (200785)<br> .overlays 0 8 0x00000000 0xf3ffffff 0xf4000000 (-201326592)<br> .hbbl 45 68 0x004f0003 0x11670002 0x11180000 (286785536)<br><br>TOC Report<br><br>p9_xip_image.C:354 : Returning error code 1 : P9_XIP_IMAGE_ERROR<br>Header version mismatch; Expecting 9, found 62<br><br>ERROR: In command(): Command failed : P9_XIP_IMAGE_ERROR<br>```<br><br>As you can see, the 'Build Date' and 'Build Host' fields both appear to<br>be 'junk' data, and the header version also appears to be wrong somehow.<br>(this is executed against the eeprom on bus 0, address 0x54; the one on<br>bus 1 seems to be more or less the same). I realize the actual SBE image<br>written to the SEEPROMs is dynamically assembled at runtime, prior to the<br>write. Perhaps this impacts the header version above?<br><br>Overall the SBE code is a bit too verbose with too many layers of<br>indirection for me to easily make sense of by itself so I've been more<br>or less brought to instead doing RE work against the final binary, using<br>the source as a reference, so any help anyone could provide here would<br>be a great help.<br><br>Regards,<br>Marty<br>_______________________________________________<br>OpenPower-Firmware mailing list<br>OpenPower-Firmware@lists.ozlabs.org<br><a href="https://lists.ozlabs.org/listinfo/openpower-firmware">https://lists.ozlabs.org/listinfo/openpower-firmware</a> <br><br></font></tt><br><br><BR>
</body></html>