PCMHammer P04

[antus]

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

[Gampy]

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

[ProfessWRX]

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

[antus]

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.

[Gampy]

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

-Enjoy

[ProfessWRX]

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?

[antus]

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.

[ProfessWRX]

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

[Gampy]

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

Kernel-P04.zip

(2.6 KiB) Downloaded 265 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

[ProfessWRX]

Awesome, I'll take a look.