GM E38 E67 Kernel/Bootloader Development Extravaganza

Bosch Motronic etc ECUs and PCMs
User avatar
Posts: 2133
Joined: Thu May 17, 2012 8:53 pm
Location: WA

Re: GM E38 Kernel/Bootloader Reverse Engineering Extravaganz

Postby Tazzi » Wed Feb 05, 2020 1:32 pm

kostia111 wrote:hello !
why not use a lot of frame message
the same way as when programming a block
then it will be possible to transfer about 4k
in one message
or use a standard service
ReadMemoryByAddress ($23) Service.
maybe I'm writing stupidity
and misunderstood you


So what you posted is the preparation/setup for the ECU, which includes unlocking, disabling chatter ect. Once that is done, the kernel (Also called bootloader) is sent to the ECU which then executes and allows reading/writing/whatever you want.

When looking at the GM logs, you will see in most car computers, a bit of code is uploaded to it first. Is that code which I am referring to in this thread where I am trying to code it up to read/write the ECU.
The more I write with PPC, the easier its becoming and the better ways of coding I am finding.

The mode 23 doesnt allow reading all memory address, and also allows only reading 8bytes at a time which is extremely slow. Whereas with a custom kernel, we could download up to 0xFFF (4,095‬) bytes at a time if we wanted.

This is the basic setup Im going for:
1) Unlock ECU
2) perform ecu setups (disable chatter, faults ect)
3) Upload bootloader code and execute
4) Request data to read using 7E0 06 35 XX XX YY YY YY where XX is length of data, and YY is the address offset from 0.
5) ECU will respond as 7E8 1Z ZZ 75 XX XX YY YY YY.... then data frames from here. Where ZZ is the canbus frame length (XX+6), XX is the requested length and YY the address offset.
6) kernel will comply with SAE standards so it can be happily read using a J2534 tool, which is the canbus formatting I was working out above.
Image

User avatar
Posts: 2133
Joined: Thu May 17, 2012 8:53 pm
Location: WA

Re: GM E38 Kernel/Bootloader Reverse Engineering Extravaganz

Postby Tazzi » Wed Feb 05, 2020 2:03 pm

Iv had to do abit of hackery with trying to make a time waste loop so that the ecu does no spit out data too quickly.

PPC appears to commonly use ori r0,r0,0 as its 'nop'.

Seem to have fucked up somewhere in it.. as once it enters... it nevers comes out.. I guess the function does do what its told haha :lol:

Im following an online example which explains saving the LR/Stack when entering a function, and then storing when returning back.. unfortunately doesnt seem to want to work although multiple examples show this exactly. The coding for the function works if I dont put it into a function and run the code directly in the loop I have.

Basically I have:
stwu r1,-0xC(r1) /allocate 12 bytes : stack pointer, link register and one non volatile reg. (4bytes each =32bits).
mflr r0 // get link register
stw r0,0x4(r1) // Save link register
stw r30,0x8(r1)//save r30

//Do a bunch of stuff here!!!//

lwz r30,0x8(r1) //restore register r30
lwz r0,0x4(r1) //load saved link register
mtlr r0 //restore link register
addi r1, r1, 0xC //retore stack pointer
blr //return function

Seems pretty straight forward.. but obviously not.
Image

User avatar
Posts: 2133
Joined: Thu May 17, 2012 8:53 pm
Location: WA

Re: GM E38 Kernel/Bootloader Reverse Engineering Extravaganz

Postby Tazzi » Wed Feb 05, 2020 2:05 pm

Ah no ok I see. Functions inside of function... theres the fuckup I think.

http://www.eecs.umich.edu/courses/eecs3 ... I_matt.pdf

I believe when I call a function inside of a function.. its overwritten the previous stack data/corrupting it so it never knows where to go. Right... going to have to see how GM did that.. or just have to add commenting on all functions to ensure no overlapping memory occurs.
Image

User avatar
Posts: 2133
Joined: Thu May 17, 2012 8:53 pm
Location: WA

Re: GM E38 Kernel/Bootloader Reverse Engineering Extravaganz

Postby Tazzi » Wed Feb 05, 2020 8:12 pm

Flashchip stuff is a little silly. The 'address' for everything is shifted by 2bits. It threw me off all afternoon trying to get the required device ID and manufacture ID.

But got it doing this now:
[06:04:12:031] Sending Bootloader
[06:04:13:580] Received frame from ecu is: 00,00,07,E8,76,80,00,00,01,7E,08,

The 01 is the manufacturer ID and 0x7E, 0x8 is the device ID of the flash chip. So the flash chip is responding to commands.
I have it output the information after executing the kernel (76 80).

Now.. the GM kernel makes ALOT of references to a QSPI device.. the only device I can think of that it is communicating to is the slave chip. It appears to poll or send some data every so often which I am assuming is done to keep it happy? I wonder if the slave chip is able to reset the main CPU if it believes its lost communication..

My kernel is still crashing/ending even after satisfying the watch dog... so Im wondering if that is why the GM kernel has QSPI in there too.
Image

User avatar
Posts: 2133
Joined: Thu May 17, 2012 8:53 pm
Location: WA

Re: GM E38 Kernel/Bootloader Reverse Engineering Extravaganz

Postby Tazzi » Thu Feb 06, 2020 3:37 am

ok yeah, thats confirmed. Sends data over QSPI peripheral to keep the device happy.
Both watch dog and slave have to be happy, otherwise device resets.

Now for the exciting news... its no longer crashing AND its responding to can frames
[01:27:10:717] Received: 7E0 06 36 80 00 3F C4 00 00
[01:27:10:718] Received: 7E8 07 76 80 00 00 01 7E 08
[01:27:22:774] No Chatter Detected..46
[01:27:23:391] Received: 7E0 01 20 00 00 00 00 00 00
[01:27:23:394] Received: 7E8 01 60 42 59 45 42 59 45

Executes the kernel at its load location
kernel responds with 76 response which include flash ID at end
And finally requesting a mode 20 to end to kernel, which responds with 60.. and a BYEBYE in hex. :thumbup:

So.. Ill call that a major success, and actually to bed before 3am :wtf: :lol:
Next is onto actually reading the flash tomorrow. I was playing around with it today while messing with the flashchip device id, although need to retest again now understanding the memory addressing better.
Image

Site Admin
User avatar
Posts: 6163
Joined: Sat Feb 28, 2009 8:34 pm

Re: GM E38 Kernel/Bootloader Reverse Engineering Extravaganz

Postby antus » Thu Feb 06, 2020 8:03 am

Good progress, thanks for posting updates. It makes for interesting reading.
Have you read the FAQ? For lots of information and links to significant threads see here: viewtopic.php?f=7&t=1396

User avatar
Posts: 2133
Joined: Thu May 17, 2012 8:53 pm
Location: WA

Re: GM E38 Kernel/Bootloader Reverse Engineering Extravaganz

Postby Tazzi » Thu Feb 06, 2020 3:30 pm

antus wrote:Good progress, thanks for posting updates. It makes for interesting reading.


No problem! It allows me to go back over my own posts too at a later date if I need a memory jog. Plus.. as always.. no documentation of stuff like this anywhere, only bits and pieces around the web which have to be strung together to make sense.

Perfect example is the memory chip addressing which is poorly explained for what occurs when using single/dual, parallel flash chips or 8/16/32 bit communication. I have close to 30tabs open just for the spansion flash chip :lol:
I managed to find someone raging about the same thing I was seeing where there was no explanation to why the addressing needed to be shifted by 2bits since the 16bit setup he was using indicating shifting 8.


Added a bit of error monitoring to check if using an unsupported command along with exiting the kernel correctly now:
[01:20:41:791] Sending Kernel
[01:20:43:468] executing kernel
[01:20:43:471] Rx frame: 00,00,07,E8,76,80,00,00,01,7E,08,
[01:20:43:472] Kernel Loaded, total time: 1.682sec

[01:20:50:262] requesting mode 70 (unsupported random command)
[01:20:50:267] Rx frame: 00,00,07,E8,7F,70,11,
[01:20:51:330] requesting mode 70 (unsupported random command)
[01:20:51:333] Rx frame: 00,00,07,E8,7F,70,11,

[01:21:27:454] requesting mode 20
[01:21:27:459] Rx frame: 00,00,07,E8,60,42,59,45,42,59,45,

[01:21:33:380] requesting mode 20
[01:21:33:388] Rx frame: 00,00,07,E8,60,

Can see on the second mode 20 request, the ECU response different which is when its out of the kernel. :thumbup:
Image

User avatar
Posts: 2133
Joined: Thu May 17, 2012 8:53 pm
Location: WA

Re: GM E38 Kernel/Bootloader Reverse Engineering Extravaganz

Postby Tazzi » Fri Feb 07, 2020 5:11 am

another standard 3:00am post.. :lol:
Now have customised DID requests put in for requesting various bits and bobs.
Along with a mode 40 which I want to use for generating CRC for sections. The CRC part is a bit complicated but I have the beginnings of that implemented.

And the exciting part.. the beginning of reading...
[02:37:59:823] Received: 7E0 06 35 0F F0 00 C0 B0 00
[02:37:59:828] Received: 7E8 1F F6 74 0F F0 00 C0 B0
[02:37:59:830] Received: 7E0 30 00 00 00 00 00 00 00
[02:37:59:830] Received: 7E8 21 38 39 31 30 34 30 36
[02:37:59:831] Received: 7E8 22 35 32 47 31 57 54 35

Currently its only doing just a couple of lines, as it was a proof of concept. But basically I have a while loop and read out 8bytes at any one time.

Im wanting to make a rotating buffer.. something like:
1) create loop to add 7bytes to CAN frame
2) count to 4 then read the next 4 bytes and continue in the loop.

should allow it to read the flash and send the data pretty efficiently and quickly.
Image

User avatar
Posts: 2133
Joined: Thu May 17, 2012 8:53 pm
Location: WA

Re: GM E38 Kernel/Bootloader Reverse Engineering Extravaganz

Postby Tazzi » Fri Feb 07, 2020 5:12 pm

And there she is!

[15:06:33:857] Received: 7E0 06 35 00 23 00 00 00 00 -request 0x23 bytes (35 bytes) from address 00 00 00
[15:06:33:860] Received: 7E8 10 28 74 00 23 00 00 00 -sure no dramas mate
[15:06:33:861] Received: 7E0 30 00 00 00 00 00 00 00 -flow control from scantool
[15:06:33:863] Received: 7E8 21 60 00 00 00 60 00 00 -7
[15:06:33:864] Received: 7E8 22 00 48 00 01 6A 60 00 -14
[15:06:33:865] Received: 7E8 23 00 00 48 00 1C 6E 60 -21
[15:06:33:866] Received: 7E8 24 00 00 00 48 00 1E 06 -28
[15:06:33:866] Received: 7E8 25 60 00 00 00 48 00 1E -35 bytes

All SAE compliant so the J tool was about to send and pickup the response

Going to do a full read to make sure its all there and correct byte for byte. And also try add a CRC function.

Otherwise I think its about ready for people to give it a go! :thumbup:
*Edit
Only support J tools, have tested with an MDI and nano
Image

User avatar
Posts: 2133
Joined: Thu May 17, 2012 8:53 pm
Location: WA

Re: GM E38 Kernel/Bootloader Reverse Engineering Extravaganz

Postby Tazzi » Sat Feb 08, 2020 3:58 am

Full read is about 2min 34seconds.
This could be spend up by decreasing the delay between frame writes but its honestly not that long of a wait to be honest.

Had a slight muck up in the initial frame response, was meant to have a 75.
7E8 10 28 74 00 23 00 00 00

was 1 bit out from a rlwimi command (Now one of my favorite things to use... go figure).

Verified that a full dump is valid when comparing with one pulled from manually pulling flash :thumbup:
Have attached it to this post.

Hopefully over this weekend I can neaten up a quick little app for reading E38 ecus and post up here.
While doing that, will be doing my research on wiping sectors and flashing.
What I have figured so far is:
1) Unlock flash/enable write mode
2) Erase sector
2) save incoming chunk of data to RAM
3) write a word (4bytes) at a time (Cant do byte at a time I 'think')

I think so long as I aim for a calibration area first which is full of FF's, I should be able to test out erasing and writing that.
Attachments
E38_Dump.bin
(2 MiB) Downloaded 24 times
Image

PreviousNext

Return to Bosch ECUs

Who is online

Users browsing this forum: No registered users and 2 guests