pcmhacking.net

I'll just open them up and check for myself for drivers and chip type. I haven't been able to try PcmHammer yet till I get back to the shop tomorrow and use my Win7 machine. Does PcmHammer have a check utility to let you know what the saved file type is regarding Intel and AMD? Also does it have a utility to check the hardware without having to open up the case during in car programming? I wonder how BinBuilder would work if you mismatch stuff? Just thinking outloud

I grabbed and edited these pics off of http://WWW.LT1SWAP.COM and added notes to the pics.

Thats right about intel only os on amd hardware. Since the flash kernel is part of pcmhammer, not the os, you can still flash your way out of it back to an amd os.

A test write will print out the ID of the flash chip, so you won't have to open the PCM.
However the app can't tell whether a .bin file contains code for for Intel or AMD chips.

We might be able to add that ability, by looking for some magic numbers in a region of the .bin file, but I don't know how reliable that would be. For example the AMD flash code writes the values AAAA, 5555, 8080, AAAA, 5555, to command registers, so if we find those close together that would probably indicate an AMD operating system. Intel uses 5050, 2020, D0D0. It's possible we could find those values close together in unrelated code or data, but it doesn't seem very likely.

I put some AMD flash code below, for example. I don't think the values in between the magic numbers (38 BC, 32 BC, etc) are always going to be the same, as they're just write-to-memory instructions and there are different ways to write to memory, so to find AMD flash code we'd have to search for the magic numbers separated by two (maybe four?) arbitrary bytes, or something like that. It seems kind of wishy-washy but it might work. Or it might not. Or it might mostly work but still fail due to quirks I haven't thought of. I dunno, but it's an idea.

Obviously it would have to be a literal search not just a lookup for the addresses will be different.

I wonder if it's worth it.

For what it's worth, in my opinion it is not necessary at this point in time, maybe later if a conflict is found.

How about via Pcminfo with a osChipType.

Speaking of PcmInfo, I have been thinking about this, how about using xml for PcmInfo??
Thus PcmInfo could be changed without recompile ...

I have a few computers and am willing to take photos, post stock bins/info, and xdfs if I can figure that part out. Is there already a repo? If so, I probably already have something to contribute.

I collect bins that are relatively suspected to be OEM burns ... Meaning I don't want it, if it's been modified.

Post it or PM it ...

Thanks

Gampy wrote:Obviously it would have to be a literal search not just a lookup for the addresses will be different.

I wonder if it's worth it.

For what it's worth, in my opinion it is not necessary at this point in time, maybe later if a conflict is found.

How about via Pcminfo with a osChipType.

Speaking of PcmInfo, I have been thinking about this, how about using xml for PcmInfo??
Thus PcmInfo could be changed without recompile ...

I'm not sure it's worthwhile either, I'm just thinking out loud here.

The only drawback to putting more properties into the PcmInfo class is that someone would need to take the time to figure out what the right values are for all of the OSIDs that we know of.

Moving it into XML is fine too. If you do, consider making ImageSize be in kilobytes, that would be a little easier to work with.

NSFW wrote:Moving it into XML is fine too.

Umm, That was a hint to you ... Me no got the skills!

NSFW wrote:A test write will print out the ID of the flash chip, so you won't have to open the PCM.
However the app can't tell whether a .bin file contains code for for Intel or AMD chips.

Thanks for that, I missed it when you posted. The Read Properties works great for PCM's with the factory sticker removed.
[01:39:26:902] PCM Hammer 012
[01:39:27:198] AVT 852 Reset OK
[01:39:27:198] AVT Firmware 1.1
[01:39:27:588] Thanks for using PCM Hammer.
[01:39:34:592] VIN: 1GNEK13Z34J235452
[01:39:34:686] OS ID: 12587603
[01:39:34:764] Calibration ID: 12587672
[01:39:34:842] Hardware ID: 12583660
[01:39:34:998] Serial Number: 1LA0PQL34037
[01:39:35:092] Broad Cast Code: YFXL
[01:39:35:185] MEC: 0

What is MEC: 0 ?

In-Tech wrote:What is MEC: 0 ?

I'm not confident in answering that so I'll leave it to someone else.

Remember, the 'Read Properties' information goes with the .bin, not the hardware. thus a write can change it ...

The only positive way to keep the original info is to engrave it on the unit!