Re: [Qemu-devel] [PATCH] sun4m: Add FCode ROM for TCX framebuffer

[Mark Cave-Ayland]

On 21/08/13 18:54, Andreas Färber wrote:

> > Shouldn't this blob come in the same patch as an update to some
> > git module, so that we keep track of the sources used to build
> > the blob?
>
> I concur. Independent of how to order the .gitmodules update, this patch
> is missing Makefile support to actually copy the new binary from
> OpenBIOS build to the location it is being added to as binary here.

Okay that's something else to add to the v2 :)

> > > --- a/hw/sparc/sun4m.c
> > > +++ b/hw/sparc/sun4m.c
> >
> > > +    fcode_filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, TCX_ROM_FILE);
> > > +    if (fcode_filename) {
> > > +        ret = load_image_targphys(fcode_filename, addr, FCODE_MAX_ROM_SIZE);
> > > +    }
> >
> > This looks like the wrong place for this -- surely the tcx device
> > should load its own fcode blob, not defer to the board code
> > to do it?
> >
> > (For that matter, presumably if this is an SBus device then
> > the offsets of the ROM, DAC, etc etc are all fixed relative to
> > the base address of the SBus slot, and the tcx device itself
> > should be creating a container with all its component parts
> > at the right offset. But that's not an issue for this patch.)
>
> I vaguely recall Mark telling me that SBus is not really
> qdev'ified/QOM'ified, right?
>
> PCI devices have support for ROM files, too, and I think they just set
> the file name and generic PCI code takes care of the actual loading.
> Maybe we would want to do the same for SBus? We're not in a rush yet so
> getting this designed right probably only takes a week or so...

Currently there is no concept of an SBus in QEMU, since the bus address 
lines are effectively mapped to the processor bus (and so the standard 
sysbus calls work just fine). I know this isn't the complete truth with 
respect to real hardware, though I suspect Blue/Bob could expand further 
on this if required.


ATB,

Mark.