ROM disassembly as raw text file
Jul 8, 2011, 05:30 AM
#1
Evolved Member
Thread Starter
ROM disassembly as raw text file
Hi folks.
Dunno if someone's done this already... couldn't find anything, so here goes:
I've been messing about on my Ubuntu laptop, and have slapped together a text file containing the full M32R disassembly from my ROM. This is a very basic disassembly - just the raw instructions - but it's a good start for those curious to see Evo X / RA ROMs from the inside.
This isn't an IDA Pro thing, as my wife said, "What's IDA Pro? HOW MUCH? This is a joke, right? Tell me you're joking.". No, I just used the objdump tool (part of Gnu binutils package), configured/built with m32r instruction set as target. Yes, the propellor on my head is spinning at 7,500rpm.
So now I can wade around, learn the instruction set, search/replace known addresses to add my own tag references, etc:
* My comments may not be using the right nomenclature, but hey, it's a learning experience! 
I will now get busy back-tracking the EcuFlash table refs to code refs, flesh those out, and start joining the dots to scale lookups. I know it would be nice to have an entire development environment, integrated viewers, library/database stuff... but for me, this is a good, free start. And it's kind of nice needing nothing more than a text editor to review it and add my tags.
Linux Propellor-Head Stuff
<geek-mode>
To get this working, I did the following...
And yes, Linux is a tiny little bit nuts-and-bolts (cough). Apologies if this isn't a 100% how-to for your OS setup... should you even have one!
Downloaded latest binutils source tar/gzip (version 2.9.1 at this time) from:
http://ftp.gnu.org/gnu/binutils/
gunzipped it and extracted it
gunzip <blah>
tar -xvf <blah>
cd <blah>
Note: I also needed to install flex, or the later stages failed with "lex not found" errors. Probably just my dodgy old Ubuntu version. Only do this if you don't have "lex"
sudo apt-get-install flex
Configured binutils for M32R target architecture
./configure --enable-targets=m32r
Built all the binutils stuff
make
Ran objdump on my ROM
binutils/objdump -b binary --architecture=m32r --disassemble-all -EB 53610010.hex > 53610010.txt
Got all excited when it worked, played air-guitar
</geek-mode>
Stuff I will also be sussing out...
So... raw assembler. Yay. Now I can dive deep into a world I thought I'd left behind in the distant 1980s (along with cassettes, The Jesus and Mary Chain, and carburetors).
Cheers,
Rich
Dunno if someone's done this already... couldn't find anything, so here goes:
I've been messing about on my Ubuntu laptop, and have slapped together a text file containing the full M32R disassembly from my ROM. This is a very basic disassembly - just the raw instructions - but it's a good start for those curious to see Evo X / RA ROMs from the inside.
This isn't an IDA Pro thing, as my wife said, "What's IDA Pro? HOW MUCH? This is a joke, right? Tell me you're joking.". No, I just used the objdump tool (part of Gnu binutils package), configured/built with m32r instruction set as target. Yes, the propellor on my head is spinning at 7,500rpm.
So now I can wade around, learn the instruction set, search/replace known addresses to add my own tag references, etc:
Code:
21834: e0 06 0f 9c ld24 r0,#0x60f9c tag- RPM scale 21838: fe 00 b2 f6 bl 0x4e410 tag- Scale lookup sub 2183c: e0 06 0f d0 ld24 r0,#0x60fd0 tag- Load scale 21840: fe 00 b2 f4 bl 0x4e410 tag- Scale lookup sub 21844: e0 05 5b 52 ld24 r0,#0x55b52 tag- Low Octane Spark Map 3d table 21848: fe 00 b2 58 bl 0x4e1a8 2184c: a0 2f 00 18 sth r0,@(24,sp) 21850: e0 05 59 50 ld24 r0,#0x55950 tag- High Octane Spark Map 3d table 21854: fe 00 b2 55 bl 0x4e1a8 21858: a0 2f 00 1a sth r0,@(26,sp) 2185c: a1 bf 00 16 lduh r1,@(22,sp) 21860: a1 2d c5 90 sth r1,@(-14960,fp) 21864: e0 06 0f 9c ld24 r0,#0x60f9c 21868: fe 00 b2 ea bl 0x4e410 tag- Scale lookup sub 2186c: e0 06 0f d0 ld24 r0,#0x60fd0 21870: fe 00 b2 e8 bl 0x4e410 tag- Scale lookup sub
I will now get busy back-tracking the EcuFlash table refs to code refs, flesh those out, and start joining the dots to scale lookups. I know it would be nice to have an entire development environment, integrated viewers, library/database stuff... but for me, this is a good, free start. And it's kind of nice needing nothing more than a text editor to review it and add my tags.
Linux Propellor-Head Stuff
<geek-mode>
To get this working, I did the following...
And yes, Linux is a tiny little bit nuts-and-bolts (cough). Apologies if this isn't a 100% how-to for your OS setup... should you even have one!
Downloaded latest binutils source tar/gzip (version 2.9.1 at this time) from:
http://ftp.gnu.org/gnu/binutils/
gunzipped it and extracted it
gunzip <blah>
tar -xvf <blah>
cd <blah>
Note: I also needed to install flex, or the later stages failed with "lex not found" errors. Probably just my dodgy old Ubuntu version. Only do this if you don't have "lex"
sudo apt-get-install flex
Configured binutils for M32R target architecture
./configure --enable-targets=m32r
Built all the binutils stuff
make
Ran objdump on my ROM
binutils/objdump -b binary --architecture=m32r --disassemble-all -EB 53610010.hex > 53610010.txt
Got all excited when it worked, played air-guitar
</geek-mode>
Stuff I will also be sussing out...
- Which areas of the ROM are executed, which are big chunks of data, and which are unused... so I can cut my text file size down from its current 20MB!
- Whether it's bad form legally to put full disassembled ROM text up online (short answer: quite probably yes).
- Trying out other objdump parameters, to see if there are different ways to present the instructions.
So... raw assembler. Yay. Now I can dive deep into a world I thought I'd left behind in the distant 1980s (along with cassettes, The Jesus and Mary Chain, and carburetors).
Cheers,
Rich
Jul 8, 2011, 08:25 AM
#3
If no one has any objections I'd be glad to give you some FTP space and host the file.
#2 - you don't watch NASCAR
?
Jul 8, 2011, 09:46 AM
#4
Evolved Member
Thread Starter
Hmm.
Looks to me like objdump is missing a couple of "M32R-FPU Extended Instruction" items. This means that, out of the box anyway, it won't know what to do with stuff like:
04 F1 yy yy
According to the manual, this should be:
btst #4,R1
Like...
So I'll need to wade into the binutils m32r-related source and educate it! Should be fun. 
Once I get a suitably tweaked m32r objdump binary (built by gcc for i386 Linux), I'll post it up. See if other people on similar OS can just run it as-is...
Rich
Looks to me like objdump is missing a couple of "M32R-FPU Extended Instruction" items. This means that, out of the box anyway, it won't know what to do with stuff like:
04 F1 yy yy
According to the manual, this should be:
btst #4,R1
Like...
Code:
38a0: 60 01 f0 00 ldi r0,#1 || nop
38a4: a0 2d 65 4a sth r0,@(25930,fp)
38a8: fe ff ff 1c bl 0x3518
38ac: fe ff fa 29 bl 0x2150
38b0: 2e ef 1f ce ld lr,@sp+ -> jmp lr
38b4: 60 00 f0 00 ldi r0,#0 || nop
38b8: a1 9d 65 5c ldub r1,@(25948,fp)
38bc: 04 f1 7c 02 *unknown* -> bc 0x38c4
38c0: 60 01 1f ce ldi r0,#1 -> jmp lr
38c4: 1f ce f0 00 jmp lr || nop
Once I get a suitably tweaked m32r objdump binary (built by gcc for i386 Linux), I'll post it up. See if other people on similar OS can just run it as-is...
Rich
Jul 8, 2011, 11:24 AM
#5
Evolved Member
Thread Starter
Cool - now I know how to add missing instructions to objdump.
From the looks of it, there are only a couple that are undefined. I've done one easy instruction...
I'll go track down other "*unknown* entries, and try to add those too. It's a bit of a maze in there, but I reckon I can nut it out.
Rich
From the looks of it, there are only a couple that are undefined. I've done one easy instruction...
Code:
38a0: 60 01 f0 00 ldi r0,#1 || nop
38a4: a0 2d 65 4a sth r0,@(25930,fp)
38a8: fe ff ff 1c bl 0x3518
38ac: fe ff fa 29 bl 0x2150
38b0: 2e ef 1f ce ld lr,@sp+ -> jmp lr
38b4: 60 00 f0 00 ldi r0,#0 || nop
38b8: a1 9d 65 5c ldub r1,@(25948,fp)
38bc: 04 f1 7c 02 btst #0x4,r1 -> bc 0x38c4
38c0: 60 01 1f ce ldi r0,#1 -> jmp lr
38c4: 1f ce f0 00 jmp lr || nop
Rich
Jul 8, 2011, 01:11 PM
#7
Evolved Member
Thread Starter
I saw JAMC perform, just a couple of years ago... on the post-Coachella-reunion glory tour. William didn't attack Jim (or us) with his mike stand, the band was tight, and they played out the entire set... but they were brilliant nonetheless. That perfect sound just washed over us, and for a little while we were all young, stupid and happy again. All hail the Reid brothers. A-hey-hey-heeeey....
But back to the task at hand! I've got objdump updated with the missing M32R definitions, and I'm happy enough with its assembler output.
I've attached my current build. There's also a readme in there, plus a wee shell script to run the tool a bit more easily.
Yeah, I know Linux isn't normally a "provide-a-binary" kind of world. Everyone normally rolls their own. If requested, I can always bundle up the few source mods I made (required to add support for the M32R "bclr", "bset" and "btst" opcodes). You can then stuff around with a full binutils v2.9.1 package download... if that floats your boat.
The attachment is tar.gz style. As it was 200KB and an EvoM-unspecified file type, I renamed it in a pleasantly dodgy way. Just rename it right back.
If you give it a try, let me know how it goes. Sure looks good on my Ubuntu laptop... and no more "*unknown*" opcodes...
Sweet!
Rich
That perfect sound just washed over us, and for a little while we were all young, stupid and happy again. All hail the Reid brothers. A-hey-hey-heeeey....But back to the task at hand! I've got objdump updated with the missing M32R definitions, and I'm happy enough with its assembler output.
I've attached my current build. There's also a readme in there, plus a wee shell script to run the tool a bit more easily.
Yeah, I know Linux isn't normally a "provide-a-binary" kind of world. Everyone normally rolls their own. If requested, I can always bundle up the few source mods I made (required to add support for the M32R "bclr", "bset" and "btst" opcodes). You can then stuff around with a full binutils v2.9.1 package download... if that floats your boat.
The attachment is tar.gz style. As it was 200KB and an EvoM-unspecified file type, I renamed it in a pleasantly dodgy way. Just rename it right back.
If you give it a try, let me know how it goes. Sure looks good on my Ubuntu laptop... and no more "*unknown*" opcodes...
Code:
b974: a0 bd c5 f0 lduh r0,@(-14864,fp)
b978: 01 f0 7c 04 btst #0x1,r0 -> bc 0xb988
b97c: e4 80 07 00 ld24 r4,#0x800700
b980: a5 74 00 00 bclr #0x5,@(0,r4)
b984: 7f 03 f0 00 bra 0xb990 || nop
b988: e4 80 07 00 ld24 r4,#0x800700
b98c: a5 64 00 00 bset #0x5,@(0,r4)
Rich
Trending Topics
Jul 8, 2011, 01:50 PM
#8
Newbie
Join Date: May 2011
Location: Germany
Posts: 15
Likes: 0
Received 0 Likes
on
0 Posts
Hey,
maybe you could post your patches and disassemblies to a google code or github account. This way you have revision control and everything is publicly available.
Is it possible to reassemble the objdump file using as?
maybe you could post your patches and disassemblies to a google code or github account. This way you have revision control and everything is publicly available.
Is it possible to reassemble the objdump file using as?
Jul 8, 2011, 09:30 PM
#9
Evolved Member
Thread Starter
I'll take a look at that.
If I do get to the point of changing code, I doubt I'd trust reassembly of the entire ROM. No, I'd work on the tiny snippet of code in question in isolation, and surgically implant it wherever it belonged. Then the only risk involved is from the changed code.
Plenty of things I can got on with, now I've got a full disassembly. It would be kind of cool to draw from the many enhancements made to the Evo ROMs over the years, and splice one or two into my RA ROM.
My to-do list includes:
Splicing in the knock-CEL goodness from Evo World to my RA ROM.
A little work in assembler could be good for my engine's health!
Finding out why my SST-related engine management doesn't switch to the Lower Boundary Spark Map during WOT upshifts.
It seems everyone else's ECU does this, but mine only retards the timing during part-throttle upshifts, and even then only sometimes.
Splicing in the temperature-dependent BWGDC % adjustment table from Evo World.
I can live with load-based boost control, as I've actually got it working quite well now. But once summer rolls around, I'll be wanting the BWGDC adjusted by a few percent to compensate.
Splicing in live-mapping from Evo World!
Aiming pretty high on this one, I know. But it'd be reaaaally nice for tuning timing.
Rich
If I do get to the point of changing code, I doubt I'd trust reassembly of the entire ROM. No, I'd work on the tiny snippet of code in question in isolation, and surgically implant it wherever it belonged. Then the only risk involved is from the changed code.
Plenty of things I can got on with, now I've got a full disassembly. It would be kind of cool to draw from the many enhancements made to the Evo ROMs over the years, and splice one or two into my RA ROM.
My to-do list includes:
Splicing in the knock-CEL goodness from Evo World to my RA ROM.
A little work in assembler could be good for my engine's health!
Finding out why my SST-related engine management doesn't switch to the Lower Boundary Spark Map during WOT upshifts.
It seems everyone else's ECU does this, but mine only retards the timing during part-throttle upshifts, and even then only sometimes.
Splicing in the temperature-dependent BWGDC % adjustment table from Evo World.
I can live with load-based boost control, as I've actually got it working quite well now. But once summer rolls around, I'll be wanting the BWGDC adjusted by a few percent to compensate.
Splicing in live-mapping from Evo World!
Aiming pretty high on this one, I know. But it'd be reaaaally nice for tuning timing.
Rich
Jul 11, 2011, 10:28 AM
#10
Newbie
Join Date: May 2011
Location: Germany
Posts: 15
Likes: 0
Received 0 Likes
on
0 Posts
Hey Richard,
I just saw that you are referencing to a really old version of binutils. 2.9.1 is one of the oldest available versions (released somewhere in 1998).
I think version 2.21.1 (released in June 2011) is the most current version.
I just saw that you are referencing to a really old version of binutils. 2.9.1 is one of the oldest available versions (released somewhere in 1998).
I think version 2.21.1 (released in June 2011) is the most current version.
Jul 12, 2011, 07:56 AM
#12
Evolved Member
Thread Starter
Hey, thanks! I was extraordinarily bandwidth-limited when I was scouting around for source material, so I guess I messed up my initial step. Duh.
Quite remarkable I got it working on Ubuntu at all, then, really.My next project will be to build a wheel out of stone, using only sticks and a mammoth tusk.
I'll redo that work. Bet it'll require less bashing using a version from this millennium!
Rich
Jul 12, 2011, 08:52 AM
#14
Newbie
Join Date: May 2011
Location: Germany
Posts: 15
Likes: 0
Received 0 Likes
on
0 Posts
You may have a look at http://www.linux-m32r.org/ there you can find a good working version of gas (as) and binutils in general.
Unfortunately some tools of version 2.21.1 don't have support for M32R anymore.
Tephra, how do you do that splicing? Would it be possible to use a C compiler to generate the code and then splice that code into the BIN file? Or is it only possible to write good old assembly code?
Unfortunately some tools of version 2.21.1 don't have support for M32R anymore.
Tephra, how do you do that splicing? Would it be possible to use a C compiler to generate the code and then splice that code into the BIN file? Or is it only possible to write good old assembly code?
Jul 12, 2011, 09:19 AM
#15
Evolved Member
Thread Starter
Great info, folks. Thanks a million.
Here's my first stab at learning M32R assy... yes, welcome to stream-of-consciousness commenting...
(looked better as an image - tabs are impossible to get right in this format)
What's the usual standard for assy commenting? I couldn't recall, so I just used an easily replacable "tag-" string.
I'm already putting together a list of interesting stuff to look at and test when I get the chance, like:
And as I'm still getting up to speed, believe none of the above! I'm not yet able to really tell the difference between the RAM area being used to store useful stuff, and the "scratch" area that's just used-and-reused for any old gubbins. All in good time...
But that 0x808f7c "Baro comp load" is a new one for me, and would be a great find, if it's right. Can't check right now, though - don't have my car! So all I can do is meander around its "residual self-image".
Rich
Here's my first stab at learning M32R assy... yes, welcome to stream-of-consciousness commenting...
(looked better as an image - tabs are impossible to get right in this format)
What's the usual standard for assy commenting? I couldn't recall, so I just used an easily replacable "tag-" string.
I'm already putting together a list of interesting stuff to look at and test when I get the chance, like:
Code:
Useful EcuFlash config addresses 0x53544 - Temp value used to decide when to switch timing load from Baro+temp to Baro compensated. Value: 0x0041 (x-40 for Celsius) 0x62384 - Load Scale - 9 elements. Like the scale used for "EGR Timing Advance". Useful logging addresses to try out (53610010): 0x808658 - Temperature used for decision as to which load is used for timing. 0x808774 - Baro+temp compensated load, presumably. Used for timing when temp under 25C. 0x808f7c - Baro compensated load, presumably. Used for timing when temp over 25C. 0x808a04 - FINAL load value chosen for use in timing map lookups, incl. any offsets. 0x808a0a - A differently scaled timing, possibly. Lower level. 0x808a3c - Another, alternate scale internal timing, apparently. Lower level again. 0x808a3e - As above.
And as I'm still getting up to speed, believe none of the above!
I'm not yet able to really tell the difference between the RAM area being used to store useful stuff, and the "scratch" area that's just used-and-reused for any old gubbins. All in good time...But that 0x808f7c "Baro comp load" is a new one for me, and would be a great find, if it's right. Can't check right now, though - don't have my car! So all I can do is meander around its "residual self-image".
Rich