Hack not working on Music Keg: messages "EJECT" and "AUX" - problem solved

[TheJohnny]

Hello,

I used the hackdms.bat on my original DMS and inserted it into my Music Keg.
All I got was "EJECT" messages.

After I run patchclean.bat on my DMS and returned to the car, the radio displayed the message "AUX".

I installed the latest firmware with the Phatnoise Music Manager - though the latest firmware was installed before - and tested the DMS with the Phatnoise tool. Chkdsk showed no failures.

A return to the car showed the "AUX" message again. The red light of the Keg is on and the green is blinking even if I turn the ignition off.

According to my manual
"EJECT" means "No disc magazine has been loaded in the changer. The disc magazine is not completely loaded." and
"AUX" means "Unsupported disc changer is connected."

What did I do wrong, what can I do next? 


Edit: title

[judb]

post the logs from the DMS and we'll try and see whats wrong.

[TheJohnny]

Code: [Select]

BOOT0-0: OK
BOOT0-1: OK
BOOT0: Successful
BOOT9: Successful
BOOTB: Successful
BOOTF: Successful
BOOT*-X: Failed
But the date is 05-04-07, so this log is from the day before yesterday when I tried to hack the Keg.

There were no files in the directory </log(s)>.

I don't get a new bootload.log at the moment.
The lights on the Keg will start blinking. When I turn the radio on, it will display "AUX" and when I turn the ignition off, the lights will still be blinking.

[judb]

the phatbox does not update timestamps as it has no internal clock source.. so you can forget about looking at date stamps.

is this the original DMS?

[TheJohnny]

Yes, it is the original DMS.

More precisely, I bought the Music Keg with the DMS used on ebay - but I think it's original.

Playing music, copying music worked fine before I wanted too much (gigabyte  )

[judb]

the only way to tell if the bootload.log is being updated is to copy a file like properties.xml into the place of bootload.log (just replace bootload.log with the xml file but don't delete the xml file you copied from)

this will cause the next boot attempt to recreate the contents of the bootload.log. 

Simply erasing the contents of bootload.log doesn't mean it will recreate it.. the system isn't that smart so to speak.

[sbingner]

Do you let it finish blinking?  Or does it never stop?

Sometimes it's just trying to update your firmware and it needs to be left for around 10-15 mins and it will work fine

[TheJohnny]

It never stops.

I waited twice for one, two hours.

The blinking is constantly without break.

[sbingner]

That, then, is bad.  Have you tried corrupting your ramdisk.sig?

[TheJohnny]

@judb

the only way to tell if the bootload.log is being updated is to copy a file like properties.xml into the place of bootload.log (just replace bootload.log with the xml file but don't delete the xml file you copied from)

You're right. my "new" bootload.log is from 12-07-04, but the content is

Code: [Select]

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

That, then, is bad.  Have you tried corrupting your ramdisk.sig?

I've read so much about corrupting the 'ramdisk.sig', but didn't try it until now.
When I went back to my car a few minutes ago with a corrupted 'ramdisk.sig' the music suddenly started playing again!!!
Thank you very much!
But what is the magic of 'ramdisk.sig'?

[sbingner]

That means the hack did not complete... you need to put the hack files back on the DMS and let the patch complete so that a valid ramdisk.sig wil work also

[TheJohnny]

So I patched my DMS again - with the same procedures as before.

The display of my stereo showed the following:

...
"Tr 1"
"Reading"
"EJECT"
"Tr 1"
"Reading"
"EJECT"

I didn't hear the hack-is-complete announcement, but the Music Keg started to play my music.

I have a patch.log in the folder 'log' but no patchverify.log.

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)
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
My bootload.log:

Code: [Select]

BOOT0-0: OK
BOOT0-1: OK
BOOT0: Successful
BOOT9-X: Successful
BOOTB-X: Successful
BOOTF-X: Successful
BOOT*: Successful
Is my Music Keg patched? Can I continue with preparing my new HDD?

Why is there no patchverify.log and what it is for?

Thanks so much and so far.


Edit: misspellings, ...

[judb]

Yes it is patched.  You may proceed.

[TheJohnny]

But why is there no 'patchverify.log' in my log folder and why didn't I hear the hack-is-complete announcement?
So is hearing music a similar sign of verfication as the hack-is-complete announcement?

And I don't have o follow nathanbeach2 advice from this thread: http://forum.phathack.com/index.php/topic,765.msg4944.html#msg4944
"You need to turn on the ignition and power up your PhatBox.  Attempt to play a song, if you hear a message stating your box is patched remove and continue to next step, otherwise wait a couple minutes then remove and reinsert dms and repeat this step once or twice."?

[TheJohnny]

I swapped my drives and created a new DMS with 'newdms.bat'.

It worked fine - no problems using the new DMS in my car!

It just takes a long time to start the Phatnoise Music Manager and for Windows Autoplay to stop, but I guess that happens when you access 100 GB over an USB1.1 connection.

Thanks judb and sbingner for the help!

P.S.: Still interested in answers for my first two questions in my post above! 

[VorTechS]

With my recent attempt at the hack - using the new wizard, I found that my stereo showed as 'playing' a track right from startup.

I left it 15 minutes, turned off the head unit, and then back on again to get a 'hack complete' announcement.

I suspect that different HU's exhibit different behaviour, as possibly do the boxes.
But it worked for you... which is cool!

[sbingner]

I don't know why it wouldn't have played that... I'll look into it eventually, but it's really hard to test these things since I have to reflash my phatbox back to stock, then reapply the patch to properly test it.   There's no good way to do that, so it takes quite a while anytime I need to try to.

[sbingner]

It wasn't playing it since the patch.sh in the current patched doesn't play it.   Good reason, huh?

Anyways, we have a dev version that vortechs and I plan on trying to test tomorrow that plays the complete version again and does some extra logging as well.  It also puts the patchverify.log and patchwrite.log files back.

[TheJohnny]

That's a very good reason!