PhatPatch - Firmware Patcher!!!!!!!!!!!!

[Firefox]

Great job guys! Freedom at last...

Can I suggest that anyone who makes use of this patch make a donation to the running of this site as per this earlier thread...

http://forum.phathack.com/cgi-bin/yabb/YaBB.cgi?board=help;action=display;num=1119315190

It's the least we can do to say thanks!

Edit (Paul): I appreciate the gesture and will put to good use any donations that come in as a result if this post.  However, let me make it very clear that Firefox said "DONATION."  In no way are you asked, required, or expected to "Pay" any amount of money for any of the information on this board.  Remember the user agreement to become a part of this forum which stated that "No information contained in or brought to light by this forum will be used for commercial purposes."  Thanks - and sorry to hijack your post!

[Matt Dralle]

Sony Phatbox DMS OWN3D!

Just spun up an 80GB OEM 2.5" drive from Fry's in the Phatbox.  Works GREAT!!  Excellent work, boys!  Also, I was able to salvage an original 60GB drive from Phatbox that had been rendered useless by a repartition/format under Windows.  Below are a couple of comments on the process along with a dump of the generated logfiles in case you are interested.

Thanks again, guys!  I bought this 80GB drive back a while ago and was in disbelieve that it wouldn't work and even more increduous when I found out it was because of the protection BS.  Woohoo!

Matt

* Note that the first half of the instructions with respect to patching the firmware must be done with a known good and working standard DMS

* Didn't work the first try.  Got "PLY1-FlashPhatbox" then time count.  Never went to the second play list.  Powercycled everything, then got "" playlist on "disc 1" for about 3 seconds, then jumped to Playlist2 with music.

* On second try, there were two files in the "log" directory:

-------------------------------------------------------------
patch.log:
--------------------------begin----------------------------
backing up drive signature
2048+0 records in
2048+0 records out
backup drive sig complete
starting patch
/dos/backup/patch.sh: 8: Syntax error: Bad fd number
backing up drive signature
2048+0 records in
2048+0 records out
backup drive sig complete
starting patch
/dos/backup/patch.sh: 8: Syntax error: Bad fd number
----------------------------end----------------------------



-------------------------------------------------------------
phatpatch.log:
--------------------------begin----------------------------
PhatPatch v0.2 -bushing
first 2 words of flash=c102 0025
writing auto-id command (AA, 55, 90)
Flash chip reports manufacturer id=0004, device id=22ba
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
Mismatch!
Verifying:
Patch 1 @ 0bb8: make drive signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0000 1a00    Actual: 0000 1a00
Verified!
----------------------------end----------------------------

[judb]

Interesting that the patch got a bad device number error the first time it ran.  hmm.. any ideas bushing?

The rest of the logs look good though.  Glad its working for you.  I'll update the wiki with the info saying a KNOWN GOOD drive to make that crystal clear.

[Matt Dralle]

The logs above are from the *successful* update.  The first failed update didn't generate any logs...

Matt

[RobM]

The logs above are from the *successful* update.  The first failed update didn't generate any logs...

Matt

Actually, from the logs you posted it looks like it worked the first time around.

The kernel might just have "oops"ed after successfully writing the flash the first time.

[judb]

It should also be noted that in the very early version of the scripts it would replace your flacplay with the original version if you followed the instructions.  now I have removed that function incase people have issues with the first attempt at flashing.

If you choose to copy the PHTSYS from the old dms to the new dms then make sure you remove the flacplay and flacplay.sig that you copied from my scripts so it doesnt keep patching your flash .. it can cause the box to freak out when you flash it sometimes so you dont want to have it do it over and over.

[sbingner]

It should also be noted that in the very early version of the scripts it would replace your flacplay with the original version if you followed the instructions.  now I have removed that function incase people have issues with the first attempt at flashing.

If you choose to copy the PHTSYS from the old dms to the new dms then make sure you remove the flacplay and flacplay.sig that you copied from my scripts so it doesnt keep patching your flash .. it can cause the box to freak out when you flash it sometimes so you dont want to have it do it over and over.

Well, once it's modified it won't try to modify it again so it shouldnt cause any problems.... but it's still not a good idea

[Oaf]

I had the same experience as Matt with the  "8: Syntax error: Bad fd number" and "Mismatch!" messages (with a Success the second time round).

First time the Phatbox just sat there for several minutes flashing the disc light and no audio. I jumped to another playlist (audio played as normal) so then I shut it down. I guessed either it was unpatched (and OK) or patched but hadn't reported it. However the fact that it had "hung" suggested that the process probably hadn't worked.

So I then disconnected the Phatbox, powered it up again and selected the "flash" playlist for a second time - and it worked exactly as described... maybe the flash routine is slightly glitchy at the moment but it doesn't appear to do any damage when it doesn't work (if, in fact it isn't working the first time).

Btw mine is an Audi Phatbox, (80GB Samsung disc!)

[todd1010]

I've got firmware version 3950.7 for my Audi Phatbox. Is this the lastest and where can we find the lastest firmware release? I thought my latest Audi firmware was version 7.02, and that 3950.07 was what I got from the radio head unit in the Function Menu.

[judb]

just put the DMS into the cradle and in the PMM use the update feature to get the most recent firmware downloaded.

[todd1010]

In this step:

From PHTSYS\backup copy p0.* to PHTDTA\profiles\default ... This will make the first playlist that the phatbox plays execute the patch.


Do I copy all 4 of these files to that folder?

p0.sig
p0
P0.idx
p0.pbx


I also noticed that in the file P0.idx in your replacement files that the letter "P" is capitalized. Did you mean to capitalize that letter?

I'm asking A LOT of question because I'm re-writing the HOW TO from a beginners stand point.

[bushing]

I just wanted to post a little text about the log file and what you should expect to see.


PhatPatch v0.2 -bushing
first 2 words of flash=c102 0025

This should always read like that - c102 0025 -- and indicates that it successfully found the flash chip.


writing auto-id command (AA, 55, 90)
Flash chip reports manufacturer id=0004, device id=22ba

These two codes indicate the manufacturer and model number of the flash chip -- they shouldn't affect anything, but I'm trying to track which chips they've put into these things, and it could help if some chips refuse to flash.

Go look here: http://wiki.phathack.com/Hardware_FAQ#Flash_ROM, and PM me if you have an ID code not listed there, and I'll add it.

Code: [Select]


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
Mismatch!


Here, it's checking to make sure that the location it's about to patch is what we expect it to be.  If it's not, it won't write anything.

Regarless, it will press on:

Code: [Select]


Verifying:
Patch 1 @ 0bb8: make drive signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0000 1a00    Actual: 0000 1a00
Verified!


Here, the "Verified" part indicates that the chip has successfully been patched.  What this indicates is that the chip had already been patched before the program ran.  

The reason you'll see this is, as I mentioned at the top of the thread, the PhatBox usually crashes right after flashing, for some unknown reason.  When it does that, it won't usually leave a log file - so running it again will product the above log file.

[judb]

In this step:

From PHTSYS\backup copy p0.* to PHTDTA\profiles\default ... This will make the first playlist that the phatbox plays execute the patch.


Do I copy all 4 of these files to that folder?

p0.sig
p0
P0.idx
p0.pbx


I also noticed that in the file P0.idx in your replacement files that the letter "P" is capitalized. Did you mean to capitalize that letter?

I'm asking A LOT of question because I'm re-writing the HOW TO from a beginners stand point.

yes you are correct, copy all files pX.ZZZ ... the PMM created those files, not me, so as for the P vs p i dont think it matters.  let me know what you have come up with and I'll check it out and update the wiki with it.  thanks!

[todd1010]

So do I navigate on my DMS, when its in the car. To "Playlist 1" and thats the script that runs the flash?

If so I did that and it first said "Corrupt Track" and went on to the "Playlist 2" on my DMS. I went back to playlist 1 again and this time it didn't play any songs but just scrolled thru a bunch of numbers like 1, 2, 3, 4, 5, etc. and then went on to playlist 2 again. I paused the DMS for a minute and then turned it off, waited for the lights to go out on the Phatbox. I brought it inside put it in the DMS cradle.


I didn't/don't see a file called:     bootload.log


But I did see one called "log" on the PHTSYS partition, is that it?

I looked in that "log" folder on the PHTSYS partition where there were a couple files.

1) logs-go-here: where nothing was written in it.

2) patch: acking up drive signature
2048+0 records in
2048+0 records out
backup drive sig complete
starting patch
/dos/backup/patch.sh: 8: Syntax error: Bad fd number
backing up drive signature
2048+0 records in
2048+0 records out
backup drive sig complete
starting patch
/dos/backup/patch.sh: 8: Syntax error: Bad fd number
backing up drive signature
2048+0 records in
2048+0 records out
backup drive sig complete
starting patch
/dos/backup/patch.sh: 8: Syntax error: Bad fd number
backing up drive signature
2048+0 records in
2048+0 records out
backup drive sig complete
starting patch
/dos/backup/patch.sh: 8: Syntax error: Bad fd number
backing up drive signature
2048+0 records in
2048+0 records out
backup drive sig complete
starting patch
/dos/backup/patch.sh: 8: Syntax error: Bad fd number
backing up drive signature
2048+0 records in
2048+0 records out
backup drive sig complete
starting patch
/dos/backup/patch.sh: 8: Syntax error: Bad fd number
backing up drive signature
2048+0 records in
2048+0 records out
backup drive sig complete
starting patch
/dos/backup/patch.sh: 8: Syntax error: Bad fd number


3) phatpatch: PhatPatch v0.2 -bushing
first 2 words of flash=c102 0025
writing auto-id command (AA, 55, 90)
Flash chip reports manufacturer id=0004, device id=22bf
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
Mismatch!
Verifying:
Patch 1 @ 0bb8: make drive signature check always succeed: [bne verify_sig_failed -> bne PC+1]
Expected: 0000 1a00    Actual: 0000 1a00
Verified!




Did my DMS flash the Phatbox correctly?

[RickG]

If you apply this patch can you update your firmaware at a later date if a newer version comes available?

[judb]

It depends on if phatnoise decided to try and attack our method of DMS hacking or not.  I would say at this point its 50/50 ...

That said, I don't expect many if any firmware updates out of phatnoise in the future as they are really not developing for this product line anymore.. they stated as much in as few of words on the now dead forums they used to host.  Sorry.

[judb]

MTS yes it looks as though it did.  The verified line at the bottom of the second log shows it verified the patch is applied.

Also, we should have a new CD based method available tomorrow or the next day at the latest to simplify the work involved so that anyone can do this mod without really knowing much other than plugging the DMS in and using a phillips head screwdriver to swap the drives out.

[Surgeon]

Great work guys!

A few of questions if I may since I like to understand what's happening when I apply patches like these...

First, the patch itself simply changes a "jmp (condition), offset" instruction to now have a zero-offset, effectively removing the unwanted "jmp" effect, correct?

Second, we are able to accomplish this without first "erasing" the eeprom because we are simply "turning off" additional bits, whereas if we needed to "set" bits in the code we would first have to "erase" the flash block back to all 0xff and then re-program the entire block, correct? This implies that once "patched" there is no going back until a full "erase-block & reprogram" util is developed, right?

Third, is there not a firmware "cksum" somewhere that should also be updated to reflect the changes made to the code? Has this "patch" been tested through full "cold-start" (usually when a POST is run to verify the firmware)?

Congrats again on the *TERRIFIC* job done by everyone involved!

-Surgeon-

[sbingner]

Great work guys!

A few of questions if I may since I like to understand what's happening when I apply patches like these...

First, the patch itself simply changes a "jmp (condition), offset" instruction to now have a zero-offset, effectively removing the unwanted "jmp" effect, correct?

Second, we are able to accomplish this without first "erasing" the eeprom because we are simply "turning off" additional bits, whereas if we needed to "set" bits in the code we would first have to "erase" the flash block back to all 0xff and then re-program the entire block, correct? This implies that once "patched" there is no going back until a full "erase-block & reprogram" util is developed, right?

Third, is there not a firmware "cksum" somewhere that should also be updated to reflect the changes made to the code? Has this "patch" been tested through full "cold-start" (usually when a POST is run to verify the firmware)?

Congrats again on the *TERRIFIC* job done by everyone involved!

-Surgeon-

I've erased and reprogrammed my box, but otherwise you're essentially correct.   Erasing and reprogramming REQUIRES a serial port since you get constant segfaults and kernel panics when running it.   It should be trivial to write a loader to flash a file off the hard drive to the firmware before the kernel starts.... there appears to be a kernel bug that's making life hard on us but it could be something we're missing. like a flakey compiler

[judb]

yes the patch works via a cold start ...

There are functions that do check the firmware... as the wiki states this process will break Audible Audio files most likely..

I don't use any Audible so I can't verify this, its only suppisition.  however every other feature works just great.