Re: [Qemu-devel] selecting a sparc framebuffer from command line

[Bob Breuer <breuerr@mc.net>]

On 3/26/2013 12:24 PM, Artyom Tarasenko wrote:
> On Tue, Mar 26, 2013 at 4:08 PM, Bob Breuer <breuerr@mc.net> wrote:
>> On 3/26/2013 6:13 AM, Artyom Tarasenko wrote:
>>> It looks like we will have more framebuffers beside TCX in the near future.
>>> One way to use them would be to make new machines combining a base
>>> machine name with a framebuffer name, like ss5tcx and ss5cg3, but I
>>> guess this would produce too many machines if we have more than 2
>>> framebuffers.
>>>
>>> Should the "-vga" option be (mis)used for selecting a framebuffer?
>>> They are not called "VGA" in the wild, but maybe the name VGA is
>>> obvious enough for a modern user? After all there is already a "-hda"
>>> option in the SPARCStation-5 emulation command line, although in the
>>> non-emulating world no one calls scsi disk "hda".
>>>
>>> Or should an architecture-specific option, like -framebuffer be added?
>>>
>>
>> I would like to see -device used.  With a better sbus framework, adding
>> multiple video devices on sparc32 should be really easy to do.
>>
>> I just looked at how "-device cirrus-vga" works.  To get -device to
>> override the default video, we need to add minimal support into vl.c to
>> recognize each video device and handle the default_vga flag.  Then
>> sparc32 could limit itself to handling either VGA_NONE or VGA_STD when
>> it adds the default video.
> 
> Oh, that's even better!
> And then how would the OpenBIOS find out what framebuffer to use?

For a single display device, can it do just like OBP?  Run all FCode
roms, then find the display device in the device tree.

For multiple devices, how to select the primary?  Possibly just use the
first one found.  OBP provides some control over this with
sbus-probe-list.  As a parallel question, for a PC with 2 PCI video
cards, which one gets used as the BIOS display?  Just trying
"qemu-system-i386 -device cirrus-vga -device cirrus-vga" gives an error
about RAMBlock already registered.

> Would -device cg3 add the FCode ROM? Or do we need another -device for that?

The FCode ROM should be integrated with the device, similar to a PCI
device with an expansion rom.  The SBUS specification defines a rom to
be at offset 0 of the slot.  Probably setup a memory region container
for each sbus slot so that the device addresses are relative to the slot
base and isolated from the system address space.

For the existing TCX, looks like it also has space for a rom at offset
0.  See ftp://ftp.rodents-montreal.org/pub/mouse/docs/Sun/S24/memory-map

So as a stepping stone, should we create an FCode ROM for TCX?

Bob