GM E38 E67 E40 Kernel/Bootloader Development Extravaganza

Disassembly, Reassembly, Tools and devleopment. Going deep with Hardware and Software.
kur4o
Posts: 948
Joined: Sun Apr 10, 2016 9:20 pm

Re: GM E38 Kernel/Bootloader Development Extravaganza

Post by kur4o »

Standard flash chip memories require all bits to be high {1`s or FFs] before programming. If not damage can occur. I hope you didn`t fried it with random writing.
If nothing seems to work can a bdm device recover the memory.
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: GM E38 Kernel/Bootloader Deveopment Extravaganza

Post by Tazzi »

ironduke wrote:
Tazzi wrote:Also decompiled the kernel used for the slave OS. Decompiles fine using HCS12.

Its only about 0x18F bytes (400) in length which isnt that much. Can see to main function being used, although Im not familiar with that architecture to break down what its doing. Not sure Im willing to put that many hours into a slave OS at the moment. Still need to have the main chip going smoothly.
Hi there and wow, some amazing reading here.. Most of it is over my head but I am trying to learn.. I figured I'd ask to assist and I'm wondering if you wouldn't mind sending me the slave OS kernel to work with?? I see that you don't want to spend tons of time with it at the moment and I have had some experience with assembly the HCS912 ecu.. Figured I could try and break it down for you..

Another quick question, what are you writing this application in? C#? C++?? Just wondering where I should focus my self teaching towards.. I've done a little in each, more proficient in C++ but not much if any work in communication protocols..

Again, this is fantastic work!!! Thanks for making this a public effort!!!
No problem, will send it through a PM!

Im writing it all in assembly, using the PowerPC (PPC) architecture opcodes. Gets all written in a textfile, then coverted to a binary and finally uploaded to the ECU. :thumbup:
So its nothing fancy!

Since assembly tends to be a bit complex, even simple(ish) C functions can sometimes be difficult to make. So instead I have been making simple C code and compiling using the gcc powerpc compiler, then decompiling the output to see how it has designed the function in assembly. This is how I made the CRC function a couple pages back which is on my todo list to implement next. Would have most certainly saved my currently dead ecu if I had implemented and used it to verify the file matched.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: GM E38 Kernel/Bootloader Development Extravaganza

Post by Tazzi »

kur4o wrote:Standard flash chip memories require all bits to be high {1`s or FFs] before programming. If not damage can occur. I hope you didn`t fried it with random writing.
If nothing seems to work can a bdm device recover the memory.
Correct, all bits need to be 1's for it to be able to program to another value correctly.

But if I had the following example:
B2 - 1011 0010
01 - 0000 0001

If I tried to program 01 to the location that holds B2, the result would be 0, since the first bit (bit0) is set to 0, which cannot be put back to 1 without erasing.
If I programmed 02 into it, the end result would be 02 since the requires bit (bit1) is set to 1 in that byte still, all other bits would be turned off.

I believe the boot sector is still actually in tact. The OS and cals are wrecked so I 'think' this should still be recoverable.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
User avatar
antus
Site Admin
Posts: 8237
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: GM E38 Kernel/Bootloader Development Extravaganza

Post by antus »

maybe, but be careful, some older flash chips are damaged if you program in to a byte which is not all logic high. if you do this and notice later on that some bits or bytes wont set later, thats probably what happened.
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: GM E38 Kernel/Bootloader Development Extravaganza

Post by Tazzi »

antus wrote:maybe, but be careful, some older flash chips are damaged if you program in to a byte which is not all logic high. if you do this and notice later on that some bits or bytes wont set later, thats probably what happened.
Yeah.. probably what has happened here. Was an oversight in the programming thinking I had disabling wiring the flash but not quite. :roll:
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: GM E38 Kernel/Bootloader Development Extravaganza

Post by Tazzi »

Yeah its certainly dead, tried bridging all the address pins of the flash and doesnt seem to get it going.

I did have a bit of a crazy idea.
Make an adaptor which presses onto the flashchips pads on the back side of the PCB and hold the reset line to ground. This should (hopefully) prevent the first buggered flash from communicating and allow connecting a valid working flash temporarily. Once the ecu is booted and bootloader started, the flash adaptor can be pulled off and can then let it flash the originall corrupted chip.

Its a bit of a muck around.. but... should technically work.

This could also be used to bypass a tuner locked ecu technically as well. Thinking I might try remove the flash from a different board I have, and jerry rig some wiring to the corrupted one.. and see what happens. :lol:
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: GM E38 Kernel/Bootloader Development Extravaganza

Post by Tazzi »

:lol: :lol: :lol: :lol: :lol:

Its alive!!!!!!!! (well.. was :roll: )

After alot of trial/errors, I managed to have it stable enough to take the bootloader. After that, I read the whole thing, erased damaged sectors and wrote of them one by one, although I missed out on a couple sectors up near top part of the flash.. I think just cause my counting skills were not great at 2:30am.
The write routine has a bug which reports failed even though it actually succeeds.. so does erase so those are things that need looking into.. but it did actually work :thumbup:

The level of sketchyness is unbelievable though, I had 80 individual wires soldered to the second flash, and the reset line tied to ground for the onboard flash. When fired up the first time, I got can frames on the bus which was incredible to see. But it appeared to be boot looping. I removed a couple wires which were a bit longer and trimmed them back and resoldered.. which seems to have it stable enough to get a kernel in after a dozen or so attempts.
I then removed each pin, one by one while it was powered up and could then use the bootloader commands to repair damaged sectors.

I still haven't implemented a verify function to check sectors/segments.. so kinda kicking myself about that.. as after power down, it didnt boot again as Iv now seen I missed sectors when reviewing my logs. :roll:

Considering that was a good 3+hours.. dont really want to do that again. Custom PCB is likely going to be a hell of alot more consistent, and can be held in place then removed when required.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
User avatar
antus
Site Admin
Posts: 8237
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: GM E38 Kernel/Bootloader Development Extravaganza

Post by antus »

Man thats hardcore! Good work!
At what point does it become easier to remove the chip and flash it off board? what sort of chip and package are we talking about?
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: GM E38 Kernel/Bootloader Development Extravaganza

Post by Tazzi »

So the flash chip is on the front side of the ecu which you can't get to. All chips are on the front side.

When pulling off the back plate, all you have is pads.

Iv gone and ripped a good flash chip off an ECU which had fried injector drivers. Required having to cut off the front plugs to get to the front of the ecu
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: GM E38 Kernel/Bootloader Development Extravaganza

Post by Tazzi »

The inbuilt scaled timers for the MPC can go get stuffed. As soon as its enabled, kills the kernel. Im sure Im missing something basic but its not playing fair.

So instead, there appears to be a nice 64bit free running binary counter. So going to try use that to generate a nice constant tester present loop generated by the kernel. This means even if a tool drops out communication, it will still keep the car in a suspended state with the tester present. (Inspiration from PeteS lsdroid kernels).

Now.. it indicates the address is SPR269 and SPR268. So I guess that means I will have to use the mfspr command to dump it into a general register and compare with a previously saved value. Lets see if this method works
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
Post Reply