Original DMS says patch applied but unable to get new DMS to work (Long)

[girick]

Ok you phathacking gurus, I have a dilemna.  Took my genuine original 20GB DMS and applied the patch to it using the Phathack DMS Tools V2.10 which went off without a hitch.  Took my patched DMS, plugged it into my Phatbox, and ran the patch.  Received the voice prompt that the patch was successfully applied and took my DMS back to my computer and checked the log files.  The patchwrite.log file says:

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)
Flash chip reports manufacturer id=0001, device id=22bf
offsets 0x555 and 0x2aa 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: 0033 1a00
Match! Programming...
Wrote 0000
Patch 2 @ 0bec: make rc.sh signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0026 1a00    Actual: 0026 1a00
Match! Programming...
Wrote 0000
Patch 3 @ 0c20: make phatd signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0019 1a00    Actual: 0019 1a00
Match! Programming...
Wrote 0000
Patch 4 @ 0c54: make linux signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 000c 1a00    Actual: 000c 1a00
Match! Programming...
Wrote 0000
Patch 5 @ 0354: make ramdisk invalid signature return 0 instead of 0xFFFFFFFF: [movlne r0, 0xFFFFFFFF -> movlne r0, #0]
Expected: 0000 13e0    Actual: 0000 13e0
Match! Programming...
Wrote 13a0
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)
Flash chip reports manufacturer id=0001, device id=22bf
offsets 0x555 and 0x2aa 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: 0001 e350
Match! Programming...
Wrote 0000
Patch 7 @ 0358: make ramdisk valid signature return 0 instead of 1: [moveq r0, #1 -> moveq r0, #0]
Expected: 0001 03a0    Actual: 0001 03a0
Match! Programming...
Wrote 0000
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: 02db eb00
Match! Programming...
Wrote 0000
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: 02f7 eb00
Match! Programming...
Wrote 0000

and the patchverify.log says

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: 0033 1a00
Unverified!
Patch 2 @ 0bec: make rc.sh signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0000 1a00    Actual: 0026 1a00
Unverified!
Patch 3 @ 0c20: make phatd signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0000 1a00    Actual: 0019 1a00
Unverified!
Patch 4 @ 0c54: make linux signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0000 1a00    Actual: 000c 1a00
Unverified!
Patch 5 @ 0354: make ramdisk invalid signature return 0 instead of 0xFFFFFFFF: [movlne r0, 0xFFFFFFFF -> movlne r0, #0]
Expected: 0000 13a0    Actual: 0000 13e0
Unverified!
Patch 6 @ 0c80: make ramdisk signature check verify 0 instead of 1: [cmp r0, #1 -> cmp r0, #0]
Expected: 0000 e350    Actual: 0001 e350
Unverified!
Patch 7 @ 0358: make ramdisk valid signature return 0 instead of 1: [moveq r0, #1 -> moveq r0, #0]
Expected: 0000 03a0    Actual: 0001 03a0
Unverified!
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: 02db eb00
Unverified!
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: 02f7 eb00
Unverified!

and the patch.log file says:

2048+0 records in
2048+0 records out
Verifying patch progress
There are  patches not yet applied
Beginning patch process
Patching to ramdisk corruption
Corrupting ramdisk
Completing Patch
Patch complete

so I attempted to patch the Phatbox again and the patchverify.log file now says

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!

and the patch.log file says:

Verifying patch progress
This system is already patched

on each subsequent attempt to patch my Phatbox.  I even went so far as to format the PHTSYS partition on my original DMS, loaded non-hacked firmware and selected the 'Reflash box with firmware' option, put it in my Phatbox, waited the required 5 to 10 minutes for the firmware to update and my box seemed fine by playing the mp3's that I had on the DMS still.  Then I took my original DMS, ran the dms hack wizard again, updated the Phatbox again, and the patch.log file still says:

2048+0 records in
2048+0 records out
Verifying patch progress
This system is already patched

So I am now completely confused, my Phatbox says it's been patched even after I reinstall un-hacked firmware but I still can't get my new 40GB DMS (I know it's not a big step but it was out of my old laptop) to work.  Please help.  I have the PHTSYS partition files zipped up and ready to go if requested.

Thanks,
Greg

[S80_UK]

I understand the confusion...

The information that you are missing is that the patch does not patch the firmware that is installed from the DMS.  It patches a few locations in a separate piece of firmware in the Phatbox which is responsible for verifying the validity of the DMS.  So reloading firmware from the DMS can never un-patch your box.

As far as I can see your box is now successfully patched. 

You don't say what happens with your new DMS...

Les.

[girick]

Les, thanks for responding.

When I put the new drive in the DMS and use the PhatHack DMS Tools v2.10 to 'Create NewDMS/Update Firmware" it creates the PHTSYS and PHTDTA partitions with no issues AFAIK and it works flawlessly in Media Manager and Music Manager but when I put it in the Phatbox I get the dreaded "CD-X No Disc" message and it kicks over to AM.

One thing I just noticed was that the PhatHack DMS Tools created the PHTSYS partition as only 64MB and not the 260MB that my original DMS has for that partition size.  I am trying the Tools again to create a new DMS to see if it creates the PHTSYS partition of the same size as the PHTSYS partition on my original DMS.  If it doesn't I am then going to try and create the new DMS with the Phatnoise DMS cd.

Update:  Just finised creating the new DMS with the Tools v2.10 and it created the PHTSYS partition as 64MB again.  Could this be my problem?

Thanks again,
Greg

[sbingner]

no, it couldn't be... did you load music to it?  Could it be set as slave?

[girick]

I've been able to load music on it with both Media Manager and Music Manager, but when I put it in the Phatbox I get the "CD-X No Disc" error message and nothing gets written to the bootload.log file.

[S80_UK]

Hi,

Sam is right - 64MB makes no difference.  The Linux kernel and software is pretty small.  Even at 64MB most of PHTSYS is empty space.  His other comment referred to the settings of your new drive.  IDE drives can be set as master or slave, normally by means of a link pushed on to a couple of pins - refer to the drive - the settings are often printed on the label.  Some drives also have a CS setting (cable select).  If in doubt, the drive make probably has the link info on their web site.  For the drive to work in the Phatbox it must be set to master (not slave, not cable select).  It is possible that it may still be recognised by PMM even if it is set wrongly.  BTW, it shouldn't matter too much, but could you tell us the type of drive that you are trying to use?

Lastly, was a bootload.log file present?  If not, can you create a dummy file by taking a copy of any small file (a ew K big is enough) and renaming to bootload.log  - make sure it's not read-only or anything like that.  After a successful boot the dummy file will be overwritten and should look like this...

BOOT0-0: OK
BOOT0-1: OK
BOOT0: Successful
BOOT9: Successful
BOOTB: Successful
BOOTF: Successful
BOOT*: Successful

Good luck!

Les.

[girick]

Les,

The drive is a Toshiba MK4026GAX 40GB 5400RPM drive.  I have finished running the BootCD from Phatnoise to create a new DMS on the MK4026GAX, created a bootload.log file by copying/renaming one of the 1k files on the DMS, and am about to go try it again and will report back what the bootload.log file says.

Thanks,
Greg

[girick]

Les, verified on the Toshiba site that no jumpers were required for the hdd to be master.

Still not booting off the new hdd.  Tried the procedure 4 times by unplugging the cable, waiting 10 minutes, plugging cable back in, turning on ignition, and inserting the DMS.  Each time it would give the following light sequence: red light on, green light on for ~1 min, green light does the 2 flash then wait and then 2 flash, then would 3 flash and immediately go to the rapid green flash.  Also, I tried using VorTechS procedure to manually add the files to the PHTSYS partition:

Firstly, you mention you 'extracted the firmware'... but you might need to re-do this in a specific order.

Delete the contents of the PHTSYS directory, but leave the partition intact.
I'll assume that you have downloaded the firmware from the relevant PhatHack download links, and that you have chosen the Kenwood one v13.01.

If you haven't, please do that first.

Then:

1) Open up 'system_0x02ff_13_01_RC.zip'
2) Extract the files:

'linux'
'ramdisk'
'linux.sig'
'ramdisk.sig'

onto the PHTSYS partition, in the order listed!

3) Extract the remaining files onto the partition.  DO NOT re-extract the files listed above [in case windows changes where they sit on the disk]

4) Extract the contents of 'daemon_0x02ff_13_01_RC.zip' onto the PHTSYS partition
5) Extract the contents of 'headunit_0x02ff_13_01_RC.zip' onto the PHTSYS partition
6) Extract the contents of 'player_0x02ff_13_01_RC.zip' onto the PHTSYS partition

I'll assume that the PhatBox already has the correct firmware loaded onto it.
So:

7) Delete the file 'forceupdate' and 'forcesettings' from the PHTSYS partition

Now, at this point you might want to fire up PMM and just check that it sees the DMS without any issues.  Don't create a playlist - PMM will create a default one with the PhatNoise startup sound.  Save and Eject to make sure the 'new' playlist is saved on the DMS correctly.

Assuming everything goes smooth up to this point, let's turn our attention to the PhatBox.

1) With your engine off, make sure there is no DMS in the PhatBox and then disconnect the cable from the back of the PhatBox and wait a couple of minutes.
2) Re-connect the cable
3) Insert the DMS into the PhatBox
4) Turn your ignition to power up the Head Unit
5) Use the Head Unit to select the PhatBox

If this hasn't kicked it into gear, just take a look at the lights on the PhatBox - make sure we don't have solid green, and at there is at least some activity.

If necessary repeat the above, waiting at least 30 seconds before removing the DMS from the Phatbox when you do.

If the repeat fails, then stick the DMS back into the Cradle and re-copy the 'forceupdate' and 'forcesettings' files from 'system_0x02ff_13_01_RC.zip' onto the PHTSYS partition and repeat the instructions above, twice if necessary.

If after all this we've gotten no-where, we can still try something else - so don't panic!

but got the same results.  Also, I had created a 6KB bootload.log file and the contents of the file were never changed so I ASFIK the Phatbox never booted with the new hdd.

I just remembered that I have a 12GB Fujitsu drive that I was using in my MediaTank (for dumping camera memory cards to) so I thought I might have a go at seeing if that drive will work just as a test.

Thanks for all the help and information.  I'm once again at that point of not knowing how to proceed.

Greg

[sbingner]

Each time it would give the following light sequence: red light on, green light on for ~1 min, green light does the 2 flash then wait and then 2 flash, then would 3 flash and immediately go to the rapid green flash. 

That's a very strange code... the blink codes mean specific errors, but what you said doesn't seem to fit any I know.  The rapid blinking light means it decided it couldn't boot... but you'll usually only see the lights come on, then an error code, then the blinking LED of death. 

3 blinks followed by LED of death = unable to reset HDD

2 blinks = ATA_ERROR flag was set... after it reset the drive - it will try again

What you said COULD make sense... but it would seem to indicate that somehow your drive doesn't like how the phatbox firmware is trying to initialize it.  Which seems pretty strange to me.

[girick]

Well, my 12GB drive works perfectly so I know my box is patched.  The way I did it was to create the partitions using the hack tools v2.10, install the 7.02 VW firmware via the tools.  First time I tried to boot it wouldn't go so I created a 6KB bootload.log file and corrupted the ramdisk.sig file and then it started up as soon as I put the DMS in the box as indicated by repeating the Welcome playlist message and the welcome sound over and over.  Too bad this drive would be a giant leap backwards .

I'm next going to try the exact same procedure on the 40GB Toshiba drive to see if it works but I'm not hopeful.  I got this drive out of my retired laptop from work, unfortunately we have put encryption on all of our laptops but I blew away the partitions and it seemed to work fine but maybe there is some part of the encryption still lingering on the disk.

Wish me luck and thanks for all the help so far.

Greg

[girick]

OK, tried the 40GB Toshiba again and the same sequencing of lights, red on, green on for ~1 min, then green doing the double flash 4 times then a triple flash then the fast flash and at this point if I select CD I get the NO CD message, during the time before the fast flashing I will get the CD-X NO MAGAZINE error.  I'm going to have to assume that this drive is not compatible either due to design or the encryption that was previously on it has rendered it unsuitable for Phatbox use.

Thanks for all the pointers, support, and encouragement.  I know my Phatbox is patched as evidenced by the 12GB Fujitus working perfectly so all I have to do is go pick up a 120GB drive and not worry about it.

Thanks,
Greg

[sbingner]

Can you post what your drive make and model number were?  In case something similar happens again...

[S80_UK]

He already did...  Toshiba MK4026GAX 40GB 5400RPM  -  Looks pretty standard to me.  My guess it that the encryption applied in it's previous use operates from master boot record onwards, and that is possibly causing the hack tools to write stuff that the box does not recognise.  I am not sure whether the current hack tools overwrite the first megabyte...?  If not, then that might be worth a shot - using the dd command to see if that gets around the issue.  The partitions would get screwed again, but then the next try with the tools may then make them work correctly.  Other than that, I'm out of ideas.

Happy Christmas, All.

Les.

[sbingner]

I really should re-read the whole thing before asking for stupid stuff...

Anyway, there is only one method of 'encryption' that should be able to do that which would be locking the drive.  If it were locked, it wouldn't work in the computer either... unless of coure this computer has some encryption software on it that is writing it in an encrypted format because that drive was enabled for encryption.  Does this system have the encryption software/hardware you mentioned?  Otherwise, any encryption would have been wiped when it got formatted...

[S80_UK]

Maybe...  I'm no expert on that stuff.     I was just thinking out loud...

[girick]

The encryption software we're using is Encryption Plus Hard Disk by PC Guardian.  After I deleted all partitions and used the hack tools on it I was able to use it in a 2 other computers that had no encryption both with an adapter to a 40 pin ide header and while in the DMS cartridge and the USB dock.  The idea of using dd to try and correct this issue sounds appealling, how do I get dd and do instructions come with it?

Thanks and Merry Christmas,
Greg

[sbingner]

I don't think it could be doing what you describe as a result of the encryption software.

If you want to be sure, use ghost or something similar (like dd, but dd is harder to use) to image your working DMS to the new drive.  Make sure you do a full drive image rather than a partition image.

dd stands for Data Dumper - it is a very basic tool that will read data from one place and write it another place.  It can be used to create an image of a drive then restore it etc.  You can find dd at http://uranus.it.swin.edu.au/~jn/linux/rawwrite/index.htm or from http://phatos.svn.sourceforge.net/viewvc/*checkout*/phatos/dmsutils/trunk/dd.exe

PS: You don't need to worry about ramdisk.sig -- your box is patched past that point so corrupting it couldnt' have had anything to do with getting that drive to work

[VorTechS]

You'll also find dd installed in the DMS_Utils directory of the latest Windows hack tools....