Problems patching Keg - HELP!!

[A543]

From what I have seen. Viot once installed always works no matter what dms is used something is installed in rom on the phatbox.

and after the firmware has loaded I STILL have VIOT

Ok, based on these quotes it seems that some permanent change is made to the Keg when VIOT is installed. Is it possible that when the VIOT plugin folder is found on the DMS the software performs a dumb update of the ROM every time the box is started, which normally doesn't harm anything, but in this case is putting the ROM (and/or something else) into a "write" state that interferes with the patch process trying to access the chips it needs? Notice the logs show the chip not responding to the chip id query.
If this were the case the patch should work if the box is powered up fresh, no plugins folders, fresh firmware, etc.
Now if the box checks for a certain value in the VIOT ROM address to determine if VIOT is installed (instead of looking for the plugin folder) and then writes to alter the firmware, again every time the box powers up, and that interferes with the patch, there'd be no way to get the patch to work without modifying Phatnoise's software or reversing the VIOT ROM patch.
Also, I can't see why the AAC plugin would alter the box permanently in any way if the plugin follows the DMS and not the box.

[sbingner]

VIOT will not always stay enabled... I have turned it on and off a number of times while doing research on how the plugin system works.  When it authorizes the VIOT plugin it changes the operating mode of the CPLD, the CPLD will stay in that mode until reset at which time it will again default to the non-SSA mode until VIOT or SSA is enabled.   You can verify this yourself via level 10 logfiles... I was going to paste the relevant info here but I cant connect to my home system from work.   It DOES save some info in plugins.dat, and unless that is removed it won't do a full reauthorization of all plugins.

Sam

[A543]

it changes the operating mode of the CPLD

This altered state is basically what I was getting at. Is it possible that this 'mode' is interfering with the patch?
Another thought I had, when one has the AAC plugin, does the AADEC file get changed? If so, maybe when someone reformats their DMS and uses PMM to set it up, PMM, knowing this person has the plugin, copies over (or changes) the AADEC file automatically, so even a fresh setup will still interfere with the patch.  Using a PMM installation that hasn't had any plugins installed to set up a fresh DMS might get around this.

[sbingner]

the aac plugin uses a different file for playing of aac files...  it doesn't modify aadec

Code: [Select]

-rwxr--r--  1 root root 136324 Jan  6  2005 aacplay
-rwxr--r--  1 root root    240 Jan  6  2005 aacplay.sig

If I can talk to somebody whos having the problem I'm sure we can figure it out relatively quickly

Oh yea, my box had the AAC plugin on it when I flashed it originally

[Firefox]

VIOT will not always stay enabled... I have turned it on and off a number of times while doing research on how the plugin system works.  When it authorizes the VIOT plugin it changes the operating mode of the CPLD, the CPLD will stay in that mode until reset at which time it will again default to the non-SSA mode until VIOT or SSA is enabled.

You didn't say how the CPLD could be reset, i've been unplugged before for 5 mins and that didn't do it, but pleased to report I have now managed to get rid of VIOT from the Keg  

I used a combination of...
(1) unplugging cable from Keg for 2 hours
(2) deleting plugins folder from PHTSYS completely (not just renaming to plugins.xxx or plugins.bak)
(3) using PMM to place updated firmware v13.01 onto DMS
(4) reflashing firmware in Keg using DMS

So this agrees with your assertion that VIOT is not permanent. I don't know which step actually removed it, but at least I'm convinced now it can be done!

So with that mini success I thought I would now be able to load the patch. Right?
Wrong...  

I still get the waiting error i.e.

Code: [Select]

PhatPatch v0.4 - original code by bushing, additional patches by sbingner
first 2 words of flash=c102 0025
writing auto-id command (AA, 55, 90)
Flash chip reports manufacturer id=c102, device id=0025
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...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
etc
etc


Any more ideas? I should be around all night tonight if you are available to help.

[sbingner]

I'll be able to once I leave work... I don't suppose you have a serial cable, or want to make one?  That would simplify things

Otherwise, we'll probably have to do alot of swapping of your DMS cartridge to make it check things...  it's not accepting the unlock code for some reason.  (you can tell by the fac that it says the manufacturer ID is the same as the first word of the flash, it's not.)

I should have seen that long ago, I guess I wasnt paying enough attention there....

BTW: the thread you mentioned where judb had the same problem, he had a bad version of the flash program... make sure you have the latest stuff posted for the flash stuff, and if you want you can get a working phatpatch from http://downloads.phathack.com/sbingner/phatpatch-0.4.gz

[sbingner]

Oh yea, losing power to the box resets the CPLD

[Firefox]

Just so you know, i'm in the UK so this is sent 9pm. Are you still in Alaska? If so I guess we are 9 hours apart? Should be fun getting a window to work for both of us........!!!

So far tonight I've been playing with a level 10 rc logging pair. I have quite a bit of stuff I could post if you think it's useful but your last comment makes me think we would need to crack the unlock first before anything else matters. Am i right?

Hmmmm. Serial cable. If it's "very easy" to make then I could have a go, but it wouldn't be tonight. Soldering isn't really my forte  

P.S. I have the v1.5 boot CD - so that must be OK already with a working v0.4 PhatPatch right?

PPS Your link above gives me an "invalid archive directory" when i try to unzip with WinZip - is it really a .gz or does it just need to be renamed as "phatpatch"?

[sbingner]

it's really .gz but sometimes clients will decompress it inline...

You can try to get the unlock code to work by using http://downloads.phathack.com/sbingner/debugr.gz and http://downloads.phathack.com/sbingner/debugw.gz

i.e:


./debugw 0x555=0xAA
./debugw 0x2AA=0x55
./debugw 0x555=0x90
./debugr 0x0

(what the patcher does)
and

./debugw 0xAAA=0xAA
./debugw 0x554=0x55
./debugw 0xAAA=0x90
./debugr 0x0

and

./debugw 0x1554=0xAA
./debugw 0xAAA=0x55
./debugw 0x1554=0x90
./debugr 0x0


just try different addresses until the read returns something besides 0xc102  -- when you get one that works, let me know what you got...  what should really work is the default addresses

[sbingner]

As to the serial cable, see http://wiki.phathack.com/Access_Serial_Port

[sbingner]

BTW, you can do all that without a serial cable... just make a script to run off your DMS and log all the output to a file

[Firefox]

it's really .gz but sometimes clients will decompress it inline...

Yep. That's what was happenning. I just needed to rename the files.

You can try to get the unlock code to work by using http://downloads.phathack.com/sbingner/debugr.gz and http://downloads.phathack.com/sbingner/debugw.gz

i.e:

./debugw 0x555=0xAA
./debugw 0x2AA=0x55
./debugw 0x555=0x90
./debugr 0x0

(what the patcher does)
and

./debugw 0xAAA=0xAA
./debugw 0x554=0x55
./debugw 0xAAA=0x90
./debugr 0x0

and

./debugw 0x1554=0xAA
./debugw 0xAAA=0x55
./debugw 0x1554=0x90
./debugr 0x0

just try different addresses until the read returns something besides 0xc102  -- when you get one that works, let me know what you got...  what should really work is the default addresses

Sorry. I don't 100% understand how I'm going to call those progs.
Do you mean I should copy both progs to backups folder in PHTSYS and then write a replacement patch.sh to actually call those commands in turn?  

Even then I wouldn't know what was safe to use as the addresses. Where did you get those example values from?
I think I'll need to wait for some 1 to 1 guidance via IRC...
...I'm pushing my limits of knowledge and feeling pretty dumb here!

[Firefox]

BTW, you can do all that without a serial cable... just make a script to run off your DMS and log all the output to a file

OK. We crossed messages.
So I got the script part right, I can do that, just don't know how to decide address values - for now i'll use your ones...

[sbingner]

Any address is safe, it won't write unless the unlock code and write code was accepted --- and that's not the write command, that's chip ID command

[sbingner]

try going to http://www.appindex.net/products/demo/chat/ and joining "The Zone" -- might be able to use that

[Firefox]

okay. i'm in there now. results from modified patch.sh weren't great. In fact the logs are easily corrupted it appears.

First part of my modified patch.sh script...

Code: [Select]


echo Starting Address Checks > /dos/log/PatchAddress.log

echo CheckingAddressCombo1 >> /dos/log/PatchAddress.log
/dos/backup/debugw 0x555=0xAA >> /dos/log/PatchAddress.log 2>&1
/dos/backup/debugw 0x2AA=0x55 >> /dos/log/PatchAddress.log 2>&1
/dos/backup/debugw 0x555=0x90 >> /dos/log/PatchAddress.log 2>&1
/dos/backup/debugr 0x0 >> /dos/log/PatchAddress.log 2>&1
echo FinishAddressCombo1 >> /dos/log/PatchAddress.log

echo CheckingAddressCombo2 >> /dos/log/PatchAddress.log
/dos/backup/debugw 0xAAA=0xAA >> /dos/log/PatchAddress.log 2>&1
/dos/backup/debugw 0x554=0x55 >> /dos/log/PatchAddress.log 2>&1
/dos/backup/debugw 0xAAA=0x90 >> /dos/log/PatchAddress.log 2>&1
/dos/backup/debugr 0x0 >> /dos/log/PatchAddress.log 2>&1
echo FinishAddressCombo2 >> /dos/log/PatchAddress.log

echo CheckingAddressCombo3 >> /dos/log/PatchAddress.log
/dos/backup/debugw 0x1554=0xAA >> /dos/log/PatchAddress.log 2>&1
/dos/backup/debugw 0xAAA=0x55 >> /dos/log/PatchAddress.log 2>&1
/dos/backup/debugw 0x1554=0x90 >> /dos/log/PatchAddress.log 2>&1
/dos/backup/debugr 0x0 >> /dos/log/PatchAddress.log 2>&1
echo FinishAddressCombo3 >> /dos/log/PatchAddress.log


resulted in this log...

Code: [Select]

Starting Address Checks
CheckingAddressCombo1
/dos/backup/patch.sh:
dos/backup/debugw: No such file or directory
Offset: 0x2aa=55
Offset: 0x555=90
Offset: 0=c102
CheckingAddressCombo2
Offset: 0xaaa=aa
Offset: 0x554=55
/dos/backup/patch.sh: /dos/backup/de/debugw: No such file or directory
Offset: 0=c102
FinishAddressCombo2
CheckingAddressCombo3
Offset: 0x1554=aa
Offset: 0xaaa=55
Offset: 0x1554=90
Offset: 0=c102

[Firefox]

just for completeness here are the results after running UNIX version of the patch.sh...

Code: [Select]

Starting Address Checks
CheckingAddressCombo1
Offset: 0x555=aa
Offset: 0x2aa=55
Offset: 0x555=90
Offset: 0=c102
FinishAddressCombo1
CheckingAddressCombo2
Offset: 0xaaa=aa
Offset: 0x554=55
Offset: 0xaaa=90
Offset: 0=c102
FinishAddressCombo2
CheckingAddressCombo3
Offset: 0x1554=aa
Offset: 0xaaa=55
Offset: 0x1554=90
Offset: 0=c102
FinishAddressCombo3

All failed to unlock the flash

Thanks for trying tonight Sam. If you get any other ideas please let me know...

[Terry_Kennedy]

okay. i'm in there now. results from modified patch.sh weren't great. In fact the logs are easily corrupted it appears.

It looks like you used an editor to create these scripts that actually backspaced over your typos rather than correcting them. Since you didn't actually execute all the commands in sequence (the "no such file" messages in the middle of the first two runs are a dead giveaway), we can't really say a lot about the results.

[Firefox]

It looks like you used an editor to create these scripts that actually backspaced over your typos rather than correcting them. Since you didn't actually execute all the commands in sequence (the "no such file" messages in the middle of the first two runs are a dead giveaway), we can't really say a lot about the results.

Thanks Terry, yes we worked out that saving the file as UNIX format eliminated the problem with running the script "cleanly".
My later post shows "accurate" execution results, but we still haven't been able to unlock my flash...

[Firefox]

Just been trawling the wiki for any other possible causes and was interested by the info about Startup Sequence FAQ (see http://wiki.phathack.com/Startup_Sequence_FAQ)

Boot procedure (on power)
The 8051 boots out of its internal 64k EEPROM [firmware.pac]
It boots up linux (see below) and the rest of the software to ask it what version of firmware.pac is stored on the drive if it is newer than that in the 8051, it will reflash itself . (This is why the instructions that come with the unit are insistent that you have the drive in the unit when you plug it in for the first time.)

Boot procedure (on ignition)
The 8051 will receive the turn*on sequence and apply power to the EP7312 (ARM)
The ARM will execute the bootloader code out of the 2mbit flash chip
This bootloader will query the drive for its ID and compare it to the signature written to the drive. It will also load the following files off the root directory of partition 1 and verify their corresponding signatures: linux, ramdisk, phatd, and rc.sh. It will hang with a blinking green light if anything is amiss.
If that check succeeds, the bootloader will load the linux and ramdisk files into memory, and jump to the linux kernel

I'm wondering if I have had a firmware.pac loaded that somehow prevents unlocking the bootloader flash.

Anyway to "downgrade" the 64k EEPROM in the 8051??