ziad

iTrader: (1)

maybe i should do soduku

golden words there Ed.... i dont know what cmp/hi r11,r12 bf loc_xxxx does but i can compare two pieces of code quite easily and go ahh that is something that should not be there or the other way around.

Danieln

iTrader: (1)

Thanks for all the information. This is what I was doing for some time anyway.
I wanted to know if I am on the right path.

Cheers,

Dan

03whitegsr

iTrader: (8)

Can somebody tell me if I'm understanding the read/write method to RAM correctly?



For the second and third line of code, I beleive the processor is moving the data at ram address FFFF8A30 to register 10, this is the way I under stand it.

Line 2) The processor adds an offset (0x244 and multiples by 4 for long word) to it's current value in the PC register to locate the address of the new data. This address happens to corresponds to RAM address FFFF8A30. The address is moved into register 10.

Line 3) The data that is currently in register 10 (FFFF8A30) is used as the address to pull data from. What ever value is currently in the address that is held in register 10 is moved into register 10 to replace the address.


Contrast that with lines 7, and 8, where I beleive it is writing new data to RAM Address FFFF8A30.

Line 7) The processor adds an offset (0x238 and multiples by 4 for long word) to it's current value in the PC register to locate the address of the new data. This address happens to be RAM address FFFF8A30 again. The address is moved into register 11.

Line 8) The data that is currently in register 10 (processed data from lines 4,5,& 6) is moved to the address located in register 11 (FFFF8A30). What ever value is currently in register 10 is moved into the address that is located in register 11, there by over writing the data that was previously in FFFF8A30.

logic

iTrader: (2)

Your description sounds right to me, regarding both PC-relative and direct/indirect addressing. Just remember that "@" means indirect; instead of using the value in the location itself (ie. "r10"), you're using that as an address to look up the value you want.

The offset multipliers for PC-relative addressing tripped me up for a long time, for some reason.

03whitegsr

iTrader: (8)

They are kind of tripping me up right now actually, I've just been playing with numbers and it looks like IDA may already multiply them as needed?

If it gives a displacement of 0x80 for example, I can add 0x80 to the current line number and then I'm one long word away from where it seems like I should be reaching.

How do you guys figure out what the RAM address actually is, Engine Speed, Load, Coolant Temp, etc?

silver_evo

You look at the MUT table and match that to what requestID you would log in evoscan or logworks. From there, you know what parameter is in that ram address. So if you want timing you look at MUT 0x06. The MUT table at MUT06 says 8BD9... Which means 0xFFFF8BD9. So you know that 0xFFFF8BD9 holds the value for Ignition Timing. In IDA pro, rename unk_FFFF8BD9 to IgnTim or something similiar.

Now that will only work for a few parameters. For stuff way deep in the rom like some of that Advanced fuel control stuff like TPS accel enrichment / Decel fuel cut delay and ISCV shenanigans you have to keep back-tracking from the MUT request deeper into the code. Like start at ISCV steps and that will get you in the ball-park for Idle control stuff. A complete memory map would be awesome, but it would change with each rom ID (94170015 != 96532706), I had one for my C-64 back in the day and i could make that thing sing with some assembly

03whitegsr

iTrader: (8)

Yeah, I think I've got the RAM stuff figured out from the ADCs.

I was wondering if there was a more simple way to do it or for situations where you don't know what the MUT address is even logging.

logic

iTrader: (2)

You're starting to get into the hard part now.

The offsets listed in the disassembled output are sort-of relative to PC. For longword-relative references, you bitwise-and PC with 0xFFFFFFFC, which might be what's been throwing you off. Also note that some displacements (12-bit disp, used in BRA and BSR) are signed, meaning you can...er...go both ways.

Finally, note that PC is always four bytes ahead of the current instruction executing; the CPU does instruction readahead, and always has at least one extra instruction in the pipeline if it can (it's why non-immediate branches execute one more instruction before actually branching). This is probably the result that you're seeing.

The software manual has a really good set of descriptions for each instruction, just in case you're using the 7052/7055 manuals to try and learn SH2 (you can almost get everything you need from there, but it's dense reading, and skips a few things).

Note that if you're wondering about what a particular MUT entry is for (up to C0, anyway), the wiki has a pretty good list of what we know so far.

One suggestion (and you might already be doing this): label addresses, particularly RAM addresses, constantly as you go. Give things names you'll be able to key off of later when you forget the chunk of code you're looking at. It also helps to have the register addresses from the manual labeled ahead of time, to give you an indication of what a particular chunk of code is doing.

silver_evo: Now you understand why some of us would really like to get everyone on a single ROM.

acamus

Maybe it would be a good idea to pick one ROM as a reference for disassemblers.
Although I am disassembling completely different ROM (stock from my car),
I always try to find the same in the "reference" ROM that all of you can find the same. I am using 88590015 as reference ROM for Evo 7-9 MT.

03whitegsr

iTrader: (8)

Logic, thanks for the help.

I think my biggest problem is this is the first time I've ever even looked at anything like this and my programming skills are quite weak. It's slow learning. That and two 1000 page manuals is a lot of information.

It's created a whole new respect for the guys designing this stuff. I can't even begin to wrap my head around how many years it probably took to create software compilers and such that convert programming language into machine code. Just as impressive is how the machine code works.

Unfortunately, it's become almost an obsession to get a basic understanding, I think my wife is going to kill me.

logic

iTrader: (2)

I typically end up referencing either 96530006 or 88590015 as a starting point, since they have the most mindshare. 8859 isn't too interesting personally right now, and I'm not doing any of this for anyone but myself right now, but since mrfred is so active with it, it's impossible to ignore.

Honestly, a compiler isn't that hard to write, but a good compiler is a mess of special cases. (And there's a lot more to it than just the compiler. If you're interested in this kind of thing, and since you're obviously able to read "thick texts" like Renesas' documentation , I highly recommend the Dragon Book as a starting point.)

And all of this would be so much easier if we had the original C source that Mitsu builds releases from, even if all the comments are in Japanese. (I'm actually not looking forward to more modern platforms being used for ECUs; the more code you can fit in ROM, and the faster you can execute it, the more code the engineers will be tempted to write. At a certain point, you'll reach a code density that makes complete disassembly and interpretation like we're doing here impractical, and it'll be easier to simply start from scratch. Long live Megasquirt? )

hackish

It is doubtful that any standalone will exceed the performance and stability of a stock ECU. The stock firmware is decades beyond what a standalone is unless you're talking about a factory supported unit like a Bosch motorsports ECU or a magneti marelli.

Really you only need a handful of tables to tune most cars anyway. These are generally easy to find. With a little experimentation and testing you can usually find the specifics. Also, from looking at the changes from model to model you can tell when they have decided to re-write and change around different routines - from fuel strategy to open/closed loop routines. As long as the work is done incrementally, new models are generally pretty similar.

-Michael

logic

iTrader: (2)

I'm talking about factory, production ECU development. The GT-R ECU is a perfect example of what's coming to production cars, and just ask jcsbanks how much fun he's having disassembling that. In comparison, replacements are generally much simpler animals to work with, especially something like Megasquirt. (I wasn't proposing it as a better performer, but as an easier platform to hack on.)

As processors get faster, it's going to be more common to see ECUs calculating values, rather than using lookup tables like we've gotten used to. As RAM increases and more flash space becomes available, you'll start seeing a shift away from dirt simple embedded OS' like HItachi's Ho7000, and a move to more fundamentally complex operating systems (embedded Linux is the first thing that comes to mind, although licensing makes that one difficult), and that will put a halt to reverse-engineering the whole thing by simply pointing IDA at it; without source, it'll take years to understand everything that's there, making adding functionality like we've done with the Evo ECU a very difficult thing.

The Evo stuff has been pretty easy overall, but I'm convinced that we're probably a couple of ECU generations away from our current approach to reverse engineering being impractical: not impossible, but not something you're going to generally see hobbyists spending time on. Rudimentary tuning? Sure, but I can accomplish that with an S-AFC. I think most of us here are interested in quite a bit more than that.

Anyway, that's just me prognosticating. Today, things are good.

jcsbanks

It is getting harder with each generation from a 32kb EEPROM not too long ago to 1MB+ full of code now, plus fancy models for combustion time and nightmare compilers that are very efficient but a nightmare of indirection to disassemble, the complexity is now frightening. Add in direct injection and the complexity gets ludicrous (so many combustion modes and switching strategies). Bosch ECUs with their torque and airflow models for everything are also heavy going. It is not uncommon to have four thousand maps in late engine or transmission ECUs. And it would be very easy for manufacturers to obfuscate things to a ridiculous extent.

hackish

Some of the difficulty also relates to the tools you're using. In past years I've written lots of code for OEMs. I was slower moving into this game because I was still bound by other agreements. I can say that OEMs have not been very interested in obsficating anything. It costs them money in both programming and debugging time. The codebase they have now is already quite complex and they're not going to make it more complex to debug.

Also, most of the changes in code are directly related to hardware and emissions requirements changes. You have to look at things from a business case point of view. People reprogamming computers, blowing up engines and getting them covered under warrantee is pretty rare. It's not costing Mitsu a lot of money. That's the only reason they care about stopping us. OEMs have spent millions developing their control strategies on top of the license fees they pay to the ECU company. (Mitsubishi themselves in our case). Why spend 50 million replacing a system that already works properly? Instead, spending 1 million for some incremental updates each time is far better.

Moving to a purely calculated solution is difficult because the math models the engineers develop for powertrains are not perfect so even the OEM has to do some tuning on top of the calculated map. As you pointed out the ECU has lots of processing resources, but lookup tables are still the easiest to modify and they work. An engine doesn't require more granularity either. In fact you can tune something on an 8x8 table that runs more than acceptably.

With GDI you have more complex math for the injection timing and such but really we don't care that much about those things. The OE is also likely to put the adjustments in lookup tables anyway. Imagine the cost of changing fuel injector model if they have to recompile and re-certify their tune. Instead they change some injector size constants and nothing has to go back for certification.

The parts you will probably see in the future involve built-in WBO2 sensors and special ignition systems such as ion sensing to determine optimum advance. Those things are very math intensive but it's usually cheapest for them to integrate an embedded controller for those functions anyway.

The SST control routines are pretty complex and some of the newer predictive driving controls are pretty complex too, but do we really care about them? Not that much.

-Michael