Hello, I tested the code on a real hardware, and it ends at the same point - no output after "Starting node #0..."
Can you replicate the results? M On Tue, Aug 8, 2017 at 2:09 PM, Michal Podhradsky <[email protected]> wrote: > 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 <[email protected]> > wrote: > >> On 8/2/17, [email protected] <[email protected]> >> 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 >> [email protected] >> https://sel4.systems/lists/listinfo/devel >> > >
_______________________________________________ Devel mailing list [email protected] https://sel4.systems/lists/listinfo/devel
