Hi Brent,
[I Cc-ed this to contact@l4ka.org and l4-hackers. L4Ka reports from other users would be great too.]
I'm curious because I get similar problems to your description when trying to boot the L4KA kernel on a K6-2 chip.
However, in my case the boot process seems to work fine as far as the initial sigma0 task starts, then rmgr in debug mode will print an error message (or a "Hello from RMGR" message depending on the build I use).
Basically, the boot fails before getting into glinux and if rmgr and the kernel are built for debugging they will trap the error and stop. In "runnable" mode, I just get a soft reboot.
I just tried L4Ka on a real pentium box:
CPU: Pentium/P54C (199.43-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x52c Stepping = 12 Features=0x1bf<FPU,VME,DE,PSE,TSC,MSR,MCE,CX8> real memory = 134217728 (131072K bytes)
I was able to boot the provided root_task template, but not glinux (yet). I booted entirely from floppy, since I can't use the hd of this production FreeBSD-box for experiments.
I compiled l4ka for 586 (not 686) with kernel debugger, sigma0, rmgr and the template root_task.
The first thing to do was to disable the call to the kernel debugger on startup in l4-ka/kernel/src/init.c:init()
#if defined CONFIG_DEBUG_KDB_ONSTART enter_kdebug("startup"); #endif
I did this because I wanted to keep the kernel debugger but I didn't found out how to use it to resume booting.
I then had to figure out, that the LINKBASE address in l4-ka/root_task/Makefile had to be changed to a real existing physical address:
< LINKBASE=0x0c200000
LINKBASE=0x07200000
If not, the following error message appears:
RMGR: loading task (fd0)/l4ka/root_task from 0x159000_0x15a6bc to [0xc200000-0xc201504 cannot allocate page at 0xc200000 : owned by 0x89] Return reboots, "k" enters L4 kernel debugger.
Trying to display the memory regions with the kernel debugger was easy. E.g. "d158fb0" shows a dump at address 00159000 which started like this: 00159000: 46 .... <after 46: ELF...> I wished the kdb was documented somewhere, not only in its sources :( The screen handling is also not perfect yet (see above with 'd' command). Dumping c200000 hangs the machine, probably because that address is outside of the physical range.
After fixing LINKBASE, booting with the following menu.lst entry was successful:
title=L4Ka without kernel debugger on start kernel=(fd0)/l4ka/rmgr -sigma0 module=(fd0)/l4ka/x86-kernel.nokdb module=(fd0)/l4ka/sigma0 module=(fd0)/l4ka/root_task.7200000
root_task is just a hello world, followed by an endless loop. This is the contents of the screen then:
----- cut here ---------- interrupt association failed (e0044800 irq: 2) interrupt association failed (e0046000 irq: 8)
sigma0_main: kernel_info_page is at 0x00107000
sigma0: map 4M page at 5800000 to 4040001 sigma0: map 4M page at 5c00000 to 4040001 sigma0: map 4M page at 6000000 to 4040001 sigma0: map 4M page at 6400000 to 4040001 sigma0: map 4M page at 6800000 to 4040001 sigma0: map 4M page at 6c00000 to 4040001 sigma0: map 4M page at 7000000 to 4040001 sigma0: map 4M page at 7400000 to 4040001
RMGR: total RAM size = 130688 KB (reported by bootloader) received 122152 KB RAM from sigma0 204 KB reserved for RMGR RMGR: attached irqs = [<!0> 1 <!2> 3 4 5 6 7 <!8> 9 a b c d e f] RMGR: loading task (fd0)/l4ka/root_task.7200000 to [0x7200000-0x7201504] RMGR: starting task (fd0)/l4ka/root_task.7200000 at entry 0x7200000 via trampoline page code 0x3140.
main: started. <<<-- appears over sigma0_main: ... <<<-- due to missing screen handling. ----- cut here -------------
So far, so good. I then tried to boot glinux with the following menu.lst entry:
title=L4Ka with glinux kernel=(fd0)/l4ka/rmgr -sigma0 module=(fd0)/l4ka/x86-kernel.nokdb module=(fd0)/l4ka/sigma0 module=(fd0)/l4ka/glinux.gz -s
knowing that I don't have any linux root partition on that FreeBSD box. Anyway, I just wanted to see glinux start and no more for now. As you can see from menu.lst, I had to gzip -9 glinux to fit it on one floppy. GRUB should be able to load gzipped modules. Booting this resulted in the following output screen:
----- cut here -------------- sigma0_main: kernel_info_page is at 0x00107000
sigma0: page 200002 requested twice, old=ff, new=4 sigma0: page 200002 requested twice, old=ff, new=4 sigma0: page 200002 requested twice, old=ff, new=4 sigma0: page 200002 requested twice, old=ff, new=4 sigma0: page 200002 requested twice, old=ff, new=4 sigma0: page 200002 requested twice, old=ff, new=4 sigma0: page 200002 requested twice, old=ff, new=4 sigma0: page 200002 requested twice, old=ff, new=4 sigma0: page 200002 requested twice, old=ff, new=4 sigma0: page 200002 requested twice, old=ff, new=4 ----- cut here -------------- The last line being constantly redrawn in an (endless?) loop.
I didn't try anything else, because I was not able to compile Dresden's L4Linux on FreeBSD (I used l4ka.org's glinux binary). At least the root_task seems to work and this is very good for now. Based on root_task, L4 servers can be build, probably with flux' oskit (which compiles w/o problems on FreeBSD too!). The we can start thinking about libmom and porting the Hurd to L4Ka.
I can't resume tests on a real pentium right now, so I'll have to look at bochs sources to add support for 4MB superpages. This will take its time though, since I'm not an x86 expert :-).
Thanks,
-Farid.
Hi Farid,
The first thing to do was to disable the call to the kernel debugger on startup in l4-ka/kernel/src/init.c:init()
#if defined CONFIG_DEBUG_KDB_ONSTART enter_kdebug("startup"); #endif
I did this because I wanted to keep the kernel debugger but I didn't found out how to use it to resume booting.
Try "h" for help - it shows you a list of all kdb commands - isn't that "*nix"-like?
I then had to figure out, that the LINKBASE address in l4-ka/root_task/Makefile had to be changed to a real existing physical address:
< LINKBASE=0x0c200000
LINKBASE=0x07200000
So the ARM-roottask configuration made it into the distribution... :)
I wished the kdb was documented somewhere, not only in its sources :( The screen handling is also not perfect yet (see above with 'd' command).
see above. Furthermore, I added a kdb-doc at http://l4ka.org/docs/kdb.asp.
Dumping c200000 hangs the machine, probably because that address is outside of the physical range.
Yes, that is necessary if you want to have pf handled in the kernel debugger. That way we can force PF-IPCs. When you use kdb we simply assume you know what you do.
So far, so good. I then tried to boot glinux with the following menu.lst entry:
title=L4Ka with glinux kernel=(fd0)/l4ka/rmgr -sigma0 module=(fd0)/l4ka/x86-kernel.nokdb module=(fd0)/l4ka/sigma0 module=(fd0)/l4ka/glinux.gz -s
knowing that I don't have any linux root partition on that FreeBSD box. Anyway, I just wanted to see glinux start and no more for now. As you can see from menu.lst, I had to gzip -9 glinux to fit it on one floppy. GRUB should be able to load gzipped modules. Booting this resulted in the following output screen:
----- cut here -------------- sigma0_main: kernel_info_page is at 0x00107000
sigma0: page 200002 requested twice, old=ff, new=4 sigma0: page 200002 requested twice, old=ff, new=4 sigma0: page 200002 requested twice, old=ff, new=4 sigma0: page 200002 requested twice, old=ff, new=4 sigma0: page 200002 requested twice, old=ff, new=4 sigma0: page 200002 requested twice, old=ff, new=4 sigma0: page 200002 requested twice, old=ff, new=4 sigma0: page 200002 requested twice, old=ff, new=4 sigma0: page 200002 requested twice, old=ff, new=4 sigma0: page 200002 requested twice, old=ff, new=4 ----- cut here -------------- The last line being constantly redrawn in an (endless?) loop.
The Linux's module overlaps with needed physical ram. That overlapping can be avoided by forcing grub to load the modules at a different address (a hack which made it into Dresden's GRUB distribution or use our GRUB-disk). I added an x86-FAQ-page with a description: http://l4ka.org/faq/x86.asp
I can't resume tests on a real pentium right now, so I'll have to look at bochs sources to add support for 4MB superpages. This will take its time though, since I'm not an x86 expert :-).
Good luck and thanks for the extensive feedback.
Volkmar
Hi Volkmar,
I did this because I wanted to keep the kernel debugger but I didn't found out how to use it to resume booting.
Try "h" for help - it shows you a list of all kdb commands - isn't that "*nix"-like?
Well, I've found out that 'g' was the right key. Of course, I tried 'h' at first, but due to some screen handling bug, only a part of the help screen appeared.
Meanwhile, I've done some hacking on bochs sources and was able to boot L4Ka with the template root_task. As already mailed, bochs' and l4ka' patches as well as some screen shots are available under:
http://home.kamp.net/home/farid.hajji/l4ka-bochs/
Once screen shot demonstrates what I mean about messed up screen handling.
The Linux's module overlaps with needed physical ram. That overlapping can be avoided by forcing grub to load the modules at a different address (a hack which made it into Dresden's GRUB distribution or use our GRUB-disk). I added an x86-FAQ-page with a description: http://l4ka.org/faq/x86.asp
Was that GRUB-hack committed to CVS at subversions.gnu.org? I used the most recent GRUB sources.
Thanks,
-Farid.
Hi Farid,
Well, I've found out that 'g' was the right key. Of course, I tried 'h' at first, but due to some screen handling bug, only a part of the help screen appeared.
Meanwhile, I've done some hacking on bochs sources and was able to boot L4Ka with the template root_task. As already mailed, bochs' and l4ka' patches as well as some screen shots are available under:
http://home.kamp.net/home/farid.hajji/l4ka-bochs/
Once screen shot demonstrates what I mean about messed up screen handling.
Nop, the screen works like that intentionally. We usually use the serial line to debug (that is the reason to have VMWareGateway for WinNT (http://l4ka.org/tools/vmwaregateway.asp) - I redirect com1 to a named pipe of NT). The screen is divided into two parts - upper half is kernel output (12 lines) and lower half is the test app. That's why the root task prints in the middle of the screen. If you need a different setup - simply change NUM_LINES in l4-ka/kernel/kdb/x86.c from 12 to 25.
Was that GRUB-hack committed to CVS at subversions.gnu.org? I used the most recent GRUB sources.
AFAIK, the current grub version is based on Dresden's network grub - so could be ;)
Volkmar
-- Dipl. Inf. Volkmar Uhlig, University of Karlsruhe, Dept. of CS, System Architecture Group 76128 Karlsruhe, Germany phone: +49 (172) 352-8285, fax: +49 (721) 608-7664, mailto:volkmar@ira.uka.de
From: Volkmar Uhlig volkmar@ira.uka.de Subject: RE: first experiences with l4ka on a real pentium Date: Thu, 19 Oct 2000 09:43:15 +0200
AFAIK, the current grub version is based on Dresden's network grub - so could be ;)
That's wrong.
Okuji
l4-hackers@os.inf.tu-dresden.de