[OpenPower-Firmware] SBE questions

Wed Jul 17 10:27:35 AEST 2019

On Tue, Jul 16, 2019 at 12:29:27PM -0500, Daniel M Crowell wrote:
> 
> 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. 
>
Yeah; I assume the XIP header itself is not protected by ECC since the
otprom_init.S which is burned-in expects some very specific locations
for it. Also, correct me if I'm wrong but the XIP, is that a true XIP
and its not running from ram (either attached DRAM or PIBMEM) but
instead directly from the seeprom flash? If you happen to know how to do
the stripping 'properly' I'd greatly appreciate that info.
>
> And there is some weird chip-boundary crossing logic to deal
> with as well.
> https://github.com/open-power/hostboot/blob/master/src/usr/sbe/sbe_update.C
> has some good info in the absence of real documentation.
> 
Heh, everything about these machines is weird in comparison to the
arch's I'm familiarish with (x86/arm), so no surprise there.
>
> > is 32k in size, but what documentation
> > I have seen says that the seeprom is 64k in size
> There are a total of 8 64K eeproms, which we treat as 2 distinct
> (primary/backup) SBE images.
> 
I assume you mean 8 per cpu here? As according to the dts only 4 32k
images are exposed per-cpu, or do you mean 8 for a dual-cpu system?
> 
> > So, I'm doing some preliminary work on the idea of a coreboot port for
> > p9 (specifically the talos ii based systems) and have a few questions
> Which pieces are you planning on replacing with coreboot?
> 
The intent and plan here is a reworked SBE firmware which understands
the cbfs (coreboot file system) instead of pnor, with hostboot being
replaced with bootblock/romstage/ramstage, and skiboot reworked into a
coreboot payload, which would be followed by a linux payload (skiboot
hangs around as OPAL right?) which would have the petitboot payload.
This would be the 'default' setup for these systems, but I don't see any
reason someone couldn't do the work to use alternative boot payloads
like grub or uefi (someone was working on uefi for power(9?) I saw
online at one point).
> --
> Dan Crowell
> Senior Software Engineer - Power Systems Enablement Firmware
> IBM Rochester: t/l 553-2987
> dcrowell at us.ibm.com
> 
> 
> 
> From:	"Marty E. Plummer" <hanetzer at startmail.com>
> To:	openpower-firmware at lists.ozlabs.org
> Date:	07/16/2019 12:21 AM
> Subject:	[EXTERNAL] [OpenPower-Firmware] SBE questions
> Sent by:	"OpenPower-Firmware" <openpower-firmware-bounces
>             +dcrowell=us.ibm.com at lists.ozlabs.org>
> 
> 
> 
> Hello.
> 
> So, I'm doing some preliminary work on the idea of a coreboot port for
> p9 (specifically the talos ii based systems) and have a few questions I
> can't seem to find a definitive answer for.
> 
> From the bmc, I'm able to dump 8 eeprom images over i2c; it appears that
> these are combined in some way to produce the 'real' image that executes,
> but I'm unsure as to how this goes.
> 
> According to aspeed-bmc-opp-talos.dts there are two i2c busses hooked up
> to the cpu-internal eeproms. i2c0 and i2c1 both have four i2c addresses
> which hook up to a dumpable eeprom file in sysfs, addresses 0x54-0x57.
> Each eeprom file dumped from sysfs is 32k in size, but what documentation
> I have seen says that the seeprom is 64k in size, so I'm unsure what's
> the correct combination (if any) of these files.
> 
> Further, using the p9_xip_tool report function against a dumped seeprom
> image returns an error I'm not sure how to resolve:
> 
> ```
> p9_xip_tool 1-0054.eeprom -iv report
> 
> Image section type : 0x00 "XIP image"
> Magic number       : 0x584950205345504d "XIP SEPM"
> Header version     : 0x3e
> Link Address       : 0xffb0cc1a00000000
> L1 Loader Address  : 0x00ff8002
> L2 Loader Address  : 0x0000ffff
> Kernel Address     : 0x000000ff
> Image size         : 0x00000000 (0)
> Normalized         : Yes
> TOC Sorted         : Yes
> Build Date         : 02/44/0000
> Build Time         : 00:00
> Build User         :
> Build Host         : 1c2b4
> Build Tag          :
> 
> Section Table      :
> 
>     Name            Align   DD   Start        End          Size
> 
>    .header          0       0    0x00000000                0x00000000 (0)
>    .fixed           0       0    0x0000015c   0xb301015b   0xb3010000
> (-1291780096)
>    .fixedtoc        0       0    0x00220000   0x016a07ff   0x01480800
> (21497856)
>    .toc             8       0    0x00000000                0x00000000 (0)
>    .strings         0       4    0x00000000   0xf3ffffff   0xf4000000
> (-201326592)
>    .loader_text     0       0    0x000b0000                0x00000000 (0)
>    .pibrepr_data    0       0    0x00000000   0x00020041   0x00020042
> (131138)
>    .text            0       0    0x04000000   0x33ffffff   0x30000000
> (805306368)
>    .data            5       72   0x00000800                0x00000000 (0)
>    .base            0       0    0x01b1f004   0x01b1f0e5   0x000000e2 (226)
>    .baseloader      0       0    0x00000000   0x0007ffff   0x00080000
> (524288)
>    .overrides       0       0    0x38730001   0x3f3e0400   0x06cb0400
> (113968128)
>    .rings           8       0    0x02be0800   0x02c11850   0x00031051
> (200785)
>    .overlays        0       8    0x00000000   0xf3ffffff   0xf4000000
> (-201326592)
>    .hbbl            45      68   0x004f0003   0x11670002   0x11180000
> (286785536)
> 
> TOC Report
> 
> p9_xip_image.C:354 : Returning error code 1 : P9_XIP_IMAGE_ERROR
> Header version mismatch; Expecting 9, found 62
> 
> ERROR: In command(): Command failed : P9_XIP_IMAGE_ERROR
> ```
> 
> As you can see, the 'Build Date' and 'Build Host' fields both appear to
> be 'junk' data, and the header version also appears to be wrong somehow.
> (this is executed against the eeprom on bus 0, address 0x54; the one on
> bus 1 seems to be more or less the same). I realize the actual SBE image
> written to the SEEPROMs is dynamically assembled at runtime, prior to the
> write. Perhaps this impacts the header version above?
> 
> Overall the SBE code is a bit too verbose with too many layers of
> indirection for me to easily make sense of by itself so I've been more
> or less brought to instead doing RE work against the final binary, using
> the source as a reference, so any help anyone could provide here would
> be a great help.
> 
> Regards,
> Marty
> _______________________________________________
> OpenPower-Firmware mailing list
> OpenPower-Firmware at lists.ozlabs.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.ozlabs.org_listinfo_openpower-2Dfirmware&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=mCj3CQvqek9g0fdziO-GEHyU1m9T3SAh0ZPd5s_AGpo&m=7TpSDj7MLKelzwurQrf9ZeclIMVa6p8f2AWtZ_5hxuM&s=bNpsKyLXKyg4k9Ei61_gtT_vu_W0-8OudiE4Pw622zY&e=
> 
> 
> 
>