From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33169) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VCBJ6-0003NW-Jy for qemu-devel@nongnu.org; Wed, 21 Aug 2013 12:30:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VCBJ0-0007Bm-Lh for qemu-devel@nongnu.org; Wed, 21 Aug 2013 12:30:52 -0400 Received: from p15195424.pureserver.info ([82.165.34.74]:57507) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VCBJ0-0007Ba-5U for qemu-devel@nongnu.org; Wed, 21 Aug 2013 12:30:46 -0400 Message-ID: <5214EAFF.3030306@ilande.co.uk> Date: Wed, 21 Aug 2013 17:29:51 +0100 From: Mark Cave-Ayland MIME-Version: 1.0 References: <1377037501-18498-1-git-send-email-mark.cave-ayland@ilande.co.uk> <5214D242.5010307@ilande.co.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] sun4m: Add FCode ROM for TCX framebuffer List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Blue Swirl , Bob Breuer , QEMU Developers , Artyom Tarasenko 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.