PS2 Linux Beta kit extras...

[nodots]

Of the 48-bit address (16 bits "high offset" and 32 bits "low offset), only the lowest 21 bits are used. Everything else is ignored, so the address space repeats after every 2MB. I haven't found a register for turning this off yet, and it may very well be a hardware limitation...

Maybe this is part of a paging mechanism? Maybe the "page" (4bit: 0-f x 2MB=32MB; 3bit: 0-7 x 2MB=16MB ) is set in a register (or register bits) of which the purpose is yet unknown?
Might have been to make erroneous region assignment difficult, ie. kernel-space overwrites by errant (but intentional) non-console code. Just a thought...
(Unless, of course that's what you meant in what I quoted.)

[SP193]

lol. The board decided to not allow me to reply to your message - just because the reply had one emoticon too many! (16 - 1 more than the limit: 15). D:

The DMA controller of the Lead Vehicle allows to not use a reference table by clearing the TMD bit. I think bit #10 (0x400) actually serves the same purpose here. However, I'm not sure yet as to whether the registers of the third DMAC are organized like the ones of the other controllers...

Thanks. I got a very interesting result today: automatic read/write responses are working . Meaning: after hardware setup, my PS2 TOOL now handles async read/write transactions on its own, with absolutely no device drivers running on the IOP. There are a few limitations, but all in all it works.

Congratulations!
What a breakthrough!

Here are some scripts (I hope you can read DSIDB syntax ):

- DSIDB log -

Thanks! I might not have a TOOL, but I'll certainly try. I'll ask you if I can't interpret the input you provided.

The first two scripts are executed manually after an IOP reset. This performs an 1394 bus reset, so the connected PC scans for new devices. Currently it does not result in anything useful, as the SBP-2 configuration rom normally at ffff:f0000400 is not present. However, one can still get a usable 1394 device in Windows by creating an instance of 1394vdev. Afterwards, Win1394 can perform async I/O to this pseudo device. I also tested Kermit, but it fails after a seemingly driver-induced timeout. Seems I messed up when writing the 1394 layer, as I currently do not have any idea why it works with regular Kermit devices and fails with the "virtual" 1394 ones...

Wow. I must test this on my retail...

This hardware-accelerated transfer method has a series of drawbacks that can really screw things up, though:

• Of the 48-bit address (16 bits "high offset" and 32 bits "low offset), only the lowest 21 bits are used. Everything else is ignored, so the address space repeats after every 2MB. I haven't found a register for turning this off yet, and it may very well be a hardware limitation...
• All accesses are restricted to word-alignment. I think this is a restriction of the IOP's DMACs. You can program other parameters, and also send packets that get automatically parsed into wrong transmission parameters for the DMAC. However, this leads to a DMAC failure and stalls transmission until both the DMAC and PHT are reset. This is what the restart_ilink_pht1dma_script is for. Until the restart, the PS2 won't accept any further packets.

#1: It seems like a hardware limitation because of the IOP. Why would we need to write beyond the 2MB offset anyway?
#2: I think that it was mentioned in the Lead Vehicle document that transfers had to be word-aligned and the transfer length rounded up to word-boundaries. The DMAC of the PS2 does expect the MADR to be set to word-aligned addresses too, so it's probably expected for the DMAC and PHT to lock up if you use an unaligned memory address.

I have also learned a bit about the registers of the third DMAC controller's PHT1 channel:

1. Bit #31 in its CHCR (bf8015cc) controls whether the channel handles packets from the Rx DBUF automatically. This needs DEn=RActl=1 and DWidth=10b (32 bits) in the 1394 node's "DMA Control and Status register", as well as EnDMAS=IHdr=1 and (I think) EHdr=0 in the "PHT Control and Status Register".
2. Registers bf8015d4 and bf8015d8 control the region of the 21-bit address space available via DMA. I called them START_MADR and END_MADR, respectively. A DMA transaction is only performed if the whole address range programmed into bf8015c0-bf8015c4 is fully contained in the region from START_MADR to END_MADR. Any address outside that range causes the DMA channel to stop.

It is interesting that the START_MADR/END_MADR check is also performed while the transfer is running, for both reads and writes. If an error is encountered during a write, the channel will simply stop and excess data is left in the Rx DBUF. This must be cleared manually, as the node controller won't accept any further packets.
The same happens for reads: if data has already been transmitted to the Tx DBUF (e.g., because the transfer region ends after END_MADR), that data will stay there and no response packet will be generated. The PHT is dead afterwards and must be reset; it may also be possible to just fill in the Tx DBUF manually, but I didn't check yet.

If the DMA transfer stops due to a range violation, bit #31 from its CHCR is also cleared automatically. So before starting the PHT again, it is also necessary to set that bit again (after clearing the DBUFs of course), or the transfer gets stuck again.

Wow. You're amazing.

Do you know whether there is an IOP register allowing to detect bus errors that have occured during DMA transfers? The EE's DMAC has one if I remember correctly, and it would surely come in handy for a DMA-enabled 1394 driver. It would also be possible to just read the channel registers and check for anomalies (an unfinished transfer is indicated by a non-zero amount of remaining data, as should be the case for unaligned transfers), but a real register would certainly be better.

Unfortunately, I don't think that the IOP has such a facility. :X

I think that programmers were encouraged (In the LSI documents) to poll the PHT status registers for any problems - and for there to be timeout code (So that the processor won't wait for a hardware event that won't ever occur).

EDIT: I have an idea: Since the DMAC handles IEEE1394 transactions, and hence the IOP's slow response speed is no longer a major factor, we can probably add code that checks on the PHT status registers whenever a SntBsyAck interrupt event occurs.

The SntBsyAck interrupt event occurrs when there is data in the receiving FIFO and a Busy ACK was sent back to the sender by the iLink hardware.

Under normal circumstances (When the iLink FIFOs are cleared quickly), the SntBsyAck interrupt event should not occur.

However, the SntBsyAck interrupt event does occur quite frequently when the PS2's iLink hardware runs without DMA support - because the IOP is slower than the IEEE1394 bus! :P

EDIT 3: Unless I made an error, and/or DMAC #3 isn't working at all on my SCPH-39006 console: The test I mentioned above won't be very accurate. D:

Unless the sender sends additional packets, the remaining data in the DBUF FIFO shall remain there and there won't be a SntBsyAck interrupt event triggered.

But it will probably still remain a valid solution if the goal is to only prevent the DMAC and PHT from getting stuck!

Well, you can always do it The Hard Way: dump everything until a fixed address, and check whether it crashes. If you get a reading, you have hit a register. If the system freezes, you hit a hole. This does take a bit of time, thought...

I did that, and have confirmed that there are no additional registers in that memory region.

Hmm, those "700" values look odd. I didn't get those, and I don't know whether reasonable channel registers would look like that. If we are unlucky, these DMA channels may not be present on all models having a 1394 port, so we would need a means to check what kind of hardware we are running on.

I think that those DMA channels are present. When I did some tests, the PS2 seems to lock up when the TR bit (0x01000000) gets set for DMAC Channel #14.

Odd as well. But please note that I'm using a TOOL for my experiments, so it may very well be that all of this cannot work on retail hardware. I really hope that this is not the case, though

I hope so too. It'll be very disappointing if DMAC #3 was found to be not working or wasn't implemented in retail consoles.

Maybe this is part of a paging mechanism? Maybe the "page" (4bit: 0-f x 2MB=32MB; 3bit: 0-7 x 2MB=16MB ) is set in a register (or register bits) of which the purpose is yet unknown?
Might have been to make erroneous region assignment difficult, ie. kernel-space overwrites by errant (but intentional) non-console code. Just a thought...
(Unless, of course that's what you meant in what I quoted.)

Maybe, but I don't think that the PS2's DMAC hardware was ever that elaborately designed though. :X

UPDATE: I tried to add code for setting up DMA channel 15, and I found that I might have hit that horrible problem with the DMA channel stalling. D:

(Bit #31 gets set during initialization, but it gets cleared after data enters the PHT 01 DBUF Rx FIFO).

There might actually be a bigger problem: The DMA module might be buggy, and cannot differentiate between IEEE1394 response packets from read/write requests!

Unfortunately, I don't have a PC with IEEE1394 hardware that runs Windows. D:
Otherwise, I might have been able to run some tests like you did. The only PC I have that has a single IEEE1394 port is running Linux, and Linux doesn't seem to allow connections to IEEE1394 devices that do not have a valid configuration ROM! :X

It'll be really wonderful if we can also identify the interrupt number for DMA channels 14 and 15, so that drivers like my SBP-2 driver can detect when the last ORB has been read!

UPDATE 2:Just wondering: Have you gotten transfers working with the PHT yet, with or without DMA support?

When I built my driver, I couldn't seem to find a way to get the PHT to generate quadlet read/write packets. Do you know if that is actually even possible?

Right now, I'm using PHT 00 for block read/write packet transmission and PHT 01 for incoming packet handling.

UPDATE 4: I think that I've obtained arguable evidence that DMA transfers do work on my SCPH-39006. After enabling DMA channel 15 and configuring PHT 01, I noticed that I no longer had to byteswap the payloads of outgoing block read request packets.

(Which also probably means that my old iLink driver might have actually always been transmitting garbled packets! D: )

Not only that, but the request for the Management ORB had been redirected to the UBUF - which is new.
(It seems that was the handiwork of the DMAC - the high 16 bits of the address that gets sent from my enclosure isn't full of zeros, but contains the console's node ID instead... so it will fall outside of the DMAR)

So yea, I got my driver going further now. The problem with the DMA channel stalling was caused by the sudden change in endianess.

I should also probably mention that the entire node controller might lock up (Packets cannot be sent via even the UBUF) if DMAC #3 misbehaves (In my tests, that was usually caused by incoming request packets with damaged memory addresses) - which in turn probably caused the PHT to get stuck.

(I also think that I had observed that behavior before when the PHT becomes stuck - when it froze because of the root node bug. So such behavior is probably a result of the way the iLink hardware was designed)

The headers of incoming block read requests now have to be byteswapped - something which I never needed to do before!

Well, since there is a change in data endianess in some transfers after I only enabled DMA channel 15 for use with PHT 01, that means that something else is changing the way data gets sent to the target (My IEEE1394 enclosure).

What do you think? Did I really manage to enable DMA channel 15 on a retail console? Or am I just barking up the wrong tree again?

About the EHdr bit: Yes, the EHdr bit must not be set or the DMA module won't work at all (It doesn't seem like it is able to send anything at all).

Now to think about it, Sony's iLink DMAC design is actually pretty solid. There is quite a low chance that the IOP kernel or the DMAC could crash because of rogue incoming request packets.

The DMAR register of the iLink node controller can be used to limit the DMA region to 0-0x00200000, and the DMAC DMAR_START and DMAR_END registers can be used to prevent DMA transfers to protected areas (Like, the IOP kernel that sits below 0x800).

Dang. If only I had some way to send IEEE1394 request packets to the console directly - then I can verify for real that the PS2 is indeed now capable of responding with it's own hardware. D:
What did you use to perform such a test anyway?

Now what we really need is a way to determine the address of incoming WRITE request packets (That have been processed by the DMAC). Otherwise, SBP-2 drivers won't be able to benefit from this *new* found technology. D:

[SilverBull]

#1: It seems like a hardware limitation because of the IOP. Why would we need to write beyond the 2MB offset anyway?

Because the TOOL has 8MB of IOP RAM

#2: I think that it was mentioned in the Lead Vehicle document that transfers had to be word-aligned and the transfer length rounded up to word-boundaries. The DMAC of the PS2 does expect the MADR to be set to word-aligned addresses too, so it's probably expected for the DMAC and PHT to lock up if you use an unaligned memory address.

Yes, I remember reading something like that. I'd still prefer having the ability to perform unaligned accesses, especially for stuff like Kermit that might want to write single bytes only.

EDIT: I have an idea: Since the DMAC handles IEEE1394 transactions, and hence the IOP's slow response speed is no longer a major factor, we can probably add code that checks on the PHT status registers whenever a SntBsyAck interrupt event occurs.

(see below for your EDIT 3)

However, the SntBsyAck interrupt event does occur quite frequently when the PS2's iLink hardware runs without DMA support - because the IOP is slower than the IEEE1394 bus! :P

I think this depends on the device on the other side of the cable. For example, when using single-threaded Kermit, it won't send another packet until the current one has either been answered or timed out.

EDIT 3: Unless I made an error, and/or DMAC #3 isn't working at all on my SCPH-39006 console: The test I mentioned above won't be very accurate. D:

Unless the sender sends additional packets, the remaining data in the DBUF FIFO shall remain there and there won't be a SntBsyAck interrupt event triggered.

But it will probably still remain a valid solution if the goal is to only prevent the DMAC and PHT from getting stuck!

We could try polling the PHT and DMAC channel on every interrupt. If I remember correctly, one of the Gap-related interrupts keeps coming in if the DMAC is stuck. Interestingly, the PHT status does not seem to indicate that there is a problem; it just stays at something like 0x4011ff (I think).

Also, manually draining the Rx DBUF does only work with DEn=0 on my TOOL. If DEn is still 1 and the DMAC is stuck, reading the register does not cause any change to the DBUF level register, so I think data is not removed from the buffer in this case.

Maybe, but I don't think that the PS2's DMAC hardware was ever that elaborately designed though. :X

I wouldn't call a DMA page register "elaborate", its more of "we didn't have a working DMAC design when this system was due, so we just crammed in some sh*t we hope to work in more than zero cases".

There might actually be a bigger problem: The DMA module might be buggy, and cannot differentiate between IEEE1394 response packets from read/write requests!

Hmm, that's really strange. I cannot test this at the moment, as I'm just using the PS2 as the target for async I/O, not as initiator.

Unfortunately, I don't have a PC with IEEE1394 hardware that runs Windows. D:
Otherwise, I might have been able to run some tests like you did. The only PC I have that has a single IEEE1394 port is running Linux, and Linux doesn't seem to allow connections to IEEE1394 devices that do not have a valid configuration ROM! :X

It'll be really wonderful if we can also identify the interrupt number for DMA channels 14 and 15, so that drivers like my SBP-2 driver can detect when the last ORB has been read!

Can't you read packets targetting the configuration ROM area from the UBUF, and handle them in software? If the DMA region is restricted accordingly, they won't be sent to the DBUF, so the DMAC should never get confused by them.

UPDATE 2:Just wondering: Have you gotten transfers working with the PHT yet, with or without DMA support?

When I built my driver, I couldn't seem to find a way to get the PHT to generate quadlet read/write packets. Do you know if that is actually even possible?

The DSIDB scripts I sent are all I currently have that uses the PHT. With DEn=0, I also managed to read received packets from the Rx DBUF manually, but I haven't yet tried to make the PHT send anything (aside from auto-DMA).

What do I have to do to get the PHT to receive more than one packet with DEn=0? With EnDMAS=1, it just puts the first received packet into the buffer, then quits any following incomming packets with a busy-ack, even if I did drain the buffer before. Do I need to send a response, or is there some other status bit somethere that needs to be changed? In my tests, I always had to reset the entire PHT to keep receiving the next packet...

Right now, I'm using PHT 00 for block read/write packet transmission and PHT 01 for incoming packet handling.

I think this is a quite optimal setup. Too bad we don't have two DMA range registers, one for each PHT...

UPDATE 4: I think that I've obtained arguable evidence that DMA transfers do work on my SCPH-39006. After enabling DMA channel 15 and configuring PHT 01, I noticed that I no longer had to byteswap the payloads of outgoing block read request packets.

Great work . That's odd, it might mean there is some weird interaction between the DMAC and PHT configurations and other parts of the node controller.

Did I understand correctly that you configured DMA channel 15 and PHT1, which then effected packets sent via the other PHT0? Or are you sending the packets via PHT1 as well?

(Which also probably means that my old iLink driver might have actually always been transmitting garbled packets! D: )

I noticed something similar with packets received in Win1394. I'm not sure at the moment how the data looks when using Kermit, but I definitely remember having to swap bytes under certain circumstances for UBUF transfers.

Not only that, but the request for the Management ORB had been redirected to the UBUF - which is new.

Isn't that related to the fact that ffff:f0000400 is way outside the DMA range?

(It seems that was the handiwork of the DMAC - the high 16 bits of the address that gets sent from my enclosure isn't full of zeros, but contains the console's node ID instead... so it will fall outside of the DMAR)

Are you sure you are not referring to the sender's node ID field in the packet?

What do you think? Did I really manage to enable DMA channel 15 on a retail console? Or am I just barking up the wrong tree again?

Surely sounds like the DMAC is doing something, but I fail to see why just enabling it should cause byte swaps. 1394 uses big-endian by design, so in a little-endian system like the IOP there must be some component that does it, but I would have expected the PHT/LVDMA to handle it, rather than the node controller doing so when putting data into the UBUF.

The DMAR register of the iLink node controller can be used to limit the DMA region to 0-0x00200000, and the DMAC DMAR_START and DMAR_END registers can be used to prevent DMA transfers to protected areas (Like, the IOP kernel that sits below 0x800).

Yes, this is what should be done in a release driver to protect sensitive areas. I would even go further and restrict DMA to just a single driver-allocated buffer, so no external component could effect the IOP in any way.

Dang. If only I had some way to send IEEE1394 request packets to the console directly - then I can verify for real that the PS2 is indeed now capable of responding with it's own hardware. D:
What did you use to perform such a test anyway?

Win1394. It allows sending basically arbitrary requests over the 1394 bus, using the 1394diag (for real devices) or 1394vdev (for virtual ones) driver. These drivers are a particularly well-known example of how not to write 1394 drivers in Windows, as they expose the entire 1394 bus driver to arbitrary user-mode components. There are a lot of bugs in the drivers (certain versions of 1394diag crash if their device is disconnected ), but a restricted subset of their functions (notably the async I/O) works quite well.

Now what we really need is a way to determine the address of incoming WRITE request packets (That have been processed by the DMAC). Otherwise, SBP-2 drivers won't be able to benefit from this *new* found technology. D:

The address and length can be read from bf8015c0 and bf8015c4, respectively, although addresses are just 21-bit then. You could even disable the channel by clearing the bit in PCR3 (bf8015f0), then the CHCR would stay with TR=1 and the initial address and length stored in the channel registers. At least it works this way on the TOOL; you can even start the DMA transfer yourself afterwards, just be enabling the channel in PCR3.

[SP193]

Because the TOOL has 8MB of IOP RAM

Ah. Now that makes sense.

Yes, I remember reading something like that. I'd still prefer having the ability to perform unaligned accesses, especially for stuff like Kermit that might want to write single bytes only.

In that case, your requests will automatically get diverted to the UBUF by the hardware. Or at least, it should...

We could try polling the PHT and DMAC channel on every interrupt. If I remember correctly, one of the Gap-related interrupts keeps coming in if the DMAC is stuck. Interestingly, the PHT status does not seem to indicate that there is a problem; it just stays at something like 0x4011ff (I think).

Interesting... so the PHT's PStk bit never comes on huh? Looks like this issue might be an irritating one.

Or - let's just assume that the IEEE1394 buses are going to be error free, and such failures can't happen.
Yea, I know that this isn't good in error-prone environments, but receiving a request to an unaligned address shouldn't be an issue as long as the iLink hardware does as described in the Lead Vehicle document (Requests to unaligned addresses will get sent to the UBUF).

I wouldn't call a DMA page register "elaborate", its more of "we didn't have a working DMAC design when this system was due, so we just crammed in some sh*t we hope to work in more than zero cases".

Haha.

I always had this feeling that Sony didn't manage to complete developing the iLink system - since the ILINK.IRX driver isn't complete (No DMA support) and had it's full debugging information, assertions and strings left in it.

Hmm, that's really strange. I cannot test this at the moment, as I'm just using the PS2 as the target for async I/O, not as initiator.

Can't you read packets targetting the configuration ROM area from the UBUF, and handle them in software? If the DMA region is restricted accordingly, they won't be sent to the DBUF, so the DMAC should never get confused by them.

Scrap that. The DMAC is probably working fine.

If you read the whole of my previous message, you'll realize that I found the issue: Some of my packets were getting byte-swapped.

The DSIDB scripts I sent are all I currently have that uses the PHT. With DEn=0, I also managed to read received packets from the Rx DBUF manually, but I haven't yet tried to make the PHT send anything (aside from auto-DMA).

What do I have to do to get the PHT to receive more than one packet with DEn=0? With EnDMAS=1, it just puts the first received packet into the buffer, then quits any following incomming packets with a busy-ack, even if I did drain the buffer before. Do I need to send a response, or is there some other status bit somethere that needs to be changed? In my tests, I always had to reset the entire PHT to keep receiving the next packet...

You can't, since it's a hardware limitation.
The DBUFs were designed to handle one packet at a time.

Only the UBUF has such functionality (If you enable URcvM in CTRL0). But I don't think that it's a really good idea to enable it as the UBUF is small and the PS2's IOP is slow! The odds of losing a packet might be high, since the IOP can "miss" interrupt assertions.

I think this is a quite optimal setup. Too bad we don't have two DMA range registers, one for each PHT...

We don't? What about the "other" set of registers at 0xBF8015B4 and 0xBF8015B8?

Of course, you must understand that I don't know what those registers really are for sure. I assumed that the register blocks for DMA channels 14 and 15 are similar.

Speaking of unknown registers, what about 0xBF8015DC and 0xBF8015E0? Those are 2 unusual registers.

Did I understand correctly that you configured DMA channel 15 and PHT1, which then effected packets sent via the other PHT0? Or are you sending the packets via PHT1 as well?

Not really.

Yes, I'm sending data via PHT 00 and requests are handled by PHT 01.

Since SBP-2 transactions require the target to respond to the transactions initiated by the initiator (The console), a response will be sent.

All inbound packets will be handled by PHT 01, including the responses from the target (Even though the original requests were sent by PHT 00).
Requests from the target will also be handled by PHT 01.

(Read below for more details. But basically, some data that gets exchanged seems to have gotten altered by the DMAC)

I noticed something similar with packets received in Win1394. I'm not sure at the moment how the data looks when using Kermit, but I definitely remember having to swap bytes under certain circumstances for UBUF transfers.

I noticed that too. Why does it seem like quadlet requests and responses don't have to be byte-swapped?!

Isn't that related to the fact that ffff:f0000400 is way outside the DMA range?

No, since the Management ORB isn't related to the Configuration ROM.

The Management ORB is a special SBP-2 Operation Request Block (ORB) that has management-related functionalities. To connect to a SBP-2 device, a login Management ORB has to be accepted by the target.

Hence, the login process is roughly as follows:

1. The initiator prepares a Login Management ORB.
2. The initiator then writes the 48-bit address of the ORB to the Management Agent CSR of the target.
3. The target then attempts to retrieve the Management ORB from the initiator with read request(s).
4. The target validates the Management ORB, and shall reject the login request if the initiator was already logged in.
5. The target shall write to the status FIFO of the the initiator with the Fetch Agent CSR's address if login was successful. The address of the Status FIFO is recorded in the Login Management ORB.

Are you sure you are not referring to the sender's node ID field in the packet?

I'm very sure about that!

I did some checking again, and now it's getting weirder: Without DMA support enabled, the requested address looks like this: 0x0000 001f2b68

With DMA support enabled, the same request goes through the UBUF instead: 0xc1ff 001f2b50.

Odd, huh?

Of course, I could have missed byte-swapping a packet somewhere, causing the IEEE1394 enclosure to request data from a malformed address. (I did mention that the byte-swapping issue appeared again after I enabled DMA channel 15).

The full headers would be something like this:

Without DMA support: 0xffc10000 001f2b68
With DMA support: 0xffc0c1ff 001f2b50

As mentioned above, the packet gets handled by the UBUF instead of the PHT when DMA support is added.

I had this problem before, but can't remember why or how it went away. I think that it went away after I made my driver byte-swap the payload in the areas it does today.... so I didn't really find out why that happened.

Surely sounds like the DMAC is doing something, but I fail to see why just enabling it should cause byte swaps. 1394 uses big-endian by design, so in a little-endian system like the IOP there must be some component that does it, but I would have expected the PHT/LVDMA to handle it, rather than the node controller doing so when putting data into the UBUF.

Thanks.

Yea, the basic iLink hardware doesn't byte-swap the data by itself.

The problem with the byte-swapping code is like this:

1. The driver most likely originally had bugs, or the DMAC tends to automatically byte-swap the data around.
2. If the driver was buggy, the design of the driver and the bugs must have somehow worked well with each other, hence still allowing IEEE1394 packets containing understandable data to be generated and received.
3. Since the DMAC has been added to the equation, the way data is put into packets has been changed.
4. Since the way the data is now put into packets has changed, there is a possibility that the DMAC has "corrected" a set of malformed packets (Since it should generate valid packets with valid data) and has hence caused code in another area to break because the data is no longer encoded in the expected endianess.
5. I know that it's confusing, but just think about it in this way: Incorrectly encoded data will always be interpreted in the correct way by incorrectly-implemented code. Correcting the data will cause the data to be interpreted incorrectly by the incorrectly-implemented code.

Yes, this is what should be done in a release driver to protect sensitive areas. I would even go further and restrict DMA to just a single driver-allocated buffer, so no external component could effect the IOP in any way.

Sony seems to have taken that approach... but it really isn't too practical on the IOP because the IOP is slow. D:

Win1394. It allows sending basically arbitrary requests over the 1394 bus, using the 1394diag (for real devices) or 1394vdev (for virtual ones) driver. These drivers are a particularly well-known example of how not to write 1394 drivers in Windows, as they expose the entire 1394 bus driver to arbitrary user-mode components. There are a lot of bugs in the drivers (certain versions of 1394diag crash if their device is disconnected ), but a restricted subset of their functions (notably the async I/O) works quite well.

Thanks.

The address and length can be read from bf8015c0 and bf8015c4, respectively, although addresses are just 21-bit then. You could even disable the channel by clearing the bit in PCR3 (bf8015f0), then the CHCR would stay with TR=1 and the initial address and length stored in the channel registers. At least it works this way on the TOOL; you can even start the DMA transfer yourself afterwards, just be enabling the channel in PCR3.

I didn't think of polling the DMAC registers. D:

Another part of the problem I face with SBP-2 is knowing WHEN the target (The enclosure) is done with the ORB list.

That brings me back to my question: How do we know when to poll the registers? Since the DMAC handles all packets passed to it, requests and responses will get processed silently.

What I thought would be an ideal solution would be to poll the appropriate registers at the end of DMA transfers (And hence, an interrupt would need to be triggered at the end of DMA transfers).

The problem is: Which is the interrupt number of that interrupt event, and how does that get enabled? I've tried all interrupt numbers that are "unknown" to us so far (A few below 0x1A and every number from 0x1A to 0x50), but none of them seem to work.

Maybe it's because no DMA transfers actually took place within my driver. (Now, that will be disappointing! ) :P

Offtopic: Oh gosh. It's 03:13 here. Gotta sleep! D:
I hope that my words here will make sense to you - since I'm prone to writing nonsense when I'm not alert.

[SP193]

Yup, I have confirmation that at least the DMA module of the SCPH-39006 console has been activated and is working.

I've also found a way to detect and reset the PHT + DMAC if it stalls.

What I did was to leave the DRFR interrupt event enabled, and check the status of the DMA channel's CHCR register whenever the DRFR interrupt event occurs.

If bit 31 is set when the interrupt occurs, do nothing. If it's cleared, reset the PHT + DMAC.

I tried checking the DBUF Rx FIFO to see whether the contents can be salvaged, but it seems like the DMA module does chew up the data in the DBUF. D:

Hence, there is nothing we can do but to clear the FIFO and reset the DMAC.

I found that by checking the status of the MADR register whenever the DRFR interrupt event occurred, I could see the (probably last) memory address that the DMAC written to.

As I could see the contents of the MADR register changing (With valid values at most times), the DMA module seems to be working.

Since my IEEE1394 enclosure seems to request more data after the management ORB is sent, it's probably also an indication that DMAC #3 is working on at least the SCPH-39006 retail model console.

However, I've deemed my entire IEEE1394 + SBP-2 driver to be b0rked in design, as those 2 drivers now seem to be riddled with the byte-swapping problem.

Now, I don't even have to byte-swap the buffer addresses in the SBP-2 driver either - otherwise the address that gets used in the next request from the enclosure will be byte-swapped!

The problem now is that it seems like requests for the configuration ROM of my PS2 doesn't seem to work right - so there must be another problem somewhere else in my drivers.

And somehow, it seems like the DMA channel might stop working when other incorrect parameters are used - since I have found it to have stop working, despite having a valid memory address in MADR. This needs to be verified though, since there are too many unknowns and problems with the drivers I'm now working with. :X

(EDIT: Just in case you know something about this: The DMAC/PHT chokes on a request to write 8-bytes to a buffer aligned to a 4 byte boundary, but an earlier request to read 32 bytes from another buffer seemed to have completed successfully).

EDIT 2: I've fixed the problem with the Configuration ROM not being accessed. It was because the payloads really now don't even need to be byte-swapped.

But now, the problem I which mentioned earlier with the DMA channel freezing up when it attempts to write 8 bytes to the Status FIFO (Note: This is a software buffer in IOP Memory) still exists. D:
I guess that the reason for that is our of my grasp right now.

Unfortunately, I have a test to take tomorrow, so I need to study now...!

BTW: These are the only things that I suppose we lack - before we gain full control of DMAC #3:

1. How do we send data to the Tx DBUFs of either PHT? We have achieved automatic handling, but what if we would like to make a transmission?
2. Does DMA Channel 14 work in exactly the same way as DMA channel 15, with exactly the same features? (I don't know about you, but I know that I haven't done any real tests with the PHT 00 DMA channel yet.)
3. If there was a set of interrupts allocated for DMAC #3, it would be wonderful to discover the interrupt numbers of the DMA channels in DMAC #3.
4. The multi-million dollar question so far: What is DMA Channel 13 used for, if it's even connected to anything? (This isn't important, but it's probably good to know about DMA Channel 13 eventually...)

Of course, you might already have the answers to these points, since you are so quick at finding new information on unknown hardware.

But yea, we can already build a near-perfect, fully working DMA-enabled driver with the information and knowledge we currently have. (All thanks to you!)

[RandQalan]

Well SP193 and SilverBull Get OPL SMB faster BTW HEHE

Just a joke but would be nice thou

[SP193]

Well SP193 and SilverBull Get OPL SMB faster BTW HEHE

Just a joke but would be nice thou

The way for that to happen was already discovered long ago. However, nobody has made that route truly safe... yet.

@Silverbull: I made an error in my previous message: After I fixed the problems with the Configuration ROM not being read, there were actually 2 DMA transfers that got b0rked instead of one.

The 2 DMA transfers are as follows:

DMA Channel 15 CHCR: 0x40000200 MADR: 0x001f2b40 DLEN: 0x00010 SLICE: 0x004 <- This seems to be a transfer to the Login result buffer.
DMA Channel 15 CHCR: 0x40000200 MADR: 0x0006cb70 DLEN: 0x00008 SLICE: 0x004 <- This is a transfer to the Status FIFO.

Therefore, on the contrary to what I believed - the DMAC is probably not restricted to making transfers in 16-byte blocks, since even that 16-byte DMA transfer failed.

Right now, I'm trying to manually copy the data out of the DBUF Rx FIFO to the destination with the IOP. But even if I get that done, it's still better if this DMA transfer problem can be fixed.

BTW: I found that only bit 31 and the DMAC_CHCR_CO bits need to be set for automatic hardware responses to take place. DMAC_CHCR_CO seems to always get set by the hardware if it wasn't set.

UPDATE: I found out why inbound DMA transfers probably aren't working: The registers 0xBF8015DC and 0xBF8015E0 seem like the range registers for inbound DMA transfers.

After I filled them in, it seems like DMA channel 15 stopped shutting down whenever a write request is received.

Of course, since I am using a retail unit with almost no debugging tools whatsoever, those registers might not be what I think they are.... D:

[SP193]

Almost everything works now... but to my own horror, I think that the data written to memory via DMA transfers are byte-swapped.
That isn't good because data read in from SBP-2 devices must not be byte-swapped.

Did you get a similar result? Do you know how to disable this automatic byte-swapping behaviour? I tried toggling the LFIRST bit of the DMA Control and Status Register for PHT 01, but it doesn't seem to matter if that bit is set or not. D:

EDIT: The LFIRST bit isn't what I thought it was.
Anyway, is there a way to prevent the hardware from byte-swapping the data, if it's really doing that?

I do hope that this isn't the reason why Sony didn't include DMA support for the iLink.

UPDATE: I've found out what DMA Channel 13 is connected to: The Tx DBUF of PHT 00. I've successfully made a transmission with it.
The 2 registers at 0xBF801594 and 0xBF801598 seem to be the DMA transfer region control registers of DMA Channel 13. Without setting them up, the DMA channel doesn't function.

[SP193]

After I got about 16 hours of rest, I found that I had really overlooked this: My old iLink driver was already byte-swapping the data as it got written to IOP memory straight from Rx DBUF 01.

Therefore, there is nothing wrong with DMAC #3 nor the DMA module. (What a relief!)

However, this also means that it'll not yield any performance improvement for my SBP-2 drivers, as the data still has to be byte-swapped by the IOP first! argh.
Unless, there is a way to get the hardware to byte-swap the payload... or to get the enclosure to not byte-swap the data before transmission.

By the way: It seems like PHT 00 really has some defect/design fault, or it's subsystems have some problem: In my previous tests that I conducted a long time ago, I found that it was incapable of receiving disk sector data (Probably because it doesn't have the same size as Rx DBUF 01..?). The SBP-2 transaction just aborts with an error (A buffer-related error).

I tried using PHT 00 in place of PHT 01, but it still gave the same old errors, despite having DMA support enabled. Looks like a real hardware bug after all...

It works perfectly fine for data transmission though, as it always did.

I've also concluded that the channels are all uni-directional because:

1. RACtl needs to be enabled, meaning that there are 2 DMA channels for each PHT... but we don't know about the existence of the 2nd DMA channel for PHT 01.
2. The DR bit isn't present for any channel in DMAC #3, so how can we control the direction of DMA transfers for these channels?
3. My tests show that DMA Channel 13 and 14 are connected to PHT 00.

Oh well, it now seems like the only things I haven't confirmed myself are:

1. Since DMA Channels 13 and 14 only have a set of DMA Region (For data READING) registers, does this mean at the DMA region registers (For data WRITING) at 0xBF8015DC and 0xBF8015E0 are shared by all DMA channels? Somehow, it seems like at least DMA Channel 14 shares those registers with DMA Channel 15.
2. We don't know about the existence of the 2nd DMA channel for PHT 01... if it does even exist.

I hope that I didn't miss any more points and discoveries that I made.

Thank you very much for your help and support, SilverBull!

UPDATE: I forgot to mention that all of my attempts at manually initiating a DMA transfer with DMA Channels 14 and 15 have failed with my retail SCPH-39006 (And I think that it's the same on my SCPH-10000 console too). It seems like the IOP crashes after I set the TR bit (Bit #24).
It seems like DMA Channels 14 and 15 will only work properly when bit #31 is set... and without with external intervention.

EDIT: I wanted to ask you some questions via PM, but it looks like your PM box is disabled.

I wanted to ask how you were generating the Configuration ROM for your IEEE1394 driver, since I think that my Configuration ROM is broken.
(I have incomplete documentation regarding the structure of the Configuration ROM, and I think that I got confused by the need to byte-swap the data).

Oh yea, and it seems like the DICR registers are used to control the interrupt events that the DMAC will trigger interrupts for... but it doesn't exist for DMAC #3?! Hmm...

Yea, and I thought that I would also like to find out mode about the SSBUS too... since it seems like almost nobody on the Internet really knows what that is.

UPDATE 2:

ps2client -h 192.168.0.134 execee host:ilink_test.elf
loadelf: fname host:ilink_test.elf secname all
Input ELF format filename = host:ilink_test.elf
0 00100000 0001bb78 ..
Loaded, host:ilink_test.elf
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...
iLinkman loaded.
Modules loaded.
IEEE1394_disk: Vendor: Ext Hard
IEEE1394_disk: Product:  Disk
IEEE1394_disk: Revision: 
IEEE1394_disk: sectorSize 512 maxLBA 976773167
USBHDFSD: boot signature 55 AA
USBHDFSD: Fat type 32 Id FAT32    
Read test: ed400.
Start reading data...
Completed.
Done: 4 652588/13 734617
KB: 65536, time: 9, Approximate KB/s: 7281

7.2MB+/s!!!!

How my tests are performed: Since the IOP only has 2MB of EDO RAM in retail consoles, tests are performed as a series of 1MB block reads.
In this test, it was a 64-block read.

Note: As the IOP's sofware clock is slow and largely inaccurate, the speed might actually be way lower or way higher (Probably the later). Another thing that you must take note of is that that is not the performance of the disk + iLink port for large block reads, because there is no way for me to perform such a test.

Not only that, but the performance is being affected by the IOP taking it's time to byte-swap the data.

I did a test with a more blocks, and it gave about 6.8MB/s. Therefore, we can probably conclude that the PS2's iLink port is probably approximately that fast.... because of the IOP!

The SBP-2 transfer block size was set to 128KB.

Of course, I don't know whether the data read in is still of good integrity at all - since I don't have a way to check it's integrity right now.

(Hopefully, the data isn't corrupted at all, and this is really how fast the PS2 can go)

Just so you know how much you can push this DMAC:

DMA Channel 13: Max slice size: 0x400, DMA thresholds: Tx: 0x3FF, Rx: 0x000. (I doubt that this channel can be used to read data from the iLink hardware at all, so I set this to 0).
DMA Channel 15: Max slice size: 0x400, DMA thresholds: Tx: 0x00F, Rx: 0x3FF.

DMA Channel 14 is probably going to perform similarly as DMA Channel 15.

Now I wonder: In order for the ProView development team to build such a driver that gave about 10MB/s... do you think that Sony actually released some technical information to a 3rd party? That sounds like something that Sony will never do...

[SP193]

ps2client -h 192.168.0.134 execee host:ilink_test.elf
loadelf: fname host:ilink_test.elf secname all
Input ELF format filename = host:ilink_test.elf
0 00100000 0001b8f8 ..
Loaded, host:ilink_test.elf
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...
iLinkman loaded.
Modules loaded.
IEEE1394_disk: Vendor: Ext Hard
IEEE1394_disk: Product:  Disk
IEEE1394_disk: Revision: 
IEEE1394_disk: sectorSize 512 maxLBA 976773167
USBHDFSD: boot signature 55 AA
USBHDFSD: Fat type 32 Id FAT32    
Read test: e9e00.
Start reading data...
Completed.
Done: 4 613449/8 631811
KB: 262144, time: 4, Approximate KB/s: 65536

That's 256 MB read in 4 seconds, giving 64MB/s++. (!!! !!!! !!!)

I performed 256 x 1MB block reads, and only byteswapped the first sector so that the drivers can see that the disk is valid.

The timming calculations were performed with integers, so 64MB/s should be lower than the actual speed (Which is probably around 70-80MB/s).

What a stark difference... if the IOP wasn't involved or if it wasn't that slow!