GitHub repo for XDFs

They go by many names, P01, P59, VPW, '0411 etc. Also covering E38 and newer here.
In-Tech
Posts: 787
Joined: Mon Mar 09, 2020 4:35 pm
Location: California

Re: GitHub repo for XDFs

Post by In-Tech »

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 :think:

I grabbed and edited these pics off of http://WWW.LT1SWAP.COM and added notes to the pics.
12586243 GTO_1_B.JPG
12586243 GTO_1_B.JPG (136.29 KiB) Viewed 5532 times
12586243 GTO_2_B.JPG
12586243 GTO_2_B.JPG (161.15 KiB) Viewed 5532 times
12586243_GTO_3_B.JPG
12586243_GTO_3_B.JPG (78.77 KiB) Viewed 5532 times
12586242_1_B.JPG
12586242_1_B.JPG (88.56 KiB) Viewed 5532 times
12586242_2_B.JPG
12586242_2_B.JPG (142.18 KiB) Viewed 5532 times
12586242_3_B.JPG
12586242_3_B.JPG (78.32 KiB) Viewed 5532 times
User avatar
antus
Site Admin
Posts: 8250
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: GitHub repo for XDFs

Post by antus »

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.
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
User avatar
NSFW
Posts: 679
Joined: Fri Feb 02, 2018 3:13 pm

Re: GitHub repo for XDFs

Post by NSFW »

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. :)
AmdFlashBytes.png
AmdFlashBytes.png (8.76 KiB) Viewed 5498 times
Please don't PM me with technical questions - start a thread instead, and send me a link to it. That way I can answer in public, and help other people who have the same question. Thanks!
User avatar
Gampy
Posts: 2333
Joined: Sat Dec 15, 2018 7:38 am

Re: GitHub repo for XDFs

Post by Gampy »

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 ...
Intelligence is in the details!

It is easier not to learn bad habits, then it is to break them!

If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
RoninDusette
Posts: 23
Joined: Thu Oct 25, 2018 8:06 am
cars: 2015 Chevy Cruze LT (Trifecta, CAI, lowered)
1991 Honda CRX Si (gutted, waiting for love)
2004 Ford Focus SE
2015 Chevy Malibu
2002 Saturn SL

Re: GitHub repo for XDFs

Post by RoninDusette »

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.
User avatar
Gampy
Posts: 2333
Joined: Sat Dec 15, 2018 7:38 am

Re: GitHub repo for XDFs

Post by Gampy »

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
Intelligence is in the details!

It is easier not to learn bad habits, then it is to break them!

If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
User avatar
NSFW
Posts: 679
Joined: Fri Feb 02, 2018 3:13 pm

Re: GitHub repo for XDFs

Post by NSFW »

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.
Please don't PM me with technical questions - start a thread instead, and send me a link to it. That way I can answer in public, and help other people who have the same question. Thanks!
User avatar
Gampy
Posts: 2333
Joined: Sat Dec 15, 2018 7:38 am

Re: GitHub repo for XDFs

Post by Gampy »

NSFW wrote:Moving it into XML is fine too.
Umm, That was a hint to you ... Me no got the skills! :oops:
Intelligence is in the details!

It is easier not to learn bad habits, then it is to break them!

If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
In-Tech
Posts: 787
Joined: Mon Mar 09, 2020 4:35 pm
Location: California

Re: GitHub repo for XDFs

Post by In-Tech »

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 ?
User avatar
Gampy
Posts: 2333
Joined: Sat Dec 15, 2018 7:38 am

Re: GitHub repo for XDFs

Post by Gampy »

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!
Intelligence is in the details!

It is easier not to learn bad habits, then it is to break them!

If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
Post Reply