Saturday, April 29, 2006

L4 almost booting

Recent changes: I first learned and practiced how to load an elf image into memory. It is actually not that complicated. The elf header tells where the image entry address is, and where to find all sections in the file. Each section has a program header. The program headers define where each section is to be loaded in memory. In L4 case, the kernel, the hello application, and server tasks each are included in a separate section and their program loaders point at where they're to be loaded. The rest of the play is finding out where each section lies in the image, and copying them into the correct addresses in memory, and jumping into the entry address. That's it.

I got that working now. The tricky bit was that the main memory starts from address 0x0, but loading the image there caused problems. The other issue is that the loader must not run on addresses where the image need to be loaded. Otherwise it would overwrite itself and the result would be undefined.

After dealing with all these, the image boots now. Second thing I did was to add printing routines for the uart, the routines that work both when the vmem is enabled and disabled. They're assembly routines that check whether the mmu_is_on() and refer to uart base address, and the string pointer passed in r0 either as they are, or by adding a vmem offset to them. It works well. The only gray region is when the vmem is enabled but the uart area hasn't been mapped and therefore inaccessable. In that case you simply don't print anything.

The initialisation goes well, up until printing the TID of a roottask (or sigma0?) I will debug it this weekend. But the actual thing is, I am so glad to have gone through the initial steep learning curve, and I actually got to practice the whole system in operation. This is going to get me going much faster than before now. Also in the past weeks, I found the cause of a bug in the linux kernel that affected mpcore booting, and that had been searched for quite some time, which is good progress. I also learned how to code for inclusion in the kernel, I got the style of writing kernel code. My next patch will have good chance to get accepted I hope. Things to do: I need to do more python work, learn scons and kenge. I need to get L4 working, and submit a patch to maintainers. I need to learn stacked git and get better on git patch management. I need to add debug section support to dite, so I can follow symbols from the debugger.

Thursday, April 06, 2006

C is simply better

I converted my c++ uart driver to C. This is because the l4 loader uses the C library to print progress, (printfs, __putchar etc.) which in turn uses some uart functions (obviously written in C in a C library). My c++ driver wouldn't fit there, so converted the code. It wasn't a big deal.

I think especially for system programming C is quite sufficient. The complexity tradeoff that C++ brings is simply not worth the benefits of the language. Maybe in app-space it makes a difference but I guess not for system programming.

Tomorrow I'll add the C uart driver to the bare-metal C library and try loading the kernel again...

Monday, April 03, 2006

L4 update

I wrote a complete uart driver in C++. Added parts of it (polled mode, it doesn't need irqs) to kernel debugger for L4. Compiled the final image, loaded it in axd and I was able to run it partially.

The problem is that the kernel image does not contain any symbols, because dite discards all of them. I got good replies in L4 mailing list. It seems I don't have to have an elf loader bundled with my image since axd is capable of loading elf images, but I'm not sure yet whether I need dite still. I should need it, because the bootinfo should be patched and hello + sigma + kernel still needs to be put together (using dite?).

I read through the elf specs, It should be easy enough to copy symbols before dite, and then patch them after dite, to the final image. We'll see.