Íõº£Ã÷ <[EMAIL PROTECTED]> 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 _______________________________________________ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios