Author Topic: banging my head against the wall trying to create a new 120 GB DMS (Read 31167 times)

chico · « **Reply #20 on:** January 06, 2008, 08:22:54 pm »

I just ran the hack procedure again. Here's the contents of the bootload log:

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

Here's the contents of the patch log:

Verifying patch progress
This system is already patched

: 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)
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: 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

: 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)
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: 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

Is the box hacked or not? Where do I go from here?

VorTechS · « **Reply #21 on:** January 07, 2008, 07:51:28 am »

The hack is applied. The logs shows the first time, it was applied and one the second execution its telling you the each of hacks in the process was already applied.

chico · « **Reply #22 on:** January 07, 2008, 12:09:30 pm »

That's what I thought. Any ideas on how to get a hacked DMS to actually work? The original runs just fine, but I get the CD-X No CD error every time I try a hacked cartridge. Should I try reflashing the phatbox with the firmware or would that be a bad idea?

chico · « **Reply #23 on:** January 07, 2008, 05:58:37 pm »

Something I just thought of that might help...or not. I still have the corrupt ramdisk.sig file on the original DMS that I used to hack the box. If I restore the original ramdisk.sig file and boot the phatbox with the original DMS, should the box recognize a hacked DMS after that? At this point it seems like there's one little, obscure thing I'm missing that's making the new DMS not work.

sbingner · « **Reply #24 on:** January 08, 2008, 10:07:48 am »

Your problem will be with the NEW DMS.... nothing you do with the old dms matters now. What your problem may be, I don't know. As long as it's properly partitioned and formatted it should work fine. I have heard reports of some people not being able to get certain drives to work at all, but I don't know why that would have been. Do you have another drive to try?

chico · « **Reply #25 on:** January 08, 2008, 02:08:27 pm »

I started with the 120 GB WD drive. After having the problems I've had, I switched to the 10 GB Toshiba drive that originally came in that DMS cartridge (while not messing with the original 20 GB Toshiba drive in my original DMS), along with working in XP only and not Vista. Since I can't get an original Toshiba drive to work, it would seem that the hard drive isn't the problem...or at least isn't the only problem. Would reflashing the box with the VW 7.02 firmware be a good idea?

I did accidentally flash the box with the firmware because I forgot to remove the forceupdate file when I created a new DMS. In the hacking procedure it says to remove the forceupdate and forceupdate.settings files (or something close to that anyway). I noticed that there isn't a forceupdate settings file in the firmware files. Is that a problem?

sbingner · « **Reply #26 on:** January 08, 2008, 05:59:04 pm »

That's not a problem... just make sure you let it COMPLETE the firmware update

--- you can reflash it if you like, it won't hurt.

Do you get a blink code with the new drive? Have you tried creating a bootload.log file on it? Do you have MUSIC on the new DMS? Have you tried adding debug rc.sh files?

chico · « **Reply #27 on:** January 08, 2008, 06:47:34 pm »

With the new drive, the green light blinks once, there's a pause, it blinks twice, there's another pause, it blinks again and the phatbox shuts off. I'll try doing the firmware reflash tonight to see if that fixes things. I've looked at the bootload.log file after my latests attempt to hack the box (where it told me that the box had already been hacked) and all the boot checks were successful.

I hadn't put any music on the DMS at all in my earlier attempts, but last night I went through the DMS creation process again with the 10 GB drive and put some music on it. I haven't had time to test that out yet though. I was expecting to get the "corrupt track" error without music.

This is the first I've heard of a debug rc.sh file. I will look into that if the test tonight is unsuccessful.

Thanks again for the help.

sbingner · « **Reply #28 on:** January 08, 2008, 11:09:38 pm »

If you have no music on it it will say no disc or no cd etc... it's hard to have a track be corrupt when it doesn't exist

chico · « **Reply #29 on:** January 09, 2008, 02:08:51 am »

Well, between reflashing the phatbox with the firmware and actually putting music on the drive I was able to get the 10 GB hard drive to work. When I swapped the 120 GB drive into the DMS and set it up, it didn't work. When I put the cartridge in the phatbox, the green light blinked five times and then three times and then the box shut off. I got the CD-X No Magazine error on the headunit. It appears that the blink sequence indicates that there was a write error and then an error communicating with the IDE adapter. Since the IDE adapter worked just fine with the 10 GB drive, is it safe to assume I need to contact Western Digital at this point to get a new drive?

Thanks again everybody for your help. I can finally see some light at the end of the tunnel.

sbingner · « **Reply #30 on:** January 09, 2008, 08:31:19 am »

Actually 5 isn't exactly unable to write... it's more unable to seek or something... essentially it tried to read a sector and the drive didn't accept the command to read that sector for some reason. I doubt you have a hardware issue with the actual HDD, or it wouldn't work in windows either. Try formatting your PHTSYS, and loading up the files in a specific order - if you tell the Windows Patch Tool to create a new DMS for you, it should put it on properly... otherwise you can copy up 1. linux 2. linux.sig 3. ramdisk 4. ramdisk.sig 5. the rest of the contents of PHTSYS

VorTechS · « **Reply #31 on:** January 09, 2008, 09:04:40 am »

Yup, the Windows hack tool loads the files up in that specific order after partitioning the disk.
Perhaps there's something I need to change in the formatting to mark bad blocks?

chico · « **Reply #32 on:** January 09, 2008, 12:33:37 pm »

Okay. Well, I'll try things again tonight with it to see how it goes. That it takes Vista up to 30 minutes to recognize the partitions on the WD drive makes me think that the drive isn't good though either. I don't have that problem in Vista with either of the other drives I've used.

Something else I thought of this morning is that I created the DMS and then deleted the files in the PHTSYS partition. I then copied the files from the PHTSYS partition of my original DMS onto that partition. If I remember correctly, I think that I just copied all the files at once. I'll try copying those four files in the order you've listed first and then the rest of the PHTSYS files. That's the only thing I can think of that I did differently (other than having more space in PHTDTA to load all the music) between creating the 10 GB DMS and the 120 GB DMS last night.

sbingner · « **Reply #33 on:** January 09, 2008, 06:35:11 pm »

do a scandisk and see if it finds any bad blocks... if it does, get it replaced... that COULD explain it

chico · « **Reply #34 on:** January 09, 2008, 07:25:28 pm »

Okay, running scandisk will be the next step. If that checks out, I'll redo the DMS and try it again.

chico · « **Reply #35 on:** January 10, 2008, 02:02:45 am »

Well, I scanned the disk and no errors were reported so I added the linux, linux.sig, ramdisk, and ramdisk.sig files to the PHTSYS partition. I then copied the rest of the PHTSYS files. I then copied the contents of the PHTDTA partition. After unplugging the phatbox from the car for 10 seconds, I plugged it back in and put the 120 GB DMS cartridge in. I selected CD on the HU and heard "welcome to the phatnoise car audio system". I finally have a working 120 GB DMS!! Now I just have to straighten out some playlist and PMM issues and I'll be all set. Thanks again to everyone who helped.

VorTechS · « **Reply #36 on:** January 10, 2008, 07:33:00 am »

Just out of interest, which linux did you put on the disk. The original or the LBA version?

chico · « **Reply #37 on:** January 10, 2008, 12:18:19 pm »

Every file I copied to the new DMS cartridge (both PHTSYS and PHTDTA) came from the original 20 GB DMS that I had been previously using.

girick · « **Reply #38 on:** January 13, 2008, 09:15:33 am »

I'm beginning to think that it might be the 120GB WD drive. I purchased a 120GB 2.5" Scorpio drive from the big blue electronics store (Best***), and had issues when trying to create a new DMS drive with it. During the creation process it would seem to be very jerky during the WMI process (don't remember the exact display but think it was 'Searching for WMI' or something) and would end up creating 2 partitions named PHTDTA. I renamed the 69MB partition to PHTSYS and manually copied the files to it per this posting from VorTechS. I would then try and open the DMS in Media Manager V3.92 and would get 'Delayed Write Errors' in Windows XP.

This happened numerous times and before reading this thread I started thinking it was an issue with the SATA raid on my eVGA motherboard since the SATA drives are listed as USB drives and are hotpluggable on this MB. I took the drive back and replaced it with a 160GB Hitachi and that gave me the same indications and results so I loaded the Phathack tools onto my work laptop and created the new DMS drive on that with no issues. I'm starting to think that I may have been experiencing 2 seperate problems, the first is with the SATA raid and the fact that they are shown as USB drives might have been confusing the PhatHack Tools and the second was just the 120GB WD Scorpio drive. After I replaced the drive I haven't had a single issue with it.

sbingner · « **Reply #39 on:** January 13, 2008, 11:27:21 am »

It's connected via USB so it is USB as far as you are concerned. If you're getting delayed write failed, it could be a bad cradle, incompatible cradle, or bad drive. I believe that with >127GB drives you need the USB 2.0 cradle. I got all kinds of errors when I tried to use the 1.0 cradle...

News:

Author Topic: banging my head against the wall trying to create a new 120 GB DMS (Read 31167 times)