[Skiboot] Entry points, hdata, and devicetree questions

[Oliver O'Halloran]

On Tue, Nov 12, 2019 at 12:35 PM Alistair Popple <alistair at popple.id.au> 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:
> > > >> > > > 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

Pretty much. I was thinking coreboot could pre-load it and put
something in the DT to tell skiboot where it is. Then coreboot based
platforms could have a coreboot_resource_loaded() that scans the DT
for pre-loaded images rather than doing it in skiboot. It might be
worth implementing something like that anyway for testing in QEMU
without a PNOR.