PCMHammer P04

[kur4o]

As you mention it. I have seen DLC crash but can`t remember exact conditions. Requesting multiple messages while pcm sending data. It is possible pcm buffers more than 1 incoming message while sending. It could be a bug since p04 p08 uses one register for read/write dlc while p01 have 2 registers. Might need more time and there might be internal conflict if too fast.

To debug some stripping will be needed and start from scratch with DLC only, and add stuff around it. I know it wasn`t stable from day one with unexpected crashes.

[antus]

I am makeing some headway on this tonight. I came to understand that the buffer needs to be odd aligned, because of the priority byte. So if it starts on odd, then DST, SRC are even, Mode/Submode are even, Payload starts on even. There is the required even.

Then I noticed the mainloop is using clr.w and cmp.w on the Mode and Submode, hence that alignment requirement for data in RAM. That was one of the crashes. Then I noticed the Kernel FlashID was writing in the buffer as words as well. I modified the main loop to clr.b as its just preventing commands from re-firing on the next pole after the work is done. Mode 00 will do that as well as 00 00. Then I modified to look for submode 3D as a byte, then do the submode comparisons as bytes. Then I found the FlashID function was useing word ops to copy manufacturer and chipid in to the message buffer. Byte operations and shift the register instructions added to solve this.
At this point I thought I had it, packaged it all up tidy and tested again, and its still broken!

The other thing I've known about but havn't bothered to fix for a long time is that the kernel needs to be odd size so that the checksum-16 block sum test for block uploads in the factory OS and in the loader get 16 bits each time for the sum test. So to solve this, instead of bothering with kernel padding I modified hammer to add a byte to the kernel buffer when it loads the kernel if its even size, to make it the required odd size. This means the upload succeeds regardless of if the kernel ends up being odd or even, but now I am seeing

Code: Select all

[22:47:43.164] 6D F0 10 76 80 78
[22:47:43.166] 6C 10 F0 3D 00
[22:47:44.276] 6C 10 F0 3D 00
[22:47:44.285] FF FF FF FF FF FF FF FF 08
[22:47:45.392] 6C 10 F0 3D 00
[22:47:45.399] FF FF FF FF FF FF FF FF 08
[22:47:46.517] 6C 10 F0 3D 00
[22:47:46.522] FF FF FF FF FF FF FF FF 08
[22:47:47.632] 6C 10 F0 3D 00
[22:47:47.634] FF FF FF FF FF FF FF FF 08
[22:47:48.836] 6C 10 F0 20

So that's the right length message responding to 3D 00 "Get Kernel Vesrion", and at the right times after it starts up and misses the first one (normal), and it responds to the reboot command OK, but it seems something has gone crazy and trashed the data segment (again?). So there is another thing to find. Still looking for that one. Last one maybe?

[antus]

Still working on the P08. I've found lots of cases of crashes from using word addressing with RAM. I have a test build that is now working without any padding bytes in the data segment, or any data segment alignment just by replacing word access to memory with byte access. Functions which work on other PCMs are breaking on P08 because of this, including the erase function

Code: Select all

move.w  7(%a1), %d1

I think what it is, is P04/P08 CPU might actually need paragraph alignment, which is why you change instructions for shorter ones and opcodes move by 2 bytes which remain word aligned but get knocked off the paragraph and crashes happen in different places. They're like land mines. I am just working through that now. I've fixed the main loop, flash id check, erase code, a few others. Then there is getting it to load in to the right patch of ram that's safe to use. For example on P08 I can get the kernel or the loader to work loading to FFAC00 but I cant find a second place where the kernel will work at the same time as having the loader in ram. I am sure there is one, but at this stage it looks like loader isn't needed for P08 so that's not a problem at this stage.

[Gampy]

Enjoying the walk in my footsteps, inside the box I created.

Changing those perfectly valid (while MessageBuffer is out of alignment) instructions to bloated byte operations will add about 100 bytes (depending on how well it's done) to the size of the Kernel and still not resolve the issue.
And it does make it harder to get the Kernel onboard the Intel P04.
I'd show you my backup as proof but you wouldn't look at it!

Your right, the priority byte is the issue, it is the first byte, it goes into the first byte of the receive buffer (MessageBuffer) and it is on a odd address, according to Hoyle it should be on a even address.
How it is,

HowItIsAlignment.png (3.06 KiB) Viewed 2224 times

How it should be,

RequiredAlignment.png (3.16 KiB) Viewed 2224 times

I have absolutly ZERO issues with P08's, they are as rock solid as the others the way I have it done, obviously excluding the P04 ...
And the P08 does in fact not need a loader, it handles Mode 3600/3680 properly.

-Enjoy

[antus]

The problem is the knife edge you speak of, which is those instructions. I am fixing that. I too had it working on all, including intel p04 (I dont have an AMD one to test but I suspect it would have worked), but you said it wasn't stable enough, so that is what I am working on. I want it to be easy to develop further as we add more pcms and not break as soon as you make a minor change.

[Gampy]

The knife edge issue is the off address buffer, not the perfectly valid instructions.

Please prove me wrong, get VPWReceive to work with the first byte of it's receive buffer in an even address ... No hacks!

-Enjoy

[antus]

this is working

I just added a single padding byte to the antus/p08 branch to the end to knock it from odd to even. It makes no difference now.

Code: Select all

a@shed MINGW64 ~/git/p08/PcmHacks/Kernels (antus/p08)
$ git diff Kernel.S
diff --git a/Kernels/Kernel.S b/Kernels/Kernel.S
index f30ba6c..d034da6 100644
--- a/Kernels/Kernel.S
+++ b/Kernels/Kernel.S
@@ -1122,7 +1122,7 @@ Mode36Reply:    .byte  0x6C, toolid, pcmid, 0x76, 0x00, 0x00
 Mode60Reply:    .byte  0x6C, toolid, pcmid, 0x60

 | Erase Sector Reply, 7 bytes
-EraseSectorReply:   .byte  0x6C, toolid, pcmid, 0x7D, 0x05, 0x00, 0x00
+EraseSectorReply:   .byte  0x6C, toolid, pcmid, 0x7D, 0x05, 0x00, 0x00, 0xAA

 | Global buffer, it's at the end and it's not transported, thus length is irrelevant!
   .globl   MessageBuffer

[antus]

I fixed another move.w in the erase code, which got that working, and then found a move.l that was breaking the CRC32 depending on alignment. Ive committed and pushed both fixes to the antus/p08 branch as well as removed the last byte of padding which exposed the CRC32 problem. More testing is required, but it seems it might be properly stable now. I will continue testing, and if it looks good, go back to the P04. All code for all flash chips is in there, and despite the size increases in a couple of places total size is still under 2000 bytes.

[antus]

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.

[kur4o]

If you want to test writing use 55AA pattern, FFs is not solid as when you erase chip it always goes to FFs, when there is no way to tell if it was written successfully. The data after 4400 looks like code with some nop instruction, but it doesn`t end as expected, there is no return instruction. It got copied from somewhere, I guess it kept copying some random data from bin or ram.