I want to write a BIOS debugger.Can you give me some advice?
Eric W. Biederman
ebiederman at lnxi.com
Tue Nov 5 21:24:01 CET 2002
Íõº£Ã÷ <whm_buaa at sina.com> writes:
> hi , all,
> I am a postgraduate student of Beijing University of Aeronautics and
> Astronautics ( in china , Beijing).
> I want to write a BIOS debugger as my graduation article.
> My plan are as follow:
> 1. firstly I want to write a debug stub which is INDEPENDENT of specific
> and small enough. The stub can set up a basic environment ( such
> as RAM
> initialization, uart initialization). It can also communicate with the
> develop PC
> through Serial port,and excute the debug command transfered by the
> develp PC.
As has been previously mentioned
> 2. write a source debugger .
> | |
> -------------------------- serial port | develop |
> | BIOS |debug stub | ----<---->--------- | pc |
> ¡¡¡¡ -------------------------- -----------
> | |
> the system figure
> I appreciate some advice about the possibility of my plan .
LinuxBIOS initializes the ram, and a few other hardware devices and that
is it. So if you want to write a debugger for that there is some
interesting work to do. If you want to write a debugger for firmware
services that are active after the initial hardware setup that is a
different problem. Currently LinuxBIOS provides none of those.
Ram initialization is the single hard dest driver to write for LinuxBIOS.
Short of an ICE I don't think you are going to get a debugger in
there. An emulator like bochs would could work, but it an emulator
may not reproduce the bugs that are visible in real life. A debugger
is useful for is looking around and dumping the state at a given
point. That we can do moderately well with modifing the source code.
What would be truly advantageous is a mini-C compiler that would
compile code that would exclusively use the registers, not memory, and
allow either inline assembly or builtin operations for all of a
processors special instructions. The biggest debugging problem I have
seen is when you add debugging code a register is accidentally
stomped. If it was possible to write the initial startup code in a
high level language it would be much easier to debug and maintain.
On the subject of firmware services, there are projects underway to
build a backwards compatiblity layer for LinuxBIOS. If what you are
really after are debugging firmware services, I would recommend
playing with etherboot. The larger target would be stubs that you can
stick in a moderately random static ELF executable. But I am fairly
certain this is just what is done on embedded targets and is not
really new ground.
More information about the coreboot