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

[notlistening]

Hi all,

edit - how annoying double posting

Right we have a RTOS of choice found here:

http://www.qnx.com/

I haved looked at this thread regarding booting for qnx, might have a gem or two in there.

http://community.qnx.com/sf/discussion/do/listPosts/projects.bsp/discussion.bsp.topc2151;jsessionid=16C813ABB6E40BA25830FA684D907695

Sneaky SanDisk


Was a little bored so I gave my e200 a twirl through a few tools. This is what i got.

Code: [Select]

TestDisk 6.8, Data Recovery Utility, August 2007
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

Disk /dev/sdd - 4075 MB / 3886 MiB - CHS 1019 126 62
Current partition structure:
     Partition                  Start        End    Size in sectors

 1 * Sys=72               99607  97 11 245730  44 51 1141509631

Bad relative sector.
 2 * NetWare 3.11+        21593  80 47 269421  14 42 1936028240

Bad relative sector.
 3 * Sys=79               239360  18 30 487187  77 39 1936028192

Bad relative sector.
 4 * Sys=0D               369390 104 25 369397 117 33      55499

Warning: Bad ending sector (CHS and LBA don't match)
Only one partition must be bootable
    Next
*=Primary bootable  P=Primary  L=Logical  E=Extended  D=Deleted

Interestingly with some digging I found the partition type codes as it thinks they are.

72 V7/x86 - Robert Nordier writes: V7/x86, a port of UNIX Version 7 to the PC, is available at www.nordier.com/v7x86.

0e FAT16 LBA            65 NetWare 3.11+        c6 sec. Huge-bad FAT16

78 QNX POSIX partition (secondary)

0D ? not sure but playing around with the tool some more it indicateds it might be JFS Don't shoot the messenger. 

Bit more: This can up on further analysis

Code: [Select]

The harddisk (4075 MB / 3886 MiB) seems too small! (< 4077 MB / 3889 MiB)
Check the harddisk size: HD jumpers settings, BIOS detection...

The following partitions can't be recovered:
     Partition               Start        End    Size in sectors
D FAT32                    0   0  1  1019  68 28    7964672 [##PORT#]
D FAT32                    0   0  7  1019  68 34    7964672 [NO NAME]

When working with the tools i got a lot of this:

Code: [Select]

[50417.044276] printk: 375 messages suppressed.
[50417.044283] Buffer I/O error on device sdc7, logical block 786433

edit - just a little more

Code: [Select]

Warning: Incorrect number of heads/cylinder 255 (FAT) != 126 (HD)
Warning: Incorrect number of sectors per track 63 (FAT) != 62 (HD)
  FAT32                    0   0  1  1019  68 28    7964672 [##PORT#]
Warning: Incorrect number of heads/cylinder 255 (FAT) != 126 (HD)
Warning: Incorrect number of sectors per track 63 (FAT) != 62 (HD)
  FAT32                    0   0  7  1019  68 34    7964672 [NO NAME]

I think it was when i specifically got photorec to work on the netware partition, also reset my usb hub and all the devices on it a few times.

During all of these test I found that my e200 went through stages of dieing firstly a few error, then more until it dropped off  usb completely.


Hope this helps can shed some light on other models etc.

Tom

[fragilematter]

I've modified 0x1FF and 0x3FF to 0xDD and it booted just fine. Then I modified 0x3FF to 0xAB, just for the sake of variety. Again, it starts up and plays with no problems. I guess the headers are checked only on firmware update 
Now I'll move on to modifying  mkamsboot.c so it places code after the OF. Oh, I almost forgot, the OF update file is 15MB in size, so the 0xDEADBEEF padding in the dump probably serves as reserved space, for a maximum of 32MB of firmware.

Edit: OK, scrap what I said earlyer about the reserved space. As I assumed initially, the OF isn't identical to the disk dump. The firmware update process probably moves things around.
The beginning of the dump has a (more or less) "correct" header structure, according to what we observed in the firmware update image.
But, in the dump we have 0xDEADBEEF padding from 0x1CEF400 to 0x1DFFBFB, and then the bytes 31 F9 7E 9D (at 0x1DFFBFC-0x1DFFBFF). These bytes are identical to the last four bytes of the update image, the only difference is that there they're at 0xEFFFFC-0xEFFFFF.
I'm thinking of using an algorithm similar to the one used in rsync to spot the portions common to the update image and the nand dump.

Also, to ease handling, I think it's safe to strip the dump to 31456252 Bytes, after this offset we have some 0 padding and then a FAT:

Code: [Select]

0x1DFFC00-0x1DFFFFF        0 padding
0x1E00000                         FAT start
0x1E00003                         OEM name - MSWIN4.1
0x1E0000D                         Sectors/cluster - 64
0x1E0000E                         Reserved sector count - 32
0x1E00010                         Number of file allocation tables - 2
0x1E00011                         Max number of root directory entries - 0
0x1E00015                         Media descriptor - 0xF8 : Hard disk. Single sided, 80 tracks per side, 9 sectors per track
0x1E00016                         Sectors per fat - 242
0x1E00018                         Sectors per track - 63
0x1E0001A                         Number of heads - 255
0x1E00026                         Extended boot signature - 0x29
0x1E00036                         FAT file system type - FAT16
0x1E001FE                         Boot sector signature - 0x55 0xAA

Edit2: I've updated http://drop.io/sansahack with the stripped dump and also a delta file I made with rdiff against the update image e200pF.bin v3.01.16F.
So, to get the dump just run

Code: [Select]

rdiff patch e200pF.bin OFtoDUMP.delta dump.bin

[atomikpunk]

Ok so to read the GPIO A pin 3 (which could be the hold button in my findings), you will need to use something like this test.S file:

Code: [Select]

OrigEntry:
  .word 0

  /* Enable the GPIO module clock */
  LDR   R1, =CGU_PERI
  LDR   R2, [R1]
  MOV   R0, #0x10000
  ORR   R2, R2, R0
  STR   R2, [R1]

  /* Be sure  GPIOA port is set to all inputs*/
  LDR   R1, =GPIOA_REG
  MOV   R2, #0
  STR   R2, [R1, #0x400]

  /* A little delay - not sure it is needed but it doesn't hurt */
loop:
  NOP
  ADDS  R2, R2, #1
  CMP   R2, #100
  BLT   loop

  /* Read GPIOA pin 3 */
  LDRB  R2, [R1, #0x20]

  /* Check its state */
  CMP   R2, #0
  MOV   R0, #0x1

  /* Delay only if bit is cleared (arbitrary) */
  MOVEQ R0, #0x500000
loop2:
  SUBS  R0, R0, #1
  BNE   loop2
  
  /* Jump back and resume! */
  LDR   PC, OrigEntry

.set  CGU_PERI,   0xC80F0014
.set  GPIOA_REG,  0xC80B0000

So the test simply check the state of the GPIOA3 pin and wait or not depending on the state. Don't forget however that the OF itself does different things if the hold button is set or not at the moment the device is booted (display a lock or boot normally). Those who will test it should notice the (quite long, about 5s) delay.

Please review this code and try it on a unbrickable device (like the e200), I suggest that Daniel tries it first since he knows how to unbrick is player, or that he teach others how to do it.

Please post your results here!

[fragilematter]

OK, the firmware update went OK. However, it seems the delay is tripped no matter what the state of the hold button is - i.e. about 6 seconds total boot time.
If you want to see for yourself have a look here http://video.google.com/videoplay?docid=1469507032638365055

Edit: weirdly, I get boot times of ~1second if I start the device by plugging the usb connected to a 5v power supply, both with hold on or off. Either GPIOA pin 3 becomes 0 or sansas boot differently when you plug in your cable (less likely)... I'll test this using the unconditional delay (the test.S from SVN).

[atomikpunk]

Hmmm ok thanks for the test. In the video, first time is with hold and second is without?

I'll dive again in analysis then :'(

[fragilematter]

Simple delay test completed: the delay is there no matter what. So you are detecting the usb cable through GPIOA3 or something.

I haven't thought of simply connecting the usb just to the sansa, no PC or power supply, just to see if it has a way of detecting just if the cable is connected (a resistor in the plug, between 2 pins of the connector or something), but I've flashed already. Either way, I don't think that would help too much in development.

But hey, you finally made a breakthrough. Great job!

[funman]

Ok so to read the GPIO A pin 3 (which could be the hold button in my findings), you will need to use something like this test.S file:

Code: [Select]

  LDR   R1, =GPIOA_REG
...
  LDRB  R2, [R1, #0x20]

Shouldn't we load [R1] ? (GPIOA_DATA, offset 0 relative to AS3525_GPIO1_BASE)

[atomikpunk]

Hmmm I doubt that pin A3 is USB but that's not impossible, could you test again with USB plugged in (or not plugged in if it was already in your 1st test) and see if it makes a difference?

funman, look above, I load R1 with the GPIOA base address

[funman]

Yes but then you load [R1, #0x20], and I understand that it should be [R1]
a.k.a GPIOA_DATA and not GPIOA_DATA+0x20

[atomikpunk]

Re-read the register description

So that GPIO bits can be set without affect to other pins in a single write operation, the address bus is used as a mask on read/write operation. The data register covers 256 locations in the address space. The eight address lines used are PADDR[9:2]. During a write, only GPIO1_DATA,... bits corresponding to HIGH address bits are updated. During a read all data bits corresponding to HIGH address bits are read, the other bits are zero.

So to read pin A3, one must read at GPIOA_BASE + 0x20 which is address line A[5] high, or pin A3 (5 - 2) as expected. If you would like to read all GPIO pins at once, you would read 0xC80B03FC, which is address pins [9:2] high.

[fragilematter]

Okay atomikpunk, I hope this will clarify as to why I'm saying it works when you plug the usb in: http://video.google.com/videoplay?docid=-402239299533763874 (it might take a few minutes before google video processes it).

In a nutshell: by starting the sansa using power button (either with hold on or off) you get the delay. But if you start the sansa by plugging it into a powered usb port (the one in the video is a Motorola phone charger with the wire clipped and a usb port attached at the end) you don't get any delay.

[funman]

Hi all, I have some good news

atomicpunk found the hold button on the Clip, it is GPIOA_PIN3 like suspected.

I ran the following code on my device:

Code: [Select]

OrigEntry:
  .word 0

  /* Enable the GPIO module clock */
  LDR   R1, =CGU_PERI
  LDR   R2, [R1]
  MOV   R0, #0x10000
  ORR   R2, R2, R0
  STR   R2, [R1]

  /* Be sure  GPIOA port is set to all inputs*/
  LDR   R1, =GPIOA_REG
  MOV   R2, #0
  STR   R2, [R1, #0x400]

  /* A little delay - not sure it is needed but it doesn't hurt */
loop:
  NOP
  ADDS  R2, R2, #1
  CMP   R2, #100
  BLT   loop

  /* Read GPIOA pin 3 */
  LDRB  R2, [R1, #0x20]

  /* Check its state */
  MOV   R0, #0x1
  CMP   R2, #0

  /* Delay only if bit is set (arbitrary) */
  MOVNE R0, #0x500000
loop2:
  SUBS  R0, R0, #1
  BNE   loop2
  
  /* Jump back and resume! */
  LDR   PC, OrigEntry

.set  CGU_PERI,   0xC80F0014
.set  GPIOA_REG,  0xC80B0000

Since on the Clip you can not press the power button, and set hold at the same time I used a trick:
I power it by plugging it over usb.
If hold is on: you'll notice a 5s delay (PIN A3 is set)
If hold is off: boot immediately

Now hunting the other buttons, and still hunting hold on the other models

[fragilematter]

Basically you reversed the behaviour (atomikpunks was delaying when the bit was cleared and yours delays when it's set), but that doesn't explain why it behaves like that on e200v2's (or at least on mine).

Still, it's nice to see things are moving! Way to go!

[funman]

the buttons may be wired differently on each model, I'm trying to see in the e200 firmware if I find a routine similar, maybe it's another pin you need to test.

Note: you can try testing other pins yourself by changing the code:

Code: [Select]

  /* Read GPIOA pin 3 */
  LDRB  R2, [R1, #0x20]

0x10 is pin2, 0x08 pin1, 0x04 pin0, 0x40 pin4 etc..

EDIT: it could be C1 on the e200, can you try these modificatons fragilematter ?

Code: [Select]

  LDRB  R2, [R1, #0x8]
...
.set  GPIOA_REG,  0xC80D0000 /* not GPIOA but GPIOC */

[fragilematter]

Thanks for looking
It's pretty late to do a "testing spree" today , but I'll try different offsets tomorrow and see if I get something