Open vmlemon opened 10 years ago
PS - If it it helps, my GRUB2 configuration file looks like:
#http://docs.oracle.com/cd/E26502_01/html/E28983/gkvif.html#glwbd mentions modules
menuentry "OS Name" {
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
multiboot /x86-kernel # The multiboot command replaces the kernel command
module /sigma0
module /l4test
boot
}
Having played some more, I noticed that I misconfigured the GRUB2 config, and set the L4 kernel as the multiboot image, instead of the kickstart.
Changing that resulted in:
KickStart 0.13.06
Detected multiboot compliant loader
kernel (0x00111000-0x0031f7af) => 0x0032a0c0
(0x00111000-0x001221c7) -> 0x00100000-0x001111c7
Conflict with multiboot module 0 (0x00111000-0x0031f7af)
Please choose a different link base
PANIC: FAIL in line 161
I guess that KickStart's incompatible with GRUB2, unless it's modified...
Looks like it's trying to relocate the kernel on itself. I don't think this is related to GRUB2, as my GRUB1 places the kernel image in the same general area of memory as your GRUB2. Here is what I think: Kickstart relocates each section of your kernel image to the addresses specified in the section header. That address is put there by your linker (the kernel image is really just an ELF file) and should be somewhere well out of the way (> 0x00600000 for me). The question is: How did your linker get the idea that the kernel image should be copied to 0x00100000? This looks like an error in the build system, possibly related to #11. I'll let you know if I come up with a solution.
Thanks,
In the meantime, I noticed that booting using the GRUB 0.97 in the CD-ROM ISO from http://www.rdos.net/rdos/grub.iso works, and I can boot into my custom, basic root task (which is based on a modified version of grabmem, if I remember correctly).
If it helps, I've probably got some of the log files from attempts at building in my fork of the repository (in which I'm mostly just working on the userland, rather than the kernel itself); and I could put some binaries somewhere, for testing (if I can find some broken ones).
Also, since it took me forever to figure out, I'm pretty sure that the GRUB2 config file's supposed to look like:
menuentry "OS Name" {
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
multiboot /kickstart # The multiboot command replaces the kernel command
module /x86-kernel
module /sigma0
module /l4test
boot
}
Rather than the aborted attempt, above...
And obviously for GRUB 0.97:
title=L4Ka::Pistachio
root (hd0,0)
kernel=/kickstart
module=/x86-kernel
module=/sigma0
module=/l4test
Congratulations :) I find it strange though that GRUB2 is making such a difference. Could you post kickstart's output using GRUB 0.97? (The same you posted above for GRUB2, containing the "conflict with multiboot module"-error.) Maybe that will tell me what GRUB2 is doing differently.
Aah, sorry for not making things clearer, but if I use the config file above (with all of the experimental bells-and-whistles on), I get the errors when booting (with GRUB2), come to think of it.
That said, I haven't tested an image built that way using the earlier GRUB, yet - but I will do, and report back.
The configuration file that works for me using the 0.97 is:
#
# Automatically generated, don't edit
#
# Generated on: tyson-VirtualBox
# At: Sat, 03 May 2014 19:25:44 +0000
# Linux version 3.11.0-12-generic (buildd@komainu) (gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu7) ) #19-Ubuntu SMP Wed Oct 9 16:12:00 UTC 2013
#
# Pistachio Kernel Configuration System
#
#
# Hardware
#
#
# Basic Architecture
#
CONFIG_ARCH_X86=y
# CONFIG_ARCH_POWERPC is not set
# CONFIG_ARCH_POWERPC64 is not set
#
# X86 Processor Architecture
#
CONFIG_SUBARCH_X32=y
# CONFIG_SUBARCH_X64 is not set
#
# Processor Type
#
# CONFIG_CPU_X86_I486 is not set
# CONFIG_CPU_X86_I586 is not set
CONFIG_CPU_X86_I686=y
# CONFIG_CPU_X86_P4 is not set
# CONFIG_CPU_X86_K8 is not set
# CONFIG_CPU_X86_C3 is not set
# CONFIG_CPU_X86_SIMICS is not set
#
# Platform
#
CONFIG_PLAT_PC99=y
#
# Miscellaneous
#
# CONFIG_IOAPIC is not set
CONFIG_MAX_IOAPICS=2
CONFIG_APIC_TIMER_TICK=1000
# CONFIG_SMP is not set
#
# Kernel
#
# CONFIG_EXPERIMENTAL is not set
#
# Experimental Features
#
# CONFIG_X_PAGER_EXREGS is not set
# CONFIG_X_CTRLXFER_MSG is not set
# CONFIG_X_EVT_LOGGING is not set
#
# Kernel scheduling policy
#
# CONFIG_SCHED_RR is not set
# CONFIG_X_SCHED_HS is not set
# CONFIG_IPC_FASTPATH is not set
CONFIG_DEBUG=y
# CONFIG_DEBUG_SYMBOLS is not set
# CONFIG_PERFMON is not set
CONFIG_SPIN_WHEELS=y
# CONFIG_NEW_MDB is not set
# CONFIG_STATIC_TCBS is not set
# CONFIG_X86_SMALL_SPACES is not set
#
# Debugger
#
#
# Kernel Debugger Console
#
CONFIG_KDB_CONS_COM=y
CONFIG_KDB_COMPORT=0x0
CONFIG_KDB_COMSPEED=115200
CONFIG_KDB_CONS_KBD=y
CONFIG_KDB_BOOT_CONS=0
# CONFIG_KDB_DISAS is not set
# CONFIG_KDB_ON_STARTUP is not set
# CONFIG_KDB_BREAKIN is not set
# CONFIG_KDB_INPUT_HLT is not set
# CONFIG_KDB_NO_ASSERTS is not set
#
# Trace Settings
#
CONFIG_VERBOSE_INIT=y
# CONFIG_TRACEPOINTS is not set
# CONFIG_KMEM_TRACE is not set
# CONFIG_TRACEBUFFER is not set
# CONFIG_X86_KEEP_LAST_BRANCHES is not set
#
# Code Generator Options
#
#
# Derived symbols
#
# CONFIG_HAVE_MEMORY_CONTROL is not set
CONFIG_X86_PSE=y
# CONFIG_BIGENDIAN is not set
# CONFIG_PPC_MMU_TLB is not set
CONFIG_X86_SYSENTER=y
CONFIG_X86_PGE=y
CONFIG_X86_FXSR=y
CONFIG_IS_32BIT=y
# CONFIG_X86_HTT is not set
CONFIG_X86_PAT=y
# CONFIG_PPC_BOOKE is not set
# CONFIG_IS_64BIT is not set
# CONFIG_MULTI_ARCHITECTURE is not set
# CONFIG_X86_EM64T is not set
# CONFIG_PPC_CACHE_L1_WRITETHROUGH is not set
# CONFIG_PPC_TLB_INV_LOCAL is not set
# CONFIG_PPC_CACHE_ICBI_LOCAL is not set
# CONFIG_X86_SMALL_SPACES_GLOBAL is not set
# CONFIG_X86_HVM is not set
# CONFIG_PPC_MMU_SEGMENTS is not set
CONFIG_X86_TSC=y
#
# That's all, folks!
Alternatively, does the config file you just posted work with GRUB2?
That's a good question.
I'm just rebuilding my userland, and reassembling my HDD partition (currently working under Ubuntu installed in VMware Player, with an SCSI disk image for the OS, and an IDE one for Pistachio; and using the IDE image directly with QEMU...), so I'll let you know as soon as it's done.
If I boot using GRUB2 (exact version is 2.00-19ubuntu2), and specify my custom server (counter
) as the root task, I get:
KickStart 0.13.06
Detected multiboot compliant loader
kernel (0x00111000-0x00155115) => 0x0015d0c0
(0x00111000-0x00123567) -> 0x00100000-0x00112567
Conflict with multiboot module 0 (0x00111000-0x00155115)
Please choose a different link base
PANIC: FAIL in line 161
If it helps, I've packaged all of the stuff from the root FS of my disk image, and committed it into an archive as part of https://github.com/vmlemon/pistachio/commit/2923651a35854032331962d0a5ec735e98a68286 (and I'll happily upload a raw, compressed disk image somewhere convenient, if necessary).
Not sure if it makes a difference, but my libio
is slightly modified (mostly by the addition of some functions) from baseline.
For 0.97, I get a successful boot:
KickStart 0.13.06
Detected multiboot compliant loader
kernel (0x00819000-0x0085d115) => 0x0015d0c0
(0x00819000-0x0082b567) -> 0x00100000-0x00112567
(0x0082c000-0x008327c2) -> 0x00114000-0x0011a7c2
(0x00833000-0x00851d58) -> 0x0011b000-0x00139d58
(0x00852000-0x00855c38) -> 0x0015a000-0x0015dc38
sigma0 (0x0085e000-0x008793c3) => 0x00020000
(0x0085f000-0x00868524) -> 0x00020000-0x00029524
roottask (0x0087a000-0x0087ffc6) => 0x0040000f
(0x0087a080-0x0087d724) -> 0x00400000-0x004036a4
Launching kernel ...
L4Ka::Pistachio - built on May 3 2014 20:26:28 by tyson@tyson-VirtualBox using gcc version 4.8.1
Checking CPU features
virtual memory layout:
user area 0 - c0000000
copy area c4000000 - c4800000
ktcb area e0000000 - f0000000
kernel area df000000 - ff000000
cpulocal data f011c000 - f012f92c
utcb pgarea df000000
space link c5000000
Initializing kernel memory (f013a000-f015a000) [128K]
Initializing kernel space
Switching to CPU local pagetable 0013b000 (CPU 0)
CPU local pagetable activated 13b000 (CPU 0)
Initializing TCBs
Activating TSS (Preliminary)
Initializing GDT (Preliminary)
Activating IDT (Preliminary)
Initializing kernel interface page (f011b000)
Adding more kernel memory
found 16M kmem (6ffe000-7ffdfff) -> (f6ffe000-f7ffdfff)
Initializing memory info
Initializing mapping database
Initializing kernel debugger
Initializing IRQ hardware
Initializing Timer
Activating TSS (CPU 0)se
Initializing GDT (CPU 0)
Activating IDT (CPU 0)
Enabling global pages (CPU 0)
Activating MSRS (CPU 0)
Initializing Timer (CPU 0)
Calculating processor speed ...
CPU speed: 1998 MHz
Initializing Processor (CPU 0)
Registering processor 0 in KIP (0MHz, 1998MHz)
Initializing threading (CPU 0)
Switching to idle thread (CPU 0)
System has 16 hardware interrupts
Initializing root servers
root-servers: utcb_area: bf000110 (128KB), kip_area: bff000c0 (4KB)
Creating sigma0 (SIGMA0)
Creating root server (ROOTTASK)
Idle thread started on CPU 0
YOU RANG THE BELL!>
It'd be nice if there was a way to capture the execution flow inside QEMU.
From GRUB 0.97 itself, I get this after loading each image:
As for GRUB2, I vaguely remember reading something, somewhere about it no longer fully complying with the multiboot spec - which seems pretty ironic, given that the GNU folks were involved in designing it...
I wouldn't count on pistachio complying with the multiboot spec either ;) Your GRUB 0.97 works because it is putting your images in a different location than GRUB2. So the question is: Why does GRUB2 think the kernel image belongs at 0x00111000? Unfortunately, I don't have time to dig into that right now, but if I come up with something, I will let you know. Thanks a lot for your help.
No worries.
It seems that others have encountered similar problems - but since I'm wanting to build something using the kernel, it only seems fair that I actually take the time to debug, and report bugs properly. :)
Thanks.
I've probably broken things subtly, but in the meantime, I've been trying to instrument KickStart (although it's slow-going, since there are so many execution paths, and files), in the hopes of figuring out where things are breaking...
Since the Ubuntu folks seem to value consumer vanity, over developer sanity, it looks as if they've "enhanced" their GRUB builds to be less verbose, if https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/386922 is to be believed.
With the old GRUB, I get:
[kickstart.cc] : KickStart 0.13.06
[kickstart.cc] : inside loader()
[kickstart.cc] : Detected multiboot compliant loader
kernel (0x00819000-0x0085d115) => 0x0015d0c0
(0x00819000-0x0082b567) -> 0x00100000-0x00112567
(0x0082c000-0x008327c2) -> 0x00114000-0x0011a7c2
(0x00833000-0x00851d58) -> 0x0011b000-0x00139d58
(0x00852000-0x00855c38) -> 0x0015a000-0x0015dc38
sigma0 (0x0085e000-0x008793c3) => 0x00020000
(0x0085f000-0x00868524) -> 0x00020000-0x00029524
roottask (0x0087a000-0x0087ffc6) => 0x0040000f
(0x0087a080-0x0087d724) -> 0x00400000-0x004036a4
[kickstart.cc] : Launching kernel ...
[ia32.cc] : Inside launch_kernel(), trying to squeeze into 0x1429696
L4Ka::Pistachio - built on May 3 2014 20:26:28 by tyson@tyson-VirtualBox using gcc version 4.8.1
Checking CPU features
virtual memory layout:
user area 0 - c0000000
copy area c4000000 - c4800000
ktcb area e0000000 - f0000000
kernel area df000000 - ff000000
cpulocal data f011c000 - f012f92c
utcb pgarea df000000
space link c5000000
Initializing kernel memory (f013a000-f015a000) [128K]
Initializing kernel space
Switching to CPU local pagetable 0013b000 (CPU 0)
CPU local pagetable activated 13b000 (CPU 0)
Initializing TCBs
Activating TSS (Preliminary)
Initializing GDT (Preliminary)
Activating IDT (Preliminary)
Initializing kernel interface page (f011b000)
Adding more kernel memory
found 16M kmem (6ffe000-7ffdfff) -> (f6ffe000-f7ffdfff)
Initializing memory info
Initializing mapping database
Initializing kernel debugger
Initializing IRQ hardware
Initializing Timer
Activating TSS (CPU 0)se
Initializing GDT (CPU 0)
Activating IDT (CPU 0)
Enabling global pages (CPU 0)
Activating MSRS (CPU 0)
Initializing Timer (CPU 0)
Calculating processor speed ...
CPU speed: 2002 MHz
Initializing Processor (CPU 0)
Registering processor 0 in KIP (0MHz, 2002MHz)
Initializing threading (CPU 0)
Switching to idle thread (CPU 0)
System has 16 hardware interrupts
Initializing root servers
root-servers: utcb_area: bf000110 (128KB), kip_area: bff000c0 (4KB)
Creating sigma0 (SIGMA0)
Creating root server (ROOTTASK)
Idle thread started on CPU 0
YOU RANG THE BELL!>
With the new GRUB, I get:
[kickstart.cc] : KickStart 0.13.06
[kickstart.cc] : inside loader()
[kickstart.cc] : Detected multiboot compliant loader
kernel (0x00111000-0x00155115) => 0x0015d0c0
(0x00111000-0x00123567) -> 0x00100000-0x00112567
Conflict with multiboot module 0 (0x00111000-0x00155115)
Please choose a different link base
[ia32.cc] : PANIC: FAIL in line 161
Still need to dig deeper into ia32.cc, and whatever else it calls, in order to do the voodoo that gets the kernel running.
Now I've got a slightly better idea of how KickStart works, I managed to extend it to expose whether an ELF binary is 32-bit, or 64-bit (so I can tell that the elf.cc has been entered), reveal some info regarding the boot info table, and say when the it tried to enter the kernel...
[kickstart.cc] : KickStart 0.13.06
[kickstart.cc] : inside loader()
[kickstart.cc] : Detected multiboot compliant loader
kernel <32> |
(0x00819000-0x0085d115) => 0x0015d0c0
(0x00819000-0x0082b567) -> 0x00100000-0x00112567
(0x0082c000-0x008327c2) -> 0x00114000-0x0011a7c2
(0x00833000-0x00851d58) -> 0x0011b000-0x00139d58
(0x00852000-0x00855c38) -> 0x0015a000-0x0015dc38
sigma0 <32> |
(0x0085e000-0x008793c3) => 0x00020000
(0x0085f000-0x00868524) -> 0x00020000-0x00029524
roottask<32> |
(0x0087a000-0x0087ffc6) => 0x0040000f
(0x0087a080-0x0087d724) -> 0x00400000-0x004036a4
[bootinfo.cc] : init_bootinfo(), boot info record size & first entry: 32...
[bootinfo.cc] : init_bootinfo(), boot info record version: 1...
[bootinfo.cc] : init_bootinfo(), have 0 entries in the table...
[kickstart.cc] : Launching kernel ...
[ia32.cc] : Inside launch_kernel(), trying to squeeze into 0x15D0C0
Not sure if any of those changes are useful for upstream, though.
Hi,
I've just built the latest Git revision under Ubuntu, including the userland, and I receive the following error, when attempting to run l4test under QEMU:
My kernel configuration file looks like:
Please can someone enlighten me on what's going wrong?