Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Patches
  • Category Operating System/Drivers
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version Release 3.9
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by desowin - 2011-11-02
Last edited by desowin - 2011-11-17

FS#12363 - Sandisk Sansa Connect port

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/

Closed by  desowin
2011-11-17 12:12
Reason for closing:  Accepted
Additional comments about closing:  

Committed as r31000.

There is initial version of the patch.

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).

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.

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.

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.

Why do you say the CONFIG_SDRAM_START missing for Creative Zen and M:Robe when it’s defined to 0×900000 (default value on reset) in their config files?

Changed the “#if defined”‘s.
Changed few comments in code - no functional changes.

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 = 0×66;
+ IO_CLK_SEL2 = 0;
+ IO_CLK_PLLB = 0×1000; /* powerdown PLLB */
+ IO_CLK_DIV0 = 0×101; /* AHB, ARM */
+ IO_CLK_DIV1 = 0×102; /* Accelerator, SDRAM */
+ IO_CLK_DIV2 = 0×200; /* DSP, MS clock */
+ IO_CLK_BYP = 0;
+#endif

be placed in _init_board (crt0-board.S).. does it make sense?

Yes, it does make sense.

Added crt0-board.S for this target which does initialization (Clocks, SDRAM, GIO).

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.

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.

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.

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...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing