PCM Hammer E38

[antus]

I guess PCM because its the name of the tool, but its a good point. But I am also thinking about editors, and if I try to create an open standard that other apps can use. I don't see any open format that would suit what is needed has been created out there so far so it'd be a first for open tuning. Also it does not need to be a 3 character extension, it could be .pcmhammer but it doesn't matter so long as it doesn't clash with an existing product. The more I think about it, the container is a pain. Nothing can edit it, and you still have to rename to a zip to get anything in or out. So the value of 'z' in the extension is nothing. Now I am thinking of changing the application so it has the concept of an image loaded, like a document. So instead of prompting for a file when you click read or write, the workflow is you load the file, then you write the file to the pcm. That takes the app in the direction of the possibility of having more tools built in. It could have a binary import or export, and potentially a segment import and export too. So someone could read a pcm, save the .phz (or whatever) it stays loaded in the app, then they can export -> to bin -> main flash and edit that bin in whatever tools, then import -> from bin -> main flash back in to the image and write it. pcm hammer could do all the file i/o so it does not get confusing for users, other than the concept that they have to do something extra to get a file that they can edit. Still could maybe submit a patch to UP to handle the format natively, and see if Mark has any interest in putting it in tuner pro. This might mean its time to re-think all of the menus so that it stays (or becomes) well organised and clear what is what. Could maybe optionally start putting basic tools like vats off by platform in to it, so it can do basic operations, though that is starting to move in the direction of universal patcher and isn't the immediate problem to be worked though.

[kur4o]

Since slave is not going to be read but, taken externally, the simplest method will work best.

Make a database with all e38 slave and cal you can find. Before reading main flash, read slave pn, after read is done stitch slave files from database to end of main bin, using strict offset format, rename .bin to .e38bin or something, so it is identified easily.

If bootblock of slave can be read than you can export, import full slave from main bin, for editing with some basic checks for p/n match and checksum match.

[antus]

I did consider that, but I do not think it is a clean solution. It will work for editing e38 bins, but it will break anything that uses size as part of the detection for filetype (including pcm hammer itself, which does this) and potentially any app that anchors any lookups to the end of the file. It would work with start of file anchors so long at the additional data is not referenced. But, it will mean code smells where code needs to be aware of both sizes and so on. That might be acceptable if that was where it ended, but I plan to take this method forward to more modern pcms later that could have multiple flash chips, not just generally non-user editable slave/slave cal or eeproms. So then to edit those ones the editor still needs to be aware of the offset. So I think the flat file will not cover the future direction, and then will need another format again, which is too many file formats. I have a first POC working, still phz at the moment that supports a combination of phz and bin support, and bin import and export. I am trying to think through what works the best and is not confusing for users.

[antus]

I have decided to hide import, as its an advanced option and makes it possible for people to make bad images. But power users will want to use it. So there is not setting to turn on import for the session only, and it is otherwise hidden. For most people export, then load the bin will be enough and never touch the slave. This should keep more files shared on the net healthy with the right slaves included.

I am also thinking the UI something like this makes sense. Here I load a phz file, export its contents, turn on the import, and then on replace for the slave os, and attempt to load the slave cal, which is rejected on mis-matched size. I think this is heading in the right direction. Powerful, but still logical for basic use cases.

Also wondering if I track the source. So if it was read from a PCM its more likely to be correct than an import. But then there is no guarantee the pcm read was a working pcm, and maybe only advanced users will import bins and they are using working combinations more often than not, so leaning towards tracking source is meaningless and will add complexity and confusion rather than reduce it.

[AngelMarc]

As long as I can unpack it, to see raw binaries. And .zip is ubiquitous. Should be easy enough for other apps to support that, even under a different name.
And, did I miss something? Where you're at now is just avoiding slave read, because you (as far as you know so far) are required to erase master, and that's more of a bricking risk. Correct? Sounds pretty good to me. I want the full reads, for sure, especially when you move to E67 support.

As a side not, apparently Chrysler PCI (like NGC3) is just VPW with different formatting, shorter address packets or something. Just wanted to throw that out there.

[antus]

I havn't been able to get the slave in to mode where it'll accept and run my code, not even as a hijack. To implement write I had to let the boot sector drive the process factory style and could not modify the process at all. So have not found a way to get code execution on the slave to add read.

As above you can save to bin and load bin (which looses metadata about slave, so then you can never write the slave), or save to phz, and load phz, which means you do get that metadata and can clone to a PCM that started with a different slave or slave config. And you can export to bin, and choose which files to export. It can be the main bin, or the slave bins. And there is a slightly hidden away import to load slave bins file file in to your phz but that is just there for power users and is designed to be less obvious so people who don't understand dont make phz files that are mismatched. And then the thing is a zip with a json file with metadata anyway, so you can always rename to zip and go in by hand and do whatever you want.

[AngelMarc]

Oh, so just BDM/JTAG for now. K.

[antus]

Not really BDM either, because that reads the whole chip, and factory style flash does not write the whole chip, so we accept factory bins only, not BDM. But the known ones are in the app, so you get them for free if you know the calibration number. You just export them (even though they are not in the zip) and it'll copy it out, so all of a sudden you do have the right file in hand.

[MPC001]

More testing required, but if anyone knows what limitations people hit when cross flashing between 2006-2007, 2008, 2009 and 2010+ E38s, I would like to know.

Have never experienced any limitations as long as the param block matches the OS (& it's use of SRAM), but the ECM must be cold booted/full power cycle so SRAM is initialized & the boot then reads the param block data. Power cycle can be avoided with the right type of reset.

No key off key on cycles or as you know the SRAM data is written to the param block and if it's a different format for a different year OS then voila corruption.

[antus]

Seem to have param block sorted, just erase sram on kernel load. challenge is arbitary code execution on slave. But can write it without, just can implement read.