Please help - neither windows nor linux hacks working

[GFPWK]

Hi,

Please could someone help me out?  This is my first post, although I've read the site and forum for hours over the past few months.  I've tried everything I can find, using both the linux and windows-based hack scripts. I must have read pretty much every page on the wiki, but can't get the hack to work. I've lost count of how many times I've tried to apply the hack.

I am currently using windows dmsutils v1.2.1, having not got anywhere with the linux based tools.  Today, I decided to start with a clean slate, and have as normal a DMS setup as possible before trying to apply the hack.  I formatted both PHATSYS and PHATDATA.  Then I applied the latest firmware to PHATSYS using PMM (v3.92) and loaded 2 playlists onto the DMS using PMM, then did a Save & Eject.  Then to check it was working OK, I disconnected power from the PB in the car, inserted the DMS, reconnected the power cable, and switched on the head unit.  The PB flashed the firmware, booted up, and all was working nicely as standard.  Music played, all features working. I powered off the head unit, waited for lights to go out on PB, then removed the DMS.  So far so good.

Next I followed the instructions at http://wiki.phathack.com/Windows_Hack_Procedure starting with BackupDMS.bat, then DMSHack.bat, and both worked without problems.

I then put the DMS in the PB and switch the head unit on as normal.  This is where the weirdness started.  The PB seemed to reboot itself pretty quickly (within about 5 seconds of powering on the head unit), and the head unit switched to radio.  So I switched source back to the PB again.  The PC started up and appeared to be in playlist mode, but it announced each of my 2 playlists in turn over and over again for about 5-6 mins, all the time with track numbers cycling fast 1-14 and 1-10 (this is how many tracks are in each of the 2 playlists).  The green light was flashing irregularly on the PB as if something was happening, but there seemed no sign of it ending, so I powered off the head unit and removed the DMS after the lights had gone out.

I checked the logs.  There was a patch.log in the PHATSYS:/log folder that seems to contain logs of lots of attempts to patch.  It is 6.4MB long.  Presumably each attempt is one cycle through the playlists (?)  But there was no patchverify.log file present.  The contents of patch.log are confusing, because it appears to show that all 9 patches are "Verified!", but if you read the detail it appears that there are various mismatches between the "expected" and "actual" values. Here's a sample (this sample seems to repeat over and over in patch.log):

Code: [Select]

: No such file or directory
PhatPatch v0.8 - original code by bushing, additional patches by sbingner
Finding patch offsets:
Verified standard patch offsets
Verifying:
Patch 1 @ 0bb8: make drive signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0000 1a00    Actual: 0000 1a00
Verified!
Patch 2 @ 0bec: make rc.sh signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0000 1a00    Actual: 0000 1a00
Verified!
Patch 3 @ 0c20: make phatd signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0000 1a00    Actual: 0000 1a00
Verified!
Patch 4 @ 0c54: make linux signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0000 1a00    Actual: 0000 1a00
Verified!
Patch 5 @ 0354: make ramdisk invalid signature return 0 instead of 0xFFFFFFFF: [movlne r0, 0xFFFFFFFF -> movlne r0, #0]
Expected: 0000 13a0    Actual: 0000 13a0
Verified!
Patch 6 @ 0c80: make ramdisk signature check verify 0 instead of 1: [cmp r0, #1 -> cmp r0, #0]
Expected: 0000 e350    Actual: 0000 e350
Verified!
Patch 7 @ 0358: make ramdisk valid signature return 0 instead of 1: [moveq r0, #1 -> moveq r0, #0]
Expected: 0000 03a0    Actual: 0000 03a0
Verified!
Patch 8 @ 0330: don't try to read ramdisk.sig (boot without any .sig files): [bl sector_read_suzy -> bl PC+1]
Expected: 0000 eb00    Actual: 0000 eb00
Verified!
Patch 9 @ 02c0: don't try to read linux.sig (boot without any .sig files): [bl sector_read_suzy -> bl PC+1]
Expected: 0000 eb00    Actual: 0000 eb00
Verified!
PhatPatch v0.8 - original code by bushing, additional patches by sbingner
Finding patch offsets:
Verified standard patch offsets
first 2 words of flash=c102 0025
testing offsets 0x555 and 0x2aa
writing auto-id command (AA, 55, 90)
testing offsets 0x5555 and 0x2aaa
writing auto-id command (AA, 55, 90)
Flash chip reports manufacturer id=00bf, device id=2789
offsets 0x5555 and 0x2aaa verified
Resetting flash.
Testing patch locations:
Patch 1 @ 0bb8: make drive signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0033 1a00    Actual: 0000 1a00
Detected patch 1 already applied
Patch 2 @ 0bec: make rc.sh signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0026 1a00    Actual: 0000 1a00
Detected patch 2 already applied
Patch 3 @ 0c20: make phatd signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0019 1a00    Actual: 0000 1a00
Detected patch 3 already applied
Patch 4 @ 0c54: make linux signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 000c 1a00    Actual: 0000 1a00
Detected patch 4 already applied
Patch 5 @ 0354: make ramdisk invalid signature return 0 instead of 0xFFFFFFFF: [movlne r0, 0xFFFFFFFF -> movlne r0, #0]
Expected: 0000 13e0    Actual: 0000 13a0
Detected patch 5 already applied
Patch 6 @ 0c80: make ramdisk signature check verify 0 instead of 1: [cmp r0, #1 -> cmp r0, #0]
Expected: 0001 e350    Actual: 0000 e350
Detected patch 6 already applied
Patch 7 @ 0358: make ramdisk valid signature return 0 instead of 1: [moveq r0, #1 -> moveq r0, #0]
Expected: 0001 03a0    Actual: 0000 03a0
Detected patch 7 already applied
Patch 8 @ 0330: don't try to read ramdisk.sig (boot without any .sig files): [bl sector_read_suzy -> bl PC+1]
Expected: 02db eb00    Actual: 0000 eb00
Detected patch 8 already applied
Patch 9 @ 02c0: don't try to read linux.sig (boot without any .sig files): [bl sector_read_suzy -> bl PC+1]
Expected: 02f7 eb00    Actual: 0000 eb00
Detected patch 9 already applied
By the way, does the "No such file or directory" line shown above signify anything?

The bootload.log file shows a normal (unhacked) boot:

Code: [Select]

BOOT0-0: OK
BOOT0-1: OK
BOOT0: Successful
BOOT9-X: Successful
BOOTB-X: Successful
BOOTF-X: Successful
BOOT*: Successful
And even after applying patchclean.bat and rebooting, the bootload.log file was the same.  So then I tried starting up the PB again, this time disconnecting power for a while, then inserting DMS, then powering on.  But still bootload.log is the same as above.

Can anyone please help me here on these points:
1. Has my PB been successfully hacked or not?
2. Why am I getting the confusing patch.log content?
3. Why is the patchverify.log file not written as well as patch.log?
4. Any other suggestions?

By the way my head unit is a VW beta, as fitted to VWs approx 1993, and the PB itself came from a VW dealer.  The PB has this model number on its base: "VAE-012-PBOX rev -".  DMM shows current firmware version as "Volkswagen/audi brand stereos, version 7.02" and the firmware property description is shown as "Properties for the in-car hardware Author: Michael Woo Version: 6.00".

Thanks very much

[sbingner]

Every patch says "Verified" so that generally means you're fully patched.

What's confusing?

[GFPWK]

Thanks for replying sbingner 

Yes I agree that the "Verified!" lines (x9) look encouraging.

I think the reason why I was confused as to whether I had completely succeeded was that I was focusing on the instructions at http://wiki.phathack.com/Windows_Hack_Procedure ...

"...review the contents of the [Phatsys]:\log folder. Specifically, look at the patchverify.log and patch.log files. If these files do not exist, review the [Phatsys]:\bootload.log file to see if the Phatbox is starting correctly."

...and because I do no have patchverify.log in my [Phatsys]:\log folder, I took this to mean that the patch had only partially succeeded.  Is that correct?

So because I did not have patchverify.log, my eye was caught by lines in patch.log where the expected and actual data differed, e.g. in line 47 of patch.log ...

    Expected: 0033 1a00    Actual: 0000 1a00

...the 1a00 part is identical, but not the 0033/0000 parts.  Perhaps the first 4 digits aren't meant to match?  Are they offsets/addresses perhaps?

Also when I wrote my first post, I was expecting that the bootload.log file after hack complete should have contained the extra line "BOOT0-2: Successful" as mentioned at http://wiki.phathack.com/Script_to_run_firmware_patch.  But now I've read that wiki page again, I think I've realised that I had misunderstood.  Is the BOOT0-2 line indicative of a DMS with no valid signature, as opposed to a hacked box that doesn't check for signature?

[WebSurfinMurf]

As per my post, I had the same confusion, "patchVerified.log" did not appear, and I did not hear the voice, when running the stand-alone scripts.
The CD scripts however did give me a voice.

[sbingner]

The dmsutils have an issue with the patch.sh -- it doesn't run any message at the end.

There are updated versions of those scripts, but we haven't released them yet.... we probably should since they're verified to be working now