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

[Andreas Färber]

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.

>>>> --- 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.

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?

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.

Cheers,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg