[OpenPower-Firmware] SBE questions

[Marty E. Plummer]

On Mon, Jul 22, 2019 at 04:14:50PM +1000, Stewart Smith wrote:
> "Marty E. Plummer" <hanetzer at startmail.com> writes:
> >> 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?
> 
> The FFS format that we use is something that is ill-defined and
> strangely custom. It also has *multiple* implementations to parse and
> generate it.
> 
Ah, gotcha. So there's a lot of code duplication up and down the stack.
Yeah, having a common implementation would be nice.
> >> 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.
> 
> I saw nothing about CBFS in the documentation tree, just on the wiki.
> 
Yeah... Also I'm gonna have fun implementing ecc support (assuming there
is none already) as it would suck to lose features while moving
platforms.
> >> 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!)
> 
> Wow, we barely fit things into 16MB.
>
It was a rather fun process. Eventually I'll put together a forked
op-build which creates the image for use in coreboot automatically
(currently I manually compress the kernel Image and make the fit image)
> >> 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.
> 
> either way. Good to know that it works on x86 though.
> 
Yeah, bit of work needed there though, since there is no nvram backing.
I know the arm64 implementation has uefi support so perhaps I can learn
how that works and implement something for x86_64-efi. Definitely need
to see if you can set arbitrary efi variables in a vendor firmware.
> >> > 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.
> 
> I know the feeling.... I manage to cope with self hosted Wordpress,
> although if I was starting afresh, I'd probably just get wordpress.com
> to host it as then I don't have to worry about anything.
> 
> >> 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.
> 
> Sweet! I was kind of hoping that would magically work on OpenBMC platforms.
> 
Yeah. Although not all the seeproms are broke out like this (honestly
I'm a bit confused on the counts here as I've seen references to three,
two, and one seeprom on the cpu so I really don't know how many there
are). Apparently only one is presented on the bmc i2c bus so if I write
a new sbe firmware and write it to that seeprom I'm not certain that's
the one that will 'take' and boot the new coreboot path... do you happen
to know of any way to access the other seeprom(s) to write the new
firmware from the power9 userspace? Its my understanding that that bus
is protected somehow from the view of the power9 after we get to
userspace.
> 
> -- 
> Stewart Smith
> OPAL Architect, IBM.
>