Forums

Need Recommendations - Possible 68K embedded unix debug issue

Started by Jim Flanagan January 4, 2009
Hi...
I need some suggestions.  I own an old 1990 vintage piece of
HP test gear that has an annoying firmware bug that I thought
(for fun) I would attempt to track down by reverse engineering
some of the firmware.  The system uses a 68030 controller and I pulled
the eproms and made a binary image in order to disassemble.
I have a very good reason to believe that HP used a variant of HP unix
for embedded systems (I am just guessing).

My question, what tools are available to debug this sort of thing?  I 
don't want to get into any legal issues as this is solely for fun (aka
no profit).

I would appreciate any help that you can offer.
Thanks
-jim
Jim Flanagan wrote:
> > Hi... > I need some suggestions. I own an old 1990 vintage piece of > HP test gear that has an annoying firmware bug that I thought > (for fun) I would attempt to track down by reverse engineering > some of the firmware. The system uses a 68030 controller and I pulled > the eproms and made a binary image in order to disassemble. > I have a very good reason to believe that HP used a variant of HP unix > for embedded systems (I am just guessing). > > My question, what tools are available to debug this sort of thing? I > don't want to get into any legal issues as this is solely for fun (aka > no profit). > > I would appreciate any help that you can offer. > Thanks > -jim
You should be able to generate a set of GNU binary utilities (binutils) for the M68k series processors. The utilities include an object file dumper/disassembler (objdump) which could do the job. Of course, there are the more common things, assembler, loader etc., as well. -- Tauno Voipio tauno voipio (at) iki fi
Jim Flanagan wrote:

> My question, what tools are available to debug this sort of thing? I > don't want to get into any legal issues as this is solely for fun (aka > no profit).
The standard for such things is the IDA Pro disassembler: http://www.hex-rays.com/idapro/ You can label subroutines and variables to make it easier to read the listing while reverse engineering. One idea would be to work backward in the listing, starting from the routines which controls the output pins. Then patching the bug would be easy, if there is some free space in the EPROM. But maybe easier would be to ask HP, if they know the bug and have bugfixed firmware? -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.de