Rockbox Technical Forums

Rockbox Development => New Ports => Topic started by: Bagder on November 29, 2007, 03:04:23 AM

Title: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Bagder on November 29, 2007, 03:04:23 AM
Hey,

We can discuss many things for these players generically, since they seem to share a lot, not the least the main chip AS3525. Which is why I created this new thread.

Speaking of this chip, I've got the data sheet from AMS for it.

Things we need to search for:

1. Figure out the firmware format. There seems to be a header with checksums of some sort, we need to figure them out.

2. We need to see if we can get some kind of recovery mode or something, that will enable us to try possibly bad firmwares and yet be able to recovery and get back to a working state.

3. We have disassembly work to do to figure out stuff that isn't in the data sheet, like LCD (this is likely to differ between the players)

My "sansa v2" summary page: http://daniel.haxx.se/sansa/v2.html
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2) and clip
Post by: skaos on November 29, 2007, 01:27:30 PM
Just a small detail: It looks like the Clip doesn't use SDRAM whereas the others do.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2) and clip
Post by: dan_a on November 29, 2007, 05:48:57 PM
I've ordered a Clip from Amazon, and I'm going to start on getting the simulator to compile.
I've not been able to find the screen dimensions on the web - does anyone know them?

EDIT:  ABI (http://www.anythingbutipod.com/compare/sandisk-sansa-c200-vs-sandisk-sansa-clip-vs-sandisk-sansa-express) say that the Clip has a 128x64 screen.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2) and clip
Post by: saratoga on November 29, 2007, 06:27:14 PM

I've ordered a Clip from Amazon, and I'm going to start on getting the simulator to compile.
I've not been able to find the screen dimensions on the web - does anyone know them?


Given that the clip appears to have just 312KB of RAM, I'm not sure how feasible a rockbox port is.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2) and clip
Post by: dan_a on December 03, 2007, 03:32:05 PM
Does anyone know anything about the file format for the firmware on the V2s?
Obviously it isn't the MI4 files as it is missing a PPOS header.  It doesn't look like raw ARM code, although it is not encrypted.  There is some kind of checksum, as I tried changing one of the strings and upgrading, and the upgrade didn't take.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2) and clip
Post by: Bagder on December 03, 2007, 04:42:46 PM
Some initial trivial findings on the .bin format:

The first 0x400 bytes is clearly some kind of header,

The header data at 0x0 is about 0x20 long and is repeated (almost) verbatim at 0x200, and between those the bytes are all 0xff... At 0x400 you can clearly see the ARM exception vectors.

At index 0x0 there's 32 bit 0, at index 0200 there's a 32 bit 1.

I would expect the numbers at 0x4 and/or 0xc to be some kind of checksum.

The bin files are all exactly 0x500400 bytes large except the e200v2 one, but I'm not sure that image is correctly saved/dumped/extracted.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2) and clip
Post by: Bagder on December 03, 2007, 05:37:31 PM
index   description (value is 32bit unless otherwise noted)

0x0     0
0x4     checksum?
0x8     type? (e4/e8/ed/ea)
0xc     some kind of value that is hardly a checksum as the value differ in
        the four files only between 0x01c6ac and 0x01d854. Possibly it is a
        16 bit value with 0x0e being another 16bit value always set to 0x01!
0x10    0x03
0x14    16 bit checksum3 ?

        Interesting detail about the byte at 0x15: it is 0x22, 0x23, 0x24 and
        0x25 in the files we have...

0x16    16 bit zero
0x18    0x40
0x1c    0x01

0x3c    0x5000 (in the e200 alone)

0x200   0x01
0x204-0x021f same as 0x04-0x1f

0x023c  same as 0x3c (in the e200 alone)

0x400 ARM exception vector and code following

(at the end of the image there are nice "de ad be ef" paddings! :-)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2) and clip
Post by: dan_a on December 03, 2007, 05:51:18 PM

(at the end of the image there are nice "de ad be ef" paddings! :-)


With 4 bytes at the very end - another checksum?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2) and clip
Post by: Bagder on December 03, 2007, 05:56:33 PM

With 4 bytes at the very end - another checksum?


Weirdly enough, the m200 and c200 images don't have those extra 4 bytes
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2) and clip
Post by: Bagder on December 04, 2007, 06:51:13 AM
I figured out the checksum on index 4 and it also uses the value at index 0x0c (I wrote a small tool that can reproduce the value). See my description in-progress:

http://daniel.haxx.se/sansa/v2.html
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2) and clip
Post by: Bagder on January 04, 2008, 05:59:17 PM
Didn't someone already provide a fdisk -l output for one of the v2s? Has anyone tried to scan the disk for the firmware image?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2) and clip
Post by: rondestvedt on January 05, 2008, 04:05:30 AM


I'd say the main problem is that nothing much is actually going on, it is much more talk about what is going on or what could go on...


Well, I'm extremely interested in making this port happen, I just don't have a lot of experience with this sort of development...

What's the next step?  From what I've seen the next big hurdle is figuring out how to upload new firmware to the v2s.  Unfortunately I didn't have a USB monitor set up when I updated my e250v2 using the SanDisk's updater.  It does not appear that there's a way to downgrade using SanDisk's updater and who knows when a new OF update will be issued.


I was able to successfully downgrade the firmware on a e250v2 from 3.01.14A back to 3.01.11A just by using the e200pA.bin file from Daniel's page here -> http://daniel.haxx.se/sansa/v2.html. After putting the .bin file in the root directory while in MSC mode, and after unplugging the USB cable it brought up a screen saying "Firmware update in progress".After it restarted the info page showed 3.01.11A as the firmware. The only problem is if the firmware update is bad, will it still be able to do another update?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2) and clip
Post by: Bagder on January 05, 2008, 07:00:54 AM
So, a daring person can thus get the .bin file, modify the 32bit value at index 4 (the checksum) and try to upgrade to that, just to see what happens... It might cause trouble, but I expect SanDisk to have some kind of precaution against damaged binaries so my hope is that this triggers some kind of recovery mode.

Another test is to modify a few strings in the image and recalc an updated checksum (based on the algorithm posted on the v2 page) and see if that is accepted and works.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2) and clip
Post by: rondestvedt on January 05, 2008, 01:20:50 PM
I just tried a simple test. I switched the positions of two letters in the message that comes up when you power on with the hold button on. The message saying that the firmware update was in progress came up, then after a few seconds it powered down without a firmware update complete, and the firmware was unchanged. I'll try again later using the checksum calculator with the same changes.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2) and clip
Post by: jcollie on January 05, 2008, 03:06:49 PM

Didn't someone already provide a fdisk -l output for one of the v2s? Has anyone tried to scan the disk for the firmware image?


The v2 disk does not appear to be partitioned, so "fdisk -l" will likely just print garbage.  I dumped the entire drive and tried searching for "AS3525" (which is a string I saw in e200pA.bin) and couldn't find it, however that could because I'm running the newer firmware version.  Could the v2s have a separate flash memory area for storing the active firmware that isn't exposed by the USB interface.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2) and clip
Post by: Bagder on January 05, 2008, 04:10:15 PM

Could the v2s have a separate flash memory area for storing the active firmware that isn't exposed by the USB interface.


It could certainly have that. Either there's a separate NOR flash for the firmware or it is simply stored somewhere on the NAND that isn't made available over usb-storage.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2) and clip
Post by: gletob on January 06, 2008, 08:28:58 PM
here is the output of fdisk -l for my c250 v2
Code: [Select]
owner@glenn-desktop:~$ fdisk -l /dev/sdf

Disk /dev/sdf: 2044 MB, 2044198912 bytes
63 heads, 62 sectors/track, 1022 cylinders
Units = cylinders of 3906 * 512 = 1999872 bytes
Disk identifier: 0x6f20736b

This doesn't look like a partition table
Probably you selected the wrong device.

   Device Boot      Start         End      Blocks   Id  System
/dev/sdf1   ?      199216      491461   570754815+  72  Unknown
Partition 1 has different physical/logical beginnings (non-Linux?):
     phys=(357, 116, 40) logical=(199215, 34, 11)
Partition 1 has different physical/logical endings:
     phys=(357, 32, 45) logical=(491460, 44, 51)
Partition 1 does not end on cylinder boundary.
/dev/sdf2   ?       43188      538843   968014120   65  Novell Netware 386
Partition 2 has different physical/logical beginnings (non-Linux?):
     phys=(288, 115, 43) logical=(43187, 17, 47)
Partition 2 has different physical/logical endings:
     phys=(367, 114, 50) logical=(538842, 14, 42)
Partition 2 does not end on cylinder boundary.
/dev/sdf3   ?      478721      974376   968014096   79  Unknown
Partition 3 has different physical/logical beginnings (non-Linux?):
     phys=(366, 32, 33) logical=(478720, 18, 30)
Partition 3 has different physical/logical endings:
     phys=(357, 32, 43) logical=(974375, 14, 39)
Partition 3 does not end on cylinder boundary.
/dev/sdf4   ?           1      931190  1818613248    d  Unknown
Partition 4 has different physical/logical beginnings (non-Linux?):
     phys=(372, 97, 50) logical=(0, 0, 1)
Partition 4 has different physical/logical endings:
     phys=(0, 10, 0) logical=(931189, 36, 30)
Partition 4 does not end on cylinder boundary.

Partition table entries are not in disk order

and  lsusb --verbose
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2) and clip
Post by: h2gofast on January 14, 2008, 10:37:28 PM
fdisk -l   for an e280 v2

Code: [Select]
Disk /dev/sdb: 8187 MB, 8187281408 bytes
252 heads, 62 sectors/track, 1023 cylinders
Units = cylinders of 15624 * 512 = 7999488 bytes
Disk identifier: 0x6f20736b

This doesn't look like a partition table
Probably you selected the wrong device.

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   ?       49804      122866   570754815+  72  Unknown
Partition 1 has different physical/logical beginnings (non-Linux?):
     phys=(357, 116, 40) logical=(49803, 223, 11)
Partition 1 has different physical/logical endings:
     phys=(357, 32, 45) logical=(122865, 44, 51)
Partition 1 does not end on cylinder boundary.
/dev/sdb2   ?       10797      134711   968014120   65  Novell Netware 386
Partition 2 has different physical/logical beginnings (non-Linux?):
     phys=(288, 115, 43) logical=(10796, 206, 47)
Partition 2 has different physical/logical endings:
     phys=(367, 114, 50) logical=(134710, 140, 42)
Partition 2 does not end on cylinder boundary.
/dev/sdb3   ?      119681      243594   968014096   79  Unknown
Partition 3 has different physical/logical beginnings (non-Linux?):
     phys=(366, 32, 33) logical=(119680, 18, 30)
Partition 3 has different physical/logical endings:
     phys=(357, 32, 43) logical=(243593, 203, 39)
Partition 3 does not end on cylinder boundary.
/dev/sdb4   ?      184696      184699       27749+   d  Unknown
Partition 4 has different physical/logical beginnings (non-Linux?):
     phys=(372, 97, 50) logical=(184695, 104, 25)
Partition 4 has different physical/logical endings:
     phys=(0, 10, 0) logical=(184698, 243, 33)
Partition 4 does not end on cylinder boundary.

Partition table entries are not in disk order
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2) and clip
Post by: hth on January 17, 2008, 02:03:19 PM
Quote
Has anyone tried to scan the disk for the firmware image?

Found no firmware on the mass storage device shown by my Sansa 280v2.

Is anybody certain that the SanDisk MCU (see bottom) is an AS3525? It's labeled different, though it's also CTBGA224, 13mmx13mm with 15x15 balls and with a quick glance i found 2 usb balls of the SanDisk chip at exactly the same location as the AMS SoC.

This is the information i found out so far:
I have found no information on the flash chips, but i suppose they are 2x4G NAND flash mapped to a 8G msc device. I *guess* they reserved at least the first x MB of either one or both flash chips and put the firmware at offset 0 of the first flash (at least it'd be the easiest to implement).

Read/Write spead to device: 4MB/sec.
Best case: Flash chips are class 4 -> 8G= concatenation of flashes
Worst case: Flash chips are class 2 -> capacity by xkB striping

Also found no way to initiate a firmware recovery, yet.

Odd things:
Also tried initiating a recovery mode by overwriting the hole disc with zero (in mind: firmware must be somewhere on the flash).
After a second or so (some of first MB nulled) the display changes from "writing" to "connected", and the process on my pc writing to the sansa hangs.
After disconnecting the e280v2, it fails rereading the media database (remember: vfat is stored on the beginning of physical target). I cannot tell the exact error message i got, but it was something like:
"Unable to read media database. Need at least 90MB space.".

Exactly the time you needed reading the message, the Sansa e280v2 turns off again. After several tries to access or write to the device (with the 90MB needed error followed by auto-turnoff), i managed to format the entire 8G device with fat32. Same message with autoturnoff.
After copying a backup of all files (as shipped) on the newly formated drive again, it worked. I chose format on the e280v2, to be sure nothing is corrupted.

I then tried to find that 90MB message within the firmware, but didn't find it, yet. Four possibilities to figure out:


Does anybody have a datasheet or the exact specs for the flash chip below?
Perhaps somebody got the specs for the Sandisk MCU (i already got the AS3525 datasheet from AMS; i hope finding out some details about the bootloader code on the 1M-ROM and wether a hardware recovery mode is implemented; based on AMS datasheet chances are 1/2 and 1/2)?
--
SanDisk Sansa e280 v2 with:
MCU: SanDisk, 20-99-00112-2, S735-691106, SDC1, TAIWAN = AS3525A?
Memory: 8MB SHDR-DRAM 4Mx16, Samsung K4S641632K-UC75
Flash: 2x4096G Flash , i.e. 2xSanDisk S747118642, SDTNLLBHSM-4096, CP0086818
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2) and clip
Post by: saratoga on January 21, 2008, 12:46:15 PM
I skimmed the firmware file.  Its actually quite readable, sandisk seems to have no problem with people looking at their stuff.

I think the firmware is basically a bunch of 100-200kb+ segments concatenated together.  Each one starts with a header like the one Bagder found that contains a simple checksum and the length of the segment.  You walk the file by reading the segment length from the header and then jumping ahead that many bytes plus however many bytes are needed so that you're 256 byte aligned.  That is sometimes the start of the next header, and sometimes the start of a "DEADBEEF" section followed by the header.  I'm not sure why they do that or how you know to skip over it.  I did this 4 or 5 times and it worked each one, but I didn't have the patience to go all the way through the file.  

Anyway, thats my quick look.  Hopefully its helpful to someone.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2) and clip
Post by: Bagder on January 21, 2008, 04:32:15 PM
Ah, cool. So perhaps the test (by rondestvedt 2008-01-05) that didn't manage to "upgrade" to a modified firmware altered strings in a section that did't get the checksum properly updated!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2) and clip
Post by: rondestvedt on January 21, 2008, 07:49:01 PM
My first test was flawed. I thought the checksum was just a simple addition of all chars in the file. After looking at Badger's code for the  checksum and seeing that it was adding 32bit integers instead of 8bit chars like I thought, I tried again, but instead of switching two letters side by side, I switched a group of 4 characters that were 32bit aligned with the beginning of the file. This time it successfully upgraded with the modified firmware, and I was able to see the changes I made. However this was just a simple switch, and the original checksum was not modified. I'm still wondering if the last 32 bits of the file is another checksum, as they differ between the versions 11 and 14.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2) and clip
Post by: Bagder on January 22, 2008, 06:47:46 AM
Then I guess another test would be to actually test with a changed checksum. And also see if you can change the file in another "section" than the first.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2) and clip
Post by: hth on January 22, 2008, 02:55:17 PM
Quote
UTF16 little endian to be specific, and I don't understand why that would tell if the image is complete or not...

This alone definetly doesn't tell that, sorry.

I was referring to my previous post: When first examining the firmware i didn't find an error message i was looking for and thought that maybe the e200p*.bin didn't contain the entire firmware, which seems to be wrong.

There's still a slight chance left for some hidden bootloader code on the flash.

I'm not sure yet either, but perhaps the firmware is a modification of AMS 's SDK for the AS352xs, which seems to be possibly build upon Segger's embOS, embFile and embWin. It also looks like the firmware contains parts of libjpeg for decoding jpeg files.

Sorry again if somebody got the idea that you can tell wether a complete
firmware image is distributed by a vendor by just looking at the encoding of
strings.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2) and clip
Post by: rondestvedt on January 24, 2008, 12:01:25 PM
I tried the same method, and it did not work. I did notice in the firmware files some strings that seem to be a diagnostic menu, with references to various kinds of tests, such as a sdram test and other hardware tests. Not sure but this testing mode might be related to a recovery mode, if we could find out how to activate it.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2) and clip
Post by: hth on January 24, 2008, 02:32:57 PM
Quote
My guess is that the sansa will refuse to upgrade to it. Did you compare the U60 .bin image   with the e2x0v2 one to see how similar they are? It could possibly help us figure out the remaining parts...


The U60 firmware image is crypted and i don't see a checksum at 0x4/0x204. If you have a look at 0xb4b400...0xb4bb9bf at the u60 bin, you see each 32-bit pair following a pattern regarding each half of each the high and low nibble of the most significant byte. This pattern can be seen at other offsets probably containing neither code nor data as well for byte 2..0, so the cryption varies with the offset.

[edit]merged follow up posting:
I found no recovery mode for the e280v2 yet, so i have some questions regarding recovery possibilities:

Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2) and clip
Post by: bucko on January 25, 2008, 05:02:24 AM
If you'll excuse my extremely fudgey C, I uploaded an "improved" checksum calculator here: http://www.bucko.me.uk/sansachecksum.c

It walks the file for quite a few blocks before exploding; I didn't bother to work out the offset into the file because I don't know how to fgetpos() an fd. :(

Many of the suspected "checksums" do not change between firmware versions -- even though the computed checksums do. So I don't think any of them are real checksums, and I'm probably missing something in my interpretation of the header.

I'd appreciate it if someone could clean it up and place it in somewhere appropriate.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2) and clip
Post by: bclick on January 27, 2008, 09:59:44 AM
I've discovered a few things:

1.) A factory diagnostic menu; to enable it, rename the FW file m300t.bin ("t" for "test") and place it on the device root, etc. Details on menu content at ABI forum, where I announced that finding to the community, here: http://www.anythingbutipod.com/forum/showthread.php?t=25408

Not sure if that works on the other V2 players based on the AMS SoC but, probably. BTW this was only verified on the .20 Clip FW.

2.) Hidden filesystem contents. By using a data recovery utility and connected in MSC mode, I found  a couple folders; ##MUSIC#, which is the MTP data, and ##PORT# (funny choice of name, eh?) which has some rather interesting file content. There is a ~20MB file called Object.dat, which I have not yet analyzed, but it does appear to contain references to the FW version, anyway, and could be the recovery mode image container (what's loaded if a FW update fails/aborts etc.).

3.) Firmware reference to MP3 encoder. Possibly this codec support is already there, but presently not used (would sure be better than WAV for voice and radio recording).

4.) Of my two Clips, one of them reports 1921MB total flash space, and the other 1949MB. Yes, same FW and yes I have reformatted them both. Probably bad NAND blocks.

EDIT - bucko - if you need a guaranteed V2 player - all Sansa Clips are AMS S0C based.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2) and clip
Post by: Bagder on January 27, 2008, 02:20:19 PM
Interesting find bclick! The "m300" name will of course need to be replaced with the one used for your target if you're gonna try this on your own (non-clip) Sansa.

So if you put the file there, all it does is make a new menu appear in the fw? Can you put any file there using that name, or is it in fact using the specific one you put there?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2) and clip
Post by: bclick on January 27, 2008, 03:27:35 PM
Yes, all it does is enable a hidden menu option. Not really much of interest in there to a porting effort, but the existence of hidden folders in the filesystem should be somewhat of interest...

You pose an interesting question...I suspected that the firmware is truly being read in, not just a matter of the filename being checked. To answer that, I changed one byte in one of the copies of the CRCs in the header and tried to update (the same version, different "letter code" in filename), and - it is refused, just like any corrupted FW...
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2) and clip
Post by: andva on January 27, 2008, 07:38:14 PM
Cool find! However, I'm _much_ more intrigued by fact #2....

To recap. Connecting in MSC mode, you find a file in the root directory (MTABLE.SYS) which contains the song database. In that file, you can see the following:

- the "drive letters" are "mmc:0" for the internal memory and (I think) "mmc:1" for the microSD card
- the format is (roughly) path, filename, album, artist, songname, genre and something else. The stock music is readily "seen" by the driver as being within the ##MUSIC# subdirectory. For instance:

mmc:0:\##MUSIC#\Music\Alias & Ehren\Lillian\

whereas the music copied over by using MSC are within (say) mmc:0:\MUSIC\whatever.

Besides, if you run "strings" on a firmware file, you'll see many references to ##MUSIC# and ##PORT#.

Since bclick found that these subdirectories were readily accessible, I suspected that they should be on the FAT somewhere, since that's the only place where the directory name is stored. (If it was, say, hardcoded to some sector, the directory contents could be found, but not the name). I tried making a directory called ##MUSIC# and seeing whether I could access the music. No dice. The directory was empty, and when I disconnected and reconnected, it had disappeared.

I then inspected the FAT in the device, and I have found the trick that the Sansa uses to hide the directories. They are regular files, but they have an attribute byte of 0x18. These two bits mean "directory" (0x10) and "volume label" (0x08). Since volume labels are ignored, no regular FAT driver is able to see the directory. But they are regular directories; you can go to the corresponding cluster and see the directory contents just fine.

I'm now using lde (Linux Disk Editor) to peruse the contents of the drive and I'm making some advances, although the ##MUSIC# directory is giving me problems (maybe there's another layer of protection so that the stock music can't be copied). But I can go to the PORT directory just fine. I'll keep you posted on that one.

EDIT - It is rather trivial to access the directories - just use an hex editor and change the 0x18 byte to 0x10, then remount the partition. I have successfully made a copy of ##MUSIC# and ##PORT# that way. (I rechanged the attributes byte to 0x18 before unplugging, so I don't know whether the Sansa would have reverted the change or not).

##PORT# does not look very promising, though (##MUSIC#, as  could be expected, contains the stock music). It contains a few images, the icon for the device, and "Object.dat" (mine is like 80Mb long, though). But I'd say "object.dat" is some kind of image of the device status (it seems to contain all the stock music, plus one recording I made as a test). I found no firmware references in the file.

I have also found that the ##MUSIC# directory I manually created was stored in the FAT, and that the Sansa had indeed changed its attributes to 0x18 (so there were actually two ##MUSIC# directories). Interestingly, the directory did contain an empty "skeleton" with the same subdirectories (and even files) making up the structure of the regular ##MUSIC# directory. Part of me wants to try what would happen when creating a ##PORT# directory, but my intuition is that it might not be a great idea ;)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2) and clip
Post by: bclick on January 27, 2008, 10:11:50 PM
Nice work, m8, thanks for picking up on that and making the effort...

Hopefully this pace of discoveries will continue!

Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2) and clip
Post by: andva on January 28, 2008, 08:43:12 AM
OK, so I'm now trying to get more firmware images by tinkering with the Sansa Updater. I have been using a packet sniffer (Wireshark) to get info about the update process. To be honest, I did not come up with that idea myself, I have seen it previously somewhere (I can't remember the exact place, maybe in the abi forums).

My findings so far:

The update procedure is initiated by the Sansa Updater program by requesting the following URL:

http://sansa.directory.flashcp.com/cocoon/bls/directory/get-project-details?dummy=dummy&project-id=SANSA

The Sansa Updater sets the User-Agent string to "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SansaUpdater)", but the server does not seem to mind. The above URL opens just fine under Firefox.

The result is a lengthy string which contains a few url-encoded parameters. Once unmangled, the information returned is:

status=ok
application-home-prefix=https://fe.gummo.flashcp.com/cocoon/bls/updates/SANSA/fe
project-server-prefix=https://fe.gummo.flashcp.com/cocoon/bls/updates/SANSA/fe
time-server-prefix=http://time.gummo.flashcp.com/cocoon/bls/time
project-server-keys=
time-server-keys=

There is another string (project) which seems to contain the same information, URL-encoded a second time.

It is not possible to access those URLs directly, they yield a Forbidden error. I'm now looking at the strings on "sansaupdater.exe" and trying to make some sense out of them; the updates info is probably obtained by adding several suffixes to the "project-server-prefix", including USB IDs and model numbers (and, maybe, some kind of device serial). If anybody wants to join the fun, be advised that the file is UPX-compressed.

@bclick: Thanks! You were the one starting it all  :)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2) and clip
Post by: andva on January 28, 2008, 11:01:40 AM
I then tried to find that 90MB message within the firmware, but didn't find it, yet.


Was the exact message "Not enough space for Music DB. Please free 90MB", maybe? It is on the firmware, and it is repeated in quite a few places (it seems to be the same in all locales).

The message, along with a bunch others, are UTF-16 encoded, little-endian. You can get a list of all those messages with "strings -e l e200pa.bin", or an adequate variation (Linux guy here).

I would say that everything that is meant to be shown on the player screen is UTF16 encoded.

I'm going over the non-UTF16 encoded strings. Some of them are rather interesting (for instance, something is supposed to trigger when you place a file called "ERASEME.CMD" in the flash root... and I bet that the earphones testing plays a file called "diagnosis.mp3" also located there). They are trivial to get by using "strings", but I can post the results somewhere if you want.

By the way. I was wrong when assuming that the recovery mode could be triggered by doing something before the "System shutdown" message which appears when you try to power up the device with HOLD engaged. These messages can be found on the firmware (non-UTF16 encoded) and, therefore, if they can be seen on the screen, it's already too late.

I suppose a lot of people have tried button combinations, but, just to confirm, did anybody try them while spinning the wheel? Each "click" counts like a button press.

Something very intriguing: There is a non-UTF16 encoded string which reads "Erase Firmware? Press center button to confirm". On the firmware file. If we can somehow get to the point where the firmware can be erased from within itself, I would suppose that the player would boot on the recovery mode. (Or be borked for all eternity :))

PS: I would also be in favor of contributing towards buying one or more Rockbox "senior" developers an v2 player, but I fully understand that they may not have the time, energy or inclination to assume the huge burden of porting Rockbox to the v2's.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2) and clip
Post by: DemonicAHole on January 28, 2008, 12:44:03 PM


I suppose a lot of people have tried button combinations, but, just to confirm, did anybody try them while spinning the wheel? Each "click" counts like a button press.


i tried to do that but to no luck, just does the usual "hold is on..system shutdown"

-p.s. i did it with hold on and then off, wheel goin both directions
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2) and clip
Post by: andva on January 28, 2008, 01:48:25 PM
Next installment: some work on the firmware format. Disclaimer: I don't know a thing about ARM code, but I can try to help :P

I have inspected the firmware binary file (for the e200), and, specifically, the "deadbeef" packing appearances. I have found some interesting structure to it, and I'll post it here in hopes that somebody with more knowledge of ARM assembler can pick it up.

The firmware seems to be divided in some kind of logical "blocks". The first area of the firmware comprises the first 122368 bytes (from 0 to just before 0x1DE00). Then, for simplification, the rest of the firmware can be divided on 77 blocks, each exactly 200 kb (204800 bytes) in size save for the last, which is ~40 kb. For convenience I have numbered these blocks 00 to 76 (I used a splitting utility). So the "header block" begins at the beginning of the firmware and is 122368 bytes long, and then "block N" begins at 122368+204800 * N (in hex, 1DE00 + 32000 * N) and is 200 kb long.

All the first blocks (the header and blocks 00 through 15) use padding. The padding is invariably a bunch of 0xFF bytes until what seems to be the next multiple of 512 (0x200), followed by 0xDEADBEEF padding until the end of the block. (This is not apparent in the header block because there is only a short FF section and no DEADBEEF; in fact, what I did was looking for the end of the DEADBEEF sequences, finding that they always were located 204800 bytes apart, and then extrapolating back to find the end of the header block.) These blocks look like some kind of "libraries" of code. I suspect that the main bulk of the code lies there.

By inspecting the strings, one can guess what each block is for:

Beginning block: initialization, basic filesystem operations, "tasks" (there are a few defined: Control Task, Decoder, Encoder, etc), a suspicious string which says "ASW is erased!", date and time functions, and probably the component which updates the firmware (the string E200P*.BIN is a giveaway)

Block 0: seems to be something related to the DRM
Block 1: more DRM-related things, a bunch of magic numbers, and what seems to be the default boot sector (maybe the formatting routine)
Block 2: something having to do with MSC (string: "Mass storage only"), libjpeg, and more magic numbers (video decoder?) Some firmware-related things, M3U reader, MTABLE.SYS reader, recorder, and Rhapsody-related things.
Block 3: Audible decoding, test mode, MTP implementation
block 4: no idea, could be some kind of image

From now on, one can find some of the functions referenced in the beginning block. The giveaway is that, at the end of each block, there is a string with the function name, plus "cr_5_0_develop" and what looks like a timestamp.

block 5: video decoder (near the end of the block, the string is "mp4_decoder")
block 6: mp3_decoder
block 7: wav_codec (recorder/player)
block 8: aud_decoder (Audible)
block 9: drmpd_persi (DRM related, probably)
block 10: Microsoft DRM in all its glory (drmpd_unlro and a few more things, the strings are a giveaway with things like "ExpirationDate", "FirstUseDate", etc).
block 11: drm_unloc function
block 12: wma decoder
block 13: more wma related functions
block 14: yet more wma/drm functions (it's disgusting how complex DRM is to implement!!)

Block 15 is totally empty (0x200 bytes of 0xFF padding, then DEADBEEF)

Blocks 16 to 22 seem to be data. Some of it looks like images. 17 and 18 contain all localization strings. 18 also contains the Rhapsody capabilities XML.

Block 23 contains the device certificate for the SANSA (more DRM things). There is some weird padding in it.

Block 24 is all DEADBEEF.

From now on, most blocks contain no recognizable strings. I think they contain all the artwork for the player, with no padding. Sometimes, the string HEADER pops up, but I don't know if it is supposed to mark the beginning of some data file.

From 71 on all blocks are all DEADBEEF, save for the very last 4 bytes, which, as Bagder has stated, could be some kind of checksum.

Hope this is of some use.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2) and clip
Post by: hth on January 28, 2008, 03:17:45 PM

I then tried to find that 90MB message within the firmware, but didn't find it, yet.


Was the exact message "Not enough space for Music DB. Please free 90MB", maybe? It is on the firmware, and it is repeated in quite a few laces (it seems to be the same in all locales).


Thank you! It was the message.

Quote
If we can somehow get to the point where the firmware can be erased from within itself, I would suppose that the player would boot on the recovery mode. (Or be borked for all eternity :))

Yes, there might be a chance, that after that the player would turn into
a mode supporting initial factory programming, but i'm not sure.

On the one hand, the rom on the SanDisk SoC may contain a different or elder bootloader not supporting usb proming.

On the other hand, i'm missing information on what the AMS rom-bootloader would do exactly and specifically, after triggering a usb bootloading mode. Maybe we trigger it, but don't see anything happening because it's

1. expecting to read the firmware from an usb device in a certain format (which is not described in the datasheet).
2. not able to control the lcd and thus able to display a message like 'no firmware for update found, bootstaging from nand.'

[edit]merge of follow up posting:

Next installment: some work on the firmware format. Disclaimer: I don't know a thing about ARM code, but I can try to help :P

Great work! I neither know much about ARM, but i've started reading quite a lot about it.

I hope the SoC supports fetching and executing instructions directly from the iNand after mapping the NAND memory into it's address space. As rockbox uses memory statically, it maybe able to reserve about 50k internal RAM for variables, another ~150k buffer for audio decoding and the remaining 120k free for other things.

If so, i will buy a cheaper DAP without additional SDRAM like the Sansa Clip and start coding a bootloader on that, first (in about two weeks, for i don't have much time until then). If it bricks, who cares, but i don't wanna brick my e280... :)

[edit]forgot something i tested out at home:
1. On e200 v2 players, the firmware copied into root must be renamed to e200pt.bin to enable diagnostic mode (so diagnostic menu may work on the m200 v2s as well).
2. Firmware updates (triggered by any file named e200p*.bin within root directory):
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2) and clip
Post by: andva on January 28, 2008, 07:41:29 PM
I wouldn't be _that_ surprised if the wheel had something to do with entering recovery mode. It is a remote possibility, since that would probably make it somewhat unreliable (you'd have to "click" just at the right time), but it can't be ruled out. The fact that the Clip does not have any rotary encoder is not definitive - after all, the e2x0v2 does have the same key that the c200 uses for (what seems to be) recovery mode, but the same trick does not work.

However, if the c200 has it, then I'm convinced that the e200 (more expensive, more complex) will also have a way of getting it into recovery mode. If the c200 way of doing it is any indication, then the steps are simple: turn off, set HOLD, hold a button (<< on the c200, but it does not work on the e200), plug it in, see what happens. We'll have to try one more time. ;)

With regards to the firmware files, if the "blocks" theory is correct, there are some interesting implications. The firmware-related strings (a la "Updating firmware") are, along with (almost) all others shown on the screen, on block 17. (Rule of thumb: If it is shown on the screen, it's UTF-16 encoded and on blocks 17 or 18). However, the glob pattern (E200P*.BIN, for my non-Rhapsody e200v2 player) is on the "beginning block" (along with the misterious ASW reference... ¿does the SoC have something called an "ASW"?). To complicate matters further, in block 2 there are some more intriguing references.

This is part of the result of running strings on block 2:
Code: [Select]

e200pV03
E200P.BIN
mmc:0:\ERASEME.CMD
Do Not Release This File In Public. Copyright SanDisk Corp. 2007
mmc:\UPGRADE.FIN
e200pSelfErase
#EXTM3U
#EXTINF:
Unknown
mmc:\MTABLE.SYS
##MUSIC#
FM%d_%01d-%02d%02d%02d-%02d%02d%02d
VORC0000.WAV
FMRC0000.WAV
thumbnail
%02d%02d%02d-%02d%02d%02d


ERASEME.CMD, E200P.BIN, UPGRADE.FIN and e200pSelfErase, to name a few, seem enticing.

Then, right after the e200pSelfErase reference (offset 0x2fabc), there is what, methinks, is the table with the allowed values for the firmware suffixes:


Code: [Select]

0002fabc  54 01 01 01 01 00 01 01  41 01 00 00 01 00 01 00  |T.......A.......|
0002facc  45 00 00 00 01 00 00 00  50 01 00 00 01 00 01 00  |E.......P.......|
0002fadc  46 01 00 00 01 00 00 00  47 00 01 00 01 15 00 00  |F.......G.......|
0002faec  48 01 01 00 01 15 00 00  4d 00 00 01 01 17 00 00  |H.......M.......|
0002fafc  4e 01 00 01 01 17 00 00  53 00 00 00 01 00 01 00  |N.......S.......|


Something interesting can be seen if we divide each row in two:

Code: [Select]

T: 54 01 01 01 01 00 01 01
A: 41 01 00 00 01 00 01 00
E: 45 00 00 00 01 00 00 00  
P: 50 01 00 00 01 00 01 00
F: 46 01 00 00 01 00 00 00
G: 47 00 01 00 01 15 00 00
H: 48 01 01 00 01 15 00 00
M: 4d 00 00 01 01 17 00 00
N: 4e 01 00 01 01 17 00 00
S: 53 00 00 00 01 00 01 00


Of the 8-byte counts, the first one is the prefix, and the other seven seem to be flags. We'll number them flag 1 through flag 7. Flags can (seemingly) take either 00 or 01 as a value, save for flag 5, which can be 00, 15 (21 decimal) or 17 (23 decimal). It seems that the firmware decides (in part) what set of capabilities it will have just looking at its suffix!

I have also reviewed bclick's original post at abi, where he took the time to go through all the letters with his m300 (thanks! :)). The only letters which did anything where the 10 letters in the table above.

Flag 1: By looking at the way it varies, I'd bet that this flag means whether the radio is enabled or not. This seems consistent with bclick's findings.

Flag 2 is only 1 for H, G and the test firmware. bclick reported that, in the m300, H and G were Hebrew and Greek respectively. So maybe this is an "allow alternate font" flag or something of the sort. Or, maybe, an option which controls whether Greek/Hebrew are present as options in the language selection dialog.

Flag 3 is only 1 for M, N and the test firmware. Same as above with "Arabic" (as bclick reported).

Flag 4 is always 1, so there's no way of knowing what it means.

Flag 5 is probably the default font/character encoding. I recall bclick reporting that, in the m300, M and N looked "like Arabic" (flag = 17), G Greek, and H Hebrew (both flag = 15). All others use the default font. The fact that this is the only flag that the test mode does not set is also worth noting.

Flag 6: I don't really know. Maybe whether the "high" volume option will appear on the menu?

Flag 7 is (quite probably) whether the "test" option will appear on the menu or not. It is only 01 for T, the test firmware.

From what I have gathered, I don't expect any other letter (or combination) to be accepted as a firmware update. Creating an ERASEME.CMD file on the root directory will probably reformat the Sansa (similar to the .fmt method for v1 hardware), but I'm not trying it just yet...

OK, (high) time to go to bed here in Europe. I expect something cool to have happened on the forum as I sleep, don't let me down! ;)

Cheers to all!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2) and clip
Post by: bclick on January 28, 2008, 08:46:14 PM
andva - Great work and excellent deductive reasoning. I had just duplicated that very effort, and came here to share it - it's still great to be late to the party!

On flag byte #5 - the T version has ALL languages supported. It is also confirmed that the Hebrew version omits Arabic, and vice versa (for socio-political reasons I suppose). All the other languages are supported by these versions. BTW, G&H are both Hebrew and M&N both Arabic; the difference of course being the radio enable bit.

I came upon the *.BIN suffix letters searching in the m300 FW (at 1D5F4) and at once realized I could have avoided trying all the letters...LOL...and the byte mask jumped out next. In the m300 (Clip, for me) FW, it is identical to what you have listed. So that's great - parallelism between models...

If you search for reference to the "version.sdk" file, it appears that this is written out if missing, using hardcoded strings from within the FW (but the FW version is dynamically written out..between the hard coded strings). Bear with me...

Now, what I suspect the ERASEME.CMD file contains is the text "Do Not Release.." etc., and some factory test / action results in the device writing this file to mmc:0:\ (root), possibly as a flash file system test file / debug flag.

Note the m300 FW appears to have nearly all the rest, including refs to JPG files (which, just ain't no way...), and a diagnostic menu for SD slot testing, as it's bigger brothers. Plenty of commonality. But on the Clip, the "free up space" string calls for "only" 30MB...

saratoga - good points. Somebody has to always throw cold water on!

j/k :D  - but even if a full RB port to the Clip is not feasible, there are those who would still be interested in exploring the possibilities and doing a little bit of "personalization", optimization, or plain old awakening of resident but inactive features. MP3 encoding for radio and voice recording alone would be huge.

EDIT - I put an ERASEME.CMD file on there (with just that notice text, no CR/LF), restarted, and....nothing. Music was not deleted, so it's presence alone won't trigger a format. The .CMD file itself was deleted, however.

AND - the UPGRADE.FIN file is written out after a firmware upgrade. I found it by loading a "new" FW file, disconnecting (FW loads, then shuts down), then connecting in "forced MSC mode" (unit OFF, switch in HOLD position, press center button, plug in cable, wait till "connected" is displayed, release center button). Apparently some house cleaning is pending. It contains a single byte (0x03) that decrements with each such connection, and it is deleted when it reaches 0 or the device is connected normally (I think). Anyway it's nothing very exciting.

:o I have also found that the FW can be loaded without any "region code" at all; as "m300.bin" it simply updates the existing version. Probably what the Sansa Updater delivers...

AND, m300SelfErase is nothing more than yet another mechanism to load firmware. I first tried placing a 0 byte file w/ that name, the Firmware Updating message came up, but no Completion. Renamed a copy of the FW file, and in it went, to completion - without altering the region code already in place.

EDIT Ditto for "m300V01"; yet ANOTHER FW filename... Sheesh! Wish there was something more useful to report - but at least, this is another "known"...

And no, ERASEME.CMD is not another way to load FW, and yes, I tried it  :P
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2) and clip
Post by: hth on February 02, 2008, 05:53:42 AM
While measuring here and there on an e200 v2, i found out something that maybe interesting:
On the right side of the front pcb (under the lcd, on its back is the micro-sd slot, about half an inch above the headphone), there are 8 blank connectors.
At the top of them, there's an arrow and the text DIP. I start counting the most top connector with 1, thus the bottom one is 8. The connectors are no dupe of the micro sd signals - which was what made me curious:

Measurings are quite inaccurate (about 2% tolerance)
Li-Io Battery: GND1..BVDD: 3.95V; GND2..BVDD: 3.91-3.92V
Resistance[Ohm] to GND: 1:15-17.5k; 2..7: INF; 8: 0
Voltage[V] to GND:
Code: [Select]

   Descr.;Supply over USB only; Battery supply only
1: VDD?? ; 3.12-3.13; 3.14
2: NC??? ; 0.00; 0.00
3: ??    ; 2.45; 2.46
4: ??    ; 2.45; 2.47
5: ??    ; 2.45; 2.46
6: ??    ; 2.45; 2.46
7: RST?? ; 2.90; 2.90
8: GND   ;

7: Looks like the player is off for less than a sec, then while still
   measuring:
   1.) SanDisk Sansa logo displays (like when turning on)
   2.) a) USB Connected: Connected message displays
   2.) b) No USB: Last screen displayed again, then music database is
                  reread
   This looks like a kind of reset, the 2.90V did not change.
   So maybe this connector is for diagnosis purposes!!!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2) and clip
Post by: Igge on February 06, 2008, 04:27:31 PM
Hello!

I'm very interested in a Rockbox version for the e200v2, too.

How big is the chance that there's a key combination for a recovery mode? I tried many combinations but none worked. And why should Sandisk change the key combination? Or is it a fact that a recovery mode is triggered by software?

FYI I made some pictures of my open e250v2. Feel free to use it:

http://img136.imageshack.us/my.php?image=img9629ny4.jpg
http://img136.imageshack.us/my.php?image=img9633ru5.jpg
http://img136.imageshack.us/my.php?image=img9640rw1.jpg

Igge
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2) and clip
Post by: Kakuwinki on February 26, 2008, 11:02:31 AM
Like I mentioned in this thread http://forums.rockbox.org/index.php?topic=13961.15, I have found a way to make the sansa e200v2 to stay on the opening video for about 30 seconds. Maybe at that moment, something should be tried to go in recovery mode?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2) and clip
Post by: dan_a on February 26, 2008, 01:50:32 PM
I've made a (very small) start on the Rockbox code for the V2s.  At the moment there's huge amounts missing - but hopefully I'll fill those in as I go.  For those using git it's in the Sansa_v2 branch at git://www.md1clv.com/Rockbox.git
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2) and clip
Post by: rasher on February 29, 2008, 04:36:44 AM
If you have one of these devices (except for the e280v2), please read this post which I accidentally posted over in the strict e200v2 thread, but meant to post here: http://forums.rockbox.org/index.php?topic=13961.msg117138#msg117138 and help us out with the USB vid/pids for your device.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2) and clip
Post by: ilikerockbox on February 29, 2008, 06:01:19 AM
Sansa Clip:

MTP
Bus 001 Device 118: ID 0781:7432 SanDisk Corp.
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x0781 SanDisk Corp.
  idProduct          0x7432
  bcdDevice           d3.38
  iManufacturer           1 SanDisk
  iProduct                2 SanDisk Sansa Clip
  iSerial                 3 5011F4065888B49F0000000000000000
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           39
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          4 config1: Mass Storage only
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              500mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           3
      bInterfaceClass         0 (Defined at Interface level)
      bInterfaceSubClass      0
      bInterfaceProtocol      0
      iInterface              5 sic ifac 1 (Capture::PIMA)
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               4
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  bNumConfigurations      1
Device Status:     0x0000
  (Bus Powered)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2) and clip
Post by: hth on February 29, 2008, 03:50:18 PM
The 8-pin header on the lcd's back i wrote about appears to be a JTAG port (maybe pin 4 is TMS), with no standard pin assignments (GND would be on 7 but is on 8, e.g.). I ordered an Olimex ARM-USB-TINY to find out more and verify the pin assignments and wait for a Sansa M240 for testing bootloader embryo.

Regarding the recovery mode, this would be too good to be true!!! However, i notice nothing different from normal operation (or i'm too dull, am i? :). AFAIK, the hold+rewind (aka hold+left button) combination on  power-on is assigned to MSC mode on the e200 v2s. So it seems this info is just given to ensure the transfer mode for uploading the firmware binary. I guess this triggers the regular firmware update code located on the NAND.

Btw., started coding the AS352X target, i.e. the CGU so far. I use the first AMS linux-arm patches as a basis and compare them to the AS3525 datasheet. OTOH, the files i stumbled upon are really incomplete, on the other, modifications for AS3527 targets should be minimal (on the audio part the 500mW amplifier removed, for power management, enhanced support):
as352x-linux-2.6.19.patch1
as352x-linux-2.6.19.patch2
as352x-linux-2.6.19.patch3
as352x-linux-2.6.19.patch4
as352x-linux-2.6.19.patch4.2
as352x-linux-2.6.19.patch5
u-boot.patch1
u-boot.patch2
u-boot.patch3
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2) and clip
Post by: ilikerockbox on February 29, 2008, 10:27:48 PM
I think that the sansa clip has the same 8-pin header, Top-Right:
(http://www.anythingbutipod.com/archives/images/sansa-clip-disassembled/sandisk-sansa-clip-disassembled-12.jpg )

It is located under the usb connector, Top-Left:
(http://www.anythingbutipod.com/archives/images/sansa-clip-disassembled/sandisk-sansa-clip-disassembled-13.jpg)

Using the photo, 6 of the 8-pin header can be traced back to the AS3525. If I(or someone else) had a data sheet I could probably figure out the function of these connections. It is likely that these connections are the same as in the e200 series.

These photo's were found on:
http://www.anythingbutipod.com/archives/2007/11/sandisk-sansa-clip-disassembled.php
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2) and clip
Post by: skaos on March 28, 2008, 01:54:43 PM
Anythingbutipod has just disassembled the Sansa Fuze. It uses the same SoC as most of the other V2 models (20-99-00112-2) and it looks like it comes with RAM (ESMT M12L64164A-7T).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2) and clip
Post by: Bagder on March 28, 2008, 03:14:34 PM
Yeps, I did extract the chip pic and compared it with the e280v2 one:

http://daniel.haxx.se/blog/2008/03/28/sansa-fuze-ams-reuse/
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2) and clip
Post by: hth on April 02, 2008, 03:13:00 PM
Unfortunately my father is in hospital for over a month now. :( So the time i can spend on the port reduced to about half an hour per month. Before the port stalls, i post some iterim results here which need verification:

8-pin JTAG connector pinout for e200v2:
Code: [Select]

1: VDD    +
2: TCK    JTAG Clock
3: TDI    JTAG data in
4: TMS    JTAG test mode select
5: nTRST  JTAG test reset, active low
6: TDO    JTAG test data out
7: nSRST  System reset, active low
8: GND    -


I used to solder 0,6mm thick wires onto the connector and put them under the lcd, leaving them out on the strap eyelet side. However, the wires didn't last long (isos broke and at least one wire got almost cut by the case). So i have to wait for an oppurtunity to fix that and verify the pinout  (my soldering station is out for repair).
Think the best would be to wire a female 1.27mm pitch 10-pin connector under the lcd left around under the mcu and put some iso-tape around the connector pins (for avoiding resets) and onto the black glueing side beneath the hold switcgh. That way jtag connections can be made on demand with an
adapter 10-pin male to a 20-way idc keyed box header (2.54mm male), and you can carry your player around without any wires coming out of it like i did.

There's a big chance that other devices (Fuze, Clip, etc.) use the same pinout for the JTAG connector; i would count from top side down or from left to right, but you can also measure potential of the outermost pins to be sure and let VDD be pin 1 (or use a led with a resistor for
determining polarity).

Btw., i started porting from scratch using the GPLed AS352X sources from u-boot and linux, because much more is implemented than the CGU only.
Unfortunately, the datasheets were within my old rockbox directory i removed, so i'll have to reobtain them to get some info later on. For now, there's enough to modify to get rockbox compiling, a patch against r16933 follows.

Edit: The patch partly contains unchanged u-boot/linux sources to be ported to rockbox.

Would be great if somebody could


I'll concentrate on the sources, though it'll progress sluggish.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2) and clip
Post by: hth on April 02, 2008, 04:49:47 PM
OK, posted as task 8843,

Link: http://www.rockbox.org/tracker/task/8843
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2) and clip
Post by: Bagder on April 02, 2008, 04:57:39 PM
Cool, if nobody else does it I hope to soon be able to go over it and commit at least parts of it to SVN to enable more people to join in this effort easier.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2) and clip
Post by: Xav on April 06, 2008, 11:00:20 AM
Here are e200v2 V03.01.16 firmwares:

http://mp3support.sandisk.com/firmware/e200/e200v203.01.16a.zip (America)
http://mp3support.sandisk.com/firmware/e200/e200v203.01.16e.zip (Europe)
http://mp3support.sandisk.com/firmware/e200/e200v203.01.16f.zip (Europe with FM Radio)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: atomikpunk on April 30, 2008, 12:03:09 AM
I recently got into looking at rockbox for my M250 and I noticed that I got the V2 and no rockbox port is still available. I have some skills in electronics, programming and disassembly analysis, and since I'd really like to try rockbox on my M250, I thought I'd help where possible in the project.

So I got the firmware in some tools I got and started looking at the firmware file. For the records, I've got the american V2 version with the 4.1.08A firmware in it. I also took note of the info which badger is keeping on his web page.

First of all, I'd like to thank badger and andva for their work since it is what got me started with the firmware analysis.

It's a bit late here but I think it's worth that I share at least part of my findings up to now. So here we go:

Naming convention & Header block(s)
First of all, I also found that the firmware file for the M250 is divided in what seems to be library blocks. However, I think that what andva consider the header block is in fact composed of 2 header chunks. The first one (that I'll name FWHeader) being only 0x400 bytes long, while the remaining bytes before block 0 are what I call BlockA. So for the blocks naming, I'd mostly stay with the convention andva defined, with the following exception: I'll refer to the 0x400 bytes block as the FWHeader block, and the remaining of bytes before Block0 being referred to as BlockA.

However, I think that the "regular blocks" are only up to the empty block. After that, the block structure doesn't seem to be used anymore. In the case of the M250 firmware, there are:
1 x FWHeader block
1 x BlockA
17 x regular blocks
1 x empty block
then, there are some other unanalyzed data.

FWHeader format
This block is 0x400 bytes long and only contain 2 data structures in it, the first one present at 0x00000000 being (almost) mirrored at 0x00000200. The structure has already been described by badger on his web site, though I think I found a bit more info about it (denoted by italic rows), so here it goes (numbers between parenthesis are for the mirrored structure at 0x200):
OffsetValue(s)Description
0x000 (1)This seems to be the index of the header structure
0x04ChecksumSeems to be a checksum
0x08Block multiplierThis seems to be used in the calculation of the regular blocks size: [block multiplier] * 0x200 = [regular block size]
0x0CBlockA sizeBlockA actual size, counted from offset 0x400 in the file (that's why I think there should be both FWHeader and BlockA blocks)
0x103A file format version number maybe?
0x148-bit checksum?A 8-bit checksum? Would be redundant IMO
0x15Model IdModel identifier
0x160Zero(?)
0x1840Fourthy(?)
0x1C1One(?)

BlockA
I didn't go deep as of now, but the first thing is that offset 0x0 of this block is an indirect branch instruction to some code at 0x4B8. I didn't have time to analyze it yet but it seems to be valid arm code.

Numeral block headers
For each regular block, a block header is also present right at offset 0x0 in each block. The block header structure can be incomplete, but the following is always present:
OffsetValue(s)Description
0x00String offsetBlock offset to the string describing the block's content
0x04Lower addressSeems to be the lower bound of an address range, still unknown
0x08Upper addressSeems to be the upper bound of an address range, still unknown
0x0CBlock sizeActual size of the block "effective" data, that is where there is valid code or data


So that's pretty much it for tonight, I'll try to continue looking at the firmware when I'll have some spare time. Meanwhile, please have a look at my finding and confirm (or infirm) that it is correct. Of course Badger you can add this info to your web site as you like :)

Good night peeps.

Edit: Clarified the "block multiplier" description in the FWHeader structure
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: saratoga on April 30, 2008, 09:10:17 PM
I applied Bagder's checksum code to blocks other then the first one, but unfortunately this did not give me the checksum in the header. 

The first header is different then the rest though.  Its length is the offset of the next block relative to the end of the present header, while the others are the relative address from the start of the header.  But even making that change didn't get me the right checksum, unless i'm doing something wrong.  I also tested the theory that the subsequent headers might be smaller or larger, but starting from the end of the block and going backward printing all possible checksums didn't yield the right sum either.

Looks like more work is required.

---

Also interesting, the datasheet mentions a USB repair mode in the SOC's internal ROM that works even if the FLASH is corrupted.  Unfortunately, as I suspected you need to trigger it electrically.  According to the sheet, GPIOA bit 4 is flipped on and then GPIOA bit 0 is read to see if the "firmware update button" has been pressed to connect them during power-on.  Unfortunately, looking at the pictures, its not clear whats hooked up to that those pins in either the E, Fuze, or Clip, as the connecting traces seems to be inside the PCB.  At first I thought the JTAG connector might also go to those pins, but it looks like this is not the case on the Clip at least. 
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: atomikpunk on April 30, 2008, 09:57:19 PM
Here is a little update for tonight.

It seems that BlockA actually contains the usual ARM 9 vector table right off at the beginning of BlockA (0x400 offset from beginning of firmware file). In the M200 firmware, only the reset, irq and fiq seems to be handled though. All the (four) others are simply infinite loops, so if they ever happen, the device is frozen.

I'll be looking at the reset vector in the next couple of days. There seem to be some hard coded addresses in there so some input about the device memory map from those with the AS3525 datasheet would be really appreciated.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: saratoga on May 02, 2008, 08:58:43 PM
Bagder:

Theres another M200V2 (or rather V4) firmware here:

http://ca1.storage.flashcp.com/sansa2/Firmware/M200/4/A/PACKAGE/SansaM200_plusA4_0_45.txt

(rename to .7z)

Firmware format looks superficially similar to the other V2 players, but I didn't look at it in much detail.

Edit:  Apparently the V2 M200 series have been out for quite a while.  That firmware update was posted on ABI in January 2007. 

Edit2:  Has anyone tried the "special MSC mode" trick on the E200v2?  The one where you plug in USB with the device off like described on Bagder's V2 page?  Seems very odd to me that it wouldn't work on the other players.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: atomikpunk on May 02, 2008, 09:33:07 PM
Well I got my M250 on april 2007 so yes it's been quite a while now... _If_ there is a recovery mode or "special" msc mode, would you think it would appear in the firmware or it would be hardcoded in the hardware?

Owh and BTW, from what I saw in the m200 firmware, there doesn't seem to be checksums for "regular" blocks. I've only seen a checksum for Block A, the one at 0x400.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: Bagder on May 03, 2008, 05:24:54 AM
I added that m200 firmware to the v2 page and I've tried to incorporate the more recent file format data/info we've learned.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: advcomp2019 on May 04, 2008, 12:52:48 AM
Edit2:  Has anyone tried the "special MSC mode" trick on the E200v2?  The one where you plug in USB with the device off like described on Bagder's V2 page?  Seems very odd to me that it wouldn't work on the other players.

About a month or two ago, I looked at this file( http://daniel.haxx.se/sansa/v2/c200/sansa-c200v2.zip ) which is on Bagder's v2 page.  If you look at those folders and if you have a v2, the special mode is just an hidden MSC mode that was in the older firmware.  Since they added USB modes to the menu, this trick looks like it does not work any more.  I tried it with my Clip.  With the Clip, it was the "Select" button and not |<<.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: atomikpunk on May 05, 2008, 11:29:25 PM
I continued analyzing the M200 4.1.08 firmware and understanding more stuff in it, though I'm far from complety understanding the whole firmware. Nonetheless, here we go for an update on my findings. ;D

For consistency, I will document every addresses in here relative to the file beginning except where otherwise noted.

Firmware file overview
The firmware file is divided in a bunch of blocks as we already know. In the M200 firmware, there seem to be 32 blocks:

Block IndexAddress in the fileDescription
00x000000Firmware header
10x000400Firmware
2 to 180x400 + (Index * Block Multiplier)Library blocks
190x21AC00Empty library block (filled with 0xFF)
20 to 26Unregular, read belowResource blocks
270x4D5400Empty resource block (filled with DEADBEEF)
280x4D5600Unknown data block
290x4D5800Unknown data block 2 (only contains 0xDF0 at 0x4D5800)
300x4D5A00Unicode certificate data
310x4D6800Empty ending block (filled with DEADBEEF)

Firmware Header Block (0)
Nothing newer than what is already known.

Boot Code Block (1)
I can confirm that this block actually contains a bootable code. So this code is loaded at address 0x0000000 in whatever ROM/FLASH/stuff that the AS3525 can boot. This code initialize some stuff like the AS3525 clock generation unit, etc. There is MUCH more to analyze in this block since this is where we'll find the most info about the V2 design (peripherals addresses, how to initialize the devices, etc.).

The following exception vector table (that contains jump instructions, which is standard for ARM vector tables) is present at 0x400:

AddressFunctionHandler summary
0x400ResetMain code at 0x4B8
0x404Undefined instructionInfinite loop
0x408Software InterruptInfinite loop
0x40CPrefetch AbortInfinite loop
0x410Data AbortInfinite loop
0x414ReservedNOP
0x418Interrupt RequestInterrupt handler at 0x8468
0x41CFast Interrupt RequestInterrupt handler at 0x8468

Library Blocks (2-18)
The 17 library blocks are tagged with the following "library names":

Block IndexLibrary Name
2usb_functio
3mp3_decoder
4otg_functio
5wav_codec
6acp_decoder
7aud_decoder
8drm10_nonpk
9drm10_pkcpt
10drm10__Init
11wma_decoder
12wma_decInit
13wma_decPlay
14drm10_InitT
15drm10_host_
16wmaPDDRMini
17wmaPDDRMper
18sd_reload__

The following (improved) table describes the library blocks header (offsets are relative to each block base address):
OffsetValue(s)Description
0x00Library nameOffset to the library name
0x04Library base addressBase address of the library
0x08Library end addressSeems to be the library end address, but seems to include extra space(?)
0x0CBlock effective sizeSize of effective data in this block
0x10Unknown valueStill unknown. Needed space for variables?
0x14Exports countNumber of publicly exported functions
0x18ExportsAn array of [export count] addresses which points to library functions

Resource Blocks (20-26)
These blocks are still mostly misunderstood, but they seems to contain various resources (localized strings, etc.). Resource blocks size is understood to be the next 0x200 bytes boundary after the block effective size. For example, a resource block with an effective size of 0x1234 would end 0x1400 bytes after the block beginning.

The resource blocks have the following header:

OffsetValue(s)Description
0x00Block effective sizeSize of effective data in this block
0x04Resource IDThe more plausible signification is a resource ID number
0x08"HEADER"The "HEADER" ascii string


So that's about it for tonight, I hope it helps understanding the firmware file format. I'll try to continue understanding the file format... Or if more experienced developpers thinks I could help somewhere else, feel free to suggest!

Edit: Changed the "Boot block of the firmware" to "Firmware" as block 1 seems to be the whole firmware (without libraries)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: Bagder on May 06, 2008, 07:09:38 AM
I'm curious why you think that block 1 is "boot code". Why isn't it simply the entire firmware, apart from the lib stuff that is provided in the other blocks?

Also, given this description I figure a custom firmware could easily just be block 0 and block 1.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: atomikpunk on May 06, 2008, 08:35:14 AM
Lambda: Yes I did however I did not have time to ask for write permission yet. You are right, this kind of info is best stored on the wiki, though I think that maybe we should dedicate a separate page for the V2 firmware stuff if we don't want to monopolize the M200 page for the firmware ;D

Bagder: You are right, what I really meant to write was that block 1 is the block that is effectively run by the hardware on boot. Though I didn't analyze everything in there, it is reasonable to think that is much more than just a bootloader in this block. I also think that this block could hold the rockbox bootloader and this should do the trick. Probably that we will need to follow the firmware file format nonetheless, for example, on a first pass, only substitute block 0 and 1, then on a second pass completely the firmware file only to include required blocks.

Can someone reading the forums and with wiki admin access give me write access to the wiki? Else, I'll try to poke someone on IRC tonight...
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: Bagder on May 06, 2008, 09:36:45 AM
Seeing that we don't have a recovery mode, we need to be very very careful when trying to insert code and run it on the v2 models, so yes we should make the Rockbox bootloader get inserted in the block 1 part, and based on some magic (like if we press a key, assuming we can easily read that without too much code) the code should proceed as normal and not run the Rockbox code. Thus we minimize the risk of bricking the device due to putting a bad image onto it.

This all of course requires that we now know how to generate a complete firmware upgrade file, so that we can insert a chunk of code in block 1 and generate a new file to upgrade to. Given the last updates of the firmware format, there's only that checksum in the header for block 1?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: atomikpunk on May 06, 2008, 11:51:31 AM
If you don't mind, I'll create a specific wiki page about the V2 firmware format here and link every v2 port pages to it. It will alleviate port pages from firmware details and still provide info to those interested... And since many Sansa devices use the same firmware format, I guess that a central page about it wouldn't hurt... What do you think?

Also based on Bagder idea, I guess that looking into the current firmware for button sensing would really help so I'll aim my analysis around that...

Calculus: thanks for the wiki access, I'll have a look at it tonight. :)

Bagder:  I guess that should do it... There are still a couple of unknown fields in the firmware header, but they seem to always be the same so I guess we could use those without much damage...

I'm pretty new to the "firmware replacement scene" so I take any advices :) But since I really don't want to brick my device, I'd prefer if some other brave souls would try it before I do ;D
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: Bagder on May 06, 2008, 03:26:50 PM
I'm pretty new to the "firmware replacement scene" so I take any advices :) But since I really don't want to brick my device, I'd prefer if some other brave souls would try it before I do ;D

I'll be bold and say that as long as we do this slowly and carefully and the code we try to run is reviewed and agreed to by a few Rockbox persons who should know this stuff, we will of course fund a replacement player for the brave soul who tries this the first time - if it breaks.

Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: saratoga on May 06, 2008, 06:53:50 PM
Figuring out how to do JTAG might be a better approach. We've got the docs and the pinout, so we could unbrick if things go bad.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: atomikpunk on May 06, 2008, 09:17:00 PM
Tonight I created a wiki page for the Sansa v2 firmware (http://www.rockbox.org/twiki/bin/view/Main/SansaV2Firmware). I also linked to it from the v2 port pages (and BTW created the m200v2 port page).

Please have a look there, and feel free to comment...
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: linuxstb on May 07, 2008, 08:01:53 AM
I've just ordered myself a 1GB Clip (as a cheap example of a v2), and (unless someone else gets there first), will probably attempt running my own code on it.

My plan of attack is along the following lines:

1) Understand the firmware format, and determine where the different parts of the firmware file are loaded into RAM.

2) (Unless such space is already available), attempt to "expand" the firmware file to create some space to insert my own code in.

3) Modify the branch instruction at the reset vector (0x0) to branch to the start of this new space, which initially will just contain a branch instruction to the original entry point of the firmware.  This is a risky step if we haven't got the load address figured out correctly, but relative branches can probably be used to minimise/remove the risk.

4) Add a delay loop into my code, so that there is a visible delay when booting (this will be my initial feedback method to see if my code is working - i.e. "true" will be to insert this delay before branching back to the OF, "false" will be to return to the OF immediately).

5) Using that delay loop as an indicator, investigate the GPIO pins, and see which (if any) buttons are linked to GPIO.   i.e. for each pin in turn, perform the delay based on its status, and try booting with and without each button pressed.  This may take a while, although disassembly of the OF might help.

6) (Hopefully) once a suitable gpio-detectable button is detected, then use this to implement dual-boot, with the default action being to branch back to the OF's entry point, and the "on key press" action being to continue to execute our own test code.

Anyone have any better ideas?  I agree JTAG would be nice, but I don't own JTAG hardware and have no skill with a soldering iron...
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: atomikpunk on May 07, 2008, 11:22:48 AM
Great linuxstb, please have a look at this topic and the wiki, we already did some work on the v2 firmware file format and are pretty close to be able to create an experimental version to play with. There is still a field that we don't understand that could prevent creation of custom firmware files, details are on the wiki.

I really like your "non-destructive invasive" approach. I already did some OF analysis though I'm far from finished. In fact, I was to the point of GPIO analysis in the disassembly, so I'll share what I find as soon as possible. But maybe I could help in the development of your dual-boot experimental firmware. Most of my analysis details are on the wiki at http://www.rockbox.org/twiki/bin/view/Main/SansaV2Firmware, but I left some incomplete/misunderstood analysis details locally on my machine (specifically on the disassembly analysis).

j8048188: Could you detail on your RAM concern about the clip? Could it also matter for other models?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: linuxstb on May 10, 2008, 03:56:04 AM
I've started analysising the Clips's firmware (based on the work done by atomikpunk), and it seems to be loading code to the 320KB internal SDRAM at address 0x0, plus more code to address 0x30000000 - which is documented as being the external SDRAM.

So the fact that the disassembky pictures here:

http://www.anythingbutipod.com/archives/2007/11/sandisk-sansa-clip-disassembled.php

are only showing two chips (presumably the AMS SoC and the 1/2/4GB NAND flash) is confusing me.

Here is what my test utility is showing for a Clip firmware (the libraries are sorted by load address, not the offset in the firmware file):


0x00000000:
  HEADER: 0x00000000
    FirmwareHeaderIndex:     0x00000000
    FirmwareChecksum:        0xbc2aff7c
    CodeBlockSizeMultiplier: 0x000000ea
    FirmwareSize:            0x0001d228
    Unknown1:                0x00000003
    ModelID:                 0x22a1
    Unknown2:                0x0000
Calculated firmware checksum: 0xbc2aff7c
LIBRARY BLOCKS:
Offset      Name           BaseAddr    EndAddr     BlockSize   Unknown1    EntryCount
0x00239800: "sd_reload__"  0x00024ce0  0x00025a24  0x00000d44  0x00000018  0x0000000c
0x0024d800: "dh_decoder_"  0x00029330  0x81031a00  0x0000896c  0x00000414  0x00000001
0x00135800: "aud_decoder"  0x00029330  0x0002dce4  0x000049b4  0x0000a5a4  0x00000001
0x000e5800: "wav_codec  "  0x00029330  0x00036ae0  0x00006674  0x00006508  0x00000001
0x001d5800: "winmed_boot"  0x00029330  0x0002997c  0x0000064c  0x00000008  0x00000001
0x001e9800: "wma_decoder"  0x00029990  0x0002a408  0x00000a78  0x0000525c  0x00000003
0x00225800: "wmaPDDRMper"  0x0002f670  0x000314b0  0x00001e40  0x00000004  0x00000001
0x00171800: "drmpd_persi"  0x0002f670  0x0003076c  0x000010fc  0x00000000  0x00000001
0x001c1800: "drmpd_unloc"  0x00030770  0x0003811c  0x000079ac  0x0000aec4  0x00000001
0x001fd800: "wma_decInit"  0x00030770  0x00034514  0x00003da4  0x00000604  0x00000001
0x00211800: "wmaPDDRMini"  0x000314c0  0x000343ac  0x00002eec  0x00001000  0x00000001
0x00095800: "wma_decPlay"  0x000314c0  0x00043ff0  0x00012b30  0x00007440  0x00000001
0x0010d800: "acp_decoder"  0x00039000  0x0003ed70  0x00005d70  0x00000030  0x00000003
0x000bd800: "mp3_decoder"  0x0003dff0  0x00045b4c  0x00007b5c  0x000040b8  0x00000003
0x0015d800: "drmpd_nonpk"  0x00042fe0  0x0004afe4  0x00008004  0x00000000  0x00000001
0x00185800: "drmpd_pki__"  0x00042fe0  0x0004a43c  0x0000745c  0x00000be0  0x00000001
0x00199800: "drmpd_unlro"  0x0004b880  0x0004e978  0x000030f8  0x00000000  0x00000001
0x00045800: "otg_functio"  0x30020f80  0x300d35b0  0x0001fb5c  0x000099f4  0x00000001
0x0006d800: "usb_functio"  0x300026a0  0x300dd000  0x0001e8c8  0x00021614  0x00000001
0x001ad800: "drmpd_mtp__"  0x30040b50  0x3004c3ec  0x0000b89c  0x00016800  0x00000001
0x0001d800: "drmndt_pers"  0x30062bf0  0x30074e24  0x00012234  0x0000b1f0  0x00000001
0x00261800: PADDING BLOCK
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: linuxstb on May 11, 2008, 08:28:16 AM
I've been experimenting with trying to install a modified firmware on my Clip, can confirm that the 4 bytes at the very end of the firmware file is a "whole-file" checksum - i.e. a simple sum of each 32-bit word in the file, not including those last 4 bytes.

Without updating this checksum, the only successful firmware update I could do on my Clip was simply swapping two 32-bit words within the main firmware block.

For the record (this wasn't immediately obvious to me), a failed firmware update will just display the message "Firmware upgrade in progress" and then power off the device.  A successful update will display the second message "Upgrade completed" before powering off.


I've managed to get the Clip to accept a modified firmware file with a small number of "spare" bytes added at the end of the main firmware image (replacing some of the 0xff padding with 0xdc,  increasing the FirmwareSize field in both of the headers, and recalculating the checksums).

What I haven't managed to do yet (and what will be needed for us to run code) is how to extend the firmware image so that it occupies more 0x200-byte blocks than it does originally.


EDIT: I've just run some of my own code on the clip for the first time - "step 3" in my post a few messages earlier in this thread.  Now for step 4, which will confirm if step 3 really worked...
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: linuxstb on May 11, 2008, 01:35:48 PM
I can confirm that I'm now successfully running my own code on the Clip  ;)

This is "step 4" of my plan - I've added a 5 second (approx) delay into the start of firmware, before the code branches back to the original entry point of the original firmware.  The firmware then continues to run as normal.

So others can start experimenting, I've committed my test programs to the Rockbox SVN - in the utils/AMS/hacking/ directory.  Just edit the "test.S" ARM code to do what you want, and type "make" to generate a patched firmware file (edit the Makefile to point to the unmodified original firmware file).

It requires the standard Rockbox arm-elf-gcc toolchain.

The immediate problem is that I can currently only successfully insert a very small amount of code - up to the next multiple of 0x200.

If anyone makes improvements to these programs, please post patches to Flyspray in the usual way, and I (or someone else with commit rights) will commit.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: atomikpunk on May 11, 2008, 11:04:37 PM
Hi,

very interesting linuxstb. I'll try a patched version with your delay on my M250 to see if it also works on it.

So I guess the next step is seeing if we can insert extra blocks in the firmware file, or at least exactly understand how the updater stores the firmware in the device? Else we'll be stuck with < 0x200 space to play with.

About your step 6, I wonder if the v2 series is handling buttons the same way the M200 v1 did. It seems from SVN that buttons were read from the ADC (?).

Just for the records, in the M200, I think I found some LCD update routine somewhere. It seems that the LCD is connected through DBOP. It probably is an SSD1815 as in the M200 v1. I found some sort of initialization routine and every commands written to DBOP are valid initialization commands for the SSD1815.

I'm still looking at the firmware. Feel free to ask for specific (firmware disassembly) items and I'll see if I can find something about it.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: linuxstb on May 12, 2008, 01:46:08 AM
Yes, it's very possible that the buttons are all on ADC, although it's quite common for at least some buttons to be on GPIO (especially the hold switch).

Assuming the M200v2 has the same 128x64 mono LCD as the v1, then I'm sure you're right about the SSD1815.  Which at least makes that step easier.  There are two commands specific to the AS3525 that you'll need to find in the original firmware - lcd_write_cmd() and lcd_write_data().  If you've found the LCD init routine in the original firmware, then you should be able to spot these.  Plus there is likely to be some LCD controller setup (setting clocks etc).

Writing an LCD driver is always a nice thing to do early in a port - it makes debugging so much easier...

But that will require solving the problem of loading more code than I currently can...
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: atomikpunk on May 12, 2008, 08:03:36 AM
Ok, I'll try to look at buttons handling later today. I was looking for GPIOs but didn't see that in v1 it was on ADC.

For the LCD, I'm pretty sure I already found both of the write_command and write_data routines. I'll give it a deeper look later today. I also think that the v1 team already put up a basic lcd driver, so it probably only need some minor changes.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: linuxstb on May 12, 2008, 08:19:23 AM
It would be useful to work out the GPIOs anyway - it will be much easier if we can find at least one button detectable that way.

It would also be nice to work out what GPIOs are used for output - hopefully the button light or other LEDs (I don't know what's on the m200v2) are controlled via GPIO.  This would be another nice way to get feedback from our test code.

P.S. The "v1 team" is just me...
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: atomikpunk on May 12, 2008, 11:15:34 PM
Well I looked at the OF tonight, analyzed a bit more on the lcd drawing routines... I can confirm that I found the lcd_write_command and lcd_write_data routines, and also found where they draw at particular pixels in (x,y). Nothing more to report as of now, but a little more understanding ;)

But for the firmware "expansion" I'm still puzzled how we could do it. I'd say that just changing the size multiplier in the header would do, _for the firmware_. But it would break the OF because of absolute addresses in the libraries...

BTW, after review, it seems that the size multiplier in the header is only valid for the firmware section, that just happens to be the same size as "library blocks" on the FW I'm currently looking at... I still don't know how to deduce the library blocks size...

So I guess I'll take advice of my pillow for now ;D


Edit: I thought about it in my shower this morning, I guess that simply expanding the firmware section in the OF could in fact do the trick, because the hardcoded addresses are for the use of library blocks, but we won't use them anyway while running rockbox, so who care about bad addresses in blocks that won't get executed!

I'm also wondering, maybe that the library blocks are in fact "files" created on a "system partition" that hold particular algorithms, like codecs, etc. I wonder if we could put some extra rockbox object files and load them the same way the OF do with library blocks. So I guess another thing to look at in the disassembly is how they dynamically load (if that's the way they do it) library blocks, where they take it from, where they load it to, etc. In brief, how the "dynamic" library handling is done.

So to resume, my research on the OF disassembly is concentrated on:
- firmware file format
- how to expand the firmware
- GPIOs
- buttons
- "dynamic" libraries
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: atomikpunk on May 15, 2008, 11:24:37 AM
Hi Daniel,

yes that would be very helpful if you could trace the buttons signals up to the processor. I work in electronics too so let me know if I can help you with that. If you don't mind checking for LEDs or stuff like that too, that'd be great.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: beambot on May 15, 2008, 12:18:12 PM
Hello Forum,

@atomikpunk , linuxstb

nice work till know. You worked out a lot of information about our new 'toy'

@linuxstb

Is it possible to give us more information about the memory mapping of the AS3525 out of the manual e.g adress range of GPIO , ROM,  RAM , extRAM, Flash etc. Perhaps this information makes it easier to take a look to the OF.(I don't know what's your aggreement with austriamicrosystems about sharing this information)

thanks
Michael
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: atomikpunk on May 15, 2008, 01:37:06 PM
Hi Michael,

thanks for the cheers ;D

About the memory mapping, Bagder will be the one who can answer this question since he's the one who worked out an arrangement with Austriamicrosystems. He will be able to release selected information based on his agreement.

If you are interested in helping understanding the OF, let me know and I will be able to share what I already found about it. And maybe we will be able to divide work and cooperate (via IRC/Wiki/Forums?).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: daniel_at on May 15, 2008, 02:08:11 PM
Hi again,

Okay  so far I have just opened it and made some pictures of it. You can find it at flicker here:
http://flickr.com/photos/90053035@N00/sets/72157605072639496/

I have added notes to some of the pictures, but they dont show up in opera... but the bottom-note says there are comments in it.

For the switches: I just made some measurements - no deep insights so far. All switches seem to be connected to a resistor-network (with 2 R's for each switch), except the Pwr-switch. All switches (again except the Pwr) are connected to Digital (or Power-)GND on one side. The other side is connected to a pulled-up line to about 3V, which switches off (or goes high-Z) every 0.5ms for a very short period of time. But the intervall between the shutoffs is not _very_ periodical and depends on task running on the E200 (so it seems to be handled in an low-priority scheduled thread).

The pulled-Up line goes to about 0.3V if the display-background light is off (i.e. powersaving mode) EXCEPT for the "UP" (or play) Switch (not the wheel-up). Maybe this is somehow a "special" key which can be checked by GPIO.
But my guess is, that all keys trigger a GPIO and than the level is checked by the ADC (maybe therefore the "high-Z" spikes).

I cant even say, if there is only one common signal line for the switches which goes to the SoC (but it pretty seems so)

HTH a bit,
Daniel

But these assumptions are very rough guesses - i havent spent much time so far on it.
I also tried (just by random poke'in) to find one of the vias near the SoC which carrys the common signal for the swtches... but havent found one...
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: Bagder on May 15, 2008, 03:40:54 PM
For lots of info on the AS3525 like (default) memory addresses for various things, check the attached patch to tracker entry FS#8843:

http://www.rockbox.org/tracker/task/8843

It is supposedly based on the AS3525 Linux patch and does include lots of details otherwise only mentioned in the data sheet.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: atomikpunk on May 15, 2008, 10:54:44 PM
Just for the records before I go to bed, I did some investigation and found some info about which memory ranges are in use. All my findings applies to the M200 series, but it should be pretty easy to translate it to other models. The range 0x49C60 to 0x4A060 seems to be used for stack, while the TTB is located at 0x44000 (up to 0x4BFFF). I found out where the TTB and TLBs are setup and I hope to better understand the memory usage, and eventually find out how libraries are loaded in memory and how they are used in the firmware.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: daniel_at on May 16, 2008, 04:57:17 AM
@Bagder: You have some datasheets for the AS3525 - or?
Do these give some information about the/a JTAG interface to the SoC/or the integrated uC?

I wanted to try to find out if the on-board 8-pin connector is a JTAG-interface and if so, also get the  pin-assignment of it. So far i know:

1 - GND
2 - low-active reset (pull to GND to reset)
3 - high-Z, pulled up
4 - high-Z, pulled up
5 - high-Z, pulled up
6 - high-Z, pulled up
7 - high-Z, pulled up
8 - V+ (3.3V)
(Pin1 is a rectangular pad...others are oval)

This means that there is one line to much for JTAG, maybe one of them has to be pulled low to enable JTAG. Does the datasheet say something about it? And has the uC in Reset-mode? (I dont think so - or?)

I have added some pics: http://flickr.com/photos/90053035@N00/2496093231/in/set-72157605072639496/

If we get JTAG working and get r/w access to the flash, than testing would be a lot easier, bec. we could always unbrick it.

Daniel
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: Bagder on May 16, 2008, 03:43:36 PM
The data sheet really doesn't mention a lot about it other than like this (http://daniel.haxx.se/rockbox/as3525-jtag.png)...
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: atomikpunk on May 16, 2008, 03:50:17 PM
Hi Daniel,

please have a look a couple of post earlier, hth already did some investigation on JTAG. Maybe it will help you. From what I understand, the JTAG interface is in fact the ARM922T core JTAG interface. So, you can have a look at the (publicly available) ARM922T datasheet which is the arm core included in the AS3525.

I don't know much about JTAG but if you can connect to it and are able to read/write the rom/flash, as you said, it will be a lot easier and safer to work.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: daniel_at on May 17, 2008, 10:34:28 AM
Hello,

please have a look a couple of post earlier, hth already did some investigation on JTAG.

Hm - have searched for JTAG prior, cant find a user hth here... i guess you mean my initial post - which ends with HTH, what means Hope That Helps :)

But anyway, thx to Bagder for looking that up in the datasheet. I have found in the ARM922 datasheet, that the nTRST should be pulled low while accessing the chip with JTAG - but i am not completely sure... maybe ill try to extend my JTAG-Programmer so that it trys all possible combinations of pinout-alignments and reset-state...

Daniel
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: saratoga on May 17, 2008, 02:24:04 PM
Hello,

please have a look a couple of post earlier, hth already did some investigation on JTAG.

Hm - have searched for JTAG prior, cant find a user hth here... i guess you mean my initial post - which ends with HTH, what means Hope That Helps :)

http://forums.rockbox.org/index.php?topic=14064.msg121222#msg121222
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: daniel_at on May 18, 2008, 07:30:17 AM
@saratoga: oh..sorry, somehow i managed to search through the wrong post. Sad that there is no option to show a complete thread on one page - or is there one?... Oh, just found - "print preview".  Nevermind :)

I have tried to connect the Sansa with the pinout from hth to my JTAG interface... couldn  not initiate the connection. I have tried different states of the System- and the Test-Reset lines.

Will try some other configurations later.

Daniel
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: atomikpunk on May 20, 2008, 11:39:07 PM
Hi peeps,

just a little update to show what I'm looking at.

I can now confirm that the "libraries" are effectively dynamically loaded as I suspected. And the code clearly shows the values we also find in the libraries header (load address, variables address, library size, variables size, etc.). This also explains why multiple libraries loading addresses overlap. I can easily be understood because most of the overlapping libraries provides the functionality which can't overlap. For example, the wav codec library is loaded at the same address as the acp decoder library.

I also think that I found the routine where the libraries are loaded but I still can't understand it. This is my next step because it may help understanding the library loading process and eventually evaluate if it is possible to expand the firmware file and how to do it.

From what I understand, if we would like to "bypass" the OF, we could simply use the whole firmware file as we wanted, not bothering with the libraries and all that stuff. I don't know how we could get back to the OF however as we don't know where is the firmware upgrade code... And since we wouldn't have the OF in backup neither... So maybe the next big question is: is it possible to grow an image file bigger than 0x500000 and still be accepted by the firmware loader?

That's about it for the last couple of days.

Any news from JTAG or other findings?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: Bagder on May 21, 2008, 03:17:01 AM
From what I understand, if we would like to "bypass" the OF, we could simply use the whole firmware file as we wanted, not bothering with the libraries and all that stuff. I don't know how we could get back to the OF however as we don't know where is the firmware upgrade code...

Right. We want (or need) dual-boot ability so we should only insert enough code in there to be able to load Rockbox from the NAND and start it. IMHO.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: atomikpunk on May 21, 2008, 09:19:09 PM
Hi,

could someone probe the xpc pins 0 to 3 while unpowered? On the 224 pins BGA package, those are E5, C4, F4 and A3 respectively. They should be tied up to GND or VCC. This could help understanding the booting mode. xpc0 tells about internal or external memory (GND is external, VCC is internal bootloader). xpc[3:1] is for internal bootloader mode.

Also, if xpc0 is tied pulled high (internal bootloader), it would be interesting to probe xpa0 (pin D5) and see if it is connected to a button. If that is the case, then maybe there is a "firmware update" mode accessible...
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: daniel_at on May 26, 2008, 04:34:01 AM
could someone probe the xpc pins 0 to 3 while unpowered?

Hm - that would only be possible on a defect device, or at least it would be defect afterwards... Its not possible to measure (reliable) any of the pins from the BGA. There are some vias which might conntact any of those pins, but you can only make rough guesses based on their position.

So if anyone has already bricked any of the devices stated in the Subject, he/she may connact me to and maybe it will be possible to make some experiments...

Daniel
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: atomikpunk on May 26, 2008, 11:36:26 AM
Hmmm I'm not sure why you say the device would be broken afterward. It's only unpowered probing, no? Like you find the ground, place a probe there, then probe the lines I listed and check if there is a pull-up or pull-down, then do it again with vcc?

Just for the record, I think I found a routine where there is GPIOA input reading on at least 4 pins of it. It is done in a quite strange manner however so I'm still trying to understand it. I'll keep you informed.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: daniel_at on May 26, 2008, 11:56:46 AM
Because a BGA hides all its pins beneath the package: http://flickr.com/photos/90053035@N00/2494642819/in/set-72157605072639496/

So you have to desolder the chip (which only works if you heat up the whole PCB so that the solder melts, which in turn destroys the device) and than make some measurements. But you can only check connection to GND/VCC or other "well known" nets.

The board from my e200 has a lot of vias under the chip - which may contact some of the pins - but you cant say sure which via goes to which pin - only make rough guesses based on the location of the via.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: saratoga on May 26, 2008, 01:58:44 PM
You can get to maybe a dozen or two of the bga pins out of 224, so testing isn't exactly easy, and a lot of them are boring pins (JTAG).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: linuxstb on May 27, 2008, 01:55:33 AM
atomikpunk.

Firstly, I think it would be useful if you could share some of your disassembly findings.  It would also seem to make sense for everyone working on disassembling V2 firmwares to use the same version.

Whilst I'm sure replacing (for example) the mp3 codec with our own code could work, it's far from ideal. 

Firstly, it will make development much slower (you'll need to start the original firmware, and play an mp3 file in order for our code to be run.

Secondly, we're running our own code within the environment of the OF - we don't know what other threads may be running at the time (or how the OF multi-tasks), so we would need to make sure we don't corrupt anything currently in use by the OF.

Thirdly, in some ways it's a disadvantage to be running within the initialised environment of the OF - it means we don't know that our code will run reliably when we move to replacing the OF firmware completely.

But having said that, it's also an advantage to be able to read the hardware registers after they've been initialised by the OF - so we can ensure Rockbox does things at least as well.

So in conclusion, trying to run code by replacing a library function would be useful, but I think we still need to find a way to extend my current method of inserting code to work with larger bootloaders.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: atomikpunk on May 27, 2008, 08:28:49 AM
Hi linuxstb,

I have no problem working on the same firmware version. ATM, I'm on the M200 v.4.1.8a but I wouldn't mind too much changing to another one. However, keep in mind that much of my work up to now would be "lost" in the sense that I would need to re-analyze most of the routines. If you guys don't mind looking at this firmware version (M200 v.4.1.8a), I'd be glad to share my findings. In fact, most of what I've found wasn't published exactly because I think it wouldn't be useful for others not looking at the same firmware version as I do.

Concerning the library replacement, I also think it is not the ideal solution. However, a big plus is that we could separate the job: one team beginning to work on missing drivers and the other team keep looking at the OF. And the biggest gain would be to have a lot more space to put custom code in because library blocks are much smaller than their "reserved" space (much smaller than for example 0x1E000 bytes size of a library block on the M200).

But you're right, we don't know if, and if so, how the kernel do multitasking and there is risk there. However, as far as we don't try to play a file of the particular format, I'm pretty sure there won't be any problem. And still, we could re-flash the device with the OF.

I too think that's a temporary solution helping us to develop while we also try to understand the firmware and figure out how we will be able to put rockbox in...


Edit: for those of you interested, I put up some more disassembly details on the SansaV2Firmware (http://www.rockbox.org/twiki/bin/view/Main/SansaV2Firmware) wiki page. For the moment it only contains an overview of both the reset and irq vectors, buts also some pointers in the code where I think the library blocks are loaded. Those with the appropriate tools may look there and see if they can provide more info about it. I already have some more details but bed is calling me for the moment, so I'll update when I'll have some time... Have fun until then :)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: beambot on May 31, 2008, 02:26:03 PM
Today I also tried to connect my clip to a jtag with the pinout given by hth and it didn't work (to solder the wires wasn't funny  ;D). Means the jtag pinout of the clip isn't the same as for the e200, the pinout is wrong or there is another' switch' to enable the jtag port. I tried some cable combination with my breadboard without success. I will take another look to it tomorrow...

Michael

 
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: saratoga on May 31, 2008, 03:10:57 PM
I quickly double checked the posted JTAG pinout against the pins in the datasheet using a scan of the clip's board (you can actually see the JTAG traces go from the CPU to the header) and they looked right to me.  Though you're welcome to double check me:

(First row is A, First column is 1)

C2 jtag_trst_n  JTAG reset not
A1 jtag_tms  JTAG mode select
B2 jtag_tck  JTAG clock
B1 jtag_tdi  JTAG data input
D3 jtag_tdo  JTAG data output
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: beambot on June 01, 2008, 01:12:44 PM
Sorry to ask again, but I would like to be sure !!!

Early in this thread some one  posted a picture of the clip's board :
If I take JTAG nSRST (Header Pin7) as a reference because this is the only one which works  ;) and take a look to the AS3525A Package Ball out I found it named M2. If I count backwards looking at the picture my proc pin candidates which are going to the jtag header are A1 A2 B1 B2 C3 (TMS,XPC7,TDI,TCK,TRST_N). So for my point of view not all neccessary JTAG pins are present at the 'header'. But it makes no sence to put only a few of the JTAG pins to the header, so I guess something is wrong with my counting. Give me a tip . Perhaps I'm not able to count  ;D

Michael
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: daniel_at on June 01, 2008, 02:09:38 PM
@beambot: try to look at the surrounding of the jtag-interface, if you find a unsolderd resistor or anything else, that can be bridged while facturing and then removed.

I found something like that within my E200v2 - but i have not tried to bridge it so far.
Picture: http://flickr.com/photos/90053035@N00/2494642819/in/set-72157605072639496/

bye, Daniel
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: atomikpunk on June 02, 2008, 08:50:37 PM
Hi,

I've just put up some more findings on the library loading routines on the wiki. Please have a look here (http://www.rockbox.org/twiki/bin/view/Main/SansaV2Firmware#Functions). As a summary, I am now pretty sure that library blocks are loaded in RAM directly by code in the firmware. I also noted that the library blocks size seems to be hardcoded in the firmware and would be 0x1E000 as expected.

If you feel like looking at the firmware, feel free to contact me via PMs and/or look at the wiki and try to expand knowledge in the area of the library loading routines. Or maybe have a look around the loading of the sd_reload, usb_function and otg_function libraries to try to find recovery procedures or stuff that trigs usb modes.

I hope we get to find a recovery procedure soon because there are a lot of things I'd like to test ;D
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: embrion on June 03, 2008, 03:22:31 AM
Quiet risky method of recovery in case somthing goes wrong with bootloader but luckly it's one-or-two-times-in-device-life operation so no big deal.
However, in early developing stage, jtag would be usefull for debricking while developing the bootloader. It's perfect interface but as far as I know, we need some dedicated software to control it ( unless it works with hyperterminal and got "load FW image from TFTP server" option ;) )
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: atomikpunk on June 07, 2008, 10:58:43 PM
I found something very interesting tonight about the OS run by the sansa. It seems like it uses Segger's EmbOS. I found at least one evidence of this in the signature of the tasks creation routine. They are particularly recognizable and they are perfect match with the homologous routines in EmbOS. However, I still don't know the compiler used as EmbOS supports multiple compiler environments...

I hope it'll make analysis much easier by having routines documentation at hand...

I'll try to update the wiki when I can so others will be able to keep up to date with findings (and possibly contribute). Until then, good night ;D
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: embrion on June 08, 2008, 02:00:03 AM
You rock :) I can't wait to switch my Nano to Sansa Fuze :D
Austrian hardware + German OS. Makes sense :)
My findings:
1. As AS3525 is ARM9 than according to  http://www.segger.com/emboscpus.html , You got 6 possibilities. At least KEIL got very nice simulator, so we could test a more or less simple code (check memory jumps and stuff  might be useful I think but I might be wrong because I did embedded only once in my life at school)
2. Those trials on Segger's site are only add ons for compilers but got included 2 very nice docs about ARM7/9 usage with embOS. I believe there shoul be trials of those compilers on manufacturers sites. At least Keil's uVision got trial version.
3. KEIL is very popular so I'd check it in the first place + 1 got some god feelings about it.
4. http://www.segger.com/jlink.html (a lot of text + some screenshots = might help with flash memo layout and/or jtag pins and/or anything else)
5.  I googled some guy's resume:
Quote
Worked on basic radio functionality for a prototype of the latest XM radio using ARM assembly, C, C++ running under Segger's embOS RTOS. The CPU is an Arm922t core as part of a System-On-Chip built by Austria Microsystems (AS3525)

Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: atomikpunk on June 08, 2008, 07:35:29 AM
Haha thanks for the great words.

Yes I downloaded trials of the embOS and the package includes a very nice doc, at least providing most (if not all) of the API with signatures, description, etc. Very valuable :)

What I would suggest for finding out the compiler used is to compare C runtime and C library output from the various compilers with the one present in the firmware. I already found out what seems to be the strncmp function in the firmware so if someone could provide with the assembly output of the various compilers, we could compare with the firmware and see which one it is...

Anyone willing to look at the firmware, feel free to contact me via private message so we can get in touch on jabber/msn/icq.


Edit: After looking a little more into it, it seems more and more possible that EmbOS version 3.32 (or earlier) was used. I'm coming to this conclusion from the structure members that moved between versions and the one that truly match the M200 4.1.8A firmware looks like EmbOS 3.32.


Edit 2: (Damn anti-double-post) After looking at the GPIO ports usage in the firmware, it seems to me that the buttons reading is done in a keypad-like manner using port A. A[3:0] seems to be used as inputs while A[7:4] seems to be used as outputs. The routine at 0x32B4 (in the M200 4.1.8A firmware) seems to be the scanning routine, checking all column/rows combination and thus giving out a 16-bit mask of the "keypad". This would also explain why Daniel said that there are switches connected to resistor "networks".

That being said, I guess that it would be interesting to: 1) be sure that this button reading method is used on all V2 sansas, and if not, what is the button reading method for other models, and 2) identify which buttons are connected to this "keypad" and which one is where. Once we are able to recognize buttons, it will be possible to create dual-boot images :)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: embrion on June 11, 2008, 12:58:40 AM
Good thinking :)
If there will be any problems with identifying which button is which, than You could always set official firmware to boot as default without key combination, Rockbox as alternative when button press and hold + use hit and miss method for finding correct key code by trying different codes in boot loader and pressing always the same physical key :) It's a lot safer approach as long as boot loader won't brake possibility to boot official firmware  :)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: atomikpunk on June 11, 2008, 07:12:29 AM
Well good and bad news this morning.

The good: I was able to run linuxstb's sleep code on my M200.

The bad: There is a place in the code where the GPIO pin A3 is used as an input and it looked like a button to me. So instead of trying to implement the scanning routine for the "keypad" buttons, I thought it would be easier and safer to try to look at one GPIO directly. So I coded a very simple routine that:
1. Enable the GPIO hardware
2. Made port A an input (since all pins are input, except in the keypad scanning routine where A[7:4] are made outputs temporarily, then back to inputs)
3. Read pin A3
4.a. If the pin read 0, then wait for 0x500000 units (which correspond to ~5s in linuxstb's code)
4.b. If the pin read 1, then don't wait
5. jump to the original firmware reset handler

I don't know why, but my M200 is bricked now. I looked and looked at my code, then loaded it in the disassembler to be sure that it was ok, also looked at my automatically-generated routine graph to be even more certain that nothing was wrong, but still there is something that I missed... :'(

It's shocking but on the other side, I knew it was risky to try so I learned from my mistake... But the problem now is I don't see much interest in pursuing my work on this since I don't have a player anymore and I don't think I'll be getting another in the near future... But nonetheless I think I'll continue reading (and posting) on this forum, at least for a while, who knows what can happen (JTAG anyone? ;D)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: Bagder on June 11, 2008, 12:55:18 PM
atomikpunk, if you get in touch with me I think I can promise you compensation from the Rockbox fund if you do decide to buy a new one and get back into the race.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: daniel_at on June 11, 2008, 02:44:02 PM
If someone has a "officially" bricked device, and dosent care to wait for some debricking solutions (did not make any progress with the JTAG port), the device would be a good candidate to desolder the AS-Chip and make some measurements. Direct connections to switches or if the already posted JTAG Pinout is correct and other Pin-Assignments.

If someone wants to ultimately brick is SansaV2: Conntact me, I can give you some hints how to "carefully" (as possible) desolder the Chip.

Daniel
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuse
Post by: atomikpunk on June 11, 2008, 09:44:45 PM
Hi everyone,

I really appreciate all of your support, it's really great to see that what we do is appreciated too. :)

Just for the info, I found out what the problem was with my firmware and no surprise it doesn't work: I used an AND instruction somewhere instead of a ORR and it resulted in disabling the ext. memory clock >:( (Really good move AMS to put the ext. memory clock enable on the same register as the GPIO enable. Bha sorry it liberates me, really it's all my fault on this one :-[)

But now there's a couple of ideas on my mind. I'll think about those a bit more so I don't get things worse than they are now... But what's really tickling me is the idea of trying out the internal boot loader. I wonder if it's possible to run it, and if so, if we would be able to do something with it. It's supposed to be selected by only one pin which should already be pulled up. I wonder if I could use a strong pulldown to make the device load the internal bootloader... And if so, I wonder what would be available in this mode and if it could be used as an unbricking method.

Ideas/comments on this?

BTW LLorean, if you feel like sending one my side, it would make my day ;) (but I'll understand if you don't/can't)

I know it's a little off-topic but if anyone know good deal pleaces for sansa M2X0, clips or E2X0 that will ship to canada, please send those to me in private messages, thanks. The only ones I know are amazon, futureshop, ebay and stuff like that...
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: daniel_at on June 17, 2008, 10:06:47 AM
Hello again, today i made some progress to find a unbrick-solution to help the developers getting started.

The datasheet says that the SoC will boot from the internal ROM if:
 a) The XPC[0] is "1" _or_
 b) The Chip fails to boot from external flash.

I searched for that pin quit a long time - but wasnt lucky so far... so i tried to look for exploiting point b). And luckely it worked after few attempts.

Under on flash-chip i found (again) two unassmblied pads - i dont know what pin it belongs to, bec. i couldnt find a datasheet for the flash... but i hoped that it is smth. like ChipSelect/Enable or an address-pin so that the flash would not respond in the planed way.
I have marked the bridge on this photo:
http://flickr.com/photos/90053035@N00/2495460818/in/set-72157605072639496/
([All Sizes] for a higher resolution)

After (only temporary) bridging it and plugging the Sansa (from OFF-State) into the USB-Port the screen and the wheel stayed dark. I un-bridged it (so that the flash should work now again).

Than the funny moment: lsusb...
Code: [Select]
Bus 001 Device 030: ID 0781:6200 SanDisk Corp.
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x0781 SanDisk Corp.
  idProduct          0x6200
  bcdDevice            4.02
  iManufacturer           6 SanDisk
  iProduct                7 M200Plus
  iSerial                 8         i 0744703011
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          9 config1: Mass Storage only
    bmAttributes         0xc0
      Self Powered
    MaxPower                0mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk (Zip)
      iInterface             10 ms ifac 1 (SCSI::BULK_ONLY)
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  bNumConfigurations      1
Device Status:     0x0001
  Self Powered

And thats it... this is a different DeviceID and complete different lsusb output than my normal one... one funny thing: my device is a E280, but the code from internal boot-loader says it is a "M200Plus". Okay - The internal Bootloader is a masked-PROM (so its "programmed" while the chip is factured) and therfor it is cheaper to use the same mask for all SoCs (i guess).

Okay - and what is with the USB-Massstorage device: fdisk showed a size of ~1024MB (normaly the dvice has 8GB), but no valid partition table.

I dumped the whole drive to a file and examined it afterwards with an hexeditor... and voila, from offset 0 ther is the same data which can be found in the firmware-files. :-D
I havent compared the dump exactly against the OF-files - but the first headers/and instructions are the same.
Okay.. the soultion is so far not very applicable (because you have to open the device, and i only kow that it works with the E200), but if you have bricked your device (atomikpunk? :) ) it is sofar the only solution... Maybe ill find a better soon

Okay... quick resume:
 *) Open device
 *) power off - Usb unplug
 *) search that said pair of pads near one of the flash-chip
 *) bridge it (but not permanetly (i.e. solder) - just press a copper wire above them)
 *) plug the USB in (I had problems on a USB2.0 port.. maybe try a USB1.1 if it dosent work)
 *) The sansa should _not_ light up (display and wheel)
 *) but the computer should report a device pluged in (dmesg or beep in win)
 *) unbridge the pads again
 *) open the whole device (/dev/sd?) in a hexeditor (in linux... in win=?)
 *) ? ? ?
 *) profit :)

But i guess SanDisk has planed some easier (non-invasive) way to call the intern EPROM-Bootloader... maybe ill find it

HTH
Daniel
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: andva on June 17, 2008, 11:13:38 AM
Excellent find! A suggestion: maybe if the Sansa utility is running while you plug in the "bricked" device, it will recognize it and do something - hopefully restoring the firmware from the factory one. If that works, that would be an effective unbricking strategy.

PS: My sympathies for atomikpunk, that really sucked :( Although it's not much, I have just tipped in $30 for the "Rockbox Fund" to partially make up for the bricked player (and to support a small fraction of your awesome work, of course)...
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on June 17, 2008, 07:40:59 PM
Wow that's great news Daniel! I looked at the M200 PCB pictures on the wiki, and there are a couple of unsoldered resistors too. There is one particularly attracting one near the JTAG connector, I guess that it will be my first look. If it works, the next thing to check will be to modify a byte or two in there to see if it will unbrick my player. I think however that I'll play safe and use a 10 or 100 ohms res. to short the pads, one never know ;)

Owh and BTW, on the (few) NAND flash datasheets I looked at that are TSOP-48, the pin which is connected to the resistor you jumped (pin 19) is almost always the write protect (/WP). So it's a bit confusing as of why it works, but maybe that pin is also connected somewhere else...


Edit: Ok I did try the same procedure and was able to see a plain'ol mass storage device in lsusb. However, unlike you Daniel, I have a device which shows up as being 0MB. I, however, only have USB 2.0 ports on my laptop so maybe this is the problem. Here is a snap of the interesting dmesg backlog:
Code: [Select]
usb 4-1: new high speed USB device using ehci_hcd and address 4
usb 4-1: configuration #1 chosen from 1 choice
scsi12 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 4
usb-storage: waiting for device to settle before scanning
scsi 12:0:0:0: Direct-Access     UNDEF    storage          1.0  PQ: 0 ANSI: 0
SCSI device sda: 1 512-byte hdwr sectors (0 MB)
sda: Write Protect is off
sda: Mode Sense: 00 00 00 00
sda: assuming drive cache: write through
SCSI device sda: 1 512-byte hdwr sectors (0 MB)
sda: Write Protect is off
sda: Mode Sense: 00 00 00 00
sda: assuming drive cache: write through
 sda:<6>sda: Current: sense key=0x0
    ASC=0x0 ASCQ=0x0
 unknown partition table
sd 12:0:0:0: Attached scsi removable disk sda
usb-storage: device scan complete
sda: Current: sense key=0x0
    ASC=0x0 ASCQ=0x0

The lsusb output is the same as yours if I use my usb ports as usb 1.1 (by rmmod-ing ehci_hcd). Maybe there is something with my linux box? So I'll try simply rebooting in windows to see what happens... (2s)


Edit 2: Well, on windows, it is detected as an "M200 Plus" device and windows installs 2 (UNDEF) drives. If I try to right-click on them, the first one seems to freeze explorer for a bunch of seconds, while right-clicking on the second one simply gives out that the drive is 0 bytes large with 0 bytes free. So it seems that there is still something missing on my side.

Any ideas out there? Daniel, you said that "I had problems on a USB2.0 port.. maybe try a USB1.1 if it doesn't work", what kind of problems did you get? Was it similar to what I'm getting now?

Owh and BTW, the M200 "bootloader" unsoldered resistor is the one right between the "repeat" button and the little battery...


PS: thanks everyone for the nice words, I really appreciate your support :)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: daniel_at on June 18, 2008, 02:31:43 AM
Hi atomicpunk & others,

Cool that you tried the procedure also with your device and I think its a good sign, that it works basically... Okay some ideas:

*) How did you (un-)bridge the pads? Maybe it is a timing problem, I dont know if i just had luck, but it worked three times in a row (only tried it 3x).
*) I have two Flash-Chips in my Sansa - how many have you? Maybe that is important... Maybe the bootloader OF is on the other one, and i just block (writeprotect?!) the other one.
*) What does "sudo fdisk -s /dev/sd?" say? or "sudo od /dev/sd?"
*) Under Windows: do you know WinHex ( http://www.x-ways.net/winhex/index-m.html ) - Very neat hexeditor (can open devices directly)
*) My proplems with USB2: did not work at all... the sansa booted into the OF - it gave me some thoughts "why?" and "how?"... But maybe I also had a problem while bridging the pads (bec. my computer with USB2 is in an other room - so i used other tools)
*) The computer which worked is a "native" USB1.1 (Notebook from the year 2000)

Okay.. thats all for now - would be glad if we get you (atomicpunk) back into the race :)

[edit]
I yesterday also tried to find other ways to enable the internal ROM-booldr.: I thought it would be reasonable that SanDisk put that XPC[0] Pin onto the Sansa-plug. So that a technican can flash the sansa with a special plug. Tried to pull up each pin up (one-by-one, with an external powersupply) and plug it into my USB: no luck. Than i though somewhere where it is easy reachable... There is a plastic-shield which is only glued above the battery: tried to pull up some pads, or bridge some resistors: no luck. Maybe some pin within the SD-Card reader.. so that you have to use a special crafted SD-Dummy... no luck.
But i wonder that my Sansa still works :)
[/edit]

CU
Daniel
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: JD24 on June 18, 2008, 04:30:28 AM
Nice find on the recovery thing daniel!

I read somewhere else that someone did enter the recovery mode with bridging
2 of the NAND datapins on startup. That could makes sense because
the cpu cannot read the flash correctly then.

EDIT:
I found the link:

http://s1mp3.org/en/docs_deadrec.php

JD
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: scharkalvin on June 18, 2008, 08:05:12 AM
you may be able to find a real small surface mount spst push button switch that
can be soldered across those two pins. 
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: andva on June 18, 2008, 11:00:11 AM
I know it might be a really dumb suggestion, but if the pinouts for the SoC are standard (and thus available in the datasheet), the XPC pin may be exposed (as in, available to poke directly) somewhere.

If I'm not mistaken the SoC (at least for the e200v2, but hopefully the same for them all) is the square chip in this image (pictures already posted by Daniel):

http://www.flickr.com/photos/90053035@N00/2495459364/

Then, you may identify most of the pins making it through to the other side (I suppose the PCB is multilayer, so apparently not everyone is, though):

http://www.flickr.com/photos/90053035@N00/2496918368/

EDIT: It looks like he already did that!

http://www.flickr.com/photos/90053035@N00/2586759595

Now, anybody know what the correct pin is?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: daniel_at on June 18, 2008, 11:33:05 AM
Hello... I was indeed working on that approch - but somehow none of the accessible pins (i have tested) make sense compared to the description in the datasheet... Non of the JTAG pins are connected to any of the pins from that connector...

Tested some of the dbop_d (Display port data) pins  - none seem to be connected with the LCD  (Bec. the XPC[0] Pin is also a dbop_d Pin...). But some supply pins i measured were okay.

So there are some possibilities
 *) I mixed up the pin-numbering (i am dyslexic :) ) (but i tried rotated and mirrored versions of it)
 *) This is a multilayer with not-though-all-layers-vias (dont know if that is possible?)
 *) Sandisk has a ordered a special Pinout for the chip
 *) My DMS is playing tricks on me...

Dont know - maybe someone with an other hardware could give it a try...

Daniel
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on June 18, 2008, 12:18:47 PM
Hi Daniel and everyone,

- yes indeed I tried multiple "delays" between my USB connection and the unbridging of the pads, but it doesn'T seem to change anything...
- the M250 have a single flash chip, but I did probe the pad and it "beeps" on both flash pin 19. This means that both pin 19 are pulled down simultaneously when the pads are shorted
- I tried using fdisk /dev/sda and the message is "unable to read /dev/sda", fdisk -l /dev/sda yields nothing at all, but I didn't try fdisk -s
- Thanks for the hex editor link, I was used to frhed, but I'll give it a try someday :)

But btw, if you want to try looking at XPC[0], you must pull _down_ the pins, not pull up ;) The bootloader is actually called on low XPC[0], and the unsoldered resistor has a pad to both chips write protect and the other connected to ground, so this is definitely a pull down.

And looking at your pictures, you seem to have the good pinout. However, just in case, did you remove a bit of the protective screen before probing the vias? Or used a needle to probe through it? Because the protective green screen is isolant... I also know that it is possible to have partial or hidden vias, but it grows the production cost so most production will try to stay away from that except when absolutely needed...

andva: "EDIT: It looks like he already did that!" He = daniel_at ;)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: daniel_at on June 18, 2008, 12:43:36 PM
Hello...

Pull down? Why do you think so?
Code: [Select]
XPC[0]
BOOT LOADER source select input
1: internal ROM
0: external ROM/Flash
(see also p21)

Or did I miss somewhere a "not"?

> - the M250 have a single flash chip, but I did probe the pad and it "beeps" on both flash pin 19. This means that both pin 19 are pulled down simultaneously when the pads are shorted

Sorry, I dont understand that sentence fully... One flash... both "pin 19" - [edit]err... just understood it... You have a place for a second Chip  on your pcb? Okay ... that makes sense [/edit]

Youre idea about the writelock seems to be true - i googled some (other) datasheets for 32Gbit-TSOP48-Flashe-Chips and they all have \WL on pin 19... Dont understand why that leads to a failed boot - maybe an other pin is also connected to that net.

Maybe youll brave enough to try a method noted by JD24 - there someone just shorted all 8 IO-Pins while booting the player (not a SanDisk at all). Usually it should be enough to ground one or two pins, so that the internal bootldr wont get the correct headers. BUT I dont know what the I/O-Drivers of the SoC would think about it :)

>  did you remove a bit of the protective screen before probing the vias?

Yep - i did... i have grinded a very sharp needle-probe for my DMS for that things... And i had connections to most of the pins - but with very high-impedance -  so no direct (copper) connection.

Daniel
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: mitchlr on June 19, 2008, 01:10:28 AM
Atomicpunk,
Did you get a replacement player yet?  If not, perhaps a couple of us who lack the ability to work on the project can see what we can do to get one to you.
Kindest regards,
Rob
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on June 19, 2008, 07:30:24 AM
Hi Daniel, Rob and everyone,

Well the unsoldered pads is definitely for a pulldown resistor because one of its pad is tied to ground (I probed it while unplugged and measured its voltage while plugged). But I think you are right, when XPC[0] is high, the cpu is supposed to boot on internal ROM. So there is something we miss in the circuit... ???

Yeah sorry I wasn't clear, there is effectively 2 flash footprints on the PCB, but on the M250 there is only 1 x 2Gb chip soldered.

About my player, thanks everyone's support and particularly for Bagder (in rockbox's name), which came with a very generous replacement offer to me so that I'll be able to get a replacement player very soon.  :) [shameless_plug]It's all possible thanks to the generous donators, so as Rob said, if you aren't able to contribute technically with the development, you can all do your part by donating to the project.[/shameless_plug]

But this is also very good news on the "hardware investigation" side because I'll be a little less shy trying things with my bricked player.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: amaldo on June 21, 2008, 09:19:00 AM
I would like to confirm that shorting the two pads near the flash-ram-chip boots my Sansa e250v2 into the 'special' mode. This works fine in my Linux machine with USB2.0 (The ehci module reports the connection)

I also see a 1027342336bytes (980MiB) drive, and the beginning seems to be exactly the same as the firmware file I installed (e200pe.bin). I haven't tried writing to it yet. Does anybody have a patched firmware with a delay at bootup, so I could try writing it into the drive?

The USB ID is: 0781:6200 SanDisk Corp. (Sandisk M200Plus)

Trying to get JTAG to work has not been very successful. I followed the pinout that hth posted in this forum, but the TDO pin is stuck at 1 (actually 2.4V instead of 3.1V). It might be related to the empty solder pads next to what we think are the JTAG pads. The bad news is that after looking at the pinout posted here (http://www.flickr.com/photos/90053035@N00/2586759595/sizes/o/) by Daniel, none of the JTAG pins from the Datasheet are connected to those pads behind the screen. Am I missing something? Maybe a buffer circuit in the middle?

Edit: The pinout as suggested by Daniel seems to be ok, I tested the power pins, and they are in the right place:

A15  = 3.1V
B15 = 0V
K1 = 1.2V
L1  = 0V

Have a nice weekend!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: andva on June 21, 2008, 11:16:46 AM
Excellent work, everyone!

Does anybody have a patched firmware with a delay at bootup, so I could try writing it into the drive?

I think that there is none yet for the e200v2 series, but you could always try writing an old version of the firmware and checking the version after rebooting to confirm that it has been updated. Bagder keeps an archive of several versions in his homepage:

http://daniel.haxx.se/sansa/v2.html

best regards - andva
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: daniel_at on June 21, 2008, 01:51:20 PM
@amaldo:

I already mentioned that i have not found any reasonable connection to that maybe-JTAG-pins. Can you probaply check if I made an error within my numberation of the Pins (rotating/mirroring)?

But maybe Sansa had ordered a special designed BGA-Package. At least they have a special PROM-Mask and a own Package labeling - but i see no reason for that... may be not that cheap..

Daniel
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: embrion on June 22, 2008, 03:37:02 AM
I checked disassembled Clip and Fuze and I can't see any candidates for jtag pins on Clip and maybe one on Fuze. Is it possible that they're just not on the PCB? Also, maybe Sandisk use jtag via their proprietary port? It would be convenient for service as disassembly wouldn't be necessary. Something like this http://www.segger.com/jpg/sam_ice.jpg
Can't we just direct solder into correct pins of SoC ? We got docs of it and the chip itself got jtag support  http://www.austriamicrosystems.com/03products/products_detail/AS3525/download/block_diagramm.gif

I'm still looking for something that would help people working on the jtag. As we know now, v2 uses Sagger embOS. Sagger also sells SAM-ICE and J-Link jtag simulators. I'm trying to find some schematics. For now, I found something about mysterious missing resistor. Check this http://www.atmel.com/dyn/resources/prod_documents/doc6206.pdf. Apart from described pinouts at page 2-1,2-2, the document also says about removing resistor at page 8-1. I know they remove it from J-link itself but maybe it is something?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on June 22, 2008, 07:36:07 PM
Hi everyone,

I agree with caladan that probably emFile is used, and I guess emUSB is also a valid hypothesis. However, I doubt emLoad is used since I simply don't the use of it when USB is available.

Concerning pinout, I'm really puzzled by all of this, I simply don't understand why pinout would be different from the original chip pinout. I thin it would also be quite difficult to change the pinout of parts of this complexity, geographically speaking.

Have we measured for capacitors between jtag pads and expected processor pins? I guess the next step on the hardware side is to probe everything we can and share results. I will gladly probe mine and share results when I'll have time to do so. As for the buffer you mentioned Amaldo, well I don't see one on the PCB, but there could be one somewhere in the processor chip maybe...

Andva, if you're adventurous, their is a patcher on SVN that you could use to patch your firmware with the delay. Have a look in utils/AMS/hacking.

Anyone with another V2 kind tried the "resistor shorting mode" on their player? 'Cause up to now, only people with E200 have made it to see a non-zero drive...
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on June 24, 2008, 09:17:33 PM
Just a small update to the wiki listing all the GPIOs (we know of) that are used in the firmware and their deduced usage.

I'm still thinking about how we could inject more than a couple of bytes into the OF to insert a rockbox bootloader, but I've not much progress to report so far... If you've got ideas on this, please share them! Of course, when we'll find a button we can easily read at boot, it will be WAY easier to test because we will be able to test some code without the risk of bricking (more) devices. We could try the keypad scanning algorithm, but there's a bunch of instructions in there, maybe we could clean it up a bit and use that?

Owh and just for the records, I've tried to bridge 2 I/O pins on the flash like it is suggested on S1MP3.org to make the SoC think the flash is corrupted. This was in order to load the internal bootloader. I've used a 100 ohms resistor without success so far. I also tried grounding some I/O pins, one at a time, via that same 100 ohms resistor, also without success... I'm a bit shy at trying it directly with a wire, fearing that I'd burn the chips drivers or something...

I'd like to help you guys probing the supposedly JTAG pins but on the M200 series, the LCD display is soldered directly above those pins >:( If I may suggest, probe the connector pins with every components, like resistors and capacitors... Maybe we are just missing passive components on the JTAG path...
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: daniel_at on July 07, 2008, 08:50:37 AM
Hello all...

Had today again some time, which I spent infront of my e200-V2.

I tried for the first time to write to the partition exhibited by the special mode - and: It works!

 * Just modified some bits in the "DEAD-BEEF"-areas
 * unpluged the device
 * started in normal mode: works.
 * unplug again
 * start in special-mode
 * check if it is still modified: YES
(no battery was connected, so it was really modified in flash)

So if anyone has some time to provide me with modified firmwares who has no e200, I am willingly available for testing them. Just conntact me by this thread or by PM. Best would be to test the modfications via IM in "realtime".

Daniel
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: andva on July 07, 2008, 11:49:51 AM
That's excellent, Daniel. I haven't yet gotten around to using atomikpunk's tools, but if you feel adventurous, you may try writing a different version of the firmware to the device to see if it is updated. Bagder keeps several versions in his website: http://daniel.haxx.se/sansa/v2.html

Thanks for trying, keep up the good work!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on July 07, 2008, 12:11:44 PM
Hi Daniel,

this is great news! I'm more than willing to help you test some stuff on your e200 if we get to be online on jabber at the same time :) I'll write a couple of tests we could try... I'll also bring an wall-powered USB hub from work to see if power was the problem with my m200... If not, I'm really clueless about the problem I'm facing with this one...

Any update on the JTAG stuff? I'm about to build a wiggler JTAG interface and try to test it on my side...

Also, I've a couple of minor findings I'd like to put on the wiki, but since the graph plugin does'nt work, I'll wait a bit... But everything is minor, nothing of big interest to report yet.

BTW, I got myself another sansa from ebay but unfortunately, it's a m200 v1. I'll try to see if someone is interested in trading with a v2, maybe in the sansa v1 port forum or something... Or if someone here wish to trade, contact me via personal messages!

Francois
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: daniel_at on July 07, 2008, 03:23:18 PM
Hello atomikpunk,

I have played a bit with motified firmwares. I use the utils/AMS/hacking tools from Dave Chapman from the svn.

I have modified the test.S:
Code: [Select]
.equ AS3525_GPIO1_BASE, 0xC80B0000
.equ GPIO3_DATA, (AS3525_GPIO3_BASE+0x0000)

.equ AS3525_GPIO3_BASE, 0xC80D0000
.equ GPIO1_DATA, (AS3525_GPIO1_BASE+0x0000)

/* This value is filled in by mkamsboot */
originalentry:   .word   0

        /* A delay loop - just to prove we're running */
ldr    r1, =GPIO1_DATA
ldrb   r1, [r1]  /* Load GPIOC-Data into r1 */
        tst   r1, #0x10   /* check if .. is set */
bne    noloop

        mov   r1, #0x500000       /* Approximately 5 seconds */
loop:   subs  r1, r1, #1
        bne   loop


        /* Now branch back to the original firmware's entry point */
noloop:        ldr   pc, originalentry
(tried different Bit-Masks....but not all)

But I did not get any results so far - the delay always happens. Which is already a good step, which says that my sansa runs my modified code.

But i also have some strange behaviour: the first boot after a fw-update (via my "special-mode"-methode) takes about 30seconds until the "Sansa"-Bootlogo comes up. Each consecutive start takes about 7seconds (with delay) or 2 seconds (without delay, removed within code)

I tried to analyse the patched firmware in the disasm... But i have some problems to get it doing what I want... Your help would be appreciated :) Just ping me, if you see me online - would be great.

Daniel
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on July 07, 2008, 07:43:58 PM
Hi Daniel (and everyone),

well there is at least one thing I see missing in your code: you should enable the GPIO module clock. This is done via the CGU_PERI register which is at 0xC80F0014 via bit 16 (0x10000). Be sure to read CGU_PERI, logical _OR_ (damnit) bit 0x10000 with the register content, and then write back to this register...

For my m200 special mode, I'm still clueless why it won't show up a drive. I'm wondering if my ext. mem. firmware is ran before the special mode bootloader... That could explain why the flash is still not found but I wonder how come the firmware would get executed before turning to the bootloader... Anyone got an idea on this?

(damn time zones... if only you guys were from americas  ;D)

Francois
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: daniel_at on July 08, 2008, 01:54:05 PM
Hello thread,

Just played a bit again with my v2. Thx, atomikpunk for the hint with the Clock-Init. The datasheet did not mention it near the GPIO-docu, but some pages apart... Havent planned to read the whole pdf :)

now my Code looks like this:
Code: [Select]
/* This value is filled in by mkamsboot */
originalentry:   .word   0


.equ AS3525_GPIO1_BASE, 0xC80B0000
.equ GPIO1_DATA, (AS3525_GPIO1_BASE+0x0000)

.equ AS3525_GPIO3_BASE, 0xC80D0000
.equ GPIO3_DATA, (AS3525_GPIO3_BASE+0x0000)

.equ CGU_PERI,0xC80F0014

.equ AS3525_I2C_AUDIO_BASE, 0xC8070000
.equ SYSTEM_REG, (AS3525_I2C_AUDIO_BASE+0x20)

/* enable the GPIO-Clock */
ldr r1, =CGU_PERI
ldr r0,[r1]

orr r0,r0,#(1<<16)
str r0,[r1]

        /* A delay loop - just to prove we're running */

        mov   r1, #0x500000       /* Approximately 5 seconds */
loop:

/* check register */
ldr    r2, =GPIO1_DATA
ldrb   r2, [r2]  /* Load GPIOC-Data into r1 */
        tst    r2, #0x80   /* check if .. is set */
/*cmp r2,#0*/
bne    noloop

        subs  r1, r1, #1
        bne   loop


        /* Now branch back to the original firmware's entry point */
noloop:        ldr   pc, originalentry
(Test now in the loop - maybe to circumvent timing problems)

Tried all 8 bitmasks for GPIO1 (which is hopefully GPIOA): no reaction to keypresses - every time it waits the ~5 seconds.

Maybe one problem: Measured the voltage on the switches again - one side is always ground the other one:
 * After power on, but in the wait-loop: 1.9V
 * If the Sansa-Bootscreen appears and in normal mode: 3V
 * In normal mode, but screen (and blue leds) switching off: 0.5V
But even with from that mode (with 0.5V) the sansa can detect keypresses.

(But i have measured with a slow DMS - maybe the keys are tested only for a short periode of time, and the DMS integrates over it... Will test again with oscilloscope some time)

Not sure what that means... but maybe there are some pullups or some powermanagment stuff to enable.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on July 08, 2008, 11:15:41 PM
Hi again,

Well I'm looking at the e200 code at the moment and it doesn't seem to have any "keypad scanning" routine, at least not as easily visible. There seems to be GPIOB pin 6 which is read in the routine at 0x851C and then its value is used a little later in that same routine. If the pin is high, then memory variable at 0x2181E is put to 1. If the pin is low, then that same memory variable is unchanged. Could that be the hold button?

Here is a list of the pins, direction (input or output) and routine address(es) where it is used, that could give a clue which one to test...

PinDirUsage in code
A0out0x1FD8, 0x1FF8
A1in & out0x851C, 0x8720
A2in0x6728
A3out0x4418
A4out0x72DA
A5out0x442C (which seems to be the LCD init routine BTW...
A6n/aUnused
A7out0x442C (but strange enough since it is only cleared once and not used again...)
B0n/aUnused
B1outA lot of routines

To be continued... (somewhat sooner than midnight ;D)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on July 11, 2008, 01:00:23 PM
Well a big news for today: I got JTAG to work on my M200!!! ;D

Hardware: Wiggler clone as shown in here (http://www.frozeneskimo.com/electronics/arm-tutorials/jtag-wiggler-clone). However, I needed to add a 10k pull-up resistor between VCC and the RST JTAG line.

Software: H-JTAG, which is a free and very nice windows JTAG interface for debuggers. What is nice about it is that it can auto-detect connected targets. This way, it was easy to know when I got it right because instead of the "unable to detect target" message I was constantly getting, I got the "ARM922T" display in big blue characters.

The JTAG pins on the M200 are (as expected) as noted on the PCB. Beginning from the VCC pin, we have:
VCC
TRST
TDI
TMS
TCLK
TDO
GND

You can get a better view with this picture (http://www.flickr.com/photos/28569998@N08/2658411725/).

So what's next? Install the winarm toolkit and try to debug this thing. If I can debug that thing and insert my own instructions, that would make my day (because I could recover my bricked m200 ;D)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: pedrov on July 14, 2008, 11:49:57 AM
Hi all,

I just bought a sansa v2 (e280), and feel a bit disappointed about the current firmware; so I'm interesting in helping to port rockbox on these devices. I read this thread, and I was impressed by what has already been discovered. Well done !

I used hachoir (a tool to discover subfiles into files), and I got this :

Code: [Select]
% hachoir-subfile e200pe.bin
[+] Start search on 15728640 bytes (15.0 MB)

Search: 19.58% -- offset=3080192 (2.9 MB)
[+] File at 3812522 size=21872 (21.4 KB): PNG picture: 256x256x8
[+] File at 3834394 size=2341 (2341 bytes): PNG picture: 132x32x8
[+] File at 3865319 size=52475 (51.2 KB): PNG picture: 256x256x32 (alpha layer)
[+] File at 3917794 size=3882 (3882 bytes): PNG picture: 132x32x32 (alpha layer)
Search: 53.75% -- offset=8454144 (8.1 MB) -- 2.2 MB/sec  -- ETA: 3 sec 111 ms
Search: 77.92% -- offset=12255232 (11.7 MB) -- 2.4 MB/sec  -- ETA: 1 sec 405 ms

[+] End of search -- offset=15728640 (15.0 MB)
Total time: 6 sec 223 ms -- global rate: 2.4 MB/sec

By the way these pictures aren't really interesting to extract (sandisk logos, and pictures of the device ...). But since I did not find any mention of them on the firmware wiki page, I thought it would be interesting to mention.

Another thing : I tried to upgrade to a "by-hand" modified firmware (I just changed "HOLD" into "HALD" in a string), but it did not work as expected. Weird, since the checksum program (available into Daniel's wiki) told me that the checksum did not changed. My sansa did not even want to flash itself with this modified version ('Upgrade in progress ...' and then shutdown).

I'm really interested in giving a hand, if I can.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: embrion on July 14, 2008, 01:14:06 PM
Well a big news for today: I got JTAG to work on my M200!!! ;D
[...]
So what's next? Install the winarm toolkit and try to debug this thing. If I can debug that thing and insert my own instructions, that would make my day (because I could recover my bricked m200 ;D)
Nice, can't wait to hear You resurrected  Your player :)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on July 15, 2008, 09:23:55 PM
Hi peeps,

another news but not good this time, it seems that JTAG stopped responding on my device. I could be many things because I was working on a pretty risky setup with a breadboard and stuff so maybe I inadvertently shorted wires or something. Anyway, no big deal, I was already prepared not to revive my sansa...  :(

But I can give more detail on my method...

I came across the OCD Commander software by Macraigor, which is the original producer of the Wiggler JTAG adapter/cable. It's very nice because you can directly control the cpu, halt it, reset it, inject instructions, replace instructions, etc. And most of all, it is free ;D

This software, however, requires to add a jumper between pin 8 and 15 of the parallel port to  be recognized, so here is a valid schematic (http://wiki.openwrt.org/OpenWrtDocs/Customizing/Hardware/JTAG_Cable) to be used with the OCD Commander software. Note to use the buffered version with the 74HC244 (or 74AC244 if that's what you have...).

With this setup, I was able to connect to the JTAG module on the Sansa m200 SoC, halt it, reset it, update the clock generation unit register to re-enable the external memory module, inject a valid ORR instruction to fix my faulty AND instruction and make the program run again. And guess what, I saw the sansa logo again since a long time ;D However, god-knows-why, the device booted in MTP mode and I was not able to update the firmware so I tried to fix that up and that's probably when I messed something up because I wasn't able to see the device again with OCD Commander (and H-JTAG for those that wonder). It kept telling me the cable was disconnected though I haven't touched a thing there, and checking that "pop API errors" checkbox, I was able to see that this error was triggered when attempting to contact the device...

I was able to connect/disconnect/reset/restart a lot of time and the device was up for all those tries before the last. And the problem is not the parallel port because I checked it out otherwise and it works fine. The only I haven't tested is to use a battery but that's difficult because of the open case so I'd have to tape the battery there and that wouldn't be practical... But honestly, I doubt it would work anyway...

Anyway that's about it for JTAG. My conclusion is: it should be possible to resurrect a bricked player with JTAG if someone is able to solder small wire on its PCB. It should also provide invaluable help to developers to test their firmwares. However, it can be risky because all the electronic is open and a single error can be dangerous.

Now onto the firmware side.

Pedrov and Darkstylist, thanks for the info, it confirms what we have found up to now. If you are interested in helping out, you can contact me via PM and we'll try to keep in touch via jabber, msn or something. We already did a lot of disassembling and analysis work but there are still plenty of misunderstood routines. I'm still searching for a good mean to share work, but meanwhile, we have the wiki, and more precisely that page: http://www.rockbox.org/twiki/bin/view/Main/SansaV2Firmware. Please be sure to read that whole thread because there are a lot of information in here.

See ya later guys
Title: Sansa Fuze/Clip FM Chip
Post by: mlifted on July 18, 2008, 06:31:04 AM
Hi folks,

found this out (mainly by accident  ;)). Hopefully this is new to you:
The FM Chip seen in the Fuze/Clip Disassembly pix from abi is the Si4702 from Silicon Labs (https://www.silabs.com/products/audiovideo/fmreceivers/Pages/Si470203.aspx).

The Markings on the Fuze Pic are:
0219 ->  Si4702 / Frimware Revision 19
CXXX -> Revision Code C Die
741  -> Production Year 2007/Week 41

The Markings on the Clip Pic are:
0215 ->  Si4702 / Frimware Revision 15
BXXX -> Revision Code B Die
735  -> Production Year 2007/Week 35

Hope that helps, and  keep up your good work! ;D

marco
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: draeath on July 18, 2008, 11:22:57 AM
atomikpunk, is there anything we can do to help replace your device?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on July 28, 2008, 04:51:17 PM
Hello,

Thanks to all of you for working on the reverse engineering, this progress is very great  :D

I would like to help figuring out the firmware format, I read this thread and the SansaV2Firmware wiki page,
so I decided to try this techniques to analyze the firmware running on my Sansa Clip
The firmware is version 01.01.29F, md5sum c12711342169c66e209540cd1f27cd26, available on http://forums.sandisk.com/sansa/board/message?board.id=clip&thread.id=6720

I want to split the .bin file in separate blocks to be able to study their content separately.

The information I found on this thread matched exactly... or should I say almost.

* Every value is 32 bits little endian if not specified otherwise
* Every block's size is padded on a 0x200 bytes boundary

OFFSET 0x0
The first 0x400 bytes are 2 identical blocks of 0x200 bytes (except their first byte is respectively 0 and 1.
This block is the "Firmware header" block.

OFFSET 0x400
Then follow a block whose size is written at offset 0x0c of 1st block: the "Firmware" block.

Then follow all kinds of blocks:
OFFSET 0x1e400
The block following immediately is a "library block" (for the function "drmndt_pers")

(By the way the "drm10*" functions have been replaced by "drmpd_*" functions, but I think you don't care much about drm ;)

Like all library blocks, its block size is written at offset 0xc

OFFSET 0x30800
Immediately after this block, follows a special padding block: it's 4 first bytes are 0xdeadbeef, but the rest of the block is just random (or meaningful?) data.
I assume the size of this block is 0x200 bytes.

OFFSET 0x30a00 - 0x46400
After this padding block follow 346 undetermined blocks, assumed of size 0x200.

OFFSET 0x46400
A library block for function "otg_functio", size 0x21000 bytes

OFFSET 0x67400
A padding block whose 4 first bytes are 0xdeadbeef

OFFSET 0x67600 - 0x6e400
After this padding block follow 7502 undetermined blocks, assumed of size 0x200.

OFFSET 0x6e400
A library block for function "usb_functio", size 0x1ee00 bytes

and so one for all the 22 library blocks, each followed by a padding block, and by unknown blocks

OFFSET 0x29e400 - 0x473200
6 header blocks followed by a padding block

OFFSET 0x473400 - END
Unknown blocks

@atomic_punk
I don't understand when you say the offset of the library blocks can be obtained with:
0x400 + (Index * block multiplier )
I suppose index is the index of the library block (1st block's index is 0), but this formulae doesn't match with my firmware.

The relation I found with the block multiplier field is : 512 * block multiplier == size of the firmware block.
Tested on 3 different firmwares: The 01.01.29 for clip, a firmware for fuze, and firmware for M200 (versions unknown (by the way we could check if we find a byte which would be 29 for version 01.01.29 and 20 for 01.01.20. This is doable because it's most likely a 32bits number, and the firmwares often (always?) have the same size: 5243904 bytes).

By the way what is the md5sum of the firmware you're analyzing ?
I've got a firmware fc9dd6116001b3e6a150b898f1b091f0  m200p-4.1.08A.bin but the offsets differs a little so I think it's not the exact same version than yours.

I have written a little tool to display the structure of a firmware, and make checks to verify certain assumptions. I can attach to the forum if you want to help, when it works well against all known firmwares, I will propose it to replace utils/AMS/hacking/amsinfo.c in svn.

Thanks, I will continue my research tomorrow  ;D
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on July 28, 2008, 08:41:04 PM
Hi funman and welcome to the magical world of v2 disassembly ;D

Great work up to now, but maybe some hints will get you back on track with the clip disassembly ;)
1. The firmware header is effectively 0x400 bytes long and there are 2 (almost identical) copies of the same header at 0x000 and 0x200.
2. At 0x400, there is the firmware block, this is where the sansa boots on power-up/reset. Take care however, because that block length is specified in the firmware header at 0x00C and can be calculated using firmware_length = 0x200 * firmware_size_multiplier. I am sorry however, I made a mistake in the table, you are right that the library blocks aren't at 0x400 + index*0x1e000 but at 0x400 + firmware_length + index*0x1e000. And that is for the M200, I know this value (0x1e000) is different for the E200, so it could be different for the clip too.
3. Take care that in my descriptions, I almost always remove the 0x400 byte long header from the file so addresses will probably be off by 0x400. This however really helps with the firmware analysis because the firmware is based at 0x00000000 and with the 0x400 offset, I'd need to do relative offsets all the time...
4. The firmware I used is the one right here (http://daniel.haxx.se/sansa/v2/m200/m200p.bin).

Yeah sure it would be great if you could attach your little soft, I'd have a look.

If you are interested in cooperation, we could get in touch on irc/jabber/whatever. Send me your instant messenger info in PM so we could talk more easily.

(BTW, if wiki admins are reading this, please fix the directedgraphplugin, that would be nice :))
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on July 28, 2008, 09:49:27 PM
The mosquitoes don't want me to sleep so I found some weird stuff ^^

1. Ok

2. This is the first bytes of my firmware block:

0000400: 58f0 9fe5 58f0 9fe5 58f0 9fe5 58f0 9fe5  X...X...X...X...

I think in previous posts you describe this block as containing code this way:
The 16 first bytes would contain branching to 4 functions.
However it's all the same: 0x58f09fe5 so that doesn't look like it's the case here.
I should get a assembler / disassembler for the AMS cpu ...

About the block multiplier, I found that all library blocks don't have the same size for me...

I use this theory : all unknown blocks just after the library blocks in my previous message are in fact
part of the library block and represent padding. I just substract the offsets between the next block
and the current block to get their size:

The first 8 blocks are 0x28000 bytes long
The 13 following blocks are 0x14000 bytes long (2 times less)
The last library block seems to be 0x3C000 bytes (it fits in 0x14000 but 320 blocks (0x28000 bytes) follow it...

Some of the first 8 blocks would fit in 0x14000 bytes also but are then followed by 160 unknown blocks
... (0x14000bytes)

So the size is always a multiple of 0x14000, but for the 2 other firmwares I have it
differs: it's a multiple of 128*0x200 (0x10000) or 240*0x200 (0x1e000)

I will check against the 2 other firmwares if the library block sizes are always identical or can vary also.
I tried to relate this variable block size with the unknown values in the firmware header but I made no match :/

Also, by looking at the hexdump I found the Unicode certificate data at 0x473600 (3 blocks after the last header block) and I will found a way to detect it (the packet differs a bit between the different firmwares).

3.4. Ok I understand why the adresses differ, because I use this firmware also in my tests.

I attach my prog, it was meant to split the firmware in multiple files but for now it only prints the different block types with offsets and block sizes.
Note you have to edit the library block size multiplier to match the one from your firmware to avoid getting thousands of padding blocks displayed between library blocks (for now).

In the future I should make a package which fetches different firmwares from sansa ftp and check them all.

Bye ^^
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on July 28, 2008, 10:00:43 PM
Hi funman,

For the branches, this is absolutely normal because branches are all relatives! The only that it tells you is that the address of the jumps are all in sequence in the firmware, which indeed is the case.

So we have two possibilities for the clip, a library block size of 0x14000 and/or 0x28000. I'll try to have a look on my side in the next days.

I'm glad you posted your program, I'll have a look at it in the next days! Hopefully, we'll be able to check that out online together.

See ya


Edit: Ok I checked out the clip firmware file 1.1.29f. The format is definitely different than the M200. Here's a bit of what I found this morning:

0x00000000: firmware header
0x00000400: firmware
0x0001E400: first library block
0x00030800: another library block
...

It seems that some library blocks now begin with 0xDEADBEEF and I'm not sure they necessarily have all the same size.

Owh BTW, if you're looking for stuff about the AMS3525 SoC, the embedded core is an ARM922T so you can get info about it...

See ya later.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on July 29, 2008, 11:56:57 AM
"0x00000000: firmware header
0x00000400: firmware
0x0001E400: first library block
0x00030800: another library block
..."

For me the 2nd library block is at 0x46400

"It seems that some library blocks now begin with 0xDEADBEEF and I'm not sure they necessarily have all the same size."

I think we must take 0xDEADBEEF in the literal sense: this block is dead beef aka padding ;)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on July 29, 2008, 12:41:59 PM
Hi funman,

The first library block is at 0x1E400 and the second one is as you said 0x46400.  And I can see that there are at least 2-3 more following at the same 0x28000 distance. So I guess that the lib block size on the clip is 0x28000.

About the dead beef values, it seems that the clip changed the way dead beef padding is done. They seem to only mark the first dword of each padding block as dead beef now, but I wouldn't be surprised if the following bytes were still junk.

And I stumbled upon the version number in the firmware, juste in case you were still looking for it. It is a plain string located at 0x1DF3A ;)


Edit: Ok a little something for tonight, funman and I finally got online at the same time/space continuum and found some stuff on the clip firmware. It seems that new versions don't have whole deadbeef padding, but only the first DWORD of padding blocks. That suggests that we could insert our code in there so I guess one problem's gone. Now we need to find how to listen to a button. Owh and the clip firmware as a checksum similar to the e200 one, but it is located 4 bytes earlier in the file, so the file really is a 0x200 multiple with the last DWORD being the checksum. That's it for tonight...
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: tobi-lu on July 31, 2008, 04:09:38 AM
Hi people!

I just read through this whole thread, the wiki page and the haxx page and now I also want to try to contribute to this.
My player is a e250v2. Right now, I don't know very much about firmware reverse engineering, but I'm really interested and willing to learn.


funman, I just tried your tool on the file e200pa.bin (md5sum 12563ad71b25a1034cf2092d1e0218c4, from http://daniel.haxx.se/sansa/v2/e200/e200v203.01.16a.zip). The assertion on line 131 fails, because at 0x3C the file contains 00 50 00 00. It's the same in the 2nd block, at 0x23C there's also 00 50 00 00.

[edit]
argh, sorry, I didn't read the wiki page well enough.
I have attached a quick fix for the tool. Perhaps it could be done better, but it works.
[/edit]


cu
Tobi
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on July 31, 2008, 06:43:04 AM
Hi tobi,

thanks for interesting into this beast :)
It's the first time I do this also and I don't know ARM assembly, but like everything that can be learned ... :)

atomikpunk gathered a lot of info already, but more eyes on the firmware are welcome!
The reverse engineering is quite advanced but a few things are missing like access to the buttons.
Once this is done we can insert code which will run only if a button is pressed to avoid bricking the device.

The problem is that in the firmware there is a few room left, but yesterday we discussed with atomik_punk about that:
Some firmwares (like the clip) present padding blocks in this way:
The first DWORD is 0xdeadbeef and the following 0x1FC bytes are junk so we could probably insert code in there rather at the end of the firmware block.

I think I will test that tonight: put a magic string in a padding block and browse memory to find this string: if found, return immediately to the original firmware code, else sleep for 10 seconds or so.
<edit>
I couldn't wait for the night I tested it right away
So far we can address all the firmware file, not only the firmware block !!
Next step is put a big piece of code in a padding block and jump to it, then come back, but I feel reluctant ..
Maybe I could check that the code is the one I wanted before jumping (or branching if you prefer) with cmp ..
I attach the test.S I used with utils/AMS/hacking in rockbox's svn repository: of course you will have to edit the magic value (your firmware should be the same size). Don't forget to swap the bytes when you read them from xxd !
</edit>


Did you check utils/AMS/hacking in the rockbox subversion repo ?

If you want to discuss over msn/jabber send me your address in PM or /query funman on freenode

About your firmware, this is true that some have 0x00500000 at 0x3c (and +0x200 because the 2 first blocks are identical except for their first byte).

I just found such a firmware yesterday and corrected my code for that. I also added a check for the whole firmware checksum (the last DWORD of the file)

I have a fuze firmware which shows these bytes, however I have another fuze firmware which doesn't show them ... strange ;)

I attach an updated version of my prog with a Makefile, so you can run "make test" and it will check the assertions against all files in the directory which ends in bin or BIN (like sansa firmwares..)

thanks, see you
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: tobi-lu on July 31, 2008, 07:41:08 AM
The problem is that in the firmware there is a few room left, but yesterday we discussed with atomik_punk about that:
Some firmwares (like the clip) present padding blocks in this way:
The first DWORD is 0xdeadbeef and the following 0x1FC bytes are junk so we could probably insert code in there rather at the end of the firmware block.
OK, but will this work on other players but the clip? Well, let's see if it even works for the clip :)

I think I will test that tonight: put a magic string in a padding block and browse memory to find this string: if found, return immediately to the original firmware code, else sleep for 10 seconds or so.
Nice idea, looking forward to see your results!

Did you check utils/AMS/hacking in the rockbox subversion repo ?
Not yet, but I read about it. Have to look at it.


As for chatting: Where do you come from? You could update your profile with your local time (if it's not correct now) so it's easier to communicate ;)
But I don't have much time to spend on the sansas until saturday ~4pm (UTC+2h) ^^

cu
Tobi


(edit: typos)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on July 31, 2008, 09:56:33 AM
The problem is that in the firmware there is a few room left, but yesterday we discussed with atomik_punk about that:
Some firmwares (like the clip) present padding blocks in this way:
The first DWORD is 0xdeadbeef and the following 0x1FC bytes are junk so we could probably insert code in there rather at the end of the firmware block.
OK, but will this work on other players but the clip? Well, let's see if it even works for the clip :)

Well we have to try ^^
I suppose all firmwares will skip blocks which begin with 0xdeadbeef but on some firmwares they were bored enough to fill all the block with this pattern.

As for chatting: Where do you come from? You could update your profile with your local time (if it's not correct now) so it's easier to communicate ;)
But I don't have much time to spend on the sansas until saturday ~4pm (UTC+2h) ^^

Ok done, I'm UTC+2 also :)
I'm from France but atm I work in the Netherlands (where I got my sansa Clip 1GB FM)

See you
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: tobi-lu on July 31, 2008, 05:50:52 PM
Aah I didn't see your edit till now ^^ I've been watching here all the time for you to post some news...

So far we can address all the firmware file, not only the firmware block !!
That's great news! Fortunately, you didn't brick your player ;D

Maybe I could check that the code is the one I wanted before jumping (or branching if you prefer) with cmp ..
Well, if it is possible, why not... you don't want to produce a paperweight, do you? ;) So being careful is never wrong.


Thanks for the piece of code (test.txt).

Bye
Tobi

//edit:
Could you please explain this:
Quote from: funman
Don't forget to swap the bytes when you read them from xxd !
In your code, you use MAGICVAL = 0xcfcfcc92. What's the original value that you put inside the firmware file? (Why are there swapped bytes at all?)
And what do you mean by "xxd"?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on July 31, 2008, 06:12:03 PM
Aah I didn't see your edit till now ^^ I've been watching here all the time for you to post some news ;D

So far we can address all the firmware file, not only the firmware block !!
That's great news!

Well it needs double checking, because I tried putting some code to be executed in a padding block, and my checks failed.

The whole sleep loop is 5 instructions = 5 * 32 bits, so I decided to check each of the 5 words (which I knew) before branching to that offset, i.e.

if(instruction1==read_instruction1 && instruction2==read_instriction2 ...) jump_to_sleep();
boot_now();

but the clip was always booting immediately so it was not reading the correct code ...

I verified that I was reading at the file offset - 0x400 (firmware header) so I don't know what happened.

So I wanted to verify the 1st word: 0xdeadbeef, to be sure I was in the padding block.

Maybe I could check that the code is the one I wanted before jumping (or branching if you prefer) with cmp ..
Well, if it is possible, why not... you don't want to brick your player, do you? ;) So being careful is never wrong.

But I recompiled/upgraded too quickly and I miss something ....

the code ran was:
Code: [Select]

ldr r3, =0x30400
ldr r2, [r3] /* load the word we are checking */
ldr r1, =0x38100000 /* verify that it's a pointer to the OF (0x138) */
cmp r1,r2

beq boot1
### missing r1 assignement ### damn !!
b boot

boot1:
mov r1,#0x500000 /* ~ 5 seconds */
b boot

boot: /* sleep loop */
subs r1, r1, #1
bne boot

ldr pc, original_entry #jump to OF

I added the "b boot" because I was tired waiting for my sansa to boot but I forgot to fill r1 which holds the number of seconds to wait !!

It could be any 32 bits value, and according to echo `$((0xffffffff/0x500000*5))` I can wait for an hour or more before seeing my clip lcd screen enlight ...
I hope there isn't something like a watchdog timer which resets the device, will see tomorrow if it's bricked or not (else I will have to explore my room for the ticket).
<edit>It works !! It took more than one hour to boot but I got my Clip back and could put the original firmware on it, the adventure continue</edit>


Also I tried to not increase the firmware block size (there is code in mkasmboot to handle that but since all the firmware files I have seen have the same size, I prefer not to try...) so I had to comment some code ;)

If you want to experiment, be VERY careful because there is no easy way to recover your sansa (except with JTAG maybe..).

Something I looked into was to try to get some random bit and conditionally branch on OF when it's 1.
That way if your code is broken, you have 1 chance out of 2 to boot the OF and update it.

I tried reading from the registers but my tests always gave the same value (maybe there is some code ran before the sansa firmware which initializes them, or they are initialized when the hardware is powered, I don't know)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: tobi-lu on July 31, 2008, 08:24:03 PM
Hi!

I just don't manage to get a successful cmp, my e250 always waits 5secs before starting.

This is what i have done:


Can you tell me ehat I am doing wrong?

Thanks
Tobi
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: daniel_at on August 01, 2008, 02:56:17 AM
Hey guys!

Cool to see some FW-hackers starting to get it started here. I'am not that used to ARM's and that stuff. But if someone wants to try a live session via IM with me, I am able to try various stuff on my E280 - because I can reliable unbrick it, if something went wrong. (As described in my earlier posts)
So testing new code could be faster and less nerve-racking.

My timezone is MESZ (UTC+2) and im quite often online... just conntact me via PM, than we can exchange IM-addresses (prefered Jabber).

Daniel
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on August 01, 2008, 03:03:28 AM
  • Edit firmware file at address 0xEFFFF8 to say 74 6F 62 69 (the value i've chosen)
  • Now here comes the problem: what should I write into MAGICVAL? According to what you told me in jabber, it should be 0xf6479626. But that doesn't work, I have to wait 5 sec...

The ARM CPU is little endian, so when you read a value from memory, the bytes are read in a
"reverse order" : least significant byte first.

When you edit the file with an hex editor your will see 74 6F 62 69
But the value (MAGICVAL) is 69 62 6F 74

Tell us if that works :)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: tobi-lu on August 01, 2008, 03:52:21 AM
Well, I've tried it, and also tried to put the magic value to another position in the file...
But it didn't work :(

daniel_at, can you please try this on your e280? Should be the same as with my e250, but who knows ^^
And have you seen my pm? If it didn't arrive for some reason, you can also find my jabber id in my profile (under YIM).


bye
Tobi


//edit:
I've been experimenting quite a lot now... My result is that it's NOT possible to access anything outside the firmware block using this method. The very last thing I can access is the 00 00 00 00 at 0x1DE18, which is right at the beginning of the first library.
I think the library starts exactly at 0x1de1c, and not at 0x1de00 as calculated by 0x400 + 0x200 * firmware_size_multiplier.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on August 01, 2008, 08:33:12 AM
I've been experimenting quite a lot now... My result is that it's NOT possible to access anything outside the firmware block using this method. The very last thing I can access is the 00 00 00 00 at 0x1DE18, which is right at the beginning of the first library.
I think the library starts exactly at 0x1de1c, and not at 0x1de00 as calculated by 0x400 + 0x200 * firmware_size_multiplier.

Maybe it is possible on the CLIP and not on other models, I will test again this evening to be sure I didn't misinterpret the results.

I don't understand well what you mean : from 0x1de00 to 0x1de18 (well - 0x400) you can see:
0x38220100 0x00000d30 0x70220e30 .. etc ?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: tobi-lu on August 01, 2008, 08:44:33 AM
I don't understand well what you mean : from 0x1de00 to 0x1de18 (well - 0x400) you can see:
0x38220100 0x00000d30 0x70220e30 .. etc ?
I came to the conclusion that 0x1de1b still belongs to the firmware, because when i used the 00 00 00 00 as magicval and 0x1de18 - 0x400 = 0x1da18 as magicoff, i didn't have to wait 5sec. When i used the next word, i had to wait, so it couldn't be accessed.

But I could be wrong here...
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on August 01, 2008, 09:18:31 AM
Hi,

great job guys :)

Maybe it would be wise that everyone share which firmware version their working on so to be clear...

Tobi-lu, did you try to read those just before 0x1de18? Something like 0x1de14?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on August 01, 2008, 11:02:44 AM
Tobi that value could also be 0x00000000 for other reasons
Try checking 3 or more consecutive values to be sure

I am using only the CLIP 01.01.29 firmware for now, I pasted the link to download it on anythingbutipod.

EDIT:
I tried again reading past the firmware block and my tests failed, I tried with the .S file I posted here so I think I was very tired and imagined that the test had succeeded :/

NEWS:
atomic_punk has likely found the function for scanning keypad:
The function is at 0x32B4 (+0x400) on the m200 firmware of atomik_punk
A very similar function is at 0x35CC (+0x400) on my clip firmware

Unfortunately we couldn't find one on the e200 firmware of daniel_at, this is sad because he has the hability to recover from bricked state ;)

See you soon for updates ;)

EDIT2:
As discussed with the hackers, it would be wise to execute our code after some stuff has been initialized.

EDIT3: /!\ DO NOT USE /!\ I HAVE BRICKED MY CLIP /!\

The firmware works this way currently:
0x0 LDR PC, somewhere
0xsomewhere LDR PC, do_stuff
0xdo_stuff
....
0xOFFSET1 BL main


The current mkamsboot.c will replace the code at 0x0 by LDR PC, OUR_CODE, and make the last instruction of OUR_CODE be LDR PC, somewhere, so it branches back to the OF.

I modified mkamsboot.c to do this:
at OFFSET1 it becomes LDR PC, OUR_CODE
and the last instruction of OUR_CODE be BL main

WARNING WARNING
The code executed at theorical offset 0xdo_stuff has hardcoded absolute offsets to the end of firmware, so the code you put in here will be modified before it is ran.
It's an efficient way to brick your Sansa, just like I did


I attach the patch to utils/AMS/hacking/mkamsboot.c
EDIT: use a correct mask when writing the relative offset of BL instruction.

Note: this is experimental code (and NOT TESTED yet on the Sansa), it assumes that there is a BL instruction just after our 1st jump, and wil read all the firmware to find one.

Your test.S file must begin with an instruction, not with .word 0.


Also I took the conversion code to translate instructions in utils/disassembler/arm/disasm_arm.c but I may have forgotten something, so double check with a disassembler that your new firmware does what you want !!

Now to you hackers to write some wise code to be executed :P
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: tobi-lu on August 02, 2008, 03:15:53 AM
OK I just read this a few times, now I think I understand what you have done with mkamsboot.

But what do you mean by this:
Also I took the conversion code to translate instructions in utils/disassembler/arm/disasm_arm.c
What's the purpose of disasm_arm.c? And what did you use it for?

As discussed with the hackers, it would be wise to execute our code after some stuff has been initialized.
Do you think you can access other parts of the firmware file then? Or access the buttons easier?
Hm, I'd like to understand it, could someone perhaps send me a chatlog?


Thanks
Tobi
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on August 02, 2008, 05:57:55 AM
Also I took the conversion code to translate instructions in utils/disassembler/arm/disasm_arm.c
What's the purpose of disasm_arm.c? And what did you use it for?

Well it's an ARM disassembler, I used it to modify the instructions / offsets.
Ex: +       jump = 0xEB000000 /* BL */ | (((bl_offset - (firmware_size + bootloader_size - 4) - 8 ) >> 2) & 0x08ffffff);
0xE0000000 is the condition: no condition
0x0B000000 is the instruction: BL (== CALL in i386 asm)
The last 3 bytes are the relative offset we jump to.

NOTE: I just found a bug: the offset mask should be 0x00ffffff not 0x08ffffff : this is why disassembling the patched firmware before putting it on the Sansa is important !! I will change the patch.

Also I forgot to mention that my code assumes there is no offset at the beginning of test.S, it replaces the instructions directly with relative offset.

As discussed with the hackers, it would be wise to execute our code after some stuff has been initialized.
Do you think you can access other parts of the firmware file then? Or access the buttons easier?
Hm, I'd like to understand it, could someone perhaps send me a chatlog?
I don't have the log, but according to atomik_punk the code before the first BL will setup the stack, and let us call various functions of the OF (to access buttons, exactly).
Of course it would be better to test that code on daniel's e200 since he has a recovery mode :)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: tobi-lu on August 02, 2008, 11:00:17 AM
So the next step would be to write some code that checks for a pressed button and goes to the delay loop if it isn't pressed.

But you (atomikpunk) haven't yet found the button handling code in the e200 firmware, right?


Anyway, this idea sounds rather promising to me :)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on August 03, 2008, 09:48:53 AM
Hi all

I am still on the process on trying to unbrick my Sansa Clip, and I found the special mode mentioned by Daniel_at.

However just like atomik_punk and his m200, on the Clip you will see a 0MB partition.
Probably Sansa didn't allocate any space for this feature on some models.

Since I unsoldered the battery, the Clip is always off unless plugged on USB, so I assume it works only with device off:

1/ Bridge the PIN 17 & 18 of the NAND flash (ALE & WE# according to this standard: http://www.onfi.org/docs/ONFI_1_0_Gold.pdf

I also read http://s1mp3.org/en/docs_deadrec.php, mentioned in this thread, and bridging IO pins also work.

It looks like a generic way to enter recovery mode, not only for Sansa ;)

2/ Plug the Clip on USB
3/ Notice a new 0MB hard disk detected
4/ ???
5/ No profit since the Clip is still bricked ;)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: daniel_at on August 06, 2008, 04:38:17 AM
Hi all (but mostly Atomikpunk)

As you were searching for a function which loads data from the flash into ram, i had following Idea:
Because I found only one reference to the NAND_FASH-registers in the OF-Loader and further we know (USB ID and other stuff) that the AMS-SoC has a Sansa-specific PROM-Code and that the Loader in the PROM must already fetch data from the Flash, it is very likely that the Flash will be initialized by the PROM-Code.

Further it is possible to map the PROM into the Address Space, but according to the docu only starting from Addr. 0x00000000 - but maybe it is possible to "rewire" that, when Sansa build theire specific PROM-Mask.
Therefor, maybe we _cant_  find the function read_flash in the Flash-based fw-part, but it calls that function on some specific address which gets mapped into PROM.

Just a random thought.... If you happend to find some calls to addresses which look suspicous, it might be some kind of that...

Daniel
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on August 08, 2008, 11:58:20 PM
Nothing much today except from that I'm pretty sure the LCD controller in the E200v2 devices is an ILI9222. I updated the E200v2 wiki page (http://www.rockbox.org/twiki/bin/view/Main/SansaE200v2) to reflect this. Still looking at the GPIOs for hints on buttons...
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Bagder on August 12, 2008, 04:17:40 PM
Hello!

Thanks to friendly people out there, I've got a bunch of more firmware images files for Sansa v2 players and they're now so many I decided to make a separate page listing all of them:

http://daniel.haxx.se/sansa/v2fw.html

Enjoy!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: dataangel on August 19, 2008, 08:10:40 PM
I'm very interested in helping getting rockbox running on my e280v2. I've been hacking C++ for years (and recently made the new dualnback plugin you can get on flyspray) but have never done any embedded stuff and never worked with ARM assembly. Is there anything I can help hack on? I'd prefer not to do anything that could brick my player but I'd gladly run any reporting utilities or if there is any coding that doesn't require a ton of ARM knowledge :)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on August 20, 2008, 10:05:48 PM
Yay, finally got my sansa v2: a 1gb clip ;D

Now let's get back to work folks...
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Sai_Deschain on August 21, 2008, 01:07:59 AM
hey folks!

First I want to say thanks for all the work you've done!
I've got a sansa e260 yesterday, of course a v2 model, and i'd really like to get rockbox running on it. i NEED it to scrobble. I haven't done anything like this before, but in school and at work i did programming in C, C++, C#, Java, Assembler, ... If there are any smaller implementing works to do, feel free to ask ;)

ICQ # 399399688  or any other messanger which pidgin/adium is able to do
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: notlistening on August 21, 2008, 06:10:21 PM
Heya all,


Got a Sansa 280 v2 not done a image yet but will ASAP. I am a Real Time Systems developer with c, VHDL, FPGA, assembler, linux driver experience etc etc UK based. Lost about 80% of my vision in 2005 and I am trying to put the remaining 20% into good use.

Please contact me at thomaslloyd82 at hotmail.com MSN if you think i might be of use. I am a little rusty but with a bit of ARM assembelly I think i'll get going again.

Tom
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on August 21, 2008, 07:35:47 PM
Please contact me at thomaslloyd82 at hotmail.com MSN if you think i might be of use. I am a little rusty but with a bit of ARM assembelly I think i'll get going again.


If this is your way of saying you'd like to help, I don't think its a very good way to do it.  Theres no organization here, its just people exchanging ideas and code.  Better to dig into the problem and then post once you have something to contribute.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on August 21, 2008, 08:09:41 PM
I've removed 5 pages of old posts from this thread that didn't have any useful info in them.  Hopefully this should make the volume of information here more manageable for people just joining in.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: notlistening on August 22, 2008, 03:49:25 AM
Humm,

Thanks for the frosty reception, I will go off into my own little bubble and probably duplicate someone elses work.

I will check back when I've got rockbox working. Just wanted to say hi to some of the people that are working on the same project.

Quote
Llorean POSTING IN THIS FORUM « on: August 21, 2006, 03:44:51 AM » 

--------------------------------------------------------------------------------

Before posting in this forum, search (the button is at the top of the forum screen) for a topic regarding the player you're interested in.

One thread per player. This is not for requesting ports to players. This is for discussion of working on them. If there is no post for your player of interest, you may start a thread. But discussion should then be of what is necessary to make the port happen, not "how great it would be" to have that port. As well, do not post simply to ask how a port is progressing. That will be considered disruptive, as it is unnecessary.

I believe that i followed the posting guidelines, correct me if I am wrong.

Oh yeah I am actively helping out now!

T
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on August 22, 2008, 07:12:28 AM
Hi everyone, and especially you newcomers,

I'm glad you joined the fun and have interest in a sansa v2 port. Please be sure to read this entire thread and the multiple pages on the sansa players on the wiki. I know it can't be quite harsh at first, but every captured knowledge is there. You can also send me a private message so we could share jabber (or other IM) IDs.

We already have some work done, both hardware and software. Some of it is documented but some is not too and we intend to improve on that "knowledge capture" part, mostly with the wiki but other suggestions are always welcome.

Our work should be first concentrated on:

If you need help starting up, please contact me I'll share some thoughts and techniques.

Welcome aboard.


As a side note, I said earlier that I got my v2, but I fact I got _2_ fully working clips at hand now so I'm ready to rock (pun intended).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: fml2 on August 23, 2008, 08:39:13 AM
Hello atomikpunk and others.

Could you please put somewhere for download the assembly text of the firmware you're trying to understand? If possible, with the comments to the things that have already been found out. I'm not an expert in assembly language but this would be a good chance for me to learn it and to (maybe) contribute to the porting of RockBox to Sansa v2.

Of course, if doing so is illegal for some reasons do not do it! (but let me know that it's illegal)

Thanks!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on August 23, 2008, 10:32:40 AM
Hi,

In my opinion it is legal to disassemble a firmware for research practices, but not redistribute copy/pasted code from reverse engineering. Depending from where you live the situation may be different, hire a lawyer for more details ;)

I have a commented disassembly for ida pro of a m200 firmware, but atomicpunk's one may be more up to date :)

++
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: notlistening on August 23, 2008, 11:35:37 AM
Hi All,

Just started gathering all the information from the forums into the wiki. If you have any files that require online storage please send me a PM as I am creating a share on MSN skydrive giving us about 5gb to play with. To be given access to add files please MSN or PM me a msn ID.

Any forwarded attatchments by e-mail will be put online when I have the chance. I want to create a one stop share for all resouces. Any feedback or suggestions would be appreciated.

sansadev@hotmail.com

Not setup a file structure yer but will do this as needs be.

https://cid-b1e4fc71fbc55227.skydrive.live.com/home.aspx This is an example of the share.

ATM there is full read rights for everyone and limited access to add/modify.

Tom
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on August 25, 2008, 11:40:16 AM
Hi again,

Well I'm not too sure about legality of publicly sharing disassembled code and such stuff so I think we should stay on the safe side and keep those for ourselves. But be sure I'd be happy to share our knowledge  with those interested in helping out. Simply contact me in private and we'll talk about this.

I didn't play long yesterday but I think I may have found something vaguely similar to a resemblance of an hold button handling stuff in the firmware ;) On the clip, I think it may look like something similar to pin 3 on port A ;) If that's the case, it would be nice because it would be very simple to read (activate the GPIO module, put the pin in the "input" direction and read it!)

I'll look more closely and try to find something similar in the e200 firmware so that Daniel could safely try it.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Llorean on August 25, 2008, 11:41:20 AM
Yes, if you're disassembling the original firmware, it still falls under any restrictions it was distributed under which usually means nobody else can redistribute it.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on August 25, 2008, 12:13:41 PM
You could probably distribute a diff against a dissassembly of the OF however.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: fragilematter on August 28, 2008, 01:52:36 PM
Hey people!

Funman, you said bridging the nand pins made a 0MB partition detected. Because my arm assembly is especially lacking (general assembly too - I only studied mmix assembly on an emulator this year at university), I tried to find out what the partition might contain on my e250v2.

Since I don't use windows, no 0Mb disk was detected, but I could see that the sansa is connected with lsusb. The connection worked both in ehci mode (usb2.0 - hi-speed) and in uhci mode (usb 1.1 - full speed) and the sansa's leds and screen stayed off.

I was able to dump (using dd) 119MB of data for several times, but each time it ended with a I/O error and the sansa disconnected. The dump is similar to the OF (e200pF.bin, version 3.01.16), with only some bytes missing or blocks displaced.
dd's output is this:
Code: [Select]
dodo@dodo-laptop:/media/data$ sudo dd if=/dev/sdb of=sansa4.bin
dd: reading `/dev/sdb': Input/output error
232160+0 records in
232160+0 records out
118865920 bytes (119 MB) copied, 244.232 s, 487 kB/s
If I tried to run lsusb immediately after, it hanged for a while (about 10 seconds - probably it was still trying to communicate with the sansa) and then displayed the devices - no sansa. Unplugging and repeating the whole short pins + connect usb algorithm made it reconnect every time.

Also, I was edited the dump and wrote it back. dd completed successfully, and the changes where permanent (and, thankfully, my sansa still works):
Code: [Select]
dodo@dodo-laptop:/media/data$ sudo dd if=copy\ of\ sansa4.bin of=/dev/sdb
232160+0 records in
232160+0 records out
118865920 bytes (119 MB) copied, 563.092 s, 211 kB/s

I've uploaded the results of my poking around (images, the dump and utils output) here: http://drop.io/sansahack. So you could try moving data to and from that disk ignoring its size, maybe you get your clip working again ;)

Thanks for the great progresses made so far thread, and I hope we'll see rockbox running on this quite powerful device!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on August 28, 2008, 04:11:06 PM
Welcome fragilematter

When you look in dmesg output you should see the size of the mass storage device detected, in my case it is 0 so I can not do anything.

I tried writing to the device anyway, but it failed.
I tried reading (limited to 512 bytes maximum), plus the data was never the same each time I read it (with a new processus)..
I quickly noticed it was my own memory I was viewing (I could see Firefox strings), that means I can't not read/write ANYTHING from the device; the recovery mode is then completely useless ...

I'll try download your dump when I have a decent connection, hopefully we can make room for our own code there.

If you can run some tests that'd be great, since you are in the elite of e200v2 owners for having a recovery mode ;)
The e200 have one, the m200 and clip (m300) have none, maybe it was not allocated at factory time, because every SoC has this functionality built in.

Good luck
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: fragilematter on August 28, 2008, 05:14:30 PM
Ouch, I'm sad to hear that  :-[

You mentioned dmesg, and I did a quick check:
Code: [Select]
[12070.741776] usb 3-2: new full speed USB device using uhci_hcd and address 13
[12070.908282] usb 3-2: configuration #1 chosen from 1 choice
[12070.936456] scsi12 : SCSI emulation for USB Mass Storage devices
[ 4822.719062] usb-storage: device found at 13
[ 4822.719067] usb-storage: waiting for device to settle before scanning
[12076.730961] usb-storage: device scan complete
[12076.733961] scsi 12:0:0:0: Direct-Access     UNDEF    storage          1.0  PQ: 0 ANSI: 0
[12076.736952] scsi 12:0:0:1: Direct-Access     UNDEF    storage          1.0  PQ: 0 ANSI: 0
[12076.751909] sd 12:0:0:0: [sdb] 2006528 512-byte hardware sectors (1027 MB)
[12076.754904] sd 12:0:0:0: [sdb] Write Protect is off
[12076.754912] sd 12:0:0:0: [sdb] Mode Sense: 00 00 00 00
[12076.754917] sd 12:0:0:0: [sdb] Assuming drive cache: write through
[12076.765897] sd 12:0:0:0: [sdb] 2006528 512-byte hardware sectors (1027 MB)
[12076.768893] sd 12:0:0:0: [sdb] Write Protect is off
[12076.768901] sd 12:0:0:0: [sdb] Mode Sense: 00 00 00 00
[12076.768905] sd 12:0:0:0: [sdb] Assuming drive cache: write through
[12076.768912]  sdb: unknown partition table

I also see the I/O errors.
Code: [Select]
[14054.706188] end_request: I/O error, dev sdb, sector 232128
[14054.706194] printk: 55 messages suppressed.
[14054.706199] Buffer I/O error on device sdb, logical block 29016
[14054.706210] Buffer I/O error on device sdb, logical block 29017
[14054.706216] Buffer I/O error on device sdb, logical block 29018
[14054.706221] Buffer I/O error on device sdb, logical block 29019
[14054.706227] Buffer I/O error on device sdb, logical block 29020
[14054.706232] Buffer I/O error on device sdb, logical block 29021
[14054.706238] Buffer I/O error on device sdb, logical block 29022
[14054.706243] Buffer I/O error on device sdb, logical block 29023
[14054.706249] Buffer I/O error on device sdb, logical block 29024
[14054.706254] Buffer I/O error on device sdb, logical block 29025
[14054.706339] sd 13:0:0:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
[14054.706347] end_request: I/O error, dev sdb, sector 232368

Just guesswork, but it might work if I try unbuffered transfers (although risky) or fire up my old workstation with usb 1.1 and check out what I can dig up.

Best wishes!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on August 28, 2008, 08:42:55 PM
Hi guys,

if you read earlier in this thread (if posts are still there), you will see that the e200 is the only model (so far) that we know has this special mode. Daniel_at discovered that mode but I and funman haven't been able to see it with both the m200 series and the clip series so we're guessing that this mode is only available on the e200 series (maybe the fuze?).

However, it is nice to see that someone else has been able to see this mode and that makes one more able to test custom firmwares ;D
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: fragilematter on August 29, 2008, 02:31:00 AM
The
Quote
(so far)
part is what I was counting on. It seems implausible that the m series and clips don't have a debricking method if the nand gets messed up, so maybe there is one, we just have to find it  :)
Anyways, I'm going to piece together an old PC, install some Linux distro and try to get a reliable connection to the sansa. I'll report back my finds.

Edit: I went ahead and tested and I still get only 119MB from the nand, but I'm figuring that it should be enough to dd a OF image in case things go wrong. I'll be around in case you have any code to test  8)

Cheers guys!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on August 29, 2008, 09:44:44 AM
It seems implausible that the m series and clips don't have a debricking method if the nand gets messed up, so maybe there is one, we just have to find it  :)

Well in fact there is one, we have a plain ol' JTAG port at hand in case something goes wrong... Which is in fact better than anything else for debugging and unbricking. The downside is people need to be able (and willing) to open their device, solder some wires, wire a JTAG to parallel port adapter and hack a bit.

But I doubt sandisk made effort to implement something else for the cost of those devices. In case something goes wrong, they replace the device and throw the defunct one on ebay :D

I have something I'd like to test on the e200 series. I think that GPIO pin A3 may be the hold button. you can try that if you are comfortable with arm assembly and disassembly tools, or I can build a test firmware if you prefer. You and/or Daniel could then test it on your e200.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: fragilematter on August 29, 2008, 10:05:27 AM
Well, basically I should configure the pin for input at base(0xC80B0000?!)+4, read it and load the read value into a register, compare it with what we are looking for and branch if equal to the code that should indicate the successful read.

Theoretically it shouldn't be too hard, practically I don't have any experience and you haven't said if you want the code to run before the jump to the OF or after the OF initializes everything. Drop me a test.s (or whatever code you want run and where you want it) and I'll test asap! :)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: philibuster on August 29, 2008, 02:18:13 PM
Clip is on woot right now for 19.99+5 shipping. Granted, it's the clip so it has the small ram, but hey, it works for hacking, right?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on August 29, 2008, 02:55:47 PM
fragilematter I checked the dump of your recovery partition and it contains the firmware, although it is a bit different:

After ~32MB the firmware is not validated by my tool, it might be because the real disk begin.
Which version of the firmware are you using? Is it available for download on the Sansa forums or anythingbutipod ?
Note: from ~17MB to ~32MB I see 0xdeadbeef padding, maybe we can insert code in this place ?

Can you modify the test.S / mkamsboot.c to use this offset instead of the end of the firmware block ?
You can calculate any offset in this area and modify mkamsboot.c to use your offset instead of reading the offset from the firmware file.

Also, the byte at offset 0x1FF is 0x46, on all other firmwares it is 0xFF, can you overwrite this byte to any value, and the corresponding byte at 0x3FF to the same value and see if the OF still boots ?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: fragilematter on August 29, 2008, 04:01:47 PM
Hey funman, thanks for taking the time to have a look at that stuff.
The firmware is e200pF.bin version 3.01.16, so it's the European version with FM - http://daniel.haxx.se/sansa/v2/e200/SansaE200_plusF3_01_16.7z. The last part of the dump (I haven't checked where it starts exactly) does appear to contain the music database, with file paths and tags, so it should be on the real disk.

Since it's midnight here (GMT+2), I'll work on it tomorrow as soon as I get the time. I'll try changing the bytes at 0x1FF and 0x3FF first and check the effects, than I'll go about modding mkamsboot :)

So, I'll check back tomorrow, hopefully with some results.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: notlistening on August 29, 2008, 09:53:38 PM
Hi all,

edit - how annoying double posting :P

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 :P 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
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: fragilematter on August 30, 2008, 03:50:40 AM
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
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on August 30, 2008, 07:34:27 AM
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!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: fragilematter on August 30, 2008, 08:48:45 AM
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).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on August 30, 2008, 08:57:36 AM
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 :'(
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: fragilematter on August 30, 2008, 09:12:43 AM
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!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on August 30, 2008, 09:40:29 AM
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)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on August 30, 2008, 11:11:03 AM
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 :)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on August 30, 2008, 11:17:12 AM
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
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on August 30, 2008, 11:29:52 AM
Re-read the register description :)

Quote from: datasheet
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.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: fragilematter on August 30, 2008, 12:29:03 PM
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.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on August 30, 2008, 12:54:45 PM
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
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: fragilematter on August 30, 2008, 01:06:49 PM
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!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on August 30, 2008, 01:13:58 PM
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 */
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: fragilematter on August 30, 2008, 01:17:05 PM
Thanks for looking :)
It's pretty late to do a "testing spree" today :D , but I'll try different offsets tomorrow and see if I get something :)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on August 30, 2008, 03:53:30 PM
I've found 2 other buttons for the Clip:

power is GPIOA_PIN7
list (or down) is GPIOB_PIN0
hold is GPIOA_PIN3

I tested the byte at  [GPIO_BASE, #(4 << PIN) ] for PIN: 0 -> 7

PIN        0        1      2      3        4      5     6      7
           __________________________________________
GPIOA | #0     #0   #0   HOLD #0   #0   USB  POWER
GPIOB | MENU #0   #0   #1    #1    #1   #1   #1
GPIOC | #1     #1   #0   #0    #0    #0   #1   #1/#0
GIPOD | #0     #0   #0   #0    #0    #0   #0   #0

Notes:
A6 is 1 when plugging usb
I tested C7 2 times and its value changed, maybe I did too much testing today, or the value has some meaning we don't know (FM?).

That means 7 buttons are still missing for the clip, and the mapping may change in each model

But I had an idea: in the diagnosis mode, there is a menu to test each button: if we can find in the firmware where is this special mode, we can hack around to find the code for buttons.

At least now we have a recovery mode for the clip, still a bit fragile but it's there ;)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on August 30, 2008, 10:47:55 PM
I guess those discoveries will pump a new hacking rage in here ;D

Tonight I did look at the display controller for the clip and I thin it might be a Solomon-Systech IC. The display itself seems to be an adelco UG-2864 and the display controller (from Solomon) might be in the family of the SSD1303. Well at least the documented commands from the datasheet looks like those I found in the firmware so that's looking good.

A display controller isn't necessarily need in a primary bootloader but it's a hell lot easier to develop when you can show some stuff on the screen :)

There's still something that tickles me: even though we found a way to read a button to select custom or original firmware, how can we tell that a broken custom firmware won't brick the device (until power off, battery discharged or something)? I mean, maybe the power off handling is done in the firmware itself, no?

Well I'll think about it in my sleep ;)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: fragilematter on August 31, 2008, 01:01:24 AM
I'm going to shave and then come back here and go about testing the e200v2's GPIOs. And probably I'll try to brick it with an infinite loop afterwards, because I know that in the OF, if it becomes unresponsive, you can hold the power button and after a few seconds it resets.

Edit: I've finished testing GPIOA:
Pin 0 1 2 3 4 5 6 7
Value#1#0#0USB#0#1#0#0

I will continue testing as soon as I'll have the time.

funman: GPIOC pin 1 is always #0
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on August 31, 2008, 10:36:49 PM
Isn't it nice to get visual feedback when hacking stuff, so I thought I'd share that pin D7 on the clip is the led driver on the button "ring", and this is verified ;D

Here's my (simple) test code:
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]

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

  /* Check its state */
  CMP   R2, #0

  /* Resume original firmware if hold is not active */
  BEQ   resume

  /* Make D7 an output */
  LDR   R2, =GPIOD_REG
  LDRB  R0, [R2, #0x400]
  ORR   R0, R0, #0x80
  STRB  R0, [R2, #0x400]

  /* Start by toggling off */
  MOV   R3, #0
  /* Let's toggle 8 times (4 on/off cycles) */
  MOV   R1, #0x8

loop1:
  /* toggle led on pin D7 */
  STRB  R3, [R2, #0x200]
  /* and prepare for next cycle */
  EOR   R3, R3, #0xFF

  /* approx 1/4 second delay */
  MOV   R0, #0x40000
loop2:
  SUBS  R0, R0, #1
  BNE   loop2

  /* Let's do 4 on/off cycles */
  SUBS  R1, R1, #1
  BNE   loop1
 
resume:
  /* Jump back and resume original firmware! */
  LDR   PC, OrigEntry

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

Owh and I thought I'd share that I did another test. I modified the above code to do 40 toggling of the led. This gave me plenty of time to try to turn off the clip while it was flashing. And the good news is that it works! I turned the clip on with hold active so that to branch to my test code. Seeing the led blink, I moved the hold/power button to the power position and about 0.5 to 1 second later, the led stopped flashing. The device indeed was turned off in the middle of my custom code! So that means that if by mistake we try some code that crashes, we should be able to simply turn off the device and reboot.

Simplified and in short, we finally found an easy and safe way to develop code on the sansa v2 ;D Maybe we should put it all together and develop some scripts to reduce mistake risks... Anyway, I'm not much the guy for that stuff, maybe someone else?

As of hacking, if I check items that should be our todo next list, maybe we should now head toward those points:
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: username on September 01, 2008, 02:38:43 AM
hi all,

first of all, thank you for your efforts to port rockbox to the sansa v2 series!
Unfortunately i cannnot help you to write code for the devices, but today i played around with my e260v2 and discovered some things.
i downloaded some v2 firmware images from daniel.haxx.se  and was very surprised to see that the md5sum for each version number is the same, regardless of the region code.

Quote
dave@haganah:~/sansae200v2fw/16$ md5sum *bin
12563ad71b25a1034cf2092d1e0218c4  e200pA.bin
12563ad71b25a1034cf2092d1e0218c4  e200pE.bin
12563ad71b25a1034cf2092d1e0218c4  e200pF.bin
12563ad71b25a1034cf2092d1e0218c4  e200pG.bin
12563ad71b25a1034cf2092d1e0218c4  e200pH.bin
12563ad71b25a1034cf2092d1e0218c4  e200pM.bin
12563ad71b25a1034cf2092d1e0218c4  e200pN.bin
12563ad71b25a1034cf2092d1e0218c4  e200pS.bin

so, if you rename e200pA.bin to e200pE.bin and copy it to the root directory of the device and unplug it, you end up with an update that installs the european version without the radio functionality. therefore, it seems that there is only one firmware for each version number.

furthermore, if you rename the firmware file to e200pT.bin and move it to / of the device, you can access the diagnosis mode (settings -> diagnosis) which lets you test the buttons, lcd, microphone and other funny things.

hope that helps, happy hacking!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Pampersrocker on September 01, 2008, 06:27:16 AM
with usernames discoverings I've found out that my e260v2 also have radio: I've just installed the e200pF firmware on my player and could listen to radio, so there'll may not be some differences between the v2 models...

sry for my English  :)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: username on September 01, 2008, 06:50:21 AM
i guess every e2x0v2 model has radio functionality. the reason why there are A and F versions is that in the A version you can select radio settings->fm region world, u.s. and japan, whereas the F version only has world but not japan. this is probably due to the fact that german (and maybe other european) authorities use some frequencies in the "japan fm region" for their communications.

nevertheless, i wonder why sansa sells devices in germany with have radio chips built-in but are disabled via firmware, although there is a firmware which excludes the frequency range which normal people are not supposed to listen.

hope not too off-topic.

Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: AlexP on September 01, 2008, 06:57:02 AM
nevertheless, i wonder why sansa sells devices in germany with have radio chips built-in but are disabled via firmware, although there is a firmware which excludes the frequency range which normal people are not supposed to listen.

Due to licensing costs in Europe - it costs more to sell a device with a radio as you have to pay for the licence for it.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: fragilematter on September 01, 2008, 07:15:31 AM
atomikpunk: when I tried to patch the firmware with the led blink code (just to see if it's there) I got a linker error:
Code: [Select]
arm-elf-ld -e 0 -o test.elf test.o
test.o: In function `loop2':
: undefined reference to `loop1'
make: *** [test.elf] Error 1

I'm thinking it has something to do with the fact that we have one loop inside another. I've got arm-elf-ld version 2.16.1.

As a side-note, I won't be able to test stuff until Wednesday, I've got some restant exams.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on September 01, 2008, 07:31:50 AM
atomikpunk: when I tried to patch the firmware with the led blink code (just to see if it's there) I got a linker error:
Code: [Select]
arm-elf-ld -e 0 -o test.elf test.o
test.o: In function `loop2':
: undefined reference to `loop1'
make: *** [test.elf] Error 1

I scratched my head this morning and linuxstb found the problem: comment line 33 is not terminated

EDIT:
fragilematter, you shouldn't try this code on the e200 because the GPIO mapping is different.
Instead you should reverse engineer the firmware to find the corresponding registers for your device.
/EDIT

by the way thanks you so much atomicpunk for this finding, this is much better to look for light rather than count the seconds ...

I have written a pattern search test, and tested 2 library blocks: usb_functio and otg_functio, and they are not loaded at their base address, neither when I boot the Clip by usb.

After work I will look for patterns in the FAT32 partition, maybe the NAND is enabled and mapped at boot ? Somehow I doubt it but it's worth a try
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: fragilematter on September 01, 2008, 07:39:31 AM
Okay, the led pin is the same on e200v2's also, it blinks them quite nicely. The only difference is that A3 is USB, not hold, so it only triggers when you start the sansa by plugging it into a usb port.

Anyhow, great finding, it will make my life easier as I'll test the other GPIOs.

Edit: funman, thanks for the warning, but it seems I was lucky. Anyhow, even if it went bad, I've got nand access to recover it ;)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on September 01, 2008, 07:45:23 AM
Hi peeps,

hehe sorry I may have added the comments after compiling the code, my fault :)

Yes funman, there seem to be a library loading routine somewhere in the firmware block. I don't fully understand it yet but it is pretty that this routine loads a library block somewhere into RAM. I'll have a closer look and see if I can understand the flash mapping. It seems that the flash is directly accessed in the CPU memory map, not using the dedicated AMS3525 NAND interface(?).

But if you can find how to directly access the filesystem that would be THE finding of the day as we could load anything we want and would not be limited by the firmware size anymore :)

Edit: be careful when trying to output to GPIO pins, most should be safe but we don't know how they are connected and putting a 1 or 0 to a pin that isn't supposed to be driven this way could damage circuitry...
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on September 01, 2008, 11:46:24 AM
Hola fellow supporters of sansaV2 port :)

Some more informations today:

The library memory mappings overlap with each other.
I loaded acp_decoder and mp3_decoder and they shared a common area, that means only one can be loaded at a time.

That seems logic considering the small amount of RAM on the clip: 2Mbits

While writting a pattern search, I came on big problem: my code was 2 instructions too long to fit in the firmware block.

I couldn't reduce it, so I had a look at other firmwares: the firmware v17 (instead of latest v29) has the biggest room for code:
The firmware fills up 0x28 bytes in the last 0x200 bytes block, that leaves us with 0xD8 (216) bytes

We'll leave with this while a e200 owner flashes a modified firmware with firmware block's size incremented by 0x200, and following blocks shifted by 0x200.
mkamsboot.c should do this for you, but you should check if modifying the whole file size is ok, or if you have to remove 0x200 bytes from the end of the file (I'm not sure if it's padding or not)

For pattern testing, I want the device to do an infinite loop into 2 different states:
1 which blinks the led for ever
1 which lights the led; and do an infinite loop

light on / light blinking is our boolean for pattern found / not found; but I have trouble leaving the LED on.
I'll probably get some fresh air and return to it ;)

See you
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: fragilematter on September 01, 2008, 12:04:17 PM
Well, you could probably engineer a image that I could dd directly to my e200v2 if space is a problem. I don't know how much we can assume that the code form the clips is similar to the e200s, the led was a lucky break.

Oh, and the firmware image and bridging the pads definitely works, I've managed to guide sucitrams into repairing his sansa by dd-ing the first ~30MB from my dump. He reported that his sansa wasn't doing anything that indicated it was running, and we got it to work again from the first try.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on September 01, 2008, 12:35:35 PM
If you can flash and recovery anything using the pad trick, maybe its time to think about replacing the OF with a simple bootloader.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on September 01, 2008, 01:51:17 PM
I am still looking at how to read from the NAND.
I had a look at the AMS3525 datasheet and firmware/target/arm/ata-nand-telechips.c but I'm not sure how to do that.

So far I suppose there is no direct mapping of the NAND into memory, and we have to issue commands to the nand.
I found the register to read unbuffered data from the ram (NAFDATA), but not how to set from which address we want to read.

EDIT: in fact we have a 16 bit register from where to read / write,
so we first use the command 0x0 (READ)
then write the columns of the memory address we want to read from,
then the rows
then we use the command 0x30 (READ, part 2),
then when the nand signals us it's ready, we read from this 16 bits register.

Hint: keep the ONFI specification handy

EDIT2:
fragilematter to generate a bigger firmware, you can modify mkamsboot.c:
line 185, replace
Code: [Select]
new_paddedsize = PAD_TO_BOUNDARY(firmware_size + bootloader_size);by
Code: [Select]
new_paddedsize = PAD_TO_BOUNDARY(firmware_size + bootloader_size) + 0x200;
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on September 01, 2008, 06:26:15 PM
I just wanted to remind you guys on this task: http://www.rockbox.org/tracker/task/8843

The file contains a lot of code already (and thus information).

E.g. much of NAND driver work.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on September 01, 2008, 09:28:21 PM
I had an idea tonight but didn't have time to implement it yet. We said we could increase the firmware block size and use this to put some more code, but why not insert our code in a low usage library block? For example on the clip, the first library block uses 0x12270 bytes out of 0x28000 allocated library block bytes. That leave's us 0x15D90, or in decimal for humans like I think I am: 89488 bytes. I think that ~90k is more than enough to pour in a bootloader ;D

The only catch is the fact we will need to load it into RAM before being able to actually use it, but hey, a library loading routine should be way smaller than a FAT-on-a-NAND library loading routine(s).

kugel: thanks for the reminder, I did take a look a long time ago but now it is much more pertinent :)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on September 02, 2008, 08:09:40 AM
I think this idea came up earler and was rejected for 2 reasons:

I'd reduce capabilities to use the OF (we don't want to destroy the OF, but rather replace it and offer dual boot)
We would boot in a state where the OF already initialized the/some hardware. Booting Rockbox in such a state would make it dependent on the OF and possibly lead to unexpected behavior.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on September 02, 2008, 08:41:32 AM
I'm sorry maybe I wasn't clear enough in my post. What I meant is to use "unused" library space in the firmware file (space filled up with 0xFF or DEADBEEF-padded junk) to put in our code. This wouldn't change anything in the OF since, to my (limited) knowledge, this space is simply not loaded at all by the firmware.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on September 02, 2008, 09:03:55 AM
You said "low usage", not unused. And even if there's an unused part, the second problem is still there. You want to boot into an environment prepared for another piece of software.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on September 02, 2008, 09:49:52 AM
Well I showed calculation of the unused space in a particular library block so I thought it was obvious I wasn't thinking about overwriting the OF code ::)

As for the "prepared environment", I don't see why we wouldn't be able to do so, in the first or second "stage" of our bootloader ???
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Bagder on September 02, 2008, 10:21:08 AM
As for the "prepared environment", I don't see why we wouldn't be able to do so, in the first or second "stage" of our bootloader ???

I agree and this is done on a few other targets with success. If we do this for a known OF version we can learn what it sets up for us and not.

And of course over time we make the Rockbox code setup things as good as possible on its own so that we get less and less reliable on the OF init.

Either way, there's nothing saying that a first "ugly" approach can't be done first to get something going and then it can be improved later on. Iterative development is the key to success.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on September 02, 2008, 10:52:27 AM
I don't understand in which way you want to do it:

- In the bootloader insert a call to the routine which loads library blocks in memory, and then branch to that location.
- In a studied library block, insert a branch in the same way we do it for now in OF with mkamsboot, which will branch to the code we inserted at the end (in the padding)
- Voodoo
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on September 02, 2008, 11:58:12 AM
Ok maybe I wasn't clear at all after all, so here are my thoughts on this.


Using this approach we don't rely at all on the OF be it for initialization or anything else because anyway, I don't think they anything we can't do! :)

There is a bit of development to do to get there, but nothing huge and in fact it can be quite easy and straightforward...

First stage bootloader
The first stage would be located in the firmware block, after the used part (that is after the code and the variable initialization sections). It needs to be as small as possible to fit every possible OF files. If we find out that we can increase the firmware block size, then we are in luck. If not, we may need an alternative location for that. I assume that we will a) have enough space in the OF file without modification, or b) we will be able to increase the firmware block size.

Its job is:

Second stage bootloader
It would be located in a library block with enough free/unused space to hold it. The best place to put it would be in the "DEADBEEF" area, which is in fact junk in the clip firmware. (reminder: each library block contains: a header, a code section, a variable initialization section, 0xFF padding up to the next 0x200 border, DEADBEEF padding up to the end of the library block). Once loaded into RAM, the first stage bootloader jumps to it.

Its job is:
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on September 02, 2008, 12:47:37 PM
Quote from: atomikpunk link=topic=14064.msg133624#msg133624 date=1220374692
[b
First stage bootloader[/b]
The first stage would be located in the firmware block, after the used part (that is after the code and the variable initialization sections). It needs to be as small as possible to fit every possible OF files. If we find out that we can increase the firmware block size, then we are in luck. If not, we may need an alternative location for that. I assume that we will a) have enough space in the OF file without modification, or b) we will be able to increase the firmware block size.

Its job is:
  • Intercept a particular signal (a button or something), and if not set, boot back to the OF (its job end up here in this case)
  • Find (or maybe it should already know) the second stage bootloader
  • Copy it from ROM to RAM

At boot we suppose ROM is mapped at 0x0, and we earlier confirmed that we can not read past the firmware block (at least this not the direct continuation of the firmware file)

So we first need to extend the firmware block, and as far as I know this has never been tried.

My theory is that you simply can not read from the library blocks, because they are loaded on-demand, and no one is ever loaded forever.
If it was the case, then the code would be a part of the firmware block.

We can suppose the library blocks are relocatable (because the code use addresses to the mapping of the block in RAM; which is absolute).
But the firmware block may have absolute offsets to the library blocks, even if we don't see a cross reference into a disassembler.

I expect fragile_matter to flash an extended firmware (by 0x200, then BOOTLOADER_STAGE2_SIZE) and tell us if he still can boot the OF and use it, and tell us the results.

Last note: ROM is 1Mbit (128kB), the one I use (firmware v17) is 120kB, that's 8kB left for the bootloader, would it be enough ?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sucitrams on September 02, 2008, 01:08:04 PM
I expect fragile_matter to flash an extended firmware (by 0x200, then BOOTLOADER_STAGE2_SIZE) and tell us if he still can boot the OF and use it, and tell us the results.

I'm not fragile_matter, but I tried to extend the firmware by 0x200 simply by modifying the mkamsboot.c . Then I flashed it and was able to boot the OF, without errors etc.

This is maybe interesting: I flashed the player with the extended firmware, and plugged it back to the PC,  and the firmware file wasn't deleted, as usual.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on September 02, 2008, 01:12:06 PM
did the player display the message "upgrade completed" ?

also if you read the recovery partition, do you see your extended firmware, or the normal one ?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sucitrams on September 02, 2008, 01:18:23 PM
Sorry my fault.  :-\
The extended firmware wasnt flashed. The upgrade didn't complete.

EDIT: I tried to flash the extended Firmware directly onto Flash. The player started, but the Display was full of "damaged" pixels.

EDIT2: I think its over. Everytime i try to write to flash, there are "IO errors", and only 14MB could be written.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: fragilematter on September 02, 2008, 02:00:23 PM
sucitrams take care when dd-ing stuff directly not to damage the file system. On e200v2's, beyond 31,456,252 Bytes you have a fat header and the music database. Or, if you do write directly to the nand, back up the stuff you have stored on the player.

I'll be resuming almost full time on rockbox testing tomorrow afternoon (I'm still in vacation, I only have one restant exam tomorrow). Hopefully I'll be able to complete the GPIO tests by tomorrow night and also catch up on what's new here.

Edit: if you get write errors try to use a stable usb port (the ones at the back of the computer) and eventually try to use usb 1.1 (modprobe -r ehci_hcd if you don't have a machine with physical usb 1.1 ports).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sucitrams on September 02, 2008, 02:16:36 PM
dd says, that there is no space left. dmesg shows 1024MB.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: fragilematter on September 02, 2008, 02:22:20 PM
Maybe it's somehow connected to the fact that I can't read more than 113.4MB from my sansa. Either that or you've damaged your nand/usb controller or something else from your player.

Perhaps you could try this (it's not directly related but it might help): sometimes the sansa lags when connected to the usb, and linux's usb stack keeps waiting for it. I found that it helps running a lsusb, it somehow makes the player to respond and connect properly to the usb.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on September 02, 2008, 02:35:01 PM
sucitrams you still have hope: the recovery mode is present.

leave it for one day or two, and try again to put the OF
Now at least we know that we must only use the recovery mode to put safe firmwares

In the meantime I attach a diff for mkamsboot.c which will keep the total file size, while shifting the content after the firmware block.

The firmware produced passes my various checks at being a normal firmware, but only testing will confirm if it's usable or not.

Note: the patch could be extended to reserve maximum size (128kB firmware block) and check for bootloader size, I will do that if this first patch works
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on September 02, 2008, 02:41:00 PM
Well I don't want to look like giving lessons or anything because I'm as curious as you guys, but I thought we would discuss the modified firmware before flashing it to a device :'(

Did you add a dummy 0x200 bytes and update the firmware header? If not, then the firmware can't do anything good... It looks for the library blocks 0x200 bytes earlier each time, which happen to be in the DEADBEEF area most of the time (if not all). So the firmware looks at a wrong header, which gives it wrong addresses where to load the data to, wrong addresses of executable routines, wrong addresses of variables, etc. So in short, the CPU writes about anything anywhere, which results in crashed player.

And if fact, I don't know if my memory fails me but I think I saw absolute routine addresses at some places in the firmware, so anything moved and bam...

However, if you still can load up the "recovery mode" with a firmware like this, it definitely confirms that this mode's code is located somewhere else than in the firmware and is good news. So I guess that with some work, the device should be unbrickable.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: fragilematter on September 02, 2008, 02:47:50 PM
I quickly tested the patched mkamsboot.c

The output was this:
Code: [Select]
gcc -o amsinfo -W -Wall amsinfo.c
gcc -o mkamsboot -W -Wall mkamsboot.c
arm-elf-as -o test.o test.S
test.S: Assembler messages:
test.S:0: Warning: end of file not at end of a line; newline inserted
arm-elf-ld -e 0 -o test.elf test.o
arm-elf-objcopy -O binary test.elf test.bin
./mkamsboot e200pF.bin test.bin patched.bin
Original firmware size - 0x0001d81c
Padded firmware size - 0x0001da00
Shifted by 1 blocks
Bootloader size - 0x00000074
New padded size - 0x0001da00
original firmware entry point: 0x00000128
New entry point: 0x0001d820

Flashed successfully, all the functionality is there (I didn't to a thorough test, but it seems OK) and the inserted test.s code also works.

I think sucitrams tried to directly dd a firmware update image to the nand, but, as I've shown earlier, the firmware update expands the firmware to 30MB, or at least it appears that way on my nand dumps.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on September 02, 2008, 03:13:18 PM
great !!!

Can you test this one which will allocate the biggest size possible (0x100 * 0x200 = 128KB) for the firmware block ?

If it's fine I'll test it on the Clip and ask someone to commit the patch

EDIT: attached corrected patch
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on September 02, 2008, 03:21:43 PM
Hey oh one second, the biggest possible should be 0xFF since the firmware header allocates 1 byte for the "firmware size" field... :)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: fragilematter on September 02, 2008, 03:23:32 PM
The output is this:
Code: [Select]
gcc -o amsinfo -W -Wall amsinfo.c
gcc -o mkamsboot -W -Wall mkamsboot.c
arm-elf-as -o test.o test.S
test.S: Assembler messages:
test.S:0: Warning: end of file not at end of a line; newline inserted
arm-elf-ld -e 0 -o test.elf test.o
arm-elf-objcopy -O binary test.elf test.bin
./mkamsboot e200pF.bin test.bin patched.bin
Original firmware size - 0x0001d81c
Padded firmware size - 0x00020000
New firmware size - 0x00020000
Bootloader size - 0x00000074
New padded size - 0x00020000
original firmware entry point: 0x00000128
New entry point: 0x0001d820

But, unfortunately, it still needs some work. The inserted code works ok, but the firmware freezes after completing the sansa logo animation.
It's almost midnight so I won't try to recover it now, it's time for me to get some sleep.

I'll check back tomorrow as soon as I get back home. Cheers!

atomikpunk: thanks for the try, but I was quicker :D
OTOH, holding the power button for a few seconds to power the e200 off works  even if the firmware is messed up.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on September 02, 2008, 03:28:52 PM
Hey oh one second, the biggest possible should be 0xFF since the firmware header allocates 1 byte for the "firmware size" field... :)
I would think it is rather 1 word, but it should be checked indeed.

Try using 0xFF as the new size instead of 0x100 (3 occurences) in the last patch,
or increase the shift value in the first patch.

Note: this should be tried on several firmware versions to ensure it works flawlessly.

fragilematter and sucitrams thanks for testing :)

EDIT: the patch was wrong, it wouldn't shift the library blocks (memmove() case not made, as show fragilematter's output). I updated it, can you retest?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on September 02, 2008, 08:24:29 PM
Maybe you are right, I did look back at the wiki to refresh my memory (no pun intended) and saw that this "multiplier" is aligned on a 4 bytes border, so it could indeed be a dword. But again, I'd have a look at the OF to see if there are hardcoded addresses that could be messed up with a displacement.

Another interesting test would be to know where the ROM is located in memory and if we can access library blocks directly from the at-boot CPU memory map or if we need to configure something before being able to do so...

Anyhow, that's it for tonight :)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: fragilematter on September 03, 2008, 06:02:39 AM
I restored the sansa (worked perfectly), then patched mkamsboot and tested. This is the output:
Code: [Select]
gcc -o amsinfo -W -Wall amsinfo.c
gcc -o mkamsboot -W -Wall mkamsboot.c
arm-elf-as -o test.o test.S
test.S: Assembler messages:
test.S:0: Warning: end of file not at end of a line; newline inserted
arm-elf-ld -e 0 -o test.elf test.o
arm-elf-objcopy -O binary test.elf test.bin
./mkamsboot e200pF.bin test.bin patched.bin
Original firmware size - 0x0001d81c
Padded firmware size - 0x0001da00
New firmware size - 0x00020000
Bootloader size - 0x00000074
New padded size - 0x00020000
Calling memmove(buf + 0x00020400,buf + 0x0001de00,0x00edfc00)
original firmware entry point: 0x00000128
New entry point: 0x0001d820

The firmware starts OK, our code works, but I can't see any text. Maybe the string addresses are hardcoded. I'll drop some screenshots on http://drop.io/sansahack as soon as i copy them from the camera.

Edit: after playing one song there probably was a write at a wrong address on the nand, because now I get corrupted graphics on the boot logo and then it locks up. After a few more starts and forced shutdowns it just lights the leds and the display illumination...
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sucitrams on September 03, 2008, 06:21:59 AM
@fragilematter:

Thats my problem too. I think we can forget it.  :(

EDIT: Now if I read out my NAND wit dd, dd stops at 14MB because of "readout errors". But I opened the firmware that was on the flash with a hex editor.
From 00000000 - 004FFEC7 everything is "00". But then the firmware begins.
I think my NAND is damaged, because many times I tried to delete the corrupted Firmware, /dev/zero, but its still there.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: fragilematter on September 03, 2008, 06:47:00 AM
Okay, I tried to restore it with the small image and it was writing everything correctly, but after unplugging and connecting it back to the usb it went into the recovery mode again. So I dd-ed the big (119MB) image I dumped the first time, and that solved the problem.

I think it wasn't booting because the fat was probably damaged, but I can't test my theory because I didn't think of making a dump of the bad firmware from the nand. And I wouldn't like to brick it again just to test that theory.

Guys, anytime you've got something else to test, I'm (and my sansa) still up for the job.

Sucitrams: I don't know what happened exactly to your e200, but I managed to restore mine 3 times by now, and I didn't encounter any write errors in the recovery mode. Don't try to zero the nand, I don't think that would be a very wise idea. Try to get to a usb 1.1 machine and dd the big image nicely. I'll look for a place to upload it and give you the link in a pm. I hope you'll be able to restore it :)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: andva on September 03, 2008, 07:04:10 AM
Try to get to a usb 1.1 machine and dd the big image nicely.

For the record, you can force Linux to use all devices in USB 1.1 mode by rmmod'ing the ehci-hcd module, so there is no need to hunt for an ancient machine.

Great job, guys!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: gevaerts on September 03, 2008, 07:05:41 AM
For the record, you can force Linux to use all devices in USB 1.1 mode by rmmod'ing the ehci-hcd module, so there is no need to hunt for an ancient machine.

You can do something similar on windows : disable the EHCI controller(s) in the device manager
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sucitrams on September 03, 2008, 10:22:31 AM
OK my Sansa is now working too.
I had to dd the original firmware (which is only 15MB in Size and not 30MB like the one dumped from Flash). I don't know why the NAND dump Firmware is always 30MB in Size, when you could also install the 15MB Firmware directly onto NAND.
But it seems, that my NAND has some bad sectors. Everytime at 14MB dd stops working, and said that there's no space left.
So I had to a "dd if=firmware of=/dev/sdb bs=512 count=27000", because Data will be only written, if dd don't break, because of IO Errors etc.
Then the Sansa started normally, but the fonts were missing. So i connected it to USB, copied the original Firmware onto the Sansa and installed it.
After that everything is fine (But I think  my Sansa's life is over, because of defect sectors).


I noticed, that if the NAND (seems) to be empty and you connect the Sansa to PC the "hidden" in my case 1024MB Partition will be active. So you could copy a firmware file directly onto NAND, without bridging the 2 Pins.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: fragilematter on September 03, 2008, 10:43:05 AM
The same thing happened to me today while trying to recover from the last flash test. When I connected the usb the sansa acted like the pins where bridged. But then I dd-ed the whole big dump and it worked perfectly.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on September 03, 2008, 11:41:17 AM
It definitely confirms that the bootloader loads an "emergency" mode when it doesn't find executable code in the flash/rom/whatever. And this can be done by flashing an empty firmware using recovery mode, or by shorting some flash chip pins :)

The next interesting test would be to check where is located the firmware in the CPU memory map and/or how library blocks are loaded into RAM.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on September 03, 2008, 11:53:19 AM
According to the datasheet, it would have to be at 0x8000_0000 to 0x8001_FFFF (or one of its aliases), since thats the only nonvolatile memory available when the NAND is shorted. 
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on September 03, 2008, 12:24:41 PM
Then the ROM is 128 kB, and the library blocks just can't fit.

The code to load them in RAM from the NAND is in the firmware block, and we must find it or reproduce its functionality.
When it's done no need to look in the library blocks, since we have access to the whole NAND and its FAT32 filesystem.

EDIT: I was looking in wrong places: I just found firmware/drivers/ata_flash.c which is what we need, I'll try to build it and make it fit in my firmware block.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on September 03, 2008, 12:44:28 PM
When it's done no need to look in the library blocks, since we have access to the whole NAND and its FAT32 filesystem.

Well it all depends on if we can grow the firmware size or if we can fit the NAND driver in the (little) space we have at the end of the firmware block... 'Cause I suspect it (the NAND driver) to be too large but that a library copy routine be small enough to fit in.

Or maybe there is something that's allows different ROM "pages" to be mapped in and out on demand?

funman: In the mail I sent you yesterday night, you should have the address of the library routine in the clip firmware, you may want to look at that...
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on September 03, 2008, 01:21:27 PM
I was more interested by the gpio function ;)

Now that I took a look at this function it looks like strcpy(), do I miss something ?

EDIT: sorry I was reading disassembly in thumb, and the function just branched to another offset which is strcpy, I'll disassemble it as 32 bits instructions.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: fragilematter on September 04, 2008, 04:24:40 AM
I've finally managed to map GPIOB on e200v2's. It looks like this:

Code: [Select]
GPIOB_pin0  #0
GPIOB_pin1  #1
GPIOB_pin2  #0
GPIOB_pin3  #0
GPIOB_pin4  power
GPIOB_pin5  #0
GPIOB_pin6  #0
GPIOB_pin7  #1

I was starting to think there was something wrong with the way I tested, because I didn't find any buttons by now, but it seems that it's OK. I'll post the rest of the GPIOs when I'll finish testing.

Edit:
Code: [Select]
GPIOC_pin0  #1
GPIOC_pin1  #0
GPIOC_pin2  #1
GPIOC_pin3  #1
GPIOC_pin4  #1
GPIOC_pin5  #1
GPIOC_pin6  #1
GPIOC_pin7  #0

The GPIOs that are !=0 are consistent with the ones identified as DBOP (LCD display) in the M200 V2 version 4.1.8a firmware analysis from the wiki (http://www.rockbox.org/twiki/bin/view/Main/SansaV2Firmware#GPIOs_Usage).

Edit2:
Code: [Select]
GPIOD_pin0  #1
GPIOD_pin1  #1
GPIOD_pin2  #1
GPIOD_pin3  #1
GPIOD_pin4  #1
GPIOD_pin5  #0
GPIOD_pin6  #0
GPIOD_pin7  #0

It looks like the e200v2's only have the power button directly on the GPIO. Either that or my tests were flawed somehow.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on September 04, 2008, 04:19:28 PM
Hi guys

I have found a way to extend the allowed size for the bootloader: use memory areas filled with the same word.
I quickly checked for 0x200 sized blocks, and only the Clip firmwares show 1 or 2, so you need to
verify that first.

EDIT:
I also attach a tool to check the size and location of the biggest memory area filled with the same byte, it seems there is room in every firmware :)

Also I attach a new version of test.S without a bug in button check: the result was stored in r2 but calling clean would modify it (luckily it didn't brick my clip)
/EDIT

We don't know if they are important for the OF, so we memset it before giving it the hand.

I attached test.S tested on Clip firmware v17, the size won is 0x3CC bytes where we can put functions, data, etc ..
Of course before doing that we have to map the RAM at 0x0 because at init only the ROM is mapped.

Note this is a bit hacky to use because you have to write separate assembly code, assemble it and merge it manually at the needed offset, and hardcode the offset/size/value in test.S ... but this will do for now.
Maybe we can modify mkamsboot/Makefile to assemble 2 different files, and look in the memory for a block large enough, then insert the value/size/address in known (by the assembly code) memory locations, like the original entry point is stored now.

By the way I'm still writing a basic driver for the NAND flash, but now I'm stuck on delays: we need to command the WE bit (write enable) and keep it high for minimum 50 ns
The interface for this bit in the AMS3525 is 4 bits which will keep it high for x+2 PCLK# cycles where x is the 4 bits value.

But I've read that the PCLK is 65Mhz, so that means keeping WE high for 17 cycles would last less 0.3 ns ..
I think we need to use a divider for the pclk, but a big divider means reduced CPU clock??

atomic punk: I have found the function which load library blocks; it takes 4 arguments: block name (string), base address, end address, size. But it was not at the same offset, maybe we are not reading the same firmware ?
I am disassembling v29 for Clip
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on September 04, 2008, 07:53:40 PM
Ok well I guess it's time for me to write :P

That's a good idea funman, I like. Even though it is risky, we now have at least one valid solution. I'm pretty sure that that needs to be set back to their original value giving the OF firmware the hand because they may be variable initialization values.

As for the button detection stuff, I strongly suggest that we don't make any change to it, at least for now. We wouldn't want to brick any more device, don't we?

For the NAND driver, I would reiterate what kugel said about that task on the bug tracker (http://www.rockbox.org/tracker/task/8843). Most of the NAND driver should be there, ready for us to use.

And hmm, how come you're speaking about a 65MHz clock? Isn't the oscillator a 24MHz? Or is there a frequency multiplier circuit in the SoC?

And about that library loading routine, would you mind refreshing my memory as to its address? I have probably looked at the wrong routine as I did not put much time yet into the clip firmware. Owh, and are you sure that the RAM isn't mapped at boot? If not, there is probably a simple way to map it. There seems to be a "remap" register somewhere I just can't remember where for now, I'll read back the doc.

Great progress guys, I hope for a nice bootloader in the upcoming days or weeks ;D
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on September 04, 2008, 08:52:55 PM
The driver is there but the way to control the nand pins is not exactly the same, plus the driver is in C and it's too big to fit, so I try to squeeze it a bit :)

I saw the 65Mhz clock in the datasheet section 7.3.12.7 but didn't see a 24 Mhz clock

The routine I saw is at 0x8598, you will probably have noticed it.

About the mapping, I tried writing a value in memory (offset < 0x20000) and read it back, but the comparison failed.

The code I posted maps RAM at 0x0, it's really simple, and I just setup a stack and use it to store registers like lr in function calls, and it works fine.

So next step is to finish the nand driver and put all the (position independant) functions in a block that I can memset() before returning to the OF.

Then FAT32, and winner ;)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on September 04, 2008, 10:34:32 PM
Hmm are you sure your code works ???

Maybe I didn't see something or what, but I see at least 2 problems (please correct me if I'm wrong): 1) You did not copy the ROM content into ram before mapping RAM at 0x00000000, and 2) you execute code from the addresses you swap in the memory map and didn't change the PC or anything before doing so. This will result in: 1) PC eventually pointing to uninitialized RAM, and while the copy process 2) PC pointing to a "copy-in-progress" memory area.

The only reason I think it works for now (and this is absolutely risky as you will see) is either: a) the RAM was previously initialized with the firmware by a "proper" load of the OF, or b) code cache is active and for whatever reason it continues to give valid code even though ROM isn't mapped anymore...

And worst of all: you should check for buttons and choose whether or not to boot custom firmware before anything else. You did changed the memory map register before that check you bad boy. ;)

For the clock, you can clearly see it here between the SoC and the mike (http://www.anythingbutipod.com/archives/images/sansa-clip-disassembled/sandisk-sansa-clip-disassembled-13-thumb-150x112.jpg).

Indeed about the LoadLibrary routine. In fact I did a little more disassembly of the clip firmware and found everything I already found in the m200 firmware so I feel like home now :P I'll gladly share my work files if you would like to have a look.

As for the NAND driver, way to go mate.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on September 05, 2008, 04:44:54 AM
Hmm are you sure your code works ???

Maybe I didn't see something or what, but I see at least 2 problems (please correct me if I'm wrong): 1) You did not copy the ROM content into ram before mapping RAM at 0x00000000, and 2) you execute code from the addresses you swap in the memory map and didn't change the PC or anything before doing so. This will result in: 1) PC eventually pointing to uninitialized RAM, and while the copy process 2) PC pointing to a "copy-in-progress" memory area.

The only reason I think it works for now (and this is absolutely risky as you will see) is either: a) the RAM was previously initialized with the firmware by a "proper" load of the OF, or b) code cache is active and for whatever reason it continues to give valid code even though ROM isn't mapped anymore...

And worst of all: you should check for buttons and choose whether or not to boot custom firmware before anything else. You did changed the memory map register before that check you bad boy. ;)
The code works (blinks) on my clip and on the e200 of fragilematter.

EDIT3:
I attach proof of concept of a 1st stage bootloader which will run code stored in a hardcoded location. binary is 140 bytes, and may even be reduced to 136 if we remove the possibility for our 2nd stage to return to OF so it should fit in most firmwares.
Note: this code doesn't do anything useful yet except branching to a location where no valid code is so you don't want to run it, but I confirm it works on the Clip: I wrote a BX R1 instruction in this block before branching to it and OF booted.
/EDIT3

1) Yes I don't copy the ROM into RAM, I just assumed it was preloaded and it booted fine, but we may have to copy the whole OF.

2) It's just the best solution because writing code that overwrites the location of the PC would be a bit tricky. I assume after and before the mapping of RAM, the first 128kB are exactly the same data.
Maybe the soc bootloader copy ROM content into RAM at boot ?

I have booted my clip fine after sleeping the whole night, so I'm sure the RAM didn't keep its state :)
Also I didn't find a way to map both the RAM and the ROM at the same time (at different locations to be able to copy from ROM to RAM)
EDIT: in fact the ROM is mapped at 0x80000000 and 0xC0000000 so we can branch to this location, enable the RAM, copy the firmware to RAM, and continue, but if we an avoid it it's better.
EDIT2: simpler solution, the RAM is mapped at 0x81000000, I attach a proof of concept which copies the whole ROM into RAM before remapping RAM to 0x0.

Finally you think it's the worst thing to change the memory map before returning to OF but I remind you this code is meant to run with a potential bricking OF, and we have to put it in the right state before returning to OF (clear the memory area where we inserted the 2nd part of our code).

I know this is dangerous and this is why I commented the functions called by this first stage : "DO NOT TOUCH"

About the NAND & clock, I will assume that the pclk is 65Mhz and loop over the code that puts WE / RE nand pins to 1 long enough to ensure the minimal delay required by ONFI spec (mode 0)
Thanks for showing me the clock on the pcb btw, I'll go to sleep less stupid tonigh ^^
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on September 05, 2008, 07:44:17 PM
It was mentioned earlier in this thread, that most buttons are possibly on ADC, and not GPIO. Maybe we should also have a look at that.

BTW: My Fuze arrived, so I'll hopefully be able to help a bit. It'd be nice if I get can one of you into chat (I use pidgin, so nearly any protocol will be fine), so that I can get faster into this and be able to catch up a bit.

Edit: I'm failing to use linuxstb's amsinfo tool on the Fuze firmware. While the header is dumped without problems, the library blocks are messed up and cause a segfault. Either the tool is broken, or the Fuze firmware format differs. I fear it could be the latter one. Could you guys have a look on the fuze firmware (downloadable at Bagder's site)?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on September 06, 2008, 10:40:32 PM
Yes sorry I was away for the day but I wanted to tell you that I'll have a look tomorrow. Until then, good night ;)


Edit: I looked at the fuze firmware. It looks like a valid firmware to me and with the same format as other V2. I'll give a look at amsinfo to see what the problem is :) But rest reassured, it IS (and its firmware IS) a v2 like all the others ;)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on September 07, 2008, 06:56:28 PM
Hello guys

I bricked my 2nd Clip this night :/
I flashed a firmware with a bad recovery mode: my 2nd stage code was written at 1st stage also and it assumes the 1st stage will make the return to OF, I should have disassembled the file before flashing it ..;

I will look at getting a new one, and I'll share my patches tomorrow after some cleaning so you can try the code (I look at e200 owners here).

kugel: the amsinfo.c assumes well formed library blocks, but it may be confused by a padding block and try to read/print its string description at wrong address => segfault.

I attach the tool I use (it will dump a file for firmware and each library block so you may want to run it in an empty dir) so you can check your firmware with it.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on September 07, 2008, 10:47:44 PM
Bhaaaa not again :'(

If you want to try JTAG, be sure to let me know if I can help... Soldering is a bit tricky, but for the rest, its quite easy...

As for the NAND interface, I'm not very far in it as of today, but I found a (quite big) piece of code that refers to the NAND enable bits in CGU_IO and other registers like that. I'm still not able to understand how exactly the NAND is accessed and to have commands samples, but I hope to find it in a "not-so-far" future... Oh and it seems like many functions are indeed from the segger embfile library as we suspected ;D

I hope that comparing with the embfile library doc will make analysis easier and quicker... But as I suspected, it seems like the NAND library is quite big :-\
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on September 08, 2008, 09:45:11 AM
Guys, it'd be nice if you were in IRC so that we can talk about this port faster.

Anyway, I want to start hacking my Fuze. What do you recommend doing first? I think it'd be helpful too see if the Fuze has this "recovery mode" too. What would I need to do to find out?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on September 08, 2008, 11:28:00 AM
Hi kugel and others,

Well I get on IRC #rockbox but being GMT-4 surely doesn't help if you're in europe since I only log in after supper, that is around midnight for europeans.

Well first, for the "recovery mode", you will need to open your player and see if there are some particular you can short. Honestly, I wouldn't recommend to try this unless you feel quite comfortable with the fact that you will break your warranty and that you are quite comfortable with electronics in general.

As for trying hacked firmwares, for the moment I would recommend against trying that out, we have enough bricked players already :'(

But, you may want to try to look at the firmware and help understand it. We are currently looking at the NAND interface so that we can get an easy (and safer!) way to load custom firmwares. If we could find the NAND interface initialization routine and data access routines, we would be in a good shape to build our own NAND driver.

Other than that, I'm beginning to think that there are a lot of information we haven't written to the wiki so if someone with decent writing skills, I feel it would be very beneficial if someone could volunteer so that we "dump" our info to him and he takes care of keeping the wiki up-to-date... Anyone?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on September 08, 2008, 03:34:55 PM
Bad news. The scrollwheel isn't working anymore.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on September 08, 2008, 04:05:44 PM
Maybe you can still use it although it's not as user friendly as before ?

Could you take photos of how you broke it so that other people do not repeat it please?

Thanks for the sacrifice of your scroll wheel !

I got another clip and I could finish writing clean & tested 2 stages bootloader.

The gpio checks the mapping for the Clip (hold & usb aka pin A3 and A6) and uses D7 as output to blink the led.

e200 mapping matches (A3 is usb and D7 is the led) but don't try it if you have another model before the mapping is figured out.

I attach diff to rockbox to use this bootloader (you only have to modify stage2.S).

Note: you better should disassemble the produced firmware before flashing it, and make a diff between it and the OF to be sure stage1 & 2 have been written correctly and the offsets are correct (they should ^^)

EDIT: add forgotten patch for find-offset.c, apply both diffs
EDIT2: as found by fragilematter, use ./find-offset instead of find-offset in the Makefile (. is not necessarily in the PATH)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on September 08, 2008, 04:13:51 PM
This is my dmesg output after inserting the Fuze with shorted NAND:

Quote from: dmesg
[32319.420338] usb-storage: device found at 10
[32319.420344] usb-storage: waiting for device to settle before scanning
[32324.420507] usb-storage: device scan complete
[32324.422625] scsi 9:0:0:0: Direct-Access     UNDEF    storage          1.0  PQ: 0 ANSI: 0
[32324.423736] scsi 9:0:0:1: Direct-Access     UNDEF    storage          1.0  PQ: 0 ANSI: 0
[32324.452564] sd 9:0:0:0: [sdb] 1 512-byte hardware sectors (0 MB)
[32324.454302] sd 9:0:0:0: [sdb] Write Protect is off
[32324.454312] sd 9:0:0:0: [sdb] Mode Sense: 00 00 00 00
[32324.454318] sd 9:0:0:0: [sdb] Assuming drive cache: write through
[32324.459838] sd 9:0:0:0: [sdb] 1 512-byte hardware sectors (0 MB)
[32324.460589] sd 9:0:0:0: [sdb] Write Protect is off
[32324.460612] sd 9:0:0:0: [sdb] Mode Sense: 00 00 00 00
[32324.460618] sd 9:0:0:0: [sdb] Assuming drive cache: write through
[32324.460639]  sdb:<6>sd 9:0:0:0: [sdb] Sense Key : No Sense [current]
[32324.462710] sd 9:0:0:0: [sdb] Add. Sense: No additional sense information
[32324.462928]  unknown partition table
[32324.463739] sd 9:0:0:0: [sdb] Attached SCSI removable disk
[32324.466375] sd 9:0:0:0: Attached scsi generic sg1 type 0
[32324.477270] sd 9:0:0:1: [sdc] Attached SCSI removable disk
[32324.477356] sd 9:0:0:1: Attached scsi generic sg2 type 0
[32324.840031] sd 9:0:0:0: [sdb] Sense Key : No Sense [current]
[32324.840044] sd 9:0:0:0: [sdb] Add. Sense: No additional sense information
[32325.003649] sd 9:0:0:0: [sdb] Sense Key : No Sense [current]
[32325.003662] sd 9:0:0:0: [sdb] Add. Sense: No additional sense information
[32327.374550] sd 9:0:0:0: [sdb] Sense Key : No Sense [current]
[32327.374568] sd 9:0:0:0: [sdb] Add. Sense: No additional sense information

This is lsusb -v of my Fuze
Quote
Bus 004 Device 010: ID 0781:6200 SanDisk Corp.
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x0781 SanDisk Corp.
  idProduct          0x6200
  bcdDevice            4.02
  iManufacturer           1 SanDisk
  iProduct                2 M200Plus
  iSerial                 3         i 0744703011
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          4 config1: Mass Storage only
    bmAttributes         0xc0
      Self Powered
    MaxPower                0mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk (Zip)
      iInterface              5 ms ifac 1 (SCSI::BULK_ONLY)
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  bNumConfigurations      1
Device Status:     0x0001
  Self Powered

fdisk -l doesn't work.

The weird thing is: I get 2 new devices upon connection (sdb and sdc).

Doesn't look like being recovery mode, does it?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: fragilematter on September 08, 2008, 04:19:22 PM
kugel: in fact it does, but it looks like the unusable one from the clips (it probably wasn't implemented by sandisk in the same way that it was on e200s)...

funman: your makefile tries to compile find-offset.c, but you haven't included it in the diff.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on September 08, 2008, 04:25:20 PM
What do you mean?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: fragilematter on September 08, 2008, 04:32:40 PM
The clips show the recovery disk, but its 0MB in size and you can't write to / read from it. It looks like the fuze has the same behaviour. Check the older posts for more info ;)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on September 08, 2008, 04:49:37 PM
Yea I udnerstood that. But this does mean, there's no such recovery mode (unusable is basically the same),doesn't it?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: fragilematter on September 08, 2008, 05:00:36 PM
For the e200s that is the recovery mode... The other v2's can probably use jtag, but it's simpler to test any code on someones e200 to make sure it's safe.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on September 08, 2008, 05:10:13 PM
If you're going to return devices you broke, you probably should not discuss it on these forums since I really doubt Sandisk allows that, and it might be considered fraud by some.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Hillshum on September 09, 2008, 11:42:33 AM

I have the writing skills and the will to be the 'wiki man', but I may need some explanation of terms (IRC). Also, soon I may not have the time.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on September 09, 2008, 12:47:53 PM
Thanks ;)

You can /query me (funman) on freenode if i'm not on #rockbox

I'm here 9AM to 6PM (CEST = GMT+2) and often on the evening
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Hillshum on September 11, 2008, 03:18:21 PM


I'm only on in afternoons (UTC-6 till daylight wasting ends, then UTC-7).
Title: NAND flash
Post by: funman on September 11, 2008, 05:01:08 PM
Now that we exchanged our IM we'll get in touch, I hope better doc attracts new hackers ;)

As for the bootloader, I'm still blocked on the nand driver

I had a look at various drivers (in rockbox, Linux and U-Boot) and especially at the patches for U-Boot & Linux mentioned in this post http://forums.rockbox.org/index.php?topic=14064.msg117283#msg117283

I also read the ONFI 1.0 & 2.0 specifications (http://www.onfi.org)

But I can not get the signal that the NAND is ready for operation

I attach my stage2.S , if you run it it will just blink the led forever, so I advise you to not use it.

Reverse engineering the OF shows no direct references to the nand registers, but atomipunk found a location in the code where these registers are calculated (by an offset to the base address) and stored in RAM, to be later used by other routines.

This renders analyzing & understanding how the OF interacts with the NAND quite complex.

Note that the patches for Linux have still not been applied, maybe they were buggy or written for a target different from the SansaV2 ? (like in AS3525-1 or AS3525-2)

We could try to contact AMS and ask them for the Linux patches, maybe they have evolved since the patches sent to the linux-arm mailing list.


NEW POST:

I have found new buttons for the Clip:

The list is growing up :)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on September 17, 2008, 11:14:09 AM
After (much) hacking into the firmware, I found it very hard to find any NAND registers references, and a lot too much SD interface registers references. As my analysis went by, I bended more and more to the idea that the flash could be in fact accessed using the SD interface instead of the NAND interface we previously suspected.

And after re-reading some docs on Daniel's site, I found out that v1 e200 players used the SD interface for the (primary) flash. So well I'll invest more time now on the SD interface as it seems to be the most promising avenue at the moment.

That's no big news for today except that on the analysis side, it is much clearer now what we're looking for ;)

Just a reminder: once we're able to load a custom firmware from the flash, we're free for _much_ more hacking since it'll be much easier to drop firmware files on the player and test stuff. So that's pretty much the last tricky part before things goes more roundly.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on September 18, 2008, 07:44:37 AM
Very good news !

Now we can continue study the OF with a clearer mind and start writing a SD driver.

I think that we must use the SD driver with the nand base address instead of the sd mci base address to access the nand, SanDisk may have wired the ams3525 differently.

Or maybe we must use the SD base address and load a specific "bank" to access the nand chip, testing will tell ...

Also don't forget when we have access to the raw nand content we must write a minimal fat32 driver to fit in the bootloader, but I hope the fat32 filesystem is quite simple.

Back to hacking ;)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Bagder on September 18, 2008, 12:53:17 PM
Also don't forget when we have access to the raw nand content we must write a minimal fat32 driver to fit in the bootloader, but I hope the fat32 filesystem is quite simple.

Rockbox already has all the fat32 filesystem code you need of course...
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: fragilematter on September 18, 2008, 12:58:56 PM
It's fat16 in fact, so we can get rid of the fat32 support and make a smaller driver ;)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on September 18, 2008, 01:22:28 PM
Are you sure it's fat16 for all v2s? I have a doubt that a 8GB Fuze uses fat16.

Also, I seem to remember that for the e200v1, fat16 was possible for <= 4GB versions, but 6 and 8GB ones used (of course) fat32.

As for the minimalistic fat driver: I think it's worth looking into existing code for already supported targets, especially if the SD interface is to be used, just like e/c200v1 series.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on September 18, 2008, 01:25:18 PM
Rockbox already has all the fat32 filesystem code you need of course...

I am not sure it fits in the 1kB of our code segment, aside with the sd driver, so I think we must go we the minimum.
I don't know filesystems but I think we can remote at least write support, recursive directories traversal, and maybe more ..

I built rockbox bootloaders for other targets and they are not very smaller than the rockbox code (without applications) and are definitely too big for the actual room.

By the way do you know if MMC (SD) and NAND flash are driven by the same driver with different base addreses for the registers in SansaV1 ?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: caladan on September 18, 2008, 02:25:10 PM
Atomikpunk must be right with that SD driver. We should have thought about it earlier, texts in sw indicate clearly that all directories are seen in mmc:\
I wonder how dangerous it would be, but maybe we should try to use the same values as those used in v1 to access registers.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on September 18, 2008, 02:40:08 PM
I wonder how dangerous it would be, but maybe we should try to use the same values as those used in v1 to access registers.

The OF clearly show different values: it shows that the SD controller is the ARM PL180
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on September 18, 2008, 11:06:16 PM
Hi again peeps,

Yeah I'm wondering, anyone knows more than I do about "metal ECO redesign"? Because the only way everything we've found about the NAND SD interface up to now suppose that a "spare" register, described as being "used for metal ECO redesign if needed" is used just prior to using the NAND flash register as we would with the Arm PrimeCell PL180... And this is quite surprising since this register should not have been like the PL180 at all, so this is what makes me think that the NAND registers on the sandisk AMS3525 SoC could have been "upgraded" with a second PL180 interface which would be selectable by using one of those spare register...

As for the FAT driver, well yes, we would need a very compact and truncated version, simply allowing one to find a specified file name and read it. We probably wouldn't need directory support, write support nor anything like that. The idea is to load a minimal bootloader that can load a full-blown rockbox firmware from the NAND, nothing fancy since we are quite short (for the moment?) on code space. And about this limitation, we should think about switching to thumb mode soon...

funman: I did some more analysis tonight and found that the NAND supply voltage is 3.0V, selected in the power register using the power value 0xA. In fact, the formula is: voltage = 2.0V + power_value * 0.1V.

About your try to work with the flash, maybe you can send me your code so I can take a look?

Have fun peeps, more to come when we'll have more time ;D
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: dan_a on September 19, 2008, 04:24:50 AM
Rockbox already has all the fat32 filesystem code you need of course...

I am not sure it fits in the 1kB of our code segment, aside with the sd driver, so I think we must go we the minimum.
I don't know filesystems but I think we can remote at least write support, recursive directories traversal, and maybe more ..
I've just done a very simple stripping out of the write functions from fat.c, and that reduced its size when compiled from 22k down to 9.7k.  Getting down to 1k including the SD driver will be quite challenging.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Bagder on September 19, 2008, 05:58:53 AM
Regarding the need for small code sizes.

Can't we just decide on a part of the OF that we can "sacrifice" (at least for now) and overwrite with bootloader code and jump to that from the tiny snippet we inject?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on September 19, 2008, 09:24:52 AM
Not really since we only have 128kB in ROM and e200 testers showed that we can't use the last bytes of the ROM, but only the last bytes of the 0x200 bytes block of the firmware

EDIT: I forgot to mention that the code in ROM contains the basis of OF and I think we just can't 'sacrifice' this code.

If we modify the parts past 128kB, they stay on NAND and are loaded afterwards by the code present in the ROM.
Maybe the Sandisk logo we see at boot can be modified to contain code? 128x64 / 8 = 1 more kB

But I don't even know if it's in ROM or in upper parts of the OF.

EDIT2 (I shouldn't press Post that fast):
I have thought about something else in the last days: if full FAT support can not be made, we could use a tool to modify the filesystem, and then in our bootloader assume a fixed location on the hard disk for the firmware (i.e. allocate a file at the very beginning of the partition for our rockbox firmware).

EDIT3 : or we can partition the disk and put a magic word in the first partition, so we know exactly at which offset to look for our firmware : much simpler because we avoid FAT
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on September 19, 2008, 11:51:48 AM
I know this may look a bit stubborn (ok, it is a lot...) but what about trying your mkamsboot patch (see this message (http://forums.rockbox.org/index.php?topic=14064.msg133638#msg133638)) not using 0x100 blocks of 0x200 bytes, but 0xFF blocks instead. Because I really feel like the "firmware block size" field may be a byte and not a word...

As for the sandisk logo, well in the m200 version it was in a (far away) library block, so probably the same for all V2s. This means nope, not available until the NAND is accessed...

As for the filesystem hacks, well yes that could work. I'd rather go with a "more elegant" approach if we can, but that could do the trick. We must take care however not to overwrite the firmware (that is located somewhere on the NAND).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on September 19, 2008, 12:09:50 PM
This needs to be done by the e200 testers.

I remember fragilematter has made some tests but don't remember which exactly

As for overwriting the OF, its not visible through usb interface so no problem, we just need to find its exact size on the nand to skip it when reading.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on September 19, 2008, 12:19:19 PM
Yes right, but would you mind updating (and reuploading) an updated version of your mkamsboot patch including this change? I think you hardcoded the 0x100 multiplier if I remember correctly...

And right for the filesystem, that could do the trick (though I still have my reserve).

I'll try the (new) patched mkamsboot once it is done on an e200 firmware and check its disassembly in case I see something wrong with it. Maybe we can coordinate with the e200 testers so we can talk "live" about it, maybe this weekend?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on September 19, 2008, 12:24:33 PM
Here is a diff to svn checkout.
It uses 0xff * 0x200 as the "rom block" size (use normal test.S with it)

E200 testers, anyone ? ;)

EDIT: this week end I'm available, I'm on European time (UTC+2) but I can stay awake late; let's meet on #rockbox ?
But next week end I live the country where I live in and I'll have to look for a place to live and a job so I will hold on rockbox hacking :'(

EDIT2: I remove the patch since it doesn't work
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: fragilematter on September 19, 2008, 02:34:18 PM
Okay, just so that anyone is advised, the mkamsboot 0xff * 0x200 rom block size firmware bricks sansa e200s... try it at your own risk
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on September 19, 2008, 02:53:03 PM
Bha damn... Thanks fragile_matter. I'll check the patch, create a patched firmware tonight and see what it looks like. If the firmware looks clean, well I'll give up god damn :'( (obviously on that firmware block size field topic, I won't give up that easily on the project itself ;D)

But I really wonder how come there is a field for that (firmware block size) in the header but they wouldn't use it ???
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on September 19, 2008, 02:59:58 PM
Maybe they use this one to flash the ROM (maybe you can write in ROM only by 512 bytes (0x200) sectors a a time ?

Also note that there is reference to past firmware, below 128k offsets, to initalise the stack.

The offset might be replicated somewhere else to handle library blocks loading ..
I'll look at finding the firmware size at other places in the file and report.

EDIT:
I removed the previous patch because it was broken.
Following patch uses 0x100 blocks (maximum), replaces in total 7 occurences of firmware size (instead of 2 previously), and update the firmware block checksum (what the previous patch didn't do).
I also added a check which verifies that the blocks we lose are padded with 0xff or 0xdeadbeef
Note: it seems that all the firmwares end with the same padding, except that some firmwares (like clip v29) are filled with random data and not recognizable padding.
XXX: patch confirmed to NOT work on E200 by fragilematter
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: tobi-lu on September 20, 2008, 07:51:21 AM
Hi!

Haven't been here for a while (shitty exams ;D), nice to see your great progress!

Well, I also read the wiki-page again and those missing graphs annoyed me once more. So I took the code and fed it to dot manually. You can see the results in the attachment. Perhaps someone can put these images into the wiki instead of the code?


cu
Tobi
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: fragilematter on September 20, 2008, 07:53:42 AM
Heya tobi-lu.
funman, atomikpunk and I will probably do a testing session on #rockbox in about an hour or two. Maybe you could join us :)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: daniel_at on September 20, 2008, 05:44:02 PM
Hey all,

I've found some button-mappings for E200-Players. Thankfully there are some direct GPIO-wired buttons, so that it is easy to check for a bootloader. Especially if we have not much space for the code.

Up/Down/Left/Right/Center are connected to GPIOC and can therefore easily be checked.
http://www.rockbox.org/twiki/bin/view/Main/SansaV2HardwareMappings

To all the Firmwarehackers:
If you have some usefull functions/snippets which may be interesting for other hackers to play with, pls add them here: http://www.rockbox.org/twiki/bin/view/Main/SansaV2FWHacks

ciao
Daniel
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on September 21, 2008, 03:41:10 PM
Daniel I added the known buttons for the Clip

I use a patched mkamsboot so the format of my assembly file(s)  are a bit different, do you want it to look at useful snippets ?
I think posting code on the wiki is a bit disorienting, we better should open a Git repository on repo.cz to share our code.

Any volunteer admin for the repository ?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on September 21, 2008, 06:06:20 PM
Well why not ask for svn access to the rockbox SVN repository? :)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on September 21, 2008, 08:42:21 PM
Usually people get SVN access by having a few patches accepted, at least that is the tradition.  The powers that be might make an exception for some people in this thread, but if theres going to be more then 1 or 2 people using it, running your own repo might be considerably easier since you could add as many people as you like to it.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on September 21, 2008, 08:45:56 PM
I agree, a repo where everyone here would have commit access is better, at least until we produce a major breakthrough.

Another note: I'll gladly try to find some buttons on my Fuze and update the SansaV2HardwareMappings page accordingly. I'd just need some short introduction on how this works. I'll be in IRC tomorrow, until evening, so it'd be nice if we can meet, for better support.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: daniel_at on September 22, 2008, 03:47:39 AM
Okay - an external Repo sounds like an good idea. First i thought i set up one on my own server - but found something looking quite okay:

http://gitorious.org/projects/rockbox_sansa_v2

I have created the initial project. To join you have just to register a user on that site and than i can add you (i hope) - But be aware: I am a git-noob :) (but thankfull that i now have a reason to get known something different than SVN)

@kugel
We just have found a reliable way of unbricking a E200-device, so the testcript for finding buttons have to be carefully adopted, so that the OF can easily (and reliable) loaded if something went wrong....

Okay - sofar
Daniel

PS: fixed typo, thx Hillshum
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Hillshum on September 22, 2008, 01:57:24 PM


Well, it seems I will not have time to keep the wiki up to date, but I will be able to find time to code/learn to code.

*puts nose in big book*
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on September 23, 2008, 09:23:49 AM
Quote
*puts nose in big book*

Don't read it too fast like I did ;D (it was too easy)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: MarcGuay on September 23, 2008, 11:23:48 AM
And after re-reading some docs on Daniel's site, I found out that v1 e200 players used the SD interface for the (primary) flash. So well I'll invest more time now on the SD interface as it seems to be the most promising avenue at the moment.

I can't tell if this has been confirmed yet but the chip in the bottom right of this photo:

(http://farm3.static.flickr.com/2121/2494641473_094bf5bd01_b.jpg)

Looks like a newer version of the SD controller in the e200v1's:

(http://www.rockbox.org/twiki/pub/Main/SandiskE200HardwareComponents/sandisk2.jpg)

and the SD c100's

(http://www.rockbox.org/twiki/pub/Main/SansaC100Port/c150-memboard-small.png)

Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on September 23, 2008, 11:47:54 AM
Well on the clip there doesn't seem to be any "translation" chip on the PCB, though I suspect it to be inserted in the AMS SoC. In fact, you will notice that the SoC is labelled with Sandisk markings so I suspect that Sandisk bought the AMS die, and added some more logic to it to support SD-interfaced NANDs. Which would in fact also explain the "spare registers for metal ECO redesign" usage...

Any comments on that? Anyone with experience in dies and chip customization?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: daniel_at on September 23, 2008, 11:56:00 AM
Just wanted to note: the term 'eco' (as you have found in the datasheet in conjunction with the sd-access) ppbl. stand for engineering change order - so it is indeed _very_ likely that sansa has added some more logic into the SoC.

http://en.wikipedia.org/wiki/Engineering_Change_Order

Daniel
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on September 25, 2008, 09:06:00 AM
Hi

I noticed OF will set the bit2 of the CCU_SPARE1 register if C1 pin reads #1, and clear the same bit2 if C1 reads #0, probably C1 is #1 when the SD-NAND interface chip is present.

On the Clip C1 was #1 when I tried it, could you check the value on E200 ?

EDIT: The exact same code is used in the e200 firmware (read C1, store the value in ram (the offset where the first nand/sd structure is stored - #8, use this value to clear/set the bit in the spare register).
However as fragilematter showed here (http://forums.rockbox.org/index.php?topic=14064.msg133746#msg133746) C1 is #0 , maybe because the chip used in the e200 and the clip is different ?

Maybe with good eyes you can also see if there is a connection between C1 and a chip near the NAND ?

Mine are too weak to notice anything on the little Clip (and we didn't find any visible SD chip anyway)


EDIT2: I posted a patch on FS#9396 (http://www.rockbox.org/tracker/task/9396) which uses a stage2 written in C.
I hope it attracts more hackers and make our code less error prone ;)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on September 28, 2008, 09:50:53 PM
Hi peeps,

I haven't posted in a while but as usual, things are still going on under the hood. funman wrote a nice C-version of his stage1/2 bootloader, we both still try to make that (damn) flash interface to work, and beside I started looking at building an LCD driver (because sometimes one need to look at something else than disassembled code ;D).

funman: almost everything in your C-version seems to be alright except that the return instruction from _start that seems to compile as a BX instruction, which may be wrong since both our crt0.S and stage2.c are ARM code... I'll have a look back at it tomorrow.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on September 29, 2008, 01:14:03 AM
funman: almost everything in your C-version seems to be alright except that the return instruction from _start that seems to compile as a BX instruction, which may be wrong since both our crt0.S and stage2.c are ARM code... I'll have a look back at it tomorrow.

Looks normal: BX Rm switches to Thumb mode if and only if Rm[0] == 1
Since the instruction we are coming from is aligned on 2, no problem.

Note on my computer it doesn't use BX but:
Code: [Select]
STM.. SP!,...,LR
LDM.. SP!,...,PC

Of course we assume that the gcc used to  build the bootloader has no bugs, the produced binary could brick your device definitely if it was the case.

Maybe for the final bootloader, we will make gcc output assembly code, check that the code is correct manually and maybe optimize the size of the code a bit, to remove any doubt.

On a side note, kugel found yesterday on his Fuze that gpio A3 is #1 when the device is powered over usb, so A3 can be used as a recovery on Fuze, E200, Clip.
C200 and M200 owners, any volunteer for testing on your model ?

P.S. I'm waiting for your LCD code ;)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on September 29, 2008, 06:51:40 AM
Just a quick note to say that I looked at a disassembled binary produced by our toolchain and it looks fine at first sight, good job! :)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: linuxstb on September 30, 2008, 04:22:58 PM
I have a plan to deal with the problem of inserting a Rockbox bootloader into the OF, whilst maintaining a reliable dual-boot feature.

However, this is based on the theory that the firmware image we're patching is not in fact stored in the 128KB internal ROM of the AS3525, but that the internal ROM stores a standard AMS bootloader (this seems to be referred to as "C21" in the datasheet), which loads the OF from the NAND flash into RAM and then executes it.

I haven't been following this forum thread closely, but the SansaV2Firmware wiki page seems to suggest that the main firmware image is stored in ROM - but as far as I can see this is indeed Read-Only Memory - i.e. there is no way to update the contents.

The idea is simply to compress the main firmware block of the OF.  UCL compression (used in Rockbox for the older Archos devices to compress flash-ROM images) is ideal for this, and I have a found a thumb version of the UCL decompress function which is only 180 bytes long.

My test firmware is m300a-1.1.17A.bin for the Clip.  The main firmware block is 119808 bytes (119336 bytes for the OF, plus 472 bytes of padding).  The 119336 bytes of the OF compresses to 77753 bytes with UCL.

The idea is to build a new main firmware block as follows:

Bytes 0-41582 would store our Bootloader, linked to run from address 0x0
Bytes 41583-119335 would contain the UCL-compressed version of the OF
Bytes 119336-119808 would contain a function to decompress the OF "in-place" and run it by branching to 0x0

Our bootloader would need to check for a keypress, and if pressed (or not pressed), then branch to the "ucl_decompress" function.  Otherwise, it would just continue running.

No RAM outside the area used by the OF would be touched, so assuming no bugs, this should be safe...

Does this sound feasible to those of you that have hacked the V2 more than me?  Is the assumption that the OF is already running in RAM a valid one?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on September 30, 2008, 04:32:40 PM
Well, the fact that you can write a firmware directly to the NAND (as in dd'ing it onto the device, not letting the player update itself -- the recovery method of the e200v2) which is then used directly after the next boot implies that it's loaded from NAND to RAM, doesn't it?

Or did I get something wrong here?

I like your idea. It sounds definitely feasible to me.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on September 30, 2008, 06:40:02 PM
Very good idea linuxstb!

And your theory is indeed confirmed.
I remember testing this by writing to the memory and reading back and the values didn't match, but I probably messed up my test.

This time I'll attach my code (test.S for svn checkout) so others can proof-read and test it.

It confirms that we can write to the memory, and I also checked the CCU_MEMMAP register : it indicates that RAM is mapped at offset 0x0

I'll try to assemble the parts needed for using your method and call for e200 testers to be sure just to be sure :)

Also I think we could measure the size we gain on different firmware versions to get the maximum.

EDIT: here are the sizes we can use for our bootloader (padding was not taken into account):
clip v01.01.17 40756 bytes
clip v01.01.18 41247 bytes
clip v01.01.20 41430 bytes
clip v01.01.29 41934 bytes
fuze v01.01.11 38746 bytes (note : strings on the file reports V4.0.45A, could it be because the firmware is more modern ?)
e200 v03.01.16 41727 bytes

So that means ~40 kB (plus the padding of the firmware block, less the button check and the decompressing function), quite enough for now ;)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on September 30, 2008, 11:23:01 PM
Hi peeps,

well I started coding the LCD driver for the clip. But coding it in C makes it quite big though I doubt it would be much smaller coding it directly in assembly. So yeah, I'd be very interested if you (funman? linuxstb?) get to make a "decompilable" OF that would lend us some space :P

The LCD driver would be helpful for debugging purposes but I doubt we will leave it in the first "stage" once we're there. I guess we will load it from the NAND which will leave us with much more playing space...
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: linuxstb on October 01, 2008, 01:55:11 AM
So that means ~40 kB (plus the padding of the firmware block, less the button check and the decompressing function), quite enough for now ;)

And of course we can also ucl-compress our bootloader, which should take it up to about 60-70KB...

This should be enough for a full Rockbox bootloader, which are typically about 40-60KB.  So this would seem to be a long-term solution.

EDIT: I have now committed to SVN my first attempt at adapting mkamsboot to do this.  Please can all interested people look at this code, compile and disassemble it.  It's NOT safe to run yet, but I committed it so other people can see it and help review it.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on October 01, 2008, 07:31:23 AM
The actual code (revision 18676) is confirmed to NOT work.

If you want to debug it you can use skyeye arm emulator.

I use the following skyeye.conf:
Code: [Select]
cpu: arm920t
mach: at91rm92

mem_bank: map=M, type=RW, addr=0x00000000, size=0x00050000, file=./fw.bin
mem_bank: map=M, type=R, addr=0x00100000, size=0x00010000
mem_bank: map=M, type=RW, addr=0xc0000000, size=0x00200000
mem_bank: map=M, type=RW, addr=0x20000000, size=0x000f0000
mem_bank: map=M, type=RW, addr=0xc0200000, size=0x00500000
mem_bank: map=M, type=RW, addr=0xc0700000, size=0x01900000
mem_bank: map=I, type=RW, addr=0xfffa0000, size=0x00060000

load_addr:base=0x20000000, mask=0xFFFF

with fw.bin being the patched firmware block.

skyeye expects an elf program, I use the following to start execution of our firmware:
Code: [Select]
int _start(void) {

    asm volatile( "mov r0, #0" );
    asm volatile( "bx r0" );

loop: goto loop; /* remove the asm statements to put skyeye in an infinite loop */

    return 0;
}

Note, to use gdb with skyeye, use the -d option of skyeye and connect to the running gdbserver like you would do on any other remote gdb (use a gdb built for arm of course).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: pedrov on October 01, 2008, 12:59:28 PM
Hi all,

I borrowed a JTAG usb interface from my firm (it looks like this : http://www.iar.com/website1/1.0.1.0/369/1/index.php), and I have a sansav2 e2xy model. I would like to know if I could help you on the port, but I don't have any experience on hardware tweaking. IIRC, atomikpunk already succeeded in connecting a JTAG interface on the device. Any advice ?

Regards,
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on October 01, 2008, 09:21:01 PM
Hi,

well yes I can help but honestly I'm not sure about the real usefulness of JTAG now. Sure it is very useful in case the device is bricked or for project that don't have safe bootloaders... But it this case, we now have a safe testing bootloader and e200's got a recovery method so...

But if you want to try it as academic learning, I'll try my best to help you. Private message me so we can get in touch in that case. :)

BTW, really looking forward the decompression method. If we can make it work and be sure it is safe, that would be nice. Good job! ;D
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on October 01, 2008, 10:27:21 PM
JTAG could still be useful for reverse engineering because it allows access to register values used by the OF.

Even for documented hardware (like the AMS DAC), a good deal of trial and error was needed on the V1 port to figure out good values, and even then we probably don't set everything quite as intelligently as the OF does.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: linuxstb on October 02, 2008, 07:42:01 AM
The new UCL compression method of adding our bootloader code to the OF now seems to be working.  The code in SVN has been tested on a Clip, and also on an E200.

This latest code no longer adds anything into the padding at the end of the firmware block - so should work with any original firmware versions.

Some more success reports could be useful, but I think this is good enough to allow more development.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: mbr on October 02, 2008, 10:35:16 AM
Some more success reports could be useful, but I think this is good enough to allow more development.

Hi there,

I can confirm, that the code in subversion (r18682) works on my e250v2 with firmware e200pa-03.01.16.bin
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Hillshum on October 02, 2008, 01:59:00 PM

Hi there,

I can confirm, that the code in subversion (r18682) works on my e250v2 with firmware e200pa-03.01.16.bin


r18684 works on my e260 with the same firmware
never mind it's r18679

Update: r18684 does work
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on October 02, 2008, 03:45:11 PM
It's also tested on my Fuze. It works.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Kilar Ezan on October 03, 2008, 06:26:33 PM
Well, I'm not a programmer and I don't know a thing about the technical side of players, but Sandisk has just released new firmwares for fuze and clip and i think that clip has just became a harder target for rockbox, because Sandisk messed with the pcb, and we have Clips v1 and Clips v2 (hardware revision 1 and revision 2 firmwares) ;/
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on October 03, 2008, 06:45:31 PM
This doesn't make the Clip (v1) a harder target in anyway.

In fact it may be very interesting if someone has a v2 Clip because it appears to have external memory attached (note that it is still based on the same AS3525 SoC).

I also hope that they activated the recovery mode on this one.

Beware before using the tools in SVN on a ClipV2 because the firmware format is a bit different (the 0x20 bytes header has been extended by 32 bits, and a checksum has been added to it).

EDIT: I looked a bit at the new firmware format:
It's basically the same format except that a 32 bits low endian value (0x0000f000) is inserted at offset 0x4, and following data is shifted by 32 bits

After 0x24 until 0x1fc, all the words are 0xffffffff (like previously)

There is a copy of these 0x24 first bytes at offset 0x200, with the difference being that the first word is 1 instead of 0 (like in the previously known format)

At offset 0x1fc, there is the sum of all 32 bit little endian words from 0x0 to 0x1fc (not including this checksum)
The same checksum is at offset 0x3fc (from 0x200 to 0x3fc), and is the 1st checksum + 1

Update the current mkamsboot.c in SVN is trivial, and left as an exercise to the ClipV2 owners ;)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: ziegs on October 04, 2008, 02:38:17 PM
It's also tested on my Fuze. It works.

I'm interested in rolling a build for my Fuze.  How can I get started?  What architecture should I target in tools/configure?

Thanks,
--z
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: fragilematter on October 04, 2008, 02:44:05 PM
You can't roll a build just yet. We just use mkamsboot from the svn to insert code into the official firmware image and then flash the player using that image. We still need a way to access the nand, so any help would be greatly appreciated.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Moarc on October 05, 2008, 03:38:20 AM
I see SanDisk provides iNAND documentation (not full, but e.g. with pin description, isn't it important information?) freely at its website, maybe it should help with hacking NAND on v2's?

http://www.sandisk.com/As...ls/ProdManiNANDAbr1.1.pdf
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: cosmocat on October 05, 2008, 03:56:15 AM
I see SanDisk provides iNAND documentation (not full, but e.g. with pin description, isn't it important information?) freely at its website, maybe it should help with hacking NAND on v2's?

http://www.sandisk.com/As...ls/ProdManiNANDAbr1.1.pdf
Link seems broken, this one should be better....
http://www.sandisk.com/Assets/File/OEM/Manuals/ProdManiNANDAbr1.1.pdf
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on October 05, 2008, 08:38:27 AM
Thanks, this document shows for example that for initializing the device, you have to send ACMD41 until it answers that it's ready.

In the MMC specification, they use CMD1 for that, and CMD41 is 'reserved'

Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: tobi-lu on October 05, 2008, 11:05:17 AM
Using google, i've found a "non-abridged" version of the manual:
http://www.spezial.cz/pdf/inand_manual_v3.1.pdf

But this document doesn't say anything about CMD41...


edit: Instead, it has lots of references to the "SDA Physical Layer Specification, Version 2.00" which isn't available freely >:(

edit2: well, a simplified version is available on http://www.sdcard.org/developers/tech/sdcard/pls/

edit3: on page 15, there are some informations about initialization.
Quote
The busy bit in the OCR is used by the card to inform the host that initialization of ACMD41 is
completed. Setting the busy bit to 0 indicates that the card is still initializing. Setting the busy bit to 1
indicates completion of initialization. The host repeatedly issues ACMD41 until the busy bit is set to 1.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on October 05, 2008, 12:26:26 PM
Quote
Any implementation of the Simplified Specification may require a license from the SD Card Association, SD Group, SD-3C, LLC or other third parties.

I believe this will be a problem, so we rather should not look at this document at all.

EDIT: unrelated to SD, but good news anyway ;)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: wnmnkh on October 05, 2008, 05:00:43 PM
Since we have two kinds of hardware versions for Clip, is this project aiming for version 1 or version 2?

I read some and it seems there are some hardware changes.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on October 05, 2008, 05:19:15 PM
Since we have two kinds of hardware versions for Clip, is this project aiming for version 1 or version 2?

Personally I own a ClipV1, and we have no details about the V2 except the firmware update recently released (which let us think that the ClipV2 comes with external RAM).

Parts of this project are common across all the Sansav2 models (including Clipv1 AND v2), since they are all based on the same AS3525 SoC.

But some development (like the LCD driver for example) is specific to each model.

Until someone comes with a ClipV2, we have no idea if all or some of the work done for the ClipV1 can be reused for the ClipV2
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on October 05, 2008, 08:13:47 PM
Haha now that's good news, good work funman (though I deserve thanks for part of it ;D).

Now let's hack that damn flash, with the LCD help of course!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on October 05, 2008, 08:54:50 PM
Of course many thanks to you atomic punk !!

I think without you there would be nothing today which let us hope for a port!

I pushed my rockbox branch in the gitorious tree (http://gitorious.org/projects/rockbox_sansa_v2), so we can synchronize the work.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on October 05, 2008, 09:26:41 PM
Quote
Any implementation of the Simplified Specification may require a license from the SD Card Association, SD Group, SD-3C, LLC or other third parties.

I believe this will be a problem, so we rather should not look at this document at all.

I believe that refers to SD communication itself, not the datasheet (which is itself available under reasonable license).  Generally such things are safely ignored since they are effectively unenforceable against source code.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: tobi-lu on October 06, 2008, 04:22:53 AM
That's what I thought as well...

In the end, we'll HAVE to use things that are in this document, because that's just how the SD communication works, no matter how we find it out.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on October 06, 2008, 11:39:07 AM
Hey guys

Now with the help of the LCD I'm sure that I can issue commands to the SD, but the protocol is still quite confusing to me.

I attach the code I use to power the device and send commands, but without my buggy commands ;)

P.S. I uploaded a nicer HD picture (http://img100.imageshack.us/img100/7923/bestwx5.jpg) of the lcd
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: daniel_at on October 07, 2008, 07:10:16 AM
WOW! Congrats to funman, atomikpunk and all other helpers! This is really great news.

I am just looking at the current GIT-Tree and feeling somehow unsure, how I cleanly get to a rockbox.bin file which i can stuff into the mkamsboot-makefile. Any Hints?

Now as we can print out more informations i would eagerly want to know where the interrupt-vector points, which handles the power-button. Because, if the "power-off" it is software driven, this vector would point to a region which is executed befor the OF (and now our rockboxloader) is executed from flash. Which will be the mask-ROM mentioned in the datasheet. According to the pdf this ROM can be mapped onto 0x00000000, but that seems unreasonable in our case, because here lies RAM which gets loaded with data from flash. So Sansa has maybe modified the Address which the mask-ROM maps to. Or the power-off is hardware driven - then forget about all i wrote :)

Daniel
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on October 07, 2008, 07:24:20 AM
I am just looking at the current GIT-Tree and feeling somehow unsure, how I cleanly get to a rockbox.bin file which i can stuff into the mkamsboot-makefile. Any Hints?

You can use tools/configure and use the Clip target, bootloader only.
But before you should be sure to disable the lcd driver, because it is specific to the Clip: I don't think it will work on the E200.

Now as we can print out more informations i would eagerly want to know where the interrupt-vector points, which handles the power-button. Because, if the "power-off" it is software driven, this vector would point to a region which is executed befor the OF (and now our rockboxloader) is executed from flash. Which will be the mask-ROM mentioned in the datasheet. According to the pdf this ROM can be mapped onto 0x00000000, but that seems unreasonable in our case, because here lies RAM which gets loaded with data from flash. So Sansa has maybe modified the Address which the mask-ROM maps to. Or the power-off is hardware driven - then forget about all i wrote :)

Daniel

I think the power-off is software driven, because on the Clip I see a logo animation before it shutdown.
You can access the ROM at 0x80000000 (it is an alias) but I think it's useless because before being able to dump its content we need flash driver :/

Also I looked at the NAND / SD registers, because I supposed the ROM bootloader would leave them initialized, but they are reset to 0 .. so nothing useful here.

The LCD controller for the Clip is very similar if not identical to controllers for other rockbox targets, and it may be the same for the E200: check the controller model on the wiki page for E200 port
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on October 07, 2008, 07:55:52 AM
Hi,

Quote from: funman
The LCD controller for the Clip is very similar if not identical to controllers for other rockbox targets, and it may be the same for the E200: check the controller model on the wiki page for E200 port

Hmm I really doubt it, if I remember correctly, the display controller on the e200 serie is an ILI-something. Anyway, it is a color display so it wouldn't work with the SSD1303 ;)

Quote from: funman
I think the power-off is software driven, because on the Clip I see a logo animation before it shutdown.

Oh that's some news, I didn't noticed. Though I think there is an hardware "recovery" power-off if you hold the power button long enough (about 4-5 seconds). I often used it with infinite loops broken test firmware ;)

Gitorious is back, yay! (See ya later peeps)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on October 07, 2008, 09:26:35 AM
Quote from: funman
The LCD controller for the Clip is very similar if not identical to controllers for other rockbox targets, and it may be the same for the E200: check the controller model on the wiki page for E200 port

Hmm I really doubt it, if I remember correctly, the display controller on the e200 serie is an ILI-something. Anyway, it is a color display so it wouldn't work with the SSD1303 ;)

I meant another rockbox target (not the Clip) may have code for a similar controller.
But first you need the initialization sequence, which is specific to the E200v2.

Quote from: funman
I think the power-off is software driven, because on the Clip I see a logo animation before it shutdown.
Oh that's some news, I didn't noticed. Though I think there is an hardware "recovery" power-off if you hold the power button long enough (about 4-5 seconds). I often used it with infinite loops broken test firmware ;)

Note also that if you boot the OF, you need to press the power button at least 4-5 seconds, but with my tests, 1/2 second is enough (when using my custom code).

So that "recovery" power off is customizable, and the time needed to hold the power button is extended by the OF.

Is it similar on E200/Fuze ?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on October 07, 2008, 10:07:18 AM
There's two power offs. The one where you see the goodbye logo, which should be software driven. The other, were the device is powered off immediately, is doutfully software driven, that'd render the purpose of "emergency power off" useless.

On the e200v1, this emergency power off was also hardware driven.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on October 07, 2008, 06:35:50 PM
I have put the patch for Clip port on the patch tracker: FS#9467 (http://www.rockbox.org/tracker/task/9467)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Hillshum on October 09, 2008, 09:12:56 PM
Don't get mad at me, but I think putting a hacked firmware image on my sansa has made it not support drm. Hey, I only free drm(aka Overdrive). So yeah. Bad for dualboot. I've looked for a solution and tried all kinds of things, including clean firmware, none have worked.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Llorean on October 09, 2008, 09:40:07 PM
Installing Rockbox on h300 also requires the loss of DRM support. If that happens, it happens, we're not going to get particularly upset about it. It would be ideal to find a way to avoid this, but if not, ah well.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on October 09, 2008, 11:48:40 PM
Hi again,

well I hacked a bit tonight on the clip buttons and found all of them. As I suspected, the clip uses a similar keypad scanning technique that was used in the M200. The principle is to rise a "column" pin, read all "row" pins, then lower the column pin, then go to the next column, etc. The clip keypad has 3 column pins (C4 to C6) and 3 row pins (B0 to B2).

So well I updated the firmware so that it will display all pressed buttons on the screen in our git repository (http://gitorious.org/projects/rockbox_sansa_v2). You can have a look at this (http://gitorious.org/projects/rockbox_sansa_v2/repos/mainline/blobs/master/firmware%2Ftarget%2Farm%2Fas3525%2Fclip%2Fbutton-target.c) for the buttons details and this (http://gitorious.org/projects/rockbox_sansa_v2/repos/mainline/blobs/master/bootloader%2Fsansa_as3525.c) for the sample firmware.

See ya!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on October 10, 2008, 12:09:32 PM
Thanks atomikpunk, I tested your code and I confirm it's fine.

I had a quick look at the FuZe firmware, and couldn't see similar code at a similar location, so maybe something else is used to get the buttons (maybe the 10 bits general purpose ADC mentioned in the AS3525 datasheet).

kugel don't hesitate to ask if you need help to understand how the buttons are read on the FuZe.

However I don't feel like reading the FuZe disassembly all night long, so I leave this task up to you ;)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: JdGordon on October 12, 2008, 12:46:02 AM
hey guys,
just joining the party and saying I have a 2gb e200v2 which im looking forward to hacking... I cant do much untill after my exams (mid november) but if anyone has something they want tested on it let me know.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on October 12, 2008, 03:36:31 PM
Hello, some news about the SD:

I have some code but I don't get past the initialization procedure (card power up, aka acmd41).
The acmd41 response is 0xFF8000 : it contains the supported voltages (all), but the bit31 is unset, which means that the card is not ready.

I tried issuing a cmd8 before acmd41 (it is required for SDHC cards) but I receive "command response timeout", which would mean this command is not supported.

EDIT: I removed the answer to the post that was just deleted - I don't think an offer to help is spam...
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: jesterday on October 15, 2008, 04:46:22 PM
Hi,

i have not read the whole thread, in fact i wouldn't understand half of it :-) .

Maybe this is already know in the meantime (have not found anything by using the search) or completely useless at this state, but switching on a e260 holding power button, forward and rewind simultaneously (state of lock button is of no importance) lead to a screen asking "Erase Firmware? Press center Button to confirm". Any other button press switches off the device.

Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: andva on October 15, 2008, 07:03:03 PM
Nice find, jesterday! I can confirm that the message pops up on my e280. I'd expect that pressing Center will put the player in some kind of rescue mode. If the player accepts unsigned firmwares in that state, then life is beautiful :) I wasn't courageous enough just yet to hit the Center button, though; anybody with the possibility of shorting the NAND pins (in case everything gets broken) volunteering out there?

A word of warning: I remember reporting that the "erase firmware? press center button to confirm" message is present _in_ the firmware file, which means that this recovery mode might be dependant on an original firmware being present on the player. So if you ever uploaded a 'broken' firmware (or, God forbid, a homebrew one), you would be deprived of this easy way out. Retarded, you know, but... worse things have been seen.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: mike16889 on October 15, 2008, 07:10:58 PM
got the same message on my e260v2 but hold had to be on. not game enouth to oress the center button cuz i still want to use my player...
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Hillshum on October 15, 2008, 08:06:14 PM

I just pushed it to erase, but it seems to work normal.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on October 15, 2008, 09:22:10 PM
Spacing on the presumed fuze JTAG connector is much smaller then the M200, so 30 gauge wire probably isn't going to work.  I'll have to try and find some smaller wire.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: daniel_at on October 16, 2008, 04:29:20 AM
The "reset firmware"-mode: Have tried the center-button, device switches off, after power on it stuck after showing the sansa-logo, after some power-cycles it booted normal into the OF without any restore-action taken.

@jesterday, How did you find that mode? By accident, or is there something about it on the net already?

@saratoga, Try to find a so-called "enameled wire" (it can usually be found in transformers and inductivities). There exists different, very thin copper wires of that type. I often use them to connect to small pads. Like here, i connected a serial interface to a destroyed iPaq-Connector: http://danyserv.selfip.org/pic/displayimage.php?album=21&pos=1

Use a very small solder-iron tip. You can also make a homebrewn solder tip by wrapping around a ~2mm thick copper-wire around your existing solder tip and file it very pointed and use that for soldering. Sorry, hard to describe, i hope you understand what i mean, cant currently find a picture of it.

[edit]
The Masked ROM-Image: uploaded the completed version of the dump (merged four reads into one, so that missed addresses get completed) to the git:
merged_dump.bin.bz2 at http://gitorious.org/projects/rockbox_sansa_v2/repos/mainline/trees/master/hacking/bits

Daniel
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: jesterday on October 16, 2008, 11:06:50 AM
@daniel_at:
not by accident and not bv webfind :-). I just played around cause i read about the special mode on the m-series. I watch this thread for 1 or 2 month, so i think maybe i could do something useful ;-)

@mike16889:
interesting! I've tested it several times, on my player it works with or without the hold button. Maybe you haven't accidently not all the button all the time?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on October 16, 2008, 02:55:38 PM
Very nice finding everyone. Daniel, I had a look at the ROM binary disassembly yesterday night and well, as funman said some of it looks very familiar with the OF but it is no surprise in my opinion. I don't know much about it yet, but a quick look at the contained strings, I can easily find the "M200Plus" string we saw when using the "recovery" mode... ;D

Use a very small solder-iron tip. You can also make a homebrewn solder tip by wrapping around a ~2mm thick copper-wire around your existing solder tip and file it very pointed and use that for soldering. Sorry, hard to describe, i hope you understand what i mean, cant currently find a picture of it.

If you guys can get a hand on "flux", it _really_ ease soldering small parts and wire. It should be quite easy to get at a specialized electronics distributor and/or reseller. You just put a lot of it on the part to solder, use a standard to small soldering tip and stain will glue to the pads. Just as an example, I can solder very small packages (with <= 0.5mm pads pitch) with a >2mm tip (yes, the tip is really bigger than the pads)... ;) Just be sure to clean the PCB region afterward if the flux is not self-cleaning.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: jesterday on October 16, 2008, 05:43:07 PM
I seems to me this "reset firmware"-Mode does nothing :-(. If i hit the center, it, as reported before, simply switches off. I even can't see that switching on again takes any longer as normal.

So i tested around a little bit.
Only thing i discovered is, that if you plug in the e260 in this mode, a new usb device is found which can't be enumerated. Same can be archived if you connect first the device, then switch off and on again with the know button combination. Difference is, that no answer is displayed this way, only the logo.

Linux output of dmesg is:

Quote
[ 3049.972884] usb 4-2.3: new full speed USB device using uhci_hcd and address 11
[ 3065.048437] usb 4-2.3: device descriptor read/64, error -110
[ 3080.227910] usb 4-2.3: device descriptor read/64, error -110
[ 3080.419764] usb 4-2.3: new full speed USB device using uhci_hcd and address 12
[ 3095.495317] usb 4-2.3: device descriptor read/64, error -110
[ 3110.674790] usb 4-2.3: device descriptor read/64, error -110
[ 3110.866645] usb 4-2.3: new full speed USB device using uhci_hcd and address 13
[ 3115.882837] usb 4-2.3: device descriptor read/8, error -110
[ 3120.998952] usb 4-2.3: device descriptor read/8, error -110
[ 3121.193803] usb 4-2.3: new full speed USB device using uhci_hcd and address 14
[ 3126.209994] usb 4-2.3: device descriptor read/8, error -110
[ 3131.326111] usb 4-2.3: device descriptor read/8, error -110

still got the feeling this thing is no help anyway... :-)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: mike16889 on October 17, 2008, 07:52:41 AM
i re tried and it douse work regardless of weather the hold is on or off.

@jesterday. did you have an updated (or custom) version of firmware running when you hit the center button? maybe it reloads the stock firmware?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: tobi-lu on October 17, 2008, 08:00:53 AM
I tried it on my e250, and it doesn't seem to work at all, regardless of the "hold" state. I have a custom firmware (compressed OF + 5sec delay). It always loads normally.

I'm pressing the back, forward and power button at the same time, is this correct?



edit: Aaah nevermind, it just worked, dunno why ???

edit2: OK, I just didn't hold the buttons long enough.
But there's nothing happening... no matter which button I press, the player just turns off and everything is like it was before.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: jesterday on October 17, 2008, 08:56:14 AM
non-modified actual firmware (03.01.16F). So far i can see, nothing is changed or even done when hitting the center.  :-\

Anyone played around with the MTABLE, RES_INFO, SYS_CONF sys files or the version.sdk?
The warning in the version.sdk file seems  senseless, as it is restored (like the other files) when changed or removed.

As the files obviously are checked when booting, maybe we have to modifiy them to get the Erase Firmware to work (as example changing the Firmware Text in ERASE or something other)? mentioned one i tested of course.
Just some thoughts

have a nice WE

jesterday

EDIT: Has someone done the work of find out the "meaning" (damm, cant remeber the right word :-) ) of the values in SYS_CONF.SYS? Can this be of help in any way?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: lassowski on October 17, 2008, 09:26:47 AM
Hi!

Perhaps this feature removes a e200xx.bin firmware image from the disk before the player is upgraded with it?

Just a thought...

Frank
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on October 17, 2008, 09:30:13 AM
The erase firmware is probably just a feature that Sandisk never enabled, which is why they don't mention it and why it doesn't seem to do anything.  Firmwares for mp3 players are highly modular, with parts provided by different vendors.  Just because something is included doesn't mean its actually used.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Domonoky on October 18, 2008, 06:59:10 AM
Hey,

i just got a sansa m200v2 and want to help out. I have tried the clip bootloader from the git tree, but unfortunatly the buttons are different on the m200v2, so it only starts the OF for me.
 
The SansaV2Firmware wikipage tells the sansa has a 4x4 keymatrix and no directly connected buttons. So i want to try to find those buttons. I have successfully inserted a delay loop, so i know the bootloader is running, and i want to use the this delay to check for buttons.

Unfortunatly i dont know too much asm, so i am still struggeling to set those GPIO pins correctly.
As far as i know, i should set one of A4-A7 to output, then write a 1 to this output, and then check A1-A3 for changes. Could someone help me with this ?  ( i am not afraid of bricking).

EDIT:
with the help of others i found nearly all buttons and put them on the SansaV2HardwareMappings wiki page.
Now i can boot into rb-bootloader if i want, but i get no reaction as lcd and backlight dont seem to work, and there is no led on this player. So next task would be either lcd driver or backlight..

EDIT:
we can control the backlight now. LCD is still unknown. Seems to be different to the one from the Clip.


greets

Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on October 18, 2008, 08:05:14 PM
Something shocked me while I was discussing with anythingbutipod people: in the diagnosis mode of the Clip there is a "SDRAM Test" which reads:
Quote
bus = [16] bits
SIZE = [2] MB
R/W TEST [PASS]

bertrik also mentioned seeing code related to external memory.

And finally the loading addresses of 2 drm library blocks, plus the "otg_functio" and "usb_functio" blocks are after 0x30000000

In the AS3525 datasheet the memory between 0x30000000 and 0x3000FFFF is "External Memory IF (MPMC Bank 4 - SDRAM)"

All this lets me suspect that the assumption that there is no SDRAM on the Clip (V1) is wrong.

By the way why do you suspect there is no SDRAM on the Clip ?


I tried writing to 0x30000000 and reading back but it failed, I suppose we need to initialize the SDRAM before using it.

EDIT: it seems the Clip ships with the 224 BGA AS3525 (with memory controller ARM PL172 (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0215e/index.html))
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Domonoky on October 19, 2008, 06:13:57 AM
Another update for the m200v2:
Funmans merge of the ssd1815 driver with the dbop commands works, and i can see the rockbox logo on the m200v2 !! *yeah*
So the LCD for the m200v2 is really the  ssd1815 :-)

Edit:
you can see rockbox on m200v2 here: http://www.retrospektiwe.de/sansa-rockbox.JPG :-)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on October 25, 2008, 08:18:48 AM
Hi !

I can know read and write to the 2MBytes of SDRAM embedded in the Clip ;)

I've put my code in the flamed git repository: see this commit (http://gitorious.org/projects/rockbox_sansa_v2/repos/mainline/commits/7799241e0b27efac667ba43a4a9251682f513d55) and this one (http://gitorious.org/projects/rockbox_sansa_v2/repos/mainline/commits/c91e1b03461ffc7e9916f7686c251e3a81079507)

Now I'll speak with the rockbox developers to commit that in the rockbox svn tree.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on October 25, 2008, 09:43:04 AM
Hi !

I can know read and write to the 2MBytes of SDRAM embedded in the Clip ;)

I've put my code in the flamed git repository: see this commit (http://gitorious.org/projects/rockbox_sansa_v2/repos/mainline/commits/7799241e0b27efac667ba43a4a9251682f513d55) and this one (http://gitorious.org/projects/rockbox_sansa_v2/repos/mainline/commits/c91e1b03461ffc7e9916f7686c251e3a81079507)

Now I'll speak with the rockbox developers to commit that in the rockbox svn tree.

Great news.  This will save us a lot of trouble rewriting how the codecs use memory for the clip port.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Domonoky on October 25, 2008, 11:11:48 AM
Hi,

i can confirm that this sdram code also works on the m200v2. (which has 2MB external SDRAM).

Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Hillshum on October 27, 2008, 04:31:34 PM
Hi,

i can confirm that this sdram code also works on the m200v2. (which has 2MB external SDRAM).



and the e200v2
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on October 28, 2008, 08:16:21 AM
Hello !

I was accepted into the committers, and I have committed the SDRAM code in rockbox SVN.

Next step: commit the SD driver embryo so people who hadn't noticed our git tree yet can look at it.

Once it's done, everything will be in SVN and there will be no need to commit code in the git repository.
If you want to work on the SVN tree just ask the developers or send me your patches!

By the way you can work on the rockbox SVN from a git-svn repository, there are instructions in the wiki on how to do so.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: ChiefAlex on October 28, 2008, 08:43:07 AM
hi together.
I own a Sandisk Fuze and e260 (V1, with rockbox running on it) .
I would love to see Rockbox on the Fuze as well. If i can help you with my player (but without risk to "kill" it) let me know it.  :)

(edit: i'm german, so any commands in simply english)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on October 28, 2008, 08:51:32 AM
Hey, I'd gladly accept help on creating a feedback mechanism for testing on the Fuze.

As of now, neither LCD nor button light nor backlight works (i.e. no visual response at all). Buttons are unknown too. The only feedback mechanism is the 5s delay loop which tends to be annoying and time intensive to work with.
Anyone with greater experience in OF disassembling than me have a look at the Fuze OF and help me getting at least the button light to work; of course LCD would be nice too :)

I've really not enough time to spend much time on the port (which means I cannot really catch up to your knowledge at this time), so I'd really need help to get the Fuze further.
 

saratoga: How's your JTAG going? Did you already receive the correct hardware (the first one you got was too big IIRC).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: linuxstb on October 28, 2008, 10:02:34 AM
There are still things that people not involved with the low-level hacking can do to help the ports along:

1) Add the Fuze (and c200v2) to the build system.  This would just be a matter of copy/paste of the existing code for targets already in SVN (clip, e200v2, m200v2).

2) Start work on all the UI simulators for these targets. 

The UI sims will all need a photo/scan of the externals of the device (resized so that the area of the LCD is the real LCD's resolution) for use as the background image (or possibly just copied from the V1 targets, where applicable).

The e200v2 sim should be the easiest to get working, as this uses the same keypad definition as the e200v1.  Other targets may need keymaps defining for the Rockbox apps/ code, plus all the plugins.

Making the UI simulators work means doing the majority of the work needed in getting the main Rockbox code working (after the low-level drivers).

Patches welcome (on Flyspray)...
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: ChiefAlex on October 28, 2008, 10:34:27 AM
Fuze could use the same keypad because buttons and wheel are the same just "menu" button is top right (botton left on e200).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on October 28, 2008, 12:12:43 PM
linuxstb, I already added the Fuze to the build system. funman added my patch to the git repo back then. I've somewhere the patch around, hopefully I find it.

For the keymap, it's similar to the e200 one yes. It just lacks the REC button, but has Power split up in a Power and Home button.

Maybe I'll give it a shot in the tiny bit of free time.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: linuxstb on October 28, 2008, 01:05:13 PM
kugel,

It would be ideal if you could create a patch against current SVN and upload it to flyspray.

It unfortunately sounds like the Fuze is going to need it's own set of key mappings.

I had a quick look at the e200v2 sim myself, and it turned out to be very quick to get working, so that's now committed to SVN.  It's not actually very useful (it is identical in use to the e200v1 sim), but it's another small box to tick in the porting process.

Dave.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: jesterday on October 28, 2008, 05:46:56 PM
i like the idea of "everyone does his part" to get things work (hmm. sounds a bit like socialism... *lol* ).

So, as i'm not firm in "low-level hacking" and also i'm al lousy writer and speaker of english, i would be glad, if i could help in any way to archive this.

To speak clearly: i anyone,who speaks german, is working on this, i would be proud to help. i own a E260 and got basic knowledge on coding "machine code" (hey, i know the dez. value of the unconditional return on Zilog Z80 *lol* ...201 btw.). No fear of "dirty work", if have time to. But i think time is not the thing we sould care about..

bw

jd

Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: mc2739 on October 28, 2008, 09:26:55 PM
We now have a semi-working display on the e200v2. Still some issues to be worked out.

Sorry for the poor quality of the pic.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on October 29, 2008, 07:36:44 AM
Looks very nice! I wonder if you can estimate how similar the LCD driver will be for the Fuze (given that the Fuze display is just "rotated").
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on October 29, 2008, 08:39:57 AM
Great news !
Now the e200 is only left behind for the buttons, but hopefully the display will make it easy to figure them.

@kugel: the FuZe doesn't look like it uses the same controller (based on disassembly)

In firmware V4.0.45 the dbop_init routine is at 0x3428 and the lcd_init at 0x354C if there is any volunteer
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on October 29, 2008, 12:54:46 PM
Hi everyone,

it's been a while since I wrote but it's just hectic at work wince 2 weeks. Anyway, I'm still following the forums and (unsuccessfully) try out stuff for the SD.

For the fuze, I can have a look when I'll have some spare times, but meawhile, if someone would volunteer to get me all serial numbers that could appear on the LCD and/or its flat cable, I could have a look if I can find the related LCD controller and thus help out coding the driver for it.

Good work everyone!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on October 29, 2008, 01:52:09 PM
When I took my Fuze apart I didn't find any numbers on the lcd or the cable. But ask saratoga, his is open at this time AFAIK.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: linuxstb on October 29, 2008, 02:07:08 PM
I'll probably have a go at writing an LCD driver, similar to what I did for the e200v2.  Hopefully once we start having a C version of the init function, someone will be able to identify the controller.

It would be useful if in the meantime, someone could add the Fuze to SVN (or post a patch doing so).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on October 30, 2008, 11:11:53 AM
Hi

Just to let you know the mirrored/rotated display on the e200v2 is fixed : you should have perfect display / colors.

Also mc2739 told us the SD code works on the e200v2, so if you have one you can help writing the SD code to finish the bootloader.

Unfortunately for Clip / m200v2 the SD card power-up phase doesn't complete and I have no idea why :(

What the OF does after the reset vector is:

I tried to reproduce this behaviour, but still no luck ..
Of course you're welcome to look at the code and see if I have forgotten some bit.

If we can't find what we miss by disassembly, then perhaps a JTAG connection to check the registers statuses will help: I have ordered an adaptor which should ship in 2/3 weeks
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Darkstylist on October 30, 2008, 02:09:01 PM
Seems like you're far into your sansa build why not release an alpha that we could try out with sources included ? i wont mind testing an unfinished rockbox on V2
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on October 30, 2008, 02:16:23 PM
Seems like you're far into your sansa build why not release an alpha that we could try out with sources included ? i wont mind testing an unfinished rockbox on V2

There is nothing to test at this moment : the effort is ONLY for developers.

When there will be something usable, builds will be available on the download page.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: mc2739 on October 30, 2008, 05:21:11 PM
Also mc2739 told us the SD code works on the e200v2

I'm not sure what I saw to make me think that the SD code was working, but it is not.  The test loops with "OP COND: 0xFF8000" displayed. It never gets to "now - card ready !".

But, some good news, I did get the buttons working (at least the ones already documented on the SansaV2HardwareMappings wiki). The problem was the dual function GPIO's. GPIOB and GPIOC are used for buttons and LCD. The LCD code blocked access to the buttons.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on October 30, 2008, 05:30:26 PM
About the SD, fragilematter just tested the code on his e200, but for the SD slot with a 128MB SD card in it, and here it succeeds: proof (http://img389.imageshack.us/my.php?image=dscf0004fv8.jpg) .

That means a bootloader which loads rockbox from the SD card could be developed until we find what's missing to use the embedded SD card.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: mc2739 on October 30, 2008, 06:27:29 PM
It also detects my 4GB card and correctly identifies it as "High Capacity".
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: linuxstb on November 01, 2008, 05:43:30 AM
The main Rockbox website is currently unavailable, so people may not see this, but I've just committed the Fuze to SVN, including my first attempt at an LCD driver.  (this doesn't use Kugel's work on adding the Fuze to the build system, as I couldn't access that patch this morning - I had to redo it myself).

This needs testing by a Fuze owner.  Details of the commit are here:

http://svn.rockbox.org/viewvc.cgi?view=rev&revision=18957

It's using the backlight code from the e200v2 - I don't know if that has already been tested or not.  The LCD driver itself is still in a very raw format, but I'm hoping it's working...
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on November 01, 2008, 09:19:40 AM
Ok, I'll give it a shot in a few minutes.

Edit: No success :(

I've done some changes changes (such as correcting firmware/SOURCES) which shouldn't break the lcd code though if it was working.


I'll upload my svn diff to the tracker, it includes a keymap and a simulator. FS#9512
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Mac n00b on November 01, 2008, 01:53:52 PM
I have been snooping around in some of the latest IRQ logs, and discovered that you are in the need for some Clip-pictures for the Simulator, here are two pictures i have taken myself, you are free to use them anyway you want:

http://img222.imageshack.us/my.php?image=clipsimyg4.png
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on November 01, 2008, 03:05:25 PM
Good news! After adding _buttonlight_on() to the bootloader, I saw this:
(http://www.alice-dsl.net/simonemartitz/rockbox/rockbox_on_fuze.JPG)(http://www.alice-dsl.net/simonemartitz/rockbox/rockbox_on_fuze2.JPG)

Rockbox logo on the Fuze! Good job guys.

PS: Sorry for the crappy quality. I only have a mobile phone camera. The logo is rather light blue than yellow.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: bombjack on November 01, 2008, 04:39:09 PM
I fixed the Clip image a little.
Its far from perfect but at least usable I think.

Strangely enough the same file looks much better in gimp than in firefox?!

Grab it from here:
http://img504.imageshack.us/my.php?image=sansaclipfc1.png

Hope I could be of help.

Great work you're doing here! :)

(http://img504.imageshack.us/img504/2332/sansaclipfc1.png) (http://img504.imageshack.us/my.php?image=sansaclipfc1.png)
(http://img504.imageshack.us/img504/sansaclipfc1.png/1/w889.png) (http://g.imageshack.us/img504/sansaclipfc1.png/1/)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on November 01, 2008, 06:29:53 PM
Hello

Great finding for the fuze, the only targets without display are now the c200v2 and the still mysterious Clipv2 !

Thanks for the images, but there is already a background image for the Clip simulator here (http://svn.rockbox.org/viewvc.cgi/trunk/uisimulator/sdl/UI-clip.bmp?revision=18948)

If you have noticed FS#9512 (http://www.rockbox.org/tracker/task/9512) we miss an image for the Fuze however..
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: bombjack on November 01, 2008, 10:12:49 PM
Ok, seems like somebody has been missing something ...
Just trying to figure how things work here.

Anyway: What about this Fuze then?

(http://img260.imageshack.us/img260/5919/sansafuzerx0.th.png) (http://img260.imageshack.us/my.php?image=sansafuzerx0.png)(http://img260.imageshack.us/images/thpix.gif) (http://g.imageshack.us/thpix.php)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: linuxstb on November 02, 2008, 11:22:42 AM
The initial version of the Fuze LCD driver had corrupted colours, but that's now been fixed.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on November 03, 2008, 09:38:43 PM
Hello

Good news today: I am able to hijack the Clip OF and branch to my (modified a bit to not disturb the current state) bootloader.

Thanks to the help of mc2739 who helped me testing & debugging the code on his unbrickabe e200, and not thanks to the numerous and still unexplainable data aborts which slow down the procedure, I can now look at the OF state precisely.

Oh and I chose carefully the location where I branch from the OF to my bootloader: it's exactly when the embedded SD card answered "I'm powered-up", i.e. the bit 31 of the response to acmd41 is set.

Yesterday mc2739 was not answering (or just a bit since it appeared in lsusb, but not as a mass storage device); let's hope it works again when he comes back!

For now I checked the i2c registers (http://paste.ubuntu.com/66697/) and the pl180 registers but there is nothing interesting there..

Next step is to check GPIO directions & values (now I can't run the test presumably because of the data aborts).

EDIT1: GPIO checked, they just show what we set in the lcd init routine
EDIT2: GPIO re-checked, before the lcd init routine :-X and they all are on input

If you hackers have a clear idea of what to check just tell it, or contact me to have the hijacking code (I don't want to give it to everybody to avoid people bricking their devices just to be on the razor edge, especially if they don't have anything clever to test)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on November 04, 2008, 03:12:45 AM
I'd like to have this code in order to check the Fuze GPIOs. They're more or less unknown at all (except A3).
That should help finding the buttons at least.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on November 04, 2008, 03:27:20 AM
It wouldn't give you anything else than the directions and values.

If you already tried to read them one by one and it failed, i see no other solution than looking at the disassembly.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on November 04, 2008, 06:12:06 AM
Don't you think it helps if I compare the GPIOs before and after the OF touched them?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on November 04, 2008, 08:23:43 AM
kugel I think you misbelieve what is "touching": the OF will not do anything except changing the direction registers (each pin is input or output) and write values into the pins set as output.

If it's output, then you'll get the value written (useless for the keypad)
If it's input you'll get nothing more than what you tried to read already.

Also if you want to get something from the OF you must be sure that it has made this information available before overwriting the bootloader with code loaded from SD.
In the Clip case, the GPIO registers aren't even accessed before that step.

In fact if you want to modify the code I use for the Clip you'll need to disassemble and study your fuze firmware first; so why not starting it now ?

It's not something impossible, and once you start i and others will of course be able to give you advices.


On the Fuze the buttons could very well be accessed via a special controller, in fact we can imagine everything until someone do the hard work and start disassembling the firmware.

The LCD code was easy to do, linuxstb did it in less than one day I believe; but if he hadn't looked at the disassembly it wouldn't have been present.


So I only have one thing to say: do it ;) (and you can count on my help, but not to do it for you)

EDIT: remove a french word spotted by BigBambi
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on November 04, 2008, 08:55:23 AM
Hi again peeps,

well I wouldn't mind having a look at the fuze OF, but I'm quite busy at work these days and it'll last up to next week. So if you don't mind waiting for next week (and the time needed to find the buttons), I can have a look for you.

Of course if you decide to do it yourself or give a hand, be sure I'll help too.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on November 04, 2008, 09:32:32 AM
I have some information about the big function which initializes the SD card (I call it 'init_card')

First the prototype is init_card(int drive, int MMC_STATUS_value, int *command_response)

More precisely, this function is called from an higher level function which initializes the PL180 controller, and then call init_card().
I call this higher level function 'init_chip'

In the first call, the function at offset 0x18 is set to NULL, and since we see it in the structure dump, that means that the first call failed, and the second one succeeded.

The difference between failure and success is in:

I insert my branch code instead of these instructions (thumb code):
Quote
ldr    r0, [r7]       @ r7 points to the acmd41 command response, so r0 contains the response
asrs  r1, r0, 31   @ if the bit 31 was set (meaning card ready), now r1 == 0xffffffff
adds r1, #1        @ if the bit 31 was set, now r1 == 0
beq  card_ready @ if the bit 31 was set, branch to card_ready

...

card_ready:
lsls r0, r0, #8
lsrs r0, r0, #8    @ clears the 8 most significative bits
str r0, [r4, #0x14] @ store the result in memory (it indicates the supported voltages)
ldr r0, [r4, #0x8]

I have put the branch at the location card_ready, so as soon as the correct response is detected, it executes the bootloader.

To dump the content of the structure when the first call to init_chip returned, I have put my branch between the 2 calls to init_chip function.

CAUTION: Don't forget the OF code is interrupt-driven !
The 2nd call to init_chip returns when the procedure is still ongoing through the interrupts (init_card is called back from the isr, again, and again)
The OF uses a busy loop (checking CmdActive bit of MMC_STATUS) to know when it completed.

I dumped the structure used in the SD code (of size 0xEC bytes), here it is:
Quote
offset - value when acmd41 succeeded - (value when 1st call returned if different) - comment
00  C8000000 @ pl180 controller base
04  3D09000 = 64000000 = clock reference (64MHz, probably CGU_PERI)
08  0          @ card selected (value written in MCI_SELECT)
0C  0
10  1 (0)
14  0xFF8000 @ the supported voltages
18  6429 (0)  @ a function called at various places in the init function
1C  45E9 (0)  @ the command response handler (it is the init function itself)
20 - 24 : 0
28  0          @ another function, always set to 0 (NULL)
2C  4 (0)
30  400 (0)
34  3           @ the clock divider for "high" frequency of 20MHz (64/20 == 3)
38 - 44 : 0
48  0           @ here it's weird, it should always be set to 1, and this value -1 is written into MMC_SELECT, not sure why it's 0 there (to analyze)
4C - 60 : 0
64  10
68 - 74 : 0
78  4D (0)  @ the loop counter for acmd41 (starts at 0x50, decremented each time acmd41 fails, abort when it reaches 0)
7C  1FF    
80  1FF     @ I'm not sure, but it corresponds to the maximum clock divider we can use in MMC_CLOCK (511 == 255*2 + 1)
84 - A4 : 0
A8  8 (1)  @ The status of the card in the intialisation (detailed after) , here means we were reading the acmd41 answer
AC  1  (0xffffffff)
B0 - D0 : 0
D4  1 (0)  @ To check carefully, at some point, thevalue 1 seems to mean SD (as opposed to MMC), but it is set to 2 and 0 as well .. quite a few branches depend on it, to investigate
D8  0   @ Indicates if the card is SDHC or not
DC - E8 : 0

Here are the values I have found for the offset A8 of this structure (the status)

Note that higher values are used in another function, they probably have meaning for data transfer

Hope that narrows the research we have to do

See you
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: calv on November 05, 2008, 03:57:50 AM
You could set all GPIOs (except those needed for display) to read, and read them in a loop and display for each bit a pixel, so you can see the status. Then you can see the response of the buttons directly on the screen.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on November 05, 2008, 09:42:03 AM
Hello, I had another idea I already experimented on 'real' OS like windows & linux to understand what they needed to boot: delete stuff until it doesn't boot anymore ;)

So far I disabled some functions (one by one, not all in a row), by writing a 'bx lr' instruction at their entry point


I also replaced the function used in field 0x18 of the structure (which was only set for the 2nd call to init_card) by NULL.

And each time the OF booted fine, which meant it had access to the SD

I also disabled this ones:

And each time the OF didn't boot (black screen).
That doesn't mean the SD init didn't work because these functions are likely used to transfer data, and if it can't transfer the boot logo from SD we can't see it.
Of course I suppose the logo is loaded from SD, but I have no evidence of this.

Something else: before dumping the content of the structure between the 2 calls to init_chip, I made sure all the interrupts had been executed, and the voltage wasn't set so the function failed.

Now I'm running out of idea of what to disable with a single instruction write (I don't want to modify too much mkamsboot by fear of bricking my Clip).

Now that we can ignore those functions, reverse engineering is getting a little bit simpler ;)


EDIT:
After resting a bit, I see the first call to 'init_chip' will in fact shut down the controller, and not call the 'init_card' function at all, so we only have one call (well plus the times when it's called from  the isr) to analyze.
That explains why they were not waiting for the status of the SD to be cleared ^^
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Moarc on November 07, 2008, 05:17:32 AM
I'm very happy to help out on this project if I can. I do not want to damage my current c250, buts thats an easy problem to solve - I just went out and bought another one. The local store is selling them for about $22 dollars US so its not much to spend if it'll help get Rockbox up and running on one.
So fire away - tell me what you want and where to get the info i'll need to do it, and I'll do what I can to help.

 ::)

You can:
- help us with hacking original firmware
-  disassemble your playes and send us scans/photos of hardware
- get $22 from us, buy a player and send it to somebody of us :p
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on November 07, 2008, 06:11:31 AM
First thing to do is to find out at least one button so we can use it to dual boot and add the c200v2 target in the rockbox tree.

To do that you need an old version (revision 18706 is fine) of mkamsboot, the one in svn is too complex.

You will patch your firmware with a check for 1 gpio pin (there is 64), and it the OF will boot immediately or with a little delay, depending on the value of this pin.
Then start the OF, note the presence or not of the delay; shut it down; start it again while pressing a button, note if the delay changed.

Note that you'll need to modify the test.S file to include the button check.

Maybe it'll be easier to come on IRC to do that.


Something else, I've gained access to the embedded SD card !
The diff (http://svn.rockbox.org/viewvc.cgi/trunk/firmware/target/arm/as3525/ata_sd_as3525.c?r1=19035;r2=19036;pathrev=19036) is really small but was hard as hell to find :)

Next step: implement the full SD protocol to read (write can wait) a firmware file from it and boot it.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: fragilematter on November 07, 2008, 10:27:28 AM
Also tested on e200v2:

(http://img139.imageshack.us/img139/5540/dscf0037lb7.th.jpg) (http://img139.imageshack.us/my.php?image=dscf0037lb7.jpg)(http://img139.imageshack.us/images/thpix.gif) (http://g.imageshack.us/thpix.php)(http://img139.imageshack.us/img139/6517/dscf0038bh2.th.jpg) (http://img139.imageshack.us/my.php?image=dscf0038bh2.jpg)(http://img139.imageshack.us/images/thpix.gif) (http://g.imageshack.us/thpix.php)(http://img89.imageshack.us/img89/1466/dscf0039ha3.th.jpg) (http://img89.imageshack.us/my.php?image=dscf0039ha3.jpg)(http://img89.imageshack.us/images/thpix.gif) (http://g.imageshack.us/thpix.php)

Funman awesome job dude!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: gabe565 on November 07, 2008, 12:46:41 PM
Just tested on my Fuze, it does the same thing that fragilematter 's e200 does. I don't have a camera with me right now, but I will have a picture up soon!


EDIT:(http://i171.photobucket.com/albums/u319/gabe565/a5ddcd33437a1.jpg)
Here's a really bad picture taken with my phone, you can barely tell what it says, but it works for now.
It says:
Quote from: Sansa Fuze
Loop number #2
OP COND: 0x80FF8000
now - card ready !

EDIT 2: I know this is a stupid question, but is there a dual boot yet, or should I just reinstall the regular firmware?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on November 08, 2008, 01:46:38 PM
My today findings:

a) On the Fuze, you need to have the backlight on for the buttonlight. GPIO D7 is the button light, but setting it high doesn't do anything without lcd backlight. That's the reason I thought it's not D7 in the first place, we just didn't have backlight, and so buttonlight didn't work.

b) I can 'access' my external microSD after #defining HAVE_MULTIVOLUME. Without a mSD inserted, it reads *PANIC* response timeout, and with a mSD inserted, it reads card ready just like with the internel one. It also needs 2 loops for the external card.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: RockRabbit on November 08, 2008, 09:25:35 PM
First thing to do is to find out at least one button so we can use it to dual boot and add the c200v2 target in the rockbox tree.

To do that you need an old version (revision 18706 is fine) of mkamsboot, the one in svn is too complex.

You will patch your firmware with a check for 1 gpio pin (there is 64), and it the OF will boot immediately or with a little delay, depending on the value of this pin.
Then start the OF, note the presence or not of the delay; shut it down; start it again while pressing a button, note if the delay changed.

Note that you'll need to modify the test.S file to include the button check.

Maybe it'll be easier to come on IRC to do that.


Something else, I've gained access to the embedded SD card !
The diff (http://svn.rockbox.org/viewvc.cgi/trunk/firmware/target/arm/as3525/ata_sd_as3525.c?r1=19035;r2=19036;pathrev=19036) is really small but was hard as hell to find :)

Next step: implement the full SD protocol to read (write can wait) a firmware file from it and boot it.

I''ll need to know the following:

1. Where to get version 18706 of mkamsboot
2. How to reteive it
3. How to compile it
4. How to install it on the player.

Ive had no luck so far locating this information trawling around on the site, although its a big site and I have'nt had time to explore it thoroughly. Can you point me in the direction of the info or perhaps provide it to me yourself?

I have downloaded the source for Rockbox and attempted to compile it. So far every attempt with different targets (e200 v1, e200 v2, c200 v1) has errored out (various errors) some way thru the compile process. I wont go into that now, but I am wondering if its anything to do with running Ubuntu 8.10. Will follow that up with someone later if I cannot vlear the problem myself.

Regards,

Phil T.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on November 08, 2008, 09:40:02 PM
http://www.rockbox.org/twiki/bin/view/Main/DevelopmentGuide, http://www.rockbox.org/twiki/bin/view/Main/LinuxSimpleGuideToCompiling and http://www.rockbox.org/twiki/bin/view/Main/UsingSVN should help you.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on November 09, 2008, 01:25:37 AM
Hello !

Finally I committed the bootloader code to the SVN repository :D
Now there is no need to reflash always with mkamsboot, standard make zip and unzip will work fine.

Some stuff remains todo:

Many thanks to all the people who wrote that big piece of software in the first place, and to the people who helped/tested on the sansav2.
It's very interesting and I learn a lot of stuff :)

See you !
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Bagder on November 09, 2008, 06:51:58 AM
Isn't it time we added one or two v2 bootloaders to the build table now? I mean to make sure they keep building fine etc.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on November 09, 2008, 12:38:03 PM
The "USB disk" offset (the number of blocks reserved for the OF in the SD) is hardcoded and needs to be calculated for e200 and fuze since they have too big firmwares (the value for Clip is 10MB, and is likely the same for m200 and c200).
You just need to print the number of sectors reported by the card and substract the number of sectors reported by the computer when you plug the model.

Moreover the code doesn't seem to work with a 8GB e200, it was only reported to work on 1GB Clip.

Maybe the SD card doesn't report as SDHC and we need to do "bank switching" (there is a vendor specific command used in the PP driver to do so)

That will need some code from the owner of a high capacity model.

The bootloader can be added to the build table, but since it doesn't work on all models maybe it can wait a bit ?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on November 09, 2008, 12:42:46 PM
My Fuze's 4GB also have been detected as 1GB only.

Also, when trying to compile the build, I got a linker error. My rockbox.sansa didn't fit into DRAM. Then I replaced MEMORYSIZE with 8 in firmware/target/arm/as3525/app.lds and it compiled.

Is the memory size from configure not properly passed to app.lds?

Sadly, I get the disk_init failed message, so i can't test further.

Edit: My microSD is detected properly with 4GB.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on November 09, 2008, 04:11:57 PM

Moreover the code doesn't seem to work with a 8GB e200, it was only reported to work on 1GB Clip.

Maybe the SD card doesn't report as SDHC and we need to do "bank switching" (there is a vendor specific command used in the PP driver to do so)

That will need some code from the owner of a high capacity model.
I have a Sansa e280 with 8GB.
I'm not sure if I can help here because my programing skills are rather low but maybe I can have a look, nevertheless...

If you have a look, read a bit the firmware/target/arm/ata-sd-pp.c file, I hope a similar technique is used (this file is used in sansa e200v1 and c200v1 at least).
It seems the SD is not reported as High Capacity, so I suppose the code switches between several 1GB banks.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: RockRabbit on November 09, 2008, 05:18:23 PM
http://www.rockbox.org/twiki/bin/view/Main/DevelopmentGuide, http://www.rockbox.org/twiki/bin/view/Main/LinuxSimpleGuideToCompiling and http://www.rockbox.org/twiki/bin/view/Main/UsingSVN should help you.

Thanks. I had already used the SimpleGuideToCompiling to compile rockbox but it did not work. I added the path to perl mentioned in the DevGuide and also re-donwloaded the source, and now it works. Not sure which bit fixed it, assuming the perl link.

I have been able to retrieve and compile the mkamsboot, but without knowing what to modify or how to install it I cannot go any further. BEing completely new to the project it looks like I will need to spend loads of time going thru the code, which is probably beyond me. Unless someone can perhaps provide me with the exe and instructions how to install? If no one has the time to do that, I may not be able to go any further at present.

Phil T.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: fragilematter on November 10, 2008, 07:29:29 AM
To get the bootloader to work on e200v2s (or at least the 2GB e250v2) the start variable in rockbox/firmware/target/arm/as3525/ata_sd_as3525.c at line 522 needs to be set to 61440.

(http://img359.imageshack.us/img359/4020/notfoundlf8.th.jpg) (http://img359.imageshack.us/my.php?image=notfoundlf8.jpg)(http://img359.imageshack.us/images/thpix.gif) (http://g.imageshack.us/thpix.php)

Now, if I'll get RB to compile we might even see a menu...
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: JdGordon on November 10, 2008, 07:47:34 AM
works on my 2GB e200v2 also :)

linuxstb suggested in IRC we fake a partition table instead of adding this hard coded value to the sd driver and I agree (I'll maybe give this ago tomorow after my last exam :D ).
Is this value going to be the same for all e200's? is there any way it doesn't need to be hard coded?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: mc2739 on November 10, 2008, 07:55:36 AM
I think it should be the same for all e200v2, since they all use the same firmware. It will probably be different for the fuze.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: JdGordon on November 10, 2008, 08:09:35 AM
I've commited that quick fix as a temporary work around untill something better happens.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Bagder on November 10, 2008, 09:52:17 AM
1. The AMS version of the m200 is now called m200v4 in Rockbox to match the name SanDisk themselves use for this device

2. The e200v2, m200v4, clip and fuze now get their bootloaders built in the build table to make sure they remain buildable.

I propose we refer to these newer model Sansas as "AMS Sansas" and not V2 or anything since there are many other version numbers involved.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on November 10, 2008, 11:25:02 AM
I think it should be the same for all e200v2, since they all use the same firmware. It will probably be different for the fuze.
I gave this value a try, and got farther than with my own value. I reached the "Loading Firmware" text.

It didn't load rockbox even though I already had a build compiled. Although it also did NOT say file not found. I suppose my build was just way too "stubbed".
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on November 10, 2008, 11:54:04 AM
Since the size is incorrectly reported, all the data accessed by the fat driver needs to be within the reported size of course, else nothing will load.

@RockRabbit : why don't you come on irc ? real time discussion is better for that I think.

@JDGordon : what's the point of a partition table ? It just makes things more complex, and is useless, we don't want to access that part of the SD card.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on November 10, 2008, 04:32:14 PM
So, I tried to build a Fuze build, but it fails to load. The checksums don't match.

I can load rockbox from either internal or external (microsd) memory. Both fail to load. The microsd is correctly recognized (numbers of blocks match with dmesg). I made sure rockbox.sansa is within the first 1GB of the internal memory.

But as I said, both fail to load with unmatched checksums.

If I try to load them anyway (ingoring the checksum error), I get a undefined instruction at 0x30000024. This is the first 30 lines of the disassembly (using the the disassembler in svn)

Code: [Select]
     0: e59ff01c ldr pc, [pc, 0x1c] <- 0x30000044
     4: e59ff01c ldr pc, [pc, 0x1c] <- 0x300000bc
     8: e59ff01c ldr pc, [pc, 0x1c] <- 0x300000c8
     c: e59ff01c ldr pc, [pc, 0x1c] <- 0x300000cc
    10: e59ff01c ldr pc, [pc, 0x1c] <- 0x300000d8
    14: e59ff01c ldr pc, [pc, 0x1c] <- 0x300000c8
    18: e59ff01c ldr pc, [pc, 0x1c] <- 0x300556a0
    1c: e59ff01c ldr pc, [pc, 0x1c] <- 0x300556ec
    20: deadbeef cdple 14, 10, cr11, cr13, cr15, {7}
    24: 30000044
    28: 300000bc
    2c: 300000c8
    30: 300000cc
    34: 300000d8
    38: 300000c8
    3c: 300556a0
    40: 300556ec
    44: e321f0d3 msr CPSR_cf, 0xd3
    48: e3a01000 mov r1, 0x0
    4c: e59f2890 ldr r2, [pc, 0x890] <- 0x30000000
    50: e59f3890 ldr r3, [pc, 0x890] <- 0x30000044
    54: e4920004 ldr r0, [r2], 0x4
    58: e4810004 str r0, [r1], 0x4
    5c: e1530002 cmp r3, r2
    60: 1afffffb bne 0x54
    64: e59f2880 ldr r2, [pc, 0x880] <- 0x3007ac40
    68: e59f3880 ldr r3, [pc, 0x880] <- 0x3012cd04
    6c: e3a04000 mov r4, 0x0
    70: e1530002 cmp r3, r2
    74: 84824004 strhi r4, [r2], 0x4

If anyone succeeds with the fuze build or have an idea why it fails to load, post!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on November 10, 2008, 04:49:24 PM
If rockbox says invalid checksum; the data is corrupted, period.

I would verify if the SDRAM works correctly first.

I found in the Fuze OF that it used 2MB, but I was told it has 8MB , so the setting might be incorrect.

Just do something like
Quote
for(i=0x30000000; i< 0x30000000+MEM*0x100000; i+=4)
    *(volatile int*)i = i;
for(i=0x30000000; i< 0x30000000+MEM*0x100000; i+=4)
    if(*(volatile int*)i != i)
         printf("bad");

to test the whole memory.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on November 10, 2008, 04:59:21 PM
I set it to 8MB, as the diagnosis mode in the OF tells me
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: JdGordon on November 10, 2008, 05:44:39 PM
@JDGordon : what's the point of a partition table ? It just makes things more complex, and is useless, we don't want to access that part of the SD card.
because it wouldnt surprise me if parts of the rockbox fat/disk drivers assume a valid parittion table exsists, and also the sd driver should always read/write to the sector it was asked for, and not silently change it
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: gevaerts on November 10, 2008, 06:03:05 PM
@JDGordon : what's the point of a partition table ? It just makes things more complex, and is useless, we don't want to access that part of the SD card.
because it wouldnt surprise me if parts of the rockbox fat/disk drivers assume a valid parittion table exsists, and also the sd driver should always read/write to the sector it was asked for, and not silently change it
If you fake a partition table, you have to shift everything a bit anyway to make room for it, so you'll have an offset anyway.

And rockbox code does handle partitionless disks anyway.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: JdGordon on November 10, 2008, 06:08:31 PM
yes, but the offset isnt inside the sd driver...
If i ask for sector 0 of drive 0 I want sector 0, not 60441
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on November 10, 2008, 09:57:03 PM
If anyone succeeds with the fuze build or have an idea why it fails to load, post!
So, I succeeded myself now (with big hints by linuxstb and jdgordon).

The SDRAM wasn't properly initialized since system-as3525.c still defines the fuze as a 2MB ram target. After moving the || defined(SANSA_FUZE) some 3 lines down to the e200v2 line, the main binary loads. One of those ancient assumtions that the Fuze is 2MB target broke the whole thing.

NOTE: I've done that with csd v1.0 and having rockbox.sansa in the first 1GB.

I couldn't get to the main menu yet. The bootlogo (of the main binary) pops up is then shifted left a bit.

After trying to boot numerous times, sometimes it said fired a error message (partition error, insert USB cable and fix).


Another thing: Yes, the one function you assumed to be lcd_enable is it. I called it directly after show_logo(). I did lcd_enable(0);. In the bootloader the display turned all white, and it looked like it was shut off (it wasn't instant white everywhere).

Edit: I did a test with forcing the csd 2.0 branch in ata_sd_as3525.c (line ~250) (that what us get 4GB reported). The main binary still loads.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on November 11, 2008, 02:56:55 AM
@JDGordon : what's the point of a partition table ? It just makes things more complex, and is useless, we don't want to access that part of the SD card.
because it wouldnt surprise me if parts of the rockbox fat/disk drivers assume a valid parittion table exsists, and also the sd driver should always read/write to the sector it was asked for, and not silently change it

Consider the SD is divided in 2 logical disks: 0->X is a reserved disk for the OF
X->end is the disk exposed over USB, and I think is the only disk we want to access.

Using a partition table is not good, because I chose to partition the disk exposed over USB, and we can't have a partition table inside a partition.

Why do you want to access the first area of the storage ? (starting from sector 0).

IMO since it's the only area exposed by the OF via USB, that's the only area we want to touch.

linuxstb told me some other targets (some iPod ?) have the same reserved blocks at the beginning of the storage, do they use the same tweak (shift the requested sector offset) ?

P.S. if we continue to skip the requested sector in the SD driver, we should also reduce the reported number of sectors
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: JdGordon on November 11, 2008, 03:25:32 AM
A better solution came up in irc today that the superfloppy mode should be told which sector to start at (it does already anyway, currently always 0) instead of using the SD driver to shift it. this _should_ work but hasnt been tested yet
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: JdGordon on November 11, 2008, 05:17:13 AM
weeee :)
time to join the party properly!

ATA error: -1
Press ON to debug

loading a real binary on my e200v2...


edit: commenting out some #ifdef BOOTLOADER lines andremoving HOTSWAP and MULTIVOLUME gets me to the logo... time to find out how much further
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: mc2739 on November 12, 2008, 12:46:12 AM
I was able to get to the main menu on my e200v2. It is still not very consistent. Sometimes, I get just a white or gray display. If you hold the player at an angle, you can sometimes still see the rockbox logo. After 10 seconds, the backlight goes off. The buttons aren't working yet, but inserting the USB cable will sometimes turn the backlight back on.

I'm starting to wonder if the shared GPIO deal is what maybe causing some of these problems (at least on the e200). The display uses GPIO B & C as do some of the buttons. The button light uses GPIO D which I believe is also used by the storage. If the various functions are not checking the status of these GPIOs, and just reading or writing under the assumption that they are still in the correct state, then who knows what will happen.

Any thoughts from the more experienced?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: JdGordon on November 12, 2008, 06:49:24 AM
sounds plausable :p

here is a better version of the disk sector offset patch I had up before.. this one actually works
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on November 13, 2008, 08:57:05 AM
I was able to get to the main menu on my e200v2. It is still not very consistent. Sometimes, I get just a white or gray display. If you hold the player at an angle, you can sometimes still see the rockbox logo. After 10 seconds, the backlight goes off. The buttons aren't working yet, but inserting the USB cable will sometimes turn the backlight back on.
The SD driver is broken.
It doesn't work.
It's not finished.
It reads corrupted data.
Don't use it.
It will not be fixed by modifying 2 lines of code.

The solution might be to use DMA requests to read the data from the SD controller.
The DMA controller is luckily a (documented) PrimeCell controller, so this should be easy to write code for it.

I'm starting to wonder if the shared GPIO deal is what maybe causing some of these problems (at least on the e200). The display uses GPIO B & C as do some of the buttons. The button light uses GPIO D which I believe is also used by the storage. If the various functions are not checking the status of these GPIOs, and just reading or writing under the assumption that they are still in the correct state, then who knows what will happen.

Any thoughts from the more experienced?

This is not a problem, the button light code shouldn't be called at all as far as i understand.
And if it is called, it should restore the state of the CCU_IO register which defines if XPD is used for SD/MMC (storage) or for GPIO.

Note that to avoid potential bugs, we should disable interrupts before changing this CCU_IO register, and reenable them after we have reset it to the original value, to be sure not to leave the register in the GPIO state while we need SD transfers.


---

People, is it possible to keep this forum thread development related, and not testing related ?
It is already quite hard for newcomers to follow these 30+ pages and understand what is the  current status.

(For newcomers: the current status is in development, and not ready for use)

IMHO the port is not in a state where it benefits from massive testing.

Maybe the developers ask to try a feature once to see if the results are not different on another model, but no need to answer the same thing 10 times.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: bertrik on November 13, 2008, 05:09:46 PM
Last night I tried to see if anything else was present on the audio master i2c bus of my clip. No luck, I only got the codec at address 0x46 to respond, no response at any other addresses. Tried the same on the master/slave bus and no response at all either (I did make sure that the master/slave i2c interface was enabled in the CCU_IO register and that the i/o pins were not configured for display use). I was hoping to find the fm radio chip.

I looked at the fuze firmware and it seems it does "bit-banged" i2c on some pins (i.e. doing i2c by wiggling GPIO pins). It might be worth looking into devices on this bus. The generic GPIO i2c driver already present in the rockbox sources could make this easier.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Domonoky on November 14, 2008, 05:05:38 PM

I just detected that, at least on the m200v4 the sd-driver doesnt need the CCU_IO bits modified.
So at least for the internal storage it doesnt use gpio d.

When i dont modify the CCU_IO i get my backlight back working. And as a added bonus the sd-driver is running much better in rockbox, i can now browse files in rockbox :-)

Could people with other sansa v2 players test if the CCU_IO bits also arnt need in the sd-driver ? (especially external sd-mem on e200v2 would be interesting).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on November 16, 2008, 01:03:32 PM
It's not needed on the Clip, but I didn't try to make the difference between modifying or not.

According to the as3525 datasheet, it should only matter when using the 'original' PL180 controller, the one used with a SD slot (on Fuze and e200, I don't know if the c200 has an SD slot).

Note that I have applied the diff of domonoky and modified it a bit, but we both still have strange results, especially panics in the fat driver, that might result from incorrect data transfers which are not reported by the DATA_CRC_FAIL in the PL180's STATUS register.

EDIT:
Disabling the irq before the data transfer gives perfect results: no overrun, no delay...
But this still causes panics in the fat driver, so the data transferred may have been corrupted.

Another problem with this approach is that we don't give back the control of the CPU to other threads or the kernel tick interrupt until the transfer has been made.
If we can fix or understand the remaining problem we might do precise timings (perhaps with a TIMER) and decide if this approach is worthwhile.

I attach a patch which disable interrupts, and does no retries if a problem happened (instead it will happily panic).
Please report if you see problems other than a panic "Updating size on empty dir entry %d"

EDIT2: the remaining problem has been fixed with a suggestion of Frank Gevaerts: the write function returned success. Making it return a failure fix the problems, I'll commit a fix shortly.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: yapper on November 16, 2008, 01:12:24 PM
...I don't know if the c200 has an SD slot
It does
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Llorean on November 19, 2008, 02:11:30 AM
Hi, I've just played with the clip simulator and noticed the keymap.

Is there a particular reason it's so drastically different than existing keymaps (especially the e200, which could be 1:1 mapped if you used the volume buttons in place of the wheel)?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on November 19, 2008, 04:00:22 PM
I think I modified the e200 keymap (replace wheel with left/right) until it built, and made a few modifications to avoid duplicate combinations.

Work on the keymap is welcome of course (I noticed that the C200 keymap is quite similar).

Note that the volume buttons are not as easily accessible as the others, so I personally would prefer if their role was limited.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on November 20, 2008, 09:05:52 PM
Hi everyone,

I had a look at the sansa fuze OF and disassembly pictures and, sadly, the more I look into it, the more I think the buttons (and wheel) are read using DBOP. Which would mean, it isn't as simple as the other players... I may be wrong, but the "ReadButtons" routine seems by far bigger than the other players equivalent.

However, without any hints on what I in the wheel/buttons part of the device, it is quite difficult to know what to do with it except to rewrite the same as what the OF does. Anyone brave enough to take pictures of the wheel/buttons disassembled casing? ;D

If you guys want to have a look at it, the deepest subroutine of the "ReadButtons" routine, which in fact directly access DBOP, is located at 0x4920 in the fuze firmware. Also, the routines write the buttons state in 0x2164E.

Any progress on the SD side?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on November 20, 2008, 09:13:35 PM
Anyone brave enough to take pictures of the wheel/buttons disassembled casing? ;D

They plug into a non-descript ZIF socket on the board via a ribbon cable.  It can be clearly seen in image 17 here:

http://www.anythingbutipod.com/archives/2008/03/sandisk-sansa-fuze-disassembly.php

Its the plain white connector with 10 pins. 
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on November 20, 2008, 10:28:41 PM
They plug into a non-descript ZIF socket on the board via a ribbon cable.  It can be clearly seen in image 17 here:

http://www.anythingbutipod.com/archives/2008/03/sandisk-sansa-fuze-disassembly.php

Its the plain white connector with 10 pins. 

Anything more than those picts? I already saw those... :( My real question was "is there any serial number or something we could recognize and get a bit more info on". Anything that could be searched on google to get a datasheet or something... Or maybe it is as simple as being passive components? 10-pins, maybe that's enough for direct connections. I would guess 1 or 2 for power and the others for each button/wheel sensor.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: daniel_at on November 21, 2008, 05:42:50 AM
Hi all,

I have already taken some pictures (other than the from abi) and posted the link in the wiki: http://www.rockbox.org/twiki/bin/view/Main/SansaFuze

As far as i can see: the Buttons are either matrixed or directed connected to the main-pcb but surley their is no further logic controlling them. But as you can see, on one of the pics, all outer rings are connected together, matrix'ing isnt possible at all.


The wheel, however, is a bit more complex... its not controlled by actuall switches but with two magnetic-sensible devices. And the wheel (the moving part) itself is a magnet. (if you place a strong magnet behinde the fuze, the wheel does not work anymore... unfortionally, my mount in my car works with an magnet :( )

So this may be sampled with an ADC or with oder complex(er) algortithms...

hope that helps a bit,
Daniel
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on November 21, 2008, 06:21:29 AM
I did tests with ADC and was not successful.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on November 21, 2008, 08:17:12 AM
Any progress on the SD side?

I have working read/write using DMA in my tree.

But we still can't access data past 1GB on >1GB models :(

--
You mention offsets in the Fuze OF, but which firmware version exactly are you disassembling ?

EDIT:
I tried the DMA code in the bootloader, the FAT32 partition is read correctly, and the beginning of rockbox.sansa as well (since I can see the correct size and checksum on screen); but the calculated checksum is always wrong .. I couldn't figure what was wrong.

I pasted (http://paste.ubuntu.com/76085/) my current diff (with some plugin keymaps, too lazy to sort it from the DMA/SD code :P ) since I couldn't figure what was wrong.

Note that when using a bootloader from SVN and this code, plugins/rockbox/lang files load just fine..
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on November 21, 2008, 12:15:48 PM
Hi again,

daniel_at: thanks for the pics, I really clear things up in my mind. It seems to me the buttons are all linked to a single supply (GND or VCC) on one side, and all connected to independent connector pins on the other. As for the wheel, well that still to be looked upon, but I think it'll be easier to test using a custom firmware once we will have a "safety button" for the dual boot.

kugel: From what I see, it definitely isn't ADC and definitely is using DBOP (so a standard "logic" interface).

funman: I *think* it is v. 1.1.11 but I'll have a look tonight. It definitely is the first version we could get from bagder's site (if there are more, been a long time since I looked there...). If you have a bit of time, would you mind explaining how to use the current SVN, I got lost with the "new" bootloader and stuff and since you're not online anymore... :P

Keep up the good work everyone!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: caladan on November 21, 2008, 01:56:24 PM
The wheel could be a standard rotary encoder using some kind of magnetic relays..
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on November 21, 2008, 07:52:40 PM
After review, it is indeed the 1.1.11 fuze firmware revision that I have here.

Caladan, yes you are right and from the pics from Daniel, it looks like it :) I know some hall effect sensors have 4 pins and this is exactly the kind of sensor they could have used with a polarized wheel.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on November 22, 2008, 07:06:37 PM
funman, I tried to apply your patch. It's seems not to be against svn, since I'm missing a file it wants to patch.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on November 23, 2008, 04:04:22 PM
sorry it was missing parts of the new files, I corrected the paste in my previous message
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on November 23, 2008, 05:00:24 PM
With the corrected patch, I'm able to successfully boot into the main menu on my fuze reliably.

The display is slightly greenish, and the area where the statusbar should be is flickering. I can turn the backlight on with inserting the usb cable. Obviously I'm not able to browse anything due to the lack of buttons.

Edit: I forgot to mention: I've made a 500MB partition to work around the >1GB problematic for now. But now as it boots successfully I'll have a look at the getting the whole 4GB to work (which will likely be problematic without seeing the filebrowser).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: daniel_at on November 24, 2008, 12:35:14 PM
The blinking top status-bar on the fuze build disappears if I remove the line 394 in lcd-fuze.c:
Code: [Select]
    lcd_write_data((unsigned short *)lcd_framebuffer, LCD_WIDTH*LCD_HEIGHT);
Seems do be a copy-pasta snipped from lcd_update...

Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on November 24, 2008, 02:06:18 PM
Small update: I found that the buttons for the Fuze are the same as the ones for the e200v2, at least the ones implemented (i.e. not scrollwheel, home(fuze)/rec(e200v2) and hold).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on November 25, 2008, 08:44:59 AM
I finally found what was wrong in the bootloader:
I was not incrementing the SDRAM pointer, so data would be overwritten after each sectors transfer; only if the requested sectors number was >= 128 (which it seems only happened in the bootloader)

I committed the (read and write) code in r19211 , with the DMA driver which will be used for I2SOUT (pcm playback) and perhaps I2SIN (pcm recording).

It will require some modifications though:

Don't forget the major bug remaining : we can't access data past 1GB on the internal storage.

NOTE: LambdaCalculus37 reported his 2GB Clip is correctly detected as 2GB by rockbox.
I believe 2GB is the maximum theorical size on not High Capacity SD cards.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: yapper on November 25, 2008, 12:20:30 PM
I believe 2GB is the maximum theorical size on not High Capacity SD cards.
I thought 4GB was the limit, but Wikipedia claims 8GB ???
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Hillshum on November 25, 2008, 01:14:37 PM

According to sdcard.org (http://www.sdcard.org/developers/tech/sdcard/), 2gb is the non-hc limit
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: cosmocat on November 25, 2008, 02:06:24 PM
the limit for sd card and microsd cards are differents.
sd card : 1GB, 2GB and 4GB
sdhc card : 4GB, 8GB, ...

but in our case, for a microsd card :
micro sd card : 1GB, 2GB
micro sdhc card : 4GB, 8GB...

if it could help...
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: philibuster on November 25, 2008, 02:12:19 PM
According to sdcard.org it says "up to 2gb" for both micro and normal SD.

wikipedia (gasp) has a good writeup about the "openness" of the "standard" and says that all <1gb should work in every case, but SD supports up to 4gb with some hacking.
http://en.wikipedia.org/wiki/Secure_Digital_card#SD_.28non-SDHC.29_cards_with_greater_than_1_GB_capacity
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: willwolfe on November 25, 2008, 02:20:25 PM
Don't forget the major bug remaining : we can't access data past 1GB on the internal storage.

I think the emphasis at this time should be on the "internal" storage.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: LambdaCalculus379 on November 25, 2008, 02:26:10 PM
Just a reminder for everyone that we're starting to veer off-topic on this thread. Let's get back to the business of porting, shall we? ;)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on November 25, 2008, 06:11:59 PM
I can confirm the Fuze buttons do not work in the main Rockbox.

More hacking is needed to make it work. Enabling button_int() for the main build in button-fuze.c does NOT give anything but a highly flickering screen and unresponsive.

Funnily enough, the screen actually reacts on your button presses, e.g. pressing up will make it invert the color, pressing center will make it flicker in a slower fashion.

Anyway, getting the buttons to work (and fixing the lcd) is not trivial, at least nor for me. I played around with irq, without success, although interrupt issues seem logical to me, since lcd and buttons are accessing the same GPIO port (lcd via switched to DBOP).
So I tried disable_irq and enable_irq, which leads to a non booting Rockbox, giving a "Divide by Zero" error at the boot for a split second (it's so fast you can't note down the address). Using disable_irq_save() and restore_irq() didn't seem to do anything.

Apart from the buttons, the lcd ain't stable. Even without buttons enabled, the display flickers frequently.

Edit: The button driver seems to crash when booting in the main. I replaced the button read function with something that toggles the buttonlight everytime that function is called. It just blinks once!
Then I placed a splashf which displays an increasing counter (which is increased everytime the funtion is called). It only counted upto 3.

Edit2: Scratch the crashing button driver. It's not crashing, that was just an issue with xpd.
But I still can't get the buttons to work in the main binary (always keep in mind: They work just fine in the bootloader).

I tried to read them seperately. I can read the Power and Down button pretty well, but reading e.g. center or right doesn't work at all. The code is the same, just the corresponding pin replaced. And they behave differently.
I'm out of ideas very soon. I'm now trying to get the button via DBOP since GPIOB and C are kinda connected to it by a physical pin or something, but I'm probably out of hope here.

Sadly, the OF doesn't reveal much at all about the buttons (at least not in my disassembly of the firmware block). I can hardly find mentions of GPIOB and GPIOC. Does anyone have an idea if the button stuff is another than the firmware block?

It would be great if I could get help on this one. Also, keep in mind, that this problems afaik are also on the e200v2 (not Fuze-only).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sko on November 30, 2008, 03:18:16 AM
Hi, I have an e200v2 and I'm watching this thread and the SVN since some weeks. I am looking at the SVN and testing the changes nearly every day.

Quote from: .kugel
Also, keep in mind, that this problems afaik are also on the e200v2 (not Fuze-only)
Yes, thats right, the buttons are working in the bootloader (at least Buttons for choosing the OF or RB), but in the Rockbox menu they aren't working.

Second thing (it hasn't been reported in this thread until now): since revision 19234 there is only a blank white screen on startup, no rockbox logo, no rockbox menu, but booting OF with the <<-button works, so the bootloader must be working I think.

EDIT: The issue with the white screen seems to be fixed with revision 19276.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on November 30, 2008, 03:28:32 PM
Hello all!

I wanted to tell you that since today we have sound working !

The code isn't committed yet, because it required quite some changes and we still experience a lot of unexplained deadlocks/reboots/shutdown etc .. but sometimes we can hear our songs ;)

See FS#9592 (http://www.rockbox.org/tracker/task/9592) for work in progress

@johnnyz86 : like saratoga told you there is still a lot of work to do (he only forgot the FM radio).

Something you'll need to work on the Sansa AMS is the AS3525 datasheet.
Unfortunately it's not redistributable, but if you come on irc (and prove you are interested) you can ask Bagder for it (he is allowed to redistribute it to developers on an individual basis, at the condition to not redistribute / make it public of course).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on December 09, 2008, 05:54:59 AM
Hello, some time has elapsed without updates, so I'll give you the status on the SansaV2:

ROCKBOX DOES NOT WORK YET not even for casual use; so really there is no point in using it if you're not going to develop and make it better.

A lot of people have been asking for status recently, i hope it's made clear.
For future reference, you can track the status here (http://www.rockbox.org/twiki/bin/view/Main/TargetStatus#New_Platforms_Currently_Under_De)

Recently we have been working on the FM radio, and it has been tested on M200v4 and Clip (radio in Fuze and e200v2 should 'just work' when we'll be able to test it)

Here is what is missing at this day:

Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Hillshum on December 09, 2008, 11:58:43 AM
Manual is another thing non-coders can write
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: battlemac on December 09, 2008, 04:49:08 PM
when you are referring to storage are you referring to the built in storage or are you referring to the SD card storage?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: gabe565 on December 09, 2008, 05:21:02 PM
It is the internal storage with the no more than 1GB problem.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Hillshum on December 09, 2008, 05:42:32 PM
is that 1GB as in 109 or 10243?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: RockRabbit on December 10, 2008, 12:00:15 AM
Hello, some time has elapsed without updates, so I'll give you the status on the SansaV2:

  • KEYMAP : The e200v2 uses the same keymap than e200v1, but other models will need reflexion on a good keymap to use. Note : this is a point where non programmers can help too

I might be able to help, provided I am given clear instructions what to do. I have been able to compile Rockbox, and am running it on a c250 version 1 (its great by the way - though of course you all know that already). I have a version 2 I might be willing to risk, providing I don't have to guess my way thru any of it.

I am willing to bet the player on the fact that the keymap is more or less the same as the e200 (excepting the wheel?). Perhaps someone can supply code that specifies the most obvious button that will be the same (the menu button ?).

Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on December 10, 2008, 05:53:08 AM
@ hillshum : I don't know exactly since I don't own such a device, but I record the reported size was a bit less than 1000000000 (so less than 1GB AND 1GiB)

@RockRabbit : you must first revert utils/AMS/hacking to revision 18663 to get the old basic mkamsboot (which inserts a delay)
Then if you are not familiar with assembly, you should come on the IRC channel and see if someone (like me if i'm present) can give you the steps
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Llorean on December 10, 2008, 06:19:55 PM
Alright, finally got my Clip. I'm looking at the keymap now, and I'll probably post two patches later (in the next few days) one "low-controversy" one where I try to fix the real problems, and a more controversial one where I try to make available the full functionality of Rockbox while still being what *I* consider usable (which may not be the same for everyone).

Alongside that, I'll try to look at the m200v4's keymap as well. I suspect though that it should just have the same keymap as the c200 in 95% of cases since the Recording button isn't often used, I think.

As a note, sound doesn't seem to be working again. At least, when I attempt to play something, it says at 0:00 on the Clip, and doesn't progress, this is with r19386
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on December 11, 2008, 06:23:23 AM
Alright, finally got my Clip. I'm looking at the keymap now, and I'll probably post two patches later
Nice!

As a note, sound doesn't seem to be working again. At least, when I attempt to play something, it says at 0:00 on the Clip, and doesn't progress, this is with r19386

Playback is quite buggy on the Clip/m200v4; you should try to apply FS#9332 (flash buffering) which gives better results.
Without it rockbox crashes because of corrupted data (we suspect that buffering.c has some overflows since replacing this file gives better results; but we are not sure yet)

You can also try FS#9611 which is FM radio support (The FM output is directly mixed on the headphones output, so it doesn't use the pcm driver)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: smdas on December 12, 2008, 09:04:27 PM
I just got a brand new AMS Sansa e260 in the mail today. I've done a bit cross-arch embedded before, and I'd like to see that RB boot screen come up on my Sansa...

I've got a small amount of RB experience as a user, in that I own a fourth-generation ipod that was given to me (which was broken, and I fixed). I've been using RB on that for a bit over two years, but that port is prone to frequent lock-up/crashes, which is super annoying. I was inclined to help there, but I really don't like the Apple hardware that much, so, I went and bought a Sansa, but it's the second-gen AMS-based hardware... so I figured that I aught to finally give back.

I have a bit of firmware experience bringing up audio hardware (bootloader work, initialization & driving of DACs/ADCs, loading DSPs but not coding them, etc), and working with various busses. Is there any work in those areas that I could help with? I don't have a micro sd/sdhc card, so probably not there. Perhaps I2C to the buttons? I dunno  ???

At any rate, my question is, has anyone had any further progress with rescuing bricked non-e200's, JTAG or otherwise? If I kill my Sansa then that will basically end my ability to help develop in a hurry. If there is a (reasonably) safe way to contribute to the firmware, then I'd love to do so.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Chronon on December 12, 2008, 10:37:58 PM
It has JTAG: http://www.rockbox.org/twiki/bin/view/Main/SansaE200v2#JTAG
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on December 13, 2008, 09:19:05 AM
If there is a (reasonably) safe way to contribute to the firmware, then I'd love to do so.

If you are inclined at hacking a bit, you can try using the (old) bootloader with delay which will delay on a custom condition (e.g.: button press) and don't wait in the opposite. With it, you'll be able to try buttons and see if you can find buttons on the ams-v2-e200... I assume you can first check that the mapping hasn't changed (based on the ams-v1-e200). Have a look at the bootloader history in svn to find the "good" one, or have a look earlier in this thread, I think funman already put a link to it...

Welcome among us :)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: RockRabbit on December 14, 2008, 12:09:06 AM

@RockRabbit : you must first revert utils/AMS/hacking to revision 18663 to get the old basic mkamsboot (which inserts a delay)
Then if you are not familiar with assembly, you should come on the IRC channel and see if someone (like me if i'm present) can give you the steps

I've got the rev 18663 code from subversion. Can you tell me where I can get the c250 firmware? Is there a way to get it off the player? I can't seem to find it on the Sansa web site.

I intend to try the raw code as is (without any key code checking) just to see that I can get it to work, before I do anything more useful.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on December 14, 2008, 12:43:15 AM
http://forums.sandisk.com/sansa/board/message?board.id=c200&thread.id=2029
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Bagder on December 14, 2008, 04:54:41 AM
Allow me to also mention that I collect most (all?) of the AMS Sansa firmwares here:

http://daniel.haxx.se/sansa/v2fw.html
Title: how to put the patched bootloader onto the target
Post by: RockRabbit on December 14, 2008, 05:25:38 AM
Thanks to saratoga and bagder I obtained the C200PA.BIN firmware, and have been able to run mkamsboot, giving me a PATCHED.BIN file.SO far so good.

Now I need to get this onto the target somehow. Is there a development version of sansapatcher or something similar?

Also do I need to rename the patched file to c200PA.BIN?

Many thanks.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Domonoky on December 14, 2008, 07:03:46 AM
There is no need for a sansapatcher for the ams-sansas. Just put the patched bin file with the correct name (c200pA.bin), to the root of you player, and the OF will flash it after USB-unplug.

But be carefull, as far as i know, the dualboot.S isnt tested on c200v2. If the dualboot function fails, it could brick your player !  (So it would be best to modify dualboot.S, so it always boots into the OF (after some delay for button checks) )

greetings, and good luck.
Title: Re: how to put the patched bootloader onto the target
Post by: saratoga on December 14, 2008, 12:08:27 PM
Thanks to saratoga and bagder I obtained the C200PA.BIN firmware, and have been able to run mkamsboot, giving me a PATCHED.BIN file.SO far so good.

Now I need to get this onto the target somehow.

The link I posted has the install instructions for a firmware file. 
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: RockRabbit on December 14, 2008, 08:59:34 PM
There is no need for a sansapatcher for the ams-sansas. Just put the patched bin file with the correct name (c200pA.bin), to the root of you player, and the OF will flash it after USB-unplug.

But be carefull, as far as i know, the dualboot.S isnt tested on c200v2. If the dualboot function fails, it could brick your player !  (So it would be best to modify dualboot.S, so it always boots into the OF (after some delay for button checks) )

greetings, and good luck.

Thanks for the warning. Actually I am following funman's instructions and using an old version of mkamsboot that simply inserts a delay into the boot process. Later I will get more adventurous and start to insert some additional keymap checking code, once I do a bit more investigation and get used to the arm instruction set.

Installed the patched bootloader and everything looks good. No brick tendencies detected. Loads the standard firmware after the delay and runs fine. Now ready for the next part.

I have come up with the following code, which is a combination of the test.s code in version 18663 or mkamsboot and the some code from dualboot.S from the current version of mkamsboot. I have made some alterations to the registers used so that hopefully the two pieces of code will work together. I have saved this code to the test.S file in place of the original 18663 version (which just contained the delay loop). Am I right in assuming that I can compile the code via make exactly as before without any more changes?

The intention is that the code will test for the left button to be pressed and exit the loop immediately if it is.  I am assuming (hoping) that the c200 might be very similar to the e200.

Code:

/* This value is filled in by mkamsboot */
originalentry:   .word   0
.set GPIOC,     0xC80D0000

        /* A delay loop - just to prove we're running */
        mov   r2, #0x500000       /* Approximately 5 seconds */
loop:       
   /* LEFT button check */
        ldr   r0,  =GPIOC /* gpioc */
        mov   r1, #0
        str   r1, [r0, #0x400]
        ldr   r1, [r0, #0x20]    /* read pin C3 */
        cmp   r1, #0             /* C3 = #0 means button pressed */
        beq   exloop

        subs  r2, r2, #1         /* decrement counter setting status flags #/
        bne   loop

        /* Now branch back to the original firmware's entry point */
exloop:  ldr   pc, originalentry
 
Does that sort of look ok?

Thanks.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on December 15, 2008, 12:52:20 PM
Does that sort of look ok?

I see no obvious error in there, but it is a wild guess to think that the C200 is similar to the E200 IMHO :) I would personally have thought that it would look more like the M200/clip, but I may be wrong... If you have some knowledge in disassembling, you could have a look at the C200 OF and try to figure out the buttons in there...

But I guess there is no harm in trying it out and see... ;D
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on December 15, 2008, 01:18:41 PM
RockRabbit: The next step is to find at least one button. Make the 5s delay dependent of the state of a GPIO pin of your choise. Then, try to boot and press buttons to see if the delay changed due to the button press.
Do this also for USB, the USB detection is like a button (i.e. boot with USB cable inserted, and without to see if delay changes).

My first recommendation would be to check GPIOA3. This pin is representing a button on the other AMS sansas as well.

Once you found a button, we can enable dual boot. Dual boot doesn't need a working bootloader, that's the fine thing about our ams sansas :)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: RockRabbit on December 16, 2008, 04:34:05 AM
I have placed the code shown below into test.S of version 18663 of mkamsboot. The player will load the OF after approx 33 seconds delay, but will load immediately the power button is pressed a second time. Does this mean that the code is successfully detecting the keypress for the power button?

Note that the statement "bne bootof" which branches out of the delay loop when the button is pressed was originally "beq bootof" in the dualboot.S file I copied it from in the current version of mkamsboot. This is contrary to the note beside the line which states the button press is detected when the value is zero, whearas my code checks for non-zero and seems to work. Can someone explain this?

Does the code look ok for me to continue adjusting the port addresses to detect more buttons, or have I got it completely wrong?

Also, can someone explain the meaning of the two lines "str   r1, [r0, #0x400]" and "ldr   r1, [r0, #0x20] "? I understand what they are trying to do, but cannot understand the immediate values. Why 0x20? This is binary 00100000 , which appears to select bit 2 rather than bit 3, and the 0x400 offset baffles me completely. Any help greatly appreciated.

Im beginning to enjoy myself immensely doing this. Lets hope I can make some progress before I brick it.


/* This value is filled in by mkamsboot */
originalentry:   .word   0
.set GPIOA,     0xC80B0000
.set CGU_PERI,  0xC80F0014

        /* A delay loop - just to prove we're running */
        mov   r2, #0xB00000       /* Approximately 5 seconds */

        /* enable gpio clock */
        ldr   r0, =CGU_PERI
        ldr   r1, [r0]
        orr   r1, r1, #(1<<16)
        str   r1, [r0]

loop:

        /* LEFT button */
        ldr   r0, =GPIOA
        mov   r1, #0
        str   r1, [r0, #0x400]
        ldr   r1, [r0, #0x20]    /* read pin C3 */

        cmp   r1, #0             /* C3 = #0 means button pressed */
        bne   bootof
 
   subs  r2, r2, #1
        bne   loop

        /* Now branch back to the original firmware's entry point */
bootof:   

   ldr   pc, originalentry
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on December 16, 2008, 04:44:36 AM
r0 contains the GPIOA base address. r0+0x400 is the the GPIOA_DIR address. Clearing GPIO*_DIR (for a specific pin, e.g. ~(1<<3), or all pins on that port, 0x0) sets the pins to input, which means that the hardware sets the bit high/low. If they're set, the hardware cannot change the state.

0x20(1<<3; pin 3) is the offset of GPIOA base address, that holds the actual pin. This is read, and (possibly) changed due to a button press.

And yes, if the power button made the of boot immediately, it means you fount the power button :)
I'll add your find to the V2HardwareMapping wiki page. Next step would to edit mkamsboot to implement dual boot.

Edit: If you feel brave enough, can you try setting GPIOD7, I assume that's the button light.

Take this code (test.S).

/* This value is filled in by mkamsboot */
originalentry:   .word   0
.set GPIOA,     0xC80B0000
.set GPIOD,     0xC80E0000
.set CGU_PERI,  0xC80F0014

        /* A delay loop - just to prove we're running */
        mov   r2, #0xB00000       /* Approximately 5 seconds */

        /* enable gpio clock */
        ldr   r0, =CGU_PERI
        ldr   r1, [r0]
        orr   r1, r1, #(1<<16)
        str   r1, [r0]

        ldr   r4, =GPIOD
        mov   r3, #128
        str   r3, [r4, #0x400] /* set Pin 7 to output, 128 = 1<<7 */
        str   r3, [r4, #512] /* set pin to high to enable buttonlight, 512 = 128<<2 */
loop:

        /* LEFT button */
        ldr   r0, =GPIOA
        mov   r1, #0
        str   r1, [r0, #0x400]
        ldr   r1, [r0, #0x20]    /* read pin C3 */

        cmp   r1, #0             /* C3 = #0 means button pressed */
        bne   bootof
 
   subs  r2, r2, #1
        bne   loop

        /* Now branch back to the original firmware's entry point */
bootof:   

   ldr   pc, originalentry
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: RockRabbit on December 16, 2008, 06:06:53 AM
Thanks for the help kugel. Cannot really understand the explanation re the ports and how they are addressed. I take it each pin is not a single bit within a word, but there are seperate words for each pin?

Is there anyway I can get hold of a copy of the AMS datasheet? It might help me understand the hardware better. Ive tried getting one from AMS, but they are asking what company i am with and when is my product going to hit the market. It all sounds depressingly corporate.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Moarc on December 16, 2008, 06:09:20 AM
RockRabbit,
Something you'll need to work on the Sansa AMS is the AS3525 datasheet.
Unfortunately it's not redistributable, but if you come on irc (and prove you are interested) you can ask Bagder for it (he is allowed to redistribute it to developers on an individual basis, at the condition to not redistribute / make it public of course).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on December 16, 2008, 07:53:24 AM
Thanks for the help kugel. Cannot really understand the explanation re the ports and how they are addressed. I take it each pin is not a single bit within a word, but there are seperate words for each pin?
Each pin is a byte. But only 1 bit of those bytes is significant, the other 7 are not. But yea, you always read/write 1 byte for each pin.

I really recomment reading the data sheet, it helps.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: RockRabbit on December 16, 2008, 09:07:41 PM
I can confirm that GPIOD pin 7 is the button light for the Sansa c250.

Thanks Kugel. The code worked fine.

Could you add it to the hardware mappings page for me please.

 ;D
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: gabe565 on December 16, 2008, 09:39:16 PM
Hmmmm...Whenever I try to run Rockbox, the bootloader starts and I see the Rockbox logo, but then, it says
Quote
*PANIC*
SD : DATA TIMEOUT,
I'm using the latest in SVN, and I'm not sure why this is happening! I'm trying to figure out what the problem is, does it mean internal SD? Even if I take out my SD card, I still get the same error. I just don't get it.

I'll add it to the hardware mappings page for you, RockRabbit.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on December 16, 2008, 11:33:34 PM
I was getting the SD : DATA TIMEOUT until I took all the music off my e280, then It booted all the way into the menu just fine.  Buttons didn't work though so I tried Domonoky's button patch and buttons sort of work.  The down button won't move to a lower menu.

I did get an ogg file to play quite  nicely though by using a fixed.cfg file.  I had rockbox start in the db menu and right arrowed my way to a music file.  After the one file played though the screen goes dark and I need to reboot.  Any other patches to get the down arrow working?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on December 17, 2008, 03:00:49 AM
I can confirm that GPIOD pin 7 is the button light for the Sansa c250.

Thanks Kugel. The code worked fine.

Could you add it to the hardware mappings page for me please.

 ;D
Great! I'll add it.  I'll maybe have a look at the c200v2 OF for the LCD if I have time.

Another thing: I think it's essential for safety that you find your USB "button". Turn the player on with USB and see if a delay happens or not compared to starting with the power button.

It would be very helpful if start creating a c200v2 target in the Rockbox tree then. So we can  build a basic bootloader using dual boot and test code *easier and safer*.

Edit: Uhm, now that I think about it. Finding USB  (and maybe some other buttons) should be essential for dual booting anyway, since I can imagine that dual boot with the power button will be somewhat difficult.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: RockRabbit on December 17, 2008, 03:14:35 AM
Where does the arm object dump program come from? I cannot find it in Ubuntu. I would like to dump the OF and have a look at it myself.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on December 17, 2008, 03:22:12 AM
It should be there once you have compiled the rockbox toolchain with rockboxdev.sh.

Look for arm-elf-objdump
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Hillshum on December 17, 2008, 12:56:37 PM
The dual boot on a release will use USB to boot OF anyway
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: gabe565 on December 17, 2008, 04:06:40 PM
Kugel: I already added it to the hardware mappings page for him.

FlynDice: That's odd... I think I'll try what you said and see if it works. Thanks!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: RockRabbit on December 17, 2008, 04:12:38 PM
Point taken about the power button - I will try to find it. However, am currently waiting till I get a datasheet before doing any more hacking. I have requested one so hopefully wont be long now till I can get things moving. In the meantime I will investigate the main ROckbox code and see what I can pick up about how it works.

Most of my life ive worked in IT writing software, usually for large companies. I have to say that doing Rockbox is a thousand times more interesting and satisfying. The pay is'nt as good, but there is lots of job satisfaction and how often do you get to listen to your code? Would'nt it be great if the Rockbox hardware could get made too?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on December 17, 2008, 05:22:32 PM
Point taken about the power button - I will try to find it. However, am currently waiting till I get a datasheet before doing any more hacking. I have requested one so hopefully wont be long now till I can get things moving. In the meantime I will investigate the main ROckbox code and see what I can pick up about how it works.

Most of my life ive worked in IT writing software, usually for large companies. I have to say that doing Rockbox is a thousand times more interesting and satisfying. The pay is'nt as good, but there is lots of job satisfaction and how often do you get to listen to your code? Would'nt it be great if the Rockbox hardware could get made too?
I have a datasheet. If you want to know something I can give you some information. Also, our Rockbox source code is a fine source of information already.
The base addresses of the GPIO ports:
GPIOA_BASE           0xC80B0000
GPIOB_BASE           0xC80C0000
GPIOC_BASE           0xC80D0000
GPIOD_BASE           0xC80E0000

You can read each pin using this formula:

GPIOx_BASE+(1<<(X+2))

where X is your pin and x A, B, C or D (the signficant pins are PAD_ADDR[9:2], that's why the +2).

To set pins use the mentioned formula and do
GPIOx_BASE+(1<<(X+2)) = (1<<X)

To clear just
GPIOx_BASE+(1<<(X+2)) = 0

You can set/clear GPIOx_DIR for pins using this
GPIOx_BASE+0x400 = (1<<7|..)

I hope this gets you somewhere until you have the datasheet.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: RockRabbit on December 17, 2008, 06:50:55 PM
Thanks hugel.

But could you explain what you mean by BASE and DIR?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on December 17, 2008, 06:57:17 PM
GPIOx_BASE just stands for the base adress, i.e. the starting address of a port.

DIR (stands for direction), as already said, decides whether a pin is configured as output or input. output means we can safely write to it (with our software), input means the hardware can safely write to it.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: RockRabbit on December 17, 2008, 11:24:14 PM
If i address a GPIO pin using the code "ldr   r1, [r0, #0x8] " where r0 has the base address of the IO port A, am I right in thinking that this is pin A1? Similarly would "ldr   r1, [r0, #0x10] " be A2?

Also, I notice that some of the pins seem to detect on bit unset (0), others on bit set (non zero). Is this normal?

I notice that in the hardware mappings twiki, no mention is made of which logic level is used for each port/button combination. Is that becuase it is not necessary or because I have got confused somewhere?

Thanks,  :o
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on December 18, 2008, 06:57:35 AM

Quote
If i address a GPIO pin using the code "ldr   r1, [r0, #0x8] " where r0 has the base address of the IO port A, am I right in thinking that this is pin A1? Similarly would "ldr   r1, [r0, #0x10] " be A2?
This is true. And Pin 7 is (1<<7+2) -> (1<<9) -> 512 -> 0x200. I think you got it now :)

Quote
Also, I notice that some of the pins seem to detect on bit unset (0), others on bit set (non zero). Is this normal?
Yes, the states at boot up don't have to be the same for all pins.

Quote
Is that becuase it is not necessary or because I have got confused somewhere?
I don't know. Probably the creator haven't thought of it (maybe because he didn't have enough inforomation at that time) when he created it.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: RockRabbit on December 18, 2008, 07:12:15 AM
Thanks kugel.

I have mapped the MicroSD present pin -> A2 (high), and the USB present pin -> A1 (low). I have write access to the twiki so I will update the hardware mappings myself tomorrow, but you can do it if you want to.

I have run tests now against almost all the pins (all but two). The only button I can detect apart from the power button is the right button which is detectable on pin C6. It looks to me like this model might have the row/column scanning structure like the clip and the m200. I am guessing that perhaps the right button is detected because of default values on the row driver pins. I note that the button mappings are the same for the clip and m200. The ports are different but the row/column arrangement is the same. If so that might mean that the input pins are C5 thru C7, with the right button showing on C6, the middle pin, as with the clip and m200. But this is pure speculation.

Any suggestions about what to do next will be greatly appreciated. I would very much like to be able to disassemble the OF, but arm-elf-objdump objects to the format of the OF bin file. Any ideas?

thanks  ;)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on December 18, 2008, 07:46:53 AM
Great news!

What to do next? Integrate the c200v2 into the Rockbox tree, so that we can use bootloaders, which are save and where we can use C code.
It could well be that it's using a keyscan matrix. But it could also be direct connections. Note that e200v2/Fuze also have Right on C6.

Oh, and we should bug linuxstb to edit mkamsboot to support c200v2.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: gabe565 on December 18, 2008, 04:23:04 PM
Kugel: Are you sure that the Fuze and the e200v2's right keys are on C6? On the hardware mappings page, it says down is C6 and right is C5. I also have write permissions to the Twiki, so I can update it if you want!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on December 18, 2008, 04:31:23 PM
Not anymore :) I just misread sorry.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: RockRabbit on December 18, 2008, 04:55:23 PM
Great news!

What to do next? Integrate the c200v2 into the Rockbox tree, so that we can use bootloaders, which are save and where we can use C code.
It could well be that it's using a keyscan matrix. But it could also be direct connections. Note that e200v2/Fuze also have Right on C6.

Oh, and we should bug linuxstb to edit mkamsboot to support c200v2.

Can you tell me where the experimental Rockbox code is? Or is it simply the latest version in trunk?

I might like to attempt this for the fun of it, even if my code is not used. However is there a proper way to do this, e.g. is there someone who is delegated to do this kind of thing?

I have a copy of the current version of mkamsboot, and it looks fairly straightforward (peels of laughter sound from around the world) to add some c200 code to detect the USB cable. Presumably I could mod that and test it even without anything else rockboxy being on the player.

One last question - is it possible that the other buttons are hooked up to GPIOC and I simply stuffed up the code when I was looking for them? Or in other words, is there a possibility that some other setting is interacting with the port that stopped the other pins working?

One even laster quesrion - Is it possible to dissassemble the OF (C200PA.BIN) using arm-elf-objdump?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on December 18, 2008, 05:18:40 PM
Can you tell me where the experimental Rockbox code is? Or is it simply the latest version in trunk?
Yes, the SVN is developement and experimental at once. Only for release the code is branced.

I might like to attempt this for the fun of it, even if my code is not used. However is there a proper way to do this, e.g. is there someone who is delegated to do this kind of thing?
Not that I know of. But just look at the source and the target tree system, and even the SVN history when other ports got their initial commit. It's quite easy.

I have a copy of the current version of mkamsboot, and it looks fairly straightforward (peels of laughter sound from around the world) to add some c200 code to detect the USB cable. Presumably I could mod that and test it even without anything else rockboxy being on the player.
As far as I know, mkamsboot doesn't contain the dual boot. It's the dualboot.S files in there which contains the dual boot functionality. You need to edit that too to have proper dual boot. mkamsboot handles patching your OF with the dual boot and the compiled bootloader (see here why dual boot works independently of the bootloader).

One last question - is it possible that the other buttons are hooked up to GPIOC and I simply stuffed up the code when I was looking for them? Or in other words, is there a possibility that some other setting is interacting with the port that stopped the other pins working?
It's possible. And it doesn't necessarily suprise me if there are buttons you didn't find. On the Fuze, I haven't found a single button using the method you used, even though there're at least 6 buttons directly attached to GPIO. You can actually feel lucky that you found so much.

One even laster quesrion - Is it possible to dissassemble the OF (C200PA.BIN) using arm-elf-objdump?
Yes. You can use this command: arm-elf-objdump -D --target binary -marm C200PA.BIN --start-address=0x400 --stop-address=0x20000 -Mforce-thumb > disasm.txt

--start-address skips the firmware header which doesn't contain code.
--stop-address=0x20000 limits the disassembly to not go beyond that adress, so that you don't get the whole libraries(codecs,drm stufff etc) disassembled, but only the main firmware(the interesting part). Note that the output is thumb code, not ordinary arm code.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: gabe565 on December 18, 2008, 05:25:07 PM
Kugel: OK, I was just wondering if you messed up or if the wiki was messed up!  ;D

Until we know if the c200 uses a keyscan method like the Clip and m200, I'll just add the right button to the hardware mappings page as C6.

EDIT: Nevermind, Kugel covered everything I said except he worded it a little better...
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: RockRabbit on December 18, 2008, 07:00:47 PM
Is it likely that some of the buttons have been wired to output pins on the IO ports, such that the button must be "energised" by setting a particular pin to output before it will be able to signal the input pin? this way the buttons would be hidden and much more difficult to locate? Has this happened before?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: gabe565 on December 18, 2008, 07:05:51 PM
I don't know of this happening in any Sansa devices before, but it is possible. I don't know how you would find them this way, do you?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on December 18, 2008, 07:07:04 PM
Is it likely that some of the buttons have been wired to output pins on the IO ports, such that the button must be "energised" by setting a particular pin to output before it will be able to signal the input pin? this way the buttons would be hidden and much more difficult to locate? Has this happened before?
That's surely possible. You're trying to read without anything being initialized by an OS. You're in a state between ROM and an actual bootloader of Software. It might be that e.g. the lcd needs to be initialized which itself then makes it indirectly possible to use other GPIOs and stuff.

And again, I didn't found any button for my Fuze with this method.

We actually have enough now for building a bootloader, so I wouldn't focus too much on this any more. Our bootloader will already have system initializations and hardware setup (kernel_init(), system_init()) that is already nicely implemented for the other AMS targets.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: RockRabbit on December 19, 2008, 04:23:04 AM
Quote
We actually have enough now for building a bootloader, so I wouldn't focus too much on this any more. Our bootloader will already have system initializations and hardware setup (kernel_init(), system_init()) that is already nicely implemented for the other AMS targets.

I'll wait till someone else is able to do that - its beyond my capabilities (at least at the moment) - and i'll pick up again when its done. I'll be glad to do whatever I can once there is a proper dual boot setup for the c200.

In the meantime i'm building a test bootloader that has subroutines that will flash the button light a set number of times (almost complete) that will enable multiple conditions to be tested in a single pass. It might actually be useful but if not its good practise for me with arm assembler (getting to grip with subroutine linkage and stack handling).

If anyone out there wants me to try something out on my c200, please let me know.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on December 19, 2008, 12:29:58 PM
Hi peeps,

its been a while, but I finally got some spare time to look back at the OF and investigated the buttons for the e200/fuze/c200 targets. As I previously said, the OF reads those buttons using DBOP. But we are also able to read some using GPIOs. It tickled me for some time but now I got an explanation for this and it is a shame I didn't notice before: some GPIO pins are shared with the DBOP data lines! ;D

This basically means that it "should" be possible to read the buttons using either the GPIO or the DBOP. However, DBOP also controls some control lines which could theorically be wired to devices chip select pins and such. This leads me to recommend using DBOP as in the OF for reading the buttons on those targets. This is only a couple of lines of code really, but it needs to be carefully put together. And as a bonus, maybe using DBOP will correct some of the current LCD/whatever bugs some people see with those targets.

I already sent a (commented) disassembly source to kugel which will look into and probably create a test code with it. If anyone is seriously interested in it, I could also send it through PM, but sadly (for legal reasons), I won't post my disassembly here.

I still read and contribute this thread but I don't have much time these days to write so feel free to comment/write to me if you need more help, I'll be glad to do what I can :)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on December 19, 2008, 12:58:15 PM
RockRabbit: I put up http://www.rockbox.org/tracker/task/9679 so that the c200v2 is integrated into the source. Note that most is guess work (which is fine for now), but we need to know the particular memory size.
Please patch your c200v2 with a stock OF named "c200pt.bin", this will hopefully enable the diagnosis mode, in which the memory size is stated.

Play around with my patch, but beware that it is completely untested. It may or may not brick (one of) your c200v2.
It'll at least build a bootloader with loops after doing init stuff.

I've made dualboot.S so that it boots the OF if USB is inserted or RIGHT is pressed. That's based on the information your findings.

atomicpunk: Thanks again!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Hillshum on December 19, 2008, 05:14:58 PM

Could some folks who have loaded modded firmwares on AMS sansas please see if DRM still works? I seem to have broken my Sansa's DRM support by doing so. If this is really the case, then e200s are not fully recoverable.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: RockRabbit on December 19, 2008, 10:14:35 PM
RockRabbit: I put up http://www.rockbox.org/tracker/task/9679 so that the c200v2 is integrated into the source. Note that most is guess work (which is fine for now), but we need to know the particular memory size.
Please patch your c200v2 with a stock OF named "c200pt.bin", this will hopefully enable the diagnosis mode, in which the memory size is stated.

Play around with my patch, but beware that it is completely untested. It may or may not brick (one of) your c200v2.
It'll at least build a bootloader with loops after doing init stuff.

I've made dualboot.S so that it boots the OF if USB is inserted or RIGHT is pressed. That's based on the information your findings.

atomicpunk: Thanks again!

You'll have to explain further about c200pt.bin. Where do i get it, and where did it come from?

Is there a way I can mod my bootloader code to ascertain how much memory the thing has? I really dont want to risk bricking it at this early stage if possible.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Hillshum on December 19, 2008, 10:28:08 PM
Take an OF image from wherever, name it c200pt.bin, and load it on sansa. Go to Settings>Diagostic and follow that.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: RockRabbit on December 19, 2008, 10:53:24 PM
Take an OF image from wherever, name it c200pt.bin, and load it on sansa. Go to Settings>Diagostic and follow that.

thanks

I ran the diagnostics - dram size shows as only 2MB. From version 1 to 2 we seem to have dropped 30 mbytes. Is that a show stopper for some of the more advanced rockbox functionality?

I have a bootloader which tests for a button press in a continuous loop. If i press the button that is being detected in the loop, the loop detects the button press continuously, even after one single press. Somehow the pin is not being reset. However the code appears to do this:


           ldr   r0, =GPIOA
           mov   r1, #0
           str   r1, [r0, #0x400]
           ldr   r1, [r0, #(1<<5)]    /* read pin A3 */
           cmp   r1, #0
           beq   tpwr

The third line (str...) as far as i know is the code to reset the pin. Can anyone explain what I am missing or why one press should keep the pin set (low in this case).?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on December 20, 2008, 08:17:38 AM
Well when you read the GPIO, you do read the state of the pin, not a single button press edge, so yes, this is normal. Every read with a button pressed will do the same. And since the code runs awfully fast compared to the speed of a finger, you'll probably always get multiple button pressed state in your loops... You can do something like "if button is pressed, loop until it is unpressed again before continuing" if that's really what you want... But I'd also put a limit to that waiting in case something goes wrong...

Oh and the third line is to set the pin as an input, not to reset its state :)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: RockRabbit on December 20, 2008, 03:35:30 PM
Well when you read the GPIO, you do read the state of the pin, not a single button press edge, so yes, this is normal. Every read with a button pressed will do the same. And since the code runs awfully fast compared to the speed of a finger, you'll probably always get multiple button pressed state in your loops... You can do something like "if button is pressed, loop until it is unpressed again before continuing" if that's really what you want... But I'd also put a limit to that waiting in case something goes wrong...

Oh and the third line is to set the pin as an input, not to reset its state :)

Thanks.

I understand what you are saying, but that does not explain my situation. When I detect the pin signal (low in this case), i execute a subroutine that flashes the button light on and off three times - which takes about 6 seconds. By the time this loop has completed, the button has been released some five seconds ago. The code then resumes the original loop looking at the state of the pin. It immediately detects the pin is low and begins the flashing routine, despite the button being unpressed. In other words the pin state is now "on" and will remain so, presumably till the battery goes flat or I get an epileptic fit watching the flashing button.

Either the pin remains at the button pressed state until "reset" (whatever that means) which seems impossible, or I have a bug in my code - but im damned if I can see it.

Anyone have a comment re the only 2Mbytes of ram on the c200 v2 target? Is thgat a problem being so low (for audio - I could care less about games or video).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on December 20, 2008, 03:36:41 PM
Anyone have a comment re the only 2Mbytes of ram on the c200 v2 target? Is thgat a problem being so low (for audio - I could care less about games or video).

Its somewhat of a problem, see for example the Clip which also has 2MB.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on December 20, 2008, 04:42:06 PM
Either the pin remains at the button pressed state until "reset" (whatever that means) which seems impossible, or I have a bug in my code - but im damned if I can see it.

Anyone have a comment re the only 2Mbytes of ram on the c200 v2 target? Is thgat a problem being so low (for audio - I could care less about games or video).
Well, apparently you have to reset the pins manually. Switch the pin to output (GPIO_DIR = 1<<X) and write the opposite value (GPIO_PIN(X) = [0 or (1<<X]), then switch to intput again (GPIO_DIR = 0).

BTW: I would really welcome if you try my patch and use a bootloader made by the build system. This is way safer, as dual boot remains if you have a bugged bootloader.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: RockRabbit on December 20, 2008, 06:09:48 PM
Either the pin remains at the button pressed state until "reset" (whatever that means) which seems impossible, or I have a bug in my code - but im damned if I can see it.

Anyone have a comment re the only 2Mbytes of ram on the c200 v2 target? Is thgat a problem being so low (for audio - I could care less about games or video).
Well, apparently you have to reset the pins manually. Switch the pin to output (GPIO_DIR = 1<<X) and write the opposite value (GPIO_PIN(X) = [0 or (1<<X]), then switch to intput again (GPIO_DIR = 0).

BTW: I would really welcome if you try my patch and use a bootloader made by the build system. This is way safer, as dual boot remains if you have a bugged bootloader.

I will try the patch eventually. Its more learning curve for me to figure out how to load and apply the patch, understand what it does, etc, plus it then moves development over into C, which I have never used a lot and have not used for quite a while - more learning curve. At least the assembler is simple. And the current bootlader I understand, and I want make the most of it before I move on to something new.

This situation with resetting the GPIO pins makes me think that all the other buttons are there if I first initialise the pins before trying to read them. Some of the pins adjacent to the C6/right button that are all seemingly permanently low (the same as the right button when pressed) may just need resetting before use, and will prove to be connected to the other buttons. It makes sense for me to try this as it is so simple to do and it is something I currently understand.

By the way - do you have a comment to make re the lack of dram - only 2Mbytes? Or don't you see that as a major problem?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on December 20, 2008, 06:16:41 PM

By the way - do you have a comment to make re the lack of dram - only 2Mbytes? Or don't you see that as a major problem?

I suppose I could have been more specific.  The 2MB RAM problem causes some of the playback issues on the Clip.  It will require some reworking of playback to deal with.  However, since the Clip port is well ahead, I don't think its something you really need to worry about now.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on December 20, 2008, 06:23:13 PM
Well, 2MB is definitely not desirable, but Rockbox is designed to run on a wide range of playes, including those with a plenty of RAM and those with very little RAM.

That means, there might be some feature restrictions (none that matter though, mainly in plugins, unlikely any in the core), and Rockbox will generally run, nicely.

And, due to being a flash target, RAM isn't so critical for audio buffering (for which the rest of the ram, that doesn't hold the binary, is used), since accessing flash is fast and cheap (energy-wise) compared to hard disc drives.

The c200 (and the c200v2 most likely too?) has a color display. Those require slightly more RAM compared to greyscale or mono targets. But I don't expect this to be a real problem - if at all.

Don't mind about the RAM for now. Until we're trying to play music, 2MB will be enough. After that, we'll get onto some optimisations and it'll just run nicely - given that the remaining MP3 & Co. problems can be fixed (which also are present on higher RAM AMS Sansas). That's at least my expectation.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: RockRabbit on December 20, 2008, 08:04:47 PM
Thanks kugel.

Yes the v2 c200 does have a colour display. The player is externally identical to the v1 and aside from the fact that its completely different it is identical (excuse my odd sense of humour). Put it this way, if I gave you both versions running the original firmware, if you did not look at the firmware revision number or the small "v2" printed on the back of the case, it would not be possible to tell the two apart.

I found three more buttons by pre-setting the logic levels of some of the pins. Using my new flashing-light bootloader, I can detect four buttons at a time. Ive updated the twiki. They are:

c3 - down button , c4 - select button, c5 - up button.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on December 20, 2008, 08:22:59 PM
c3 - down button , c4 - select button, c5 - up button.
That's cool! It would be nice if you could note whether high or low indicate button presses. Maybe not on the HardwareMapping page, but on a dedicated page (like a SansaC200V2Port or so..)

But on the other hand, I guess it really doesn't hurt if the table gets expanded by a level indicator and maybe a default value cell for each pin.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: RockRabbit on December 20, 2008, 10:12:20 PM
kugel - how do I apply your 9679 patch and to what do I apply it?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on December 20, 2008, 10:25:42 PM
You apply them to SVN (trunk). See here for a small guide: http://www.rockbox.org/twiki/bin/view/Main/WorkingWithPatches

The first patch adds c200v2 to our firmwarepatcher tool, the second one adds the c200 as a target into the rockbox tree.

After you patched, please double-check [sourcedir]/rbutil/mkamsboot/dualboot.S to see if I have done something wrong.

After than you need to build mkamsboot. To do that, just type make in [sourcedir]/rbutil/mkamsboot/.
You can then build a bootloader using these instructions: http://www.rockbox.org/twiki/bin/view/Main/HowToCompile
You should get a bootloader file(bootloader-c200v2.sansa), which you pass together with C200PA.bin to mkamsboot (./mkamsboot <OF file> <bootloader file> <patched file>. The patched file is that what you put on your c200v2 after renaming it to c200pa.bin.

Our bootloader code is situated in  [sourcedir]/bootloader/sansa-as3525.c. This is the file you should edit for your experiments.

Some tests would be: test if buttonlight_on() works. test if backlight_on() works. test if lcd_init() works. While I'm doubtfully about lcd_init, I think backlight should actually work.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: RockRabbit on December 20, 2008, 10:27:33 PM
thanks. i'll give it a try.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on December 20, 2008, 10:38:50 PM
Uhm, before you build the bootloader (but after patching) edit firmware/target/arm/as3525/system-as3525.c and tools/configure to reflect the correct memory (I guessed 8MB when I made the patch).

And sorry that I need to say it again: Double-check rbutil/mkamsboot/dualboot.S. This file is critical! Wrong code will brick your player. So please check if I added the correct GPIO states for USB present and Right button.

Sorry, we can't be safe enough about that file :)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: RockRabbit on December 21, 2008, 12:33:06 AM
Uhm, before you build the bootloader (but after patching) edit firmware/target/arm/as3525/system-as3525.c and tools/configure to reflect the correct memory (I guessed 8MB when I made the patch).

And sorry that I need to say it again: Double-check rbutil/mkamsboot/dualboot.S. This file is critical! Wrong code will brick your player. So please check if I added the correct GPIO states for USB present and Right button.

Sorry, we can't be safe enough about that file :)

I did have to change the code which checks for the "right" button - it should be looking at logic level 0 not 1.

I changed:
        cmp   r1, #1                /* C6 high means button pressed */
        beq   boot_of
to:
        cmp   r1, #0                /* C6 high means button pressed */
        beq   boot_of

If i mistakenly stated the wrong level in a previous post i apologise.
The other thing I found is very minor, and that is the new option 59/ for the c200 during the build actually shows e200V2 on the display rather than c200v2, so there are now two options for the e200v2. I did not change this because as far as I can see this is only cosmetic and shown on the display - the code builds for the correct target anyhow.

Anyhow following your excellent instructions I was able to quickly do all that was required and have now built a new BIN file, with no apparent problems. The only thing I had to do to get the main tree patch to work was to enter a -P0 option otherwise it could not find the files. Remember all this stuff is new to me, but I am getting the hang of it.

I have not as yet edited the sansa_as3525.c file, I have just got the patch/build process to work and complete, to see that I could do it. Now I will go on to the next stage and edit the file, rebuild and actually load onto the player.

Is the only thing I have to change in regards to the dram config from this:

#if defined(SANSA_CLIP) || defined(SANSA_M200V4)
/* 16 bits external bus, low power SDRAM, 16 Mbits = 2 Mbytes */
#define MEMORY_MODEL 0x21

#elif defined(SANSA_E200V2) || defined(SANSA_FUZE) || defined(SANSA_C200V2)
/* 16 bits external bus, high performance SDRAM, 64 Mbits = 8 Mbytes */
#define MEMORY_MODEL 0x5

to this:

#if defined(SANSA_CLIP) || defined(SANSA_M200V4) || defined(SANSA_C200V2)
/* 16 bits external bus, low power SDRAM, 16 Mbits = 2 Mbytes */
#define MEMORY_MODEL 0x21

#elif defined(SANSA_E200V2) || defined(SANSA_FUZE)
/* 16 bits external bus, high performance SDRAM, 64 Mbits = 8 Mbytes */
#define MEMORY_MODEL 0x5
??
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on December 21, 2008, 09:48:47 AM
Thanks a lot for the testing and editing.

So, have you actually updated your player with a patched OF (created by mkamsboot)? If yes, and if dualboot works, I think my patch can be committed (with the changes you mentioned of course).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: RockRabbit on December 21, 2008, 04:18:48 PM
Thanks a lot for the testing and editing.

So, have you actually updated your player with a patched OF (created by mkamsboot)? If yes, and if dualboot works, I think my patch can be committed (with the changes you mentioned of course).

Not yet. I need an answer to the question above (in my previous post), re the change to the dram setting. Once I know thats ok, I will go ahead.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on December 21, 2008, 05:54:04 PM
Thanks a lot for the testing and editing.

So, have you actually updated your player with a patched OF (created by mkamsboot)? If yes, and if dualboot works, I think my patch can be committed (with the changes you mentioned of course).

Not yet. I need an answer to the question above (in my previous post), re the change to the dram setting. Once I know thats ok, I will go ahead.
Yes, your change is correct.

Edit: You'll also want to change tools/configure to reflect the correct memory (search for "59)" and you'll get to the c200v2 part).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: RockRabbit on December 21, 2008, 06:32:28 PM
thanks.

Ill get on to it right away.

Kugel - Made another change - the code to detect the boot up condition was set to pin A3 - this is the power button. However you refer to this code as detecting the USB cable, which it does normally for all other players. Not sure whether you want this to be the power button or the usb cable. I changed it to be the USB cable, pin A1.

Applied the new bootloader with no problems. At present it does nothing, but it responds properly to the usb cable and holding down the right button - so its a safe bootloader.

How will we handle the changes - will you do them manually or should I email you the changed files?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on December 22, 2008, 06:17:27 PM
Uhm, no, I had it set to A1 ("ldr   r1, [r0, #0x8]    /* it's A1 on C200 */"). What did you exactly change to make it work?

I suggest you do "svn diff rbutil/mkamsboot/ > patch.diff" and upload the file to the task (http://www.rockbox.org/tracker/task/9679). You can of course sent it to me by email or any other way of your choice (my email is: thomas47@arcor.de).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: RockRabbit on December 22, 2008, 07:25:08 PM
Uhm, no, I had it set to A1 ("ldr   r1, [r0, #0x8]    /* it's A1 on C200 */"). What did you exactly change to make it work?

I suggest you do "svn diff rbutil/mkamsboot/ > patch.diff" and upload the file to the task (http://www.rockbox.org/tracker/task/9679). You can of course sent it to me by email or any other way of your choice (my email is: thomas47@arcor.de).

Apologies. Your code was fine. I did not pay enough attention to the code - i mistook the ifndef for an ifdef (not being familiar with the coprocessor and doing it in a rush). Forget I ever mentioned it - ignore the ramblings of an old man.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on December 22, 2008, 07:30:54 PM
Ah ok, fine. I think you're right. Using #ifdef is better, as it's more clear. I also always expect #ifdef and don't pay much attention on whether there's an n between or not. Also #ifdef SANSA_C200V2 makes it just clearer what code is used for that target and what not.

Can you please give me a short sum up on what you changed? The memory stuff and...?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: RockRabbit on December 23, 2008, 10:25:57 PM
I think this is all I changed in total..

system-as3525.c
line 186+
moved the SANSA_C200V@ from the 8 mybtes group (next to the FUZE) to the 2 mbytes group (next to M200V4)
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
#if defined(SANSA_CLIP) || defined(SANSA_M200V4) || defined(SANSA_C200V2)
/* 16 bits external bus, low power SDRAM, 16 Mbits = 2 Mbytes */
#define MEMORY_MODEL 0x21

#elif defined(SANSA_E200V2) || defined(SANSA_FUZE)
/* 16 bits external bus, high performance SDRAM, 64 Mbits = 8 Mbytes */
#define MEMORY_MODEL 0x5
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
/tools.configure
line 1761+
changed the memory= from 8 to 2
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
   59|c200v2)
    target_id=55
    modelname="c200v2"
    target="-DSANSA_C200V2"
    memory=2 # wild guess
    arm9tdmicc
    bmp2rb_mono="$rootdir/tools/bmp2rb -f 0"
    bmp2rb_native="$rootdir/tools/bmp2rb -f 4"
    tool="$rootdir/tools/scramble -add=c2v2"
    output="rockbox.sansa"
    bootoutput="bootloader-c200v2.sansa"
    appextra="recorder:gui"
    plugins="yes"
    swcodec="yes"
    # toolset is the tools within the tools directory that we build for
    # this particular target.
    toolset=$scramblebitmaptools
    # architecture, manufacturer and model for the target-tree build
    t_cpu="arm"
    t_manufacturer="as3525"
    t_model="sansa-c200v2"
    ;;
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

/rbutil/mkamsboot/dualboot.s
line 124+
changed the cmp r1, #1 to cmp r1, #0
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
#elif defined(SANSA_C200V2)
        /* check for RIGHT on C6, should maybe changed to LEFT as soon as it
         * known in which pin that is in order for consistency  */
        ldr   r0, =GPIOC
        mov   r1, #0
        str   r1, [r0, #0x400]      /* set pin to output */

        ldr   r1, [r0, #0x100]      /* 1<<(6+2) */
        cmp   r1, #0                /* C6 high means button pressed */
        beq   boot_of
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on December 23, 2008, 10:35:53 PM
Thanks! That means I remembered correctly. I already put a new (supposedly final) patch on the task.

Good to know my patch didn't break other people's mp3 player ;)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on December 23, 2008, 10:37:13 PM
Also, learn to use patches.  Its really annoying having to figure out what you changed otherwise.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on December 23, 2008, 11:56:42 PM
The c200v2 patch has just been committed to SVN.

RockRabbit, I'd welcome if you play a bit around with the Rockbox bootloader (remember: You can do anything with it, since dual boot isn't dependent on a working bootloader). In particular I'm curious if backlight_on() and/or buttonlight_on() are working (just add those before the #ifdef SANSA_C200V2 line in bootloader/sansa_as3525.c).

And if you have any questions regarding the build system rockbox uses, don't hesitate to ask :) It may take some time, but you'll find your way through the target tree(forest rather).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: RockRabbit on December 24, 2008, 11:57:10 PM
I have re-installed the rockbox tree from the latest version on svn. I have tried the calls you suggested to the functions backlight_on(),    buttonlight_on() and lcd_init().

The backlight_on and buttonlight_on calls appear to do nothing. The lcd_init() call turns the screen backlight on, giving a blank white screen, before turning off again after about a quarter of a second. It appears then that the player has turned off, since pressing the power button again will trigger the same sequence. Since a perpetual while loop follows the call to lcd_init, I am inclined to think that the code crashes during the lcd_init routine, and the while loop is never reached.

With the backlight_call, the player stays active, presumably within the while loop.

What confuses me is that I can find no definition for the buttonlight_on function anywhere within the rockbox tree. I have used the Gnome search tool to look for buttonlight_on() and several files are listed, but they all call the function, not define it. Yet the code compiles, which indicates (i presume) that the compiler has a definition for the function somewhere, although there is some kind of "implicit definition" warning.

I can't determine from your post whether you intend for me to create this function, but I am assuming not. Can you explain what is happening here?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on December 25, 2008, 02:02:18 AM
What confuses me is that I can find no definition for the buttonlight_on function anywhere within the rockbox tree.

The one you want is in backlight-c200v2.c.  Theres actually a dozen or so of them in the target tree, so if your search tool isn't finding them, its probably not working right.  I suggest using grep.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on December 25, 2008, 08:15:46 AM
Well, in backlight-c200v2.c there's _buttonlight_on() (with the leading underscore), but that's the actual function that turns it on (you can try calling directly that instead of buttonlight_on()), buttonlight_on calls that in a roundabout way. The functions with the underscore are generally those who touch the hardware, while the ones without are the ones which are supposed to be used by "the user" (i.e. not low-level stuff such as apps/ code).

Interesting that lcd_init did someting.

€dit: IIRC it's possible that you need to call backlight_on (or _backlight_on) before buttonlight_on (or _buttonlight_on).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: stel on December 30, 2008, 04:04:41 AM
Hi,
I took my 8Gb Clip(v2) apart last night and have the following info:
SoC: 20-82-00196-4 : S835-NH7332 : SA0342-8
FM: 0219 CC6S 832
Memory: S83718794 : SDTNLLCHSM-8192 : DP0025407AR
Board: M300 VER2.6

I've got a few pic's if anyone needs them, and although I'm not used to using TWiki I can post my findings if someone would point me in the right direction as to the most suitable page.

Let me know if I can be of any more help.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Modernwarfare on December 31, 2008, 01:11:03 PM
Hello, im sorry if that's a little too off-topic but id like, although my leak of knowladge at what your edoing, to help in the developpment of the rockbox for the v2 models- since i own one and wanted to help as much as i can.
i understood taking the device apart and taking some pictures of it might help.
please not me of any way wich i could help in this.
(email me if you like- omerisrael@gmail.com)
keep on doing you great work (just a bit faster, please) :D
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on December 31, 2008, 03:53:10 PM
Hello, im sorry if that's a little too off-topic but id like, although my leak of knowladge at what your edoing, to help in the developpment of the rockbox for the v2 models- since i own one and wanted to help as much as i can.
i understood taking the device apart and taking some pictures of it might help.
please not me of any way wich i could help in this.
(email me if you like- omerisrael@gmail.com)
keep on doing you great work (just a bit faster, please) :D

Looking at the wiki, we still need c200v2 pictures, so feel free to add those.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on January 01, 2009, 05:52:08 AM
I took my 8Gb Clip(v2) apart last night
...
I've got a few pic's if anyone needs them, and although I'm not used to using TWiki I can post my findings if someone would point me in the right direction as to the most suitable page.

Hello

You can create a SansaClipv2 page and link it from the SansaV2 page, but you'll need to come on IRC (irc://irc.freenode.net/#rockbox) first to get write access to TWiki
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on January 01, 2009, 08:33:04 AM
RockRabbit, reading your posts we're not too far away. If you saw a white background it means that a) backlight works and b) some parts of the LCD driver also work.
Can you please double check buttonlight_on() / _buttonlight_on() (both should work), I'd be really surprised if that doesn't work.

I'm gonna have a look at the c200v2 disassembly for a LCD driver.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Modernwarfare on January 01, 2009, 10:51:53 AM
Hello, im sorry if that's a little too off-topic but id like, although my leak of knowladge at what your edoing, to help in the developpment of the rockbox for the v2 models- since i own one and wanted to help as much as i can.
i understood taking the device apart and taking some pictures of it might help.
please not me of any way wich i could help in this.
(email me if you like- omerisrael@gmail.com)
keep on doing you great work (just a bit faster, please) :D

Looking at the wiki, we still need c200v2 pictures, so feel free to add those.

oh, well. mine is E280 v2
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: KerwoodDerby on January 07, 2009, 09:23:35 AM
I added photos (http://www.rockbox.org/twiki/bin/view/Main/SansaC200v2) of the board in my new Sansa c250 v2 (firmware 03.02.05) in the wiki.

There are 7 pads in a row on this board (not 8 ). I don't know what this means; if it is JTAG, perhaps one of the signals is unused in this configuration.

Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: atomikpunk on January 07, 2009, 04:49:11 PM
I added photos (http://www.rockbox.org/twiki/bin/view/Main/SansaC200v2) of the board in my new Sansa c250 v2 (firmware 03.02.05) in the wiki.

There are 7 pads in a row on this board (not 8 ). I don't know what this means; if it is JTAG, perhaps one of the signals is unused in this configuration.

Well the M200v2 only have 7 JTAG pins, as described here (http://forums.rockbox.org/index.php?topic=14064.msg129684#msg129684) So maybe this port on the C200 is also for JTAG :)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sko on January 08, 2009, 04:13:28 PM
Hi!

I found something about the wheel on the e200v2: I'm using the fuze-button driver for it but the wheel is not very reliable (it scrolls 2 or 3 menu items down and then it doesn't work at all). But if I press the ">>|"-button while scrolling with the wheel it works better: it's still not very reliable, but it scrolls as long as I press the button while scrolling (no stop after 2 or 3 items).
I don' know if this is helpful, I just wanted to tell you  :)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on January 10, 2009, 12:16:24 AM
What did you need to do to get the fuze-button driver working for the wheel on the e200v2?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sko on January 10, 2009, 04:22:57 AM
Here is the diff... I hope it works (never used diff before).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on January 10, 2009, 10:18:04 AM
Interesting. You mean, if you start scrolling and press >>|, then scrolling never stops?

For the jump'iness: You can try changing this line:
                if (queue_empty(&button_queue) && ++counter >= 4)
so that counter is higher, so that the wheel doesn't report that it has been turned so often.

Have you had success with the REC button? Did the Hold button work?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sko on January 10, 2009, 11:06:30 AM
Interesting. You mean, if you start scrolling and press >>|, then scrolling never stops?

Right. But it doesn't scroll as it should: it changes the scroll direction sometimes without scrolling the wheel in the other direction.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on January 10, 2009, 11:07:16 AM
Have you had success with the REC button? Did the Hold button work?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sko on January 10, 2009, 11:32:34 AM
The Hold button seems to be recognized, but isn't working as expected: if hold is on the lock-icon on the status bar is flashing (together with the backlight) sometimes if I press a key / scroll the wheel.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on January 10, 2009, 11:33:47 AM
The Hold button seems to be recognized, but isn't working as expected: if hold is on the lock-icon on the status bar is flashing (together with the backlight) sometimes if I press a key / scroll the wheel.
Ah so it's at least recognized. That's different from what domonoky reported when he tried this code first.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sko on January 10, 2009, 02:20:39 PM
Ah so it's at least recognized. That's different from what domonoky reported when he tried this code first.
I also changed the line
Code: [Select]
if (queue_empty(&button_queue) && ++counter >= 4)to
Code: [Select]
if (queue_empty(&button_queue) && ++counter >= 8)but now I tried with the old line too and it is the same behavior (just a bit faster if using the wheel).

Edit: but how can I test the REC button? What should happen if I press it?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on January 10, 2009, 02:25:07 PM
Try printing/logging the values DBOP_DIN gives.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on January 10, 2009, 06:18:35 PM
Maybe someone more familiar can make use of this quicker than I can.  Thanks to the diff that sko posted I was able to get into the plugins and games.  I found in the Blackjack game that I was able to reliably and precisely use the scrollwheel to control my bet increment (by 10's).  I had to use the >> button to increment by 1 first but after that I could increment up, down and stop where I wanted.  I also found that it seems with this patch the scrollwheel is more of an enabler.  What I mean by that is that in trying to navigate the menus both the >> and << buttons seem to do the moving if you start the scrollwheel first and then press one of those buttons.  I've seen the small lock icon flip open and closed with the hold switch also but cannot reliably duplicate the behavior.  The REC button has eluded any noticeable effects in my playing around.

I've also found that in rockpaint, oscilloscope, mandelbrot, bubbles, sudoku, and plasma  that putting the hold switch on turns the backlight off while switching it off turns the backlight back on(the screen is still displaying...).

Also in the sudoku game I can use the scrollwheel to scroll numbers into the boxes under complete control.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sko on January 11, 2009, 05:03:16 AM
I've also found that in rockpaint, oscilloscope, mandelbrot, and plasma  that putting the hold switch on turns the screen off while switching it off turns the screen back on.
Same in the time & date screen (System > Time & Date).

Try printing/logging the values DBOP_DIN gives.
How can I do this? I tried printf and DEBUGF, but both didn't compile. Is there a missing include? I'm not very familar with C, usually I write applications in Delphi.

Edit: I tested blackjack now, and it is working as FlynDice wrote: the wheel is reliable there.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Domonoky on January 11, 2009, 07:02:53 AM
I also just tried this patch again.

For me the wheel reading is very unreliable, you have to be very lucky that rockbox recognises a wheel event. strangely, as others noted, it seems to work better in the time & date screen.

I also tried to print out the dbop_in value (with snprintf and lcd_puts), but then i can not see any reaction to the wheel or buttons in the dbop_in value.  I suspect there is some timing problem in this, maybe it depends on if and where we interrupt the lcd ?   
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sko on January 11, 2009, 07:07:53 AM
I also just tried this patch again.

For me the wheel reading is very unreliable, you have to be very lucky that rockbox recognises a wheel event. strangely, as others noted, it seems to work better in the time & date screen.
Well... I just press and hold ">>|" and then turn the wheel and it works for me.

Edit: without pressing ">>|" it recognises the wheel just one or two times.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on January 11, 2009, 07:27:28 AM
Quite weird.

I've looked a bit at the patch.
Sko:
I noticed you changed the WHEELCLICKS_PER_ROTATION #define. Be careful with that define. It's directly connected to scrollwheel acceleration. And scrollwheel acceleration is problematic with the Fuze, possibly with the e200v2 too (as we're not using an interrupt handler [yet]).

int_btn &= ~(BUTTON_REC|BUTTON_POWER); in get_button_from_dbob??

You changed BUTTON_HOLD to BUTTON_REC, why that?
Resetting the hold button is vital for it to work properly. It might be that this change causes your weirdness.

Other than that, I can't explain that pressing >>| after the wheel causes scrolling etc.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sko on January 11, 2009, 07:41:09 AM
Quite weird.

I've looked a bit at the patch.
Sko:
I noticed you changed the WHEELCLICKS_PER_ROTATION #define. Be careful with that define. It's directly connected to scrollwheel acceleration. And scrollwheel acceleration is problematic with the Fuze, possibly with the e200v2 too (as we're not using an interrupt handler [yet]).
Well I counted the wheelclicks, and it clicks just 24 times, I thought the Fuze has maybe more wheelclicks.

int_btn &= ~(BUTTON_REC|BUTTON_POWER); in get_button_from_dbob??

You changed BUTTON_HOLD to BUTTON_REC, why that?
Resetting the hold button is vital for it to work properly. It might be that this change causes your weirdness.

Other than that, I can't explain that pressing >>| after the wheel causes scrolling etc.
Oops... this is a mistake, I was looking for all references to BUTTON_HOME, I must have accidently changed this.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on January 11, 2009, 07:47:12 AM
Well I counted the wheelclicks, and it clicks just 24 times, I thought the Fuze has maybe more wheelclicks.
Don't confuse wheel clicks with the physical clicks the wheel appears to do (the symbol should probably renamed, it confused me too).

It should hold the value of their respective DBOP_DIN changes per rotation. And that changes several times per physical clicks.
I counted 4-5 for each physical "click" on my fuze (hence only post if the counter is >= 4, so each post is equivalent to 1 item in the list). And I counted ~14 physical clicks per rotation.

I know this should give 70 wheelclicks per rotation, but honestly didn't pay to much attention into this as well, as 48 "just works" on the fuze.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sko on January 11, 2009, 08:09:50 AM
I removed the mistake in get_button_from_dbob, but the behavior of the Hold switch hasn't changed.

Don't confuse wheel clicks with the physical clicks the wheel appears to do (the symbol should probably renamed, it confused me too).
Ok, good to know, really confusing :). I changed it back to 48.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Domonoky on January 11, 2009, 11:55:53 AM
I did some more experimentation, and i can confirm, that it somehow works when you press and hold "<<" or ">>" while using the wheel. Unfortunatly i have no idea why.
Also those readings with the pressed buttons are not reliable, it sometimes finds scrollwheel and hold/rec and sometimes not. This is why we see the hold button flickering on and off.

I also did take a look a the datasheet, and noted that the wheel and other missing buttons are on dbop bit12 and upwards. Interestingly these dbop bits map not to a gpio port, but to some dedicated dbop pins. Which means we have to use dbop for this for sure.

Also the bits i can reliable read from the dbop are all below bit12, all higher bits are nearly always 0, so there must be something wrong with our dbop setup ? *speculating*

happy hacking.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on January 11, 2009, 02:31:17 PM
Also those readings with the pressed buttons are not reliable, it sometimes finds scrollwheel and hold/rec and sometimes not. This is why we see the hold button flickering on and off.
You're able to read REC (sometimes)?


Also the bits i can reliable read from the dbop are all below bit12, all higher bits are nearly always 0, so there must be something wrong with our dbop setup ? *speculating*
I don't think so. It's basically exactly what the OF does. Interesting that you found something in the datasheet. I didn't. Can you point me to the page?

Well, reading the wheel is pretty reliable on the Fuze. I was suprised if the e200v2 needs some special handling, but it's possible. I think a look in the OF can't hurt.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Mikerman on January 14, 2009, 01:19:16 AM
1-13-09:  1gb refurbished Clips for $9.99 + $5 shipping at woot.com; good until sold out or 24 hours, whichever is first ...

In case experimental units are needed.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sko on January 17, 2009, 09:27:23 AM
Hi kugel, your buttonlight-patch (http://www.rockbox.org/tracker/task/9663#comment27741) seems to do nothing on the e200v2, I tried on clean svn and with the modified fuze button-driver.

EDIT: hmm... commited patch works really good (running r19795), good work!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on January 19, 2009, 01:19:08 PM
Does anyone have the scrollwheel working correctly on the e200v2 yet?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Skream13 on January 19, 2009, 08:22:27 PM
Has anyone been able to run the simulator on the fuze yet?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on January 19, 2009, 10:17:11 PM
Has anyone been able to run the simulator on the fuze yet?

Yes, Kugel's patch for it was committed a couple months ago.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: calv on January 23, 2009, 08:22:05 AM
What about the DRM-loss issue, that was raised here? (someone lost permanently the ability to play DRM with OF after flashing custom code)

It might be good, to collect information about that: Which of the AMS players do/don't show this behaviour, which OF versions?

While this doesn't have immediately to do with rockbox, its still on topic here and worth investigating IMO, to let potential developers and testers (and later: users) know, what they can expect.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Hillshum on January 23, 2009, 02:03:07 PM
I think I am the only one to have experienced the loss of DRM. If I can get a confirmation from someone else I will take charge of the matter.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sko on January 24, 2009, 04:19:39 AM
I can confirm the DRM-loss for my e250v2: if I want to play an DRM-protected file (from www.musicload.de) I get the message "Synchronize to continue your music subscription".
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Hillshum on January 24, 2009, 10:33:15 PM
This is with a clean firmware image installed correct? (no Rockbox bootloader or anything)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sko on January 25, 2009, 03:11:43 AM
Yes, it's the 03.01.16F from http://daniel.haxx.se/sansa/v2fw.html.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Hillshum on January 25, 2009, 08:08:08 PM
Okay, thanks.

Now we need confirmations on different targets. I'll edit TWiki to reflect this discovery tomorrow unless someone does first.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: j8048188 on January 26, 2009, 01:33:21 PM
does synchronizing allow you to play the drm music again?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on January 26, 2009, 01:41:49 PM
Can we keep this thread on Rockbox developement?

I have no DRM infected music, and I have my doubts that our installation procedure makes them unusable.
But just in case it does, it doesn't matter for us. We don't care about DRM'd music at all. And thus, discussion about this is considered off-topic.

I won't delete the posts, so that the issue doesn't get forgotten (not the we intend to fix it [We surely don't intentionally brick DRM too though], but it may be important for users if the AMS Sansas are going to get supported).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: haker305 on January 26, 2009, 03:30:34 PM
Do we have working both LCD & some buttons on E200v2? When i normally compile RockBox from SVN for E200v2 i have fully working LCD, but buttons isn't working. But when i apply patch for buttons available in patches cattegory, i have issues with LCD...
I'm ready for testing some code if you need this.

haker305
P.S. Sorry for my English, I'm from Poland and 14 years old ;).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sko on January 27, 2009, 03:40:16 AM
I found something weird: I played around with Rockbox (r19857) and changed the theme to "UniCatcher". With this theme the wheel is working really good! But just in the menus, in the wps or plugins like pictureflow the wheel is still unusable.
I hope this will help you a little bit. 

EDIT: The HOLD-Switch is also working with this theme.
Title: My hello and this thread condensed into one page
Post by: weltyj on January 27, 2009, 08:55:55 PM
Hi everyone,

I just received a c250 for $15 from buy.com, and since it turned out to be a v2 not a v1, here I am  ;)

First thing I wanted to do is read through this thread, and see what progress had been made, and I found it:

1) Amazing, you are all doing great stuff here.
2) Hard to search the this particular thread for items of interest (in my case *c200*)

So, I just pulled all posts together, with only the minimal content needed so I could search for text using my browser.

Here's the link to the one page.  It is not dynamically updated  so I will rebuild it every few days...

http://www2.redhawk.org:8080/rockbox_v2_thread.html

After I successfully do a compile, I'll be glad to lend a hand with testing.

Cheers,
Jeff
Title: Re: My hello and this thread condensed into one page
Post by: kugel. on January 28, 2009, 02:17:30 AM
Hi everyone,

I just received a c250 for $15 from buy.com, and since it turned out to be a v2 not a v1, here I am  ;)

Cool, we're in the need of c250 developers. Once you compiled, can you tell me what's working in SVN and what not?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sko on February 01, 2009, 04:54:45 AM
Hi, I applied kugel´s changes on the fuze button driver to the modified version wich is working with the e200v2, now the DBOP-values on the debug-menu are visible on the e200v2 too.

EDIT:
Hmm... the value it shows for the REC-button seems to depend on the value of the scroll wheel (I have no plan about this dbop-voodoo thing, so I don't know if this behavior is correct or not), this are the values it shows (I turned the wheel clockwise and watched the DBOP_DIN values):
before pressing RECwhile pressing REC
FFFF887F087F
FFFFA87F287F
FFFFE87F687F
FFFFC87F487F
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on February 01, 2009, 08:02:46 AM
"REC-button seems to depend on the value of the scroll wheel"
What do you mean by this? Does that mean there's no reaction of dbop when pressing REC without scrollwheel, or just that the values differ?
The latter one is easily explainable. REC seems to be bit 15, which means it subtracts 8 from the 2nd pair of numbers (each pair is 1 byte). The REC button only represents 1bit, so it only changes the total number by a fixed value.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sko on February 01, 2009, 09:54:30 AM
Just the values differ, it's also working while scrolling, so REC is bit 15. Thanks for the explanation :)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on February 01, 2009, 10:06:02 AM
You can implement rec button reading just like it's done with the power button. But, don't forget that bit 15 NOT set indicates a button press (so something like, bool _button_rec = !(_dbop_din & (1<<15)) )

If you got it working, please post your patch to http://www.rockbox.org/tracker/task/9639
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on February 01, 2009, 01:38:13 PM
I've tried this code to get the rec button.  It sees the rec button as pressed during startup and clears my settings sending me back into cabbiev and buttons/wheel don't work anymore.  Is there a reason for making a  bool _button_rec variable?

static void get_rec(void)
{
    if (!(_dbop_din & (1<<15)))
        int_btn |= BUTTON_REC;
}

Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on February 01, 2009, 02:02:47 PM
I've tried this code to get the rec button.  It sees the rec button as pressed during startup and clears my settings sending me back into cabbiev and buttons/wheel don't work anymore.  Is there a reason for making a  bool _button_rec variable?

static void get_rec(void)
{
    if (!(_dbop_din & (1<<15)))
        int_btn |= BUTTON_REC;
}
That should work. But you need to reset the button state at the beginning of the dbop function (int_btn &= ~BUTTON_REC), and call get_rec at the end of it.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on February 01, 2009, 02:47:10 PM
Yes that's what I've done I think.  I used this line to reset since get_power could also modify int_btn. 

  int_btn &= ~(BUTTON_REC|
              BUTTON_POWER);

EDIT: I think I got the REC button working by putting in a bypass while rockbox is booting up.  I'm not sure how to check it out real well but when I press it the button light illuminates and the backlight comes back on.  If I can figure out how I'll post a diff to the tracker.

EDIT2:  I've tested it in several plugins also (sudoku and calculator and a few others).  It is seeing the rec button but it seems something else besides the rec button is setting DBOP 15 to 0 also.  In XOBOX the game is paused/unpaused in a regular pattern.  I did post a patch to the tracker if anyone wants to play with it some.
Title: more c200v2 info regarding pin mappings
Post by: weltyj on February 05, 2009, 10:23:00 PM
I found BUTTON_LEFT on GPIOC2

Found nothing else on GPIO's A or B for buttons, tested both high and low states.

The backlight function as implemented in the SVN trunk does not appear to work.  I could see no backlight at all.

Testing in bootloader/sansa_as3525.c:

Buttons work fine via button_read_device(), until a call is made to lcd_init(), at which point I see what appears to be the backlight come on, but the buttons are hosed (I assume because the issue of using GPIOC for both buttons and lcd has not been sorted out yet.)

I tried turning on the backlight with GPIOD 0 thru 6, but no success.  Is there any chance GPIOD might be used for BUTTTON_VOL_UP, BUTTON_VOL_DOWN or BUTTON_REC ?
Title: Re: more c200v2 info regarding pin mappings
Post by: kugel. on February 06, 2009, 01:25:02 AM
I found BUTTON_LEFT on GPIOC2
On 1 or 0?


Found nothing else on GPIO's A or B for buttons, tested both high and low states.

The backlight function as implemented in the SVN trunk does not appear to work.  I could see no backlight at all.

Testing in bootloader/sansa_as3525.c:

Buttons work fine via button_read_device(), until a call is made to lcd_init(), at which point I see what appears to be the backlight come on, but the buttons are hosed (I assume because the issue of using GPIOC for both buttons and lcd has not been sorted out yet.)
This could very well also be your sansa crashing. The lcd driver is copied from the e200v2, seems it's not working at all. Can you try the Fuze lcd-driver? (Copy lcd-fuze.c into lcd-c200v2.c) I don't think it will work but it's worth a try.

I tried turning on the backlight with GPIOD 0 thru 6, but no success.  Is there any chance GPIOD might be used for BUTTTON_VOL_UP, BUTTON_VOL_DOWN or BUTTON_REC ?
Could be, no idea It could also be that you need to switch some other PIN to find other buttons (which could then even be on the same pins as buttons already found). The backlight is certainly not on GPIO though.
Title: Re: more c200v2 info regarding pin mappings
Post by: weltyj on February 06, 2009, 07:25:54 PM
I found BUTTON_LEFT on GPIOC2
On 1 or 0?
On 0, just like all the other buttons.

This could very well also be your sansa crashing. The lcd driver is copied from the e200v2, seems it's not working at all. Can you try the Fuze lcd-driver? (Copy lcd-fuze.c into lcd-c200v2.c) I don't think it will work but it's worth a try.
I'll give it a try.
---
No luck.  I tried both the Fuze and the e200v2 drivers.  The clip and m200v4 drivers aren't drop in replacements so that will take a little more effort to try those if you think it's possible they'll work.

I tried turning on the backlight with GPIOD 0 thru 6, but no success.  Is there any chance GPIOD might be used for BUTTTON_VOL_UP, BUTTON_VOL_DOWN or BUTTON_REC ?
Could be, no idea It could also be that you need to switch some other PIN to find other buttons (which could then even be on the same pins as buttons already found). The backlight is certainly not on GPIO though.

I am thinking that too -- could be a keyscan col/row setup similar to what's been found on the clip/m200 models, we've just found the first column so far...

Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on February 07, 2009, 02:17:01 PM
I played around with the cabbiev2 theme settings on my e280v2 and found I could make the scrollwheel work if I change the background color to white and don't use the backdrop.  It worked one bit off of white(EFFFF...) but I haven't been able to test to failure so far.   I did set the top adjustment to the middle of the settings limits and scrolling failed though.  Would this point to an lcd driver issue?

EDIT:  For background colors scrolling only works for RGB: values FFXXXX F7XXXX EFXXXX and E7XXXX.  The green and blue values all work fine it's the red values that seem to be a problem.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on February 07, 2009, 02:18:27 PM
I played around with the cabbiev2 theme settings on my e280v2 and found I could make the scrollwheel work if I change the background color to white and don't use the backdrop.  It worked one bit off of white(EFFFF...) but I haven't been able to test to failure so far.   I did set the top adjustment to the middle of the settings limits and scrolling failed though.  Would this point to an lcd driver issue?
I would think so yes.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on February 11, 2009, 12:06:27 AM
Back on the e200v2 REC button, I'm trying to figure out if I'm chasing my tail here a bit.  I've got it seemingly working in the main rockbox app.  I say that because the backlight and buttonlight both come back on when I push the rec button just like any other button.  I also enabled recording in the config file and a long rec press takes me into the recording menu.  There do not seem to be any "phantom" rec presses in the main rockbox area aside from on bootup.  On bootup rockbox behaves as if the rec button is pushed, ie it clears all settings and a grey box appears saying settings cleared.  I have managed to bypass the rec button on startup to get into rockbox with a working rec button however.  Playing around with the plugins though has made me wonder what else may be going on.  BlackJack gets stuck in a button switch because it continuously pulls the BUTTON_REC  code off the button queue even though the rec button isn't being pressed.  There's also one of the higher bits set so it gets stuck.  Sudoku behaves properly when I press the rec button but there are phantom rec presses when I turn the scrollwheel.  Because of the startup issue I'm not sure if this is a rec button issue or a plugin issue.  Any thoughts?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: bertrik on February 11, 2009, 03:06:43 AM
Just letting you know, the ams sansas should now have working radio, except for the c200v2.

Most of them seem to use an si4702 FM chip which is supported by the si4700.c driver, the m200v4 uses a tea5767 FM chip supported by the tea5767.c driver. There is no radio yet for the c200v2 because we don't know yet how to talk to the FM chip.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on February 11, 2009, 10:44:05 PM
I believe the rec button and scrollwheel issues on the e200v2's are basically the same problem.  I changed the background color in blackjack to LCD_WHITE and the rec button gets read just fine.  This actually makes the bootup issue with the rec button also make sense.  The background color when rockbox boots up is black.  This is the timeframe I have been bypassing.  Once I make it into the menu's, I've set the background color to white and rec and scrollwheel work fine.  I'm thinking that for some reason any background color that doesn't have it's red component maxed out is altering DBOP 15 and 14, and maybe also 13 but I can't tell yet.  Does this bolster the LCD driver as the culprit?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on February 12, 2009, 04:25:11 AM
Does this bolster the LCD driver as the culprit?
Possibly. If the Fuze uses the same code, without problems, it really seems to be some lcd driver issue.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: bertrik on February 14, 2009, 04:13:15 PM
I enabled battery charging on the sansa clip today. The ams sansas use the same charge controller as the v1 sansas, so it wasn't actually that hard to add it. I didn't enable charging for other ams sansas yet, because each player probably needs its own settings (max. charge current and voltage), but it should be relatively easy to add once we have sufficient information.

What is needed for other ams sansa targets is the following:
* max charge current, this can be determined by measuring the current through the USB cable while it is charging in the OF (and the battery is still less than half full).
* max charge voltage, this can be determined by looking at the battery voltage in the battery debug menu, just after the OF has fully charged the battery.
* battery capacity, this can probably be determined by looking at the battery itself (there's probably already pictures of it in the wiki), from sandisk specifications or from the battery manufacturer.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on February 14, 2009, 09:20:09 PM
e280v2  Read off of battery label

P/N: 54-57-00046
3.7V
750mAh
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on February 14, 2009, 10:06:56 PM
e280v2  Read off of battery label

P/N: 54-57-00046
3.7V
750mAh

Thats the same battery as used in the V1.

Quote
I didn't enable charging for other ams sansas yet, because each player probably needs its own settings (max. charge current and voltage), but it should be relatively easy to add once we have sufficient information.

The fuze uses another ATL battery, but the exact model appears to be custom.  All ATL batteries are 0.5C recommended for charging, but I'm not sure what the capacity is.  Based on volume, its about 600mAh, so maybe 150 mA would be safe until we find out the exact capacity.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: bertrik on February 15, 2009, 07:58:55 AM
I updated the SansaCharging page on the wiki with a table that summarises the battery properties / charge settings of the various sansa targets. Please update this as you find out new information.

I forgot one other thing: the battery voltage can be read back through several ADC channels, but some are more useful than others, for example on the c200 the true battery voltage cannot be read back at all (way too high), same problem on e200 but we can read the RTCSUP ADC channel there. So please experiment a bit with this too to find the most representative ADC channel for the battery voltage.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on February 15, 2009, 08:58:48 PM
Some news on the Fuze's Home button (very related to the recent e200v2 button findings).

The Home button is detectable on DBOP_DIN bit 15, but only if the higher bits in DBOP_DOUT are set.

This means, if the background color/backdrop needs to have at least 128/16 bits (RGB888/RGB565) red color values.
The other thing: GPIOB depends on the background color too.

Setting DBOP_DOUT before reading messes up the display, so this is not an option. We have to find a away to set the bits in DBOP_DOUT without affecting the display. We should also investigate how GPIOB is involved (IIUC it shares wires with DBOP).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on February 16, 2009, 04:27:40 PM
Buttons & scrollwheel working great on e200v2 svn now.  Thank you Domonoky!!

ogg playback works fine as long as I leave the wps screen.  If I just stay at wps the music stops after 2-10 secs.  it will restart if I press the play button twice and then stop again unless I leave wps.  MP3 still reboots.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on February 16, 2009, 08:33:10 PM
Buttons & scrollwheel working great on e200v2 svn now.  Thank you Domonoky!!
This wasn't possible without your findings about the background color. Thanks a lot for that! It'll also enable the Home button on the Fuze.

May I ask a question? Is the wheel jumpy or unreliable? I've noticed that no post to the button queue is skipped. That causes problems on my Fuze (jumpy wheel, randomly changes direction, wrapping lists (or rather not wrapping if wheel is turned more quickly) not working at all).

edit: Just saw the "if (++wheel_click_count < 2)" line, that seems to be the skipping I talked about. I guess it's fine then.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Chesteta on February 16, 2009, 10:26:24 PM
On my e200v2 the wheel seems to move very smoothly; it does seem a bit slow; (like i'd like it to accelerate faster if i spin it fast instead of going what seems to be about a constant speed) but that probably can be changed in rockbox settings...

EDIT: also i should note, mp3's play back from the microsd chip (8gb) does work, if you touch the wheel or buttons things stop after ~10 sec.; when first playing an mp3 off the microsd chip, when the back light fades out, the audio does stutter a bit too.  I also noticed that the wheel light seems to 'chirp' on and off as the microsd chip is accessed (I set it to be off by default).  I can try to be more descriptive about the wheel light stuttering if anyone feels it could help :)

EDIT2: the hold button does not work; it can be on hold and the player will still turn on even...
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sko on February 17, 2009, 02:39:25 AM
Buttons working fine on my e200v2 now, but I can confirm I can turn the player on even if the HOLD-switch is set to hold.
Mp3-playback isn´t working at all, rockbox just freezes (my mp3 files have at least 192 kBits).
Ogg works with 128 kBits with staying in the wps and with 160 kBits if I leave the wps, with 256 kBits playback stops after 3 or 4 seconds.
But IIRC & IIUC this depends on the mmu (I read something about in the IRC-Log here (http://www.rockbox.org/irc/log-20090118)). May I ask if there are any news about the mmu?

EDIT: forgot to write: wheel is working fine!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on February 18, 2009, 12:00:59 PM
Can some e200 guy try this patch? http://pastie.org/392981

It takes a few parts from the Fuze LCD driver, to unify them a bit. Should not change behavior, but make the code more readable.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sko on February 18, 2009, 12:15:18 PM
I'm compiling right now, but I can say that r20040 is not working, the bootloader is loading the firmware but it's hanging before the mainmenu appears.

EDIT: Same with your patch, no mainmenu.

EDIT2: r20042 is good, buttons and wheel are working again.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on February 19, 2009, 12:01:21 AM
debug-as3525.c line 37    #if defined(SANSA_FUZE) && defined(SANSA_E200V2)

supposed to be || ?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Hillshum on February 19, 2009, 10:18:52 AM
I have no clue. But IRC might be the better place to ask...
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sko on February 19, 2009, 12:41:32 PM
I think "||" is right too, because with it the DBOP-value is shown in the view IO ports menu (see svn log for r20042). With "&&" it isn't visible there (can't be, imho two targets can't be defined).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: notlistening on February 19, 2009, 08:54:14 PM
Hi,

Not sure how many hardware secrets still exist with the e200 but i have a busted e280v2 that needs a new screen. I am registered blind and have no chance of being able to feel my way to replacing a new LCD. any takers? I am happy to post the unit.

Currently the player turns on to give a nice white background on the screen with a big black smash mark the blue lights of the scroll wheel for about 10-15 secs then dies. I am from England but am happy to post most places.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on February 19, 2009, 10:14:30 PM
Seems that I broke the e200v2's LCD driver. Can someone please test, if http://pastie.org/394710 makes it work again?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on February 19, 2009, 11:37:55 PM
Kugel, sorry to run off on you in the middle of that but sometimes 6th grade math just can't wait :o !  I tried 394710 and got basically the same results.  Let me try to describe them here.

When I turn the player on it boots up with the cabbie backdrop visible but no menus.  Scrollwheel, |<<, >>|, and menu(bottom) button give no response.  >|| (play) button however will take me right into the wps screen and music starts playing.  Scrollwheel now works along with |<< & >>| but the menu button does not.

EDIT: http://pastie.org/394841

In lcd_update_rect if I move the lcd_write_cmd(R_WRITE_DATA_2_GRAM); after the lcd_window calls I get a menu on bootup but it is skewed diagonally.   In lcd_update I also changed the 2nd lcd_window_x to lcd_window_y.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on February 20, 2009, 08:28:18 AM
Ok, can someone try this then? http://pastie.org/395034
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Hillshum on February 20, 2009, 08:35:53 AM
I'm not in a position to compile right now, but on a different matter, how do I go about determining the data needed to enable charging in the e200?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on February 20, 2009, 09:50:39 AM
The battery and charger on the V2 are the same as the V1.  I don't think we need to determine anything else.  The old settings should be fine.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sko on February 20, 2009, 10:11:23 AM
Ok, can someone try this then? http://pastie.org/395034
I tried it... see the attachment for the result, it seems that every pixel-row is shifted left by one pixel, but it is fine if messages are displayed (e. g. the message "screendump enabled" if I enable it). Sorry for the bad picture, screendump bitmaps are useless because they look fine.

EDIT: bootscreen looks also fine.

EDIT2: with r20064 it's fine again, no shifted pixel.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Hillshum on February 20, 2009, 10:21:36 AM
The battery and charger on the V2 are the same as the V1.  I don't think we need to determine anything else.  The old settings should be fine.

So should I post a patch with it enabled or will someone who knows more than me simply commit it? If the former where should I look in the source tree?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sko on February 20, 2009, 11:42:49 AM
Uhm... it seems that sound playback is not working at all on e200v2 on r20064. Even ogg-files. Can somebody confirm this?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on February 20, 2009, 11:43:55 AM
Uhm... it seems that sound playback is not working at all on e200v2 on r20064. Even ogg-files. Can somebody confirm this?
FlynDice just told me that it's working even better than before my lcd work.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sko on February 20, 2009, 11:48:55 AM
Ok, I'll format my player and put a clean new rb-build on it and try it again.

EDIT: you're right, it works, sorry :) and FlynDice is right, it's working better now! No more stutters if I navigate through menus while listen to music, good work!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on February 20, 2009, 01:16:32 PM
Can people please look at http://www.rockbox.org/tracker/task/9933 ? Thanks
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sko on February 20, 2009, 01:52:11 PM
Can people please look at http://www.rockbox.org/tracker/task/9933 ? Thanks
Sorry, but the patch is not working:
Code: [Select]
patching file firmware/SOURCES
patching file firmware/target/arm/as3525/sansa-e200v2/lcd-e200v2.c
Hunk #3 FAILED at 125.
Hunk #4 FAILED at 184.
Hunk #5 FAILED at 283.
3 out of 5 hunks FAILED -- saving rejects to file firmware/target/arm/as3525/sansa-e200v2/lcd-e200v2.c.rej
patching file firmware/target/arm/as3525/sansa-e200v2/button-target.h
patching file firmware/target/arm/as3525/sansa-e200v2/button-e200v2.c
Reversed (or previously applied) patch detected!  Assume -R? [n]
My working copy is at r20060 as yours.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on February 20, 2009, 02:11:12 PM
Meh, I didn't think you'd really look at the revision of the patch :/

My tree was at r20060, but contains the e200v2 lcd fixes, so it was actually at r20063.
Anyway, I uploaded a proper diff against r20067.

Please comment on the scrollwheel. I changed how it's read to be like the fuze.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sko on February 20, 2009, 02:34:56 PM
Well, display works, but the scrollwheel scrolls in the wrong direction some time, but just two or three items, then it scrolls in the right direction again.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on February 20, 2009, 03:15:41 PM
Now I'm a little less clueless...    (I think this is the datasheet....)

http://www.austriamicrosystems.com/eng/content/view/full/14666
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sko on February 20, 2009, 03:30:49 PM
Now I'm a little less clueless...    (I think this is the datasheet....)

http://www.austriamicrosystems.com/eng/content/view/full/14666
Me too... the datasheet wasn't available public until now iirc

btw: have you testet kugels patch? You can ignore the fails of the patch for button_e200v2.c and button_fuze.c because iiuc these files are not needed with this patch. I testet it, it compiles and works... nearly (see my last message).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: orsonj on February 23, 2009, 04:21:51 PM
I just got a c240 v2. It doesn't look like it has been tested much according to the wiki. (there are a lot of posts in this thread, haven't read much here) I'm not a coder, but would be willing to test out firmware builds and provide feedback. I might be able to build from source if someone pointed me in the right direction, but I'm not sure how well I'd be able to pull that off.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Hillshum on February 23, 2009, 05:40:30 PM
Someone want to change the thread title to say m200v4?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: jhMikeS on February 23, 2009, 05:42:10 PM
Quite nice of them to now make it available and even a newer one than we had (1v1). Kudos to AMS for their good sense.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on February 25, 2009, 10:45:37 PM
Has anyone had any luck playing mp3 off the microsd card?  I thought there was a report of that last week.  Could someone try on the fuze or  e200 and let us know the results?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Chesteta on February 26, 2009, 12:19:17 AM
mp3 off microsd causes a crash for me... ogg off microsd works... but it pauses like 12 sec in if you touch anything after hitting play and gets messed up easily
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sko on February 26, 2009, 03:07:31 AM
mp3 off microsd causes a crash for me... ogg off microsd works... but it pauses like 12 sec in if you touch anything after hitting play and gets messed up easily
Ogg from internal memory works fine on my e250v2 if i leave the wps after hitting play (for files up to 160 kBit/s, 256 kBit/s causes freeze after a few seconds).

EDIT: mp3 causes freeze from internal memory and reboot from microsd.

EDIT2: I tested ogg from microsd now, same behavior as from internal memory.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on February 26, 2009, 08:27:59 PM
I just put up a patch on flyspray that removes the dpop read delay and sigificantly shrinks the gpio delay for the e200v2 button driver.  It's been working fine for several days now.  I took out the gpio delay and the buttons stopped working so a delay is definitely needed.  A delay of 1 worked ok so I doubled it to 2 to be conservative.... ;)  http://www.rockbox.org/tracker/task/9959  ymmv
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on February 26, 2009, 09:22:38 PM
I added another patch at http://www.rockbox.org/tracker/task/9933 which goes another approach.

Please test and comment (on the tracker).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on February 27, 2009, 03:51:32 PM
Seems that r20124 broke all playback on my e280v2 including flac and ogg.  r20123 works fine.

Edit: changes:

/apps/plugin.h:
line 808 & 815:    __attribute__ ((section (".data")))       changed  to    DATA_ATTR 

/apps/codecs/codec_crt0.c:
line 25:                 __attribute__ ((section (".data")))       changed  to    DATA_ATTR 

/firmware/export/config.h.
line 627 added:        #define DATA_ATTR       __attribute__ ((section(".data"))) 
line 645 added         #define DATA_ATTR

Maybe a clue here for why mp3 didn't work before?   Codecs in (or out of) iram?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sko on February 27, 2009, 04:15:24 PM
I have r20127 on my e250v2 and I can confirm that all playback is not working.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: midgey on February 28, 2009, 03:43:55 AM
Please try a build r20135 or newer. I've committed a fix to my changes from the other day and codecs are working on the Gigabeat once again. See the IRC log if you want to understand why the change broke things.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Hillshum on February 28, 2009, 09:22:09 AM
I uploaded a patch to http://www.rockbox.org/tracker/task/9968 to enable charging on the e200. You folks that know a little more than me, please comment on it.
Title: v1 Fuze vs. v2 Fuze
Post by: epithetless on March 01, 2009, 11:41:23 AM
Out of rabid curiosity: Does the progress that's been made so far with the Fuze also apply to the newer v2 Fuzes, or just the original (now v1) Fuzes? In my searching across these forums, I haven't been able to determine whether anyone's tested on the v2 Fuze hardware yet (or even owns a v2 Fuze to test on). I suppose it'd be helpful to know the same about the v2 Clips as well...
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sko on March 01, 2009, 03:00:01 PM
If I connect my e250v2 to the computer the clock is set to Sep 23 2017 00:00 after disconnecting. If I set the right date/time it is correct until I connect it to the computer again. Is this the normal behavior until now?
Title: Re: v1 Fuze vs. v2 Fuze
Post by: saratoga on March 01, 2009, 03:18:06 PM
Does the progress that's been made so far with the Fuze also apply to the newer v2 Fuzes, or just the original (now v1) Fuzes?

Not much is known about the V2 hardware.  If its based on the AS353X, then some of the V1 hardware is probably present, and also the mkamsboot code will likely work.  However, until someone starts working on a port, I don't think we'll know for sure.
Title: Re: v1 Fuze vs. v2 Fuze
Post by: epithetless on March 01, 2009, 03:22:27 PM
Not much is known about the V2 hardware.  If its based on the AS353X, then some of the V1 hardware is probably present, and also the mkamsboot code will likely work.  However, until someone starts working on a port, I don't think we'll know for sure.

Thanks, saratoga. I suspected as much, but it's good to get confirmation on that front.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Hillshum on March 01, 2009, 11:29:06 PM
If I connect my e250v2 to the computer the clock is set to Sep 23 2017 00:00 after disconnecting. If I set the right date/time it is correct until I connect it to the computer again. Is this the normal behavior until now?
The OF and Rockbox fight for control of the RTC. The OF's "default" time is Sep 23....
I've been getting that too.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: bertrik on March 04, 2009, 08:38:17 AM
The RTC in the sansas is basically just a second counter. Earlier sansas keep the time in seconds since January 1st, 1980.

My theory is as follows:
in the e200v2 series the OF keeps the time in seconds since January 1st, 1970 (unix time) and has a check for invalid second values. One such check could be that the time is not before the build date of the firmware itself, which could be September 23rd, 2007. If the RTC is set to a date in 2009 in rockbox (using 1980 as second 0), the OF will interpret this as a date 10 years earlier, in 1999 (using 1970 as second 0). The OF concludes this is an invalid date because it is before the OF build date and sets the RTC to the OF build date, which is September 23, 2007. Back in Rockbox, this value of the RTC counter is interpreted as 10 years later which is 23 September 2017.

To test this theory, we should find out if the build date of the firmware is indeed around sept 23, 2007. It would be nice to know if earlier original firmwares reset the date to a different (earlier) date. Also try to find out if dates after sept 23, 2017 are not reset back to sept 23, 2017.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sko on March 04, 2009, 08:47:44 AM
My theory is as follows:
in the e200v2 series the OF keeps the time in seconds since January 1st, 1970 (unix time) and has a check for invalid second values. One such check could be that the time is not before the build date of the firmware itself, which could be September 23rd, 2007. If the RTC is set to a date in 2009 in rockbox (using 1980 as second 0), the OF will interpret this as a date 10 years earlier, in 1999 (using 1970 as second 0). The OF concludes this is an invalid date because it is before the OF build date and sets the RTC to the OF build date, which is September 23, 2007. Back in Rockbox, this value of the RTC counter is interpreted as 10 years later which is 23 September 2017.
Hmm... would it be possible that rockbox does an similar check?

Also try to find out if dates after sept 23, 2017 are not reset back to sept 23, 2017.
I'll check this when I'm back at home (forgot my player -.-).

EDIT: I checked it: I've set date and time correct in RB and connected it to the PC. After disconnecting the OF showed Sep 24 2007 and RB showed Sep 23 2017. Then I set Sep 24 2017 in RB and OF showed Sep 25 2007, I tried one minute too (OF doesn't show seconds, but one second would also be enough I think), same result: no reset. So dates after Sep 23 2017 are not reset back.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: bertrik on March 05, 2009, 04:25:42 AM
sko, thanks for confirming.
I hope to have a patch (to rtc-as3514.c) by tonight to test/fix this problem. I'm curious to which sansas this issue applies (maybe all AMS sansas?).
The only AMS player I have is a Clip and this one doesn't show date/time in the OF, but early in the Clip port I did notice some time resetting behaviour too.

I created a patch that should fix this problem, I can't test it myself though (I don't have a player with this particular problem): http://www.rockbox.org/tracker/task/9985
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sko on March 06, 2009, 01:01:01 AM
It works, now RB and OF are showing the same date/time (I set it in RB), good work bertrik!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on March 06, 2009, 10:19:19 AM
Hello pals!

I started (well, continued) researching about how to access the data on the internal storage past 1GB (on 4GB and more models).

Hopefully I should get a device one of these days, and then I'll be able to experiment some code.

Here are the findings so far:

According to daniel, data reading fails at the (rockbox) sector 0x1dae0 ; which is in fact the hardware sector 0x1e9e00 (0x1dae0 + 61440).

Now just for fun, let's multiply this number by 4:
0x1e9e00 * 4 = 0x787a00 , which is the number of blocks per bank in the e200v1/c200v1 driver... Funny no ? ;)

I found evidence that the OF issues a CMD6 to the storage, which is the command to enable bank switching, so we can't deny that Sansa AMS use bank switching in a similar way than Sansa v1!



Now we need to find how to actually switch banks.
The c200v1/e200v1 driver uses a proprietary command (35) and then writes the bank number into the FIFO buffer.

If the same method is used in Sansa AMS, we need to find the specific command, nothing arised from reverse engineering yet, but it's a tedious task and light might appear any time.


I grepped the OF (various models and versions) for 0x1e9e00 and got no result, but I see 3 occurences of 0x787a00 in 3 different functions.

Note that there is NO occurence in Clipv2 firmware (where storage might be implemented differently) and in m200v2 firmware (where capacity might not exceed 2GB?).


Unfortunately the use of this number 0x787a00 in the 3 functions doesn't tell me anything meaningful ..

Keep on rocking !
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sko on March 06, 2009, 11:48:22 AM
I enabled battery charging on the sansa clip today. The ams sansas use the same charge controller as the v1 sansas, so it wasn't actually that hard to add it. I didn't enable charging for other ams sansas yet, because each player probably needs its own settings (max. charge current and voltage), but it should be relatively easy to add once we have sufficient information.

What is needed for other ams sansa targets is the following:
* max charge current, this can be determined by measuring the current through the USB cable while it is charging in the OF (and the battery is still less than half full).
* max charge voltage, this can be determined by looking at the battery voltage in the battery debug menu, just after the OF has fully charged the battery.
* battery capacity, this can probably be determined by looking at the battery itself (there's probably already pictures of it in the wiki), from sandisk specifications or from the battery manufacturer.


I looked at my e250v2:
1. varying, I had values between 350 and 400 mAh, OF showed nearly empty (red battery icon)
2. 4.149 V
3. 3.7 V, 730 mAh (see picture)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Hillshum on March 06, 2009, 02:14:18 PM
One other thing on the >2gb storage, I have been rolling with the wheel light off quite a bit lately on my e260v2. But It often flashes on once for a sec. When copying files it flickers the whole time. It seems to be tied to reading the NAND or the uSD.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: gabe565 on March 06, 2009, 06:26:06 PM
My 8gb Fuze does the same thing. When the wheel light is on, I'm fine, but once I turn it off, it'll flash on file access.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on March 06, 2009, 08:21:45 PM
I experience it too...sometimes, the other sometimes it works. I haven't worked out a reliable solution yet (and I do think we have worse problems).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: gabe565 on March 06, 2009, 10:06:45 PM
Yeah not being able to read past the first gigabyte needs to be figured out first
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on March 07, 2009, 12:31:49 AM
Do we even have nand on the ams sansa's?  I know there is a nand interface on the chip but it seems sandisk opted to go with an embedded sd card instead(they are sandisks after all...).  My point to that is though that the sd interface uses gpio-d and the button light seems to be turned on with gpio-d[7].  Yes I know the diagram in the datasheet does not show an actual assignment for pin 7 but it would seem that anecdotal evidence suggests that the sd interface is using it for something.  Am I misunderstanding something?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on March 07, 2009, 07:24:04 AM
Do we even have nand on the ams sansa's?  I know there is a nand interface on the chip but it seems sandisk opted to go with an embedded sd card instead(they are sandisks after all...).  My point to that is though that the sd interface uses gpio-d and the button light seems to be turned on with gpio-d[7].  Yes I know the diagram in the datasheet does not show an actual assignment for pin 7 but it would seem that anecdotal evidence suggests that the sd interface is using it for something.  Am I misunderstanding something?

You're right. It's all SD. The datasheet has information about the AS3525 SD interface.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: gerstavros on March 08, 2009, 10:31:43 AM
Hi! After some months i entered the site again and saw at the homepage that on Sandisk, instead of writing (not the v2 models), it writes (not the AMS models). What is that? http://www.rockbox.org/twiki/bin/view/Main/SansaE200v2writes that v2 aren't supported. Can somebody explain what is the AMS and if rockbox works on v2 or not?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on March 08, 2009, 11:02:55 AM
AMS = v2

We chose to use the term AMS which represent the hardware used in these models, as opposed to 'v2' which is confusing.

See that there exists 4 versions of m200 and 2 versions of Clip & Fuze, so "AMS" refers to:

m200v4
c200v2
e200v2
Fuze
Fuzev2
Clip
Clipv2
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: jomegatau on March 08, 2009, 11:14:10 PM
Has anyone had any luck playing mp3 off the microsd card?  I thought there was a report of that last week.  Could someone try on the fuze or  e200 and let us know the results?

Hi FlynDice:   
I have had no luck playing mp3's from either the internal flash or the microsd card.  The mp3 application exits immediately after starting.   All of these mp3's play fine using the OF.   I did try playing an unencoded  wav file and it worked from the internal flash or the microsd so I do not think it is a file system issue!   The files were encoded using lame on a openSuse 11.1 system.   I have a 8gb HC sandisk microsd card installed in the sansa.  My  sansa is a e260v2 running the March 1 svn sources version r20148M-090301.    I am interested if anyone else has this problem too!     

jwt
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on March 09, 2009, 12:28:47 PM
As far as I know mp3 does not work still.  I thought I had read a post that said someone had mp3 playing from the microsd and there would be a clue to investigate there but that proved to be unfounded.  I didn't have a microsd to test myself then....
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: TopQuark on March 11, 2009, 07:41:04 PM
AMS = v2

We chose to use the term AMS which represent the hardware used in these models, as opposed to 'v2' which is confusing.

I thought the v1 also uses AMS hardware just that it is the older version.  No?

Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on March 11, 2009, 07:58:32 PM
AMS = v2

We chose to use the term AMS which represent the hardware used in these models, as opposed to 'v2' which is confusing.

I thought the v1 also uses AMS hardware just that it is the older version.  No?



They use an AMS DAC, but a PP CPU.  The AMS CPU used in the V2 is actually the first AMS CPU model.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: pbxy on March 12, 2009, 02:54:31 PM
Hi,

as a Sansa Clip v2 (8 GB) owner, I want to adapt amsinfo.c to the modified firmware format of the ClipV2's.
I'm using firmware version 02.01.32 (http://daniel.haxx.se/sansa/v2/clip/clip02.01.32.zip).

Funman already mentioned the slight changes (http://forums.rockbox.org/index.php?topic=14064.msg136212#msg136212) compared to the ClipV1 firmware file. So I shifted the offsets of all header values after FirmwareHeaderIndex by 4 bytes and I noticed the SVN version of amsinfo.c treats "ModelId" as a 32 bit value, but in the wiki it says 8 bit (http://www.rockbox.org/twiki/bin/view/Main/SansaAMSFirmware#Blocks_Description).
The shown ModelId, when treated as 32 bit value, is shown as 0x2724 while the values of the other devices listed in the wiki are all 1 byte long.
I guess this is an error in amsinfo. When corrected the ClipV2 ModelId shows as 0x27.

Output is now as follows:
% ./amsinfo clip02.01.32/m30pa.bin
0x00000000:
  HEADER: 0x00000000
    FirmwareHeaderIndex:     0x00000000
    CLIPv2 firmware format
    FirmwareChecksum:        0x9b2d5536
    CodeBlockSizeMultiplier: 0x000002fe (* 0x200 = 0x0005fc00 <-- main firmware block size)
    FirmwareSize:            0x0005fa7c (diff. to calculated firmware block size: 0x0184)
    Unknown1:                0x00000003
    Unknown2:                0x24
    ModelID:                 0x27
    Zero:                    0x0000
    FortyHex:                0x00000040
    One:                     0x00000001
    FiveThousandHex:         0xffffffff
    HeaderChecksum:          0x9b3469a2
Calculated header checksum: 0x9b3469a2 MATCH
[...]
Calculated firmware checksum: 0x9b2d5536 MATCH
Calculated file checksum: 0xf2b58380 MATCH

Reset Vectors:
    Address 0x0400: e59ff058
    Address 0x0404: e59ff058
    Address 0x0408: e59ff1fc
    Address 0x040c: e59ff058
    Address 0x0410: e59ff058
    Address 0x0414: e1a00000
    Address 0x0418: e59ff054
    Address 0x041c: e59ff054

firmware_size(0x0005fc00) => start(0x00060000)
LIBRARY BLOCKS:
Offset      Name           BaseAddr    EndAddr     BlockSize   Unknown1    EntryCount
0x00060000: "drmndt_pers"  0x30064cc4  0x30076e4c  0x00012188  0x0000ad48  0x00000001
0x00072204: "rubbish"  0x18be6784  0x4ae13d6c  0x2cd672ae  0x69525f90  0x16496df1
[1]    10194 segmentation fault  ./amsinfo clip02.01.32/m30pa.bin


Obviously there are some differences between the library blocks of clipv1 and clipv2. I think something like that was mentioned earlier in this thread.
Does it have something to do with the 0xDEADBEEF, which is used differently?

Another thing: I tried to enter one of the "special modes" mentioned earlier by turning the device off and then pressing and holding the buttons <<, >> and power. The described screen with "Erase Firmware? Press center button to confirm." came up. But three times or so it started up and showed the menu where you can select the region. This was similar to the menu you also see after a settings reset. But in this one you could select "Diagnosis" which I did. Before this my firmware version was the normal "P", after it's "T" - the test mode in which you can select "Diagnosis" in the Settings menu. Currently I cannot reproduce this, but this doesn't seem interesting anyway.

I also tried to enter the described e200(?) special mode where you have to put the device off, activate the "hold" button, press << and plug the USB cable in. As expected, nothing special happend. The device just boots up into USB MSC mode and my computer detects a 8 GB device.

Can anyone describe how to open the enclosure of the clipv2? I'd like to use the JTAG port in case I brick something while experimenting with getting a bootloader to work. Would recovery be possible using this method?

EDIT:
I made some screenshots:
http://img3.imagebanana.com/view/udimwsqq/sdram.jpg diagnosis mode reporting 8 MB SDRAM
http://img3.imagebanana.com/view/k8iq1ngt/erase.jpg erase firmware?
http://img3.imagebanana.com/view/g7bcmgid/regiondiagnosis.jpg "Diagnosis" in region list

pbxy
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Hillshum on March 14, 2009, 09:30:16 PM
I get the same scrollwheel issues (reverse direction etc) on my e200v2 in the OF as well as rockbox
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on March 14, 2009, 09:57:58 PM
I get the same scrollwheel issues (reverse direction etc) on my e200v2 in the OF as well as rockbox

In the OF too? That's pretty interesting. It basically proves that the OF doesn't do better than we do. and we're doing pretty bad, compared to the e200v1.

And if the OF can't do better in this area, there's probably no better way.

edit: fix stupid typo.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Hillshum on March 14, 2009, 10:12:10 PM
Could this be an issue with the RB bootloader? I never noticed it till a few days ago? If I could get my sansa to behave right now I'd try a clean firmware.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on March 14, 2009, 11:53:29 PM
I've been investigating the mmu for a few days along with the instruction & data caches and bus modes.  Right now we are running with the mmu disabled and the instruction and data caches enabled, even though the Arm TRM says you shouldn't do that with the data cache.  I'm basing my assertions on the values read from the control register used to enable/disable these features.  The caches are enabled in the bootloader along with asynchronous bus mode and that carries through to the main rockbox.  The strange thing is that if I enable the mmu it slows down rockbox which is quite opposite of what I would expect.  Disabling the Dcache (since the mmu is not enabled) seems to have no effect good or bad that I can see yet(but maybe I don't know what I'm looking for...).  I looked through the disassembly of the OF(e200v2) and found the mmu and cache functions along with functions to set the 3  bus modes.  They all look similar to what we've got in mmu-arm.S.  We can enable the mmu quite easily but there must be something that doesn't want to "play nicely" with our little friend here.  Any chance our good old 1GB sd problem is related?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on March 14, 2009, 11:57:40 PM
I've been investigating the mmu for a few days along with the instruction & data caches and bus modes.  Right now we are running with the mmu disabled and the instruction and data caches enabled, even though the Arm TRM says you shouldn't do that.  I'm basing my assertions on the values read from the control register used to enable/disable these features.  The caches are enabled in the bootloader along with asynchronous bus mode and that carries through to the main rockbox.  The strange thing is that if I enable the mmu it slows down rockbox which is quite opposite of what I would expect.  Disabling the Dcache (since the mmu is not enabled) seems to have no effect good or bad that I can see yet(but maybe I don't know what I'm looking for...).  I looked through the disassembly of the OF(e200v2) and found the mmu and cache functions along with functions to set the 3  bus modes.  They all look similar to what we've got in mmu-arm.S.  We can enable the mmu quite easily but there must be something that doesn't want to "play nicely" with our little friend here.  Any chance our good old 1GB sd problem is related?

The datasheet doesn't only tell the "one shouldn't do that", but also that the dcache *cannot* be active without mmu somewhere.

I'm fairly sure the slowdown you're noticing is due to disabling the ICache too (because this matches my experiences), but feel free to prove the opposite with patches. I haven't managed to turn the mmu on yet.

Oh, and yes, the control register shows "true" for dcache, but I *really would not* rely on this register for reading the dcache status without mmu.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on March 15, 2009, 12:37:00 AM
Yes I guess I'm getting caught in the enabled vs functioning trap.  When I disable the Icache it behaves identically to what happens when I enable the mmu. 

I'll start looking at the "Program level 1 and level 2 page tables as required" middle step and see what I can see...

Do you have a suggestion for determining if whether or not the mmu and Dcache are actually working besides a noticeable speed difference?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: pbxy on March 15, 2009, 12:50:18 AM
Hi again,

I patched mkamsboot and I can now run custom code on my Clip v2. :)
Luckily the dualboot.S code detects if USB is plugged in and switches to OF because GPIO mapping seems completely different from v1.
I tested most of GPIOA and B with C6 as output, but no button presses were detected. I tested using the "delay method".

Well, the rockbox bootloader for Clip v1 doesn't run either. At least there's nothing on the display.

My modifications to mkamsboot.c are attached. I also added header checksums check, a missing int cast and fixed a double free exception.
I'm currently using the "clip" rockbox bootloader target until there's something more appropriate available.

% ./mkamsboot ~/x/clip02.01.32/m30pa.bin ~/x/rockbox/bootloader-clip.sansa m30pa.bin
mkamsboot v0.1 - (C) Dave Chapman and Rafaël Carré 2008
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[INFO] MD5 sum - 0ad3723e52022509089d938d0fbbf8c5
[INFO] Original firmware MD5 checksum match - Clip V2 2.01.32
[INFO] Patching Clip V2 firmware
[INFO] Original firmware size:   391804 bytes
[INFO] Packed OF size:           90807 bytes
[INFO] Bootloader size:          45068 bytes
[INFO] Packed bootloader size:   22732 bytes
[INFO] Dual-boot function size:  264 bytes
[INFO] UCL unpack function size: 168 bytes
[INFO] Total size of new image:  113971 bytes
 *****************************************************************************
 *** THIS CODE IS UNTESTED - DO NOT USE IF YOU CAN NOT RECOVER YOUR DEVICE ***
 *****************************************************************************


pbxy
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on March 15, 2009, 01:07:52 AM
Do you have a suggestion for determining if whether or not the mmu and Dcache are actually working besides a noticeable speed difference?

Can the MMU mirror memory?  You could setup a duplicate copy of the main memory at some other address and then see if it exists.  If not, you could try remapping memory, but that could cause its own set of crashes.

Quote from: pbxy
I tested most of GPIOA and B with C6 as output, but no button presses were detected. I tested using the "delay method".

The ClipV2 is believed to use a different CPU then the V1, so the GPIO addresses may not even be at the same addresses in memory.  You should ask Bagder to request a copy of the AS3536 datasheet.  Otherwise, you'll have to dig through the retail firmware looking for GPIO registers.

Edit:

I looked at the V2 clip firmware, and its got the string "AS3525_2_0 " just like the V1.  funman said he saw ARMv5 ops in the firmware file, so I checked, and there are v5 ops.  That would imply that its not a 3525 (ARMv4), but i see a few in the ClipV1 firmware too (things like "stc2   7, cr15, [ip, #888]"). 

Is it possible theres dead code in there meant for different AMS chips, and that we're actually still dealing with an AS3525 on the V2?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on March 15, 2009, 07:36:22 AM
Yes I guess I'm getting caught in the enabled vs functioning trap.  When I disable the Icache it behaves identically to what happens when I enable the mmu. 

I'll start looking at the "Program level 1 and level 2 page tables as required" middle step and see what I can see...

Do you have a suggestion for determining if whether or not the mmu and Dcache are actually working besides a noticeable speed difference?

Is this still with bertriks patch? Because I didn't manage to enable the MMU.

Quote from: pbxy
Hi again,

I patched mkamsboot and I can now run custom code on my Clip v2. Smiley

Great success, good job! Is there a recovery method on the v2 clip, or did you just hope to not brick your clip entirely? I'll have a look at your patch.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: pbxy on March 15, 2009, 08:44:26 AM
Is there a recovery method on the v2 clip, or did you just hope to not brick your clip entirely? I'll have a look at your patch.

I have not discovered any recovery method yet, I just tried to make sure the OF is still able to boot when the button checks fail.
So I was hoping the hardware would be similar enough to the v1 to run the code and unpack the OF.
Apart from that I think it was important to raise the DRAM_SIZE value from 0x50000 to 0x200000, because the unpacked OF is bigger (0x5fa7c).

The ClipV2 is believed to use a different CPU then the V1, so the GPIO addresses may not even be at the same addresses in memory.

The USB "button press" on A6 gets detected if USB is plugged in, so at least the GPIO address/pin combination for this is equivalent to the v1.
After the USB check code I tried several Cx-output/Bx-input combinations for the following button check.

EDIT (2009-03-16, 01:32): I found the power button on A7 like in the clip v1, and I'm using it now to boot the OF (my current mkamsboot/dualboot is attached).

Now I'm trying to get the display in the rockbox bootloader to work. In the OF (still v02.01.32) there's the display initialization function beginning at address 0x73E0 (counted without fw file header).
It uses almost exactly the same order of commands (0xd5, 0x10, 0xdb, 0x34, ...) as the clip v1 display driver in rockbox (lcd_init_device() in firmware/target/arm/as3525/sansa-clip/lcd-ssd1303.c).
Only the lcd_write_command(LCD_SET_COM_OUTPUT_SCAN_DIRECTION_INV); (command 0xC8)  is made 4 times instead of 1 in the OF.

The GPIO pins used in the OF also differ from v1. In the display initialization there are GPIOB{1,2,3,5,7} and GPIOA5 set as outputs and set to different values.
In the function which seems to write the display commands (beginning at address 0x7238) there are also different values for DBOP_CTRL (0x51004), DBOP_TIMPOL_01 (0x36A12F) and DBOP_TIMPOL_23 (0xE0370036).
Additionally at the end of this function, DBOP_CTRL is again set to 0x51004 and DBOP_TIMPOL_23 is set to 0xE037E037.

I currently don't fully understand the OF's code, but I tried to adapt the differences in the rockbox clipv1 display driver. It's currently not working (nothing's shown on the display), but I'll attach it, too.

EDIT (2009-03-18, 01:41): Yay, visual feedback! Button light is on GPIOA_PIN(5).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on March 15, 2009, 01:39:30 PM
Is this still with bertriks patch? Because I didn't manage to enable the MMU.

Ah see you got caught in the same semantics trap that I did.  I have enabled the mmu but I do not have a functioning mmu.  I have been playing around with the cache flag parameters handed to the map_section function from mmu-arm.S.  I believe these are the cache flags from page 4-11,12 in the TRM.  If I "enable" the mmu and use CACHE_NONE(0x0) for map_section I believe I get no mmu and no cache.  However if I use 0xc(for cached writeback mode) I get a white lcd screen..  but very very quickly as if perhaps the mmu were working but theres a memory mapping problem(which is beyond my skills at this point...)  Then again I could just be hoping.

EDIT:  The more I read about setting up the translation tables and mapping the more I think that is our problem here.  Its as if we have a light switch and we've tossed some wire between the switch and a lightbulb and have been expecting the light to turn on just because we turned the switch on.  I think if we set up the mapping correctly we get the mmu to operate.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Hillshum on March 16, 2009, 11:18:55 AM
The ClipV2 is believed to use a different CPU then the V1, so the GPIO addresses may not even be at the same addresses in memory.  You should ask Bagder to request a copy of the AS3536 datasheet.  Otherwise, you'll have to dig through the retail firmware looking for GPIO registers.


Didn't AMS make the datasheet public? There's a link in this thread somewhere...
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on March 16, 2009, 11:22:46 AM
Re-read please. He was talking about the AS3536 datasheet. AMS published the AS3525 one.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on March 18, 2009, 08:08:13 AM
It uses almost exactly the same order of commands (0xd5, 0x10, 0xdb, 0x34, ...) as the clip v1 display driver in rockbox (lcd_init_device() in firmware/target/arm/as3525/sansa-clip/lcd-ssd1303.c).
Only the lcd_write_command(LCD_SET_COM_OUTPUT_SCAN_DIRECTION_INV); (command 0xC8)  is made 4 times instead of 1 in the OF.

I think Clipv1 OF also used 4 times this command, but we reduced it to one.

When you have some functional code, you can try remove some bits one by one to exclude useless ones.

Good luck for LCD !

--
Some news about SD:

I received a Fuzev1 from saratoga and a USB cable from gevaerts, but sadly I broke the USB connection the first day by using a custom USB charger !
Luckily I can still charge the battery over USB (only the data connection is broken) and update the code via a microSD card.

The bank switching code is located in the "sd_reload__" module, and is very similar to the code for e200v1/c200v1 :
- send command 6 (switch)
- send command 35 (proprietary command)
- send the bank number on the SD controller FIFO (1 byte set to the bank number, followed by 511 '\0'

Something is still missing because I get DATA TIMEOUT from the SD controller when trying to read from the 2nd bank.

After that we will still have to find how to calculate the total capacity (and number of banks) : maybe by trying switching banks one by one until we can't?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: calv on March 19, 2009, 05:36:35 AM
When you have some functional code, you can try remove some bits one by one to exclude useless ones.

[...]

Something is still missing because I get DATA TIMEOUT from the SD controller when trying to read from the 2nd bank.

I don't mean to be sarcastic or rude, but couldn't this be because of the previously mentioned technique to remove I/O that you believe is useless? I mean if some I/O is repeated then its mostly for timing reasons. This means it could work in some situtations without repetitions, but sometimes it won't. Just a thought, though...
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on March 19, 2009, 08:45:44 AM
This is why I always test code removal bit per bit ^^

I have made significant progress now:

I can read my watermark past the 0x1E9E00th sector.

I needed some initialisation, which enables the access to 0x1E9E00*4 (just like e200v1) sectors on the first bank.

I suppose bank switching works but I can't test rigorously since without USB access I can not modify/dump the whole disk structure of my Fuze. I even ignore if it's a 4 or 8GB.

The OF code seems to handle only 1 or 2 banks (4 or 8GB) : do you know if a 16GB model exists ?

Next step is to find the number of banks dynamically to know the exact size of each model, and also test if it needs bank switching or not (2GB and less models don't).

I attach my current patch, I'd appreciate if you can test it and play with it on e200/Fuze/Clip

--

pbxy : I have compared Clipv2 and Clipv1 OFs and have some results for you:

Keypad matrix scan is identical to Clipv1 except you have to write on GPIO D4 D5 D6 and read on D0 D1 D2
The FM chip I2C uses B6 as SCL and B7 as SDA

I forgot to check the SDRAM setting before leaving for the internet access point but I believe it's 8MB like Fuze & e200v2.

If you need something else just ask !
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Hillshum on March 19, 2009, 09:42:24 AM

I received a Fuzev1 from saratoga and a USB cable from gevaerts, but sadly I broke the USB connection the first day by using a custom USB charger !
Luckily I can still charge the battery over USB (only the data connection is broken) and update the code via a microSD card.


is the cable fine?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: mc2739 on March 19, 2009, 08:52:39 PM
@funman

I have tested your bank switching patch on my e260v2.

I can now read sectors below 0x798800 (actually sector 0x7A7800 including the offset). Without the patch, I can only read sectors below 0x1DAE00 (actually sector 0x1E9E000 including the offset).

This appears to be the full capacity of the 4gb e260v2.

The test_disk plugin still fails the write & verify test with a compare error.

Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: michaelc5047 on March 19, 2009, 10:48:49 PM
There's been a bit of talk on the Sansa forums about a pitch issue on the Clip v2 and the Fuze v2, where playback of files with a sampling rate of 44.1KHz is 2% slower than it should be due to a clock problem. I personally have an 8GB Clip and a 4GB Clip (of the v1 variety) and have compared playback between the two, and noticed that the 8GB does play slightly more slowly. A couple of the threads are here (indicating that fixes are in the work in upcoming firmware upgrades, but at the expense of power consumption): http://forums.sandisk.com/sansa/board/message?board.id=sansafuse&thread.id=11835 and http://forums.sandisk.com/sansa/board/message?board.id=clip&message.id=16478#M16478.

Would the clock issue be a problem, power consumption-wise, for eventual Rockbox builds on these units? Or is it completely too early to tell and/or hypothetical at this point?

Thanks.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: yelped on March 19, 2009, 10:59:33 PM
Hypothetical at this point. ;)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on March 20, 2009, 06:28:58 AM
This is why I always test code removal bit per bit ^^

I have made significant progress now:

I can read my watermark past the 0x1E9E00th sector.

I needed some initialisation, which enables the access to 0x1E9E00*4 (just like e200v1) sectors on the first bank.

I suppose bank switching works but I can't test rigorously since without USB access I can not modify/dump the whole disk structure of my Fuze. I even ignore if it's a 4 or 8GB.

The OF code seems to handle only 1 or 2 banks (4 or 8GB) : do you know if a 16GB model exists ?

Next step is to find the number of banks dynamically to know the exact size of each model, and also test if it needs bank switching or not (2GB and less models don't).

I attach my current patch, I'd appreciate if you can test it and play with it on e200/Fuze/Clip

The patch seems to work fine, I didn't test deeply (most of my music is mp3, which crashes anyway), but under the assumption, that MediaMonkey sync's alphabetically, it seems I can access albums near to A as well as those near to Z, which indicates successful access over the bank borders.
The capacity is reported correctly too.

Given that the capacity is reported correct, bank switching could be enabled upon checking the capacity, right? If >= 4GB, then enable banks.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on March 20, 2009, 11:18:03 AM
@Hillshum

I don't know how to verify if the cable is fine, but that could very well be the case.. I'll ask my friends to see if I can find a Sansa + a cable to see which one of the cable or the Fuze is damaged.
For now, I continue working with the microSD ;)

@mc2739

Did the test fail before using this patch ?

@kugel

How come the capacity is reported fine ?
The CSD reports 0x1E9E00 sectors on my Fuze and I remember that it was identical bit per bit for all e200 and Fuzes (even with different capacities).
Are you reading it from debugging > disk info ?

I'm still looking at how to find the number of banks (4GB or 8GB), and if they are needed or not.

If you can give me different CSDs with their model & capacity I could compare them with the one I have (I was reading the function which parses the CSD and I noticed some 'out of spec' fields!!)


By the way I tried to enable the MMU and noticed some problems:
 - if I enable caching & buffering (flag 0xC) on IRAM I see crashes quickly after boot
 - if I enable it on SDRAM I can not boot : the 1st sector (partition table) is incorrectly read

Flyndice: I looked (quickly, because I don't know anything about this stuff..) at the MMU code in the OF of Clip and Fuze and I see a strange thing:
 - Clip OF enable caching only for the 1st MB of SDRAM (out of 2)
 - Fuze OF enable caching onyl for the first 5 MBs of SDRAM (out of 8)

weird.. !
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on March 20, 2009, 11:27:52 AM
@Hillshum

I don't know how to verify if the cable is fine, but that could very well be the case.. I'll ask my friends to see if I can find a Sansa + a cable to see which one of the cable or the Fuze is damaged.
For now, I continue working with the microSD ;)

@mc2739

Did the test fail before using this patch ?

@kugel

How come the capacity is reported fine ?
The CSD reports 0x1E9E00 sectors on my Fuze and I remember that it was identical bit per bit for all e200 and Fuzes (even with different capacities).
Are you reading it from debugging > disk info ?
No, disk info still shows 0x1E900. I was looking under System->Rockbox info. It shows (apparently correctly) how much disk spaces is left and the total disk space (currently I have "141MB/3.79GB").
Quote
I'm still looking at how to find the number of banks (4GB or 8GB), and if they are needed or not.
I'm assuming it's 1 bank for each 2GB (2GB is the maximum you can get with non-HC), although it would seem weird why the problems already start at 1GB. Maybe it's 1bank per 1GB, but then it would be weird why 2GB models don't have a bank.

BTW, I haven't exactly looked at your code. But it just works, what's the exact problem with the number of banks or do you have it hard-coded for 4GB?.
Quote
If you can give me different CSDs with their model & capacity I could compare them with the one I have (I was reading the function which parses the CSD and I noticed some 'out of spec' fields!!)
Well, IIRC the v1 sansas don't have a CSD lookup table, if you mean that.

Quote
By the way I tried to enable the MMU and noticed some problems:
 - if I enable caching & buffering (flag 0xC) on IRAM I see crashes quickly after boot
 - if I enable it on SDRAM I can not boot : the 1st sector (partition table) is incorrectly read

Flyndice: I looked (quickly, because I don't know anything about this stuff..) at the MMU code in the OF of Clip and Fuze and I see a strange thing:
 - Clip OF enable caching only for the 1st MB of SDRAM (out of 2)
 - Fuze OF enable caching onyl for the first 5 MBs of SDRAM (out of 8)

weird.. !
Interesting. Can I see the code? I haven't been able to boot at all (no apparent crash or partition error), just freeze when I tried.

Weird that it doesn't cache the whole ram. Maybe it doesn't cache its plugin memory (if they have one) or something. I'm unsure if we gotta do it in the same way.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on March 20, 2009, 11:38:21 AM
I'm assuming it's 1 bank for each 2GB (2GB is the maximum you can get with non-HC), although it would seem weird why the problems already start at 1GB. Maybe it's 1bank per 1GB, but then it would be weird why 2GB models don't have a bank.
Currently it's ~4GB per bank (just like e200v1) so 2GB or less models don't need switching

BTW, I haven't exactly looked at your code. But it just works, what's the exact problem with the number of banks or do you have it hard-coded for 4GB?.
I have not hardcoded it, nor put any limit, so I thought testing would require formatting the storage with > 1GB partition and see if the FAT driver can access all the data.
Perhaps the reported size you see comes from the FAT32 header, I'll check that.
Right now we still need to find the 'disk' capacity.

Well, IIRC the v1 sansas don't have a CSD lookup table, if you mean that.
I mean I need a CSD for various Sansa AMS (e200, Fuze, Clip, ..) with 1 or 2GB, 4GB and 8GB to see the differences.

Interesting. Can I see the code? I haven't been able to boot at all (no apparent crash or partition error), just freeze when I tried.

Weird that it doesn't cache the whole ram. Maybe it doesn't cache its plugin memory (if they have one) or something. I'm unsure if we gotta do it in the same way.

Sorry I don't have it with me, I'll take the patch next time!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on March 20, 2009, 11:40:17 AM
Currently it's ~4GB per bank (just like e200v1) so 2GB or less models don't need switching
Then my fuze would only have 1 bank, and we wouldn't need switch. I don't quite understand.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on March 20, 2009, 11:58:55 AM
We need to determine at runtime if the Sansa uses banks of 0x7A7800 sectors (~4GB) because 2GB and less models don't.

Then if it's 4GB or more we need to use a special command to enable access to the whole capacity of the bank.
If it's 8GB or more we need to determine the number of banks in this model (reading the OF it seemed only 1 or 2 banks was possible, this is why I was saying 4GB OR 8GB, and not 16GB; but this assumption might be wrong for newer models like Clipv2 or Fuzev2)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: pbxy on March 20, 2009, 12:29:40 PM
If you need something else just ask !

Thanks for the button pins. All button except for left, select and right get detected now.
From button_init_device():

    GPIOD_DIR &= ~((1<<2) | (1<<1) | (1<<0));
...
    GPIOD_DIR |= ((1<<6) | (1<<5) | (1<<4));


I have a bigger problem with DBOP or the display controller. I can't spot any write to the GPIOx_AFSEL registers in the v2's OF.
In the v1 OF it is clearly visible before and after some writes into DBOP_TIMPOL_{01,23} and DBOP_CTRL.
In the v2 OF there's a silimar section writing into these registers (at 0x71d0), but there are no writes into *_AFSEL anywhere (except for one GPIOD_AFSEL = 0 somewhere else).

On the other hand it is clear DBOP is used, because the command write routine (0x7238) writes into DBOP_DOUT the same way the v1 OF does.
If the bits in the AFSEL registers are not set high, this would mean no GPIO pins are configured to be controlled by DBOP, right?
So the display controller had to be connected to the dedicated DBOP pins existing on the AS3525? I'm not sure about this,
because then I think the display commands should arrive without any further initialization.

I also noticed that the "fifo queue empty" bit in DBOP_STAT, which is looked at in lcd_write_command(), doesn't get set after writing a byte,
when the following commands are not executed in the initialization:

    CGU_PERI |= 0x10000;
    CCU_IO |= 1<<3;
    CGU_DBOP |= 0x18;


Not all of them are necessarily relevant, but I didn't test it. At least, the fifo status bit gets cleared. Or may this be a bad sign?

I also guess that GPIOB_PIN(2) is the D/C# pin. "0xfb" is written to it in the write command function in the OF and "4" in
another one which may be the write data function. But there are also the pins B1, 3, 5 and 7 in the initialization:

    GPIOB_PIN(1) = 0xFD;
    GPIOB_PIN(2) = 1<<3;
    GPIOB_PIN(5) = 0xDF;
    GPIOB_PIN(7) = 0;


EDIT: added (dirty) lcd-ssd1303.c patch.

EDIT2: I cleaned the messy patch up and added the OF offsets where the different instructions were made, here it is.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: mc2739 on March 20, 2009, 12:34:03 PM
@mc2739

Did the test fail before using this patch ?

Yes, it did fail before the patch was applied.

No, disk info still shows 0x1E900. I was looking under System->Rockbox info. It shows (apparently correctly) how much disk spaces is left and the total disk space (currently I have "141MB/3.79GB").

My e260v2 acts the same. Under System->Rockbox info it shows the correct size (3.79GB), but under System->Debug->View disk info it shows Blocks: 0x0011E9E00. There is also some other info on the View disk info screen that looks wrong.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sko on March 20, 2009, 02:12:18 PM
No, disk info still shows 0x1E900. I was looking under System->Rockbox info. It shows (apparently correctly) how much disk spaces is left and the total disk space (currently I have "141MB/3.79GB").
Same on my e250v2: System->Rockbox info shows 1.88GB (correct), System->Debug->View disk info shows Blocks: 0x001E9E00.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on March 20, 2009, 10:09:39 PM
e280v2: : System->Rockbox info shows INT: 7.18GB/7.62GB, MSD: 3.50GB/7.45GB.  System->Debug->View disk info shows Blocks: 0x001E9E00 for internal and 0x00eef000 for msd card.

As far as mmu goes here's some commented disassembly(e200), see what you can make of it...

http://pastie.org/422828
EDIT: whoops 0x300<<2 = 0xc00 not 0x30000....

EDIT: Well that makes more sense now.  Looks like the OF makes the 1MB sections at 0x00000000 and 0x30000000 writeback cacheable and the rest non cacheable. The other difference I noticed are the access pemissions in the tags.  The OF uses a c value(11 permission bits) and the other rockbox arm mmu routines seem to use a 4 (01  supervisor r/w, user r only).  Would someone who actually knows what they're doing take a look and comment...   ;)


EDIT:  I cloned a bit of kugel's debug code to work on the mmu.  here's a diff to make the mmu info come up under debug View HW info


EDIT:I've put the TTB_BASE at 0x307fc000 to mimic the of and actually read the values in the table to see if they were set up right.  They appear to be fine.  I found I can enable write-back cache on the 1 MB sector at 0x00000000 with no ill effects but if I try to enable writeback  on the 1MB section at 0x30000000 I get a mirror image display.  Rockbox appears to be operating as the lcd screen dims and comes back with wheel/button input.  After the second time it dims the lcd comes back with non mirrored message :

No partition
found.
Insert USB cable
and fix it.

which seems to be from main.c where it can't mount any disks.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on March 23, 2009, 09:38:22 AM
Hello,

I investigated the "disk" problem on my Fuze, and I think it is more a memory problem rather than SD problem.

I launched the md5sum plugin on the whole disk, and absolutely all sums were right (even for the bitmaps which are wrongly displayed)

I bought a Sansa Clip to see if I could see any differences between the 2 models, but it turned out to be a Clipv2 !

Note that it's a 1GB model in the new packaging, which makes wrong the assumption that v2 models are only 4GB or 8GB.

I started working on the Clipv2 then : see the patch on FS#10047 (http://www.rockbox.org/tracker/task/10047) (mkamsboot+bootloader)

pbxy : I looked at the LCD code and the LCD commands themselves are 100% identical to the Clipv1. I found the same differences than you:

I downloaded your patch and I'll read it at home.

I remember the Clipv1 needs a GPIO pin to be set to work at all (probably the pin powering the screen) and this pin wasn't set in the LCD code, but in hardware initialisation routines.

I looked at these routines to find something similar but I was afraid ..
The Clipv2 uses I2C on something else than the AS3514 : with I2C_TESTOUT2 (0xC8070058) & I2C_TESTIN registers:

It seems that this i2c communication is used on registers not present in AS3514 (0x12, 0x17 which is USB_UTIL in as3514, 0x18 to 0x1f but not 0x1d)

Perhaps on these registers is a LCD_enable bit.

Else the Clipv2 OF looks like it uses an extended AS3525 : it's an armv5t since the BLX instruction is used, and use some registers undocumented in AS3525 pdf (like 0xC6070000 marked as "reserved"; or too big offsets like [something_BASE,#0x40] where registers stop at #0x30)

Perhaps finding which SoC it uses and if the i2c registers are documented would help activating the LCD (and next steps).

See you
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on March 23, 2009, 01:20:49 PM
I think I've got the mmu working but it makes the main program choke while trying to mount disks.  I put a patch on flyspray so hack away.

http://www.rockbox.org/tracker/task/10048
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Mikerman on March 23, 2009, 09:17:43 PM
If further Clips are needed for testing:

Refurb 2gb Clips are at $29.99 (+s/h), at Compusa.com.  Shipping ran $7 for me when I checked it out.  The site says it ships internationally, but extra fees apply.

http://www.compusa.com/applications/searchtools/item-Details.asp?EdpNo=4472464&sku=S153-7036%20RB
 
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Bagder on March 24, 2009, 05:50:43 AM
i am new to this and tried to build and install bootloader and rockbox from source (with one warning: Your cross-compiler arm-elf-gcc 4.1.1 is not of the recommended version 4.0.3!) 

As things in this early port work are a bit shaky already without you experimenting with alternative compiler versions, I would strongly advise you to use the version rockboxdev.sh builds for you!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: rrwood on March 24, 2009, 12:48:46 PM
I'd like to get started doing some dev work to help with the port to the new Sansa models.  Any suggestions on getting started?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on March 24, 2009, 12:50:18 PM
I'd like to get started doing some dev work to help with the port to the new Sansa models.  Any suggestions on getting started?

Pick up something that isnt' working (MMU, disk, etc), read through whats already been done, and start experimenting.

Edit:  Maybe not disk since it looks like funman has been busy:

FS#10053 - Sansa AMS >2GB support

Could always ask in IRC if you need more ideas.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on March 24, 2009, 12:54:36 PM
Hello

I opened FS1#10053 (http://www.rockbox.org/tracker/task/10053) for storage (>2GB), please test and comment on the task.

I also have some infos on Clipv2:
The VIC controller is not a pl190 : it uses the register [base + 0x300] which is not documented in pl190 doc.

I could succesfully use blx (armv5t) and strd (armv5e) instructions, but not ssat (armv6) so the CPU is armv5E/T

The registers at 0xC6070000 are used for storage (SD card, like in Clipv1)
0xC6070028 = argument and 0xC607002C = command , perhaps it will help finding which AMS SoC is used.

If the website mentioned by Mikerman ships in France for not too much, I would surely have use of one of these Clips.

See you
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: mcuelenaere on March 24, 2009, 05:30:42 PM
...

I could succesfully use blx (armv5t) and strd (armv5e) instructions, but not ssat (armv6) so the CPU is armv5E/T

...
I'm not sure if you already know, but you can identify an ARM cpu by reading out cp15 register 0 (see this (http://infocenter.arm.com/help/topic/com.arm.doc.dai0099c/DAI0099C_core_type_rev_id.pdf) for more info).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on March 24, 2009, 07:28:53 PM
I attached a diff to this post that displays the contents of the p15 registers in the HW debug page.

http://forums.rockbox.org/index.php?topic=14064.msg147056#msg147056


Edit: But now that I think about that you have no lcd to read....
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on March 25, 2009, 05:50:49 AM
I can "display" numbers by flashing the button led (2 blinks = bit 1, 1 blink = bit 0)

Thanks mcuelenaere, I will use this method

Other news: the i2c register 0x20 (AS3514_SYSTEM) reads "revision 4" and I can shutdown the Clip by clearing the bit 0

FlynDice : about the MMU I have some remarks:

pbxy :
I try to use OF "hijacking" to find the required LCD bits:
When I got it working, I hope to use printf() (since the LCD initialization has already been done) and then remove function calls one by one to see which are mandatory.
Keep updated!

EDIT:
The Clipv2 CPU is a ARM926EJ-S (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0198e/index.html) (Java able!) so it suggests a AS3530 AS3531 or AS3536 SoC like we thought. I'll request the datasheets from AMS and hope that they answer!
Here is the cp15 id register value: 0x41069265

EDIT2:

I think it would be a AS3531 since AS3530 & AS3536 are advertised as "audio/video" able, but we can't know until we get the datasheet for them.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on March 25, 2009, 06:28:40 PM
FlynDice : about the MMU I have some remarks:
  • The real size is 0x1000 (16kb aligned)
  • You should use (RAM_ORIG + MEM*0x100000 - TTB_SIZE) for the position
  • You should update plugin.lds app.lds & boot.lds to remove TTB_SIZE from the RAM size

Ok, thanks,  real life is getting in the way a bit here but I'll try to spend some time on this later tonight.  Do you have any insight on the problems this causes while trying to mount disks in main.c init()? (by coincidence that was the same spot that was failing on your first sd-banks patch)  Domonoky mentioned there could be a conflict with dma and cacheable memory.


EDIT:  Let me preface this by saying I'm learning all this on the fly so to speak, so feel free to correct my ignorance without bruising any ego.

The TTB_SIZE of 0xfff I used was simply the figure the OF uses in it's scheme to write 0x1000 tags into the table. But I'm having trouble wrapping my head around it's actual size.  I was thinking the size was 0x4000.  It seems the OF uses a 0x4000 value as it places the table at 0x307fc000 and the gigabeats use this 0x4000 value also.  But I could certainly be convinced otherwise...

Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on March 26, 2009, 08:17:05 AM
Myself i'm still learning and I think you know more than me on the MMU subject ;)

The documents specify the size should be a multiple of 0x4000 (16kb) and the position aligned on 16kb.

The OF loop use <= 0xfff to loop over the 0x4000 bytes (0x1000 words : you'll surely notice a lsls r0, r0, #2 to shift between word position & byte position)

--

Good news : I have now access to the LCD on Clipv2 (I updated the ticket with a new patch, pay attention to _backlight_on() which holds the required i2c  registers modifications).

pbxy I hope it will help you to find the last buttons.

I had to skip system_init() to have display at all.

Now on the similarities & differences with Clipv1/AS3525:


--
EDIT:

I forgot to mention that I think the memory problems could be related to clock frequencies.
For example the external memory clock (extmem_clk) must not be higher than 90MHz, and the peripheral clock (pclk) not higher than 65MHz.
But pclk = extmem_clk OR extmem_clk/2
So we can have at maximum:
extmem_clk = 90MHz & pclk = 45MHz OR
extmem_clk = 65MHz & pclk = 65MHz.

I'm still not sure of which settings the OF use exactly ..
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: pbxy on March 26, 2009, 12:26:22 PM
Good news : I have now access to the LCD on Clipv2 (I updated the ticket with a new patch, pay attention to _backlight_on() which holds the required i2c  registers modifications).

Great work! :)
(Rockbox logo on clipv2. (http://img3.imagebanana.com/img/v79esumt/clipv2oled.jpg))

pbxy I hope it will help you to find the last buttons.

It did! Used as keypad inputs are D0:2 as you said, outputs are D3:5.
Compared to the v1, column switching works the other way around: All 3 output pins are high except the one for the wanted column.
An input pins reads 0 when the corresponding button is pressed.

I needed to add a few nops after switching a column to get reliable results from button_read_device().
Without the delay, eg. VOL_UP and DOWN were reported when just DOWN was pressed.

With the attached button-clip.c every button except for HOLD gets detected.
I printed out all GPIO pin states on the display but nothing changes when hold is pressed.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: j8048188 on March 26, 2009, 01:04:00 PM

  • SD code is different, and pl18? documentation on ARM.com has vanished?

Was it on the website before? If so, where did you go to get it?
I may be able to find a cache of the page.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: mc2739 on March 26, 2009, 10:00:17 PM
For any tester with an e200v2, I have opened FS#10043 (http://www.rockbox.org/tracker/task/10043) for updates to the lcd driver.

These updates enable inverse video, upside down mode, and lcd standby. Also, some unneeded GPIO setting code was removed.

Please post any comments or results on the Flyspray task.

Thanks
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on March 27, 2009, 10:35:22 AM
With the attached button-clip.c every button except for HOLD gets detected.
I printed out all GPIO pin states on the display but nothing changes when hold is pressed.

Isn't hold on A3 like on Clipv1 ? I'll have to test, but I remember seeing it on A3 in the OF.

saratoga:
Are you sure your armv5 instruction isn't data or 2 thumb instructions ?
You should check register c0 of cp15 to be sure of the CPU used.

By the way I should get a Clipv1 within a few days (sent today).

And also: AMS answered (in french!) and sent me a NDA before sending me the AS3536 datasheet.
Now I just wait their answer about AS3530 & AS3531, because AS3530 & AS3536 have built in hardware H264 decoders (expensive, especially for the patents licences); this is why I think the Clipv2 is AS3531 based, but having all the documents couldn't harm in determining the exact SoC used.

j8048188:
I still have the document, but I was hoping to see if the SD registers matched with a newer PrimeCell controller : it seems ARM doesn't build new SD controllers.

By the way : here are some SD registers I found:
0xC6070000 = sd registers base
    + 0x00 = power?
    + 0x28 = argument
    + 0x2c = cmd
    + 0x30 = resp0
    + 0x34 = resp1
    + 0x38 = resp2
    + 0x3C = resp3
    + 0x40 = status (irq status?)
    + 0x44 = clear (irq clear?)
    + 0x100 = fifo

command register bits:
bits 5:0 = command
bit 6    = response
bit 7    = long response
bit 31   = command enable/command active ?

I had a look at Linux (2.6.28) source but couldn't find any controller matching those.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on March 28, 2009, 07:46:23 AM
With the attached button-clip.c every button except for HOLD gets detected.
I printed out all GPIO pin states on the display but nothing changes when hold is pressed.

Isn't hold on A3 like on Clipv1 ? I'll have to test, but I remember seeing it on A3 in the OF.

You have to set A7 direction out, set pin A7, wait a little bit (I used for(i=0;i<50;i++) asm volatile("nop"); ) , read A3; unset pin A7 and set the direction to input to read power button.

Now the buttons are complete!

I tried quickly to access the SD, I could send some commands but with some trouble:

So I think I'll just wait the documents from AMS.. it should save much pain
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on March 30, 2009, 11:43:15 PM
I believe I've gotten rockbox to boot with the mmu functioning on my e280v2 but have no test to actually prove it.  I updated the mmu patch at http://www.rockbox.org/tracker/task/10048 and kugel did a little housekeeping for me(thanks).  I tracked the problem down to a conflict between cached memory and dma transfers.  Then I looked at the gigabeat fx and saw they were doing a range invalidate on the dcache there so I tried it and lo and behold it works, well sort of.  Playback is broken for me but the ui runs very snappily.  I think there's still a lot of fixing here but I think this points in the right direction.  Someone who understand things better than I do should take a look and see what they think.  I have just made the 2 1MB sections at 0x00000000 and 0x30000000 writeback cacheable to mimic the OF.  Also the code is all available from mmu-arm.S.  I got it to work with those functions and added some bus control functions from the OF to that file.  Check it out and see what you think, I know kugel at least is not convinced it's actually working.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on March 31, 2009, 07:29:29 AM
Codecs are worse than before, from what I've noticed.

I think a good way to test the mmu would be to map the IRAM behind RAM, so 0x38000000 or so (edit *.lds accordingly), if that turns out working, then it must be running.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on March 31, 2009, 09:50:09 PM
I'm already in so far over my head my ears are starting to hurt but here goes nuthin...

  Where's the 8 MB of ram documented if anywhere?   Was that just figured out along the way somewhere?  I see the 320 K TRAM I'm assuming is IRAM and the ROM for the bootloader.  I know from looking at the code that the 8 MB(or 2MB I guess for lowmem) of ram is there and its at 0x30000000.  And then we have the internal SD and the microsd.  Are the 2 sd cards accessed through the mpmc is that what's going on?  I've been scanning the memory map at the end of the datasheet trying to make all this fit together in my head before diving into the virtual address and physical address mapping party.  Do I have this all right so far.

 Please help correct my misconceptions before I waste a lot of time on this.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on April 01, 2009, 08:21:34 AM
The 8MB of RAM are "documented" in the OF SDRAM initialisation (setting of MPMC_DYNAMIC_CONFIG_0)

320kB TRAM is what we call IRAM, but not the bootloader ROM! The ROM is 128 kB at 0x80000000.

The 2 SD cards are accessed via the MMC/SD controller ARM PrimeCell PL180, nothing to do with MPMC !
PL180 controller for internal SD is at 0xC8000000
PL180 controller for SD Slot is at 0xC8020000

Hope that helps !
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on April 02, 2009, 03:59:18 PM
Very little progress. It builds and runs the bootloader, but most/some buttons and display don't work. Thus, the main build doesn't really work too.

If you intend to help development (e.g. by doing actual coding or original firmware disassemling, or donating a player), then we welcome you. But if you don't please do not ask for status in this thread.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on April 02, 2009, 07:21:37 PM
Funman:  Thanks for the caching article, sorry to drop & run on you like that but I had kids getting up and had to run off to fly across the country...

I don't know if I'm misunderstanding your comment on irc about looking in the OF for mrc/mcr whether you didn't find them or just what you found wasn't real interesting.  I found them in the e280 by _not_ forcing thumb in the objdump/disassembly.

The clipv2(the new one) had roughly the same mmu startup routines as the e200.     http://pastie.org/435466

Still researching dma and cache but nothing really new so far.

Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on April 03, 2009, 10:24:26 AM
No problem ^^

The mrc/mcr instructions are not interesting, there's nothing that we aren't doing already.
And indeed they are ARM instructions which don't exist in thumb mode.

I have played with your patch and updated FS#10048 (http://www.rockbox.org/tracker/task/10048), still no success with caching, but at least the MMU works fine!

I also opened FS#10092 (http://www.rockbox.org/tracker/task/10092) which cleans up a bit system_init() : it would be nice to test on e200v2 & m200v4 (domonoky?)

By the way, has progress on c200v2 stopped?

If someone is willing to write code and test it on target, I can help by disassembly for LCD & buttons.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sko on April 04, 2009, 11:47:38 AM
@funman:
I have tested your MMU patch (e250v2):

I  also tested your cleanup-patch and I couldn't find any problems, so I think it works.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on April 04, 2009, 03:52:21 PM
I"ve been looking at he gigabeat fx the past few days seeking clues and noticed that they don't seem to use the IRAM, at least not in the way that we use it for the as3525.  I thought the main difference between the 922 and 920 is the smaller I/Dcaches on the 922.  In their app.lds they have no IRAM and in boot.lds theyhave an IRAMSIZE of 4K  but it isn't used for anything it seems.  Do they use it differently? And if so is there a good reason?

Edit:Ach nevermind, been submerged in this a little too long and everything's starting to run together on me, I was thinking our IRAM was part of the 922 instead of part of the as3525....
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on April 04, 2009, 05:01:26 PM
  In their app.lds they have no IRAM and in boot.lds theyhave an IRAMSIZE of 4K  but it isn't used for anything it seems.  Do they use it differently? And if so is there a good reason?

The Gigabeat F doesn't use IRAM because theres so little of it.  4KB isn't enough for codecs (which are currently designed for at least 48KB).  We could use it for core stuff, but so far no obvious use for such a small amount has been found.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on April 07, 2009, 08:54:18 AM
sko: thanks, but can you please comment on the FlySpray tasks? It's easier to follow than a fast evolving forum thread ;)

I have experimented a bit to understand why the Sansa AMS crashes a lot and seem to suffer from memory corruption, so I'll try to resume again if someone can see some light:

Feel free to correct me, and to verify my experiments.

I don't know in which direction to look now :/
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: wpyh on April 07, 2009, 11:28:26 AM
funman: maybe you could create some kind of "memtest" program to see where the corruption happens. The location where the corruption happens should be constant, since I also see the background corruption problem on my 8GB Fuze at always the same coordinates.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: freqmod on April 07, 2009, 02:35:33 PM
I played a bit with the flash buffering patch FS #9332 and it seems to me that the last part of the buffer write is corrupted.

If i made the buffer smaller i got more, but shorter shuttering, when i made the buffer 4096 bytes it was nearly a constant 1/2 sec of playing, 1/2 sec of shuttering. That would support the ram timing theory, and that the problems are not based on the location in the memory.

btw. files with low bitrate (speex with ~15kbps) plays nearly perfectly, and i listened to an audiobook for 5 hours yesterday with only a bit skipping at the start, and without crashing. (when i did not fast forward, paused or anything like that).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: mc2739 on April 07, 2009, 09:37:51 PM
@funman

Here is an interesting observation for you.

The e200 screen is 176 wide and 220 tall compared to the Fuze which is 220 wide and 176 tall.

I reconfigured so that my e200 screen is rotated 90 degrees to match the Fuze and I get  the same screen corruption as seen on the Fuze.

I have not had any screen corruption in the standard configuration
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on April 08, 2009, 07:39:47 AM
@wpyh : I already tried some memset/memtest but didn't see any problem, even if I waited 1 minute before write & read.
I'll retry on the whole 8MB of SDRAM.

@freqmod : which player are you using ? I thought FS#9332 only brings improvement on players with 2MB of SDRAM (Clip/m200v4)

@mc2739 : thanks, at least the problem is consistent between e200v2 & Fuze!
I loaded a white bitmap as the backdrop on my Fuze but I don't remember seeing any non white pixel..

@kugel : do you have informations / tests on this backdrop corruption ?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Hillshum on April 08, 2009, 10:24:01 AM
@funman

Here is an interesting observation for you.

The e200 screen is 176 wide and 220 tall compared to the Fuze which is 220 wide and 176 tall.

I reconfigured so that my e200 screen is rotated 90 degrees to match the Fuze and I get  the same screen corruption as seen on the Fuze.

I have not had any screen corruption in the standard configuration

Could this mean if we wrote to the controller sideways on the Fuze it would work?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: wpyh on April 08, 2009, 12:53:56 PM
Well, if I replace the backdrop with some other bitmap measuring 220x176, the corruptions don't happen. Therefore the corruption is very data-specific.

Could the corruptions be some kind of side-effect from CPU calculations? Such as registers being mapped to RAM, and we use that part of RAM to decode the bitmap?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on April 08, 2009, 01:54:08 PM
Sounds like the buffer being used for the bitmap is being overwritten, either by a bad pointer or because we've double mapped a piece of memory.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: calv on April 09, 2009, 04:09:52 AM
Well this problem appears even without MMU enabled, so logical=hardware addresses. But on the hardware side the memory (and even I/O) could be mapped to multiple places and overlap in some places. Maybe we are using addresses, where memory and I/O overlap. It could even be, that we are using the correct I/O addresses, which are nonsense (hardware-wise): working because of hardware mapping, but at the same time overwriting RAM. The OF could even use the same addresses, but then mapped by the MMU to different hardware addresses, where RAM is not selected, and thus not overwritten.

Maybe finding out at what exact addresses in RAM the backdrop gets corrupted and comparing those addresses to our I/O addresses could bring some clue about this.

Only one of my usual wild guesses, though  ::)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on April 09, 2009, 05:08:49 AM
The backdrop is corrupted without memory mapping too (in fact, not only the backdrop, but every bmp above ~190px wideness). And we're using the correct RAM addresses.

The loading is problematic, because the issue was revealed by a commit which changed the bmp loader to load a whole pixel row at once, instead of only 8px of a row at a time.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: freqmod on April 09, 2009, 05:29:38 AM
@funman: I am using sansa clip v1. (which also has corruption in the file buffering)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on April 09, 2009, 08:49:25 AM
Hey pals!

I know it's not Christmas but I have some presents for you:
Take this ata transfers fix (http://www.rockbox.org/tracker/task/10113) and this stable mp3 decoding (http://www.rockbox.org/tracker/task/10114)

Now if you can make your sansa crash please tell me how :)

Next steps:
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: wpyh on April 09, 2009, 10:47:15 AM
@funman: Ogg (Vorbis) and MP3 playback works fine on my 8GB Fuze now. I think you should specify that one has to clean up the build directory before trying out your patch :p
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Hillshum on April 09, 2009, 11:09:08 AM
Isn't it good advice to do that anyway?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sko on April 09, 2009, 11:40:57 AM
Isn't it good advice to do that anyway?
I think so, too.

btw (not very important now I think):
After I noticed that mp3 is working really good with funmans patch, I tried to play a movie (elephantsdream-q6-224x128-354kbps.mpg (http://download.rockbox.org/mpeg/elephantsdream-q6-224x128-354kbps.mpg) from the MPEGPlugin wiki-page (http://www.rockbox.org/twiki/bin/view/Main/PluginMpegplayer#Sample_Videos)): sound is working, but no picture, thats much better than before: there were just reboots if I tried to play it.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: cyclon1978 on April 09, 2009, 12:29:26 PM
with both patches i have on e280v2 mp3 playback - great, ogg playback - great, video playback: sound without picture

Thanks!

Andreas
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: freqmod on April 09, 2009, 12:42:36 PM
@funman, well it does not crash, but my clipv1 stops playing when a track  if you shuffle a bit, and the let a track  play about a minutte after the lcd display has been turned of, then it displays (root), (root) and wont play anthing before playback is stopped (i.e. the square icon appears)  (when the disk alignment patch is applyed to rockbox SVN). This applies to mp3, but not to  speex (at least it takes much more time).

I did a full new full checkout from svn and made a new build directory to be shure it was no old remains from other patches.

edit: It does not seem like the oled/lcd has anything to do about it, it chashed when the lcd was active tool.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on April 09, 2009, 01:39:29 PM
funman:  I tested both patches and they work nicely.  I say commit as soon as possible.

Performance is still extremely poor for whatever reason.  MP3 takes ~ 145MHz.  I can shave 10MHz off that by putting everything in IRAM, but thats it.  Cache shouldn't hurt us all that badly when running out of IRAM, unless lack of the MMU imposes some other performance penalty (slowing down sequential IRAM access or similar).  Is it possible some driver is doing a lot of busy waiting?

Otherwise, the port seems quite functional. 
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on April 10, 2009, 12:49:33 PM
@freqmod : I'll try using my clip more to see if I can reproduce (the IRAM patch didn't apply to Clipv1 and m200v4 at all by the way)

@sko/cyclon1978 : on the Fuze you need this patch (http://www.rockbox.org/tracker/task/10118) for mpegplayer

@saratoga : I'll try to look in drivers if they do busy waiting and put some yield() here
Perhaps the slowness comes from the fact that we don't declare the SDRAM nor IRAM as cached (via the MMU) ?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: bertrik on April 10, 2009, 01:07:39 PM
IIRC from the discussions on IRC, a lot of ARM targets currently use long calls which makes the code slower and bigger. I think one of the most important things we could do with the MMU is to map memory regions such that they are close enough to each other to use short calls, thereby shrinking the code and speeding it up (slightly).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on April 10, 2009, 01:09:50 PM
IIRC from the discussions on IRC, a lot of ARM targets currently use long calls which makes the code slower and bigger. I think one of the most important things we could do with the MMU is to map memory regions such that they are close enough to each other to use short calls, thereby shrinking the code and speeding it up (slightly).

Yep, indeed. BTW: The long-call border is 64MB. I.e., if a foo() calls bar() and bar is more than 64MB away. then a long call must be used.

If we can put everything within 64, e.g. by mapping the iram just after the dram, we can get rid of long calls.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: helios on April 10, 2009, 04:04:12 PM
MPEG-3, Ogg Vorbis, and C64 SID files now work nicely with revision 20680 on Sansa e250v2! FLAC already worked with revision 20619 and version 3.2 of rockbox.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on April 11, 2009, 02:14:09 AM
I'm spinning my wheels working on the mmu but plugging away. I can tell you a whole bunch of things that don't work and not one that does.  I think the mmu is actually functioning as several people have reported success mapping memory regions to different locations.  Whenever I try to enable caching however I get a mirror image lcd screen.  I have tried all kinds of combinations of invalidate_cpucache, clean_dcache, clean_dcache_range etc. to no avail.

In my flailing away at the problem I did come up with several questions though:

Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sko on April 11, 2009, 03:19:47 AM
  • And , of course now that Funman has mp3 and ogg playing so nicely for me(thanks a ton by the way) how do I stay motivated  :P
Well, iiuc the performance would be much better with mmu, 145 MHz for playing mp3 is to much and decreases the runtime I think.

btw: what about FS#9985 (http://www.rockbox.org/tracker/task/9985) (rtc fix) I think it's working good, maybe commit it?

I would also like to say that the work you guys do is really great, many thanks! I hope I will understand it someday :)

EDIT: I made a patch to make menus wrap on e200v2, maybe someone may have a look at it: FS#10127 (http://www.rockbox.org/tracker/task/10127)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on April 12, 2009, 12:49:40 PM
I'm spinning my wheels working on the mmu but plugging away. I can tell you a whole bunch of things that don't work and not one that does.  I think the mmu is actually functioning as several people have reported success mapping memory regions to different locations.  Whenever I try to enable caching however I get a mirror image lcd screen.  I have tried all kinds of combinations of invalidate_cpucache, clean_dcache, clean_dcache_range etc. to no avail.

In my flailing away at the problem I did come up with several questions though:

  • It appears we have leftover room in iram, is there a reason not to use it for the stack?
  • Do we really need the mmu functioning in the bootloader?  It seems to me it overcomplicates things.
  • And , of course now that Funman has mp3 and ogg playing so nicely for me(thanks a ton by the way) how do I stay motivated  :P

Please keep up the good work! Have you found a combination which is not so utterly slow?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on April 14, 2009, 11:16:06 AM
It appears we have leftover room in iram, is there a reason not to use it for the stack?

Not really, but is it really helpful (how much speedup) ?

Do we really need the mmu functioning in the bootloader?  It seems to me it overcomplicates things.

Not at all! It's simpler to enable it in the rockbox.sansa loaded from disk

And , of course now that Funman has mp3 and ogg playing so nicely for me(thanks a ton by the way) how do I stay motivated  :P

Getting FS#10118 and looking for full speed video playback ;)


Some bad news: I broke my Fuze LCD while it was in my pocket (how breakable it is!) and when trying to exchange the LCD screen with the other Fuze I had, I unsoldered the LCD connector :/

saratoga's Fuze was hardware rev 1.2 and mine was 1.41, the 1.41 connector looks much more breakable...

Now I still have the rock solid Clip to develop, but had not much luck with MMU.

I'm looking at understanding the I2C registers to use interrupts and remove the busy loop in ascodec driver; and also to enable headphones detection.

Keep up rocking !
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on April 14, 2009, 03:33:23 PM

Not really, but is it really helpful (how much speedup) ?

Tests will show. Putting the lcd framebuffer didn't gave more than 7% (though the Fuze's LCD is utterly slow compared to other targets anway, caching needed? :)

Quote

Some bad news: I broke my Fuze LCD while it was in my pocket (how breakable it is!) and when trying to exchange the LCD screen with the other Fuze I had, I unsoldered the LCD connector :/

saratoga's Fuze was hardware rev 1.2 and mine was 1.41, the 1.41 connector looks much more breakable...

You're kidding, aren't you? Another two broken Fuze's within a few days? :(

I've had the 1.41 too. The LCD broke too, but the connector is pretty solid still.

Quote
Now I still have the rock solid Clip to develop, but had not much luck with MMU.
My clip isn't so rock solid :(

Quote
I'm looking at understanding the I2C registers to use interrupts and remove the busy loop in ascodec driver; and also to enable headphones detection.

Keep up rocking !

Do our Sansas have the capabilities for that? Do you have informations about this?

Keep rockbox too!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on April 16, 2009, 11:17:55 AM
No I'm not joking, I read that you broke your Fuze too :(

I gave up studying i2c registers, I think the benefit isn't very high (i2c busy loop delay could be mesured anyway).

About headphones detection I gave up as well since we can detect insertion but not removal it seems, and i2c interrupts are not needed for this. (You can enable the interrupt by IRQ_ENRD_* ascodec registers and check the status manually).

Just look for "headphone detec" in the AS3525 spec and "DET_ON" in as3514.h

@saratoga : except lcd & i2c I didn't see any busy loops without yield() in the middle, so I think the slowness is related to caching being disabled (mmu disabled).

Other stuff : today I looked again at the Clipv2 and now I pass the SD init procedure! Now I'm looking at which registers to modify to get a DMA transfer.

The code is still very hackish, I'm eagerly waiting for a AS3531 spec to see which SD controller is used.
I'll write again to the AMS people I contacted to see if they didn't forget me.


Oh and I noticed that the viewer plugin crashes a lot on my Clip, did someone notice that as well on Clip & other targets?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Mikerman on April 16, 2009, 11:50:18 AM
In case further Clips are needed for experimentation, etc.:  1gb refurb'ed Clips at $14.99 with free s/h, at Buy.com.

http://www.buy.com/prod/sandisk-sansa-clip-mp3-player-1gb-recertified/q/loc/111/210490112.html?adid=17654&dcaid=17654
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: arez1 on April 16, 2009, 03:50:33 PM
hi,
iam not quite sure what i need to report and whats not relevant but i will give it a try ;)

- Flashing Wheel : instead of turning of, the wheel starts flashing... you might reproduce it by setting your start screen to "last played" and turn your player of/on - then just wait a bit

- Data abort : at 3004FFF0 .. just happened once while i was playing a mp3, watching the playlist and going one step back ( <- )

running an e200 v2 - 8gb
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Hillshum on April 16, 2009, 04:16:10 PM

- Flashing Wheel : instead of turning of, the wheel starts flashing... you might reproduce it by setting your start screen to "last played" and turn your player of/on - then just wait a bit



If you pay attention, you'll notice it's flashing on disk access
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: arez1 on April 17, 2009, 02:48:04 AM
i used rockbox on my e200 v1 and it never flashed so i thought its kind of unwanted... imo its quite annoying so is this a wanted feature of rockbox or just something to make observations easier for development?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on April 17, 2009, 03:03:28 AM
i used rockbox on my e200 v1 and it never flashed so i thought its kind of unwanted... imo its quite annoying so is this a wanted feature of rockbox or just something to make observations easier for development?
No, it's not wanted. But it's not a big deal yet as there are bigger problems. If you can fix it, please do so and post the patch.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: cyclon1978 on April 17, 2009, 07:03:20 AM
hi, i have a question about the lcd driver.

i am trying to modify the code from funman's patch #10118 for the e200v2 and succeded viewing videos in good quality but... they are rendered from upper left corner and so they will not fit.

for e200 i need to rotate it 90 degrees and i tried that with R_ENTRY_MODE_VERT but i fear that dont work in the way i thought (i hoped it would reconfigure the display to interpret the lcd memory "rotated") maybe can someone explain if there is a way to do the rotate without recalculate the image?

i found some comments in mpegplayer about rotating images - should the image be rotated in lcd_blit_yuv or previously?

thanks,

andreas
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on April 17, 2009, 11:23:25 AM
The HORIZ/VERT mode changes the way pixels are stored: i.e from top to bottom or from left to right.

For video to work properly, you must also change the coordinates from where you start drawing.

The assembly helper called by lcd_blit_yuv() draws 2 "lines" at a time in this way:

Code: [Select]
===========> line 1 from left to right (on fuze)
0 3 5 7 9
1 4 6 8 ...
===========> line 2

The number represents the xth pixel written
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: cyclon1978 on April 17, 2009, 01:40:12 PM
i drawed only the first line and tried all HORZ/VERT modes:

#define R_ENTRY_MODE_HORZ_NORMAL 0x7030
#define R_ENTRY_MODE_HORZ_FLIPPED 0x7000
#define R_ENTRY_MODE_VERT 0x7038
#define R_ENTRY_MODE_SOLID_VERT  0x1038

but every time i got the same result: two lines from upper left to upper right. i expected i would get two lines from upper left to lower left with VERT modes... so i assume both VERT modes are not working  :-\
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on April 17, 2009, 03:18:24 PM
This snippet from plugin.lds seems to me to pass by as3525 with MEMORYSIZE > 2 or am I missing something?

http://pastie.org/450159

EDIT:  Ah, I guess it gets taken care of for us as a catch all but it makes the code a bit obscure.  Doesn't this set  #define DRAMSIZE for all the targets that follow though?  That could irritate a few people.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on April 18, 2009, 08:20:37 AM
i drawed only the first line and tried all HORZ/VERT modes:

but every time i got the same result: two lines from upper left to upper right.

That's normal, the pixels are written into the window previously specified with lcd_window_x() & lcd_window_y(), using the orientation you chose with HORZ/VERT mode.
For e200v2 you also have to change these windows (I think 2 pixels wide and 220 pixels high)

@ Flyndice : indeed this is a bit obscure and should be changed to
#elif CONFIG_CPU == AS3525
#if MEMORYSIZE >= 2
..
#else
..
#endif
#else
#   error
#endif
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on April 18, 2009, 01:29:38 PM
I posted  FS#10141 (http://www.rockbox.org/tracker/task/10141) to change plugin.lds.  Someone take a look and see what you think.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sko on April 19, 2009, 03:15:43 PM
Here is a patch by kugel and me which enables scrollwheel acceleration on e200v2: FS#10151 (http://www.rockbox.org/tracker/task/10151). Maybe someone with an e200v2 can have a look at it.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: mbr on April 20, 2009, 09:23:11 AM
Here is a patch by kugel and me which enables scrollwheel acceleration on e200v2: FS#10151 (http://www.rockbox.org/tracker/task/10151). Maybe someone with an e200v2 can have a look at it.

The patch works on my e250v2
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on April 20, 2009, 09:44:43 AM
Hi.

I have played with FS#10048 and noticed something interesting:

When declaring IRAM as cached/bufferable, rockbox sometimes boot, sometimes crash.
When it boots I can decode/play (perfect sound) ~20s of audio before it crashes.

I had the time to use test_codec before rockbox crashes, and decoding speed was significantly higher! (required freq for MP3 : 36MHz)

So the slowness problem definitely comes from caching.

Since rockbox continues to crash / deadlock (even with caches disabled), we probably have remaining bugs in our drivers, which might be more visible when caches are enabled...

So, TODO : read carefully all the as3525 drivers and look for bugs ;)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on April 20, 2009, 01:04:16 PM
I had the time to use test_codec before rockbox crashes, and decoding speed was significantly higher! (required freq for MP3 : 36MHz)

Wow even faster per clock then PP or the Gigabeat F!

When declaring IRAM as cached/bufferable, rockbox sometimes boot, sometimes crash.
When it boots I can decode/play (perfect sound) ~20s of audio before it crashes.

Do you flush the caches before/after DMA transfers to IRAM then? 
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sko on April 22, 2009, 01:45:21 AM
I updated FS#10151 (http://www.rockbox.org/tracker/task/10151): it's compiling again (didn't work since r20757)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on April 22, 2009, 07:04:55 AM
Do you flush the caches before/after DMA transfers to IRAM then?

Only before transfers, did you look at FS#10048 ?

Other topic : I started looking at USB code, and indeed the registers look very similar to AMD 5536 UDC, but some are missing (from AS3525, or from AMD 5536).

A problem is that I don't see any FIFO mentioned in AMD 5536 or AS3525, I still have to read the Linux source code to see how data is transferred.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: daytona955 on April 22, 2009, 07:22:07 AM
There seem to be Linux USB gadget drivers for the Synopsys DesignWare HS OTG core (as per the AS3525 PDF) here:

http://svn.dd-wrt.com:8000/dd-wrt/browser/src/linux/rt2880/linux-2.6.23/drivers/usb/dwc_otg

and here:

http://casper.berkeley.edu/svn/trunk/roach/sw/linux/drivers/usb/gadget/dwc_otg/

Dunno if that might help?

The  licence seems quite permissive...
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on April 23, 2009, 07:26:15 AM
Thanks, but it doesn't appear to be a compatible device:

Register at offset 0x404 is "Host Frame Interval Register" while in AS3525 datasheet and AMD5536UDC it is DEV_CTL (and I couldn't find at least one register that matches)

Here are some differences between the registers list in AS3525 datasheet and AMD5536UDC (perhaps different hardware revisions of the same chip?):

EP In Status Mask Register (EP in base + 0x18) is absent from AMD5536UDC datasheet
EP In Write Confirmation Register (EP in base + 0x1C) is absent from AS3525 datasheet

The RX & TX FIFOs are absent from both datasheets but are documented to be at 0x800 (RX) and 0xC00 (TX) in the linux driver source code.


I'm reverse engineering the usb_functio & otg_functio library blocks from Clip firmware to try to see more light but it's a bit difficult: the code appears to be compiled C++ and use a lot of pointers and structures (perhaps something to do with class inheritance).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on April 23, 2009, 11:13:11 AM
You don't seem to be interested in the MMU stuff right now anymore? It would be awesome if we could figure it out, USB is (IMO) not really essential now (i.e. if we want to release the sansas, we should fix the mmu stuff before caring about USB).

In any event, could you post the code with which you were able to have caching + playback for 20s anywhere?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: cyclon1978 on April 24, 2009, 11:10:45 AM
i adopted the lcd yuv blit patch for sansa e200. please check FS#10165 http://www.rockbox.org/tracker/task/10165 and if it can be commited it should be merged with FS#10118 http://www.rockbox.org/tracker/task/10118, it uses the same lcd_write_yuv420_lines/lcd_write_yuv420_lines_odither function. No need for duplicated code ;-)

maybe the lcd_window_blit function can be split into window_x and window_y functions like the fuze version do it...

thanks,

Andreas
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on April 24, 2009, 11:16:51 AM
Yes of course I'm still interested!

I want to work on USB to be able to use logf() through usb, and see more exactly when our Sansas stop working (it's a bit hard when the lcd screen doesn't work!)

The code I used to have playback + caching for 20s is nothing but the patch you posted on FS#10048 with these diffs:

Just see my comment on Apr 3rd (in FS#10048) : I think nothing changed since, except that I don't remember trying playback.

In short I don't have any code to share which isn't on the flyspray task already :/
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sko on April 25, 2009, 05:32:47 AM
Could someone with a fuze test how the scrollwheel works in spacerocks, please? On the e200v2 the spaceship turns in wrong direction or don't turn at all if I turn the wheel to fast. I want to know if this happens on the fuze too, as they basically use the same scrollwheel function.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: PouncePony on April 25, 2009, 07:16:59 AM
Scroll wheel works properly in Space Rocks on the Fuze.

-Pony
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sko on April 25, 2009, 07:54:49 AM
Scroll wheel works properly in Space Rocks on the Fuze.

-Pony
Thank you. I'll try to have a look at this, as it seems to be related to scrollwheel acceleration and repeats, which seem to work on e200v2 not as good as on the fuze until now.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Hillshum on April 25, 2009, 08:54:43 AM
I'm having serious issues on my e260, but I get it in the OF too (even without any RB code) so I think it's hardware related.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: fenugrec on April 26, 2009, 10:47:35 AM
Has anyone officially contacted Synopsys ? (www.synopsys.com)
They made the IP for the USB core, it would be this one:
http://synopsys.com/dw/ipdir.php?ds=dwc_usb_2_0_hs_otg

p.162 of this doc has more general information :
http://www.synopsys.com/dw/doc.php/doc/dwf/manuals/dw_frg.pdf

Having the official pdf from Synopsys would be a plus...
I tried looking around on the website, and registering on the
website was next to impossible, so perhaps an official contact
from Rockbox would have more success ?

Also, it would seem that AMD's 5536 has a different core altogether -
the datasheet doesn't mention OTG compliance, and looks more like
a complete host controller than a device.. I may be quite
wrong on this though, I just skimmed over the 5536 datasheet.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: daytona955 on April 27, 2009, 05:18:13 AM
More background info here:
  https://www.synopsys.com/dw/doc.php/ss/austriamicrosystems_ss.pdf
but nothing of concrete help.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Bagder on April 27, 2009, 06:43:30 AM
I have "officially" contacted Synopsys regarding docs for their USB block used in this chip.

They did not even respond.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: bertrik on April 27, 2009, 05:07:43 PM
I looked at the c200v2 display init sequence: it's remarkably similar to the init sequence currently used for the c200 display in rockbox. I believe the same LCD and LCD controller is used. The c200v2 uses the DBOP port to write to the LCD controller, while the c200 talks to the PP LCD port. I'm hoping we can re-use the c200 driver and reimplement the lcd_send_command and lcd_send_data functions.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: fgknskosk on April 28, 2009, 01:54:13 PM
I am using an 8gb, sansa fuze and I think I have discovered a diagnostic mode in the latest firmware
 
I accessed it by ressetting the player (hold power on) then holding the home and play keys while turning on. this gave 4 options diagnostic, northamerican, europe and rest of the world. selecting diagnostic and connecting via usb gave access to the files including upgrade.fin and mtable.sys
im not a programmer so dont know how much this helps. all the best with the port. you guys rock
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sko on April 29, 2009, 02:15:02 AM
I think FS#10151 (http://www.rockbox.org/tracker/task/10151) (e200v2 wheel acceleration) is working quite good now, maybe some e200v2 users can test the latest patch again and if there are no problems it can be commited I think.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Will on April 29, 2009, 11:20:06 AM
Quote from: fgknskosk
I am using an 8gb, sansa fuze and I think I have discovered a diagnostic mode in the latest firmware

I accessed it by ressetting the player (hold power on) then holding the home and play keys while turning on. this gave 4 options diagnostic, northamerican, europe and rest of the world. selecting diagnostic and connecting via usb gave access to the files including upgrade.fin and mtable.sys

I also have an 8gb fuze. Firmware version v01.01.22F
The "trick" can be reproduced without ressetting the player. Just hold play and home at the same time the player turns on.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: ChiefAlex on April 29, 2009, 12:57:30 PM
Same on my 2GB Fuze. Firmware is  V01.02.26T.
After chosen "diagonsis" mode language and rest are reset (e.g. Time format).
Under Options new Option named "Diagnosis". Activiating it make Screen white with Battery Voltage Info (3,870V)
and text:
Quote
Connect USB to
charge or DownKey
to continue...

After pressing "down":
Quote
[SDRAM Test]
BUS= [16]bits
SIZE=[8]MB
R/W TEST [PASS]
Downkey to continue...

after this:
Quote
[LCD Text]

Downkey
to start...

(Screen turns red, after pressing down green, blue and back to text:)
Quote
[LCD Test]

TEST END
UpKey to return
DownKey
to continue...

Now:
Quote
[Keys Test]
wh-[?] Wh+[?] Rec[?]
Left[?]Right[?]Hold[?]
Menu[?]Enter[?]Up[?]
Downkey to continue...
Pressing Keys make the ? to "ok".

Next DownKey:
Quote
[Radio Test]

FREQ 107.8MHz

DownKey to continue...

next:
Quote
[Codec Test]
Earphone
Testing...
nothing happens here. Next Downkey change "Earphone" to "MIC".
Over earphone now the Mic is active and works.

next one:
Quote
[iNAND Test]
Version V01.02.26T
SIZE = [1929]MB
FAT SIZE =[1929]MB
DownKey to Continue...

Next:
Quote
[SD Slot Test]
Insert SD...
DownKey to continue...
(SD was already inserted before, after Downkey:
Quote
[Batt.=[3.870]V
Chrg.=[3.771]V

Downkey
to End.

Device shut down after this, i started it and Media Reresh started.

Hope this helped someone.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on April 29, 2009, 03:44:45 PM
We knew about the diagnostic mode in the settings (which you can access just by uploading a fuzeT.bin named OF file too), but not that you can select diagnostic during boot and accessing hidden files in USB.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on May 03, 2009, 04:55:01 PM
domonoky, I read on IRC logs that you need help for integrating mkamsboot into rbutil ?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on May 03, 2009, 04:55:39 PM
http://www.rockbox.org/tracker/task/10185
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on May 04, 2009, 06:55:14 PM
Do we use the ide interface at all for the ams sansas?  I'm trying to understand why the ide interface gets enabled and clocked in sd_init.  I thought the internal sd was on the nand interface and the microsd was on the sd/mmc interface, connected to the processor through the apb/ahb bus.   Does the ide interface need to be enable for some reason? DRAM? What's the connection here?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Hillshum on May 05, 2009, 10:21:26 PM
Is everyone else able to get to the quickscreen while browsing the list of games? I can't on e200v2, nor will Rockbox return to that screen after booting.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: mc2739 on May 06, 2009, 06:46:56 AM
This is not a Sansa AMS problem. I also cannot access the quickscreen from any of the plugin lists on my e200v1. It does not work in the uisimulator either.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: arez1 on May 06, 2009, 11:36:16 AM
if you could tell me what this quickscreen is and how to access it, i could test it on my e200v2, if needed
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on May 06, 2009, 11:37:59 AM
Its not an AMS problem, it should have bug report on the tracker, not here.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on May 06, 2009, 03:44:39 PM
Do we use the ide interface at all for the ams sansas?  I'm trying to understand why the ide interface gets enabled and clocked in sd_init.  I thought the internal sd was on the nand interface and the microsd was on the sd/mmc interface, connected to the processor through the apb/ahb bus.   Does the ide interface need to be enable for some reason? DRAM? What's the connection here?

The IDE interface is needed for internal SD to operate correctly, but I don't know how it is connected internally : probably a Sansa extension.
To verify, just comment out the line which enables IDE clock and see if SD works.
Note : if we reset IDE interface (in CCU_SRC, see system_init()) SD stops working, all other peripherals can be resetted.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on May 07, 2009, 08:25:46 AM
I posted http://www.rockbox.org/tracker/task/10191 to see if synchronous clocking has any advantage.  For MAX speed it runs the processor at 248Mhz and peripherals at 248/4= 62 MHz.  For NORMAL speed it runs the processor and peripherals at 31 Mhz.  I don't know that this is any better than what we do now but I thought it was worth checking out.  It seemed to be more stable while I was investigating the mmu but I think funman may have found a solution there.  The one thing I can say for sure is better is the wheel light flashes much less during disc accesses, but it still flashes once in a while.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: rp on May 07, 2009, 08:30:11 AM
How is the wheel light connected to this?
I thought it's controlled by GPIO D7?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: bertrik on May 07, 2009, 09:34:22 AM
If we run the processor at less than 200 MHz, the core voltage can be reduced from 1.2V to 1.1V, according to the as3525 datasheet (see the note in paragraph 6.2.2) . This could save some power (in a simple approximation dissipated power is inversely proportional to the *square* of the voltage). I think we don't really *need* to run at absolute maximum speed of 248 MHz, so we could save power by running slightly lower than 200 MHz.

By the way, I noticed that AMS has a new revision (rev1.13) of the as3525 datasheet on their website, see http://www.austriamicrosystems.com/eng/Products/Mobile-Entertainment/High-Performance-Microcontrollers
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Llorean on May 07, 2009, 09:42:19 AM
You really should make the full speed available while boosted, I'd imagine. Otherwise you're potentially cutting off file formats (ApeV2 at certain compression levels possibly) as well as restricting the bitrates and possibly resolutions at which video can be encoded.

The whole point of being boosted is that things that need a large amount of CPU can get the full capabilities of the player behind them.

If there's a role for "not quite full power" it should probably be engineered in as a general thing, rather than choosing to limit just one port (well, set of ports).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on May 07, 2009, 11:01:30 AM
If we run the processor at less than 200 MHz, the core voltage can be reduced from 1.2V to 1.1V, according to the as3525 datasheet (see the note in paragraph 6.2.2) . This could save some power (in a simple approximation dissipated power is inversely proportional to the *square* of the voltage). I think we don't really *need* to run at absolute maximum speed of 248 MHz, so we could save power by running slightly lower than 200 MHz.

Can it be adjusted on the fly?  If so, the beast has the same problem due to its frequency/voltage scaling.  We should probably consider a more general solution to this problem, either by having more complicated boosting code or by allowing codecs/plugins to request a higher clockspeed/voltage level.

Quote
By the way, I noticed that AMS has a new revision (rev1.13) of the as3525 datasheet on their website, see http://www.austriamicrosystems.com/eng/Products/Mobile-Entertainment/High-Performance-Microcontrollers

" Added definition of Power Management Output Voltages"
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on May 07, 2009, 11:41:58 AM
You really should make the full speed available while boosted, I'd imagine. Otherwise you're potentially cutting off file formats (ApeV2 at certain compression levels possibly) as well as restricting the bitrates and possibly resolutions at which video can be encoded.

The whole point of being boosted is that things that need a large amount of CPU can get the full capabilities of the player behind them.

If there's a role for "not quite full power" it should probably be engineered in as a general thing, rather than choosing to limit just one port (well, set of ports).

That would probably also mean to to lose our zero-wait boosting. Sad thing, but I generally agree with you. However, zero wait boost is probably wanted once we get more into a gui boost.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on May 07, 2009, 03:13:22 PM
If we run the processor at less than 200 MHz, the core voltage can be reduced from 1.2V to 1.1V, according to the as3525 datasheet (see the note in paragraph 6.2.2) . This could save some power (in a simple approximation dissipated power is inversely proportional to the *square* of the voltage). I think we don't really *need* to run at absolute maximum speed of 248 MHz, so we could save power by running slightly lower than 200 MHz

Can we adjust that voltage somehow or was that a choice sandisk made when they designed the player?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on May 07, 2009, 03:56:27 PM
The AMS chip has its own voltage regulators which are under software control. 
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on May 07, 2009, 04:48:13 PM
Ah yes found it now.
Does this note on the next page under 6.2.3 have any bearing on this lower frequency?

(1) This setting must not be used for AS3525 core supply because the lower voltage limit is out of core supply specification limits.

EDIT: I suppose this could apply for the above 200Mhz clocking and if we're below that  the note on the previous page would apply.  Otherwise why would there be a setting for lower?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on May 07, 2009, 05:53:41 PM
Ah yes found it now.
Does this note on the next page under 6.2.3 have any bearing on this lower frequency?

(1) This setting must not be used for AS3525 core supply because the lower voltage limit is out of core supply specification limits.

EDIT: I suppose this could apply for the above 200Mhz clocking and if we're below that  the note on the previous page would apply.  Otherwise why would there be a setting for lower?

The voltage needed depends on the clock speed and the the process used to make the chip.  Low voltage runs of chips are possible either by optimizing for power consumption in the fab or by limiting clock speed.  Thus theres typically many more settings for voltage available then each individual chip is rated for.  If we were willing to accept low clocks for all components, we could probably use lower voltages then the chip is designed for too.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: daytona955 on May 08, 2009, 05:37:15 PM
Is there a good reason for AS3525_DBOP_FREQ to be 8MHz (clock_target.h)?
The AS3525 data sheet says <= 65MHz (para 7.3.12.7 on P92).

I've changed it to 62MHz (i.e. PCLK) on a build in an e260v2, and it seems to work well. Responsiveness of the scroll wheel is much improved - to the point where spacerocks becomes playable :)

On a slightly different clocking issue, the ARM922 tech ref (para 5.4) says that for asynch mode, FCLK must have a higher frequency than BCLK. But without boost, Rockbox seems to run FCLK at 31MHz & BCLK (aka HCLK in the AS3525) at 62MHz. How does Rockbox get away with that?

Sorry if there are obvious answers to these - I'm a bit new to Rockbox.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on May 09, 2009, 12:02:16 AM
On a slightly different clocking issue, the ARM922 tech ref (para 5.4) says that for asynch mode, FCLK must have a higher frequency than BCLK. But without boost, Rockbox seems to run FCLK at 31MHz & BCLK (aka HCLK in the AS3525) at 62MHz. How does Rockbox get away with that?

funman realized the same thing a few days ago and said he had found some success with the caching and mmu problems by increasing the frequencies.  See: FS#10048 mmu-dcache (http://www.rockbox.org/tracker/task/10048)

I managed to get synchronous up and running with this patch:FS#10191 synchronous clocking (http://www.rockbox.org/tracker/task/10191)

There is a problem with the i2c (ascodec) clocking though.  Read the message traffic on those two FS's and it should give you a good idea of where things are.  I haven't seen any comments from funman in a couple of days so I don't know if he's had any success in sorting out the clocking issues.  I have not found anything new to add in the past couple of days.

EDIT:  I finally tried some tests on SVN vs synchronous clocking.  The synchronous clocking setup turns out faster from what I can tell;
                    sync              SVN
test_codec    132.59      vs  142.5  (mp3)
test_fps         42.2 fps   vs   30.6 fps
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: daytona955 on May 11, 2009, 09:46:24 AM
Regarding DBOP clocking, is this code

    CGU_DBOP = (1<<3) | CLK_DIV(AS3525_PCLK_FREQ, AS3525_DBOP_FREQ);

in ams3525_dbop_init() correct?

For example, with PCLK=62M, and a desired DBOP clock of 8M, CLK_DIV gives 8 (truncated from 8.74999...).  (I think 62 & 8 are effectively the current SVN values.)

62M/8 gives 7.75M, which is less than 8M (and so is safe if 8MHz was an absolute limit).

But the AS3526 data sheet says  that DBOP_PREDIV_SEL is only 3 bits, so we cannot set it to 8.

Also, the actual division ratio is 1/(DBOP_PREDIV_SEL+1).

So for this example, the actual division ratio becomes 1/((0x8 & 0x7)+1), i.e. 1.

I think the code needs 1 subtracted from the divisor to have the correct effect.

Edit:
Actually, the PCLK value in SVN (clock-target.h) is

#define AS3525_PCLK_FREQ        65000000

The actual PCLK will be 62MHz, but the DBOP clock would calculated on 65MHz. This would give give a divisor of 9, giving a real value of 2 when programmed to the hardware.

However, subtracting 1 would not fix the problem in this case...
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on May 11, 2009, 10:18:54 AM
Regarding DBOP clocking, is this code

    CGU_DBOP = (1<<3) | CLK_DIV(AS3525_PCLK_FREQ, AS3525_DBOP_FREQ);

in ams3525_dbop_init() correct?

Initially, it ran at PCLK speed (see http://svn.rockbox.org/viewvc.cgi/trunk/firmware/target/arm/as3525/sansa-fuze/lcd-fuze.c?r1=19276&r2=19330). During the work for r19330, we played with the clocks and found ~20MHz (PCLK / 3) quite usable. I'd say 8MHz is not intended.

Edit: Yes, CLK_DIV seems to give wrong results. And to be honest, if it really was 8MHz, I think the the LCD would be next to infunctional. So, currently it's at PCLK / (1+1)=32.5 MHz. I think we could change it to be = PCLK and clock down when the backlight is off to save power.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: daytona955 on May 11, 2009, 02:52:22 PM
I think CLK_DIV probably does the right thing (although with out any description...), in that it gives a divisor that means the actual generated frequency does not exceed the target.

But when used with hardware that avoids divide-by-zero by treating n as 1/(n+1), the output from CLK_DIV needs adjusting. See for example

Code: [Select]
CGU_PERI |= ((CLK_DIV(AS3525_PLLA_FREQ, AS3525_PCLK_FREQ) - 1) << 2)
                | 1; /* clk_in = PLLA */

in system-as3525.c.

A quick grep shows it is used without adjustment in setting the DBOP, I2C2 and SD ident clocks. But I've only checked that the DBOP case is actually wrong (so far).


Edit:
Maybe the incorrect setting of CGU_DBOP is why funman gets this issue in FS10048:
Also I find it weird that UI becomes much slower when we divide pclk by 2 : the DBOP frequency should not change that much since it's lower than pclk anyway... do you have an idea why?

Now I have a build where DBOP clock == PCLK, and a fix to the programming of CGU_DBOP (adjust divisor by -1).

I have done a few builds with different PCLK values. I tested UI responsiveness by an ad-hoc test: how well the rotation of the spacerocks ship tracks the scrollwheel. 

With the fix to CGU_DBOP I now get decreasingly poor responsiveness with PCLK frequencies of less than 41.333...Mhz. 

Before fixing CGU_DBOP, changing PCLK (& therefore DBOP clk) had all sorts of strange effects, including white screen, scrambled screen, non responsive UI.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on May 12, 2009, 03:35:25 AM
Thanks for hunting that bug!

Indeed I think this is the source of the LCD problems we saw.

The OF uses dynamic clocking for pclk, fclk, and all peripherals, and every setting is checked at each change, but I think we can avoid that with preprocessor checks like:

Code: [Select]
#define DBOP_DIV (CLK_DIV(....))
#if DBOP_DIV > 8
#    error "dbop clkdiv too high"
#endif
CGU_DBOP |= (DBOP_DIV - 1) << x

Also the pclk should be set to its exact value (62M) not the maximal value, to calculate correct clock dividers..

EDIT : another bug I just reminded of

For users with 8GB and more models : don't use test builds because they could totally brick your Sansa.

We don't switch banks in SD transfers when we are crossing a bank boundary, so when crossing the 4GB border, we could accidentally write to the first blocks of internal storage, which hold the Original Firmware.

I noticed this problem when reading ata-sd-pp.c which has a comment line 951. (And by the way, it could be a source of the filesystem corruption the people using Sansa e200/c200 are seeing).

An efficient fix should be relatively easy to do and also applied to ata-sd-pp.c, but in the meantime be careful!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: wpyh on May 13, 2009, 08:21:02 PM
EDIT : another bug I just reminded of

For users with 8GB and more models : don't use test builds because they could totally brick your Sansa.

We don't switch banks in SD transfers when we are crossing a bank boundary, so when crossing the 4GB border, we could accidentally write to the first blocks of internal storage, which hold the Original Firmware.

I noticed this problem when reading ata-sd-pp.c which has a comment line 951. (And by the way, it could be a source of the filesystem corruption the people using Sansa e200/c200 are seeing).

An efficient fix should be relatively easy to do and also applied to ata-sd-pp.c, but in the meantime be careful!

Oops... I just upgraded my Fuze 8GB with the latest SVN. It's still working fine even though I have crossed the 4GB boundary though.

I thought we already switch banks when accessing the internal storage? Otherwise, how can it boot from >4GB?

I hope the fix can get in soon.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on May 13, 2009, 09:48:44 PM
I think you're confusing the bank switching problem (which is fixed) with a newly identified problem: writing across the bank boundaries (which is not).  Rockbox can actually boot without write support at all (see the D2 port for instance).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on May 13, 2009, 11:51:21 PM
funman:  Isn't i2c input from PCLK?

line 56 clock-target.h
#if (CLK_DIV(AS3525_PLLA_FREQ, AS3525_I2C_FREQ)) >= (1<<16) /* 2*8 bits */
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: bertrik on May 14, 2009, 01:21:09 AM
After closer inspection of the OF, it seems the high part of the i2c divider is set with only 2 bits, meaning the total divider cannot be higher than 0x3FF. This should still be big enough to divide any clock down to safe i2c speeds (< 400 kHz).

The OF uses interrupts to handle i2c traffic instead of busy-waiting. This seemed very complicated to me to implement in the intial phase of the port, maybe we should reconsider that. On the other hand an i2c transfer takes only 30 bits or so (75 us at 400 kHz), so maybe it's not worth a thread switch.

Instead of polling the i2c status/busy-bit we could could perhaps poll the i2c interrupt bits. These have not been documented yet though.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: daytona955 on May 14, 2009, 04:39:50 AM
Is it likely that the divisor is of the form 1/(n+1)? Since 1/0 is unlikely to have meaning...
So maybe the code should subtract 1 from prescaler before applying it?
At the division ratios needed, an error of +1 on the divisor is not going to have a big impact though.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on May 14, 2009, 04:52:43 AM
Oops sorry for the mistake, I corrected the problem, and also set the clock divider to 10 bits.

bertrik do you think the interrupt bits would be set before the status bits?

Since the as3525 is old now, perhaps AMS would be kind enough to give us the docs for the i2c module.. (they seem to ignore us concerning the AS3531 datasheet needed for Clipv2/Fuzev2 however)

daytona955 : it seems that the divisor is of the form 1/(n+5) ... bertrik can you confirm that ?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: stray on May 14, 2009, 03:55:23 PM

For users with 8GB and more models : don't use test builds because they could totally brick your Sansa.

We don't switch banks in SD transfers when we are crossing a bank boundary, so when crossing the 4GB border, we could accidentally write to the first blocks of internal storage, which hold the Original Firmware.

I noticed this problem when reading ata-sd-pp.c which has a comment line 951. (And by the way, it could be a source of the filesystem corruption the people using Sansa e200/c200 are seeing).

An efficient fix should be relatively easy to do and also applied to ata-sd-pp.c, but in the meantime be careful!
Does this bug only affect the internal memory?
So is using a 2GB Fuze with an 8GB microSDHC safe?

/edit: That was fast. Thx :D
 (didn't want to create another useless post)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Hillshum on May 14, 2009, 04:10:14 PM
Yes and yes.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: jago on May 15, 2009, 05:49:17 AM
Hello!

Nice work until now. Thanks  :).
I own a sansa e260 (4Gb) and I have big problems with revisions higher than r20922.
With r20923 started the trouble. My sansa freezes every few minutes or I get error messages like this: *panic* flush_fat_sector() - could not write sector xxxx (error -101)
There must be something problematical with this commit, at least for my sansa.
I am back on r20922 now and all is fine.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on May 15, 2009, 07:31:36 AM
Can you update to last svn again, and change AS3525_IDE_FREQ in firmware/target/arm/as3525/clock-target.h to 90000000 ; and see if this fixes your problem ?

I suppose that the problem is the change from 90MHz to 66MHz , perhaps we need to adjust it a bit.

We used 248/((248/90)+1) = 82.666MHz and now 248/((248/66)+1) = 62MHz IDE clock

When using PLLA at 384MHz, the OF uses 384/((384/66)+1) = 64MHz clock (perhaps not always since there is more than one PLLA setting in the OF)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on May 16, 2009, 12:17:57 AM
Need some help if anyone has had this happen.  I can't access my internal memory through usb and the OF anymore.  I can access the microsd card just fine though and I can copy from it to the internal memory ok using rockbox.  Tried a different cable no luck. Different computer, no luck Copied a new copy of a rockbox bootloader to the internal card and it went through the firmware upgrade process just fine but same results with usb.  Anyone got any ideas for me?

EDIT: Nevermind, I took a chance and reformatted with the OF and it restored my connectivity with the internal disk, Whew ;D

I'm attaching a patch that puts some clock debug info on the debug view hardware page.  I believe the sd numbers are out of whack but the rest work I think.  The assumption is that PLLA is at 248MHz and I've tried to pull the actual divider values out to see what the clock values are ending up as for the various peripherals. Your mileage may vary of course...
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: stray on May 16, 2009, 12:56:50 AM
Can you update to last svn again, and change AS3525_IDE_FREQ in firmware/target/arm/as3525/clock-target.h to 90000000 ; and see if this fixes your problem ?
This fixed my Fuze. Before i had to try several times to get the database to build, got some *panic* errors etc.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: jago on May 16, 2009, 04:18:21 AM
Quote
change AS3525_IDE_FREQ in firmware/target/arm/as3525/clock-target.h to 90000000

I have just tried.
Seems to solve the problem.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on May 17, 2009, 08:58:41 AM
Ok so using 82.666MHz clock for IDE shows better results than with 62MHz

The OF seems to use 64MHz (384/6) , if we want to see if it works alright with 64MHz, we need to change the PLLA setting to a multiple of 64MHz. (like 384MHz)

If you don't know how to change it (you need to modify the PLLA setting!) I'll try to come with a patch tomorrow.

Thanks for testing!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: iudex on May 17, 2009, 02:05:56 PM
So, what's now to do?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on May 17, 2009, 02:30:51 PM
I put a list of requirements we'd agreed on informally for a release on the wiki page.  Of course those are just the minimum for a release, theres much more then that left undone.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on May 18, 2009, 12:24:03 AM
Ok, here's the second go at something to show what the clocked rates are.  Tell me if you think this should go on FS as a patch or if this is ok just attaching to a post.  This patch only assumes that clk_main = 24 MHz.  Everything else is calculated using the actual dividers read from registers.  It takes into account synchronous, asynchronous, fastbus, optional clock inputs and seems to work very well for me.  The layout may stretch a bit long vertically for the fuze but it fits nicely in the e200 screen.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on May 18, 2009, 06:39:45 AM
If you don't know how to change it (you need to modify the PLLA setting!) I'll try to come with a patch tomorrow.

I couldn't make a patch with 64MHz freq for pclk which booted on my Fuze (showed a white screen), so I suggest just reverting this with a comment.

test_disk with CGU_IDE at 90MHz (real : 82.66MHz) just passes, so unless someone else has an idea..


@FlynDice : if you can make your patch scroll in both directions (think of the Clip..) it should be committed

EDIT: I added FS#10216 (http://www.rockbox.org/tracker/task/10216) to fix possible ATA problems on 8GB models, but it requires testing by a owner of such a device. wpyh?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on May 18, 2009, 04:49:49 PM
funman:  I just realized that I sent you my 8GB player and kept the 4GB (not the other way around as I was thinking for some reason) so I can't test.  However I did the test anyway about the 2GB mark and it obviously transfers without trouble.  If anyone else wants to try this on a real 8Gb target and let us know if it works:

Apply this patch: 
http://www.duke.edu/~mgg6/rockbox/diskcheck.patch

Then use this file:
http://www.duke.edu/~mgg6/rockbox/myfile.txt

with dd as so:
sudo dd if=myfile.txt of=/dev/sdc bs=512  seek=8026112

BE SURE TO CHANGE /DEV/SDC TO WHATEVER YOUR DEVICE MOUNTS AS!

This will write the sequence 1 2 3 ... to the block 0x7A7800.  Then check the debug screen under "View IO ports".  DIR0 is "0" and DIR4 is "1" if everything is working.  If its not, you'll get some other value (at least I hope, I can't test it on mine).  Then repeat with funman's patch to see if it works the next time.  Then you'll probably want to reformat to fix your file system.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on May 19, 2009, 02:40:53 AM
I postedFS# 10219 (http://www.rockbox.org/tracker/task/10219) for my debugclocks patch.  Scrolling is a bit beyond me right now but I did put some paging into it that should work for a clip.  See what you think.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on May 19, 2009, 05:39:37 AM
with dd as so:
sudo dd if=myfile.txt of=/dev/sdc bs=512  seek=8026112

The seek= option must be 7964671 (0x7A7800 minus 1 minus OF size)

Also don't forget to write a filesystem which is 3GB or so. This way rockbox won't write data across the 4GB limit, and you don't risk bricking your player.

Also
Code: [Select]
+        _DEBUG_PRINTF("DIR0: %x DIR4: %x", *(buf2+512), *(buf2+512+4));
should be

Code: [Select]
+        int *wordbuf = (int*) buf2;
+        _DEBUG_PRINTF("DIR0: %x DIR4: %x", wordbuf[512/4 - 1], wordbuf[512/4]);

And should return 0x7f and 0x80.

That will show the last word of last sector of first bank, and first word of first sector of second bank.

EDIT:
I postedFS# 10219 (http://www.rockbox.org/tracker/task/10219) for my debugclocks patch.  Scrolling is a bit beyond me right now but I did put some paging into it that should work for a clip.  See what you think.

Thanks, I added a few modifications and committed it.
Also thanks to your patch for making me notice a bug in Clip LCD driver :P

EDIT2:

Code: [Select]
+    sd_read_sectors(0, 0x7A7800 - 1, 2, buf2);should be
Code: [Select]
+    sd_read_sectors(0, 0x7A7800 - 0xF000 - 1, 2, buf2);because we also skip the OF in sd_read_sectors() .. sorry for the confusion.

Be sure to share your methods with your results so multiple persons can check them!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on May 19, 2009, 11:15:15 AM
with dd as so:
sudo dd if=myfile.txt of=/dev/sdc bs=512  seek=8026112

The seek= option must be 7964671 (0x7A7800 minus 1 minus OF size)

I don't think the OF shows up over USB, so you don't need to correct for it.  At least using 7A7800/2 on my 4GB (since I lack an 8GB) gave me the expected results with dd (first word of the first block of the new bank is 0x01, while the second is 0x02). 
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on May 19, 2009, 11:51:06 AM
That's because the OF doesn't show up, we need to correct it.

0 ....(OF).... 0xF000 ..... 0x7A7800 (real sectors)
........(OF).................0 ... 0x7A7800-0xF000 (usb)
........(OF).................0 ... 0x7A7800-0xF000 (rockbox)


And on your 4GB Fuze, you only have 1 bank !
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on May 19, 2009, 01:24:05 PM
The debugclocks info is in svn now but the info displayed is static, ie whatever the state of the frequencies was when the page was displayed will not change for current conditions.  This patch will turn the info back to "live" info that will change realtime.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on May 19, 2009, 01:59:43 PM
The debugclocks info is in svn now but the info displayed is static, ie whatever the state of the frequencies was when the page was displayed will not change for current conditions.  This patch will turn the info back to "live" info that will change realtime.

The usae of while(1) is weird too. Why not just button_get instead (without the timeout part)?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on May 19, 2009, 02:21:14 PM

The usae of while(1) is weird too. Why not just button_get instead (without the timeout part)?

Don't look to me for pretty or elegant coding solutions :P.  I'm sure you can tell by now I pretty much go find out how someone else did whatever I need done and copy it. If it works great, if not I shake it a little and try again! In fact I think that's a part of your code from the debug io ports that I copied for that part... ;D

Please, if you think you have a better way, change it or tell me how and I will.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on May 19, 2009, 05:42:36 PM
In fact I think that's a part of your code from the debug io ports that I copied for that part... ;D
Haha, seems so :)

You can be sure I only copied other code too :P
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on May 21, 2009, 12:33:14 AM
I have had a bit of success with the mmu tonight, not enough to say I have it working but enough to focus on what the problem may be and a taste of what may be possible with the mmu working.  I am not going to post a patch yet, maybe later tonight if I can make some more progress.  I think there are other folks who could make headway faster so I thought I would just post my findings so far in the hopes that they are useful now.  I have been playing around today with a clocking setup of PLLA=384, FCLK=192, PCLK=64, with bus synchronous for boosted and fastbus @ 32MHz unboosted(the performance of this setup was quite acceptable I thought also).  I tried the mmu setup I had been working on before the clocking issues came up and got the same i2c problems that go along with that.  So I added the delays to ascodec.c and tried again and found I could play music just fine, until the first song ended...... Then it was as if playback locked up.  I could still navigate the ui but I couldn't get playback to start again without rebooting.  Here are the things I noticed:  In the buffering thread it was showing about 44MHz average for decoding and was boosted very minimally. On the clocking display you will notice that the sd and msd freqs go to 405khz for disk accesses and then back to an invalid value when the access is over.  Well they end up locked at 405 when my music stops playing and the frequency is locked at 192MHz for the player, all while still able to navigate the ui.  I'm thinking this points to some type of sd access problem and that's an area I'm not very familiar with yet.  Then again I've been know to draw an incorrect conclusion or 2 so what do you folks make of it?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on May 21, 2009, 05:57:06 AM
MCI_CLOCK register is only changed after sd_init_card succeeded (to give maximal frequency = pclk) and in init_pl180_controller (which is only called once in sd_init(), and then at each sdhc card insertion)

So the frequency shouldn't change .. weird!

Did you check the hard value of the registers for nand & sd card, or only the frequency ?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on May 21, 2009, 08:35:09 AM
This was one of the areas in debugclocks that I had to massage slightly to work but I think I got it right.  I used the following 2 defines for the registers which I beleive are correct for MCI_CLOCK:

#define MCI_NAND        *((volatile unsigned long *)(NAND_FLASH_BASE + 0x04))
#define MCI_SD          *((volatile unsigned long *)(SD_MCI_BASE + 0x04))

As ARM has taken the pl180 docs off their website I'm kind of feeling my way along here but the results seem to be consistent.  When there is no disk access going on(my assumption is that on disk access I get the pesky button light "feature") the registers show zero for dividers but when there is disk access there is a divider present and it shows the frequency as 405 khz.  As soon as disk access stops the divider is cleared to zero and the frequency shows PCLK freq.  When I tried to check things out in the code I couldn't find a place where the divider was reset unless perhaps MCI_CLOCK_BYPASS does this( no docs though....)

EDIT:  Oh one more detail to the setup that was partly working, the IDE frquency was set at 90 but showing 76 MHz
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on May 21, 2009, 11:10:32 AM
I'll give you the pl180 docs I have later.

I identified a problem in MCI_* clock frequencies : if bit 10 is set : divide logic is bypassed and the resulting frequency is pclk.

Also we disable nand & sd modules when there is no transaction to save power : I believe the MCI_* value at this moment has no meaning.

Finally I think 405kHz value is a rounding error in divide function, because 62000000 / ((0x4c*2)+1) == 400000
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on May 23, 2009, 12:44:55 PM
I'm playing a bit around with the DBOP clock.

test_fps showed that when I use 62MHz instead of 31MHz, the framerate noticeably increases. But only when the cpu is boosted too (e.g. 197 vs 246 fps). At 62MHz, we're probably limited by the 31MHz of the CPU, as there was no increase at all.

I'm doing a battery bench now (with caption backlight and 120s backlight timeout, so the backlight is on almost always and updates are not disabled). I hope to find that the dbop clock has no noticeable impact on battery life, so that we can run it always with 62MHz (we could still clock it low in lcd_enable). Making it dependent on the cpu frequency (i.e. 62MHz while boosted, 31MHz while not) isn't exactly trivial.

I don't think we should clock it as high as possible to gain maximum performance and to make the UI more pleasent (scrollwheel responsiveness also depends a bit on dbop).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: daytona955 on May 23, 2009, 01:47:31 PM
The following are the out-pourings of a Rockbox noob - so feel free to take them with a pinch of salt...
At 62MHz, we're probably limited by the 31MHz of the CPU, as there was no increase at all.
Errm.. that implies PCLK > FCLK, which is not a legal combination, for asynch or synch clocking. Sadly  ARM DDI0184B is silent about what punishment awaits those who violate this tenet...
Quote
Making it dependent on the cpu frequency (i.e. 62MHz while boosted, 31MHz while not) isn't exactly trivial.
If PCLK is 62MHz boosted & 31MHz unboosted, DBOP clock can have a divisor of 1 (or 0 if we talk about the value written to HW). I think that's fairly trivial  ;). However, keeping the I2C clock constant is probably less trivial, but it's not clear to me if that is important. There is also the issue of fm_delay(), which is heavily dependant on CPU clock rate - again, I don't know whether it is important - but maybe it has something to do with the FM radio sometimes failing to work.
Quote
I don't think we should clock it as high as possible to gain maximum performance and to make the UI more pleasent (scrollwheel responsiveness also depends a bit on dbop).
I find the wheel responsiveness is very dependant on on DBOP clock, especially when <~40MHz. That may be because I have an e260v2 rather than a Fuze. The e260v2 code sends 2x as many OS messages per wheel rotation. Each driver sends one message per 'wheel click'. But the e260v2 has 24 clicks/rotation, rather than the 12 of the Fuze. So the CPU gets hit harder in the e260v2 case for a given rotation rate.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on May 23, 2009, 02:11:16 PM
Errm.. that implies PCLK > FCLK, which is not a legal combination, for asynch or synch clocking. Sadly  ARM DDI0184B is silent about what punishment awaits those who violate this tenet...
Our PCLK has always been 62MHz, and our CPU clock (FCLK) always varying between 248MHz and 31MHz depending on the state. I didn't know about the restrictions, but I haven't noticed obvious problems yet.
Quote from: daytona955
If PCLK is 62MHz boosted & 31MHz unboosted, DBOP clock can have a divisor of 1 (or 0 if we talk about the value written to HW). I think that's fairly trivial  ;). However, keeping the I2C clock constant is probably less trivial, but it's not clear to me if that is important. There is also the issue of fm_delay(), which is heavily dependant on CPU clock rate - again, I don't know whether it is important - but maybe it has something to do with the FM radio sometimes failing to work.
changing the divider is trivial of course. But changing it dynamically with the cpu freq, plus making it dependent on the backlight (if we want it always clocked low without backlight) is not so trivial anymore.
On the other hand, it may be much easier as I imagine, I haven't really looked into doing it since I'm waiting for the battery bench first.
Quote from: daytona955
I find the wheel responsiveness is very dependant on on DBOP clock, especially when <~40MHz. That may be because I have an e260v2 rather than a Fuze. The e260v2 code sends 2x as many OS messages per wheel rotation. Each driver sends one message per 'wheel click'. But the e260v2 has 24 clicks/rotation, rather than the 12 of the Fuze. So the CPU gets hit harder in the e260v2 case for a given rotation rate.
However, the fuze and e200 equally call the dbop read function  (the actual hardware polling) every half tick, no matter of how many messages are sent. And the e200 doesn't even ask the dbop if a lcd update is going, while the fuze still does. It doesn't have much to do with the messages sent.

However, below this 31MHz I have noticed badly decreasing wheel responsability too.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on May 23, 2009, 11:52:17 PM

changing the divider is trivial of course. But changing it dynamically with the cpu freq, plus making it dependent on the backlight (if we want it always clocked low without backlight) is not so trivial anymore.
On the other hand, it may be much easier as I imagine, I haven't really looked into doing it since I'm waiting for the battery bench first.


If we can check the status of the backlight I think it can be done very easily as part of the set_cpu_frequency() function used for boosting/unboosting.  I think we could just check if the backlight is off and if so reset the frequency to normal/2 instead of normal.

I've found something that may make this seem undesireable though.  In playing around with different frequency settings and observing the buffering thread I've noticed that the average MHz to play a .mp3 decreases very substantially when PCLK  is higher.  As an example with synchronous bus, FCLK 192, PCLK 64 for boosted, and fastbus FCLK=PCLK=64 for unboosted I get an average of 91MHz decoding an mp3, boosted 21% of the time.  If I go to 192/48 I get 160 MHz to decode and boosted 78% of the time.  At 192/38.4 it runs boosted(192MHz) at 100% and in fact sound starts dropping out because it can't keep up.  I got similar results with FCLK at 248 and varying PCLK's .  It seems with 248 though there's enough extra processor while boosted to keep sound going.

As it seems I have a penchant these days for proclaiming I have a solution to world peace and can demonstrate cold fusion in the lab would someone be so kind as to verify.... ;)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: daytona955 on May 24, 2009, 03:00:10 AM
I've found something that may make this seem undesireable though.  In playing around with different frequency settings and observing the buffering thread I've noticed that the average MHz to play a .mp3 decreases very substantially when PCLK  is higher.  As an example with synchronous bus, FCLK 192, PCLK 64 for boosted, and fastbus FCLK=PCLK=64 for unboosted I get an average of 91MHz decoding an mp3, boosted 21% of the time.  If I go to 192/48 I get 160 MHz to decode and boosted 78% of the time.  At 192/38.4 it runs boosted(192MHz) at 100% and in fact sound starts dropping out because it can't keep up.  I got similar results with FCLK at 248 and varying PCLK's .  It seems with 248 though there's enough extra processor while boosted to keep sound going.
Might this be due in part to the fact that the MPMC clock is derived from PCLK? So if PCLK is reduced from 64 to 48, and we leave unchanged the MPMC registers characterising the SDRAM (in terms of MPMC clock cycles), we are in effect telling the MPMC that the SDRAM is slower by a factor of 64/48...

I did try (in a patch in FlynDice's FS#10191) using PCLK_DIV1 to get a 62MHz MPMC clock and a 31MHz PCLK to avoid this, but RB failed to boot.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on May 24, 2009, 08:11:06 AM
I've run battery_bench on my Clip & Fuze for 3 combinations:

But I didn't test extensively performance.

From what I hear from you guys, it seem that we should use the maximal frequency for PCLK.

FlynDice : Did you run battery_bench when using fastbus for unboosted mode ? (fclk = pclk = 62MHz) ?

If there's not much loss I think this is the way to go.
I'll try to recharge my DAPs before going to work, so I can run the test and have the results for tomorrow.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on May 24, 2009, 10:07:36 AM

If we can check the status of the backlight I think it can be done very easily as part of the set_cpu_frequency() function used for boosting/unboosting.  I think we could just check if the backlight is off and if so reset the frequency to normal/2 instead of normal.
But I don't think you want to call set_cpu_frequency when the backlight goes on and off? Or wait until the next boost toggle for updated dbop clocks?

Maybe it's not hard to do, but it's not exactly trivial as far as it seems to me.

EDIT:
PS: ~9h with playing 320kbit mp3 with backlight next to always on (plus another cpu consuming feature: crossfeed) and 62MHz dbop. Not bad at all IMO. Going to test lower dbop clock now.

PS2: I think maxing PCLK seems like a good thing to do as per FlynDice "messurements".
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on May 24, 2009, 07:19:40 PM
One thing I want to double check:  mkamsboot's output will only take on the target its made for right?  So you can't accidentally flash a V1 clip bootloader onto a V2?

Additionally, i've ordered an e200v2, which has easy access to the battery terminals, so I can make whatever power measurements people are interested in seeing once I get it.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on May 25, 2009, 04:16:40 AM
Quote from: funman
mkamsboot should be made more intolerant.
I think if you're not using the correct target, only a warning will be issued while it should abort.

I also plan to make modifications of untested firmwares (unknown md5sum) fail, and if people want to test a new firmware they would have to modify the source.
EDIT: committed

Here are the plots (almost no difference for Fuze, except longer battery life with lower pclk)
For one test, my Clip wasn't fully loaded, but you can still see the difference.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on May 25, 2009, 07:02:35 AM
So, the difference between DBOP @62MHz and DBOP @15MHz (lower was not possible) is non-existent. Both give me 9h in my heavy test.

I opt for removing the divider.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on May 25, 2009, 07:04:56 AM
I opt for removing the divider.

Please just let me test on my Clip as well since the screen is different. That way we can make the change for all models.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on May 25, 2009, 08:04:14 AM
I also tested CPU @ 192/64 and PCLK@64 (just by changing clock-target.h for now) and get major speed ups in decoding and test_fps.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on May 25, 2009, 04:54:15 PM
I posted FS#10245 (http://www.rockbox.org/tracker/task/10245) to try to make changing clocking schemes easier.  You can make all your changes in about a 5 line space.  Easier for me does not necessarily mean easier for you though, your mileage may vary.


EDIT:  @funman,kugel

Would you take a look at FS#10254 (http://www.rockbox.org/tracker/task/10254) and tell me your thoughts!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: budweiser on May 29, 2009, 02:37:25 AM
i have a sansa 2.0gig running the latest rockbox with a sandisk 8gb micro sdhc.. i have it boot to the sansa firmware ..The problem I am having is if I bootup with the sd card in the unit the unit locks and I have to remove the battery . I can only boot if the sd card is not in , I can use the player just fine and it reads all the songs on the sd card .. i just can't start the unit with the card in .. is this normal ? is there a fix  for this ?

Thanks Bud....
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: matsch on May 29, 2009, 08:21:23 AM
I have a sansa clip V1 2GB, without radio chip. I try to run Rockbox SVN 21127 on it,
but there is only a black screen. In case of USB connection I can see for a short time the Rockbox menu and then the USB symbol (very weak). Same result with earlier SVN.
The clip is quite old. I bought it in Germany in Oct 2007.
Thanks for your work on Rockbox. My contribution can only be trying out versions and reporting bugs.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on May 29, 2009, 08:25:56 AM
I believe this is a known bug with certain 8GB microsd cards.  I think it's related to timing issues in the sd card driver if I recall correctly.  You should not need to remove your battery though.  You should always be able to shut down your player by holding the power button down for 10 seconds.  Then pop the card out, reboot rockbox, and once rockbox boots up reinsert the card and it should work normally.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: budweiser on May 29, 2009, 09:46:05 AM
I believe this is a known bug with certain 8GB microsd cards.  I think it's related to timing issues in the sd card driver if I recall correctly.  You should not need to remove your battery though.  You should always be able to shut down your player by holding the power button down for 10 seconds.  Then pop the card out, reboot rockbox, and once rockbox boots up reinsert the card and it should work normally.
 

No I can't turn off the unit without taking the battery out it will lock up ... I wonder if i change the boot order to rockbox first ifthis will resolve my problem ...Bud
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on May 29, 2009, 11:04:57 AM
No I can't turn off the unit without taking the battery out it will lock up ... I wonder if i change the boot order to rockbox first ifthis will resolve my problem ...Bud

If you can change the boot order then you're running a build I'm not familiar with as Rockbox should boot unless you hold the |<< (left) while turning the player on which then boots the OF.  I'm assuming an e200V2 since you can remove the battery but the clip and fuze use the same key.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on May 30, 2009, 09:27:32 AM
I have a sansa clip V1 2GB, without radio chip. I try to run Rockbox SVN 21127 on it,
but there is only a black screen.

Can you try r21087 and see if your screen works?
The current revision works fine on my Clip.
Also as far as i know all Clips should have radio chips (but disabled by the OF for some), but you will be able to confirm when you got rockbox booting.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: cpnfantstk on May 30, 2009, 01:16:59 PM
Is their any caution for me putting the latest SVN on my M200V4 for testing out bugs or is M200V4 stable enough?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: matsch on May 30, 2009, 01:44:03 PM
Quote
Can you try r21087 and see if your screen works?
The current revision works fine on my Clip.
Also as far as i know all Clips should have radio chips

I get the same result with r21087, black screen.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on May 30, 2009, 06:43:38 PM
Is their any caution for me putting the latest SVN on my M200V4 for testing out bugs or is M200V4 stable enough?

Rockbox for the Sansa AMS is not released and you will get no support here.

This thread is here for development only, I believe we will call for testers when we have something stable.

For status and warnings, just read the SansaAMS wiki page.

Quote
Can you try r21087 and see if your screen works?
The current revision works fine on my Clip.

I get the same result with r21087, black screen.

Did you update both rockbox build & bootloader? Can you see the bootloader screen? Does the Clip work with the OF?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on May 31, 2009, 12:53:11 AM
I received my e200v2.  If anyone wants power measurements taken, please let me know.  I can easily measure current in real time using a DMM for any rockbox patch by removing the battery and using a power supply.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: matsch on May 31, 2009, 02:36:15 AM
Quote
Did you update both rockbox build & bootloader? Can you see the bootloader screen? Does the Clip work with the OF?

I updated both build and bootloader. I cannot see the bootloader screen. OF works fine.
I used bootloader-clip.sansa for making the bootloader with mkamsboot. Is the file correct?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on May 31, 2009, 03:08:58 AM
Can't resist a new toy and I'm a visual type-o- guy so just to show what's possible once we figure this darned mmu thing out I got some screen shots to show you.  Its running on 192/32/32 with mmu and both caches enabled, and as you can see it's only boosting 10% of the time and averaging a bit more than 48MHz while playing an mp3 file.  You can see a bit of corruption in the screen but funman's last patch corrects this.  Playback with cached memory is still not working reliably for me though.  One interesting thing I have found also is that for some reason if I use a plugin that has playback controls to start playback I get a much higher chance of music playing for more than 4-5 minutes.  Another thing is that as long as I don't attempt to play music, Rockbox runs very well.  I can play games all day long and when I hold the power button down to power off it has a normal shutdown.  Once I play music on it though I end up having to hold the power button for 10 secs to force it to turn off.  I was wondering if the fact that things run better when started from a plugin point to a buffer conflict with the plugin & audio buffers?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on May 31, 2009, 04:24:00 AM
Quote
Did you update both rockbox build & bootloader? Can you see the bootloader screen? Does the Clip work with the OF?

I updated both build and bootloader. I cannot see the bootloader screen. OF works fine.
I used bootloader-clip.sansa for making the bootloader with mkamsboot. Is the file correct?

Yes it's the correct file (Clip bootloader).

You should try earlier revisions (bissecting) until you get display working, or perhaps tweak the delays in firmware/target/arm/as3525/sansa-clip/lcd-ssd1303.c

@FlynDice:
The plugin & audio buffers are separated (see app.lds), so I suspect a difference in timings.
Perhaps we should look again at the i2sout registers, there is some bits we don't use and the OF does.

@All:
I tagged a 1.0 release of mkamsboot (the tool to patch OF files) and you can get binaries at http://download.rockbox.org/bootloader/sandisk-sansa/mkamsboot-1.0/ (OSX binaries will come in a near future)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: jago on May 31, 2009, 07:54:51 AM
With recent revisions the radio of my e200 isn't working anymore.
If I switch to radio mode it shows only the status bar on top and freezes then.
After some investigation it seems that rev 21088 is messing something up.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on May 31, 2009, 08:31:19 AM
With recent revisions the radio of my e200 isn't working anymore.
If I switch to radio mode it shows only the status bar on top and freezes then.
After some investigation it seems that rev 21088 is messing something up.

r21088 changed the default cpufreq from 31 to 62, can you try to higher the delays in fmradio-i2c-as3525.c until radio works?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: matsch on May 31, 2009, 09:39:20 AM
Quote
You should try earlier revisions (bissecting) until you get display working, or perhaps tweak the delays in firmware/target/arm/as3525/sansa-clip/lcd-ssd1303.c

Same result with r20834. I do not know what to tweak in lcd-ssd1303.c. This is
probably a HW issue.

Maybe my clip has a different OLED compared to others which needs a higher driver strength from SSD1303. How can I change the contrast or brightness to a higher value?
At least I can see the info on the screen with USB connected, but with very weak conatrast.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on May 31, 2009, 03:17:57 PM
jago:

I have an e280 and without the mmu operating the radio function works just fine.  When I enable the mmu I have the same problem you are having.  I have tried several values for fm_delay() with no luck yet.  Still trying.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sko on May 31, 2009, 04:55:48 PM
Hmm... same problem as jago here: radio is not working on my e250v2 with clean r21151.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on May 31, 2009, 06:58:45 PM
Quote
You should try earlier revisions (bissecting) until you get display working, or perhaps tweak the delays in firmware/target/arm/as3525/sansa-clip/lcd-ssd1303.c
Maybe my clip has a different OLED compared to others which needs a higher driver strength from SSD1303. How can I change the contrast or brightness to a higher value?
At least I can see the info on the screen with USB connected, but with very weak conatrast.

You can edit .rockbox/config.cfg and add a line:
contrast: 28


contrast value ranges from 0 to 50 (maximum)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: mc2739 on May 31, 2009, 07:05:17 PM
I have added FS#10267 (http://www.rockbox.org/tracker/task/10267) to address the FM radio problem. The patch increases the fm_delay(). The radio now functions properly on my e200v2.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on May 31, 2009, 10:14:24 PM
Can't resist a new toy and I'm a visual type-o- guy so just to show what's possible once we figure this darned mmu thing out I got some screen shots to show you.  Its running on 192/32/32 with mmu and both caches enabled, and as you can see it's only boosting 10% of the time and averaging a bit more than 48MHz while playing an mp3 file.  You can see a bit of corruption in the screen but funman's last patch corrects this.  Playback with cached memory is still not working reliably for me though.  One interesting thing I have found also is that for some reason if I use a plugin that has playback controls to start playback I get a much higher chance of music playing for more than 4-5 minutes.  Another thing is that as long as I don't attempt to play music, Rockbox runs very well.  I can play games all day long and when I hold the power button down to power off it has a normal shutdown.  Once I play music on it though I end up having to hold the power button for 10 secs to force it to turn off.  I was wondering if the fact that things run better when started from a plugin point to a buffer conflict with the plugin & audio buffers?

Great! Can you upload your diff of this very setup to FS#10048? I think we're not too far away from the goal! 500+% real time seems very reasonable too compared to other targets.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: jago on June 01, 2009, 06:51:42 AM
Quote
I have added FS#10267 to address the FM radio problem. The patch increases the fm_delay(). The radio now functions properly on my e200v2.

Unfortunately it doesn't work for my e200v2 (clean r21151).
I've played around a little with the values for the delay loop. I tried values from 200 up to 2000 but there was no change. Strange that it works for m2739 but not for me.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: matsch on June 01, 2009, 09:31:31 AM
Quote
Maybe my clip has a different OLED compared to others which needs a higher driver strength from SSD1303. How can I change the contrast or brightness to a higher value?
At least I can see the info on the screen with USB connected, but with very weak conatrast.

You can edit .rockbox/config.cfg and add a line:
contrast: 28

config.cfg did not help, also tweaking some parameters in lcd-ssd1303.c was not successful.
Perhaps my OLED needs a special initialization which the OF makes. Fact is that the screen works with very low contrast which is enhanced if the Clip is connected/powered by USB.
I do not have time to go into into the LCD driver basics and stay with the OF of the Clip.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on June 01, 2009, 10:02:51 AM
Perhaps my OLED needs a special initialization which the OF makes. Fact is that the screen works with very low contrast which is enhanced if the Clip is connected/powered by USB.

I noticed the same effect when working on the Clipv2 LCD, before finding the required i2c magic.
Perhaps your screen is powered by some combination, and plugging it on USB delivers some current to it.

When I find some time I'll look at the OF again to see if we didn't forgot some combination.

By the way some GPIO pins settings were removed since they had no effect (at least on the Clips tested so far). You could try to add them back (one by one and then the 2 of them)

Just add these lines at the top of lcd_init_device() after ams3525_dbop_init() :
Code: [Select]
GPIOB_DIR |= 0x40; /* pin 6 out */
GPIOB_PIN(6) = (1<<6);
GPIOB_DIR |= 0x20; /* pin 5 out */
GPIOB_PIN(5) = 0;

And if one day you open your Clip, please write down the numbers written behind the LCD display (not that it would be useful anyway, but extra information can not harm!).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: ej0rge on June 01, 2009, 11:29:06 PM
If a developer is looking for a c200v2, send me a PM - I found one in a box of 15 broken c250's and I am willing to part with it. I just need to fix the headphone jack first, maybe re-pot the board in a case that is less damaged.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on June 01, 2009, 11:51:34 PM
For any e200v2 users who are comfortable changing the frequency settings I have found that changing the frequencies in funman's latest mmu patch at FS#10048 to DRAM=PCLK=31 and DBOP = PCLK/1 solves a whole lot of problems for us right now until things get tested more!  LCD works fine with these settings!

#define AS3525_FCLK_FREQ      248000000            /* Boosted FCLK frequency  */
#define AS3525_DRAM_FREQ       31000000            /* Initial DRAM frequency  */
        /* AS3525_PCLK_FREQ != AS3525_DRAM_FREQ/1 will boot to white lcd screen */
#define AS3525_PCLK_FREQ      (AS3525_DRAM_FREQ/1)   /* PCLK divided from DRAM freq */
#define AS3525_DBOP_FREQ      (AS3525_PCLK_FREQ/1)   /* DBOP divided from PCLK freq */
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sko on June 02, 2009, 04:05:33 AM
For any e200v2 users who are comfortable changing the frequency settings I have found that changing the frequencies in funman's latest mmu patch at FS#10048 to DRAM=PCLK=31 and DBOP = PCLK/1 solves a whole lot of problems for us right now until things get tested more!  LCD works fine with these settings!

#define AS3525_FCLK_FREQ      248000000            /* Boosted FCLK frequency  */
#define AS3525_DRAM_FREQ       31000000            /* Initial DRAM frequency  */
        /* AS3525_PCLK_FREQ != AS3525_DRAM_FREQ/1 will boot to white lcd screen */
#define AS3525_PCLK_FREQ      (AS3525_DRAM_FREQ/1)   /* PCLK divided from DRAM freq */
#define AS3525_DBOP_FREQ      (AS3525_PCLK_FREQ/1)   /* DBOP divided from PCLK freq */


Yay... I watched "Elephants Dream" from the mpegviewer wiki page with this setting and it was playing smooth most time. I also had no freezes until now (played 4 different movies until now).
I also tested one 320 kBit/s mp3 file which played with 14 % boost at about 61 MHz. I'll do further stabiltity tests with music now.
But the menus seems to react slowlier than before and the wheel is not very reliable in spacerocks and pictureflow (spacerocks at all and pictureflow on fast turns).

EDIT: radio is working again (was not working with svn)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on June 02, 2009, 04:46:37 AM
But the menus seems to react slowlier than before and the wheel is not very reliable in spacerocks and pictureflow (spacerocks at all and pictureflow on fast turns).

I can confirm that unboosted the UI responsiveness is suboptimal.

I hope we can find a setting for ~40-45MHz for unboosted (that would also let run mp3 unboosted).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on June 02, 2009, 06:37:15 AM
I can confirm that unboosted the UI responsiveness is suboptimal.

I hope we can find a setting for ~40-45MHz for unboosted (that would also let run mp3 unboosted).

Yes I believe that's from the lower PCLK, but for the e200v2's it lets the lcd function much better for now.

I tried 240/40 and she white screened on me.  I got lots-o-Rockbox time today let me see what else I can come up with for e200v2's.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sko on June 02, 2009, 08:26:09 AM
My player played 25 songs (mp3) until now without any freezes or other problems with mmu + caches... playback seems stable, but I'll let it play more songs to be sure. 
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: jago on June 02, 2009, 08:31:33 AM
I found that with forcing asynchronous bus-mode my radio is working again (Actual SVN).

Code: [Select]
#if 1 // (AS3525_FCLK_FREQ % AS3525_PCLK_FREQ)
#define ASYNCHRONOUS_BUS                          /* Boosted mode asynchronous */
#endif

EDIT: radio is working again (was not working with svn)

Yes, lowering the DRAM_FREQ to 31 MHz is working too.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: stray on June 02, 2009, 10:14:32 AM
FS#10048 (newest patch) does not work on my Fuze.
Test_disk/test_fps runs fine. No white screens,screen corruption etc.
But sometimes my scrollwheel stops working, and instead it controls the backlight. Oo

/edit: Building the database also didn't work.