[Skiboot] Entry points, hdata, and devicetree questions
Marty E. Plummer
hanetzer at startmail.com
Thu Nov 14 08:13:08 AEDT 2019
On Tue, Nov 12, 2019 at 12:35:14PM +1100, Alistair Popple wrote:
> 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).
Hmm. 'need' is kinda subjective here. I think I've seen some open-power
spec which says firmware must be BE but could be wrong. I've been working
in build system guts to be able to build in both modes. Would require a
BE->LE flip very early in the bootblock. Ideally I'd get it more or less
running in LE mode and be able to step through it in BE mode to find the
endian breaks, since you generally want software to be clean for both.
> 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).
Yeah, lot of reading there. Basically yes and yesish. Coreboot has a
means to use external code ('vendorcode' in the tree) 'as is' but you
could either rewrite it entirely in coreboot style or just use a smidge
of glue code.
> 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.
Yeah, that's the hardest part of it I think. so much abstraction makes
it hard to follow at times.
> > > > 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
> > >
More information about the Skiboot