Hi, I'm currently evaluating using the L4ka:Pistachio kernel on the x86 architecture as the core of an operating system project I am part of.
I'm building from the latest sources on the Mercury repository system with GCC 4.4.1 and Binutils 2.19.1.20090418 on Arch Linux (Linux 2.6.x). The build process completes flawlessly. I am trying to boot into the kernel through GRUB (I'm testing on VMware Workstation 6.5.2), by loading kickstart at the kernel, followed by the modules x86-kernel, sigma0, then one of the sample applications (pingpong, grabmem. l4test). Kickstart boots into the system, but once the kernel has loaded the system appears nonoperational: [pasted below] KickStart 0.13.06 Detected multiboot compliant loader _kernel (0x00816000-0x00840995) => 0x001444a0 (0x00816000-0x00829192) -> 0x00100000-0x00113192 (0x0082a000-0x0082a4b8) -> 0x00115000-0x001154b8 (0x0082b000-0x0083500e) -> 0x00116000-0x0012000e (0x00836000-0x00839fe8) -> 0x00141000-0x00144fe8 sigma0 (0x00841000-0x00857a8d) => 0x00020000 (0x00842000-0x0084a410) -> 0x00020000-0x00028410 roottask (0x00858000-0x0085ee02) => 0x00300000 (0x008f9000-0x0085d040) -> 0x00300000-0x00304040 Launching kernel ... [/paste end] But nothing more. When I built the kernel will spin wheels enabled, I noticed it was animating as if the kernel was still functioning. I also attempted building with other kernel configurations enabled and disabled - all resulting in the same outcome. I then attempted to modify one of the sample applications (grabmem), and I discovered that I could write directly to the screen buffer (0xb8000), which shows the application does load (but it is strange since as far as I know, printf also writes directly to the screen buffer, but printf does not appear to be doing anything). Also at the same time I discovered the system hangs during any attempt to communicate with sigma0 (through the functions provided in l4/sigma0.h). I also noticed, in the kernel's build directory there is an include directory. However I don't see these files being referenced anywhere by the user code. ( The prebuild 0.4 image functions correctly under VMWare. ) I don't understand what I am doing wrong, and if I may have missed any steps to get the system functioning? Also, I could write directly to 0xb8000 from the roottask. From my understanding, only sigma0 was suppose to have all physical memory allocated to it at boot, therefore for my roottask (or any other thread) to access the physical memory at this location I would need it mapped into the thread's local address space. So could some one please explain the memory protection and clear this up? Also, I'm unsure of at what location in virtual memory the kernel has been mapped. Thanks for all your help, Andrew
