E92 PCM Reverse Engineering

[fl0wl0w]

I put together a kernel that can so far read. haven't tried writing yet. It conforms more to the UDS spec rather than the GM flavor. I thought i would share some of my findings.

The bootloader does in fact have a couple of watchdogs that it has to service. There is the core watchdog and also an external watchdog that is fiddled over SPI. Luckily for your kernel endeavors, these are both serviced in the EMIOS11 interrupt that points back to the bootloader as long as you don't try and change the INTC vector table location. That is the only INTC interrupt the bootloader configures, so as long as you implement that, you can get interrupts working for your kernel. Although leaving those out makes the kernel way smaller because the interrupt vector table is huge(7680 bytes for hardware interrupt dispatcher, 1440 bytes for software interrupt dispatcher through IVOR4). I still need to actually setup the EMIOS in my kernel instead of relying on the bootloader to do it. Doing so would mean the kernel would work from bootpin mode as well. If you disabled interrupts altogether and triggered the watchdogs manually that is also an option.

I implemented the UDS compression option using LZ4 in my kernel which just about doubles the read rate. 51.5KBps average and can read out all 4MB in just 1:21. The biggest thing i am not happy about with my kernel right now is it is so big (65KB!) I think alot of that is down to reusing some C++ libraries I had made for another project along with its use of std libraries. It's not too big of an issue with E92 and its massive 256KB of SRAM, but I do want to move to an E78 later for PFI.
https://github.com/FL0WL0W/KernelMPC5674F

My eventual goal is to do a lot more than just a Kernel. I plan to map out all of the gpio pins for e78 and their functions and get this fully integrated with my EmbeddedIOServices repo and run my EFIGenie project on it as well as use it as just a robust arduino of sorts.

[morfi]

That's big @fl0wl0w ! Thanks for sharing it. I'll soon be working on a blind spot module that is also MPC56xx based and any tips on what GM might have put in the bootloader is super helpful.

"as long as you don't try and change the INTC vector table location" -- do you get that for free with a C-runtime kernel (crt0 leaves IVPR / the INTC vector base pointing at the bootloader's table) or did you have to patch your startup so it doesn't repoint them?

the watchdog-over-SPI part -- did you infer that solely from the boot code or did you do some PCB probing too?

[antus]

I've been looking at the E38 one, and it sounds very similar. Boot loader runs the process, app uploads a lib with an erase function and a program function, and it starts with 2 pointers, one to each function. It sounds like this style carries through for quite a while up to e92 and possibly more. There is also a type byte, of 00 or 01 which tells it if the payload lib is for the master or slave.

[morfi]

I've been looking at the E38 one, and it sounds very similar. Boot loader runs the process, app uploads a lib with an erase function and a program function, and it starts with 2 pointers, one to each function. It sounds like this style carries through for quite a while up to e92 and possibly more. There is also a type byte, of 00 or 01 which tells it if the payload lib is for the master or slave.

so it stops at $3600 I assume and doesnt do $3680 like it would with a kernel that takes over the main loop?

[fl0wl0w]

"as long as you don't try and change the INTC vector table location" -- do you get that for free with a C-runtime kernel (crt0 leaves IVPR / the INTC vector base pointing at the bootloader's table) or did you have to patch your startup so it doesn't repoint them?

the default project from NXP didn't have any of the interrupts setup in the startup ASM. They setup the software interrupt dispatcher and it was mostly done in c. I added a bunch of stuff to my startup asm to actually enable the interrupts and send them to a few handlers. My Kernel is using interrupts for the EMIOS interrupt and the CAN RXFIFO interrups.

the watchdog-over-SPI part -- did you infer that solely from the boot code or did you do some PCB probing too?

I inferred this soley through the boot code as well as testing. I first tried making the kernel have interrupts without reimplementing the spi payload, but without those being sent the MPC would reset. Luckily the spi stuff is pretty simple. i just copied whatever GM was sending in their bootloader. However, I have no idea what the messages mean or do other than keep the watchdog from resetting the MPC. I've heard people say that the companion processor does things for IMMO, or is a GPIO expander of sorts and possibly gets code updates when doing SPS flashing, but I haven't found any evidence of that in disassembly yet, but i also haven't looked very hard. I do know the bootloader sends a slightly different payload than the bootloader.

I've been looking at the E38 one, and it sounds very similar. Boot loader runs the process, app uploads a lib with an erase function and a program function, and it starts with 2 pointers, one to each function. It sounds like this style carries through for quite a while up to e92 and possibly more. There is also a type byte, of 00 or 01 which tells it if the payload lib is for the master or slave.

I wouldn't doubt that they are nearly all the same protocol and setup. Maybe they changed in Global B? But i would bet everything GM made with the MPC line of stuff has this same bootloader structure. This is likely the way they would upload calibration changes during late development when the ECU is already in the car. uploading a lib is faster than a full kernel and if you don't need to read and just need to upload flash changes, this is the most straight forward way to do it.

so it stops at $3600 I assume and doesnt do $3680 like it would with a kernel that takes over the main loop?

yes

[antus]

Thanks for shareing. This has been helpful in understanding the E92. I was actually going to add E39a to PCM Hammer first but it turned out my E39a was DOA. In testing I pulled out an E92 I had on hand since it had the same connector/bench pinouts, which I was not planning to add to PCM Hammer yet, but it lit up as soon as I plugged it in with the bench loom I was testing, so kept going. This is not production ready yet, also only read at this point in time but so far, so good. Thanks to the Universal Patcher guys for mapping out the file format too.

[10:14:44.587] Loaded DLL
[10:14:44.601] Thanks for using PCM Hammer.
[10:14:46.236] Connected to the device.
[10:14:46.265] Battery Voltage is: 13.472
[10:19:09.570] Detected PCM on Can500k
[10:19:09.570] PCM Identification:
[10:19:09.570] OSID: 12691156
[10:19:09.570] VIN: 1GCNCNEC1JZ104992
[10:19:09.570] Traceability (MTC): 1117177109907B8R
[10:19:09.570] SWMI 01: 12691156
[10:19:09.570] SWMI 02: 12675364
[10:19:09.570] SWMI 03: 12675313
[10:19:09.570] SWMI 04: 12675457
[10:19:09.570] SWMI 05: 12686582
[10:19:09.570] SWMI 06: 12686263
[10:19:09.570] SWMI 09: 12667480
[10:19:09.570] SWMI 10: 12675190
[10:19:09.570] End Model P/N: 12686027
[10:19:11.542] Detecting PCM...
[10:19:11.549] Detected E92 on Can500k
[10:19:13.887] Slave module slave-os: 12667480
[10:19:13.892] Slave module slave-calibration: 12675190
[10:19:13.908] Security seed: B1498F1A06
[10:19:13.908] Using saved key for this seed.
[10:19:13.919] Unlock succeeded.
[10:19:13.931] Loaded Kernel-E92.bin (2388 bytes)
[10:19:13.932] Kernel MD5=3A17B61A472CB38AEF1B99C34458F499
[10:19:13.958] Requesting programming mode.
[10:19:17.021] Kernel upload 14% complete.
[10:19:17.139] Kernel upload 100% complete.
[10:19:17.139] Kernel uploaded to PCM successfully.
[10:19:17.450] Kernel version: 2026-08-22 15:07:21 PCM=0x92
[10:19:17.460] Flash chip: Freescale MPC5674F on-chip flash, 4096KiB
[10:19:17.460] Reading 4096 KiB...
[10:22:10.637] Read complete.
[10:22:10.637] Elapsed time 00:02:53.1774639
[10:22:10.640] Identifying 4096KiB file.
[10:22:11.039] Validating 4MB file.
[10:22:11.039] Checksum validation:
[10:22:11.039] Segment Checksum 1 Checksum 2
[10:22:11.039] OS 5783 OK 941A OK
[10:22:11.040] System CE0D OK B2C6 OK
[10:22:11.040] Fuel 3F27 OK 6B8D OK
[10:22:11.040] Speedo C25C OK 4048 OK
[10:22:11.040] EngineDiag 0086 OK 91B9 OK
[10:22:11.040] Engine F8F3 OK DE34 OK
[10:22:11.040] Boot Block FFFF n/a FFFF n/a
[10:22:11.040] SYSSPD ext FFFAECA7 OK FFF8209D OK
[10:22:11.040] ENG extra 1 F576275F OK F59F83B1 OK
[10:22:11.040] ENG extra 2 EC2CF15E OK -
[10:22:11.040] CVN validation:
[10:22:11.040] Segment CVN Verdict
[10:22:11.040] OS 5783 Good
[10:22:11.040] System CE0D Good
[10:22:11.040] Fuel 3F27 Good
[10:22:11.040] Speedo C25C Good
[10:22:11.040] EngineDiag 0086 Good
[10:22:11.040] Engine F8F3 Good
[10:22:11.040] Boot Block FFFF n/a
[10:22:11.040] All checksums are valid.
[10:22:11.040] File operating system ID: 12691156
[10:22:11.041] Returning to normal mode.
[10:22:11.044] Clearing trouble codes.
[10:22:11.583] Elapsed time 00:02:57.6648553
[10:22:22.295] Saved E92_12691156_20260823_1.phz

[gixxer92]

Hey everyone, I’ve been lurking here for a bit and wanted to contribute something back after learning from the work and open discussion here.
I’ve been working with a spare 2017 E92 and comparing the software from a 2017 L86/8-speed setup with a 2018 L86/10-speed setup.
AI has been helping me write tools, examine the files, and organize the findings. I’m still learning this side of things, so I’d appreciate people checking the work and pointing out anything we’ve misunderstood.
So far, I have a few things to contribute:
- Repeatable bench reads using a Macchina M2 with changes built around PCM Hammer.
- Scripts and notes that help locate the code handling messages between the engine computer and other modules.
- Comparisons showing where similar functions appear in the two operating systems.
- A read limitation worth highlighting: our current method fills the first 256 KB with FF rather than actually reading those bytes.
I'm still breaking the bins down into mapped areas and working out what the individual values mean. Both project calibrations have been modified, so I’m keeping that distinction clear.
I’m putting together the checked notes and scripts to share. Some findings still need confirmation against recordings from running vehicles, and help with that would be appreciated.
Thanks to everyone who has shared their knowledge and tools, it’s what made getting this far possible.
I hope this helps us all!

[antus]

The FFs are because thats the boot sector and its locked out for read. If you can find a way to make it accessible again from a booted system that would be great. But so far I dont think there is a way other than jtag with the shadow password.

[fl0wl0w]

The FFs are because thats the boot sector and its locked out for read. If you can find a way to make it accessible again from a booted system that would be great. But so far I dont think there is a way other than jtag with the shadow password.

I've read it out no issue. you have to avoid a couple small areas at the end of emulated eeprom space as they have bad ecc and will crash your kernel if you try to read them. otherwise you can read and write the whole boot sector.

The following flash doublewords are not accessed because they are not backed by valid ECC data. Read, upload, and hash operations substitute FF for each byte in my kernel:
0x0001FFF8–0x0001FFFF
0x0002FFF8–0x0002FFFF

[antus]

That's interesting. I was able to read straight through but got back all FF from the hardware. No substitutions in software, no crash. That is also what I found in E38 trying to read slave. It looks to me like a common pattern. The boot vectors are at the start, and they do the hardware init, then I assume jump to the main OS which then locks out the boot sector. Or so I thought. I wonder why yours is different.

You can test mine in pcmhammer develop branch code. https://github.com/PcmHammer/PcmHammer/ ... 2744260176