Rockbox Development > New Ports
SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
daniel_at:
Hello,
just short notice:
I d/l the latest fuzeV1 ( http://forums.sandisk.com/sansa/board/message?board.id=sansafuse&thread.id=33874 ) original firmware, and found that the SVN-mkamsboot does not know this version (1.2.28). I tried it, patching, booting (OF and RB) works. On a 8GB, Fuze V1.
--- Code: ---Index: mkamsboot.c
===================================================================
--- mkamsboot.c (Revision 23063)
+++ mkamsboot.c (Arbeitskopie)
@@ -196,6 +196,7 @@
{ MODEL_FUZE, "1.01.15", "df0e2c1612727f722c19a3c764cff7f2" },
{ MODEL_FUZE, "1.01.22", "5aff5486fe8dd64239cc71eac470af98" },
{ MODEL_FUZE, "1.02.26", "7c632c479461c48c8833baed74eb5e4f" },
+ { MODEL_FUZE, "1.02.28", "5b34260f6470e75f702a9c6825471752" },
{ MODEL_C200V2, "3.02.05", "b6378ebd720b0ade3fad4dc7ab61c1a5" },
--- End code ---
Daniel
funman:
thanks for testing daniel, it's r23067 (one day too late for mkamsboot 1.1 though)
yelped:
What's wrong with the mp3encoder included with Rockbox? It outputs a lot shorter files with squeaky voices. Does this happen on all targets, or only on the Fuze? If so, why?
Thanks a lot for the great work.
FlynDice:
@funman
re ata_sd_as3525.c: Tell me if I'm understanding correctly
line 130 #define UNALIGNED_NUM_SECTORS 10
738 if(transfer > UNALIGNED_NUM_SECTORS)
739 transfer = UNALIGNED_NUM_SECTORS;
740 if(write)
741 memcpy(uncached_buffer, buf, transfer * SECTOR_SIZE);
It seems we are using transfers of at most 10 sectors(1280 Byes), memcpy to uncached buffer, then dma uncached buffer to MCIFIFO(drive). I assume this is so the dma can use an uncached, aligned buffer.
I hope this is a silly question ;), if we're going to end up memcopying the whole thing to the buffer anyway, why don't we just memcopy to the FIFO in the first place...?
funman:
Good point.
We also do a memcpy from MCIFIFO when reading to use an aligned & uncache buffer to be sure the data cache in synchronized with memory (no data in the cache).
Ideally we would only use aligned buffers and sizes multiple of 32 (cache size) and use cache invalidating functions but we would need to check all calls to storage_(read/write)_sectors. You could keep an eye on FS#9708 because I think that's exactly what they are doing.
When we were not using DMA but direct copy from/to the FIFO in the isr we sometimes had problems where we wouldn't be fast enough to fill/empty the FIFO and transfer would fail. Now perhaps the situation changed since the icache is enabled.
I think we should wait until DMA is enabled on PP and remove the memcpy, I just assume DMA is faster than a FIFO copy in the isr. Of course feel free to make benchmarks ;)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version