[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 at 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.