forums.ps2dev.org

I'm trying to get ps2link to work with ps2hdd (from ps2sdk) and cannot get my CVS checkouts (from yesterday) to work.

ps2link runs fine until I use ps2client to load the HDD IRXs. I found the post which gives the order of everything, but whether I follow it or not, ps2hdd always freezes at exactly the same place.

The freeze occurs right after the 'checking log' dprintf1 in journalResetore.c
I put in some extra dprint inside and after this if but never get any other output, so my conclusion is that call is causing the problem.
If I read the source right, this a built-in function, isn't it?
What is causing the lock-up? Some previous call the to same function?
Is there a conflict somewhere with LaunchELF? It's my BOOT.ELF, and I use it to launch ps2link, but LaunchELF hasn't displayed it's "Loading HDD modules" message.

Extra details:
PS2: non-sony HDD, non-modded SCPH-500010/N (used the MC exploit to set myself up), using LaunchELF v3.11 as BOOT.ELF
DEV: FedoraCore2, used toolchain.sh to set up (gcc-3.2.2, binutils-2.14), no problems encountered[/code]

Silly question, but is the hdd formated?

Also, how big is the HDD ? I don't remember if greater than 140GB or so is still a problem with the current IRXs. It may have been fixed and this is a non-issue.

The HD is a 120GB Maxtor taken out of a usb-only OneTouch, and it is formatted...
I've been usng ps2menu, ps2os, and execftps to read/write the HD without problems -- those apps are actually installed on the HD and LaunchElf runs them from there.
ps2link is the only one I've had to install on the MC.

I cannot find the sources to ps2link-1.24 or PS2OS v0.3a, both of which work fine with my HDD (no longer in CVS).

I've started diff'ing ps2sdk and it's 'ancestors' (ps2drv, libhdd) to figure what changed...
So far:
- ps2hdd / libhdd do not have significant changes.
- ps2atad has changes to enable 48bit support

Next to examine is dev9... but I'm afraid I may not be comparing anything useful since I don't know for sure what source-versions were used to compile ps2link-1.24 and PS2OS.

Can compiling ps2link with LOADHIGH or BUILTINIRXS affect anything?
What could be causing the PS2 to freeze on the atadDmaTransfer() call in journal.c?
To me (who doesn't have much experience with low-level hardware stuff, but plenty of software/sysadmin experience), the behaviour compares very well to locked resource problems... such as when a thread locks a resource but exits abnormally without releasing the lock.
So is there some sort of resource-locking that isn't being unlocked properly somewhere?

You should be able to pull whatever revision of a project you want from cvs by specifying its tag. In fact, have a browse through ps2link 1.24:

( http://cvs.ps2dev.org/ps2link/?only_wit ... 2LINK_1_24 )

ooPo wrote:You should be able to pull whatever revision of a project you want from cvs by specifying its tag.

Doh! I wasn't using the correct tag name!

EDIT: I've realized filesizes are a useless comparison, so I removed them. Next time I'll post md5 sums instead.

Could someone post the compiled filesizes you get when compiling from CVS? Here's what I get using Makefile defaults (DEBUG=0, LOADHIGH=0, BUILTIN_IRXS=0):
<<worthless filelist cut out in edit>>

As I was going through the source code, it was obvious that most of the stuff had not changed, with the exception of HDD stuff which seems to be entirely rewriten in some parts.
Also, since nobody has chimed in saying they have the same problem I do, the prime suspect is now my setup... either I somehow managed to break my toolchain or I'm the only one who has the particular PS2 hardware combo I have (unmodded SCPH-50010N, ethernet/modem NetworkAdap, non-sony 120GB maxtor).

I noticed that pratically every IRX file I could find was listed as "not stripped" when using the 'file' command. All the ps2sdk IRX I compiled were listed as "stripped".
So I happily commented out "LDFLAGS+=-s" from all the Makefiles in the 'iop' tree. Guess what? The non-stripped modules load. The stripped ones don't.
I get "loadmodule: id -201, ret 590528" for the stripped IRX (no matter which one) and a proper load for non-stripped.

When loading the non-stripped ps2hdd.irx from host:, it fails when no command-line options are given. It works fine with "-n 4 -o 8".

Load sequence:
From mc0:
- BOOT.ELF == LaunchElf v3.32
- PS2LINK v1.24 (binary dist)
Then through ps2client-2.0.0:
- optionally PS2LINK v1.30
- ps2atad.irx
- ps2hdd.irx -n 4 -o 8
- ps2netfs.irx

Everything is compiled from cvs except LaunchElf and ps2link_1.24.

Ok... I've re-installed the toolchain and all on two different computers and still get the same results.

These are the combinations to reproduce 3 different results for each of the above:
1) complete proper working access to hdd
2) loading ps2atad modules and freeze (hd light on, network dead)
3) loading ps2atad complely, but unable to mount

Here's how I consistently get the same results:
1) ps2link-1.30 + ripped DEV9 + ripped ATAD.IRX
1) other precompiled bins (ps2os for one)

2) ps2link-1.30 + ps2sdk/dev9 + ps2sdk/ps2atad
2) ps2link-1.30 + ps2sdk/dev9 + ripped ATAD.IRX

3) ps2link-1.24(bin) + ps2sdk/ps2dev9 + ps2sdk/ps2atad
3) ps2link-1.30 + ripped DEV9 + ps2sdk/ps2atad

Also, the netfs 'dir' command behaves slightly differently between 1 and 2 -- one needs "ps2client dir hdd:", and the other "ps2client dir hdd:/" in order to get the partitions listing. (I'm not even concerned with multiple listings for the same name at this point).

I checked my build outputs carefully and checked out all the warnings (even corrected those that weren't in print-related statements)... not that the warnings were dangerous (u32 vs int stuff).

(Just so it's clear and I'm not flamed unecessarily: the 'ripped' IRX are from official sony products I posess legally. So I modified them a bit for testing purposes...)

Just in case 48bit wasn't being detected properly on my drive, I tried bypassing the detection and forcing each of the modes -- simply by changing "lba_48bit = " at lines 915 & 925.
When I force 28-bit, I get the same freezing behaviour described above.
When I force 48-bit, I get this error: So that's not the problem.


Can someone point me to help on tracing the execution through the network (if it's possible)? (Or do I need to use a usb connection to get proper tracing)?

trace what ? if you need more output do some extra printf in either ps2atad or ps2hdd code.

Toker: Add some traces down in the ps2atad call. I think it should work ok to do printfs via ps2link/ethernet, at least if the dev9 stuff is working correctly ;)

But yea, if you have the correct usb cable, Naplink can be better when debugging this kind of stuff, since it doesnt have any dev9 dependancies.

I have the same problem as you btw (hangs w orange led when checking log). Got very little time to work on it though (surprise), so it'd be really appreciated if you could dig in there and find out what's wrong.

Wow, hanging with Orange LED and checking the journal is the same problem that happened to me when I stuck my PSX hdd into the PS2.

So could this be a problem with specific HDDs and their ATA mode settings ?

Dunno. Dont think so though, since the drive works fine with for example the dms3 hdd format utility.

pukko, gorim,
Thanks for confirming I'm not the only one!
But it appears most other people do not have the same problem, so is it possible there's something broken with our installation of the toolchain? I'm shooting in the dark, but haven't there been issues in the past building gcc with other versions of gcc causing it to be broken (not PS2 specific)?

There have been problems using GCC 3.2.2 to compile certain IOP modules. Try building ps2dev9 and ps2atad with GCC 2.8.1 (Karmix's toolchain) and see if that fixes it.

I think I'm getting somewhere... (the recent posts have been invaluable)

Last night, I launched the toolchain build on a Redhat 9 box (which has gcc-3.2.2, as opposed to gcc-3.3.3 on FC2).
First thing I noticed, ps2dev9 gave identical md5 as what I had built on FC2, but both ps2atad and ps2hdd are different -- and ps2hdd LOADED without freezing!
I'll do more thorough testing tonight and let you know exact results and behaviour.

I haven't tried Karmix' toolchain, but that'll be the next step if what I have now doesn't work 100%.

EUREKA!!! I have finally managed to get hd access with IRX that I built myself!

On my RH9 box (gcc-3.2.2), ran the toolchain.sh (not the new Nov 30th), then manually installed the binutils-2.9.1 and gcc-2.8.1 as per ooPo 'obsolete' instructions.
These IRX are identical (md5) to others I had downloaded, and ps2atad loads up without freezing the PS2.
What a relief to finally get stuff I compile myself to work completely!

My FC2 box is running the newest toolchain.sh now. I'll try that first and if it doesn't produce useable IRX, I'll do the same manual install of the IOP toolchain. I'll post an update...

The newest toolchain, with gcc-2.8.1 & binutils-2.9.1 for IOP installed on top, creates working ps2dev9, ps2atad, and ps2hdd IRX.
(Without the 'old' IOP stuff on top, the IRX generated by the new toolchain were identical to the previous toolchain.)
I've found I must execute 'ps2client devlist' before 'ps2client dir hdd:' will work, but that's minor.

Thanks for digging into this Toker. I should've stopped by this thread sooner, I would've made that suggestion straight off, because I've also had problems building ps2dev9, etc. with GCC 3.2.2. I still use Karmix' toolchain for all of my IOP modules.

To ooPo and pixel: it sucks someone else had to reconfirm what I already confirmed (last March) that GCC 3.2.2 and friends does not generate proper code for IOP:

http://forums.ps2dev.org/viewtopic.php?t=145
http://forums.ps2dev.org/viewtopic.php?t=154

IMO the best thing that can happen is that the 3.2.2 compiler for IOP gets pulled, and Karmix' put in it's place in toolchain.sh. While it seems to work for certain combinations of host GCC toolchains, it obviously doesn't work for everyone.

mrbrown wrote: To ooPo and pixel: it sucks someone else had to reconfirm what I already confirmed (last March) that GCC 3.2.2 and friends does not generate proper code for IOP:

Ok, I bite. What is gcc doing wrong ? Seems no one is trying to figure it out ?
Would that be better than substituting an older toolchain ? While substituting the older toolchain is a good temporary workaround, I am wondering if it might be nicer if there can be one toolchain base that can handle anything...

The issue is with the build toolchain - the compiler that's used to build the ps2dev toolchain. Something in mine (GCC 3.3.5) and Toker's (GCC 3.3.3) breaks GCC 3.2.2 for IOP. Yeah, it sounds strange, but this is why ooPo was pushing for GCC 3.x for IOP in the first place - on his system, his build GCC (don't remember which) was unable to even compile Karmix' older IOP toolchain.

So you'd be looking there first, and IMO it's not worth it. It's better to have a stable IOP toolchain than to require folks to have to build yet another toolchain setup on top of that (which is what ooPo deftly avoided - we could never convince him to downgrade GCC so that he could build Karmix' toolchain).

I was using gcc 3.2.3 back when the IOP patch was being tested.

It was just a matter of gcc 3.x not wanting to compile gcc 2.x - but I have a patch that allows it to be built on my site. I could certainly downgrade the script to build that instead...

Bah. This sucks. I was fooling with some IOP code yesterday. :)

I have to agree about the whole ordeal "sucking". I spent hours reading source and comparing diffs... The silver lining is that I now have a pretty good understanding of how everything ties together!

I had seen the threads from over 6 months ago mentionning similar problems, but since the toolchain was newer, I assumed the problem had gone away.
ooPo, if you want I can modify your toolchain.sh to give the user a choice on which IOP toolchain to build. At the very least, could you put a warning about the potential problems?

Trying to fix GCC is way over my head -- but I know someone who has contributed patches to gcc for tagged control structures and has written his own multi-machine disassembler. AND, he just bought a PS2 to "do stuff" with the VUs. I'll see what he has to say when I see him again next week...

I'm hoping that this was one of (if not THE) most obscure type of bug and that things can just get easier from here...

Its ok, I'll give the weekend for this to simmer and then modify the script to use the old IOP stuff. Maybe someone smart will have an epiphany. :)

Sounds like a good time for a new toolchain-unstable.sh, actually.

Yeah, the biggest hurdle starting ps2dev is the toolchain, so congrats, you're a MAN now :P.

You should've seen the state of things before ooPo started hosting patches and toolchain.sh :).

mrbrown wrote:You should've seen the state of things before ooPo started hosting patches and toolchain.sh :).

You mean the good old days ?

Okay. It seems all of this got fixed. This was not toolchain related though. Code related:

http://cvs.ps2dev.org/ps2sdk/iop/dev9/d ... 1.5&r2=1.6


The old 2.x gcc wasn't smart enough to interlace usage of registers and usage of them. gcc 3.x is a bit more intelligent about that, especially since the modules are compiled using -O2 by default in the sdk.



Well, I didn't really replied anything in that thread earlier because I was quite 99% sure it wasn't linked to the toolchain, and rather to some things like that volatile stuff.



Anyway, it works now. Thanks Herben for finding that bug.