GM E38 Kernel/Bootloader Reverse Engineering Extravaganza

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

GM E38 Kernel/Bootloader Reverse Engineering Extravaganza

Postby Tazzi » Wed Jul 17, 2019 12:07 pm

Title really does say it all :thumbup:

Started looking at the write kernel used on the E38's from SPS, I was playing with my own VE and bascially programmed it up as a Pontiac G8, and noticed there were two kernels sent:
1) First was for OS and all other major cals
2) Second was for Slave OS and another cal labelled Engine in SPS, Im yet to compare where exactly that engine cal goes.. in the ECU. Im assumign on of the files actually updates the slave mcu, and the other updates the MPC slave segment.

Anyways, as far as Im aware, legaility wise there 'shouldnt' be an issue sharing the kernel bin, its more the fact of using it without permission. So anyone that wants to tinker and take a look at the kernel in ida, let me know and Ill shoot through a message :)

Now.. to the nitty gritty stuff... The MCU in the E38's is a MPC562, it has NO internal memory, and only has external memory, so to address the external memory, it needs to call to 0x80000000.
After decompiling the kernel in IDA, we see this:
Image

Link to reference manual: https://www.nxp.com/docs/en/data-sheet/MPC561RM.pdf

We have a good 6 regular functions which are all called from the top segment of instructions. I started commented every instruction.. but as I went along.. I started noticing the absence of the CAN register (TOU_CAN) and also calls to the external memory. Theres calls for all sorts of other registers including interrupt Mask2 register (SIMASK2 = 0x2FC048) and time base/control (TBSCR), but the entire CANbus register (0x307000 to 307800) never appears :?

Sub_74C, has a whole section in regards to addressing the QSMCM register (queues Serial Multi-Channel Module), memory address of 0x3050000. As far as I understand.. this might be the serial communication between the actual main CPU and slave CPU. Why its doing anything with that is beyond me.

So Iv come to the conclusion of:
1) Im going mad
2) Or, the memory addresses are actually offset.|
3) Somehow, It has not decompiled correctly, although it does it happily. May need to try something other than IDA and see if the same results are produced.

Even looking at the flow of the kernel.. I dont see enough for/while loops to be performing read/writing to CANbus and also flashing memory. :roll:
Attachments
E38Kernel_loadedIDA.PNG
E38Kernel_loadedIDA.PNG (41.4 KiB) Viewed 459 times
Image

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

Re: GM E38 Kernel/Bootloader Reverse Engineering Extravaganz

Postby Tazzi » Wed Jul 17, 2019 12:37 pm

Seems the me9 ecus use the MPC chipset as well.

https://webcache.googleusercontent.com/search?q=cache:zuEjxhDI4bgJ:https://www.trionictuning.com/forum/viewtopic.php%3Ft%3D3302%26start%3D10+&cd=6&hl=en&ct=clnk&gl=au
This doesnt talk about kernels at all, but gives a quick indication on what to do with a full E38 bin for loading it properly into ida.

It does speak of configuring the base correctly as its offset to something like 0x400000... wonder if thats whats happening in the kernel too.
Image

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

Re: GM E38 Kernel/Bootloader Reverse Engineering Extravaganz

Postby Tazzi » Thu Jul 18, 2019 11:33 am

The plot thickens...

So.. the slave CPU is a motorola MC9S12, the slave kernel sent over canbus is actually compiled for that specifically.
I thought the slave kernel was run on the MPC562 chip, and it then remotely flashed the slave chip, but doesnt seem to be the case!

I think both the MPC and MC9S912 chips can be addressed separately and both listen to the CANBus system.

Now.. looking at the MPC kernel again, that section I referred to for serial/SPI communication, that must be the communication from the MPC to the Slave CPU. Not sure what its doing yet as havent commented each line of that, but that is the only other peripheral it could be speaking to on board.

So.. this begs the question.. if the kernel isnt running the show for controlling CANbus and directly flashing its memory... then is it really needed?? As far as I see, it disables interrupts and timers ect, and anything else that could get in the way.. then sends a couple commands from the QSMCM register which must be to the slave cpu.

It could possibly be telling the slave CPU to ignore incoming requests?? Maybe?? Then an inbuilt kernel in the MPC OS actually does all the flashing?? I guess one way to find out is see what happens if I try flash it without a kernel... :shock:
Image

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

Re: GM E38 Kernel/Bootloader Reverse Engineering Extravaganz

Postby Tazzi » Thu Jul 18, 2019 11:51 am

Ok yep... Im beginning to think the actual OS has it built into it now.
Look at below, can see it sends the kernel in two parts which is accepted. The tool requests the OS to check if it needs updating.. which it does in this circumstance. It then sends the next update 0x34 request and begins sending the OS file.

Now.. the kernel itself does NOT setup or touch the CAN registers at all... like nada.. zilch... nothing. Im sure its doing something internally.. but.. its certainly not running in a loop to be searching for CAN messages and handling them like i would expect.

Code: Select all
00 00 07 E0 34 00 00 15 40 [0009] FramePad - prepare 0x1540 bytes
00 00 07 E0 [0004] TxDone
00 00 07 E8 7F 34 78 [0007] -wait Im slow
00 00 07 E8 74 [0005] Not Padded - sweet as, good to go
00 00 07 E0 36 00 00 3F C4 30 00 3F C5 1C 00 3F C6 40 FF FF FF FF FF FF .. [4098] FramePad - First part MPC kernel
00 00 07 E0 [0004] TxDone
00 00 07 E8 76 [0005] Not Padded -accepted
00 00 07 E0 36 00 00 3F D4 28 FF FF FF FF FF FF FF FF FF FF FF FF FF FF .. [1362] FramePad  -last part MPC kernel
00 00 07 E0 [0004] TxDone
00 00 07 E8 76 [0005] Not Padded -accepted

Kernel is sent and accepted... next part is flashing

00 00 07 E0 1A C1 [0006] FramePad -request OS
00 00 07 E0 [0004] TxDone
00 00 07 E8 5A C1 00 C0 87 9F [0010] Not Padded -OS = C0879F (needs updating to C0A212)
00 00 07 E0 34 00 0F FE [0008] FramePad -prepare 0xFFE
00 00 07 E0 [0004] TxDone
00 00 07 E8 74 [0005] Not Padded - accepted
00 00 07 E0 36 00 00 3F 90 90 20 33 00 01 20 00 C0 A2 12 41 41 00 00 00 .. [2058] FramePad -first part of OS, sent to addy 3F9090
00 00 07 E0 [0004] TxDone
00 00 07 E8 7F 36 78 [0007] Not Padded - Im slow mate, hold up
00 00 07 E8 76 [0005] Not Padded - alllll goood
00 00 07 E0 36 00 00 3F 90 90 20 33 00 01 20 00 C0 A2 12 41 41 00 00 00 .. [4098] FramePad - next part, addy 3F9090
00 00 07 E0 [0004] TxDone
00 00 07 E8 7F 36 78 [0007] Not Padded
00 00 07 E8 76 [0005] Not Padded
00 00 07 E0 36 00 00 3F 90 90 54 CC 06 FE 7D 03 64 30 4E 80 00 20 39 00 .. [4098] FramePad -next part, addy 3F9090
Image

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

Re: GM E38 Kernel/Bootloader Reverse Engineering Extravaganz

Postby Tazzi » Thu Jul 18, 2019 12:07 pm

The memory layout shown below.. this shows where the above log is putting the data.

So the kernel goes into (2parts): 0x3FC430,0x3FD428, both within the ram address (3F8000 to 3FF000)
Which is 0xFF8 in size between them, which equals 4088 bytes which is exactly the first chunk of data of the kernel sent... so this shows it loads the data correctly, increasing the ram address.

Next, where it begins to flash the actual OS files and cal files, it send to address 0x3F9090, which is still within the ram address. BUT... when its flashing, it never updates this ram address, it always sends to the same address.

What I think is happening, is there is an inbuilt kernel, which will accept specific files which match the sps file structure. Usually these files will actually state the cal number, and indicate things like where its going in memory and stuff like that. So that then matches up with what we are seeing, where the same ram memory address is used the whole way through :thumbup:
Attachments
memorye38.PNG
memorye38.PNG (144.64 KiB) Viewed 420 times
Image

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

Re: GM E38 Kernel/Bootloader Reverse Engineering Extravaganz

Postby Tazzi » Thu Jul 18, 2019 12:10 pm

Next on the list... test the theory... :thumbup:

Assuming that works.. the checksum needs to be worked out for the files so they can be modified.
Otherwise, at least this is a very easy way of performing factory OS flash. Makes me wonder if it has an inbuilt read kernel too...
Image

User avatar
Posts: 2033
Joined: Fri Mar 14, 2014 8:37 pm
Location: Bacchus Marsh, Vic

Re: GM E38 Kernel/Bootloader Reverse Engineering Extravaganz

Postby Biggvl » Thu Jul 18, 2019 12:31 pm

Following this with great interest :thumbup:
According to chemistry, alcohol is a solution...

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

Re: GM E38 Kernel/Bootloader Reverse Engineering Extravaganz

Postby Tazzi » Thu Jul 18, 2019 12:43 pm

Biggvl wrote:Following this with great interest :thumbup:

Im currently coding up to flash with sending the MPC kernel first.. and then flash segments to make sure its all working.

Then remove out the kernel.. and see if it still works :D
Image

User avatar
Posts: 4861
Joined: Sat Feb 28, 2009 8:38 pm
Location: Wellington NZ

Re: GM E38 Kernel/Bootloader Reverse Engineering Extravaganz

Postby delcowizzid » Thu Jul 18, 2019 8:10 pm

Always digging deep good stuff mate
If Its Got Gas Or Ass Count Me In.if it cant be fixed with a hammer you have an electrical problem

Posts: 3171
Joined: Mon Aug 02, 2010 6:35 pm

Re: GM E38 Kernel/Bootloader Reverse Engineering Extravaganz

Postby Dylan » Thu Jul 18, 2019 8:16 pm

I don't know what you're doing but I love it.

Next

Return to Bosch ECUs

Who is online

Users browsing this forum: No registered users and 1 guest