[Skiboot] Entry points, hdata, and devicetree questions

[Alistair Popple]

On Tuesday, 12 November 2019 10:13:45 AM AEDT Marty E. Plummer wrote:
> 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).

Do you need to make BE builds? As far as I know it should be possible to do 
this as LE code if that makes porting coreboot easier (and in fact longer term 
is probably desirable).

>From the driver perspective what are you aiming for? Does coreboot just become 
the host/platform for running the existing hardware procedure flow or are you 
looking to rewrite these procedures and integrate them in some coreboot 
specific way? I'm certainly interested in helping any effort to rewrite these 
but as Oliver said it's a lot of work for which the only documentation is the 
existing code (which isn't particularly easy to follow - for reference see 
https://github.com/open-power/hostboot/tree/master/src/import/chips which is 
what's known internally as the hardware procedures).

So as an interim measure we've been creating a reference implementation of the 
API (known internally as FAPI) that is required run the existing procedures 
with the hope that they could be rewritten/reworked into something cleaner one 
by one without having to rewrite them all at once.

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

Not yet, but if your interested I should be able to push something out. Note 
that whilst it binds to a C API due to the way things have been designed 
internally it's implemented in C++. However thankfully the procedures don't 
rely heavily on anything that doesn't exist in an embedded runtime 
environment. They mainly seem to exploit copiouss amount of C++ templating in 
dubious ways which is what I'm trying to untangle.

<snip>

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

It's not :-)

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

It does, but I think what Oliver is referring to is the actual mechanism for 
reading the kernel image from storage. In other words adding a coreboot 
specific mechanism to access the kernel image from skiboot shouldn't be too 
hard because we already support two completely different systems using resource 
hooks (FSP and BMC) for access anyway.

- Alistair

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