Re: [Qemu-devel] qemu Makefile.target vl.h hw/cuda.c hw/grackle_...

[Blue Swirl]

On 11/2/07, J. Mayer <address@hidden> wrote:
>
> On Thu, 2007-11-01 at 23:13 +0100, J. Mayer wrote:
> > On Thu, 2007-11-01 at 21:53 +0200, Blue Swirl wrote:
> > > On 11/1/07, Blue Swirl <address@hidden> wrote:
> > > > On 10/29/07, Jocelyn Mayer <address@hidden> wrote:
> > > > > CVSROOT:        /sources/qemu
> > > > > Module name:    qemu
> > > > > Changes by:     Jocelyn Mayer <j_mayer> 07/10/28 23:42:18
> > > > >
> > > > > Modified files:
> > > > >         .              : Makefile.target vl.h
> > > > >         hw             : cuda.c grackle_pci.c heathrow_pic.c ppc.c
> > > > >                          ppc_chrp.c ppc_prep.c
> > > > > Added files:
> > > > >         hw             : mac_dbdma.c mac_nvram.c macio.c ppc_mac.h
> > > > >                          ppc_oldworld.c
> > > > >
> > > > > Log message:
> > > > >         * sort the PowerPC target object files
> > > > >         * make PowerPC NVRAM accessors generic to be able to use a 
> > > > > MacIO NVRAM
> > > > >           instead of the M48T59 one
> > > > >         * split PowerMac targets code:
> > > > >          - move all PowerMac related definitions and prototypes into 
> > > > > hw/ppc_mac.h
> > > > >          - add hw/mac_dbdma.c, hw/mac_nvram.c and macio.c
> > > > >            which implements shared PowerMac devices
> > > > >          - define the g3bw machine in a new hw/ppc_oldworld.c file
> > > > >         * Fix the g3bw target:
> > > > >          - fix the Grackle host PCI device
> > > > >          - connect the Heathrow PIC to the PowerPC 6xx bus pins
> > > > >
> > > > > CVSWeb URLs:
> > > > > http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target?cvsroot=qemu&r1=1.212&r2=1.213
> > > > > http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemu&r1=1.280&r2=1.281
> > > > > http://cvs.savannah.gnu.org/viewcvs/qemu/hw/cuda.c?cvsroot=qemu&r1=1.16&r2=1.17
> > > > > http://cvs.savannah.gnu.org/viewcvs/qemu/hw/grackle_pci.c?cvsroot=qemu&r1=1.6&r2=1.7
> > > > > http://cvs.savannah.gnu.org/viewcvs/qemu/hw/heathrow_pic.c?cvsroot=qemu&r1=1.5&r2=1.6
> > > > > http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc.c?cvsroot=qemu&r1=1.34&r2=1.35
> > > > > http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc_chrp.c?cvsroot=qemu&r1=1.44&r2=1.45
> > > > > http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc_prep.c?cvsroot=qemu&r1=1.47&r2=1.48
> > > > > http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mac_dbdma.c?cvsroot=qemu&rev=1.1
> > > > > http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mac_nvram.c?cvsroot=qemu&rev=1.1
> > > > > http://cvs.savannah.gnu.org/viewcvs/qemu/hw/macio.c?cvsroot=qemu&rev=1.1
> > > > > http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc_mac.h?cvsroot=qemu&rev=1.1
> > > > > http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc_oldworld.c?cvsroot=qemu&rev=1.1
> > > >
> > > > You broke sparc64-softmmu build with this patch.
> >
> > I am missing something ? I rebuilt all available targets before
> > commiting... but I now see sparc64-softmmu seems not to be in the
> > available targets, which could explain I cannot check if it compiles or
> > not...  As it been removed by mistake ?
> >
> > > I think the best solution to fix this is to put the nvram helpers to
> > > m48t59.h as inline functions  instead of duplicating the code in
> > > several places.
> >
> > You mean the NVRAM_set / get_xxx ? I was to remove the definitions from
> > vl.h, I have to say, because those are supposed to be PowerPC (in fact
> > OpenHack'Ware) related hacks.
> > Those functions will never go in m48t59.h as they are not related with
> > m48t59. Apple machine don't have such a device (even if Qemu pretend it
> > has, this is to be removed in the days to come) but need those functions
> > to pass arguments to the firmware. What I needed to do (and that what I
> > did commit) is make those routines independant from m48t59 so I can
> > remove this device from ppc_chrp.c and ppc_oldworld.c and use the real
> > Mac nvram instead (but ppc_prep.c still uses m48t59...).

I see. Should sun4m use these functions too? On the other hand, there
is no need to be too independent on Sparc, because I think all Sun4u
machines use m48t59 and sun4m machines have either m48t08 or older
m48t02 (not supported yet). So if you prefer, sun4u could use the same
approach as sun4m and not use these functions?

> > Whatever, I'll try to fix the sparc64 case as I broke it (if I found the
> > code ;-) ).
>
> This patch seems to fix the Sparc64 compilation. I cannot test that it
> works, but the PowerPC counterparts is OK. I also fixed a bug in the
> NVRAM_set_string function.
> Tell me what you feel about it, if you're OK, I'll commit it.
> This code could be shared, but it should be independant of the NVRAM
> model implementation. As I would not like to put this code in vl.c,
> maybe we need a c file in the hw subdirectory to put those kind of
> functions, which are part of the hw library but hardware implementation
> independant...

Works fine here, thanks.