Rockbox

Tasklist

FS#12363 - Sandisk Sansa Connect port

Attached to Project: Rockbox
Opened by Tomasz Moń (desowin) - Wednesday, 02 November 2011, 21:35 GMT
Last edited by Tomasz Moń (desowin) - Thursday, 17 November 2011, 12:12 GMT
Task Type Patches
Category Operating System/Drivers
Status Closed
Assigned To No-one
Operating System All players
Severity Low
Priority Normal
Reported Version Release 3.9
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

I am attaching patch adding initial support for Sandisk Sansa Connect.
Installation currently requires little hardware modification to bypass the check.

Bootloader build is assumed to be installed in place of vmlinux - it can boot both OF (by pressing PREV whilst booting; vmlinux.bin and initrd.bin are being searched on storage and then loaded) and Rockbox.

Included is initial support for following:
-buttons
-lcd
-sdhc
-backlight

Easiest way to test new builds of Rockbox main binary is to set device into "usbautoboot" mode (login into OF shell and issue command "ptool -s usbautoboot 1") and then use zsitool to upload the binary (adding .srr header is required) into RAM.

zsitool can be found at: http://hg.atheme.org/users/desowin/zsitool/
Mentioned hardware modification: http://desowin.jogger.pl/2011/10/19/sansa-connect-hacking-cz-5-flashing-bootloader/
This task depends upon

Closed by  Tomasz Moń (desowin)
Thursday, 17 November 2011, 12:12 GMT
Reason for closing:  Accepted
Additional comments about closing:  Committed as r31000.
Comment by Tomasz Moń (desowin) - Wednesday, 02 November 2011, 21:36 GMT
There is initial version of the patch.
Comment by Tomasz Moń (desowin) - Thursday, 03 November 2011, 06:53 GMT
As per saratoga comment yesterday on IRC, I'm attaching new patch assigning copyright to me for all new files, even those that are mostly just a copy from other target (those files in fact contain just a stubs for specified driver).

Moreover, I fixed the model num to 81 in scramble.c and configure (a new target was commited with id 80 during my work on this port and I forgot to update those on merge).
Comment by Tomasz Moń (desowin) - Thursday, 03 November 2011, 09:22 GMT
I have found there's really ugly bug on multiple SD transfer to an unaligned buffer that was introduced when I switched the code to use DMA.

Attached (cumulative, supersedes previous patches) patch fixes it.
Comment by Tomasz Moń (desowin) - Friday, 04 November 2011, 07:56 GMT
Synchronized patch with current svn.
Improved button experience - scrollwheel still appears slow, but is much more deterministic now.
Fixed SD write operation as well as cache commit/invalidation.
Fixed plugins - those can load now fine.
Comment by Karl Kurbjun (kkurbjun) - Friday, 04 November 2011, 13:47 GMT
This patch looks really good. It is nice to see someone else using the DM320 port and it really worked out that you didn't need to touch much that would effect other targets.

Notes:
-------------------
CONFIG_SDRAM_START missing for Creative Zen and M:Robe

"#if defined"'s added to system-dm320.c for CREATIVE_ZVx are not accurate. They should just include the M:Robe, the ZVX port is broken and unmaintained.

Should system_prepare_fw_start be placed in the crt0-board.S along with an inclusion of the branch to that function?

This is not specific to your port: but in general it looks like system-dm320 needs to be re-factored so that we can avoid some of those ifdef's and isolate the target specific stuff. Not sure on an approach for that offhand.
-------------------

The work looks great. If you get to the DSP code and have trouble let me know and I will help out on that.
Comment by Tomasz Moń (desowin) - Friday, 04 November 2011, 15:29 GMT
Why do you say the CONFIG_SDRAM_START missing for Creative Zen and M:Robe when it's defined to 0x900000 (default value on reset) in their config files?

Changed the "#if defined"'s.
Changed few comments in code - no functional changes.

Comment by Karl Kurbjun (kkurbjun) - Friday, 04 November 2011, 15:54 GMT
Sorry about that. I forgot that it was already used/defined. No worries on that then.

One question on system-dm320.c:

Can this:
+#ifdef SANSA_CONNECT
+ IO_CLK_PLLA = 0xA0;
+ IO_CLK_SEL0 = 0x66;
+ IO_CLK_SEL2 = 0;
+ IO_CLK_PLLB = 0x1000; /* powerdown PLLB */
+ IO_CLK_DIV0 = 0x101; /* AHB, ARM */
+ IO_CLK_DIV1 = 0x102; /* Accelerator, SDRAM */
+ IO_CLK_DIV2 = 0x200; /* DSP, MS clock */
+ IO_CLK_BYP = 0;
+#endif

be placed in _init_board (crt0-board.S).. does it make sense?
Comment by Tomasz Moń (desowin) - Friday, 04 November 2011, 19:51 GMT
Yes, it does make sense.

Added crt0-board.S for this target which does initialization (Clocks, SDRAM, GIO).
Comment by Karl Kurbjun (kkurbjun) - Sunday, 06 November 2011, 03:31 GMT
Looks good.

One other thought:
It looks like the AVR code uses the second SPI interface. Is it possible to extend the existing SPI driver in spi-dm320.c so that it can talk through either controller?

The init function could probably setup both controllers since it disables the clock at the end anyway. The spi_targets structure could possibly include the target SPI controller as a field so that the same block_transfer function could be used for both controllers.

I am not sure if that is the best solution; I am just trying to avoid duplicate code.
Comment by Tomasz Moń (desowin) - Sunday, 06 November 2011, 06:05 GMT
I thought about that too, and even added the controller info to spi_targets, but after all, discarded that idea.

The main reason behind discarding that idea was that the SPI0 interface can do DMA, whilst the SPI1 can't - hence I think the functions in spi-dm320.c should be separate, with SPI0 using DMA.
The timings need to be fixed - the udelay(100) are just rought estimates that make sure all the commands work.

Given above reasons, it's why I decided to put that code into avr-sansaconnect.c.
Comment by Tomasz Moń (desowin) - Sunday, 13 November 2011, 16:14 GMT
Fixed bug in SD initialization which resulted in always setting slowest clock possible.
Fixed bug in LCD initialization which set other GIOs controlled by IO_GIO_DIR2 register.
Added I2C software implementation on GIO36 (SCL) and GIO35 (SDA) which is used in Sansa Connect (the hardware I2C cannot be used, as the pins are already occupied by SPI).
Added AIC3X audio driver.
Synced to latest SVN, added GUI boost support.

Changes to SD initialization greatly improves storage access - loading OF image from storage is now mere seconds instead of nearly two minutes.
Comment by Tomasz Moń (desowin) - Monday, 14 November 2011, 17:11 GMT
Software I2C implementation now uses generic I2C driver.
Fixed hold switch change detection (lost hold switch changes should be gone).
Use sleep(HZ/20) in lcd_sleep() instead of udelay(50000) to improve resonsiveness.

Loading...