Rockbox

In my OF disassemblies, this register set shortly after the OF is loaded in a "system_init" type function.
For the c200 & hdd1630 (pp5022) and the sa9200 (pp5024), it is XMB_RAM_CFG |= 0x4FA (⇐= NOT what Toni has above).
For the m:robe100 & tpj1022 (pp5020), it is XMB_RAM_CFG |= 0x400.

Of course there are also lots of other registers being manipulated in the section of code, some of which are clearly usb-related, and some which appear to be clock related (perhaps peripheral clocks). Also, I can't say that this register isn't touched in other parts of the OF.

NOTE: in the Rockbox PP5020 register definitions, we refer to XMB_RAM_CFG = 0x7000003c. However, according to the m:robe diagnostic menu, this register is misdefined. It defines XMB_NOR_CFG = 0x70000034 and XMB_RAM_CFG = 0x70000038.

Yes, you are right.

Initially the OF or-s with 0x4FA, but later on USB detection the register is first bic-ed with 0x85 then or-ed with 0x20, which gives effectively oring with 0x47A. The register shows 0x8005E6FA before and 0x8005E67A during USB connection in the OF. 0x8005E200 in rockbox before my mod.

I don't think, that the OF restores the old value after disconnection. I couldn't read the exact value, because the OF quickly reboots after disconnecting.

Toni, you are right ;)

Here's what the Philips SA9200 OF does: http://pastebin.com/m362a572a

There seems to be another error (I think Toni mentioned it in IRC):
usb-drv-arc.c:line 413 should be: while ((inl(0x70000028) & 0x80) == 0);

I can't see any significant difference in the number of packet errors with or without these changes.

With the changes in the original post, I was able to transfer 35GB in Rockbox/SansaE280 without a disconnect on my problem machine. Without it transfer failed at ~1GB.

Michael, that sounds promising.
Frank, is there an easy way (either on sansa or in Windows/Linux) to detect packet errors?

Toni: not really. They are handled transparently by the hardware, so software doesn't even know about them (unless there are too many in a short time, in which case the hardware does notify the software side).
I'm looking at them with a hardware tracer, so I can see things like retried packets reasonably easily.

The fact that  FS#10015  improves things does make me think that the problem is in talking to the controller on the sansa side, not actually on the wire ( FS#10015  shouldn't change anything on the wire, but it does seriously reduce the number of times we talk to the controller)

This doesn't seem to hurt on ipod in any way, so I'm committing this.