GM E38 Kernel/Bootloader Development Extravaganza

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

Re: GM E38 Kernel/Bootloader Deveopment Extravaganza

Postby Tazzi » Tue Feb 11, 2020 12:25 am

Ah fuckity fuck fucking fuck.

I see it now... Its extremely poorly explained... but I see it...

See the highlighted below. So its showing address 70000-73FFF... this is 0x4000 difference which is actually 0x10000 for this flashchip which is exactly what was erased.

Even though I requested the address of 70400, any address in that range just deletes the whole area. I assumed I could erase the sector size it says earlier.. but size depends on location.
So a bit of logic is needed in the software side to acknowledge that specifc ranges (Most of the chip) is actually 0x10000 in size.

stupidflashchip.PNG
stupidflashchip.PNG (9.36 KiB) Viewed 228 times
Image

Posts: 50
Joined: Sun Apr 10, 2016 9:20 pm

Re: GM E38 Kernel/Bootloader Deveopment Extravaganza

Postby kur4o » Tue Feb 11, 2020 2:27 am

So it is $4000 dwords which equals $10000 bytes. This sucks.
The bin have the cal data from 1c0000 on. Which means that os is intacked and is fully functioning. If the cal data part is not fully erased the OS might fail to load due to bad checksums.

I see that AA 55 66 66 at the end of os segment and cal data segments might be some check dword for bad flash. If you managed to lie the os[grounding some memory pin if there is any] that these are FFs it might be possible for os to boot into recovery mode.

Anyway you are headed on a brick, with that part erase approach, even it had worked the way you wanted it.

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

Re: GM E38 Kernel/Bootloader Deveopment Extravaganza

Postby Tazzi » Tue Feb 11, 2020 12:37 pm

kur4o wrote:So it is $4000 dwords which equals $10000 bytes. This sucks.
The bin have the cal data from 1c0000 on. Which means that os is intacked and is fully functioning. If the cal data part is not fully erased the OS might fail to load due to bad checksums.

I see that AA 55 66 66 at the end of os segment and cal data segments might be some check dword for bad flash. If you managed to lie the os[grounding some memory pin if there is any] that these are FFs it might be possible for os to boot into recovery mode.

Anyway you are headed on a brick, with that part erase approach, even it had worked the way you wanted it.


Yeah spot on, so it was a little unexpected :lol:

Iv seen E38's with erased segments and still work recoverable, thats using a Holden VF OS and calibration which I know has a backup/recover method in them which SPS is able to detect and recover.

But it seems the spare ECU is completely dead. I went over the kernel I used (Saved for later analysis) and I didnt disable the entire write command. The kernel sent all the require commands to do a write, except the final one which does the actual write. The problem with the way that was set, is the next command that gets set would be used as the 'address' to write to. Even though the flash was not erased, it can still set bits to 0 which I believe is exactly what happened.

Pretty sure I have set bytes in the first boot block to 00 by accident.. which is why it no longer wants to run :lol:

And yes, I believe the last 4 bytes do have something related to recover mode. I believe usually when writing to the cal section, it deletes the entire cal and then writes over it. The boot then checks that part of code and if its wrong, it goes into recovery.

If I can recover this dead ecu, I will test that theory.
Image

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

Re: GM E38 Kernel/Bootloader Deveopment Extravaganza

Postby Tazzi » Tue Feb 11, 2020 12:42 pm

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.
Image

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

Re: GM E38 Kernel/Bootloader Development Extravaganza

Postby Tazzi » Wed Feb 12, 2020 2:00 pm

Managed to read the nor flash on the dead unit... and yeah... it messed with a bunch of bytes in the OS and boot section which is what killed it. :lol:

Probably not too comfortable on attempting again without being able to recover, so part is being able to properly recover bad flash. Will resort to an actual clip on programmer for the flash chip if needed, just need to be able to flash in the event it occurs again.
Image

Posts: 2471
Joined: Sun Aug 02, 2009 9:16 pm
Location: Bayside, Melbourne, Victoria

Re: GM E38 Kernel/Bootloader Development Extravaganza

Postby VX L67 Getrag » Wed Feb 12, 2020 8:36 pm

Wouldn’t hot swapping fix it like it has with other e38’s I’ve had non responsive with flashing incompatible os’s?

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

Re: GM E38 Kernel/Bootloader Development Extravaganza

Postby Tazzi » Wed Feb 12, 2020 10:50 pm

VX L67 Getrag wrote:Wouldn’t hot swapping fix it like it has with other e38’s I’ve had non responsive with flashing incompatible os’s?

Unfortunately not, that was the first thing I tried.

The problem is it has corrupted part of the operating system, so it doesn't boot/run correctly. :thumbdown:

Going to see if I cant maybe bridge some pins to jump into recovery mode maybe.
Image

Posts: 50
Joined: Sun Apr 10, 2016 9:20 pm

Re: GM E38 Kernel/Bootloader Development Extravaganza

Postby kur4o » Thu Feb 13, 2020 7:58 am

It is worth trying the ground pin method. The recovery code is very small in length and the chance it is intacked is big. It runs at the very start and is some comm loop only. On ls1s it is like $2000 in length and it can accept uploads without unlocked the pcm. There are some specific messages being send, identifying the brick.

Is this pcm have external memory chip or it is part of the processor. Do you have that routine for the slave and the address where it is loaded. I found some slave file and it is also segmented, There is like OS and 1 cal data segment in it. I suspect more on the chip that are not updated.

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

Re: GM E38 Kernel/Bootloader Development Extravaganza

Postby Tazzi » Thu Feb 13, 2020 1:10 pm

kur4o wrote:It is worth trying the ground pin method. The recovery code is very small in length and the chance it is intacked is big. It runs at the very start and is some comm loop only. On ls1s it is like $2000 in length and it can accept uploads without unlocked the pcm. There are some specific messages being send, identifying the brick.

Is this pcm have external memory chip or it is part of the processor. Do you have that routine for the slave and the address where it is loaded. I found some slave file and it is also segmented, There is like OS and 1 cal data segment in it. I suspect more on the chip that are not updated.


Yeah Its on todays agenda to try recover. Im not feeling too confident with the bricked ECU since its random byte bytes through the entire bin which have been set to 00 or random values.

Basically my kernel had the following code:
While (TotalFlashedBytes < TotalBytesToFlash)
{
Send Command Request To Program Bytes
//Send Bytes to be flashed.
}

Now the // means that line of code was commented out. So what was happening is the flash chip was being commanded to accept the next line of data for programming. Because I had that line commented out the actual data, the flash chip was accepting the 'command' as the data and randomly 00 places in the flash :lol: :roll:

Was a slight oversight on my behalf, I thought I had disabled the writing completely while testing.

The memory chip is external, next option is to see if grounding pins works.
Image

Posts: 6
Joined: Thu Feb 13, 2020 11:32 pm

Re: GM E38 Kernel/Bootloader Deveopment Extravaganza

Postby ironduke » Fri Feb 14, 2020 1:29 am

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!!!

PreviousNext

Return to Bosch ECUs

Who is online

Users browsing this forum: No registered users and 1 guest