The "TOOL" side of Red Hat Linux on The PS2 TOOL not working!!

Discussion in 'Sony Programming and Development' started by PS2Guy, Sep 4, 2011.

  1. PS2Guy

    PS2Guy Lost in the neverending abyss.

    Joined:
    Jan 18, 2011
    Messages:
    552
    Likes Received:
    2
    I've been having trouble with my TOOl for a while now, and finally got around to fixing it the other day, and on start up it loads the mrp drivers, but it still won't connect to the ps2 side from dsedb.

    I thought that i would check to see the ROM version in dsidb and my version is dnas310 where it should be (and was) t10000-rel300.bin.

    So i thought that maybe I could reinstall the entire distribution on another hard drive and use that, but when I have installed Red Hat Linux on other hard drives it is only a Linux disc, and was wondering where the TOOL part of the TOOL start up comes from. Prodg? Codewarrior? PS2SDK?

    I hope this makes sense.
     
    Last edited: Sep 6, 2011
  2. PS2Guy

    PS2Guy Lost in the neverending abyss.

    Joined:
    Jan 18, 2011
    Messages:
    552
    Likes Received:
    2
    Bump!!! :shrug: Seriously?? :confused: Does no-one know???:crying:
     
  3. ASSEMbler

    ASSEMbler Administrator Staff Member

    Joined:
    Mar 13, 2004
    Messages:
    19,394
    Likes Received:
    995
    Probably ps2 side is damaged
     
  4. SilverBull

    SilverBull Site Supporter 2010,2011,2013,2014,2015.SitePatron

    Joined:
    Jun 12, 2008
    Messages:
    385
    Likes Received:
    6
    There seems to be a bit of confusion here... The short version of the answer is "from the official PS2 SDK" (more specifically: the file t10000-rel300.bin or equivalent). To understand that, you need a bit of background on computer architecture, so here is the long version:

    The TOOL is basically two computers in the same enclosure. One is what we call the "PC side", the other the "PS2 side".

    As the names imply, the first one resembles a standard PC (x86 processor), whereas the second one is a (albeit heavily customized) PS2. Both systems run completely independent of each other, with different processors (PC: on the PCI card; PS2: EE+IOP as usual, on the big board mounted against the holding plate on the right side of the TOOL, when looking at its front).

    Both computers boot off their respective boot ROMs. For the PC, the ROM is responsible for loading Linux from the HDD attached to the PCI card. For the PS2, though, the ROM (located on the PS2 mainboard mentioned above) just loads a slightly modified version of the same software that would also run on a retail PS2, plus some additional modules on the IOP.

    The PS2 side does never access a HDD by itself; it can't, at least not with any of the flashrom versions I have seen so far. It simply boots off its ROM, then waits for commands from the PC.

    As such, no matter what you do to the harddrives (both of them), you usually cannot interfere with the PS2 ROM. You can reinstall Linux on the PC side without affecting the PS2 at all. There are only two exceptions:

    1. Updating the PS2 flash ROM. You can run a program on the PC side that loads a special flasher via dsidb, thus forcing the PS2 ROM to be overwritten.
    2. Toggling the TOOL/WS button.
    The TOOL's PS2 ROM has two nice features regular consoles do not have: first, it is a flash ROM, so it is updatable ;-). Second, it has two "banks" (I just call them that; don't know whether there are independent chips or its just simply a 8MB NOR with the highest address line wired to an XOR gate). Anyway, this means the chip can house two independent copies of the PS2 ROM. This is a safety measure, because if the flash writer is interrupted (e.g. due to a power failure), it could leave the ROM in a corrupt state that would prevent the console from booting. Unbootable console means you cannot attempt to update the flash again, so this can really come in handy, especially for us as we cannot simply send these units in to SCE(A|E|I) for repair.

    From the point of view of the software on the PS2 side, these ROM banks could be called "current" and "other". The "current" one is the one the PS2 boots from (4MB mapped to physical addresses starting at 0xBFC00000 on both CPUs), and this is the only one the software normally sees. On the other hand, the "other" bank is hidden, and cannot be accessed by regular means. I would assume it is mapped somewhere else, but I actually never bothered to look for it.

    Now for the interesting question: how to access the banks and update them. That's where the TOOL/WS switch is used, as is the infamous "-mpu4shadow" option. I strongly suggest you also read through the setup_3.0.1.pdf (or equivalent) manual (PlayStation 2 Development Environment, Setup Guide), and if in doubt please ask here, because misusing the software tools can easily render your TOOL inoperable. You can destroy your TOOL's PS2 ROM if you are not careful here... :gravedigging:

    TOOL/WS controls what is the "current" bank. Let's call the physical banks 0 and 1, then the following happens:

    TOOL/WS set to TOOL: "current" is bank 0
    TOOL/WS set to WS: "current" is bank 1

    As the banks are independent and each contain their own copy of the PS2 BIOS, you can still operate the console as long as one bank is fine and you select it via the TOOL/WS button.

    Now, there are two possibilites you have when updating the flash ROM. You can invoke the updater either with or without -mpu4shadow.

    If you run the updater without -mpu4shadow, it writes to the "current" bank.
    If you run the updater with -mpu4shadow, it writes to the "other" bank.

    So the normal update goes like this: verify that TOOL/WS is set to TOOL, thus setting the "current" bank to bank 0. Then, run the updater without "-mpu4shadow", and it updates bank 0. If everything goes fine, you end up with bank 1 unchanged (see below why this is good), and bank 0 containing your new firmware. Simply reboot the PS2 side afterward and have fun.

    What happens if the update fails? Say the updater gets interrupted in the middle of writing to bank 0, thus leaving the PS2 in an unbootable state. dsidb won't be able to connect, and you won't be able to re-run the updater because of that to fix it. In this case, you can perform the recovery procedure, provided your bank 1 is still fine:

    !!!PS2 TOOL ROM RECOVERY PROCEDURE: DO NOT ATTEMPT UNLESS TOLD TO DO SO!!!


    1. Set TOOL/WS to WS, thus making bank 1 the "current" one.
    2. Reboot PS2, then run the updater with the "-mpu4shadow" option, thus writing to the "other" bank (0).
    3. Set TOOL/WS back to TOOL, verify that the updated ROM boots
    !!!END OF PS2 TOOL ROM RECOVERY PROCEDURE!!!

    It should be clear what this does: you switch to booting from bank 1 (the non-corrupted one), then write to the "other" bank via -mpu4shadow, effectively overwriting (and hopefully fixing) the mess the failed first update attempt has left there.
    If this succeeds, you should get a perfectly fine, updated bank 0, which you can then boot from by setting the switch back to TOOL. If this fails again (e.g., because of yet another power outage), you are fine as well, as it still only touches bank 0; you can try again if needed.

    The same procedure can be used in reverse, e.g. to restore the WS bank if it got overwritten for some reason. However, these two banks are the only safety measure; if both are destroyed, your TOOL becomes a pretty doorstop. As long as at least one is still fine, though, you should be able to restore the other, provided the flash chip itself still works (please remember that this is ancient hardware, so these have an even more limited number of erase/write cycles than today's flash chips), and the signalling of the TOOL/WS switch works. In case this wire breaks, you cannot toggle the boot bank anymore, but you can still use -mpu4shadow to write to the non-boot one... :evil::evil::evil:

    The whole process of updating the flash ROM, including recovering from a bad flash, is also described in the setup_3.0.1.pdf manual. However, before doing it, I recommend you try whether your TOOL/WS button works as expected. If all owners of the TOOL have followed that guide, the WS ROM has never been overwritten, so it should always be another version than the ROM in TOOL mode. You can easily check this via dsidb; for the same reason, I recommend to never overwrite the WS ROM. That is, never use -mpu4shadow when in TOOL mode.

    I hope this clears where the TOOL's PS2 gets its boot data from. Happy coding!

    (And I really wonder whether anybody around here reads such long posts...)
     
    Cyantist likes this.
  5. ASSEMbler

    ASSEMbler Administrator Staff Member

    Joined:
    Mar 13, 2004
    Messages:
    19,394
    Likes Received:
    995
    Silverbull you are amazing to write so in-depth a reply.
     
  6. sneakypeanut

    sneakypeanut Pika CHUUUUUU!!!

    Joined:
    Apr 14, 2010
    Messages:
    1,055
    Likes Received:
    10
    wow i never seen such a in depth reply was an amazing to read might have solved the problems i had when i had my ps2 tool :/
     
  7. PS2Guy

    PS2Guy Lost in the neverending abyss.

    Joined:
    Jan 18, 2011
    Messages:
    552
    Likes Received:
    2
    I just want to thank SilverBull for his lengthy reply to my question and all the PM's that we've had since.

    He is the fn man and a great asset to this place.

    Your help is greatly appreciated.

    PS2Guy!!
     
  8. l_oliveira

    l_oliveira Officer at Arms

    Joined:
    Nov 24, 2007
    Messages:
    3,879
    Likes Received:
    245
    Now, let us know if your TOOL get back online, ok ? :thumbsup:
     
  9. PS2Guy

    PS2Guy Lost in the neverending abyss.

    Joined:
    Jan 18, 2011
    Messages:
    552
    Likes Received:
    2
    I've actually corrupted the last hard drive trying to dd it for SilverBull, so it might be some time yet. He has to send me a copy of one of his hdd's.

    But if I ever get up and running again, you ( The Community ) will be the first to know.
     
sonicdude10
Draft saved Draft deleted
Insert every image as a...
  1.  0%

Share This Page