Rockbox

On my Archos Recorder V2, when running recent versions, including 3.10RC and r31107, entry into USB mode can be slow and problematic. Unfortunately, I'm not always able to reproduce this. When it happens, it happens repeatedly, but sometimes it repeatedly doesn't happen. Based on the following 3 pieces of evidence, it seems like Rockbox is trying to do something with the disk after the USB to IDE bridge chip is allowed to start using it.

When it happens, there is a long wait before the USB screen is displayed, during which time the red LED is on. I hear disk access as if there is disk access from the computer, and there are many disk errors in dmesg. The LED goes off right before the USB screen appears.

I edited r31107 firmware/usb.c to write strings at various points of usb_slave_mode(). When the problem happens, the string from after cpu_idle_mode(true) is on the screen and the red LED is on.

In the SMART error log on the original DK23EA-20 drive (accessible via smartctl), I saw ICRC errors, which I think means interface CRC, meaning Ultra DMA CRC. This would be consistent with Rockbox doing stuff which corrupts DMA data. (The ISD-300 configuration EPROM has been modified to enable Ultra DMA, using this http://www.rockbox.org/wiki/UDMAonUSB ) The drive passed the long SMART self-test, and reading of the entire drive surface completed without any errors reported or logged.

Edit: I have traced it to an opendir_uncached("/.rockbox/fonts") that starts after the end of usb_slave_mode(on). So, I guess the font code needs some changes. It would also be nice to have something at the storage or ata level preventing further storage access after storage_enable(false).

Edit 2: I have now traced it to an opening of the font file in glyph_cache_save(). Fonts are closed in gui_usb_screen_run(), but usb_acknowledge(SYS_USB_CONNECTED_ACK) happens before it. So, USB mode can be activated before font_unload() calls. In this patch, I move the usb_acknowledge(SYS_USB_CONNECTED_ACK) to just before the while (1) main loop of the USB screen. This fixes the problem on my Archos Recorder V2, and USB mode entry becomes fast and reliable. It ought to be safe to put the acknowledge earlier, but I see no problem with putting it just before the loop.

I have an electrical concern relating to this bug. It's not good to have the CPU fight the bridge chip. If one pin drives an IDE bus line high and another pin drives it low, that could overload the pins. I'd like to have more protection here, such as pin setup via ata_enable(false) which ensures that the CPU can't drive the IDE bus and/or blocking of disk activity at the ata or storage level. However this this patch ought to be good enough for now.

 apps/gui/usb_screen.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)