PCMHammer P04

by **antus** » Wed Nov 15, 2023 2:27 pm

I think there is a problem with your disassembly, that disassembles fine for me.

Code: Select all: RAM:00FF8036 loc_FF8036: ; CODE XREF: RAM:00FF80A2↓j RAM:00FF8036 ; RAM:00FF80F2↓j ... RAM:00FF8036 13FC 0000 00FF B3A9 move.b #0,(byte_FFB3A9).l RAM:00FF803E 6100 007A bsr.w sub_FF80BA RAM:00FF8042 6100 05E2 bsr.w sub_FF8626 RAM:00FF8046 6100 008C bsr.w sub_FF80D4 RAM:00FF804A 7000 moveq #0,d0 RAM:00FF804C 1039 00FF B3A9 move.b (byte_FFB3A9).l,d0 RAM:00FF8052 E188 lsl.l #8,d0 RAM:00FF8054 1039 00FF B3AA move.b (byte_FFB3AA).l,d0 RAM:00FF805A 0C40 3D00 cmpi.w #$3D00,d0 RAM:00FF805E 6700 007E beq.w loc_FF80DE RAM:00FF8062 0C40 3D01 cmpi.w #$3D01,d0 RAM:00FF8066 6700 015A beq.w loc_FF81C2 RAM:00FF806A 0C40 3D02 cmpi.w #$3D02,d0 RAM:00FF806E 6700 00BE beq.w loc_FF812E RAM:00FF8072 0C40 3D03 cmpi.w #$3D03,d0 RAM:00FF8076 6700 007E beq.w loc_FF80F6 RAM:00FF807A 0C40 3D05 cmpi.w #$3D05,d0 RAM:00FF807E 6700 01D4 beq.w loc_FF8254 RAM:00FF8082 E048 lsr.w #8,d0 RAM:00FF8084 0C00 0034 cmpi.b #$34,d0 ; '4' RAM:00FF8088 6700 0422 beq.w loc_FF84AC RAM:00FF808C 0C00 0035 cmpi.b #$35,d0 ; '5' RAM:00FF8090 6700 042C beq.w loc_FF84BE RAM:00FF8094 0C00 0036 cmpi.b #$36,d0 ; '6' RAM:00FF8098 67FF 0000 0456 beq.l loc_FF84F0 <------ RAM:00FF809E 0C00 0020 cmpi.b #$20,d0 ; ' ' RAM:00FF80A2 6692 bne.s loc_FF8036 RAM:00FF80A4 207C 00FF B39A movea.l #unk_FFB39A,a0 RAM:00FF80AA 303C 0004 move.w #4,d0 RAM:00FF80AE 6100 051C bsr.w sub_FF85CC RAM:00FF80B2 6100 0020 bsr.w sub_FF80D4 RAM:00FF80B6 4E70 reset

by **Gampy** » Wed Nov 15, 2023 2:29 pm

ProfessWRX wrote:Ok, I'm looking at something weird in the Kernel. It's the same problem in the p08 and p10 kernels.

Code: Select all
ROM:0000006E cmpi.w #$3D03,d0 ; Compare Immediate ROM:00000072 beq.w sProcessOSID ; Branch if Equal ROM:00000076 cmpi.w #$3D05,d0 ; Compare Immediate ROM:0000007A beq.w sProcessEraseSector ; Branch if Equal ROM:0000007E lsr.w #8,d0 ; Logical Shift Right ROM:00000080 cmpi.b #$34,d0 ; '4' ; Compare Immediate ROM:00000084 beq.w sProcessMode34 ; Branch if Equal ROM:00000088 cmpi.b #$35,d0 ; '5' ; Compare Immediate ROM:0000008C beq.w sProcessMode35 ; Branch if Equal ROM:00000090 cmpi.b #$36,d0 ; '6' ; Compare Immediate ROM:00000090 ; --------------------------------------------------------------------------- ROM:00000094 dc.b $67 ROM:00000095 dc.b $FF ROM:00000096 dc.b 0 <-----------Something's wrong with this. ROM:00000097 dc.b 0 ROM:00000098 dc.b 4 ROM:00000099 dc.b $56 ; V ROM:0000009A ; --------------------------------------------------------------------------- ROM:0000009A cmpi.b #$20,d0 ; ' ' ; Compare Immediate ROM:0000009E bne.s sMainLoop ; Branch if Not Equal ROM:000000A0 movea.l #unk_FF8796,a0 ; Move Address ROM:000000A6 move.w #4,d0 ; Move Data from Source to Destination ROM:000000AA bsr.w sVPW_Send ; Branch to Subroutine ROM:000000AE bsr.w sWasteTime ; Branch to Subroutine ROM:000000B2 reset ; Reset External Devices ROM:000000B4

Snip of the source ...

Code: Select all: cmpi.b #Mode_36, %d0 | Is it mode 0x36 (Tool sending data to write, either to RAM or Flash) beq.l ProcessMode36 | Process it cmpi.b #Halt_20, %d0 | Is it mode 0x20 (return to normal comms)

That version of IDA cannot disassemble the beq.l ...

-Enjoy

by **ProfessWRX** » Wed Nov 15, 2023 2:42 pm

Well that’s a strange command. A .word would have been plenty.
I’ll keep at it all.

by **antus** » Wed Nov 15, 2023 2:54 pm

It could be that the 2 byte offset fixed it somewhere else, for unexplainable reasons. This sort of stuff is what we have been trying to understand for months. You could probably make it a word, it'd break, then you'd put a nop somewhere and it'd work again.

I am pretty sure something cares about paragraph alignment but it should not and it is not explainable. I suspect its an obscure CPU bug, fixed in the next hardware revision and I suspect motorola might have helped bake a software workaround in to the GM compiler, and if that was the case we'll never get to the bottom of it. Its the only possibility left that I can come up with.

by **Gampy** » Wed Nov 15, 2023 3:01 pm

I was testing something and missed it on the change back ...

-Enjoy

by **ProfessWRX** » Wed Nov 15, 2023 3:38 pm

Can I get examples of a kernel bin that’s broken and a kernel that’s fixed so I can look? I have a strange thought on it that I want to explore.

And broken, what exactly is meant? The cpu fails to run it after loading? Or something else?

by **antus** » Wed Nov 15, 2023 4:42 pm

Yes, crashy. I don't have time to build a kernel, put a nop in it, build it again, and test them and confirm one works, one does not. You might need to put BDM in your P08 or your P04 so if it erases and then crashes you dont get a brick, or when you do you can recover. Then just build the antus/p08 kernel and add a nop somewhere and watch it have effects it shouldn't. Typically crashes are immediately before or after the erase. You may find something we havn't but we have spent months on this and learnt a lot about these PCMs and this last one escapes us. If you use my kernel with the byte operations then its pretty stable. If you use one with the word operations then you also need to watch comms buffer word alignment closely.

You can set up some tests where a crash after erase shouldnt cause a brick (junk data in the unused param block), but I have crashed so many kernels and I will say there is no 100% safe way to test and sooner or later you'll brick, so you want BDM recovery ready to go before you go down this road.

Also note that you need to keep the loader (when using it) and kernel load addresses the same between the assembly kernel build and pcmhammers load address. If there is a mismatch you'll get a crash from that, rather than the kernel.

by **ProfessWRX** » Wed Nov 15, 2023 11:23 pm

Ah I thought there was a record of breaks and builds you guys kept.

by **Gampy** » Thu Nov 16, 2023 1:04 am

2 P04 Kernels, the only difference is a single NOP placement ... One works, the other doesn't.

Kernel-P04.zip: (2.6 KiB) Downloaded 19 times

WARNING! IIRC this broken Kernel will soft brick your PCM! DO NOT USE!

Look through the following code, you will see two places with "<<<<<<<<<<<<<<<<<<<<<<<<<<<<<" and a note ...
All the code is the same except the placement of this one NOP instruction ...
The one makes it work, without it, it does not work, however, if it gets relocated after where it's at it also doesn't work, it has to be where it's at or before in order for it to work.

It can be placed in many other places higher in the source, just not lower!
Unless the binary size changes, it does have a relation to the binary size. And how many bytes it takes to make it work depends on the resulting binary size., if I optimize it a lot, I may need to add 12 bytes or more!
As it is right now it only needs this one NOP instruction to take it from not working to working.

It fails to erase, I think Unlock fails, because what the data on the chip looks like is scrambled like it looks when you try to erase without unlocking

The code path is a call to IntelEraseSector, then it calls IntelFlashUnlock and returns to IntelEraseFlash and erases the Flash ...

I hope I explain clearly!

Code: Select all: | =============== S U B R O U T I N E ======================================= | | Intel Flash Unlock | Tested on, | AB28F400B (512k) | AB28F800B (1m) | | Uses | d1 - Scratch | IntelFlashUnlock: #if defined P08 move.w #0x0F, (REG_FFF408).w | Hardware Setup move.w #0x05, (REG_FFF4C8).w | Hardware Setup #endif move.w #0x0007, (SIM_CSBARBT).w | $FFFFFA48 move.w #0x6820, (SIM_CSORBT).w | $FFFFFA4A move.w #0x0007, (SIM_CSBAR0).w | $FFFFFA4C | Unlock move.w #0x7060, (SIM_CSOR0).w | $FFFFFA4E | Enable +12v Vpp #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 register bset #VPP_BIT, %d1 | Set Vpp Latch Bit move.w %d1, (HARDWARE_IO).w | Move modified value back to Latch Address #endif move.w #32767, %d1 | 32768 loops IntelFlashUnlockWait: | Allow Vpp ripple to settle bsr.w ResetWatchdog | Scratch the dog bsr.w WasteTime | Twiddle thumbs dbf %d1, IntelFlashUnlockWait | If False Decrement and Branch nop | This nop is for P04 sizing/alignment <<<<<<<<<<<<<<<<<<<<<<<<<<<<< IT WORKS WITH IT HERE rts | =============== S U B R O U T I N E ======================================= | | Intel Flash Lock | Tested on, | AB28F400B (512k) | AB28F800B (1m) | | Uses | d1 - Scratch | IntelFlashLock: move.w #0x0007, (SIM_CSBARBT).w | $FFFFFA48 move.w #0x6820, (SIM_CSORBT).w | $FFFFFA4A move.w #0x0007, (SIM_CSBAR0).w | $FFFFFA4C | Lock move.w #0x1060, (SIM_CSOR0).w | $FFFFFA4E | Disable +12v Vpp #if defined P08 bclr #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 register bclr #VPP_BIT, %d1 | Set Vpp Latch Bit move.w %d1, (HARDWARE_IO).w | Move modified value back to Latch Address #endif rts | =============== S U B R O U T I N E ======================================= | | Intel Flash Erase Sector by Address | Tested on, | AB28F400B (512k) | AB28F800B (1m) | | Entry | a0 - Sector Address to Erase | | Exit | d0 - Status 0=Ok, 1=Fail | | Uses | d1 - Scratch | d2 - Loop Index | IntelEraseSector: bsr.w IntelFlashUnlock | nop | This nop is for P04 sizing/alignment <<<<<<<<<<<<<<<<<<<<<<<<<<<<< IT FAILS WITH IT HERE move.w #CLEAR_STATUS_REGISTER, (%a0) | 0x5050 Clear State Machine Status Register move.w #INTEL_ERASE_CMD, (%a0) | 0x2020 Set State Machine into Erase Mode move.w #ERASE_RESUME_CONFIRM, (%a0) | 0xD0D0 Confirm Command Erase - Start Erase move.w #READ_STATUS_REGISTER, (%a0) | 0x7070 Set State Machine into Read Status Mode, until commanded otherwise, see below move.l #6553600, %d2 | Erase Loop Timeout index, run away prevention, leave big, allow each PCM to respond in it's own time IntelEraseSectorNotReady: bsr.w ResetWatchdog | Scratch the dog move.w (%a0), %d1 | Move State Machine Status to register, it is still in Read Status Mode btst #0x007, %d1 | Test Status - If bit 7 is set, it is Ready (done). bne.s IntelEraseSectorReady | Status Success - Jump to IntelEraseSectorReady subq.l #1, %d2 | Decrement index bne.s IntelEraseSectorNotReady | Fail Status Check, Test again moveq #2, %d0 | Set Error Code 2 = Timeout error cmpi #0, %d2 | Did Timeout occure ? beq.s IntelEraseSectorDone | Yes, Done, Failure IntelEraseSectorReady: moveq #0, %d0 | Set Success (if Status passes) andi.w #0x0E8, %d1 | Mask 1110 1000 cmp.w #0x080, %d1 | Check status beq.s IntelEraseSectorDone | Pass ?, Done, Success moveq #1, %d0 | Set Failure IntelEraseSectorDone: move.w #READ_ARRAY_CMD, (%a0) | 0xFFFF Take State Machine out of Read Status Mode move.w #READ_ARRAY_CMD, (%a0) | 0xFFFF Return to Normal Read Array mode bsr.w IntelFlashLock rts

-Enjoy

by **ProfessWRX** » Thu Nov 16, 2023 1:13 am

Awesome, I'll take a look.

PCMHammer P04

Re: PCMHammer P04

Re: PCMHammer P04

Re: PCMHammer P04

Re: PCMHammer P04

Re: PCMHammer P04

Re: PCMHammer P04

Re: PCMHammer P04

Re: PCMHammer P04

Re: PCMHammer P04

Re: PCMHammer P04

Who is online