PCMHammer P04

[antus]

I have just tested P01 and the erase happened but kernel reported a failure, this has left my PCM in a bad state. I'll continue to work on this (probably a simple enough timing issue) but please hold on testing the above request a little longer as you might get yourself in to trouble on non-p08 platforms.

[Gampy]

Yea, unfortunately I tested before I saw this ...

-Enjoy

[antus]

If just pushed an update to the same P08 branch where it'll still send the key if you have a user defined key selected, even if seed is 0000. I was doing this previously with messy hacks for development, but I think its good for the main app as if you pick the user key, you probably want to send it regardless of what seed comes back. So this will be able to be used to recover from an erased / damaged security data formerly in the param block. So if key is 0000 and you suspect this is what happened (or know it in this case) you can set user key to FFFF and it'll still send it and unlock so you can fix the param block without BDM.

[Gampy]

I don't test/play on parameter sectors, therefore I do not have that issue ... Testing on parameter sectors is silly IMO.

I test on calibration sectors and calibration sectors only! PERIOD!
(Except on the P04 that doesn't follow the Flash Sectors)
The worst problem I have (unless it damages the chip) is it goes into recovery mode, PCM Hammer handles that perfectly fine ...

-Enjoy

[antus]

Yeah like you say that's good for p01 and p59. I am using param blocks because its a safer method for all of them and its also a small sector so you are less likely to hit timeouts while getting the base functionality right. You and I both have had these flash chips doing everything they're capable of and even things they aren't! So I guess you just damaged a cal sector and used a different build to put it back, no difficulty in that. I had to set key to FFFF and send it after seed, but so far I havnt bothered fixed it as it'll probably just trash it again next flash, so I am just running like this until I can get the code to work properly and it can fix that sector itself. Typical fault in plain view though, it doesn't seem to be timing on VPP, and the same code works on intel in P08, so not sure what the difference is between them, not that much has changed. WIP.

[antus]

Well you wouldn't believe it, but gampy, how sure you were about the syntax needed for Vpp? Well that syntax didnt work on P08, but the alternate syntax did. So I thought that proved the point that the other syntax was good. But now, its proven you were right, on P01. So neither syntax works on both! So the solution ended up being:

Code: Select all

#if defined P08
    bset    #VPP_BIT, (HARDWARE_IO).w  | Does not work on P01, needed for P08
#else
    move.w  (HARDWARE_IO).w, %d1       | Move Vpp Latch Address value to d1
    bset    #VPP_BIT, %d1              | Set Vpp Latch Bit
    move.w  %d1, (HARDWARE_IO).w       | Move modified value back to Latch Address
#endif

and the same but with bclr for lock...

It was the only way to get the same code base to work on both platforms. The code in the current merge request is tested on P01, P59, P08, P12 (all the platforms I currently have - p10 and p12b are on the way). So we need testing on P10 and P12b.

What a pain to figure out! Either different variations of 68k processor I guess, or differences in the VPP hardware.

[Gampy]

I swear the P04 is haunted!

-Enjoy

[antus]

More testing required and this might change the P08 patch as well, but I think I may have found the elusive P04 problem... Early testing indicates so. We were using a scratch register with word data without initialising it, so any junk present in the high word from unrelated factors would break the erase function when it was present. A single clr.l %d1 in the erase function to clear any junk before using it in that function seems to have done it. I also have some P08 OSIDs to get in, and this needs more testing on other PCMs, but hopefully we'll have a P04/P08 merge request up soon.

Code: Select all

PS C:\Users\a\git\p08\PcmHacks\Kernels> git diff .\Kernel.S
diff --git a/Kernels/Kernel.S b/Kernels/Kernel.S
index f2311af..ccc38ee 100644
--- a/Kernels/Kernel.S
+++ b/Kernels/Kernel.S
@@ -735,6 +735,7 @@ IntelFlashLock:
 |   d2 - Loop Index
 |
 IntelEraseSector:
+    clr.l   %d1                           | clear scratch space^M
     bsr.w   IntelFlashUnlock

     move.w  #CLEAR_STATUS_REGISTER, (%a0) | 0x5050 Clear Status register

Code: Select all

[09:33:09:334]  PCM Hammer (29/07/2023, 8:49 PM)
[09:33:09:337]  Saturday, July 29 2023 @09:33:09:33
[09:33:09:473]  AVT 852 Reset OK
[09:33:09:476]  AVT Firmware 1.5
[09:33:11:767]  WARNING: This version uses the new Assembly Kernels, USE AT YOUR OWN RISK!
[09:33:16:455]  C:\Users\a\Documents\P04 - antus 4444.bin
[09:33:16:473]  Validating 512k file.
[09:33:16:482]  	Start	End	Stored		Needed		Verdict	Segment Name
[09:33:16:491]  	00000	7FFFF	2A1DB4A1	2A1DB4A1	Good	Whole File
[09:33:16:495]  Requesting operating system ID...
[09:33:16:579]  PCM and file are both for the same Hardware P04
[09:33:16:584]  PCM and file are both operating system 12589762
[09:33:16:589]  WARNING: P04 Support is still in development.
[09:33:18:497]  Unlock succeeded.
[09:33:18:558]  Attempting switch to VPW 4x
[09:33:18:584]  Module 0x10 (engine controller) has agreed to enter high-speed mode.
[09:33:21:717]  PCM uses a kernel loader.
[09:33:21:981]  Loader upload 100% complete.
[09:33:21:995]  Loader Version: 69000104
[09:33:22:000]  Loader uploaded to PCM succesfully.
[09:33:22:215]  Kernel upload 21% complete.
[09:33:22:396]  Kernel upload 47% complete.
[09:33:22:580]  Kernel upload 73% complete.
[09:33:22:770]  Kernel upload 100% complete.
[09:33:23:891]  Kernel Version: 82400204
[09:33:23:896]  Kernel uploaded to PCM succesfully.
[09:33:23:971]  PCM and image file are both operating system 12589762
[09:33:24:033]  Flash chip: Intel 28F400B, 512kb
[09:33:24:038]  Calculating CRCs from file.
[09:33:24:046]  Requesting CRCs from PCM.
[09:33:24:051]  	Range		File CRC		PCM CRC	Verdict	Purpose
[09:33:24:056]  060000-07FFFF	not needed	not needed	n/a	OperatingSystem
[09:33:24:063]  040000-05FFFF	not needed	not needed	n/a	OperatingSystem
[09:33:24:069]  020000-03FFFF	not needed	not needed	n/a	OperatingSystem
[09:33:24:076]  008000-01FFFF	not needed	not needed	n/a	Calibration
[09:33:24:339]  006000-007FFF	E8244787	E8244787	Same	Parameter
[09:33:24:610]  004000-005FFF	C431BB2E	85B5BB36	Different	Parameter
[09:33:24:622]  000000-003FFF	not needed	not needed	n/a	Boot
[09:33:24:633]  Processing range 004000-005FFF
[09:33:24:643]  Erasing.
[09:33:25:614]  Writing...
[09:33:30:802]  Calculating CRCs from file.
[09:33:30:814]  Requesting CRCs from PCM.
[09:33:30:822]  	Range		File CRC		PCM CRC	Verdict	Purpose
[09:33:30:831]  060000-07FFFF	not needed	not needed	n/a	OperatingSystem
[09:33:30:841]  040000-05FFFF	not needed	not needed	n/a	OperatingSystem
[09:33:30:850]  020000-03FFFF	not needed	not needed	n/a	OperatingSystem
[09:33:30:861]  008000-01FFFF	not needed	not needed	n/a	Calibration
[09:33:31:135]  006000-007FFF	E8244787	E8244787	Same	Parameter
[09:33:31:421]  004000-005FFF	C431BB2E	C431BB2E	Same	Parameter
[09:33:31:433]  000000-003FFF	not needed	not needed	n/a	Boot
[09:33:31:500]  All relevant ranges are identical.
[09:33:31:512]  All write-request messages succeeded on the first try. You have an excellent connection to the PCM.
[09:33:31:526]  Please help by sharing your results in the PCM Hammer thread at pcmhacking.net.
[09:33:31:539]  Flash successful!
[09:33:31:617]  Clearing trouble codes.
[09:33:32:724]  Elapsed time 00:00:14.2222334

[Gampy]

Been there done that ... Same results!

Antus_Failure.png (20.34 KiB) Viewed 1640 times

Your branch 100% ...

You just finally got up on the knife edge!

Add a WasteTime or two some place else that is benign (unused by the P04, but still in the P04 Kernel) and it'll break it, or fix it ... Depending!

Edit: I guess I should point out the fact that nothing that uses d1 in IntelEraseSector, uses (or even sees) anything larger then a Word, therefore what is in the Long (DWord) is irrelevant!

-Enjoy

[Gampy]

I still believe the scratch register init was part of yet.

As I stated that belief is incorrect!

And here is the proof ...

Code: Select all

IntelEraseSector:
    move.l  #0xABCD0000, %d1 | High word test garbage
    bsr.w   IntelFlashUnlock

Resulting in perfect Intel writes on P01, P04, P08, P59 ...

There is no high word interference as claimed!

-Enjoy