Re: [Qemu-devel] [PULL] qemu-sparc update

[Alexander Graf]

> Am 08.03.2015 um 17:03 schrieb Mark Cave-Ayland <address@hidden>:
> 
>> On 08/03/15 20:48, Alexander Graf wrote:
>> 
>>> On 08.03.15 06:57, Mark Cave-Ayland wrote:
>>>> On 08/03/15 10:31, Peter Maydell wrote:
>>>> 
>>>> On 8 March 2015 at 19:04, Mark Cave-Ayland
>>>> <address@hidden> wrote:
>>>>> On 08/03/15 09:47, Peter Maydell wrote:
>>>>> 
>>>>>> On 4 March 2015 at 15:20, Mark Cave-Ayland
>>>>>> <address@hidden> wrote:
>>>>>>> Hi Peter,
>>>>>>> 
>>>>>>> Here are the updates from my qemu-sparc tree. Please pull.
>>>>>> 
>>>>>>> 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 +-
>>>>>> 
>>>>>> Shouldn't there be an update to roms/openbios to go with the
>>>>>> pc-bios/openbios-sparc64 binary blob update?
>>>>> 
>>>>> I haven't committed the sun4u MMIO patches to OpenBIOS yet because
>>>>> without the corresponding QEMU parts OpenBIOS SVN trunk breaks (and the
>>>>> 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 which
>>>>> is SVN trunk plus the NVRAM MMIO accessor changes in order to preserve
>>>>> bisection.
>>>>> 
>>>>> 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.
>>>> 
>>>> Hmm. I'm not a huge fan of having the binary in git and the submodule
>>>> reference be out of step...
>>> 
>>> 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.
>> 
>> Is there any way to make the change backwards compatible, so that we
>> don't need to sync versions?
> 
> 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.
> 
> 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.
> 
> 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