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: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH] sun4m: Add FCode ROM for TCX framebuffer
Date: Wed, 21 Aug 2013 18:06:13 +0100

On 21 August 2013 17:29, Mark Cave-Ayland <address@hidden> wrote:
> 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.

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].

-- PMM



reply via email to

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