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

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

[Artyom Tarasenko]

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?

-- 
Regards,
Artyom Tarasenko

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

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

[Bob Breuer]

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.

Bob

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

[Artyom Tarasenko]

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?
Would -device cg3 add the FCode ROM? Or do we need another -device for that?


-- 
Regards,
Artyom Tarasenko

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

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

[Bob Breuer]

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

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

[Artyom Tarasenko]

On Wed, Mar 27, 2013 at 3:54 PM, Bob Breuer <breuerr@mc.net> wrote:
> 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?

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

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

[Mark Cave-Ayland]

On 27/03/13 16:43, Artyom Tarasenko wrote:

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

I'm actually slightly ahead of you here. Take a look at my OpenBIOS 
console patchset I posted a couple of weeks ago, and in particular this 
patch: 
http://www.openfirmware.info/pipermail/openbios/2013-March/007491.html.

Both tcx.fs and vga.fs were deliberately designed so that with minimum 
effort they can be converted to an Fcode payload suitable for a display 
device, similar to as mentioned here: 
http://docs.oracle.com/cd/E19683-01/806-1379-10/displydv.html.

The minor downside is that we'd have to specify fcode-utils as a 
dependency for building the resulting Fcode images, but that's not 
insurmountable.

So yes, if QEMU are happy to host the FCode binaries then it would be 
great if we could specify the SPARC cg3 framebuffer using something like:

-device cg3,rom=QEMU,cg3.bin

Obviously the in-built QEMU,cg3.bin would be the default file if rom= 
was not specified, but it means that people booting using real SUN OBP 
images can point to a real SUNW Fcode display ROM and use that if 
desired with the same patch.


ATB,

Mark.

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

[Blue Swirl]

On Thu, Mar 28, 2013 at 11:46 AM, Mark Cave-Ayland
<mark.cave-ayland@ilande.co.uk> wrote:
>
> On 27/03/13 16:43, Artyom Tarasenko wrote:
>
>>> 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?
>
>
> I'm actually slightly ahead of you here. Take a look at my OpenBIOS console patchset I posted a couple of weeks ago, and in particular this patch: http://www.openfirmware.info/pipermail/openbios/2013-March/007491.html.
>
> Both tcx.fs and vga.fs were deliberately designed so that with minimum effort they can be converted to an Fcode payload suitable for a display device, similar to as mentioned here: http://docs.oracle.com/cd/E19683-01/806-1379-10/displydv.html.
>
> The minor downside is that we'd have to specify fcode-utils as a dependency for building the resulting Fcode images, but that's not insurmountable.
>
> So yes, if QEMU are happy to host the FCode binaries then it would be great if we could specify the SPARC cg3 framebuffer using something like:
>
> -device cg3,rom=QEMU,cg3.bin

As the first step, we could start shipping the FCode blobs like we do
for OpenBIOS now. Later FCode ROM build can be integrated to other ROM
builds.

>
> Obviously the in-built QEMU,cg3.bin would be the default file if rom= was not specified, but it means that people booting using real SUN OBP images can point to a real SUNW Fcode display ROM and use that if desired with the same patch.
>
>
> ATB,
>
> Mark.