[Top][All Lists]

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

Re: [PATCH qemu v23] spapr: Fix implementation of Open Firmware client i

From: BALATON Zoltan
Subject: Re: [PATCH qemu v23] spapr: Fix implementation of Open Firmware client interface
Date: Fri, 9 Jul 2021 17:35:18 +0200 (CEST)

On Fri, 9 Jul 2021, Alexey Kardashevskiy wrote:
On 09/07/2021 23:28, BALATON Zoltan wrote:
On Fri, 9 Jul 2021, Alexey Kardashevskiy wrote:
On 09/07/2021 08:34, BALATON Zoltan wrote:
MorphOS still boots but this breaks Linux which changes a few things in the device tree to fix it up to make it look the way it thinks is better.

What are those things? What does the change break precisely? Does the kernel stop booting?
Can you please send output with the trace_vof_setprop tracepoint enabled?

It's fixing up some props that on Pegasos2 firmware are not how Linux expects them.

Why does it need to fix them then? You are building the FDT in QEMU, built it in the way Linux like and then you do not depend on the kernel fixing them up. What do I miss?

The SmartFirmware used on the real hardware has some quirks that Linux handles by fixing up the device tree. The board firmware has the device tree the way I build it. I want to be compatible with how things work with actual board firmware (thus replacing the non-distributable firmware blob with VOF but still allowing using a ROM image if needed) not just get things work with VOF by whatever hacks needed to get Linux boot. Keeping compatibility with board firmware is useful so other guests can work too and avoid possible conflicts with different assumptions from different guests that may need different hacks if not using board ROM and also it's simpler to debug by just comparing with what the real firmware has. These fix ups are needed with the board firmware so they are also needed with VOF which emulates the board firmware now, at least to the point of simple CI and RTAS that's enough for some guests to boot (currently Linux and MorphOS which are the two guests that work well enough with current state of emulation anyway; AmigaOS needs some graphics driver or better Radeon emulation then it would need more stuff from VOF as it calls methods to access disk blocks which may be something you did in your further patches for GRUB so I can get back to it when you get to GRUB support but that's not urgent as there's no ouput without a graphics driver in AmigaOS so not really useful to fix VOF for it now).

From traces I see that (besides PCI) it mostly sets props for linux-initrd/bootargs which you rather need to handle to keep the machine's properties and the FDT in sync.

How do I handle that and what do I need to keep in sync? The pegasos2 does not support -initrd option as initrd is embedded in kernel and -append is just passed through to bootags. I don't use these in QEMU at all so the guest can do whatever it wants with them.


reply via email to

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