From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40774) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VDDXr-00054t-HZ for qemu-devel@nongnu.org; Sat, 24 Aug 2013 09:06:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VDDXl-0002Pl-OO for qemu-devel@nongnu.org; Sat, 24 Aug 2013 09:06:23 -0400 Received: from p15195424.pureserver.info ([82.165.34.74]:56153) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VDDXl-0002Of-Eu for qemu-devel@nongnu.org; Sat, 24 Aug 2013 09:06:17 -0400 Message-ID: <5218AF89.4020205@ilande.co.uk> Date: Sat, 24 Aug 2013 14:05:13 +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> <5214EAFF.3030306@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 , Anthony Liguori , Bob Breuer , QEMU Developers , Artyom Tarasenko 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.