pcmhacking.net

antus wrote:Thanks! The file looks correct. Can see the right file structure and it looks like all data lines and address lines were well connected and the data does not look damaged.
It did need 'a' and 'b' bytes swapped. Ive applied this and now it loads correctly in ida.

How should I use this file now? The one I posted earlier was the entire flash chip's data.

antus wrote:try this payload

Code: Select all

start:
wait01:
    bsr.w   ResetWatchdog
    bsr.w   WasteTime
    jmp.s   wait01
    
WasteTime:
    nop
    nop
    nop
    nop
    rts

ResetWatchdog:
    move.b  #0x55, (0xFFFA55).l			| Reset COP1
    move.b  #0xAA, (0xFFFA55).l
    bclr    #7,	(0xFFFA21).l			| Reset COP2
    bset    #7,	(0xFFFA21).l		
    rts	

.end

I ran this through VPWexplorer and sent to FF2000. Not sure if I did correctly but here is the PCMs responses.

I think thats what we were looking for - the pcm takes the kernel and it satisfies the watchdog and it goes silent. The lack of response after the send indicates success.

I have just sent another version of my tweeked VPW Explorer, I have added an OsID button (3C0A), if our code is running it will fail quickly, if our code is not running it will respond quickly with the OsID.

I have also sent a version of my hack to Antus's asm code that is longer, shooting for ~20 seconds, then it should exit, thus send the ack, hopefully that is before VPW Explorer times out ...
I'm hoping VPW Explorer can log the shift from Empty Buffer to ACK.

Antus, does my loop counter and exit strategy hack to your code look sane ??

It looks sain, but I think you need an rts at the end. I dont know if you can jump back out of a kernel though, ive never done it. It would require the pcm is still in a normal state and the stack pointer is intact. The test kernels dont touch those things, but in the P01 the pcm sets itself up differently so its not monitoring interrupts generated by the engine before it jumps to the kernel and I dont know what this one does. Personally I'd call it win already and im trying to confirm the DLC registers, as I think getting it talking is the next step.

I do not consider this a kernel ... It is just a routine!
At least at this point in time.

I agree after we prove the dogs are happy ... The next step would be getting it speaking!

All I care about at the moment is proving the dog is happy, I do not believe it currently is ...
IMO the only way to prove it, is to loop longer then the COPs timeout then exit so the OS can send the ack.

Then I'll move on to the next step.

In the P01/P59 I have used the PcmHammer kernels mode3680 to upload a small kernel, prove it runs, then exit back to the PCM Hammer kernel.
Just got done doing so ...

If I put an rts at Exit1: it would return and execute the next statement 'jmp.s wait01', thus remaining in the loop, I want to quit the application.
At this point it should all be good, we have not mucked up the environment yet so returning to the OS should be all good.

In the log above the kernel/routines are sent at [05:42:54:101] and nothing is received back by the end of the log at [05:44:37:088]. Thats longer than the watchdog I believe. I dont know how long the watchdog lasts, but I think its in the vicinity of a couple of hundred milliseconds at most. Still, the osid test will make it more certain. We cant have too much data.

The thing is, the log looked exactly like the log of my very very first attempt, and many since ...

I didn't get the results I expected from my last test, the log looks the same.

I've just sent another.

Where are these ones? I seem to have lost them in the thread. They would be working if that's whats in them. I can only see TX followed by RX in this thread, except with my kernel its TX then no more RX at all, consistent with the test loop with watchdog executing and nothing talking to the DLC.

antus wrote:Where are these ones?

Logs ??