[OpenPower-Firmware] SBE questions

[Stewart Smith]

"Marty E. Plummer" <hanetzer at startmail.com> writes:

> 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.

We have libflash/ from the skiboot tree, which is used in a few places
at least, and that's probably the leading candidate.

>> >> 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.

So, there's only real one use for ECC anymore.

Back on POWER8 systems we originally talked directly to the flash
controller to read the flash. If there were ECC errors there, we could
correct them. Notably, not *all* of firmware needed to boot was ECC'd,
so there was only about half of the firmware needed to boot that you
could possibly have an ECC error in and still boot. So, effectively
pretty damn useless.

Now with mbox and hiomap, we're just reading the data over LPC from RAM
on the BMC. The BMC presumably has a sensible way to ensure there's not
errors on storage (e.g. data checksums), and we also have Secure Boot
enforcing that the hashes match (and xz compression with CRC32
checksums). So any bit error *will* be detected, although not
*corrected*.

LPC itself doesn't have any ECC on it, so we *could* get bit flips
transferring from the BMC, but these would be caught by secure boot or
the CRC32 in xz compression, so a simple reboot would probably fix
things.

I'm not sure there's any value in continuing to have ECC anywhere TBH.

>> >> 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)

I think Jeremy has a plan to upstream the petitboot makefile to
buildroot, and then you should be able to create that image purely with
upstream buildroot rather than needing op-build.

>> >> 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.

At some point early in Hostboot, it protects the SBE SEEPROM from being
written. It does this so that you can't then compromise secure boot, and
it's also a nice bit of brick protection.

-- 
Stewart Smith
OPAL Architect, IBM.