[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Generic bootinfo implementation

From: Alexandre Buisse
Subject: Re: Generic bootinfo implementation
Date: Mon, 14 Feb 2005 17:08:57 +0100

> Hi,
> with the help of racin (who began the job) and marcus, I implemented
> the generic bootinfo protocol (as described in l4-x2.pdf, appendix J).
> There are the headers for libl4 (but not in l4/compat and more exotic
> structures like ELF or EFI tables are not yet implemented) and the
> real thing in laden, plus a two lines modification in wortel to find
> the multiboot info again.
> We are compliant with the L4 specification (in the bootinfo field of
> the KIP, we find the generic bootinfo start, and the multiboot info
> address is specified in a MBI record) and should be able to load any
> L4 kernel.
> Most of the code of ia32-cmain.c was moved into the new file
> ia32-btinfo.c. The initialization of the generic bootinfo structure is
> done in mbi_to_generic_bootinfo, called from cmain and the modules are
> added in find_components(). It is stored at the arbitrary address
> 0x30000 which seemed free. I also moved the parsing of the arguments
> to cmain, in order to be able to have serial output as soon as
> possible.
> There is no problem with laden and, good news, we now have full output
> in the Kernel Debugger when pressing 'B'. However, the thing crashes
> here after calling sigma0 with the following output :
> creating sigma0 (000c0001)
> creating root server (000c8001)
> idle thread started on CPU 0
> 000c8001 pf @ f000ff5f, ip=00300032
> --- "KD# user touches kernel area" ---
> --------------------------------- (eip=f0105ec0, esp=f0112d66) ---
> Wortel is not yet called when that happens, and this looks to me as
> the_bug_that_always_happen_when_you_forget_to_strip_your_binaries,
> although I double stripped them. I added protected regions for the
> generic bootinfo structure, may be is it what causes the problem ?
> I attach nevertheless the patch (obtained with diff -Nru, I don't know
> if that is what is required).

I managed to find the bug (wortel was using libl4 functions before
libl4_init() was called and as the commandline was not yet parsed, it
didn't know where to output the various debug messages) and corrected
several other minor things. wortel still uses the multiboot info (it
retrieves its address from the generic bootinfo structure) so it is
not very useful yet, but I am in the process of rewriting the
corresponding parts of wortel.

It seems to work fine now and I can start banner without problems.
There is much more debug output from laden now (may be should I reduce
it a little ?) which convinced me that there are no obvious bugs in
the implementation, but may be do you want more tests than simply
booting it for real (if so, I have absolutely no idea of how to
proceed) ?

As this is my first experience of OS hacking, please let me know if
some things are wrong, either in style or in conception.

The new patch I attach assumes you've got a clean cvs checkout and
that you did not use the first patch.

And btw, s/racin/Matthieu/ and s/^A$/Alexandre/ in my first mail :)



Attachment: bootinfo2.patch
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]