GitHub repo for XDFs
Re: GitHub repo for XDFs
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.
I grabbed and edited these pics off of http://WWW.LT1SWAP.COM and added notes to the pics.
- 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
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
Re: GitHub repo for XDFs
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.
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.
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!
Re: GitHub repo for XDFs
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 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!
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!
-
- 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
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.
Re: GitHub repo for XDFs
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
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!
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!
Re: GitHub repo for XDFs
I'm not sure it's worthwhile either, I'm just thinking out loud here.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 ...
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!
Re: GitHub repo for XDFs
Umm, That was a hint to you ... Me no got the skills!NSFW wrote:Moving it into XML is fine too.
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!
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!
Re: GitHub repo for XDFs
Thanks for that, I missed it when you posted. The Read Properties works great for PCM's with the factory sticker removed.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.
[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 ?
Re: GitHub repo for XDFs
I'm not confident in answering that so I'll leave it to someone else.In-Tech wrote:What is MEC: 0 ?
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!
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!