qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions


From: Rob Landley
Subject: Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
Date: Sat, 20 Aug 2011 17:16:23 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11

On 08/18/2011 03:51 PM, Laurent Vivier wrote:
> Le jeudi 18 août 2011 à 21:13 +0100, Natalia Portillo a écrit :
>> Hi Laurent,
>>
>> El 18/08/2011, a las 20:57, Laurent Vivier escribió:
>>
>>> Le jeudi 18 août 2011 à 20:42 +0100, Natalia Portillo a écrit :
>>>> Hi Laurent,
>>>
>>> Hi Natalia,
>>>
>>>> El 18/08/2011, a las 15:02, Laurent Vivier escribió:
>>>>
>>>>>
>>>>>
>>>>>
>>>>> Le 18 août 2011 à 13:12, "François Revol" <address@hidden> a écrit : 
>>>>>
>>>>>> Le -10/01/-28163 20:59, Laurent Vivier a écrit : 
>>>>>>> Le mercredi 17 août 2011 à 17:35 -0500, Anthony Liguori a
>>>>> écrit : 
>>>>>>>> On 08/17/2011 03:46 PM, Bryce Lanham wrote: 
>>>>>>>>> These patches greatly expand Motorola 68k emulation within
>>>>> qemu, and are what I used as a basis for my 
>>>>>>>>> Google Summer of Code project to add NeXT hardware support to
>>>>> QEMU. 
>>>>>>>>
>>>>>>>> Please don't crap flood the list with a series of 100 patches. 
>>>>>>>>
>>>>>>>> Split things into logical chunks such that a series can be
>>>>> reasonably 
>>>>>>>> reviewed and applied. 
>>>>>>>
>>>>>>> And I'm not sure this series of patches is ready for inclusion
>>>>> in qemu 
>>>>>>> mainline as it should break existing m68k emulation... 
>>>>>>>
>>>>>>> Bryce, you should only post your patches, refering to the
>>>>> repository on 
>>>>>>> which they apply, i.e.
>>>>> git://gitorious.org/qemu-m68k/qemu-m68k.git , 
>>>>>>> master branch. 
>>>>>>>
>>>>>>
>>>>>> Btw, are you planning on merging it back someday? 
>>>>>>
>>>>>
>>>>>
>>>>> Yes... when it will work correctly.
>>>>>
>>>>>
>>>>> I have at least, to rework 680x0 FPU part (80bit fpu) to not break
>>>>> the existing one (64bit fpu).
>>>>> I have to check modified instructions don't break existing m68k
>>>>> emulation.
>>>>
>>>>
>>>> Maybe Bryce can help you
>>>
>>> I don't know if he is courageous enough to review and push 111
>>> patches ;-)
>>
>> He worked on emulating an abandoned, strange, difficult to get, and 
>> undocumented hardware, using your 111 patches, and finished it before the 
>> wholy more experienced MESS team.
> 
> The next-cube emulation is really working ?
> 
>> He is! xD
> 
> There is no problem for me, he can do...
> 
>>>>> Currently, I'm trying to port some parts of BasiliskII into Qemu to
>>>>> be able to boot MacOS 7.6.
>>>>
>>>>
>>>> Why are you planning to port a hack instead of making a full machine
>>>> emulation?
>>>
>>> Because I'm lazy and dumb: the work is already done, I like cut'n'paste.
>>
>> Yeah, you said it!
>> The work is already done, we have all the hardware emulation that Basilisk 
>> substitutes for hacks.
> 
> I'm not sure of that... no MMU emulation, no Nubus, no ethernet card, no
> video card, no SWIM, no SCSI, ... useless with a patched ROM.
> 
> You know, nights are not long enough...
> 
>> We only lack the 68k cpu (oh! your patches!!!) and the glue :p
> 
> this part is not working well as well ... gcc cannot compile linux
> kernel, some demos fail in gtk-demo, ...

I got gcc 4.2.1 with binutils 2.17 to compile the m68k Linux kernel
(including 3.0).

This kind of regression testing of each new release on various platforms
is what I've been doing for the ones I've got working for years now.
I'd love to add m68k to it (heck, I've got infrastructure to do nightly
builds from upstream -git of the kernel and uClibc and auto-bisect
breakage that prevented dropbear and strace from building natively under
the result; I admit I haven't put in the effort to follow up on the
result yet).

But all i've been able to say so far is 'I got it to compile", I can't
_run_ it on qemu.  (And my aranym setup keeps bit rotting, and hasn't
got the right kind of console anyway...)

Rob



reply via email to

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