On Mon, 2014-05-19 at 11:20 -0400, Kevin O'Connor wrote:
On Mon, May 19, 2014 at 02:27:38PM +0100, David Woodhouse wrote:
On Fri, 2013-11-29 at 12:44 -0500, Kevin O'Connor wrote:
Do you need debug output from 16bit mode or 32bit segmented mode? The post and boot phases are all 32bit code so typical boot time debugging shouldn't be impacted. Gerd's cbmem debugging code uses this approach.
I don't need debug output. But an INT 10h implementation like sgabios¹ would be really useful on Quark, because there's normally no real VGA output (unless you can connect mini-PCI one, which is what I've done so far).
Yes, a serial console using mmio serial ports would be a good reason to integrate sgabios functionality into seabios.
A couple of months back I looked through the sgabios assembler. It looks mostly straight-forward. The only thing that was marginally complex was its ability to keep a cache of background attributes.
However, I note that sgabios already talks about having support for SMM traps to talk to an EFI console, so perhaps that's the way forward.
I wasn't aware of that. Do you have a link?
https://code.google.com/p/sgabios/source/browse/trunk/design.txt#219
"Optionally the serial port input/output can be replaced with a SMI trigger that calls into an EFI BIOS in order to tie into its own console input and output routines rather than directly hitting the serial port. In this particular case it's assumed that all logging is handled in the EFI module that will be called. BIOS int 15h, ax = 0d042h is used to trigger SMI. The parameters passed will need to be changed to be specific to the EFI or SMI handler put in place. In the example in SMBIOS, for output, ebx = 0xf00d0000 | (char << 8), and for input, ebx = 0xfeed0000, with the character, if any, returned in the eax register with ZF set and eax=0 if no character was available."
This appears to be a lie. There's nothing but a FIXME in the code (line 849 on the send_byte function).
But an sgabios implementation is going to need *memory* in the A segment, and play tricks to spot when the application/OS has written there and output the appropriate changes to the serial port. So I'm not sure it's stunningly useful to do so.
sgabios doesn't do anything like that today. Most apps that anyone cares about (ie, modern bootloaders) are well behaving - they output their vga text using the int 10h bios interrupts. Sgabios hooks these interrupts to provide service.
In my tests, the only thing I've found which does direct text writes to the 0xa0000-0xc0000 framebuffer are really old dos programs. Even freedos uses the standard bios interface.
Hm, OK. Again I got that from sgabios's design.txt:
Known Bugs ---------- With some versions of DOS, only the last character of every line is displayed once dos boots since DOS will use direct access to the VGA framebuffer until the end of line is reached, at which point it will start using int 10h. Dual cursor tracking might fix this issue by maintaining positions for dos that look like the end of line and another for internal use to know where to output next.