Page 1 of 1
Stuck on firewire
Posted: Sun May 16, 2004 10:17 pm
by Guest
I recently got diverted from another project (just for grins) messing
around with the ilink 1394 interface. After persusing the documentation
mrbrown provided from his webpage, I was able to perform minimal
initialization of the ilink PHY and LINK. Another connected host on the
bus (my mac) can see the PS2 and communicate on the physical level
by examining the PS2's PHY registers over the wire. No, no data transfers
yet...I haven't gotten that far, but they both "know" each other is there.
I have been playing with registers to verify and test functionality,
and there is where the problem is: it seems many registers described
in the LSI documentation are not there - specifically, the registers
affecting the CIP, PHT, and DMA processing. Attempts to access them
based on the documented offsets result in much getting touch-feely
with my reset button. Poking around the address space has thus become
quite the headache.
Either Sony is deriving great pleasure from moving things around the
map (the current base address of 0xbf808400 for the registers I *can*
see also differs from the documentation), or Sony has decided not to
implement the functionality in hardware that those registers represent.
So, the question is, does anyone know if those registers exist ? It would
be great if they did, because some cool DMA things could possibly be
done.
Gorim
Posted: Mon May 17, 2004 2:00 am
by mrbrown
Reverse the 140KB ilink.irx, it contains assertions and other debug code that should make it easier to map hardware registers.
I got my ilink.irx from GT3, I've also heard that Unreal Tournament shipped with it.
Posted: Thu May 20, 2004 2:36 pm
by nosense
I've been messing with the firewire interface also. There is a good sample device driver & application in the win2k ddk that lets you push packets onto the wire (from the PC) umongst other things. I looked at ilink.irx a while ago too. Aside from having many threads to talk to 1 device! I noticed is uses a block of registers which are not in the docs mrbrown posted.
I haven't looked at it again for a few weeks, but am still plugging away when I get the chance...
Posted: Fri May 21, 2004 11:30 am
by Guest
Disassembling is one of my poor skills. I have spent countless hours
over iop-objdump output and finding out where all of the 1394 register
accesses are occuring is not easy. It seems there are only 3 register
addresses in use.
However, I have had success in merely brute forcing my way through
checking the register offsets on the documentation.
It seems that the documentation *is* correct on the list of registers,
but with some exceptions: 7 of the 1394 registers are not used, and
are unmapped from the hardware. Any accesses to these result in the
bus error problems that were stymying me earlier. So long as one
avoids them like a bad hair day, all is fine.
Furthermore, after initializing the 1394 controller, the default values
(non-zero) contained in all of the accessible registers match precisely
what is expected from the documentation.
This is good news, I hope to continue this weekend in making some
data transfers.
Gorim
Posted: Fri May 21, 2004 12:36 pm
by nosense
I don't have my notes here, but...
The docs show an gap in the address space. I found a bunch of registers were mapped to those locations. This could be the missing registers you're talking about. In the documentation, are they grouped as a contiguous block??
Posted: Fri May 21, 2004 2:28 pm
by Guest
So far everything is contiguous according to the documentation,
with gaps expected where shown in the documentation, with
these apparent exceptions:
1. 7 registers in the documentation do not exist and are unmapped
to the hardware.
2. You have found mapped registers within the gaps that are
undocumented.
Actually I think I know what is within one of those gaps, but I might
like to get some advice and confirm it first.
Essentially there are 3 blocks of 1394 registers with roughly a
0x20-0x30 gap between them:
1. General 1394 control, interrupt, and ubuf/fifo access.
2. Port 0 specific registers
3. Port 1 specific registers (so...uhh...what is hooked up to port 1
I wonder ? Hmm... *thinking of all sorts of things*). Examining
port 1 at the PHY from remote shows the twisted-pair wires held
in a Z state of high impedance, so they could just be terminated
without being attached to anything.
As for the registers that are missing and unmapped:
0x014 PHY Access Register
0x054 UBUF Receive Level
0x058 Encoded Interrupt Priority
0x0CC DBUF Watermarks Register 0
0x0D0 DBUF FIFO Size Register 0
0x14C DBUF Watermarks Register 1
0x150 DBUF FIFO Size Register 1
So far, accessing them has caused apparent bus errors that hang
up my ps2client. (If I have spare time, I might write a bus error
exception handler for ps2link :P )
Of course, these registers could be elsewhere, but it doesn't make
too much sense. My thinking is they were either unneeded, or
reflect an earlier version of the 1394 controller. In fact, the vendor
and device ID codes indicate at least that the PHY is an earlier part
than what is shown in the documentation.
That is what I have found so far. Maybe with 2 people working this
we might someday reach the holy grail of getting 1394 working
after all these years.
Some people have told me that its not worth it because 1394 doesn't
exist in newer PS2 models.
But my vision of what can possibly be done with this, is many cooler
PS2DEV development tools that might make the older models more
desirable for Dev purposes. No, not to use 1394 in a developed app,
but to use it has a development tool.
What could one do ? Well, 1394 controllers normally have busmaster
DMA capabilities that only require register initialization and requires
no software handlers - just send a packet from a remote fw host and
it will automatically read/write memory via DMA. Imagine a dev tool
that can manipulate IOP memory without needing IRX/IOP software
handlers as an intermediary ? This is soemthing I am interested in
persuing the possibilities.
Gorim
Posted: Mon May 31, 2004 8:41 pm
by Guest
nosense wrote:I don't have my notes here, but...
The docs show an gap in the address space. I found a bunch of registers were mapped to those locations. This could be the missing registers you're talking about. In the documentation, are they grouped as a contiguous block??
At least in the first gap, they do not appear to be.
The quad of registers starting at 0x60 appears unmapped, at least,
its causing apparent bus errors on access.
The quad starting at 0x70 is ... interesting.
0x7c is some sort of "master" control over the ilink PHY and LINK
core. If you set bit 7, PHY and LINK appear to turn off. Subsequent
setting and/or clearing of that bit have no affect. If you then set bit 8,
everything then turns back on... again subsequent setting/clearing of
that bit has no affect. These are not reset bits, they are on/off switches.
I have no idea what the other bits in that register do. There is nothing
in the docs that describes anything similar to this register.
The other registers in the 0x70 block (0x70, 0x74, 0x78) are being
difficult. I think I know what they are based on the ilink.irx and some
LSI docs, but they aren't playing nice with me. I will post more if I
can get anything to work.
I haven't looked into the gap between PHT0 and PHT1 registers, nor
those that follow PHT1 up to 0xFFF.
Gorim
Posted: Tue Jun 08, 2004 7:54 am
by zerocom
You might be interested in this:
Code: Select all
ret = _sceCdRI(buf1,&value);
if ((ret > 0) && (value == 0))
{
guid[0] = 0x08004600 | buf1[0];
guid[1] = *((unsigned int *) &buf1[4]);
modelid = (*((unsigned int *) buf1))>>8;
printf("GUID: 0x%08x%08x, MODELID: 0x%08x\n",guid[0],guid[1],modelid);
}
else
printf("no iLink Info\n");
It will get the unique id for the config rom.
I did this some time ago, not sure if it's working on the old japanese ps2's.
Afaik from my disassemble try of the original ilink module, the sony driver does not use DMA, so it might be hard to find out how it works.
Isochron transfers support would be a nice feature...
Bye...