Gathering SELF-ID packets –
@Silverbull: I'm sorry, but could you please help me out with this?
I've been stuck with this problem for about a year already: I do not have a reliable method retrieving the SELF-ID packets. D:
How do you determine when to access the UBUF or DBUF 00 to parse the SELF-ID packets?
I've tried polling for the SubActGap interrupt by clearing and polling the SubActGap bit of the intr0 register, but that doesn't seem to work right. D:
(Previously, I think that it was either the SubActGap interrupt never occurring or the SELF-ID packets were not all gathered in the UBUF after the SubActGap bit was set again... now that problem I mentioned below is occurring)
The problems I have now are:
1. Freezes (See below)
2. The SELF-ID packets are not being gathered properly (The trailing "end of self-id packet set" word is missing, presumably because I am reading the UBUF before all SELF-ID packets are gathered.....).
3. Sometimes, bus resets aren't even detected (Seems to be related to the first problem).
Now I don't know what is wrong at all - the i.Link hardware of my SCPH-39006 seems to be malfunctioning... or maybe the bugs in my drivers are intensifying as I make changes.
When a bus reset is initiated (After the ISBR bit is set in PHY register 5), the console might freeze as the i.Link hardware rentlessly spams PhyRst and UResp.... killing the IOP.
I don't remember having this problem before... so I am a little worried that it might be caused by my equipment wearing out over the years of intensive programming.
Other than the SELF-ID packet gathering issue that has been with it for the past half a year, the rest of the driver is probably fine.
Now I just want to dump all this as soon as possible. I've invested in so much time (Months lol... I wished that I either studied or played during them), but very little results have been produced.
(It's like PS2ESDL - I've built it, but it doesn't work too well and I never got to enjoy using them )
Did some more experiments, and found that:
1. The IOP is so slow that it's missing some interrupt assertions (Like it has before), and the i.Link hardware somehow won't indicate bus resets when the UBUF contains packets. D:
2. Hence, changing the enabled interrupt events and the code in the interrupt handler causes that problem to appear and disappear, as the amount of work the IOP has to do changes.
I don't know how to really fix this issue... unless I either make the interrupt handler as small as Sony's or perodically poll the UBUF for data.
EDIT: lol... I just remembered that I had encountered this issue before, and it was uber irritating. Never really fixed it, since it got fixed with the design of the old iLinkman drivers.
EDIT 2: I forgot to mention: I think that the weird PhyRst spamming issue seems to have disappeared after I unplugged and reconnected the IEEE1394 cable.
Update 2: I think that I've fixed the issue with the bus reset interrupts going unnnoticed by continuously checking the intr0 and intr1 registers in the interrupt handler until there are no more interrupts to service. I think that the SMAP driver does this as well...
Now the old problem with either UBUF transmissions not going through or something preventing the i.Link hardware from indicating that the packets were sent successfully with the UBUF is back again. D:
(Oh what lol.. what am I doing here? My finals are tomorrow! X) )
UPDATE 3: All problems probably fixed. XD
But I still have no idea how this will function on an older console (v7s and below) and in a game loader (PS2ESDL). I have no idea how much better device compatibility will be either.... but I can say that DMA support certainly will help.
Transmissions are now done with the UTD interrupt (No more polling! Yay) and UBUF data is handled with a thread.
Sony should be proud that I am not hogging the IOP by handling UBUF data within the interrupt handler.
This is a log generated when I ran my drivers on my SCPH-77006 console. It appears that there is a functional i.Link controller on it.
loadelf: fname host:iLink_test.elf secname all
Input ELF format filename = host:iLink_test.elf
0 00100000 0001dbb8 ..
start address 0x1000e0
gp address 00000000
Get Reboot Request From EE
ErrorTrap v1.00 initilizing...
read/write allocate memory 4000
Loaded debugging modules. Now loading ILINK modules...
iLink driver version 0.98H
Initializing Configuration ROM...
Console GUID: 0x80a2c90a 08004620, ModelName: .
Threads created and started.
iLink interrupt: 0x20400000 0x00000000
-=Waiting for the serial bus to be ready=-
-=Bus reset start detected=-
Handling UBUF data... handler: 0x0e.
Received PHY packet.
Receiving SELFID packets...
SELFID received from Node 0x0000. Speed: 0x00. Power: 0x00.
Local Node ID: 0xffc0.
iLink callback called. Reason: 0x08.
BUS RESET DETECTED. Nodes: 1
Local Node: 0x0000ffc0.
Attempting to initialize unit 0...
iLinkFindUnit() 0 UnitSpec: 0x0000609e; UnitSW Version: 0x00010483.
Reading CROM of node 0xffc0, offset: 5, nquads: 1.
Error: Unit 0 is not a valid SBP-2 device. Code: -1.
The log indicates that the SCPH-77006 might have a fully-functional LINK layer of a i.Link controller, as it can be configured to and can trigger interrupts.
Not only that, it seems to function like it has a functional PHY (A bus reset can be triggered).
However, Sony didn't seem to have included DMAC #3 in it's usual spot. Accessing any registers that belongs to DMAC #3 will cause a bus error.
Even weirder: DMACMAN doesn't seem to be aware that DMAC #3 doesn't exist! You can try to enable, disable and control the channels within DMAC #3 via DMACMAN, but doing so would result in a bus error.
So... if one could find out how to tap onto the IEEE1394 connectors, it might be possible for all newer PS2s to have a functional i.Link port....
EDIT: But I wouldn't bet on it. I just noticed that the node ID of that single SELF-ID packet is totally zero... which isn't normal. Sony might have merely included just sufficient chip logic to make it appear to the Sony i.Link driver that the hardware exists, but is not connected to anything.
EDIT 2: Nah. I'm wrong. It's normal if the node ID is zero, as I remember only printing out the node ID without the bus ID....
The number of ports is 2 as well, like with all older PS2s.
Last edited by SP193; 02-21-2012 at 08:14 AM.
Reason: The late PS2s might have functional i.Link controllers too....
SCPH-10000 S. MINOKAMO v1.01 (Defunct)
SCPH-10000 S. KISARAZU v1.00 (faulty)
SCPH-15000 S. KOHDA (With warranty seal!) :D
DESR-5100 S. EMCS