Page 1 of 2

MPC56xx / PowerPC table lookup examples?

Posted: Fri Jan 14, 2022 8:29 am
by Gatecrasher
Has anyone got disassembly examples for how an MPX56xx or other PowerPC variant does table lookups? I'm picking apart a chassis control module (MPC5644A) looking for the NPP exhaust valve controls. Now that I'm finally learning how Ghidra works, I'm making decent progress. Knowing a little bit about how GM does table and axis lookups would help a lot though. It doesn't look like GM uses headers or prefixes like the old Mitsubishi stuff I'm used to. That stuff seems so quaint by comparison.

Re: MPC56xx / PowerPC table lookup examples?

Posted: Fri Jan 14, 2022 11:06 am
by Tazzi
This would all depend on how the developer handles it?

Some GM modules have references to every table/option near the top of the operating system. This is easy to identify after having 1 or 2 items defines, since you can then search the absolute address of the defined value in memory and try identify it in the operating system area.

Re: MPC56xx / PowerPC table lookup examples?

Posted: Sat Jan 15, 2022 12:40 am
by Gatecrasher
Ok. I was hoping there was some sort of common-ish format to the calibration files that you could use to get some basic characteristics of the table and then work backwards from there.

This thing has a ton of code. It can perform a whole lot of functions in the trucks. Air suspension, trailer braking, etc. I'm kind of surprised they stuck it in cars where it's only doing exhaust flapper control. Seems way overkill.

Re: MPC56xx / PowerPC table lookup examples?

Posted: Mon Jan 17, 2022 8:52 am
by Gatecrasher
This is irritating. I don't think it's explicitly related to map lookups, but it's busting up my disassembly enough to hurt my search. Ghidra flags this as a bad instruction and halts disassembly. IDA doesn't know it either. It happens in quite a few places.

Code: Select all

                             LAB_0015fc90                                    XREF[1]:     0015fc78(j)  
        0015fc90 81 8e 31 ac     lwz        r12,DAT_000031ac(r14)
        0015fc94 3d 60 00 09     lis        r11,0x9
        0015fc98 81 6b 91 00     lwz        r11,-0x6f00(r11)=>DAT_00089100                   = 41800000h
        0015fc9c 10              ??         10h
        0015fc9d 8c              ??         8Ch
        0015fc9e 5a              ??         5Ah    Z
        0015fc9f cc              ??         CCh
        0015fca0 40              ??         40h    @
        0015fca1 85              ??         85h
        0015fca2 00              ??         00h
        0015fca3 18              ??         18h
The processor is an off the shelf NXP part, so I don't think it's some custom GM stuff. It might be related to cache instructions in later versions of this PPC core, but I can't find a clear answer on it. If anyone has seen this in other PPC based ECUs, please let me know.

Re: MPC56xx / PowerPC table lookup examples?

Posted: Mon Jan 17, 2022 9:04 am
by Tazzi
Likely a VLE instruction.

In MPC55xx and newer (Including MPC56xx), they brought in VLE instructions which can sometimes not be automatically picked up or identified.

Re: MPC56xx / PowerPC table lookup examples?

Posted: Mon Jan 17, 2022 9:43 am
by Gatecrasher
I may have fixed it.

You can change the processor language for an existing project. It's irreversible, so they recommend you back up your project file before you do it. I switched from "PPC big endian 32 bit" to "PPC big endian 64 bit VLE with 32 bit addressing". The code block disassembles now.

Code: Select all

                             LAB_0015fc90                                    XREF[1]:     0015fc78(j)  
        0015fc90 81 8e 31 ac     lwz        r12,DAT_000031ac(r14)
        0015fc94 3d 60 00 09     lis        r11,0x9
        0015fc98 81 6b 91 00     lwz        r11,-0x6f00(r11)=>DAT_00089100                   = 41800000h
        0015fc9c 10 8c 5a cc     efscmpgt   cr1,r12,r11
        0015fca0 40 85 00 18     ble        cr1,LAB_0015fcb8
        0015fca4 39 80 00 00     li         r12,0x0
        0015fca8 b1 8e 32 84     sth        r12,0x3284(r14)=>DAT_4000b274
        0015fcac 38 60 18 05     li         r3=>DAT_00001805,0x1805
        0015fcb0 48 00 4a b1     bl         FUN_00164760                                     undefined FUN_00164760()
        0015fcb4 48 00 00 38     b          LAB_0015fcec
EFSCMPGT is apparently Floating-Point Single-Precision Compare Greater Than.

Re: MPC56xx / PowerPC table lookup examples?

Posted: Mon Jan 17, 2022 12:18 pm
by Tazzi
haha!! VLE strikes again!!!

Came across the same issue when looking at the GM write kernels.

Hopefully that helps make a bit more sense.

Re: MPC56xx / PowerPC table lookup examples?

Posted: Mon Jan 17, 2022 12:32 pm
by antus
Good to know, thanks for sharing Tazzi, not an obvious one to understand when you just see the disassembly fail.

Re: MPC56xx / PowerPC table lookup examples?

Posted: Tue Jan 18, 2022 1:05 am
by Gatecrasher
I think I found the master subroutine for the exhaust valve controls. It checks one byte in the calibration region for a 1 or 0, and if it find a 1, it starts down a tree of 103 additional subroutines. I don't know yet if that's just the NPP sound valves or if that includes the upstream AFM valves too. That seems like a whole lot of code for it to just be the NPP valves. I've barely scratched the surface yet.

I stumbled on something else interesting. It looks like some of the map values are 32 bit floating point values, and Ghidra shows them as percentages in the decompiler window. So that's handy. I've never seen that before. There's a ton of xxyy0000 values in the calibration region, and I was wondering what the hell they were. It looks like there might be some RPM values encoded the same way too.

Re: MPC56xx / PowerPC table lookup examples?

Posted: Sun Feb 13, 2022 5:24 am
by Gatecrasher
Been meaning to post an update on this. I found the valve control tables. There's no real preamble or header or even a lookup table that points to the valve tables. They're just direct references in the code. It's weird, because there's plenty of other places where they used lookup tables to point to things like peripheral registers. Things you'd think would be a lot more constant than calibration tables.

Anyway, I got there by backtracking the diagnostic routines and then just converted all the suspected tables into FP values using Ghidra. Once I found enough stuff that resembled the screenshots people have posted from HP Tuners, I put it into TunerPro and made a really basic XDEF.

Once the weather warms up I'll test out some changes and try to find something that makes my new exhaust happier. :D

Ghidra's decompiler is like magic. It made this SO much easier. It was still a pain in the ass, but it was at least a manageable pain in the ass.

Hey Tazzi...how hard would it be to add this MCU to your flashing tool? It'd be a nice finger in the eye to HPT. The whole thing that got me started on this was not wanting to pay over $500 just to tweak two tables.