[Skiboot] Entry points, hdata, and devicetree questions
Marty E. Plummer
hanetzer at startmail.com
Tue Nov 12 10:13:45 AEDT 2019
On Mon, Nov 11, 2019 at 01:33:11PM +1100, Oliver O'Halloran wrote:
> 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.
No, I'm hella high-balling the project. I rather doubt that I as a
single entity can achieve this. However, I do believe I can do enough
work to attract a critical mass of developers who are interested in the
same project. Even discounting the large amount of work to be done in
writing drivers and such, as in 'real code', I've discovered a large
amount of coreboot to be heavily leaned towards LE code, so much as to
make BE builds of my current coreboot work fail on progressing from
bootblock to romstage (and probably the same going forward).
> 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.
That would be quite useful. Is there some mailing list/repo I should be
watching for this?
> > 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.
Ok, that was what I had in mind (generate fdt in coreboot before handing
off to skiboot) but reading the bit about p9 and hdat made me a bit
worried for lack of docs.
> > 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.
True. I suppose hdat probably came into use for you guys before fdt
because (I would guess) fsp p8 systems (which use hdat) came before
open-power p8 systems (which uses a fdt). Just curious as to stuff.
> 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.
Excellent. I don't mind learning new things but if I already know
something 'standard' which fills a role the 'new' 'nonstandard' thing
also does, well, I tend to get a bit annoyed unless the 'new' thing is
exceptionally better than the old in some way.
> > 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.
Well the thing is I am basically wanting skiboot to not touch kernel
loading at all, for my platform. Unless I'm reading wrong, does this not
happen unconditionally at the end of core/init.c:main_cpu_entry with the
function load_and_boot_kernel ?
> > making use of the preram cbfs cache for the opal msglog and so forth).
> The what?
Basically its a bit of memory where coreboot's equivalent of 'dmesg'
buffer lives until serial or some form of output gets up. I think there
is a similar bit in hostboot, the 'kernel_printk_buffer'.
> > Thoughts/suggestions?
> > ---
> > Marty Plummer
> > _______________________________________________
> > Skiboot mailing list
> > Skiboot at lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/skiboot
More information about the Skiboot