GM E38 E67 E40 Kernel/Bootloader Development Extravaganza

[Tazzi]

if you want to do programming just like sps does
then in addition to software and calibrations, nothing more needs to be programmed
if checksums are already calculated in the file

if the checksums are not yet corrected
this can be done on the fly before programming
memory area where you still found them

I often program modified files
standard sps procedures
I only preliminarily count checksums
and change them in the file

Yeah I understand. Im more focusing on making my own custom kernel so I can read/write to absolutely any address including the parameter block which has VIN/Seed/Key ect.

[kostia111]

if you want to program the whole block
in one piece
but modified files
there’s still a lot to fix
much easier to use the standard procedure
breaking a common piece into pieces like GM does

[Tazzi]

if you want to program the whole block
in one piece
but modified files
there’s still a lot to fix
much easier to use the standard procedure
breaking a common piece into pieces like GM does

Basically the plan is to have the following options
1) Write entire calibration section (0x1C0000 - 0x200000). This is only 0x40000‬ (262,144bytes) which will program extremely fast being such a small section.
2) Write single segment (would take only a few seconds)

Now the only issue with the single segment option like GM does is the actual segments do not line up with the flash sectors.

As in, the flashchips sectors which are 0x2000 bytes long, do not line up cleanly with all the cals locations since there could be 2 or more cals that fall into the one sector, or 1 cal could spread over a few different sectors
Hence the second option is actually more difficult to do.

[kostia111]

Yeah I understand. Im more focusing on making my own custom kernel so I can read/write to absolutely any address including the parameter block which has VIN/Seed/Key ect.

if you are talking about a memory area
from 0xc000 to 0x10000
then this is emulation of non-volatile memory in flash
there are several pages visible
I think in this area there are checksums

[Tazzi]

if you are talking about a memory area
from 0xc000 to 0x10000
then this is emulation of non-volatile memory in flash
there are several pages visible
I think in this area there are checksums

Spot on, its the eeprom emulation area.

So when someone rewrites the VIN using dynamic IDs (DIDs), it updates that area with the new vin.

That area also holds things relating to security immobiliser codes and other bits and pieces. So its also another method of being able to get the immobiliser code for resetting and security linking to

[kostia111]

yes you're right any standard programming
consists of two parts
this is programming the main software if it has changed
and calibration programming
but this is only the first part
further win programming takes place
programming date
programmer number
some operations on binding a block to a car, etc.
knowing the authorization algorithm and security code
it is not very difficult to do with standard procedures

the hardest thing you've done
this is reading the whole memory dump.

[Tazzi]

yes you're right any standard programming
consists of two parts
this is programming the main software if it has changed
and calibration programming
but this is only the first part
further win programming takes place
programming date
programmer number
some operations on binding a block to a car, etc.
knowing the authorization algorithm and security code
it is not very difficult to do with standard procedures

the hardest thing you've done
this is reading the whole memory dump.

Yes, security unlocking (Seed/key) is part of everything I have been doing, you must security unlock an ecu before being able to upload a custom kernel / bootloader.

[Tazzi]

Just a standard... 2:00am post. Cause.. the best work is done when sleep deprived

So I have coded up majority of the flash erase and programming into the kernel, but have it currently skip the actual vital parts since going to need to trial run this first to make sure all addressing and things work correctly before pulling the trigger.

For the erasing part, Im going to get it to transmit back the success command plus the sector it has erased to verify sector address(7E8 06 74 QQ WW TT XX YY). Basically everything gets setup and ready to go, other then the single command run to erase that sector, if successful it should send back that message. Only part thats a bit hard to test... until its done... is the function I built to verify the block was infact erased which verifies by checking if the flash is FF.

For the programming/writing.. I currently have it dumping all the bytes to ram, and will validate its correct using a ram read command (mode 40). The actual programming of the bytes has been disabled, but that is a very simple loop which reads a word from ram, writes the word to flash then finally increases address by 4 to repeat until the block has been done (so damn simple).

Im feeling pretty confident on the writing part, but not so much on the erasing. GMs kernel doesnt really give an indication for how long it takes to erase a sector. The data sheet says 1 second per sector.. which would be over a minute in just erasing which seems extremely wrong. GM kernel does not sit around for 1 minute in erasing so I call bullshit on that one.

e38erase.PNG (12.16 KiB) Viewed 7289 times

Even on the sectors with 16k words, doign 16000(ish) * 18 = 294912us = 294.912ms. Literally 1/3rd of the indicated time.. s

Next issue is I cant get the timer to be working correctly. Whenever I enable it, the whole kernel crashes. I assume its because of some sort of timer interrupt which fires but every interrupt is disabled for timers so I cant see how. I figured using a proper timer to count time would be smarter then trying to use a nop loop to waste time.. which is currently the only real way I have found to waste time, inspiration taken from that in the P01/P59 kernel.

*Edit
Page 63, Erase and programming performance.
Typical sector erase time is 0.5seconds. Up to 5secs in worse case conditions of 145degC and 1million cycles.
So.. ~30second for a full chip.. or.. calibration of 0x40000 would be about ~3.5seconds, that seems way more sensible. Now to get some sort of timer working.. or nail in the nop loop values for accurate delays.

[Tazzi]

Pulled the trigger and tried to erase, but no go. Didnt seem to actually erase anything at all on the flash chip.
Likely something silly I have missed or incorrectly written in assembly.

But on that note, going to continue with putting whats currently working into an app for reading E38 flash out.

[Tazzi]

eh.... so... found my mistake in the erase code. I was sending 30 instead of 0x30 so it wasnt erasing.

So.. Iv killed an ECU. Since well. it seems erasing a sector isnt what Iv expected.. and its actually erased a fuck load more then I was expecting. So I didnt check it.. power cycled.... and... shes a no boot.
I did a read before power cycling, although I only checked the section I thought I had changed (0x1C2000-0x1C4000) which was correct, but on second review its actually gone and deleted almost 10 times that around it. So Iv either miss interpreted the flash chip tech document... or it lies.