Hi Adrian, Kofi, I followed your advice, and just as a proof of concept I redefined putConsoleChar from here: https://github.com/seL4/seL4/blob/master/src/plat/pc99/machine/io.c#L38 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 https://github.com/seL4/util_libs/blob/master/libplatsupport/src/plat/pc99/ega.c 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: https://drive.google.com/file/d/0B8h93vAE2c4ibmRKQkdZU3EtcUk/view?usp=sharing Any ideas what am I missing? Regards M On Wed, Aug 2, 2017 at 4:18 AM, Andrew Warkentin <andreww...@gmail.com> wrote: > 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 Devel@sel4.systems https://sel4.systems/lists/listinfo/devel
