Hey Michal,
Sorry I'm so late in getting back to you:
So the message you see there is printed by the kernel in smp_sys.c (https://github.com/seL4/seL4/blob/master/src/arch/x86/kernel/smp_sys.c#L66), and this function is called by (https://github.com/seL4/seL4/blob/master/src/arch/x86/kernel/boot_sys.c#L610).
Just beneath that, there's another printf() that says, "Booting all finished, dropped to user space\n". Since this message isn't printed, it appears that the kernel is freezing sometime between `start_boot_aps`, and that final printf. If we look at the line
here (https://github.com/seL4/seL4/blob/master/src/arch/x86/kernel/smp_sys.c#L76) it appears the kernel uses a loop with no timeout when waiting for AP cpus to wake up from their dormant state. It seems that the CPU the kernel is trying to boot isn't responding,
or isn't entering the kernel.
I'd need more information about your configuration process, the repository you're using (seL4test? seL4Bench? Some custom infrastructure?), and maybe a link to a github repository where I can view the diff of your changes to the kernelso I can try your
modified kernel myself.
Would you be able to provide me with any of these things?
On 8/2/17, Adrian.Danis@data61.csiro.au <Adrian.Danis@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