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