SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2

[mbr]

Here is a patch by kugel and me which enables scrollwheel acceleration on e200v2: FS#10151. Maybe someone with an e200v2 can have a look at it.

The patch works on my e250v2

[funman]

Hi.

I have played with FS#10048 and noticed something interesting:

When declaring IRAM as cached/bufferable, rockbox sometimes boot, sometimes crash.
When it boots I can decode/play (perfect sound) ~20s of audio before it crashes.

I had the time to use test_codec before rockbox crashes, and decoding speed was significantly higher! (required freq for MP3 : 36MHz)

So the slowness problem definitely comes from caching.

Since rockbox continues to crash / deadlock (even with caches disabled), we probably have remaining bugs in our drivers, which might be more visible when caches are enabled...

So, TODO : read carefully all the as3525 drivers and look for bugs

[saratoga]

I had the time to use test_codec before rockbox crashes, and decoding speed was significantly higher! (required freq for MP3 : 36MHz)

Wow even faster per clock then PP or the Gigabeat F!

When declaring IRAM as cached/bufferable, rockbox sometimes boot, sometimes crash.
When it boots I can decode/play (perfect sound) ~20s of audio before it crashes.

Do you flush the caches before/after DMA transfers to IRAM then? 

[sko]

I updated FS#10151: it's compiling again (didn't work since r20757)

[funman]

Do you flush the caches before/after DMA transfers to IRAM then?

Only before transfers, did you look at FS#10048 ?

Other topic : I started looking at USB code, and indeed the registers look very similar to AMD 5536 UDC, but some are missing (from AS3525, or from AMD 5536).

A problem is that I don't see any FIFO mentioned in AMD 5536 or AS3525, I still have to read the Linux source code to see how data is transferred.

[daytona955]

There seem to be Linux USB gadget drivers for the Synopsys DesignWare HS OTG core (as per the AS3525 PDF) here:

http://svn.dd-wrt.com:8000/dd-wrt/browser/src/linux/rt2880/linux-2.6.23/drivers/usb/dwc_otg

and here:

http://casper.berkeley.edu/svn/trunk/roach/sw/linux/drivers/usb/gadget/dwc_otg/

Dunno if that might help?

The  licence seems quite permissive...

[funman]

Thanks, but it doesn't appear to be a compatible device:

Register at offset 0x404 is "Host Frame Interval Register" while in AS3525 datasheet and AMD5536UDC it is DEV_CTL (and I couldn't find at least one register that matches)

Here are some differences between the registers list in AS3525 datasheet and AMD5536UDC (perhaps different hardware revisions of the same chip?):

EP In Status Mask Register (EP in base + 0x18) is absent from AMD5536UDC datasheet
EP In Write Confirmation Register (EP in base + 0x1C) is absent from AS3525 datasheet

The RX & TX FIFOs are absent from both datasheets but are documented to be at 0x800 (RX) and 0xC00 (TX) in the linux driver source code.


I'm reverse engineering the usb_functio & otg_functio library blocks from Clip firmware to try to see more light but it's a bit difficult: the code appears to be compiled C++ and use a lot of pointers and structures (perhaps something to do with class inheritance).

[kugel.]

You don't seem to be interested in the MMU stuff right now anymore? It would be awesome if we could figure it out, USB is (IMO) not really essential now (i.e. if we want to release the sansas, we should fix the mmu stuff before caring about USB).

In any event, could you post the code with which you were able to have caching + playback for 20s anywhere?

[cyclon1978]

i adopted the lcd yuv blit patch for sansa e200. please check FS#10165 http://www.rockbox.org/tracker/task/10165 and if it can be commited it should be merged with FS#10118 http://www.rockbox.org/tracker/task/10118, it uses the same lcd_write_yuv420_lines/lcd_write_yuv420_lines_odither function. No need for duplicated code ;-)

maybe the lcd_window_blit function can be split into window_x and window_y functions like the fuze version do it...

thanks,

Andreas

[funman]

Yes of course I'm still interested!

I want to work on USB to be able to use logf() through usb, and see more exactly when our Sansas stop working (it's a bit hard when the lcd screen doesn't work!)

The code I used to have playback + caching for 20s is nothing but the patch you posted on FS#10048 with these diffs:

• Enable dcache & icache (they are explicitely disabled in sansa_as3525.c)
• Enable caching for IRAM (CACHE_ALL) only, not for SDRAM (CACHE_NONE)
• Uncomment dcache invalidation (before read_sectors() ) and dcache writeback (before write_sectors() ) in ata_as3525.c

Just see my comment on Apr 3rd (in FS#10048) : I think nothing changed since, except that I don't remember trying playback.

In short I don't have any code to share which isn't on the flyspray task already :/

[sko]

Could someone with a fuze test how the scrollwheel works in spacerocks, please? On the e200v2 the spaceship turns in wrong direction or don't turn at all if I turn the wheel to fast. I want to know if this happens on the fuze too, as they basically use the same scrollwheel function.

[PouncePony]

Scroll wheel works properly in Space Rocks on the Fuze.

-Pony

[sko]

Scroll wheel works properly in Space Rocks on the Fuze.

-Pony

Thank you. I'll try to have a look at this, as it seems to be related to scrollwheel acceleration and repeats, which seem to work on e200v2 not as good as on the fuze until now.

[Hillshum]

I'm having serious issues on my e260, but I get it in the OF too (even without any RB code) so I think it's hardware related.

[fenugrec]

Has anyone officially contacted Synopsys ? (www.synopsys.com)
They made the IP for the USB core, it would be this one:
http://synopsys.com/dw/ipdir.php?ds=dwc_usb_2_0_hs_otg

p.162 of this doc has more general information :
http://www.synopsys.com/dw/doc.php/doc/dwf/manuals/dw_frg.pdf

Having the official pdf from Synopsys would be a plus...
I tried looking around on the website, and registering on the
website was next to impossible, so perhaps an official contact
from Rockbox would have more success ?

Also, it would seem that AMD's 5536 has a different core altogether -
the datasheet doesn't mention OTG compliance, and looks more like
a complete host controller than a device.. I may be quite
wrong on this though, I just skimmed over the 5536 datasheet.