Evo X ROM disassembly/interpretation discussion
#1
Evo X ROM disassembly/interpretation discussion
I hope this is the correct place for this thread. I'm finally putting in a bit of effort into some disassembly and interpretation of the Evo X m32r ROM. Since the Evo X ROM uses a language and layout that hasn't been discussed previously on EvoM, I'm hoping this thread can serve as a place to ask useful questions and report useful methods to disassemble and interpret the ROM code.
Anyhow, I'm looking at a USDM 52680018 GSR ROM.
To get my feet wet, I'm starting off by looking at the layout of table data and interpreting the table lookup routines. My hope here is to get a feel for the m32r assembly language and to use the table header data to find RAM addresses for key variables because, ATM, we have no guide to the RAM addresses like we did with the MUT table in the Evo 8/9 SH ROM.
Below is what I've got for the x-axis layout. The x-axis layout is identical to the layout used in the Evo 8/9 SH code.
First word: RAM variable that stores lookup
Second word: RAM variable used for input into axis
Third word: number of table elements
The difference is how the m32r deals with RAM addresses in table axes. It is storing them as relative addresses. To find the actual RAM address, a little math is needed as follows:
AbsAddr = FFFF|RelAddr (sign extension) + RefRAMAddr
The reference RAM address is 0x80C000. For this axis below, the absolute address for the input RPM RAM variable is:
AbsAddr = 0xFFFFC746 + 0x80C000 = 0x808746.
The x-axis below was for ignition table lookup, so for the 52680018 ROM, it appears that the RPM RAM variable used for ignition table lookups is 0x808746.
The load RAM variable for ignition table lookup is is 0x808590.
Anyhow, I'm looking at a USDM 52680018 GSR ROM.
To get my feet wet, I'm starting off by looking at the layout of table data and interpreting the table lookup routines. My hope here is to get a feel for the m32r assembly language and to use the table header data to find RAM addresses for key variables because, ATM, we have no guide to the RAM addresses like we did with the MUT table in the Evo 8/9 SH ROM.
Below is what I've got for the x-axis layout. The x-axis layout is identical to the layout used in the Evo 8/9 SH code.
First word: RAM variable that stores lookup
Second word: RAM variable used for input into axis
Third word: number of table elements
The difference is how the m32r deals with RAM addresses in table axes. It is storing them as relative addresses. To find the actual RAM address, a little math is needed as follows:
AbsAddr = FFFF|RelAddr (sign extension) + RefRAMAddr
The reference RAM address is 0x80C000. For this axis below, the absolute address for the input RPM RAM variable is:
AbsAddr = 0xFFFFC746 + 0x80C000 = 0x808746.
The x-axis below was for ignition table lookup, so for the 52680018 ROM, it appears that the RPM RAM variable used for ignition table lookups is 0x808746.
The load RAM variable for ignition table lookup is is 0x808590.
Code:
ROM_:00060F3C word_60F3C: .short 0xC596 ; DATA XREF: sub_1F884:loc_1FA98o ROM_:00060F3C ; sub_20870+160o ... ROM_:00060F3C ; x-axis RPM ROM_:00060F3E .short 0xC746 ; rel addr for input RAM variable, ROM_:00060F3E ; absolute addr = 0xFFFFC746 + 0x80C000 = 0x808746, ROM_:00060F3E ; absolute addr for output RAM = 0x808596 ROM_:00060F40 .short 0x17 ; number of elements ROM_:00060F42 .short 0x80 ; data start ROM_:00060F44 .short 0xC0 ROM_:00060F46 .short 0x100 ROM_:00060F48 .short 0x140 ROM_:00060F4A .short 0x180 ROM_:00060F4C .short 0x1C0 ROM_:00060F4E .short 0x200 ROM_:00060F50 .short 0x240 ROM_:00060F52 .short 0x280 ROM_:00060F54 .short 0x2C0 ROM_:00060F56 .short 0x300 ROM_:00060F58 .short 0x340 ROM_:00060F5A .short 0x380 ROM_:00060F5C .short 0x3C0 ROM_:00060F5E .short 0x400 ROM_:00060F60 .short 0x480 ROM_:00060F62 .short 0x500 ROM_:00060F64 .short 0x580 ROM_:00060F66 .short 0x600 ROM_:00060F68 .short 0x680 ROM_:00060F6A .short 0x700 ROM_:00060F6C .short 0x780 ROM_:00060F6E .short 0x800
Last edited by mrfred; Jan 1, 2009 at 09:00 PM.
#3
Nice find, what an odd way they do it! That will need some creativity for cross referencing as you mentioned by PM.
I mentioned to gunzo that there was more code likely to be found by disassembling the interrupt vectors for timers if it is anything like DSM and Evo 7-9 code. Not sure whether this is a remaining issue or not?
Also, finding the entry vector was interesting until it was realised that it is actually an instruction to be marked as code, rather than a vector to be marked as data. Just a note for anyone puzzling over their first disasm attempt.
I mentioned to gunzo that there was more code likely to be found by disassembling the interrupt vectors for timers if it is anything like DSM and Evo 7-9 code. Not sure whether this is a remaining issue or not?
Also, finding the entry vector was interesting until it was realised that it is actually an instruction to be marked as code, rather than a vector to be marked as data. Just a note for anyone puzzling over their first disasm attempt.
#5
Nice find, what an odd way they do it! That will need some creativity for cross referencing as you mentioned by PM.
I mentioned to gunzo that there was more code likely to be found by disassembling the interrupt vectors for timers if it is anything like DSM and Evo 7-9 code. Not sure whether this is a remaining issue or not?
Also, finding the entry vector was interesting until it was realised that it is actually an instruction to be marked as code, rather than a vector to be marked as data. Just a note for anyone puzzling over their first disasm attempt.
I mentioned to gunzo that there was more code likely to be found by disassembling the interrupt vectors for timers if it is anything like DSM and Evo 7-9 code. Not sure whether this is a remaining issue or not?
Also, finding the entry vector was interesting until it was realised that it is actually an instruction to be marked as code, rather than a vector to be marked as data. Just a note for anyone puzzling over their first disasm attempt.
I spent about 1/2 day going through finding more vectors and unanalyzed hex. I'd say that autodisassembly gets only about 2/3 of the code. There are many indirect references to subroutines (stacks of subroutine addresses), so quite a bit of searching for unanalyzed hex seems to be necessary. I suspect that some of these indirectly addressed subroutines are OBD related, as that's what many of the indirectly addressed subroutines in the Evo 8/9 ROM are as well.
#6
Evolved Member
iTrader: (2)
Join Date: Oct 2002
Location: Somewhere
Posts: 1,328
Likes: 0
Received 0 Likes
on
0 Posts
Indirect addressed subroutines are likely non engine related also (gearbox/immobiliser/ETACs comms etc) .. that should account for some of the unreferenced maps I was telling JCSBANKS about ..
Good thing about this newer ROM is there's plenty of room for expansion ..
Good thing about this newer ROM is there's plenty of room for expansion ..
#7
I am somewhat familiar with open ecu and what the tables look like, and am currently trying to learn more about how to correctly use the interface. I have read NJ1266's write up on "how to tune an evo" and found a lot of useful information in there, but I am still trying to learn more. As far as this stuff goes... I'll just come right out and say it; I have only a vague conception as to what I'm looking at here. I assume that this "code" is what needs to be deciphered and interpreted to correctly create the open ecu software, correct? How did you guys even get this code to begin with? Did you guys just use a tactrix cable to pull the ROM image onto a computer? I know much more about cars in general and engine management than most people, but you guys are clearly in a different league so can you help an aspiring student learn more about this? Thanks for any help.
Last edited by STi2EvoX; Jan 1, 2009 at 08:04 PM.
Trending Topics
#8
Evolved Member
very thoughtful of you to start this thread. I will be starting my disassembly work soon in a few days. Its been a while since I did anything this hardcore. This will be a good reference thread for me.
#9
I am somewhat familiar with open ecu and what the tables look like, and am currently trying to learn more about how to correctly use the interface. I have read NJ1266's write up on "how to tune an evo" and found a lot of useful information in there, but I am still trying to learn more. As far as this stuff goes... I'll just come right out and say it; I have only a vague conception as to what I'm looking at here. I assume that this "code" is what needs to be deciphered and interpreted to correctly create the open ecu software, correct? How did you guys even get this code to begin with? Did you guys just use a tactrix cable to pull the ROM image onto a computer? I know much more about cars in general and engine management than most people, but you guys are clearly in a different league so can you help an aspiring student learn more about this? Thanks for any help.
The more people, the better!
Last edited by mrfred; Jan 1, 2009 at 09:12 PM.
#10
Evolving Member
Join Date: Sep 2008
Location: Calgary, AB
Posts: 197
Likes: 0
Received 0 Likes
on
0 Posts
I am somewhat familiar with open ecu and what the tables look like, and am currently trying to learn more about how to correctly use the interface. I have read NJ1266's write up on "how to tune an evo" and found a lot of useful information in there, but I am still trying to learn more. As far as this stuff goes... I'll just come right out and say it; I have only a vague conception as to what I'm looking at here. I assume that this "code" is what needs to be deciphered and interpreted to correctly create the open ecu software, correct? How did you guys even get this code to begin with? Did you guys just use a tactrix cable to pull the ROM image onto a computer? I know much more about cars in general and engine management than most people, but you guys are clearly in a different league so can you help an aspiring student learn more about this? Thanks for any help.
#11
I believe the FP is set in one code path and left alone. Unfortunately lots of compilers are using indirect addressing, some nastier than others
#12
Registered User
iTrader: (5)
Is this the right software manual?
http://documentation.renesas.com/eng...mcu/e32rsm.pdf
http://documentation.renesas.com/eng...mcu/e32rsm.pdf
#13
Is this the right software manual?
http://documentation.renesas.com/eng...mcu/e32rsm.pdf
http://documentation.renesas.com/eng...mcu/e32rsm.pdf
If you want to download the processor manual, it appears to be a 32182 with 1 MB ROM size and 64 KB ROM. RAM starts at 0x804000 and ends at 0x813FFF.
#14
Registered User
iTrader: (5)
Thanks, would like that link. Could you also post a snippet (or all of it) of ECU code if you have it?
Yep, that's the right software manual. Some of the basic register handling commands are not included in the manual though. I can post a link to a more complete command set tomorrow.
If you want to download the processor manual, it appears to be a 32182 with 1 MB ROM size and 64 KB ROM. RAM starts at 0x804000 and ends at 0x813FFF.
If you want to download the processor manual, it appears to be a 32182 with 1 MB ROM size and 64 KB ROM. RAM starts at 0x804000 and ends at 0x813FFF.