Il dom 2 feb 2020, 12:51 Alexey Kardashevskiy <
address@hidden> 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