From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47304) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YUiOG-0005Yn-3r for qemu-devel@nongnu.org; Sun, 08 Mar 2015 17:05:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YUiOC-0007EI-T3 for qemu-devel@nongnu.org; Sun, 08 Mar 2015 17:05:36 -0400 Received: from cantor2.suse.de ([195.135.220.15]:43520 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YUiOC-0007EA-ID for qemu-devel@nongnu.org; Sun, 08 Mar 2015 17:05:32 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Alexander Graf In-Reply-To: <54FCB909.7000105@ilande.co.uk> Date: Sun, 8 Mar 2015 17:05:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150304062009.GB8014@kentang.lan> <54FC1E9C.4060401@ilande.co.uk> <54FC2B2E.2030702@ilande.co.uk> <54FCB58D.30702@suse.de> <54FCB909.7000105@ilande.co.uk> Subject: Re: [Qemu-devel] [PULL] qemu-sparc update List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mark Cave-Ayland Cc: Peter Maydell , QEMU Developers > Am 08.03.2015 um 17:03 schrieb Mark Cave-Ayland : >=20 >> On 08/03/15 20:48, Alexander Graf wrote: >>=20 >>> On 08.03.15 06:57, Mark Cave-Ayland wrote: >>>> On 08/03/15 10:31, Peter Maydell wrote: >>>>=20 >>>> On 8 March 2015 at 19:04, Mark Cave-Ayland >>>> wrote: >>>>> On 08/03/15 09:47, Peter Maydell wrote: >>>>>=20 >>>>>> On 4 March 2015 at 15:20, Mark Cave-Ayland >>>>>> wrote: >>>>>>> Hi Peter, >>>>>>>=20 >>>>>>> Here are the updates from my qemu-sparc tree. Please pull. >>>>>>=20 >>>>>>> MAINTAINERS | 3 + >>>>>>> hw/ppc/ppc.c | 161 -------------------- >>>>>>> hw/ppc/ppc405_boards.c | 2 +- >>>>>>> hw/ppc/prep.c | 163 ++++++++++++++++++-- >>>>>>> hw/sparc/sun4m.c | 10 +- >>>>>>> hw/sparc64/sun4u.c | 20 ++- >>>>>>> hw/timer/m48t59.c | 359 ++++++++++++++++++++++++++++++++---= ---------- >>>>>>> include/hw/timer/m48t59.h | 61 ++++---- >>>>>>> pc-bios/openbios-sparc64 | Bin 1616768 -> 1616768 bytes >>>>>>> qemu-doc.texi | 7 +- >>>>>>=20 >>>>>> Shouldn't there be an update to roms/openbios to go with the >>>>>> pc-bios/openbios-sparc64 binary blob update? >>>>>=20 >>>>> I haven't committed the sun4u MMIO patches to OpenBIOS yet because >>>>> without the corresponding QEMU parts OpenBIOS SVN trunk breaks (and th= e >>>>> QEMU parts have taken many weeks to get right which is a long time to >>>>> leave things broken). Hence I've gone for just updating the binary whi= ch >>>>> is SVN trunk plus the NVRAM MMIO accessor changes in order to preserve= >>>>> bisection. >>>>>=20 >>>>> As soon as this is applied, I can apply my remaining OpenBIOS patches >>>>> and then send a separate qemu-openbios pull request which will bring >>>>> everything up to date. >>>>=20 >>>> Hmm. I'm not a huge fan of having the binary in git and the submodule >>>> reference be out of step... >>>=20 >>> Alternatively if you have shell access to git.qemu.org then I can commit= >>> just the MMIO accessor changes to SVN trunk now and then with a manual >>> update to the OpenBIOS git mirror I can re-send the signed pull request >>> with updated binaries? I've deliberately held off applying patches to >>> OpenBIOS SVN trunk in case this was the preferred method as I'm keen to >>> be able to bisect down to this particular change on SPARC64. >>=20 >> Is there any way to make the change backwards compatible, so that we >> don't need to sync versions? >=20 > Not without refactoring to enable more than one type of NVRAM accessor > in OpenBIOS, plus a fw_cfg variable to enable the switch between the two > for SPARC64. >=20 > Given that SPARC64 is still more experimental than stable plus newer > versions of OpenBIOS aren't guaranteed to work with older versions of > QEMU anyhow, I just can't see that this is worth all the extra effort > for the sake of a follow-up pull request within a day or so that will > bring everything up to date whilst still allowing a proper bisection. >=20 > Now if Peter is still keen to keep the git submodule reference intact > then I'm happy to commit just the MMIO accessor changes to OpenBIOS SVN > trunk as long as we can minimise the time between the QEMU changes and > the OpenBIOS changes. Yes, I think that's a reasonable way forward. Maybe add a fw_cfg and assert(= ) on it nevertheless, so people don't fall into pits ;). Alex