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
