qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] sun4m: Add FCode ROM for TCX framebuffer


From: Mark Cave-Ayland
Subject: Re: [Qemu-devel] [PATCH] sun4m: Add FCode ROM for TCX framebuffer
Date: Sat, 24 Aug 2013 14:05:13 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12

On 21/08/13 18:06, Peter Maydell wrote:

Okay so in that case what is the best way to manage to process? If both this
and the follow-up patchset are committed first without the associated FCode
ROM images then qemu-system-sparc will be broken until the main OpenBIOS
images are updated because (quite rightly) the TCX driver will attempt to
load the ROM at startup and fail because they aren't present...?

Is the best way to send a pull request for the update OpenBIOS images plus
associated FCode ROMs first and then work on getting the QEMU patches
applied? This isn't strictly correct, but the display code currently has a
"panic" fallback in place where it should try and load an inbuilt TCX driver
if it doesn't find a valid display ROM during probe.

I guess Anthony gets to make the call on what we should do here,
but my opinion is that if the problem is effectively "these QEMU
changes must be in sync with these updated OpenBIOS images" then
(a) something's wrong because having QEMU that closely coupled
to firmware is rather dubious and (b) there should be a single patch
[and thus a single git commit] which both updates QEMU and updates
the blobs in our repo and updates the gitmodule to point at the
sources we used to build those blobs].

Just to clarify that all of the changes don't have to go in one commit, since the current OpenBIOS has a (temporary) fallback to use an internal copy of the old hard-wired TCX FCode blob if it can't locate a suitable display ROM. While this may be removed longer term, I think it's a reasonable compromise in order to maintain bisectability of the QEMU tree at the moment.

Based upon this thread, my preferred method would be this:

1) Get Anthony to update the OpenBIOS git repository on git.qemu.org

2) Update the existing OpenBIOS images for all architectures on my
   github account and send a pull request

3) Rework the patch based upon yours/Andreas' suggestions and resubmit
   to the qemu-devel list, including the new TCX FCode ROM

4) Get TCX driver patch applied

Any future updates to OpenBIOS will also update the TCX ROM image, although I'm fairly sure that changes in the ROM aren't likely to occur often if at all. Does that sound reasonable to everyone?


ATB,

Mark.



reply via email to

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