TOOL dsedb help

Discussion in 'Sony Programming and Development' started by relax, Apr 18, 2013.

  1. relax

    relax Active Member

    Joined:
    Jun 14, 2012
    Messages:
    28
    Likes Received:
    0
    Recenlty picked up a DTL-T10000H A. When ever I use reset 2 100(or 0 0), It just shows the rom verson, and sits back at dsedb prompt. The TOOL screen is never displayed, and the retail game in the drive, doesn't seem to move.(not positive, TOOL is kinda loud)

    dsedb S> reset 2 100

    EE DECI Manager version 0.01 Dec 1999 17:48:37
    CPUID=2e14 BoardID=4126 ROMGEN=2000-0117 128M

    dsedb S>
     
  2. unclejun

    unclejun Site Supporter 2011-2014

    Joined:
    Nov 12, 2005
    Messages:
    1,919
    Likes Received:
    136
    The TOOL screen should be displayed before you attempt a reset.
    There are 2 switches on the front of the Tool, they should be on DVD and TOOL.
    Also, 8 dipswitches are on the back, they should be set as DUDDUDUU (D:down U:up).
    For PAL TV, °5 should be down.
    What is the region of your retail game?

    Last thing, you seem to be running an old version of the DECI2 manager, you should update the ROM and dsnet too.
    If you run dsidb, the version of your rom file should be displayed, look for t10000-rel???.bin on the second line.
     
  3. relax

    relax Active Member

    Joined:
    Jun 14, 2012
    Messages:
    28
    Likes Received:
    0
    The region is US. The Front switch was on WS. Could have sworn I checked if it was on TOOL. Switching to TOOL, fixed the no reaction problem. reset 2 100, is now displaying the initialization process.
    Also with dsidb. I'm not seeing any t10000-rel*.bin
     
    Last edited: Apr 18, 2013
  4. sp193

    sp193 Site Soldier

    Joined:
    Mar 29, 2012
    Messages:
    2,232
    Likes Received:
    1,073
    I'm curious to know: The ROMGEN line is 2000-0117 (Which is, boot ROM v1.00, which is found on the first SCPH-10000 consoles). Does that change if the TOOL's flash is updated? AFAIK it's showing the boot ROM's actual build date on retails, but I'm not sure whether flashing a TOOL will really change that value.

    EDIT: I just realized that the board ID is also valid, compared to on retails (!).
     
    Last edited: Apr 18, 2013
  5. unclejun

    unclejun Site Supporter 2011-2014

    Joined:
    Nov 12, 2005
    Messages:
    1,919
    Likes Received:
    136
    The dsidb output on my Tool:

    CPUID=15, ROMGEN=2002-0722, CACH_CONFIG=1edd8, 8MB, IOP mode, FlashROM boot
    <20020722-142111,ROMconf,t10000-rel255.bin:11840>
     
  6. sp193

    sp193 Site Soldier

    Joined:
    Mar 29, 2012
    Messages:
    2,232
    Likes Received:
    1,073
    Thank you! So YES, the ROMGEN value seems to change along with the contents of the boot ROM in flash... :)
     
  7. relax

    relax Active Member

    Joined:
    Jun 14, 2012
    Messages:
    28
    Likes Received:
    0
    Sorry for the delay. had to setup ssh(pita with out package man) so I could scroll up and copy paste.

    CPUID=15, ROMGEN=2004-0826, CACH_CONFIG=1edd8, 8MB, IOP mode, ROM boot
    <20040826-112724,ROMconf,dnas300.bin:11856>

    dnas?? as in the Dynamic Network Authentication System? yeah I'm at a loss why that is the rom.
     
  8. relax

    relax Active Member

    Joined:
    Jun 14, 2012
    Messages:
    28
    Likes Received:
    0
    Well after some goggling, I did see a post about TOOLs having dnas roms. couldn't find the difference though.
     
  9. relax

    relax Active Member

    Joined:
    Jun 14, 2012
    Messages:
    28
    Likes Received:
    0
    Some games loaded some games went back to "S>" with no error msg. So I updated dsnet, with out a problem. but everything was the same. So moved onto updating the ROM. dumped the original ROM as a back up to be safe, hmm yeah that didn't make it safe at all >.<. Because now after a successful ROM flash. (Stated "Complete !"). dsedb hangs and gives "no connectr".
    Atemptinng to revert back to the original rom dump fails. because dsflash also says "no connectr".

    EDIT: Deciding to edit this so I stop talking to myself.

    I followed the instructions in the SDK in recovering the ROM. Everything checked out. switching back to TOOL and booting, and we're good. /sigh
    still have the "dsedb does nothing on some games" problem. but having to "recover" the ROM, has scared me enough to stay far away from romflash. lol

    on a side note. This is my 4th TOOL So I was abit used to the routines of loading games/programs. but this is the first TOOL with the dnas ROM
    If anyone can shine some light on why the rom is named dnas. that would be cool. I'm familiar with what I know to be dnas, having dealt with it with FFXI. But I don't get the connection to the ROM.
     
    Last edited: Apr 22, 2013
  10. sp193

    sp193 Site Soldier

    Joined:
    Mar 29, 2012
    Messages:
    2,232
    Likes Received:
    1,073
    AFAIK TOOLs are supposed to be flashed with a boot ROM that matches the SDK that the programmer is using. So if you have one with dnas300, it probably means that the paired SDK was DNAS v3.00.

    Unlike a TOOL running with the DNAS boot ROM, retail consoles can't have their ROM chips flashed. So their IOPs get reset with an IOPRP image containing the DNAS modules.

    And AFAIK, the DNAS IOPRP images are like their non-DNAS equivalents... but at least their CDVDMAN modules have extra functions that are used for DNAS authentication itself.
     
  11. relax

    relax Active Member

    Joined:
    Jun 14, 2012
    Messages:
    28
    Likes Received:
    0
    Yeah makes sence. extracting the rom and comparing it to rel300, pretty much everything checks out the same, except CDVDMAN. witch is a few bytes larger.
     
    Last edited: Apr 22, 2013
  12. SilverBull

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

    Joined:
    Jun 12, 2008
    Messages:
    385
    Likes Received:
    6
    As sp193 wrote, for game development, the TOOL was flashed with the kernel version for the corresponding SDK. The Sony libraries verify that the IOP runs the correct kernel, and refuse to work if they find something else. That's also why retail games reboot the IOP first (that's probably the only SIF RPC call without a version check). They have to, otherwise, they wouldn't be able to access their resources on the optical disk.

    For game development, it comes in handy if the initial IOP reset can be skipped. First, it saves time. Second, the debuggers don't like IOP resets. All DECI2 communication is handled by the IOP, so doing a reboot also resets the DECI2 state machines, on both the IOP and EE. Information about breakpoint locations is cleared, and activated EE breakpoints become permanent; the original instruction that has been overwritten by the patched-in BREAK is lost during the state reset. Furthermore, if the EE sits on a breakpoint while the IOP reset occurs, it will also clear that state as well, thus resulting in the debugger breaking into itself. That's the reason why you cannot step through the code between an IOP reboot and the successful call to sceSifSyncIop.

    The IOP reset known from retails also works on the TOOL. However, you explicitly need to tell the IOP DECI2 debugger that the versions of the DECI2 manager and the running kernel may differ, or bad things can happen. That's what the 0x100 IOP boot parameter is for. I usually use a parameter combination like "f0002 100" when running retail games, as that also disables certain EE kernel checks that are not present on retails (but cause hard breakpoints on the TOOL). I recommend not to use the 0x80 IOP option (restrict IOP to 2MB RAM), though: if activated, you will actually end up with less usable memory than on retail machines, due to the DECI2 modules still being loaded.

    sp193 is correct, the difference is that the DNAS CDVDMAN exports some additional functions: #79 (sceCdReadDiskId), #80 (sceCdReadGuid) and #82 (sceCdReadModelId). These are not implemented in the regular CDVDMAN, where they just return zero.

    Like CDVDMAN, CDVDFSV also got two new SCMD RPC calls for DNAS: #36 (sceCdReadGuid) and #38 (sceCdReadModelId).
     
  13. PS2Guy

    PS2Guy Lost in the neverending abyss.

    Joined:
    Jan 18, 2011
    Messages:
    553
    Likes Received:
    2
    Does anyone know anything about these and why these have to be set the way they are? I'd be interested to know just out of curosity.
     
    Last edited: Apr 29, 2013
  14. unclejun

    unclejun Site Supporter 2011-2014

    Joined:
    Nov 12, 2005
    Messages:
    1,919
    Likes Received:
    136
    I was looking at the diagnostics utilities on my T15000, there's a RDRAM chip test in there, it mentions that the dipswitches 6 and 7 must be off for the test.
     

    Attached Files:

Share This Page