[Skiboot] Entry points, hdata, and devicetree questions

[Oliver O'Halloran]

On Sun, 2019-11-10 at 15:06 -0600, Marty E. Plummer wrote:
> Greetings.
> 
> 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.

I suspect you've low-balled the amount of work required here since the
implementing the API required by the hardware procedures is pretty
involved (read: insane) and I don't think re-implementing them from
scratch is viable. Writing them in the first place was a multi-year
project for a lot of people and even with public docs odds are there
will be some parts that just require asking the HW designer what the
hell they were thinking.

Alistair (+cc) has been working on implementing the HWP API in C (the
HWPs themselves are C++) that would allow integrating them into
coreboot. I don't think that's public yet, but it's a blocker for other
work so that should happen soonish.

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

We don't load the ELF directly so nothing outside of skiboot itself
really knows (or cares) about boot_entry. The entry point that gets
used is chosen by whatever is loading skiboot based on whether the
loader is providing HDAT or FDT. As you pointed out there's three cases
of interest:

1. P8 FSP, where the FSP generates HDAT after hostboot has run.
2. P8 OpenPower, where hostboot generates an FDT.
3. P9 systems where Hostboot generates HDAT.

Keep in mind this is only the "normal" cases where we're booting a real
system with an offical firmware image. For simulators like qemu we
always generate an FDT and we also have internal debug tools to boot
the system without hostboot which also generate an FDT for skiboot.
There's nothing stopping you from doing the same from coreboot.

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

HDAT isn't a new thing. It dates from about ~2004 and it's really the
interface between the FSP and Phyp (the proprietary FW hypervisor). It
was re-purposed as the interface between hostboot and skiboot on P9
because we already supported so that we could boot skiboot on FSP
systems. I think there was some reason for moving the generation of
some parts of HDAT into hostboot too, but I don't remember the details.

The decision to use HDAT everywhere on P9 was largely because we had
few problems with bad DTs being generated by hostboot and wanted to
move the DT generation into skiboot where we had better control over
what was created. In hindsight this was a mistake and everyone involved
regrets doing it, but there's no hugely compelling reason to re-write
it all, yet...

This is our problem to deal with though. You can, and should, ignore
HDAT entirely.

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

We ship a single image for skiboot that supports all processors and
platforms. Features like the stb/cvc API are enabled based on the
existance of DT specific nodes, or nodes with a certain compatible
string. Adding drivers for coreboot specific interfaces should be
pretty straightforward with a combination of DT checks and using the
platform hooks we provide.

> Also would
> probably need a smidge of glue code here and there for corebot specifics
> (for example cbfs 'partitioning' instead of pnor,

We've already got loading objects from flash abstracted since it's
different between FSP and BMC systems. Pre-loading a kernel is
supported via some properties in the chosen node (used on qemu), but
you could probably do a more complete implementation by providing a
coreboot specific implementation of the start_preload_resource() and
resource_loaded() platform hooks.

> making use of the preram cbfs cache for the opal msglog and so forth).

The what?

> Thoughts/suggestions?
> 
> ---
> Marty Plummer
> _______________________________________________
> Skiboot mailing list
> Skiboot at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/skiboot