Re: [PATCH qemu v2] spapr: Kill SLOF

["Philippe Mathieu-Daudé" <philmd@redhat.com>]

On 1/6/20 6:25 PM, Peter Maydell wrote:
> On Mon, 6 Jan 2020 at 17:09, Cédric Le Goater <clg@kaod.org> wrote:
>> ARM bootloaders are also embedded in QEMU's code. See hw/arm/boot.c.
>> You could improve a bit the definition though.
> 
> Given an opportunity to restart from scratch I don't know
> that I'd do things the way hw/arm/boot.c does. The initial
> idea was really simple and straightforward: 3 or 4 insns
> which just set some registers and jumped to the kernel.
> Fast-forward a decade or two, and the complexity has
> significantly increased as we added extra tweaks to deal
> with SMP systems, the GIC interrupt controller, boards
> which need to do some extra odd stuff, CPUs which start
> in Secure state, 64-bit CPUs, mangling the DTB, booting
> multiple flavours of image file format, implementing
> various 'firmware' functionality and APIs, and so on and on.

:S

> Insisting from the start that QEMU emulates what bare metal
> hardware does, and doesn't get into the business of faking
> up the behaviour of firmware would have been a neater
> separation of concerns in the long run.
> 
> To the narrower concern, yeah, on the arm side we
> just embed hand-assembled hex values in the C file;
> this is mostly to avoid needing a cross-compiler setup at
> QEMU build time, but it also lets us hand-patch the
> binary blob at runtime to fill in addresses and so on.

This was also before we provide a handy docker image with cross compiler 
for about all architectures supported.

Maybe the cross-build-guest-tests target from tests/tcg/Makefile.qemu 
can be reused to build spapr-rtas.S?