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

[Mark Cave-Ayland]

On 24/08/13 18:46, Andreas Färber wrote:

> Am 21.08.2013 20:52, schrieb 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 :)
>
> On second thoughts, more important than Makefile changes (which would
> depend on the OpenBIOS gitmodule update) would be to document textually
> in the README wherever the openbios-sparc origin is tracked that this
> file comes from OpenBIOS rXXXX, too.

Sure - we already do this for OpenBIOS updates anyhow, so all that is 
required here is to add the FCode ROM to the list of filenames given in 
the README.

Given that the fallback seems to be working fine, I'll send Anthony a 
pull request to update the main OpenBIOS images so at least any 
subsequent patches can be rebased from that.

(cut)

> > > 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.
>
> Seems I mixed that up with CBus then. ;)
>
> So, TCX is a SysBusDevice. How do I recognize which devices are SBus
> devices? Do you have a list of files/types or some recipe to find out?

I don't have any official documentation, but it is possible to see where 
each device belongs by launching qemu-system-sparc with each machine 
type and issuing "show-devs". Anything under /iommu/sbus is located on 
the SBus, and using drivers/sbus.c in the OpenBIOS source it's possible 
to map the SBus physical slot number to its equivalent sysbus address.

> With QOM it would be easily possible to derive a TYPE_SBUS_DEVICE from
> TYPE_SYS_BUS_DEVICE and have TYPE_TCX be derived from it. Then
> SBusDeviceClass could supply a rom_file field, which generic SBus code
> loads in its realizefn while still being able to use sysbus_*() API.

I suspect that the hard bit is working out the slot<->address mappings 
for all of the devices above for each machine; once that is done then I 
think you should be able to model SBus using just a MemoryRegion and 
some generic FCode ROM loader code.


HTH,

Mark.