[Skiboot] Entry points, hdata, and devicetree questions

Marty E. Plummer hanetzer at startmail.com
Mon Nov 11 08:06:25 AEDT 2019


As you may be aware, I'm currently working on porting coreboot to the p9
platform (specifically the talos ii line of products). The plan is to go
through the normal coreboot process (bootblock->romstage->ramstage),
then execute skiboot, more or less as it currently exists, in a manner
similar to how bl31 is executed on rk3399 coreboot platforms, then
execute a FIT image as a payload.

This is quite a large task, and I'm having to read and cross reference
quite a lot of code and datasheets, and annoy a few mailing lists in the
process, so now its your turn.

The entry to skiboot is asm/head.S, that much I can gather, but I'm a
bit unsure as to the actual entry point. readelf on the final skiboot.elf
points at boot_entry, but the comment above fdt_entry says this is where
you go (it branches almost immediately to boot_entry anyways) if you
have a devicetree pointer in r3, and hdat_entry for fsp, so I'm quite a
bit confused as to what's actually happening.

On another note, the documentation says that power9 only uses hdat, and
that p8 may be both hdat and a mini device tree from fsp, or purely a
devicetree on open-power systems. Which of these statements are actually
true in the case of an Open-Power P9 system like the talos ii? And said
snippet of documentation says HDAT spec is not public, as its just an
interface between hostboot and skiboot. Well, I'm going to have to
interface with skiboot in some manner, so I'm going to have to either be
able to use a flattened image tree (why even bother with a new thing
hdat? was devicetree not good enough for some reason? just confused since
as mentioned in the docs devtree is an industry standard used by just
about everything not x86) or hdat. That being said, is there any work or
consideration for opening the hdat spec? A bit hard to use an interface
without documentation.

And, I think this may be my last concern in this area, about booting the
kernel and your version of secureboot. Would the skiboot project be
amicable to patches to enable conditional enabling of either stb/cvc or
coreboot's own vboot solution, along with not handling kernel load via
skiboot (letting coreboot's own FIT support handle it)? Also would
probably need a smidge of glue code here and there for corebot specifics
(for example cbfs 'partitioning' instead of pnor, making use of the
preram cbfs cache for the opal msglog and so forth).


Marty Plummer

More information about the Skiboot mailing list