As far as I know, to interface with the VGA hardware, all you'd need is * Physical memory access capabilities that allow your driver thread access to video memory and perhaps also the video bios
* I/O access capabilities that will let you access the VGA's I/O ports (0x3B0 through 0x3DF if I remember correctly). Beyond that, just read the VGA specs so you know how to actually interface with the hardware itself. From seL4's perspective you just need to be sure your driver has the proper capabilities to do so. On Tue, Aug 15, 2017 at 12:11 PM, Michal Podhradsky <[email protected]> wrote: > 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/b >> lob/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_l >> ibs/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 > >
_______________________________________________ Devel mailing list [email protected] https://sel4.systems/lists/listinfo/devel
