Page 14 of 31
Re: PCMHammer P04
Posted: Fri Aug 11, 2023 5:42 pm
by antus
Yeah. I try to write FFs to that sector because it does no damage. If the kernel runs through and says it was successfull then I move to more conclusive tests. But since the kernel code is known good on other PCMs the presence of errors from the write process is enough to signify that all things are not equal on this one and something needs to change. Currently Im playing with load addresses, I cant see any reason that write routine would have had its d0 corrupted causing overrun, so I am suspect of using some RAM I cant. Most problems were either alignment crashes because of the move.w direct in the buffer, or failing to turn on Vpp if the bset instruction wasnt the right variety. Both of those appear solved, so its almost got to be using ram that is reserved or used by some unknown chip in the P04. It can't be something fundamentally wrong with the write loop.
Re: PCMHammer P04
Posted: Sat Aug 12, 2023 4:29 am
by kur4o
It is very likely there is some shared memory in RAM. You can always make a script to dump the ram at any time to verify if that is the case.
I think space from ff8000-ffaffff on p04, should be free from interference. but not sure it will be enough for the flash routine.
To free some more space you can double upload the loader so it is not in the middle.
On blackbox pcm and 97-98 ls1 pcm there is some locked RAM area in the middle of nowhere, and pcm crashes when you try to read it.
Re: PCMHammer P04
Posted: Sat Aug 12, 2023 1:59 pm
by antus
I cant explain it, I've read the code over and over, I changed it to use d7 to store the write length instead of d0, and now it works perfect. I cannot see any reason why d0 cant be used, and there is no problem with any other code in other places in the kernel that uses d0. So at this point I think I'll just be happy with that, and re-test everything, including p59 because its currently the only AMD chipped PCM I have (though my p12b did rock up the other day, that might be an AMD come to think of it... might have to get it on the bench too). There is also an AMD P04 on the way, which will need testing eventually as the P59 and P12b wont have the same quirks as the early CPU in the P04 and P08. Its quite possible/probable something will need to be changed for compatibility there too.
I know we've seen this before, but this time, without the "knife edge", padding bytes, built to work without special extra attention to the alignment requirements of the early CPU.
Code: Select all
[01:48:13:812] PCM Hammer (11/08/2023, 7:03 PM)
[01:48:13:820] Saturday, August 12 2023 @01:48:13:82
[01:48:13:876] AVT 852 Reset OK
[01:48:13:882] AVT Firmware 1.5
[01:48:14:217] Thanks for using PCM Hammer.
[01:49:22:682] WARNING: This version uses the new Assembly Kernels, USE AT YOUR OWN RISK!
[01:49:34:605] C:\Users\a\Documents\p04-start.bin
[01:49:34:621] Validating 512k file.
[01:49:34:628] Start End Stored Needed Verdict Segment Name
[01:49:34:636] 00000 7FFFF 2A1DB4A1 2A1DB4A1 Good Whole File
[01:49:34:641] Requesting operating system ID...
[01:49:34:748] PCM and file are both for the same Hardware P04
[01:49:34:753] Operating system IDs do not match.
[01:49:34:757] PCM operating system ID: 12201468
[01:49:34:760] File operating system ID: 12589762
[01:49:34:766] Changing PCM to operating system 12589762
[01:49:34:769] WARNING: P04 Support is still in development.
[01:49:36:022] Unlock succeeded.
[01:49:36:088] Attempting switch to VPW 4x
[01:49:36:110] Module 0x10 (engine controller) has agreed to enter high-speed mode.
[01:49:39:253] PCM uses a kernel loader.
[01:49:39:521] Loader upload 100% complete.
[01:49:39:534] Loader Version: 69000104
[01:49:39:539] Loader uploaded to PCM succesfully.
[01:49:39:748] Kernel upload 20% complete.
[01:49:39:935] Kernel upload 47% complete.
[01:49:40:122] Kernel upload 73% complete.
[01:49:40:304] Kernel upload 100% complete.
[01:49:41:423] Kernel Version: 82400204
[01:49:41:428] Kernel uploaded to PCM succesfully.
[01:49:41:506] Changing PCM to operating system 12589762
[01:49:41:605] Flash chip: Intel 28F400B, 512kb
[01:49:41:620] Calculating CRCs from file.
[01:49:41:630] Requesting CRCs from PCM.
[01:49:41:636] Range File CRC PCM CRC Verdict Purpose
[01:49:44:004] 060000-07FFFF D2DDB07E 9370485B Different OperatingSystem
[01:49:46:383] 040000-05FFFF 10A46FED EC03D070 Different OperatingSystem
[01:49:48:798] 020000-03FFFF C7E426CF 6E7D0148 Different OperatingSystem
[01:49:50:604] 008000-01FFFF E5CCF450 F48444E3 Different Calibration
[01:49:50:901] 006000-007FFF E8244787 E8244787 Same Parameter
[01:49:51:213] 004000-005FFF 85B5BB36 85B5BB36 Same Parameter
[01:49:51:633] 000000-003FFF 62A39A35 77063ABF Different Boot
[01:49:51:643] Processing range 060000-07FFFF
[01:49:51:653] Erasing.
[01:49:53:180] Writing...
[01:51:16:782] Processing range 040000-05FFFF
[01:51:16:789] Erasing.
[01:51:18:315] Writing...
[01:52:41:938] Processing range 020000-03FFFF
[01:52:41:946] Erasing.
[01:52:43:462] Writing...
[01:54:07:358] Processing range 008000-01FFFF
[01:54:07:367] Erasing.
[01:54:08:700] Writing...
[01:55:11:421] Processing range 000000-003FFF
[01:55:11:429] Erasing.
[01:55:12:402] Writing...
[01:55:22:846] Calculating CRCs from file.
[01:55:22:861] Requesting CRCs from PCM.
[01:55:22:869] Range File CRC PCM CRC Verdict Purpose
[01:55:25:246] 060000-07FFFF D2DDB07E D2DDB07E Same OperatingSystem
[01:55:27:659] 040000-05FFFF 10A46FED 10A46FED Same OperatingSystem
[01:55:30:067] 020000-03FFFF C7E426CF C7E426CF Same OperatingSystem
[01:55:31:909] 008000-01FFFF E5CCF450 E5CCF450 Same Calibration
[01:55:32:176] 006000-007FFF E8244787 E8244787 Same Parameter
[01:55:32:472] 004000-005FFF 85B5BB36 85B5BB36 Same Parameter
[01:55:32:892] 000000-003FFF 62A39A35 62A39A35 Same Boot
[01:55:32:969] All relevant ranges are identical.
[01:55:32:980] All write-request messages succeeded on the first try. You have an excellent connection to the PCM.
[01:55:32:992] Please help by sharing your results in the PCM Hammer thread at pcmhacking.net.
[01:55:33:003] Flash successful!
[01:55:33:085] Clearing trouble codes.
[01:55:34:217] Elapsed time 00:05:58.1900477
Re: PCMHammer P04
Posted: Sat Aug 12, 2023 4:52 pm
by antus
p04 intel, p08 intel, p01 intel, p59 amd OK
p12 amd, erases, fails on write... getting there.
Re: PCMHammer P04
Posted: Sun Aug 13, 2023 1:42 am
by Gampy
What can I say ... I was wrong, it was not VPWReceive.
If I had only tested my 100% aligned Kernel with VPWReceive before opening my mouth, I wouldn't have.
-Enjoy
Re: PCMHammer P04
Posted: Sun Aug 13, 2023 2:47 am
by rjdrew1986
We owe a great deal to Antus, Gampy & Kur4o. All three of you extremely skilled. It's amazing to me how you guys just will not give up. And are wiling to share your thoughts along the way which helps to educate the rest of us. We are all very fortunate to be a part of this amazing forum.
Re: PCMHammer P04
Posted: Sun Aug 13, 2023 3:23 am
by zack4200
antus wrote:Anyone got any ideas what could cause this? I was intentionally erasing and re-writing sector 4000 in the intel P04, the erase worked, the write crashed and it took BDM to recover. I read this off the flash to check the damage before I re-wrote it. The sector should be empty but there is this data in there. It looks P04 internal, - the NuNuNu or Nq pattern comes up a lot, and I see a lot of numbers like 00FF979C which is a valid RAM address. But the bytes are not in the bin anywhere, and not in the flash kernel or the loader. I guess the write process kept writing but lost track of its source data buffer and copied junk from the wrong part of RAM before it caused a crash. It looks like the first 1K packet wrote all FF as expected, the second one starting at 0x4400 was total fail, or perhaps the first one didnt stop in the right spot and just kept writing data beyond the end of the buffer. Actually, I bet that was it.... Those memory addresses are probably the stack or left overs from the OS or Loader stack in RAM above the flash kernel. So the loop counter must have been corrupted by some external or additional factor.
I can't claim to understand a whole lot of what's been discussed in the last few pages, but I know LS Droid recommends adding a resistor (maybe 100k? can't remember for sure what size) from class 2 to ground when reading/writing p04s because the bus is a bit noisier/less stable than P01/P59 or something along those lines. Maybe it's the same thing causing the junk and issues here?
Re: PCMHammer P04
Posted: Sun Aug 13, 2023 4:54 am
by kur4o
If d0 is used in stack, there might be the bug, stack overfill or stack return on subroutine exit and it returns some random data to d0 if overfilled.
d7 is very unlikely to be stacked at any point.
Or it could be some difference in registers usage. 16bit vs 32bits. It could be also how commands are sent to intel chip, usually they are pushed to d0.
Re: PCMHammer P04
Posted: Sun Aug 13, 2023 11:03 am
by antus
We are not using registers much, we don't use the link function with the stack at all, in this case we just save the count in the register when the mode 36 comes in, put it in 2 registers. One is used to validate the block checksum and this one is just left alone until it needs to be used. It looks like the same problem with d7 on the P12, write overrun. The C kernel which loads to the same address is 8kb and this one is under 2kb and I don't know where the stack is but since its not pushed, popped, or linked I don't think that would be it. We could just keep using the C kernel for P12, but on the other hand it'd be nice to solve it and have the one kernel source for all VPW PCMs that end up supported by PCMHammer.
Re: PCMHammer P04
Posted: Sun Aug 13, 2023 12:02 pm
by MudDuck514
antus wrote:We are not using registers much, we don't use the link function with the stack at all, in this case we just save the count in the register when the mode 36 comes in, put it in 2 registers. One is used to validate the block checksum and this one is just left alone until it needs to be used. It looks like the same problem with d7 on the P12, write overrun. The C kernel which loads to the same address is 8kb and this one is under 2kb and I don't know where the stack is but since its not pushed, popped, or linked I don't think that would be it. We could just keep using the C kernel for P12, but on the other hand it'd be nice to solve it and have the one kernel source for all VPW PCMs that end up supported by PCMHammer.
Antus,
Great job (actually, ALL of you "great job" as this would NOT have come together if not for the team effort) on getting to this point.
I'll agree it would be nice having just one kernal for ALL supported PCMs.
On the other hand, having 2 (or 3) STABLE kernals is MUCH better than one for EACH PCM!
Just MY opinion.
Mike
(I REALLY wish I better understood things and was able to help out)