PCM Hammer P12 development

[Gampy]

Got past the mode 34 request failure with a simple change,

Code: Select all

        /// <summary>
        /// Create a request to uploade size bytes to the given address
        /// </summary>
        /// <remarks>
        /// Note that mode 0x34 is only a request. The actual payload is sent as a mode 0x36.
        /// </remarks>
        public Message CreateUploadRequest(int Address, int Size)
        {
#if P12
            byte[] requestBytes = { Priority.Physical0, DeviceId.Pcm, DeviceId.Tool, Mode.PCMUploadRequest };
#else
            byte[] requestBytes = { Priority.Physical0, DeviceId.Pcm, DeviceId.Tool, Mode.PCMUploadRequest, Submode.Null, 0x00, 0x00, 0x00, 0x00, 0x00 };
            requestBytes[5] = unchecked((byte)(Size >> 8));
            requestBytes[6] = unchecked((byte)(Size & 0xFF));
            requestBytes[7] = unchecked((byte)(Address >> 16));
            requestBytes[8] = unchecked((byte)(Address >> 8));
            requestBytes[9] = unchecked((byte)(Address & 0xFF));
#endif
            return new Message(requestBytes);
        }

The kernel uploads, however it is silent ...

In the meantime, kur4o dumped a load that appears (fingers crossed) to be bearing fruit in some places not another ... Unfortunately I have not yet found the DLC addressing, any help would be appreciated.

I do have a couple differently RAM addressed kernels out for trial ... Unfortunately the test PCM has become slightly damaged by another tool.

Speaking of that damaged PCM it is spitting out a continuous stream of,

RX: 6C F0 10 A2 00

Messages.

Now, the Os is spitting them out right ??
So, if the Os jumped to the kernel code those messages would immediately stop, right ??
So that would be a good indicator that it's at least running (or trying to) ??
However if it never misses a beat on the A2 messages it never even tried!

Would that be a fair statement ...

I would think the PCM would miss a blink or two if it was dysfunctional from the upload ...

[kur4o]

6C F0 10 A2 00

Is an indicator of soft bricked.

Could still be saved just like the recovery mode works in ls1 type of pcms.

I will look for dlc but p12 watchdog don`t need the slave ones. Maybe rip the watchdog from the file I uploaded.

You can upload to ffff6000 + for now for safety reasons.

[kur4o]

Not quite sure but the dlc can be at fff800, just like the v6 pcms.

Looks like the ff2000 RAM is run by the slave cpu, there are different watchdog registers there, and at ff6000 is the main CPU area.
So it migth be tricky to make both cpus happy.

It wil be nice if we get a pic of the board. The connectors pins needs desoldering from main board to get it removed.

[darkman5001]

Good news... I found another test P12 PCM. So the one that I was using that somehow got damaged is now a casualty of war.
I broke it open and got good pics of the board, CPU and flash chip. I also posted pinouts and also manufacture documentation from AMD.

viewtopic.php?f=42&t=7748

[darkman5001]

I removed the flash chip from the crashed P12 PCM. I have to find a 56pin socket for my chip programmer before I can look at what's salvageable.

[Gampy]

I am not the disassembly guru here, however looking at the FFFF0000.rar attachment in sub_FF213C, there is,

Code: Select all

ROM:00FF2172                 move.b  #$55,(byte_FFFFFA55).w
ROM:00FF2178                 move.b  #$AA,(byte_FFFFFA55).w

I'm pretty confident that is COPA (Watchdog1), please do school me if I'm wrong!

Immediately following that is what I believe is COPB (Watchdog2),

Code: Select all

ROM:00FF217E                 bset    #7,(byte_FFFFFA21).w

However, I would expect it to be immediately followed by,

Code: Select all

ROM:00FF21AA                 bclr    #7,(byte_FFFFFA21).w

however it is a bit further down so I am a bit confused there ...

I do not believe it's to this stage yet, I do not believe the kernel is jumped to (executed).

The last tests were at FF4000 and FFA000, I'll try FF6000 and P04 DLC addresses ... Nothing to lose but time, unless I run our volunteer tester off!

[kur4o]

Than you look at sub_ff60ee and the confusion is even more.

[kur4o]

Made a quick disassembly and the dlc is at fff60c, I guess ls1 style.

The COp might need fixing

ROM:00FF2172 move.b #$55,(byte_FFFFFA55).w
ROM:00FF2178 move.b #$AA,(byte_FFFFFA55).w

and

eori.b #$80 byte_FFFFFA21

and or this
andi.w #$FFEF word_FFFFF7A0

or

Code:
Select all
ROM:00FF217E bset #7,(byte_FFFFFA21).w

However, I would expect it to be immediately followed by,

Code:
Select all
ROM:00FF21AA bclr #7,(byte_FFFFFA21).w

Looks like very specific time should pass before clearing bit 7.

Some timer FFFFF762 is used for the timing. Not widely used in code, only one very long subroutine that do only this in repetitive cycle.

[antus]

Yep the first watchdog/cop stuff looks right, typically 55 (01010101) and AA (10101010) to toggle all bits in watchdog 1, and bset, bclr to toggle a single bit (bit 7) in watchdog 2.

You also sound right about the timer. The cheapest way to implement a delay is to just waste a known about of clock cycles, and if longer delays are needed make the loop programmable so you can loop more times from an argument.

DLC is usually a couple of registers and the gap between them might not be the same. On the P04 we found a couple of the registers were merged. Maybe check the P04 test kernel and its comms routines might be a better fit than the P01 routines. Still need the DLC registers though. Should not be too hard to find given enough time in the disassm once the main comms loop is found. It should be along the lines of call a subroutine to gather a data packet, compare the mode to see what the packet is then hand off to a subroutine to handle it. The read routine will have all the receive registers, and the write ones will be nearby. Its quite likely the write routine which has those registers is within a routine or two close to the read routine.

If were serious about this I think we need to implement a kernel structure in the C# code which contains the binary filename on disk, the load address, and a list of enums as to what it supports. Then in the PCM hammer main loop we'll be able to turn of CRC validation if the kernel doesnt have it because it doesnt fit. That'd probably also get the P04 over the line.

[darkman5001]

Do you guys think that because it is saying the buffer is empty is the reason why the kernel isn't uploading? What's the next step? I ready to do more testing.