[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH qemu v2] spapr: Kill SLOF

From: Philippe Mathieu-Daudé
Subject: Re: [PATCH qemu v2] spapr: Kill SLOF
Date: Mon, 6 Jan 2020 19:56:04 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2

On 1/6/20 6:25 PM, Peter Maydell wrote:
On Mon, 6 Jan 2020 at 17:09, Cédric Le Goater <address@hidden> 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.


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?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]