GM E38 E67 E40 Kernel/Bootloader Development Extravaganza

Disassembly, Reassembly, Tools and devleopment. Going deep with Hardware and Software.
Post Reply
kur4o
Posts: 948
Joined: Sun Apr 10, 2016 9:20 pm

Re: GM E38 Kernel/Bootloader Reverse Engineering Extravaganz

Post by kur4o »

Since you are at the reading stage. Is there any way to read the slave file.
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 Reverse Engineering Extravaganz

Post by Tazzi »

kur4o wrote:Since you are at the reading stage. Is there any way to read the slave file.
I have been looking into that.. so the slave is a: MC9S12 C32MPBE25 1M34C CTQYV1114
data sheet: https://www.nxp.com/docs/en/fact-sheet/MC9S12C32FS.pdf
reference manual: https://www.nxp.com/docs/en/data-sheet/MC9S12C128V1.pdf
Page 48 of reference manual is pinout.
So its not powerpc, uses the same Motorola architecture ( HCS12 famaily) which says it is "Opcode compatible with the 68HC11 and 68HC12", which I believe is the same architecture ass the P01/p59... so might need the expertise of the P01/P59 lads to understand whats happening with that.

I will need to double check my GM logs but pretty sure a different bootloader is written and then the slave OS uploaded.
The second bootloader is not PowerPC off the top of my head. So I believe depending on the address its uploaded to, is whether it goes to the master of the slave system.

The slave does have CAN pins.. although looking at the board.. I dont think they are actually running to anything. Will need to probe to verify.
I believe what happens is the following:
1) Bootloader gets sent, depending on upload address is whether the master CPU saves to its ram or sends it over to the slave
2) Slaves receives bootloader via SPI communication
3) Executes and runs the code.
4) master must just know to shoot across the data to slave based on address sent to.. I think.

But theres only a few different slave OS's. Almost easier to just get all the OS's and then make a variant of the bootloader that GM uses.
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 Deveopment Extravaganza

Post by Tazzi »

Onto the next deadly saga.. writing.

Am going to need to use the following commnad:
Address : Command
1554 : AA
AA8 : 55
1554 : 80
AA8 : 55
XX : 30 (or 1554 : 10 for full chip erase... deadly)

This is a sector erase request. Sector entered at XX which I assume will also require the shift left 2 bits.
Looking through the GM kernel.. I dont think I saw it do the final step. Maybe jumped to another function or something, will have to go back through it.

Looking at the data sheet: https://www.cypress.com/file/219931/download
Quick quote from the data sheet
"These devices are organized in 1,048,576 double words (32 Mb) or 524,288 double words (16 Mb) and are capable of linear burst
read (2, 4, or 8 double words) with wraparound. (Note that 1 double word = 32 bits.) These products also offer single word
programming with program/erase suspend and resume functionality."

Page 14 has sector sizes.
Looking at SA0/SA1 as the example, shows 0-0x7FF which is 2048 dwords. So we know a dword is actually 4 bytes, so its 2048*4 = 8192 bytes (0x2000)

And also 524,277 double words so multiple by 4 bytes (1x double word) which is 2,097,152‬ (0x200000) which is the size of our E38 flash :thumbup:

So think I can safely say the smaller size that an be erased at a time would be 2048 bytes which is pretty standard.

Im guessing erasing then immediately writing a section is the safest bet for an architecture rather then having two separate commands sent to the ecu, just do it all in one.
So the address used to upload to the E38 will be use to determine which sector is erased... can make the ecu return a fault if invalid sector address... but if valid will erase and then program with bytes provided.
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 Deveopment Extravaganza

Post by Tazzi »

*sigh*... it makes sense now.

dword = 4 bytes. Shifting left by 2 bits = 4. So depending on what size word your using for the flash will affect how to address to it. Cool that makes ALOT more sense.

Now.. 1 sector is 0x2000 bytes (8192)
The max number of bytes that can be transmitted by can in one chunk is 0xFF9 (4089bytes).
So matter what, there needs to be a minimum of three chunks sent for flashing:
send two chunks 0xof 4089 (8178bytes) plus tiny chunk of 14bytes.
Or 4 chunks of 0x800 (2048 bytes).
This also means I cannot erase and flash an entire sector in one single command (unfortunately) so back to two separate ones.

Id like to follow a similar writing standard to what GM has indicated in SAE documents, but with minor tweaks.
1) Send mode 34, this requests the ecu to prepare for X amount of bytes. I recon using this command to indicate which flash sector/s to erase would be best.
so example: 7E0 06 34 QQ WW TT XX YY where:
QQ WW TT is the flash address (sector) that will be erased,
xxyy is the length of bytes going to be sent =0x800
ECU will response with 7E0 01 76 once it has successfully erased. I would assume an easy way to validate it has erased is to check bytes are FF? Could loop through every byte or just check a couple.

Technically.. the XXYY will do nothing.. since we dont actually need to prepare any ram... we have a shit load.


2) send mode 36 for data upload. This has the address and data for flashing.
example 7E0 18 06 36 00 XX YY ZZ SS where:
800 is the length, plus 6 to include this initial frame bytes
00 = compress byte - we are not using this
XX YY ZZ SS = address.

Again following SAE standards, multiline frames/flow control standards needs to be followed so will need to deal with the leading counting byte (ignore it) and only extract the following 7 bytes.
As doing 7bytes of data, this will be 292 full can lines plus 1 last line with the remainder 4 bytes.
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 Deveopment Extravaganza

Post by Tazzi »

Hmmm... I know I have done this work before but it seems to be missing
@Antus, I believe when we did the CRC work we had written down where to extract the calibration locations inside the bin although for the life of me cant find it on the PC, Im just wanting to identify what locations are cal only and what is OS. Then hopefully I can tinker with a 'not so' important cal only area.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
kostia111
Posts: 47
Joined: Mon Oct 21, 2019 4:58 am

Re: GM E38 Kernel/Bootloader Deveopment Extravaganza

Post by kostia111 »

open the dump you read
from address 0x10000
there is a heading
it clearly shows at what addresses software is loaded
and calibration
as well as addresses regarding which control addresses are considered
sum of blocks and cvn


when is programming
after loading the kernel
this header is loaded first
specifically in your case, its length is 0x800
the core takes it apart
and now knows what will be loaded and at what addresses

I know until bit the whole script for programming any block GM
I often have to fix them in order to bypass some checks or download all the software and not just calibrations with matching numbers, etc.
if interested, we can talk about it
Attachments
e38-1.JPG
e38-1.JPG (89.12 KiB) Viewed 5129 times
Last edited by kostia111 on Sat Feb 08, 2020 8:39 pm, edited 1 time in total.
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 Deveopment Extravaganza

Post by Tazzi »

kostia111 wrote:open the dump you read
from address 0x10000
there is a heading
it clearly shows at what addresses software is loaded
and calibration
as well as addresses regarding which control addresses are considered
sum of blocks and cvn
Ahhhhh so I was kinda right with what the internal kernel was doing
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
kostia111
Posts: 47
Joined: Mon Oct 21, 2019 4:58 am

Re: GM E38 Kernel/Bootloader Deveopment Extravaganza

Post by kostia111 »

look at the log
at the beginning of this topic
after loading the kernel
header loaded first
and then the software file was downloaded
but from the very beginning again including the title
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 Deveopment Extravaganza

Post by Tazzi »

01001E-F = CRC (OS)
1C001E-F = CRC
1C136E-F = CRC
1C3592-3 = CRC
1C3936-7 = CRC
1CD392-3 = CRC
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
kostia111
Posts: 47
Joined: Mon Oct 21, 2019 4:58 am

Re: GM E38 Kernel/Bootloader Deveopment Extravaganza

Post by kostia111 »

there is the same heading
and slave processor files
only addressing will be two byte
and the title itself will be shorter
I think 0x80
Post Reply