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: Wed, 21 Aug 2013 17:29:51 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12

On 21/08/13 16:34, Peter Maydell wrote:

Unfortunately the OpenBIOS repository is still based in SVN :(  There is a
git-svn mirror on git.qemu.org, but currently it needs to be manually
updated and so is generally not particularly helpful. For the 1.6 release I
got Anthony to manually update the repository on git.qemu.org so that the
git submodule reference was updated as part of the pull request.

The main reason for not updating the git submodule in this particular commit
is because this is actually a precursor to another larger sun4m framebuffer
patch, and once both these patches are hopefully accepted then my plan is to
send a single pull request to update all 3 of the OpenBIOS images at the
same time rather than to split architectures across different OpenBIOS
versions.

In that case we should defer adding this fcode rom blob until then.
I really don't like the idea of having random binary blobs in our git
repo (and thus in our release tarballs) which aren't tied exactly to
the sources you need to rebuild them.

(It's the pain of managing this which is why I don't like binary blobs
at all, in fact. But they're a fact of life given that mostly we don't have
easy cross-compilation setups  :-( )

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.


ATB,

Mark.



reply via email to

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