GM E38 E67 E40 Kernel/Bootloader Development Extravaganza

Disassembly, Reassembly, Tools and devleopment. Going deep with Hardware and Software.
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 »

Well.. mfspr crashes the cpu for TB. After a bit of googling... its actually a common problem. Wonder if that was my issue for the other timer based stuff.

Anyways, getting away with other commands Iv managed to get it to output:

[09:53:20:006] 05,59,5F,C9,
[09:53:21:093] 05,69,F6,4E,

The timestamp at the beginning is generated by the application.. but essentially we have almost exactly 1 second.

And looking at the hex, we can see an almost 0x10 0000 value. So roughly every 0x10 0000 would be 1 second.

Or, 0x418 (1048) per 1ms (ish).

So.. this should be able to be used as a general timer for the tester present, and can even be used as a more accurate method then 'waste time' function I currently use.

Function setup will be bascially save the start time and desired timeout into ram, and just check this in the main loop consistently.

Iv also found for the CAN frames, the interrupt for write successfully sent... does not work, but the status register indicates when its reading, writing or idle. So a simple loop can be made to wait until idle after writing.
This just optimizes the kernel speed when writing, and can also be setup to allow adjustable delays between canbus frames (technically) which could be handy for supporting other devices... maybe even the dreaded ELM :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 »

Code: Select all

[22:52:22:602]   Received: 101 FE 01 3E AA AA AA AA AA 
[22:52:23:641]   Received: 101 FE 01 3E AA AA AA AA AA 
[22:52:24:695]   Received: 101 FE 01 3E AA AA AA AA AA 
[22:52:25:750]   Received: 101 FE 01 3E AA AA AA AA AA 
[22:52:26:787]   Received: 101 FE 01 3E AA AA AA AA AA 
[22:52:27:842]   Received: 101 FE 01 3E AA AA AA AA AA 
[22:52:28:896]   Received: 101 FE 01 3E AA AA AA AA AA 
About 1.1seconds, thats pretty good, will drop it to about 0.9-1.0sec as I think SAE spec indicates modules will resume normal activity if tester is not sent every 1.5 seconds? maybe it was 2.5seconds.

Just tested in my VE ute, and its keeping the CAN line happy even if I unplug the tool and then reconnect. :thumbup:
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 »

And so I dont go bricking the ECU again.. simple sum of memory to compare between file and memory:

Code: Select all

[12:17:21:003]  Requesting 32bit Sum of flash
[12:17:22:732]  ECU Response: 0B7281E5
[12:17:27:041]  File Calculated Sum is: 0B7281E5
Will work on the CRC implementation tomorrow.
Only thing I didnt plan so well is setting a range for the CRC to calculator for since its response is currently:
7E0 07 40 02 11 22 33 44 55

I only have 5 bytes to play with since (11...55) the bytes before are the length, mode and submode.
But since the address's are 3bytes long, it doesnt fit.

Could add in flow control to allow for a second frame to be sent.. but seems like alot of effort to just get an extra byte in.
The difference would be:
7E0 10 08 40 02 11 22 33 44
7E8 30 00 00 00 00 00 00 00 (ECU must respond to maintain flow control)
7E0 21 55 66

Its not hard... just adds to the apps size which is currently 3.3kb. Speaking of which, I believe I have only allocated myself up to 4k (0x1000) bytes, so not a whole lot of room left now although not a whole lot more to add (other then fixing erase/write)
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 »

CRC calc unfortunately doesnt work too well.

was 2 and half minutes to do CRC on entire flash... which is ridiculously long.

I believe the issue is I need to deal with the WDT less and use only registers, instead of ram as well, since compiler saves everything to ram for the calculation.

*Edit

Yeah, was dealing with WDT waaaaaay too much

[10:02:38:920] Received: 7E0 02 40 02 00 00 00 00 00
[10:02:55:836] Received: 7E8 06 80 02 FF A4 01 34 00

cut down to 17seconds now, I think this could be a smidge better, currently only checking WDT every 0x200 (512) loops in CRC, I believe this could be bumped to 0x400 and get the time to maybe 14seconds

*Edit 2
Nope, 17seconds is definitely the marker, changing the wdt loop has negligible affect after 0x200.

That means if breaking it down into OS and cal, we would have:
OS = 14.5seconds (0 - 0x1B FFFF)
Cal = 2.5seconds (0x1C 0000 - 0x1F FFFF)
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 »

Got an E67 in with a fried injector driver.. so... it has been pulled apart! :thumbup:

E67 has a MPC565, and uses same flash as E38. So everything for the flashchip should be identical. Also has the same slave chip which is on the back side of the flash.

The MPC565 has internal flash (1Mb).. so Im not sure if thats going to be blank, or its going to have something? Along with the 2Mb external flash.

*Edit
Seems almost all addressing is kept the same.. I 'think' I should be able to upload the E38 kernel and it should at least run and not crash instantly.. canbus 'should' work assuming its using the same can.
E67_PCB_front.jpg
E67_PCB_front.jpg (292.05 KiB) Viewed 12716 times
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
kur4o
Posts: 948
Joined: Sun Apr 10, 2016 9:20 pm

Re: GM E38 Kernel/Bootloader Development Extravaganza

Post by kur4o »

You are right. The flashing and unlocking by GM is identical on the first versions of both of these. So I guess internal registers and ram layout is also identical.
The flash routine you developed is likely to work on both.
daniel2345
Posts: 51
Joined: Wed Feb 19, 2020 9:58 pm

Re: GM E38 Kernel/Bootloader Development Extravaganza

Post by daniel2345 »

This one works like E38, just verified on my desk.


You have to check where internal flash is blended into memory space.
Probably 0x400000.

Read there :)

Ill do the same tonight.
Hopefully its empty, so no third flash driver needs to be developed ;)
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 »

daniel2345 wrote:This one works like E38, just verified on my desk.


You have to check where internal flash is blended into memory space.
Probably 0x400000.

Read there :)

Ill do the same tonight.
Hopefully its empty, so no third flash driver needs to be developed ;)
Oh wow, so it might be spread between internal and external?
Maybe they use the internal for boot code and external for the main operating system and calibrations. That would make sense.

I'll wire up the board and see if can't read the flash.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
daniel2345
Posts: 51
Joined: Wed Feb 19, 2020 9:58 pm

Re: GM E38 Kernel/Bootloader Development Extravaganza

Post by daniel2345 »

Yes, mixing address space is very common and has been done before with MPC5xx architecture.
Common automotive approach would be putting all calibration on one flash and leave software where it is in system without internal flash.

But bootcode must be in flash since it is mapped to 0x000000.
We know that because we read valid file there with same structure as E38.

Since the area above 0x200000 to 0x3FFFFF is system reserved, they can not overlap until all system stuff is mapped above 0x300000.

But that can't be the case since can registers are at place we expect them below 0x300000.
Otherwise your and my flashloader would not be able to answer. And it does :)

Conclusion is that only positions possible for blending in internal flash is above 0x400000 and it can not be boot code.
Since calibration is also in external flash, code looks complete, my guess is that in internal flash is just empty and reserved for future purposes.

Since the code makes references to Adresses 0x400000+, this is either coprocessor space or internal flash.


We will find out soon :)
kur4o
Posts: 948
Joined: Sun Apr 10, 2016 9:20 pm

Re: GM E38 Kernel/Bootloader Development Extravaganza

Post by kur4o »

That makes sense. The bootblock is from 0-FFFF, E000-FFFF is eeprom data. That area is not included in the checksum and is not updated during factory flash. It must contain all of the reset vectors and interrupts. I am sure the service number is linked with the data stored there. When it is updated a new service number is issued for the same internal hardware pcm. the question is how this can be updated if possible at all and a confirmation must be made that it is actually in the internal processor flash, by lifting the memory chip and getting the content with a chip burner.
Post Reply