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 Mainchips, 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. 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 .
best regards! yours Haiming Wang 王海明 whm_buaa@sina.com 2002-10-30
- firstly I want to write a debug stub which is INDEPENDENT of specific
Mainchips, 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.
I don't belive there's such thing as "chipset independent ram initalization". other than what what you descriped pretty much summarizes what LinuxBIOS is.
2. write a source debugger . --------- | | -------------------------- serial port | develop | | BIOS |debug stub | ----<---->--------- | pc |
���� -------------------------- ----------- | | ------------------
the system figure
have you tried out bochs? It seems to me it may do pretty much what u want. Although it will put your problem sort of upside down where the burden will be to ensure accurate hardware representation by bochs.
just my two bits.
I think this is an excellent idea. I have thought thought about this myself also.
I was looking at taking kgdb kernel debugger stub and moving it from the Linux kernel into LinuxBIOS. It would have the advantage that it could trap some hardware events that cause a reset, which are currently overwritten or cleared by the PC BIOS upon reset. A LinuxBIOS debugger could save some extra machine state and send it out the debug (serial) port. This functionality is related to implementing power management in LinuxBIOS - things like STR (suspend to ram) require a reset vector handler that is more intelligent.
A BIOS debugger could also make use of the hardware Break/SMI button to bring up the debugger, even if keyboard and serial port are not responding.
I would find such a system useful. I would encourage you to use existing debuggers if possible (kgdb, or kdb) since the source level debuggers already exist for these (ie emacs) and the project could be completed sooner.
Regards,
Jeremy
----- Original Message ----- From: "王海明" whm_buaa@sina.com To: linuxbios@clustermatic.org Sent: Tuesday, October 29, 2002 11:51 AM Subject: I want to write a BIOS debugger.Can you give me some advice?
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 Mainchips,
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.
write a source debugger .
-------------------------- serial port | develop | | BIOS |debug stub | ----<---->--------- | pc || |
-------------------------- ----------- | | ------------------
the system figure I appreciate some advice about the possibility of my plan . best regards!
yours Haiming Wang 王海明 whm_buaa@sina.com 2002-10-30 _______________________________________________ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
������ 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 specific
Mainchips,
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.
Eric