[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] selecting a sparc framebuffer from command line
From: |
Artyom Tarasenko |
Subject: |
Re: [Qemu-devel] selecting a sparc framebuffer from command line |
Date: |
Wed, 27 Mar 2013 17:43:44 +0100 |
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