Information about TA-082

[ryoko_no_usagi]

Hello everyone,

I do not own a TA-082 motherboard myself, but I was recently contacted by someone who wanted some help with reflashing a bricked TA-082 motherboard to 1.5. I naturally gave the advice that it wasn't possible, but it turns out that I was wrong. They managed to flash a 1.5 dump onto the TA-082 board and, a bit surprisingly, it booted up. This clearly proves that the IPL is not blacklisted in anyway. However, the UMD and WLAN did not work. This matches exactly what laichung reported way back when: http://forums.ps2dev.org/viewtopic.php? ... ght=#38352.

To get around this, an attempt was made to retain the original TA-082 IdStorage by patching it to a 1.5 dump. This did not work at all; the PSP didn't even boot.

I'm theorizing that this is because the 1.5 firmware doesn't recognize the new IdStorage codes and bails out. Same reason as why the 1.5 updater doesn't run on PSP-1007.

I'm also guessing that the problem with the UMD and WLAN is simply because the methods the 1.5 tries to use to access these are incorrect due to the different hardware revision. 1.5 firmware can't properly drive the newer hardware but a newer revision module that knows of the new hardware could probably be used instead, with some assumptions of course. I don't have much free time to spend on PSP hacking anymore so I figured I put this out there for someone to work on if they feel like it...

Something I thought of: The new so-called "custom 2.71" firmware by Dark_Alex probably is a small 1.5 bootstrap to load a patched 2.71 fw, correct? I haven't looked at it, so I don't really know, but that's what I'm guessing. So, it could be possible to flash it onto a TA-082 and have it work, so long as nothing in the 1.5 bootstrap gets confused by the newer IdStorage...

EDIT: apparently quite a lot of 1.5 is used to bootstrap the patched 2.71, so I came up with the following idea since probably the 1.5 bootstrap will fail due to ta-082 idstorage: put a 1.5 compatible idstorage also on the chip. There should be enough space for two I hope (can't check at this time.) The 1.5 one is set to be the "normal" one and the ta-082 one is changed to be a "custom" (simply change the spare page that identifies idstorage). The 1.5 bootstrap will use the 1.5 compatible one and not crash (but obviously UMD and WLAN might not work). The "custom 2.71" is patched so that it instead recognizes the ta-082 idstorage by changing the sceIdStorage routines to look for the other id-mark. When 2.71 is bootstrapped it will hopefully recognize both UMD and WLAN :)

[fosi]

I got the same UMD & WLAN problms, and offical firmware updater can't execute.


but modification of MAC address worked.
(MAC page data from the bricked ta-082 psp)

now i'm trying to find out some information in the idstorage area.

[moonlight]

I currently think that main.bin from ipl maybe what bricks the TA-082.

Since 1.50 firmware runs fine in a TA-082 with devhook in 2.71, that means that the firmware itself doesn't cause the brick but something in the ipl. Only two posibilities remaining: main.bin or the ipl payload. Main.bin seems to access idstorage for something, i don't know for what...

[J.F.]

Since 1.50 firmware runs fine in a TA-082 with devhook in 2.71, that means that the firmware itself doesn't cause the brick but something in the ipl.

No because most of the low-level hardware prx's are already loaded (from the 2.71 firmware) by the time devhook loads something (ISO or program) and opens any more prx's from the 1.5 firmware image.

[moonlight]

Since 1.50 firmware runs fine in a TA-082 with devhook in 2.71, that means that the firmware itself doesn't cause the brick but something in the ipl.

No because most of the low-level hardware prx's are already loaded (from the 2.71 firmware) by the time devhook loads something (ISO or program) and opens any more prx's from the 1.5 firmware image.

No. When devhook load the 1.50 firmware, the psp is soft-reseted, and the 1.50 firmware is loaded without any 2.71 module.

Also i have more proofs that the firmware is not the cause, approaching a bug that let me load code before idstorage.prx is loaded, i've faked all idstorage read petitions that happened, until my custom vshmain was loaded, with the data of a single psp. While this worked in all normal psp's i could test, this bricked a TA-082.

[J.F.]

Interesting... I'll keep an eye on the thread as I have one of these TA-082 PSP's.

[moonlight]

The full list of idstorage read petitions in 1.50:

main.bin (ipl): 0x0004, 0x0005, 0x0006

chkreg: 0x0102, 0x0100, and if those fail, 0x122, 0x120
memab: 0x0100, and if it fails, 0x120
mgr: 0x0040, some other calculated from "something"
openpsid: 0x0101, 0x0102, if they fail, 0x121, 0x122
power: 0x0004
umdman: 0x0102
usb: 0x0041
usbstor: 0x0043
wlan: 0x0044 (mac), 0x0045
sysconf_plugin: 0x0044 (mac)
vshmain: 0x0046 (it uses the first byte of this key, as a param to vshImposeSetParam).

[harleyg]

Nice work there alex.
Alot of unused keys then?

Edit:
To identify a TA-082, you can read the nand ID.
On a TA-079 or TA-081:

0000000000 EC 75 A5 BD .u..

On a TA-082:

0000000000 EC 35 A5 BD .5..

Also, in 0x050 (serial) in idstorage, you can tell by 2 things.
On a TA-079 or TA-081:

0000000000 34 57 4D 42 30 39 34 38-32 34 34 57 4D 31 35 32 4WMB0948244WM152
0000000016 39 38 31 32 30 34 30 33-32 35 30 39 30 39 01 03 98120403250909..
0000000032 00 01 00 01 01 01 01 01-01 01 01 01 01 00 00 00 ................

On a TA-082:

0000000000 30 30 30 30 30 30 30 30-30 30 30 30 30 30 30 30 0000000000000000
0000000016 30 30 30 30 30 30 30 30-30 30 30 30 30 30 02 05 00000000000000..
0000000032 00 02 00 01 01 01 01 01-01 01 01 01 01 00 00 00 ................

I dont know if this is helpful to anyone. :)