[Skiboot] Entry points, hdata, and devicetree questions

Oliver O'Halloran oohall at gmail.com
Tue Nov 12 13:01:22 AEDT 2019

On Tue, Nov 12, 2019 at 10:14 AM Marty E. Plummer
<hanetzer at startmail.com> 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:
> > >
> > > *snip*
> > >
> > > 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 ?

Look at the implementation of load_kernel(). We first try use the
resource loading API which uses the platform hooks to load the kernel.
If that fails we fall back to the built-in kernel. If there's no
built-in kernel we'll check for the "kernel-base-address" property in
/chosen/, and if all else fails we'll assume it got loaded at
0x2000_0000. The whole load_and_boot path is a bit of a trainwreck
that could use a clean up, but no one has gotten around to it.

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

I don't really see the point. Skiboot would be running after coreboot
so why have skiboot writing into coreboot's log buffer? If you just
want coreboot's log visible to the OS we have a generic facility to
export memory ranges that would probably work.


More information about the Skiboot mailing list