[OpenPower-Firmware] SBE questions

Marty E. Plummer hanetzer at startmail.com
Thu Jul 18 06:54:31 AEST 2019


> Hi Marty,
> 
> > >
> > > 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
> 
> The XIP header actually is protected by ECC -- the HW itself strips it out
> for the SBE (and thus the code running in the OTPROM).
> 
Hmm. So if the hw strips the ecc automatically, does that mean that
whatever replacement sbe firmware I cook must be ecc'd before being
written to the seeprom?
>
> > 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.
> 
> The SBE boot flow goes as follows:
> 1) execute directly from OTPROM (reset I2C bus, check for magic)
> 2) jump to SEEPROM, execute just enough from here to copy a loader into PIBMEM
> 3) Loader copies and decompresses the main SBE image into PIBMEM.
>     a) At this point the SBE "kernel" and execution loop are running from PIBMEM
>     b) Some of the code is still executed from SEEPROM directly due to lack of space
> 4) SBE will boot istep 2-4 doing chip HW init
> 5) in istep 5 SBE will load the Hostboot boot loader (HBBL) from SEEPROM
> 6) HBBL is what actually reads the file format on PNOR and loads Hostboot proper
> 
Ok, this is good info. I've ran into similar stuff in u-boot previously.
> 
> > > > 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?
> 
> There are 8 per-cpu -- treated as a primary SBE boot flash and alternate
> (in case the primary is corrupted during a code update)
>
Yeah. I got back 4x2 images. They were all 32k though.
>
> Here is info on how to extract and remove the ECC on the SBE SEEPROM
> image. There are actually 4 unique SEEPROMs that the SBE treats as a
> logical "flash".  The following commands are from IBM's service processor
>
That's the ibm equivalent of a bmc, correct?
>
> -- you will have to tweak, but in general just need to read the
> "-a" address, offset 0 for 65529 bytes, then append all the images together.
>
Yeah, I got 4 images from each bus, but they only had 32k inside them.
>
> Notice that the althernate is on a different I2C bus, but same addresses:
> 
Yeah, I had the same thing on my sysfs explorations. However it was
addresses 0x54-0x57 and they were all 32k in size.
> #Read primary image and reconstruct
> iicmaster -b /dev/iic/L02C0E06P01  -t 24C512 -a 0xa8 -W 2 -o 0
> --file=./sbe_0 -r 65529
> iicmaster -b /dev/iic/L02C0E06P01  -t 24C512 -a 0xaa -W 2 -o 0
> --file=./sbe_1 -r 65529
> iicmaster -b /dev/iic/L02C0E06P01  -t 24C512 -a 0xac -W 2 -o 0
> --file=./sbe_2 -r 65529
> iicmaster -b /dev/iic/L02C0E06P01  -t 24C512 -a 0xae -W 2 -o 0
> --file=./sbe_3 -r 65529
> cat sbe_0 sbe_1 sbe_2 sbe_3 > sbe.bin.ecc
> 
> #Read alt image and reconstruct
> iicmaster -b /dev/iic/L02C0E06P03  -t 24C512 -a 0xa8 -W 2 -o 0
> --file=./sbe_0 -r 65529
> iicmaster -b /dev/iic/L02C0E06P03  -t 24C512 -a 0xaa -W 2 -o 0
> --file=./sbe_1 -r 65529
> iicmaster -b /dev/iic/L02C0E06P03  -t 24C512 -a 0xac -W 2 -o 0
> --file=./sbe_2 -r 65529
> iicmaster -b /dev/iic/L02C0E06P03  -t 24C512 -a 0xae -W 2 -o 0
> --file=./sbe_3 -r 65529
> cat ./sbe_0 ./sbe_1 ./sbe_2 ./sbe_3 > ./sbe.alt.bin.ecc
> 
> To remove ECC use this tool from op-build
> <op-build repo>/output/host/bin/ecc --remove ./sbe.bin.ecc --output sbe.bin --p8
> 
^ this --p8 worries me; I assume you're still talking about p9 but this
tool was made in the p8 era and they both use the same ecc algos?
Otherwise, this worked, and it ended up giving me one single 32k image
which the p9_xip_tool understood properly, along with non-garbage
metadata.
> 
> > >
> > > > 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).
> 
> As I mentioned above the SBE doesn't ever read the PNOR directly -- it just
> loads the HBBL which is stored on the SEEPROM.
>
Yeah, I realize the bit on the seeprom that deals with the pnor is
actually in the hostboot repo but I was just referring to the entire
seeprom's firmware collectively.
>
> So if you just want to tweak it to understand cbfs -- then you are going to
> want to modify the files in hostboot:
> https://github.com/open-power/hostboot/tree/master/src/bootloader
> 
> If you make changes there op-build will compile them into img/hbibl.bin
> which then gets morphed into the PNOR partiton HBBL (if you try to use hbibl.bin
> directly please note that the first 12K for exception vectors gets chopped
> off).
> 
> During normal boot Hostboot will check the contents of the SBE + HBBL partition
> and if it doesn't mactch what is in the SEEPROM, it will update it. So for your
> work you can probably just rely on the HBBL partition and the automatic update
> path.


More information about the OpenPower-Firmware mailing list