Re: [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.

selecting a sparc framebuffer from command line

[Blue Swirl]

On Thu, Mar 28, 2013 at 11:46 AM, Mark Cave-Ayland
 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.