started from scratch

It's been a while since my last post. Basically I got a basic hello-world system booting but IPC calls failed. The scheduler somehow throws both roottask and sigma0 out of the runqueues and never runs them again but the idle task. I couldn't properly figure out why this was happening. I began to get this feeling that if I wrote the code myself, would understand it much better and easier. So I left the work there and started my own project from scratch. And yes I can't understand what's going on in that Kenge system either. Reading the sources don't help. In linux it's fine, at least you have a device drivers book, various kernel books and responsive mailing lists. Then when you get to the source you actually seem to pick up a lot from it. But on this I don't think I will lose a lot by starting from scratch. In fact I think writing it yourself is an unmatched learning exercise - only if it is `feasible' that is. I think that it is feasible on the L4 case, because the original pistachio sources are some ~15000 lines. The NICTA version is about ~25000. And oh yes, the biggest benefit of doing it from scratch is that you at least have a step-by-step approach to the problem, and you do feel that you are actually making some progress. In the former case though, you dig up the source, never sure you understand it all, and always dependant on other's help because either they've written it or they've been working on it for a longer time than you.

Anyways, now I got a basic scons system working, being able to cleanly build a bunch of object files, and cleanly configure a piece of C source by using CML2. It works quite nicely and note the word `cleanly'. I tried my best to make it simple and readable. I also finally got around to understanding how linker scripts work, what LMA and VMA addresses mean etc. In a nutshell, the `.' represents the VMA, so one should use AT() ADDRESS() etc. to define the LMA of an output section. The `.' automatically makes sure the VMA's don't clash, but one must take care not to overlap LMA addresses. Also in the elf image, the lma seems to correspond to the physical address in the program header, and VMA to the virtual address field. Also the VMA is what counts as the absolute address of an object file. I'll solidify more on this stuff if I can get my head around wrapping a standalone image with a loader and load it. Anyways, the ld manual and ELF specs are quite good at explaining this stuff, especially after you'd learned a few bits already. It's way too late now, (3AM) I gotta go to bed and leave this stuff for Sunday. I hope London will be fun tomorrow.