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

[Artyom Tarasenko]

On Wed, Mar 27, 2013 at 3:54 PM, Bob Breuer <[e-mail]> wrote:
> On 3/26/2013 12:24 PM, Artyom Tarasenko wrote:
> > On Tue, Mar 26, 2013 at 4:08 PM, Bob Breuer <[e-mail]> 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