Colorado / H3 BCM hacking

[04colyZQ8]

hxd will work great for block checksum. It is 16 bit, byte sum from 4th byte of message till end of data.

Most modules have special write sequence to eeprom, On power down it checks for changes and write to eeprom new data, comparing it from some virtual eeprom stored in RAM.

Yes something like that:) in this the eeprom can be written to at any point and instantly shows the change … that is the copy in the ram. However at key off/on it corrects it from the actual EEPROM.

There is a function that they use to write the actual EEPROM, you send the location in ram, and the number of bytes you changed and call it. Then the changes stick after key/off on.

My intent upload new eeprom image to ram, send instructions via 36 80, call factory function to write the entire EEPROM

[kur4o]

Plan looks solid, hope there is no limits in uploading to specific ram addresses, than you can upload to other location,->copy to ram eeprom->execute factory code.

[04colyZQ8]

Plan looks solid, hope there is no limits in uploading to specific ram addresses, than you can upload to other location,->copy to ram eeprom->execute factory code.

The eeprom is small like 800kb I think? What’s the max size of bytes I can send via 1x? I’m not sure I want to tackle 4x mode yet?

[antus]

A few of my comments lately from earlier generations are being proven different with newer models, so I wont claim to be right, but for comparison the VPW 68k pcms from about 1999 when they implemented the parameter block use something similar. In those PCMs, the flash chip has two 'paramater' blocks as documented by Intel and AMD. They're copied to SRAM at boot, and the PCM works with the ram copy. When ignition is removed the PCM shutdown code runs, and the RAM copy is compared to the Flash copy. If they are different it'll use code in the OS to erase the flash and write it back from sram to persist it. Back in the very early days of flash tool development before pcmhammer and when it was just me on 'ls1flash' I was able to use an early iteration of my kernel to patch data in ram then jump to a known address for the shutdown procedure for an known OS. This was the first way I found I could use to update things in that parameter block, like seed/key on locked PCMs back to factory, without having flash functionality developed in my kernel. I think this space is often referred to as eeprom, but its not... its flash, with a working copy in sram. Not sure if your BCM is doing something like this or has a real eeprom. There is certainly precent by GM to use the above concept to 'emulate' a non-existant eeprom with a sector of flash. I believe they probably did this to cost cut needing the extra component, and work around issues with updating the data at runtime where it needs to be instant and they cant afford the time to erase and re-write a sector.

[04colyZQ8]

A few of my comments lately from earlier generations are being proven different with newer models, so I wont claim to be right, but for comparison the VPW 68k pcms from about 1999 when they implemented the parameter block use something similar. In those PCMs, the flash chip has two 'paramater' blocks as documented by Intel and AMD. They're copied to SRAM at boot, and the PCM works with the ram copy. When ignition is removed the PCM shutdown code runs, and the RAM copy is compared to the Flash copy. If they are different it'll use code in the OS to erase the flash and write it back from sram to persist it. Back in the very early days of flash tool development before pcmhammer and when it was just me on 'ls1flash' I was able to use an early iteration of my kernel to patch data in ram then jump to a known address for the shutdown procedure for an known OS. This was the first way I found I could use to update things in that parameter block, like seed/key on locked PCMs back to factory, without having flash functionality developed in my kernel. I think this space is often referred to as eeprom, but its not... its flash, with a working copy in sram. Not sure if your BCM is doing something like this or has a real eeprom. There is certainly precent by GM to use the above concept to 'emulate' a non-existant eeprom with a sector of flash. I believe they probably did this to cost cut needing the extra component, and work around issues with updating the data at runtime where it needs to be instant and they cant afford the time to erase and re-write a sector.

As always you are spot on! And this is great info! Yes think fortunately I do have an actual eeprom which is great if I screw if up I can just use a ch314a to fix it. It’s a 2c540 I think if the top of my head?

On another note how are these written and programmed at the os level? I’m assuming it would use cs, and oe, we and a gio from the main chip to communicate with it?

[antus]

in the pcms you dont need to control cs, oe directly. you do need to control 12v vpp. you write magic numbers to magic addresses to put the flash in to command mode (and loose read access to it while its in command mode, thus the pcm has to be in the right state and cpu running from ram). process is in the intel and amd flash data sheets. vpp control needs to be reverse engineered and changes between pcms. sometimes the vpp pin is ready to use, sometimes you have to configure it for output from the cpu first. Intel and amd use the same process to get the chip id, so the kernel can do that then go in to intel or amd mode at runtime. pcmhammer is unique in that its kernels send the chip id back to the pc and put it on the screen so you can see what chip it found.

[04colyZQ8]

hxd will work great for block checksum. It is 16 bit, byte sum from 4th byte of message till end of data.

Most modules have special write sequence to eeprom, On power down it checks for changes and write to eeprom new data, comparing it from some virtual eeprom stored in RAM.

So this is the message I want to send
6D 40 F0 36 80 00 0E 00 0B 82 B5 7F 48 01 25 FF 70 05 BD 7F 08 00 00 41 //mode 36 from tool to pc code 80 execute code 0e length I think?? Where and how does the checksum go on, and how to calculate it? I didn't see any checksums in the factory kernel (utility file)

This is the actual code I want to go into ram at address 8000b82 (3 byte addressing, cpu ads the rest) is 0x0b82:
B5 7F 48 01 25 FF 70 05 BD 7F 08 00 00 41

[04colyZQ8]

6D 40 F0 36 80 00 0E 00 0B 82 B5 7F 48 01 25 FF 70 05 BD 7F 08 00 00 41 05 B6
is this correct checksum is 05 B6 ??
and oe is the length of code? see bellow
B5 7F 48 01 25 FF 70 05 BD 7F 08 00 00 41

[kur4o]

6D 40 F0 36 80 00 0E 00 0B 82 B5 7F 48 01 25 FF 70 05 BD 7F 08 00 00 41 05 B6
is this correct checksum is 05 B6 ??
and oe is the length of code? see bellow
B5 7F 48 01 25 FF 70 05 BD 7F 08 00 00 41

You got that correct, now it is time to test on bcm.

[04colyZQ8]

6D 40 F0 36 80 00 0E 00 0B 82 B5 7F 48 01 25 FF 70 05 BD 7F 08 00 00 41 05 B6
is this correct checksum is 05 B6 ??
and oe is the length of code? see bellow
B5 7F 48 01 25 FF 70 05 BD 7F 08 00 00 41

You got that correct, now it is time to test on bcm.

No dice I’m 99% sure my arm assembly code is perfect unless you cannot jump from ram to main flash for functions. Was interesting had to use a 32 bit pointer and bx instruction that I never used I typically would use bl for jump to function but that is only -+ 32mb and because we are running from ram which is along ways from the main flash bl doesn’t work!

Anyway the checksum I’m confident with now. But still not sure weather this is supposed to run in 4x instead of 1x

I was using a universal patcher master script with j-console to send the same code the factory uses .. unlock ae etc.. now when I send my mode 36 I get a neg message or no message?

Send 6d 40 f0 36 80……..
Get 6d f0 40 36 18 22 //bad
Should be 74, 73 of 78 if I recall

If I have the utility file to send my kernel and run it in the “program ..” it shows correct 74, 73, or 78 response!

I think this is because the utility file is going from 1x to 4x mode.

How can I do this with script in universal master?

Tried:
Mode:4x
That didn’t work.

I have noticed typically 6d instead of 6c is 4x.

Otherwise I need to hack the utility file to send 36 80, I tried for hours putting 80 where zeros where and never got if to work. So even though it’s giving good response codes on that app it doesn’t matter since I can’t do 36 80 only 36 00