[OpenPower-Firmware] SBE questions

[Marty E. Plummer]

> "Marty E. Plummer" <hanetzer at startmail.com> writes:
> >> > 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).
>
> You can just hack the Hostboot Boot Loader (part of hostboot, see
> src/bootloader/) to understand CBFS and that'll get the SBE loading
> things.
>
Yeah, someone else mentioned this approach earlier.
> I might suggest going in reverse order though through the firmware
> stack, first get skiboot to understand CBFS (likely in a simulator like
> qemu or Mambo - aka POWER9 Functional Simulator), then get Hostboot to
> understand it, then the Hostboot Boot Loader.
>
> TBH, re-using a data structure and code for it for our flash layout
> would be an improvement over what we have now.
>
I cannot parse this statement, could you rephrase?

> There's also mboxd on the BMC which can construct a FFS image on-the-fly
> based on files in the BMC filesystem, and it could be modified to
> present a CBFS image, and likely largely just unit tested.
>
That would be cool stuff.

> Looking at the Coreboot docs, it looks like there's a redesign of cbfs
> going on? Perhaps even replacing it with Flashmap?
>
Beware the docs. Their are two sets, one is old wiki and the other is
generated from the coreboot repo's documentation tree.
> There have been *two* PoC implementations of UEFI for POWER, and it's
> something we've discussed a few times. The biggest disadvantage is that
> it's a giant monstor of a code-stack that has to be maintained, and
> there just aren't resources for it. Balance that with the "you can take
> Petitboot from our cold dead hands" attitude of anyone who ever uses it
> after any other firmware environment, and I'm not sure we'd gain much
> there.
>
Yeah, petitboot is hella nice. I stuck it into the 8mb flash on my kevin
chromebook (lotta compression needed there!)

> Also consider that although "option ROMs" is also presented as an
> advantage to UEFI, there's been literally zero option ROMS ever shipped
> in EFI Byte Code, so you'd get to include an x86-64 emulator, and have
> to deal with IO space and other things that just don't exist in POWER
> hardware.
>
> An idea discussed was to make Petitboot be a UEFI application (like GRUB
> is), and that's probably the sanest and most backwards-compatible way to
> look at a UEFI implementation.
You mean, like petitboot.efi without a kernel at all? I actually have my
x86_64-efi machine using petitboot inside an efistub kernel+initramfs,
so that works at least.

>
> "Marty E. Plummer" <hanetzer at startmail.com> writes:
> >> 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?
>
> Correct. There's another ECC algorithm in there, and I *think* it's
> what's used on flash for the IBM FSP, but I'm not sure. The repository
> where the 'ecc' binary comes from was thrown over the wall 5.5years ago
> or so and was unmaintained until I gained god-mode on the open-power org
> and merged my patches from years prior :)
>
> Mind you, if anyone knows the origins, Dean is the person :)
>
> > 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.
>
> It'd be really cool if you wrote all this up and blogged it somewhere.
>
I've been waffling on the idea for a long time but all the blog software
sucks lol. I've a fair amount of useful information I could put up
there.

> Probably the most terrifying thing about hacking on OpenPOWER firmware
> is bricking your SBE.
>
Actually, my investigations says that (at least on talos) its relatively
easy to reprog the sbe... I've done a full wipe and rewrite from a dump
earlier, just some file called eeprom under /sys/devices/platform/ahb/...
cat to dump, cat from /dev/zero to nuke, cat from eeprom dump to eeprom
sysfs file, back exactly how it was before.

> A utility that sits on and ships with the BMC to verify and reprogram it
> if needed would be *fantastic*. Something that doesn't come with the
> overhead of the (internal) debug tools that is.
>
> --
> Stewart Smith
> OPAL Architect, IBM.