SanDisk Sansa m200 series (v1)

[LambdaCalculus]

Mine is a NAND based... anyone want to trade?

[rickbronson]

  I've been thinking about this SD NAND bridge.  There must be a way to disable the bridge because the TCC770 needs to be able to talk with the NAND directly when it boots.  There is no way the TCC770 can boot via SD (that I can tell).  So it must be doing this upon boot:

1. SD bridge is wired to NAND and TCC770 is wired to NAND.
2. Upon boot SD bridge tristates output to NAND.
3. TCC770 boots and boots from NAND via direct connection.
4a. Booted software (HARP) detects presence of SD bridge and tristates NAND direct connection and uses SD bridge only.
4b. Booted software (pre HARP) detects no SD bridge and continues to use NAND direct connection.

  Make sense?

[LambdaCalculus]

Very interesting. I think the next step now is find some way of monitoring the boot sequence of a NAND and HARP m200, and comparing the results.

I'll try and see if the OF brings up any juicy info.

[shotofadds]

  I've been thinking about this SD NAND bridge.  There must be a way to disable the bridge because the TCC770 needs to be able to talk with the NAND directly when it boots.  There is no way the TCC770 can boot via SD (that I can tell).

It's a possibility, sure. Although for this to work, the bridge would have to be disabled at reset as I doubt there's any hardware-specific code in the TCC770 boot ROM.

But in that case, the experiment to read the NAND chip id should have been successful....  maybe I'll have a go if/when I get some time next week.

Very interesting. I think the next step now is find some way of monitoring the boot sequence of a NAND and HARP m200, and comparing the results.

Might be a good idea to look for differences in the startup code between the v1/2/3.xx firmwares?

[LambdaCalculus]

Might be a good idea to look for differences in the startup code between the v1/2/3.xx firmwares?

A very good idea indeed, shotofadds. I'll try and look for the firmware updaters for each version. I'll let you know if I find anything.

[rickbronson]

  I thought it would be a good idea to be able to read registers on running Sansa firmware so I wrote a c program that overlays code in the SANSM200.rom image then calculates the CRC and makes a new SANSM200.rom.  This file is then put on a m230 in the root directory, when the USB cable is pulled it does a firmware update (but only if the battery is very fresh!).  I found the tiny subroutine that runs when the "Information" menu is brought up.  The program that I overlayed prints one different register each time you go out of, then into "Information".  Here are some interesting register values:

   .word   0x80000300    //   GDATA_A   got: 00005fef
   .word   0x80000304    //   GIOCON_A  got: 00000070
   .word   0x80000308    //   GSEL_A    got: 00000080
   .word   0x80000310    //   GDATA_B   got: 003a0f5c
   .word   0x80000314    //   GIOCON_B  got: 002cfca3
   .word   0x80000318    //   GSEL_B    got: 000012a3
   .word   0x80000320    //   GDATA_C   got: 02000000
   .word   0x80000324    //   GIOCON_C  got: 03ffffff
   .word   0x80000328    //   GSEL_C    got: 00000001
   .word   0x80000330    //   GDATA_D   got: 000000d0
   .word   0x80000334    //   GIOCON_D  got: 00000030
   .word   0x80000338    //   GSEL_D    got: 00000002
   .word   0x80000340    //   GDATA_E   got: 00000000
   .word   0x80000344    //   GIOCON_E  got: 000000ff
   .word   0x80000348    //   GSEL_E    got: 00000000
   .word   0x90000050    //   NFC_CTRL  got: 00f00131
   .word   0x9000012C    //   SDIDCTRL  got: 00001494
   .word   0x90000130    //   SDISTAT   got: 01604080
   

  Anyone have any other register (or anywhere in the whole memory space) they are interested in?

[shotofadds]

I wrote some code that attempts to read the NAND chip id, which I've put on the tracker as FS#9096. On my rev.3 m230 this displays NAND id 0x0 0x0... as if no chip were present, but on the rev.1 or C100 it seems to cause a freeze instead. Anyone want to take a look?

I don't think I've mentioned it here or the wiki yet, but there are a set of pins which control the boot mode. They're just to the right of the LCD and are marked "NAND", "BANK1", "BANK2", "TRI-F" and "USB". Of these only "TRI-F" is connected on my rev.3.

If the "USB" pins are connected when inserting the USB cable, the device will boot into USB-boot mode, which is nice.

[rickbronson]

shotofadds,

  This is what I got when I tried to get nand id's, all zeros.  Yesterday I tried setting all of the GPIO and NAND registers to what they are in the running product but still didn't get anything. 

  On a different subject, one thing I found that made me curious is this register:

   .word   0x80000364    //   BM        got: 00000013

  This tells me that the tcc770 is booting off of EEPROM.  Anyone know anything about this?  If this is true then the tcc770 may be going right from EEPROM to SD in the boot process and the NAND may not be tied directly to the tcc770.  I looked at the board and did see a  10 pin part marked "SCTI AIP" that could be a EEPROM

  Rick

[atomikpunk]

Hi guys,

sorry to spam your thread but I'm currently working on the sansa v2 port and I bought an m230 off ebay. Unfortunately it is one with the v.2.2.5 firmware, so it is a "v1 hardware". I'm interested in trading this one for a "hardware v2" one, that is one with a v.4.x.y firmware. I really don't care the flash size and I understand that mine is only 512Mb, but for rockbox development, it doesn't matter.

So if anyone reading that thread is willing to trade, please contact me via personal message...

Thanks and good luck with the v1 port (which seems to go smoothly as I can see)!

[shotofadds]

A quick update on current progress, for NAND M200s at least:

The TCC780x (D2) NAND driver has had a few tweaks applied and now also runs on TCC77x, as ata-nand-telechips.c. With current SVN it's possible to call ata_init() from the bootloader and read sectors with some degree of success. If you're lucky (and you've enabled HAVE_FAT16SUPPORT) it may even successfully mount the partition.

The logical/physical block translation scheme appears to be almost identical to the D2, but the current implementation is not perfect, so incorrect data is sometimes/often returned. From what I've seen so far, these kind of errors seem to occur more frequently on the m200 than the d2.

To try and investigate further, I've written a quick-n-dirty Windows program to write raw sectors with known values to the M200 UMS volume, and some Rockbox code to read/verify those using the NAND driver. The first test successfully read the first 16Mb with no apparent errors. I'll try to do some further tests to track down the remaining problem(s) in the next week or two, but no promises...

  This tells me that the tcc770 is booting off of EEPROM.  Anyone know anything about this?  If this is true then the tcc770 may be going right from EEPROM to SD in the boot process and the NAND may not be tied directly to the tcc770.  I looked at the board and did see a  10 pin part marked "SCTI AIP" that could be a EEPROM

Sorry, I hadn't seen your post until now. That certainly goes a long way to explaining how those HARP versions might boot. I'm not really that familiar with the various boot modes available - does the datasheet give any clues as to how you might read data from that chip?

[shotofadds]

Time for a quick update...

Thanks to some sterling USB work by vitja and gevaerts, I've been able to dump enough raw NAND data from my M200 (harware revision v2) to the PC to be able to perform some useful analysis. I /think/ I now understand the FTL well enough to produce a reliable read-only Rockbox driver (the results of some initial PC-based tests run look encouraging).

The bad, but somewhat expected, news is that this seems to be using a slightly different FTL scheme to the D2 (and iAudio 7?). It's very likely the Logik DAX and C100 use this scheme, though.

The two schemes can probably be runtime-detected, but it'll likely work out easier to split the driver into a common raw NAND access layer (the existing ata-nand-telechips.c?) with separate ftl-v1 and ftl-v2 layers selected at build time, depending on the model.

I hope to find enough time at the weekend to update the Rockbox driver and do some testing on the device. Wish me luck!