Rockbox

Tasklist

FS#10026 - E200: Improve USB detection in WinXP

Attached to Project: Rockbox
Opened by Toni (ahellmann) - Sunday, 15 March 2009, 21:45 GMT
Last edited by Frank Gevaerts (fg) - Tuesday, 17 March 2009, 20:29 GMT
Task Type Patches
Category Drivers
Status Closed
Assigned To No-one
Operating System Sansa e200
Severity Low
Priority Normal
Reported Version Version 3.1
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

E200: Improve WinXP rockbox USB detection

With current SVN (in fact since the beginning of rockbox USB) I had the problem, that 7 out of 10 WinXP connections failed on the first try. A second try without reboot caused rockbox to freeze in the USB screen. If a connection was established (on the first try), I had no problems copying files from / to the sansa. After investigating the OF, I found the evil register, which seems to cause the problems.

In usb_init_device(void) (usb-fw-pp502x.c) I added the following register manipulation behind the udelay(100000) statement. This one liner solves the problems here and leads to the same behaviour as the OF. (no failed connections). After a short test I found no negative impact on other software parts.

XMB_RAM_CFG |= 0x47A; (added below udelay(100000); in usb-fw-pp502x.c
This task depends upon

Closed by  Frank Gevaerts (fg)
Tuesday, 17 March 2009, 20:29 GMT
Reason for closing:  Accepted
Additional comments about closing:  Committed as r20344
Comment by Mark Arigo (lowlight) - Monday, 16 March 2009, 14:05 GMT
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.
Comment by Toni (ahellmann) - Monday, 16 March 2009, 17:21 GMT
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.
Comment by Mark Arigo (lowlight) - Monday, 16 March 2009, 20:04 GMT
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);
Comment by Frank Gevaerts (fg) - Monday, 16 March 2009, 20:35 GMT
I can't see any significant difference in the number of packet errors with or without these changes.
Comment by MichaelGiacomelli (saratoga) - Tuesday, 17 March 2009, 01:47 GMT
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.
Comment by Toni (ahellmann) - Tuesday, 17 March 2009, 07:22 GMT
Michael, that sounds promising.
Frank, is there an easy way (either on sansa or in Windows/Linux) to detect packet errors?
Comment by Frank Gevaerts (fg) - Tuesday, 17 March 2009, 12:30 GMT
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)
Comment by Frank Gevaerts (fg) - Tuesday, 17 March 2009, 20:22 GMT
This doesn't seem to hurt on ipod in any way, so I'm committing this.

Loading...