������ whm_buaa@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 specificMainchips,
and small enough. The stub can set up a basic environment ( suchas RAM
initialization, uart initialization). It can also communicate with thedevelop PC
through Serial port,and excute the debug command transfered by thedevelp 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.
Eric