PCMHammer P04

[darkman5001]

Just so I am clear, do we need more testing for P10 and P12 for Gampy's new kernel? If so I'll get set up and do some testing.

[antus]

yes and no. they should work but from the problems we see on p04 and p08 intel routines may change again. what is in gampys pull request should build and write p10 and p12 and gampy is the only one to test those ones on his pcms so far.

[Gampy]

Yes, the P10, P12 and P12b need testing ... They use AMD chips and that is not likely to change, neither should the Intel Flash internal state machine handler code.
In reality, ALL units need testing, P01, P10, P12, P12b, P59 (Both AMD and Intel), and the E54.

You can get a prebuilt package here: PCMHammer Github Action Artifacts

The P08 is just another Intel AM28F400BB Flash Chip, the internal State Machine in it is no different then the others and it will work the same as the other Intel AB28F400BB Flash Chipped units as long as the Unlock/Setup code is correct!

Intel did NOT change the internal State Machine without changing the chip ID ... PERIOD!

-Enjoy

[kur4o]

All intel chips have some code sequence to enable vpp and than wait for a bit to set for some specific time. The usual method is set a vpp register,->wait in a loop and test another register for vpp status. When vpp status is OK->proceed -> if it doesn`t get OK for a specific time ->exit with an error.

Actually vpp induce heavy noise on bus and is enabled only when actual erase, write is done and than turned off, until next batch of data is written.

[darkman5001]

Ok, so far, I tested a P04, P10, P12 and P12b. Pay no attention to volts in the logs. My MDI2 is plugged into a GoDiab GT100+ and the PCM power is connected directly to a lab power supply. I used the test version of PCM Hammer posted at viewtopic.php?f=42&t=8300. The P04, P10 and P12b seemed to do successful reads however the 1mb p12 did not. PCMs that I read successfully, I used the saved bin to do test writes, except for the 1mb P12 which did not perform a successful read. I did a test write anyways using a file in my tune library, and still had errors however at the end it said the test write completed. P12b denied kernel upload for the test write. I also noticed on a couple of the PCMs there were many read retries. Hopefully I am not missing anything. Attached are read bins for each successful read, along with all logs.

[antus]

All intel chips have some code sequence to enable vpp and than wait for a bit to set for some specific time. The usual method is set a vpp register,->wait in a loop and test another register for vpp status. When vpp status is OK->proceed -> if it doesn`t get OK for a specific time ->exit with an error.

Actually vpp induce heavy noise on bus and is enabled only when actual erase, write is done and than turned off, until next batch of data is written.

Yep. This is where we are at. We don't know the register to wait for all platforms, so some are time waits. We know the erase and write code is correct, and we know Vpp is coming on, so the problems we need to track down likely are to do with Vpp coming on, and what and why that is breaking. There is more to it than that too. Its also possible that we are loosing the DLC. But at that point we are blind so we cant tell if a VPW routine is stuck and not returning, of if the DLC is in a bad state. More testing to do. Everything that is in the flash datasheet is the easy part, its the quirks and undocumented stuff that is the bigger challenge.

@darkman, thanks for those.

[darkman5001]

All intel chips have some code sequence to enable vpp and than wait for a bit to set for some specific time. The usual method is set a vpp register,->wait in a loop and test another register for vpp status. When vpp status is OK->proceed -> if it doesn`t get OK for a specific time ->exit with an error.

Actually vpp induce heavy noise on bus and is enabled only when actual erase, write is done and than turned off, until next batch of data is written.

Yep. This is where we are at. We don't know the register to wait for all platforms, so some are time waits. We know the erase and write code is correct, and we know Vpp is coming on, so the problems we need to track down likely are to do with Vpp coming on, and what and why that is breaking. There is more to it than that too. Its also possible that we are loosing the DLC. But at that point we are blind so we cant tell if a VPW routine is stuck and not returning, of if the DLC is in a bad state. More testing to do. Everything that is in the flash datasheet is the easy part, its the quirks and undocumented stuff that is the bigger challenge.

@darkman, thanks for those.

No problem Antus. Tomorrow I will test a P01 and both P59s and see where we are at there.

[darkman5001]

Okay, tonight I tested another P04, a P01, a P59 Intel and two P59 AMD. This P04 would not even attempt a test write because not supported. The P59 Intel was misrepresented as an AMD. The two AMD P59s also had errors however were represented as AMDs. All had CRC errors during the test write as well as multiple retries. Logs attached. Again pay no attention to reported voltage. My MDI2 is connected to a GoDiag GT100+ and the PCM power is connected to a lab power supply. PCM voltage was around 14.6v for all yesterday's tests as well as todays.

[antus]

Thanks for the results. I'll look in more detail shortly. A quick answer:

"The P59 Intel was misrepresented as an AMD."

This isn't possible. The chip id comes from the chip itself, there is no lookup against OSID or anything we could have gotten wrong. If the system was broken it'd be an invalid ID and say unknown and abort. You might want to pop the lid and check you havn't got your PCMs mixed up.

I am not sure what to expect from the test write. Are you able to read a bin, change the vin, key off, power off (to persist the vin change to flash), then do a write paramater block to write the original paramater block only back from your first bin? The change of vin will mean a change in that block is found and it will erase and write it. But being a param block its a bit safter than writing more than that. I suspect it'll work fine. If it erases but doesnt write security key will be FFFF and you can use a custom key with a normal copy of pcmhammer to write the original param block back.

[darkman5001]

Thanks for the results. I'll look in more detail shortly. A quick answer:

"The P59 Intel was misrepresented as an AMD."

This isn't possible. The chip id comes from the chip itself, there is no lookup against OSID or anything we could have gotten wrong. If the system was broken it'd be an invalid ID and say unknown and abort. You might want to pop the lid and check you havn't got your PCMs mixed up.

I am not sure what to expect from the test write. Are you able to read a bin, change the vin, key off, power off (to persist the vin change to flash), then do a write paramater block to write the original paramater block only back from your first bin? The change of vin will mean a change in that block is found and it will erase and write it. But being a param block its a bit safter than writing more than that. I suspect it'll work fine. If it erases but doesnt write security key will be FFFF and you can use a custom key with a normal copy of pcmhammer to write the original param block back.

I will pop the covers tonight and confirm. I just did basic read and test writes. What specific tests should I run for each PCM? I want to make sure the test results are accurate and useful.