From: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
To: The OpenBIOS Mailinglist <openbios@openbios.org>
Cc: Blue Swirl <blauwirbel@gmail.com>, Bob Breuer <breuerr@mc.net>,
qemu-devel <qemu-devel@nongnu.org>,
Artyom Tarasenko <atar4qemu@gmail.com>,
Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [Qemu-devel] [OpenBIOS] selecting a sparc framebuffer from command line
Date: Thu, 28 Mar 2013 11:46:02 +0000 [thread overview]
Message-ID: <51542D7A.3060201@ilande.co.uk> (raw)
In-Reply-To: <CACXAS8ATLK-2s2jc6D5Jh=iC_VpPW24qH8a23AFWH5CwgTA07Q@mail.gmail.com>
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.
next prev parent reply other threads:[~2013-03-28 11:43 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-26 11:13 [Qemu-devel] selecting a sparc framebuffer from command line Artyom Tarasenko
2013-03-26 15:08 ` Bob Breuer
2013-03-26 17:24 ` Artyom Tarasenko
2013-03-27 14:54 ` Bob Breuer
2013-03-27 16:43 ` Artyom Tarasenko
2013-03-28 11:46 ` Mark Cave-Ayland [this message]
2013-03-30 13:18 ` [Qemu-devel] [OpenBIOS] " Blue Swirl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51542D7A.3060201@ilande.co.uk \
--to=mark.cave-ayland@ilande.co.uk \
--cc=atar4qemu@gmail.com \
--cc=blauwirbel@gmail.com \
--cc=breuerr@mc.net \
--cc=kraxel@redhat.com \
--cc=openbios@openbios.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.