Hi Adrian, Kofi,

I followed your advice, and just as a proof of concept I redefined
putConsoleChar from here:
On top of printing on serial port, I added a line with
text_ega_putchar((int) a); - so now the character is printed both on serial
out and VGA screen.

I added the scrolling etc functions from
to take care of line wraps and control characters (\n, \t, etc).
Then I compiled the basic keyboard camkes example:
https://github.com/seL4/camkes/tree/master/apps/keyboard and I run the
program in qemu with -vga -std option.

I can see the kernel booting up on the screen as well as the serial out,
but as soon as sel4 drops into userspace ("Starting node #0 with APIC ID
0") , it stops outputting anything (user program not running?);

The screenshot is here:

Any ideas what am I missing?


On Wed, Aug 2, 2017 at 4:18 AM, Andrew Warkentin <andreww...@gmail.com>

> On 8/2/17, adrian.da...@data61.csiro.au <adrian.da...@data61.csiro.au>
> wrote:
> > Assuming you are talking about text mode VGA then having the kernel
> render
> > to such a buffer is not particularly difficult. Instead of the 0xB8000
> > address though I would consider using the supposed multiboot video mode,
> and
> > perhaps falling back to the buffer at 0xB8000 if no multiboot video mode
> > provided, that would provide the most reliability. You will need to
> >  * Emulate the vt100 codes in the seL4 messages, or disable colored
> output
> > (which I believe is all we use control codes for)
> >  * Handle end of line detection and scrolling
> > Whilst not using multiboot an old slightly bitrotted user level example
> of
> > what you are proposing is
> > https://github.com/seL4/util_libs/blob/master/libplatsupport
> /src/plat/pc99/ega.c
> >
> > If you want to use a linear graphics mode though (and you don't want to
> > change display modes later on) then obviously it's a little more
> complicated
> > as you'll have to do font rendering. Not that rendering the equivalent
> of a
> > monospaced text mode onto a linear graphics mode is particularly
> difficult
> > though. Note that we currently have not written graphics support beyond
> the
> > multiboot graphics mode that the kernel can request from its loader, in
> > particular we do not have any code that would allow you to change the
> screen
> > mode later on at user level.
> >
> Like I said before I am planning to exclusively use a linear
> framebuffer rather than hardware text mode (which is a relic from an
> era when hardware wasn't powerful enough to do software text modes
> with reasonable performance, and I believe it's not supported at all
> under UEFI), and I'm planning to have it just emulate a dumb terminal
> (i.e. no escape codes; I don't want to bloat the kernel with a VT100
> emulator just for displaying early boot messages). I was thinking of
> using the framebuffer console code from coreboot's libpayload (which
> only emulates a dumb terminal and is very lightweight).
> > Asking the kernel to stop using its debug output device, to allow the
> user
> > to start using wholly for its own purposes, is something that could be
> > useful to add. Probably would have to be another 'debug' syscall, and
> could
> > function as a dynamic enabling/disabling of kernel printing.
> >
> I was going to have the kernel automatically disable the early console
> immediately before it loads the root server, so there would be no need
> for an API (at least not under UX/RT). UX/RT's root server will
> contain its own early console emulator (possibly also based on that of
> libpayload) that will provide a minimal subset of a Unix terminal
> device to programs run during early boot (initializing the console
> emulator will be the first thing that the root server does). A
> full-featured DRM/DRI graphics driver and console emulator will take
> over before the root volume is mounted.
> _______________________________________________
> Devel mailing list
> Devel@sel4.systems
> https://sel4.systems/lists/listinfo/devel
Devel mailing list

Reply via email to