More of a curiosity really, as it is what it is, but any M68k gurus that have any insights into this:
An E38 MPC561 seems to have a pretty "linear"/continuous use of flash memory - i.e.:
BOOT 56k
NVM 8k
OS 1768k
CALS 262k
Whereas the M68k ECU's seem to be more of all over the place relatively. Any ideas as to why? GM driven? Product of how the tool chain/compiler works?
e.g.:
E40 - 68377
BOOT_1 0x00000 Size>0x4000
NVM 0x4000 Size 0x4000
OS_2 0x8000 Size 0x17E90
OS_1 0x1FE90 Size 0x170 ("OS_1" as OS ID Located in this small block)
CALS 0x20000 Size 0x20000
OS_3 0x40000 Size 0xC0000
T42 - 68375
BOOT_1 0x00000 Size 0x4000
NVM 0x4000 Size 0x4000
OS_2 0x8000 Size 0x8000
OS_1 0x10000 Size 0x10000 (OS ID here)
CALS 0x20000 Size 0x20000
OS_2 0x40000 Size 0x70000
E40 Slave - M68F375
Similar to above but with 4 blocks of OS (1,2,3,4) & a cal block between OS 2 & OS 3.
Thanks anyone if any ideas.
M68k Memory Map Fragmentation
-
MPC001
- Posts: 174
- Joined: Sat May 05, 2018 11:41 am
M68k Memory Map Fragmentation
Last edited by MPC001 on Thu Oct 02, 2025 4:55 am, edited 4 times in total.
-
antus
- Site Admin
- Posts: 10014
- Joined: Sat Feb 28, 2009 10:34 am
- cars: TX Gemini 2L Twincam 8psi
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Subaru WRX 2007
Re: M68k Memory Fragmentation
M68k, from what I've gathered pulling them apart and the checksum blocks across different versions it seems too be early ones they just threw it all in there, one giant logical block. Then they improved to an era where they sized the blocks to fit the sectors on the flash memory, as provided by the memory manufacturer. Then I guess they wanted more flexibility, as well as some calibration blocks are a lot smaller that the hardware sectors, like system or speedo sector, so they put an index in the bin early towards that start that defined where the calibration blocks where in the memory. This gave them the ultimate flexibility, and in general across all of these PCMs except the very early ones you can always think about in terms of calibration sectors, not bins. Eventually they're not contiguous as well, and not on just one flash chip and then you need some other kind of format for data on the PC that can have multiple sectors in it. Either multiple bin files and some kind of memory map file to spell out what goes where, or bundle it all up more like an archive with the metadata also in it like most the aftermarket tool vendors do.
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
-
AngelMarc
- Posts: 612
- Joined: Sat Apr 08, 2023 11:23 am
- cars: A CB450 running to 8,000RPM with a P59.
Re: M68k Memory Fragmentation
Pretty sure it's just because flash blocks, but I know way less than others here about that.
Check the datasheet for the flash and see what you think.
Check the datasheet for the flash and see what you think.
Don't stress specific units.
-
antus
- Site Admin
- Posts: 10014
- Joined: Sat Feb 28, 2009 10:34 am
- cars: TX Gemini 2L Twincam 8psi
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Subaru WRX 2007
Re: M68k Memory Fragmentation
I think what he's talking about is P59 / P12 and so on where they have an index that defines the start and end of the segments. Yes, the flash partitions are used to make sure the segements are in sensible places and to support flashing boot/param/calibration/operating system seperately from each other, but then within calibration you have engine/engine diag/trans/trans diag/speedo/system all separately with indexes in the bin to define start and end. Enample (P12) : https://github.com/PcmHammer/PcmHammer/ ... or.cs#L634
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
-
MPC001
- Posts: 174
- Joined: Sat May 05, 2018 11:41 am
Re: M68k Memory Fragmentation
Thanks Antus & Marc for the replies.
Possibly a combination of the index header in the OS pointing to the calibration segment addresses which yes need to observe flash block boundaries & why the calibration segments collectively in an E40/T42 are a round 0x20000 & E38/E67 a round 0x40000 (for example), but also how the OS can be split into 2 or 3 blocks but the entire 1 or 2 meg flash can be written all in one sweep or block by block - flash boundaries observed that is - like 0x4000 NVM block, or NVM 0x2000 x 2.
Must take another look & confirm end of segment signatures are where I am assuming
or each block of OS has a end of seg sig.
IIRC also, the checksum & CRC 16 in the OS takes into account the two or three discontiguous blocks of the total OS.
Possibly a combination of the index header in the OS pointing to the calibration segment addresses which yes need to observe flash block boundaries & why the calibration segments collectively in an E40/T42 are a round 0x20000 & E38/E67 a round 0x40000 (for example), but also how the OS can be split into 2 or 3 blocks but the entire 1 or 2 meg flash can be written all in one sweep or block by block - flash boundaries observed that is - like 0x4000 NVM block, or NVM 0x2000 x 2.
Must take another look & confirm end of segment signatures are where I am assuming
IIRC also, the checksum & CRC 16 in the OS takes into account the two or three discontiguous blocks of the total OS.
-
antus
- Site Admin
- Posts: 10014
- Joined: Sat Feb 28, 2009 10:34 am
- cars: TX Gemini 2L Twincam 8psi
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Subaru WRX 2007
Re: M68k Memory Fragmentation
Yes, You wont find operating system/calibration/param blocks overlapping the same blocks, so that they can be re-written without affecting others. Except in 1990s OS before somewhere around 1998 where they did not have the design maturity and just put it all in one giant block without using the flash hardware design features.
You also wont see them put speedo block to line up with a flash partition on its own because they're too small and its too wasteful. For example I just opened a 2005 Commodore Ute P59 bin and see speedometer starts at 1FEE2 and ends at 1FFCF. 1FFCF-1FEE2 means its only ED aka 237 bytes long. To allocate a 32Kb flash partition just for that wastes a lot of space. I would assume they are thinking, that usually when a car comes in to a shop for a calibration upgrade, they might as well do all calibrations in one hit so it makes sense to choose smaller flash chips over a larger chip at higher cost with more wastage to solve a problem that doesn't really exist. The flash chip can handle more re-writes than the car is likely to need to need for calibration updates at the service center over its operational life.
You also wont see them put speedo block to line up with a flash partition on its own because they're too small and its too wasteful. For example I just opened a 2005 Commodore Ute P59 bin and see speedometer starts at 1FEE2 and ends at 1FFCF. 1FFCF-1FEE2 means its only ED aka 237 bytes long. To allocate a 32Kb flash partition just for that wastes a lot of space. I would assume they are thinking, that usually when a car comes in to a shop for a calibration upgrade, they might as well do all calibrations in one hit so it makes sense to choose smaller flash chips over a larger chip at higher cost with more wastage to solve a problem that doesn't really exist. The flash chip can handle more re-writes than the car is likely to need to need for calibration updates at the service center over its operational life.
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
-
MPC001
- Posts: 174
- Joined: Sat May 05, 2018 11:41 am
Re: M68k Memory Fragmentation
I thought it might be clearer with a memory map image to outline an E40 (fragmented OS) vs E38 (E67) comparison:
For E40:
OS1 has the OS ID & memory map lookup table & Checksum/CVN values
OS2 starts with the jump table but precedes OS1
OS3 carries on from OS2 (and has a legacy/old ID at the start)
Checksum & CVN (CRC) calculated across OS2 > OS1 > OS3 as a single contiguous block (bar their values except Checksum once CVN is calc'd.
For E40:
OS1 has the OS ID & memory map lookup table & Checksum/CVN values
OS2 starts with the jump table but precedes OS1
OS3 carries on from OS2 (and has a legacy/old ID at the start)
Checksum & CVN (CRC) calculated across OS2 > OS1 > OS3 as a single contiguous block (bar their values except Checksum once CVN is calc'd.
You do not have the required permissions to view the files attached to this post.
Last edited by MPC001 on Mon Sep 29, 2025 9:30 am, edited 1 time in total.
-
MPC001
- Posts: 174
- Joined: Sat May 05, 2018 11:41 am
Re: M68k Memory Fragmentation
Understood on no overlaps. Hence the cal block overall is a single 0x20000 E40, 0x40000 E38/E67, with System, Speedo, Fuel, Diagnostics & Engine segs in each.antus wrote: Mon Sep 22, 2025 7:43 am Yes, You wont find operating system/calibration/param blocks overlapping the same blocks, so that they can be re-written without affecting others. Except in 1990s OS before somewhere around 1998 where they did not have the design maturity and just put it all in one giant block without using the flash hardware design features.
You also wont see them put speedo block to line up with a flash partition on its own because they're too small and its too wasteful. For example I just opened a 2005 Commodore Ute P59 bin and see speedometer starts at 1FEE2 and ends at 1FFCF. 1FFCF-1FEE2 means its only ED aka 237 bytes long. To allocate a 32Kb flash partition just for that wastes a lot of space. I would assume they are thinking, that usually when a car comes in to a shop for a calibration upgrade, they might as well do all calibrations in one hit so it makes sense to choose smaller flash chips over a larger chip at higher cost with more wastage to solve a problem that doesn't really exist. The flash chip can handle more re-writes than the car is likely to need to need for calibration updates at the service center over its operational life.