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

[Artyom Tarasenko]

On Wed, Mar 27, 2013 at 3:54 PM, Bob Breuer <address@hidden> wrote:
> On 3/26/2013 12:24 PM, Artyom Tarasenko wrote:
>> On Tue, Mar 26, 2013 at 4:08 PM, Bob Breuer <address@hidden> 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?

Sounds reasonable to me, but
- afaik the current TCX implementation is written in C, no Forth. So
maybe it's easier to keep the current implementation in OpenBIOS and
just add some kind of auto-detection.
- I'm not a graphic guy. :) I run qemu -nographic whenever possible.
So I'd wait till someone from the graphic side comments on it.

Blue? Mark?

-- 
Regards,
Artyom Tarasenko

linux/sparc and solaris/sparc under qemu blog:
http://tyom.blogspot.com/search/label/qemu