Il dom 2 feb 2020, 12:51 Alexey Kardashevskiy <aik@ozlabs.ru> ha scritto:

> > QEMU must not load GRUB from disk, that's the firmware's task.  If you
> > want to kill SLOF, you can rewrite it, but loading the kernel GRUB from
> > disk within QEMU is a bad idea: the next feature you'll be requested to
> > implement will be network boot, and there's no way to do that in QEMU.
>
> What is exactly the problem with netboot? I can hook up the OF's "net" to
> a backend (as I do for serial console and
> blockdev, in boot order)


Who provides the OpenFirmware entry point when you remove SLOF and boot
directly into grub?

Or alternatively it is possible with my patchset to load petitboot (kernel
> + intramdisk, the default way of booting
> POWER8/9 baremetal systems) and that thing can do whole lot of things, we
> can consider it as a replacement for ROMs from
> devices (or I misunderstood what kind of netboot you meant).
>

Why wouldn't that have the same issue as SLOF that you describe below (I
honestly don't understand anything of it, but that's not your fault :-)).

Paolo


> > You should be able to reuse quite a lot of code from both
> > pc-bios/s390-ccw (for virtio drivers) and kvm-unit-tests (for device
> > tree parsing).  You'd have to write the glue code for PCI hypercalls,
> > and adapt virtio.c for virtio-pci instead of virtio-ccw.
>
> The reason for killing SLOF is to keep one device tree for the entire boot
> process including
> ibm,client-architecture-support with possible (and annoying) configuration
> reboots. Having another firware won't help
> with that.
>
> Also the OF1275 client interface is the way for the client to get
> net/block device without need to have drivers, I'd
> like to do just this and skip the middle man (QEMU device and guest driver
> in firmware/bootloader).
>
> I'll post another RFC tomorrow to give a better idea.
>
>
> --
> Alexey
>
>