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, 02: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, 04: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, 04: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, 05: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, 05: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, 12:00:20 PM
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, 01: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, 10: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, 10: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, 09: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, 10: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, 06: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, 01: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 06, 2008, 12:29:25 AM
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, 08: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, 09: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, 10: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, 12:51:31 PM
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, 04: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, 07: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, 10: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, 09: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, 12:22:48 PM
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, 04: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, 09: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, 02: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 12, 2008, 12:04:37 AM
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, 02: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, 09: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, 09: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 13, 2008, 12:15:34 AM
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, 12:24:37 PM
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, 01: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, 02: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, 03: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, 04: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, 11: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, 05: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, 04: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, 04: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, 11: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, 03: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, 08: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 21, 2008, 12:39:07 AM
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, 04: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, 10: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, 05: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, 12:36:26 PM
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, 12:56:46 PM
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, 02: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, 02: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, 09: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, 03: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, 04: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, 02: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, 03: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, 09: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, 04: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, 11: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, 03: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, 08: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, 01: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, 08: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, 01: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, 03: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, 10: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, 11: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, 12:13:38 PM
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, 08: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, 03: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, 05: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, 09: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, 12:00:11 PM
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, 12:33:05 PM
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, 01: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, 01: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, 02: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, 08: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, 10: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, 12:16:46 PM
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, 02: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, 04: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, 08: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, 10: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, 09: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, 12:49:51 PM
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, 01: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, 04: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, 08: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, 02: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 09, 2008, 12:15:41 AM
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, 02: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, 12:49:57 PM
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, 02: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, 10: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, 07: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, 12:22:57 PM
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, 05: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, 09: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, 10: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, 11: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, 12:56:57 PM
"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, 01: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, 05: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, 07: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, 08: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, 10: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, 06: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, 07: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, 09: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, 03: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, 04: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, 04: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, 09: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, 09: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, 10: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, 12:02:44 PM
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, 04: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, 06: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, 12:00:17 PM
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, 10: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, 05: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 09, 2008, 12:58:20 AM
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, 05: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, 09: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, 11: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, 02: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, 07: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, 08: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, 09: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, 04: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, 08: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, 09: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, 11: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, 12:35:37 PM
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, 12:40:16 PM
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, 12:41:20 PM
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, 01: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, 02: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, 05: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, 06: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, 09: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, 03: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, 10: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, 11: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, 03: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, 03: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, 05: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, 10: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, 04: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, 08: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, 09: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, 09: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, 10: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, 10: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, 12:11:03 PM
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, 12:17:12 PM
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, 12:29:52 PM
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, 01: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, 01: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, 02: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, 02: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, 02: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, 04: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, 11: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, 02: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, 11: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, 03: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, 07: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, 07: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, 07: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, 08: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, 08: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, 08: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, 08: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, 12:46:24 PM
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, 01: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, 01: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, 02: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, 07: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, 10: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, 09: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, 09: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, 10: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, 10: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, 11: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, 11: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, 12:58:12 PM
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, 01: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, 02: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, 02: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, 02: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, 03: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, 03: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, 03: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, 03: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, 03: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, 03: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, 04: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, 04: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, 04: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, 04: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, 09: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, 07: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, 07: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, 07: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, 08: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, 08: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, 11: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, 11: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, 12:41:17 PM
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, 12:53:19 PM
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, 01: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, 01: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, 02: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, 05: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, 05: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, 08: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, 09: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, 11: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, 05: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, 08: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, 11: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, 07: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, 11: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, 10: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, 12:28:00 PM
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, 04: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, 05: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, 05: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, 05: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, 05: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, 05: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, 05: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, 06: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, 06: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, 12:42:33 PM

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, 01: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, 04: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, 06: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, 12:14:09 PM
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, 08: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, 01: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, 01: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, 02: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, 02: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, 03: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, 03: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 19, 2008, 12:06:16 AM
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, 05: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, 06: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, 10: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, 12:51:48 PM
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, 01: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, 01: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, 01: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, 03: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, 03: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, 03: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, 08: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, 08: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, 06: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, 04: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, 07: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, 09: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, 09: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, 04: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, 02: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, 10: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, 12:23:48 PM
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, 12:47:54 PM
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, 12:56:00 PM
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, 10: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, 10: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, 02: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, 07: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, 05: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, 05: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, 07: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 October 01, 2008, 12:23:01 AM
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, 02: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, 08: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, 01: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, 10: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, 11: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, 08: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, 11: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, 02: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, 04: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, 07: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, 07: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, 03: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, 03: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, 04: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, 04: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, 09: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, 12:05:17 PM
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, 01: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, 06: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, 06: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, 09: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, 09: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, 10: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, 05: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, 12:39:07 PM
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, 08: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, 08: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, 08: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, 10: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, 11: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, 07: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, 10: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, 10: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 10, 2008, 12:48:40 AM
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, 01: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, 01: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, 04: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, 05: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, 08: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, 08: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, 09: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, 10: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, 05: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, 12:06:50 PM
@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, 03: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, 06: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, 08: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, 09: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, 09: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, 10: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, 10: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, 07: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, 09: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, 07: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, 09: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, 10: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, 12:11:48 PM
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, 05: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, 09: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, 09: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, 09: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, 11: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, 11: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, 01: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, 02: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, 06: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, 10: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, 08: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, 09: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, 01: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, 02: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, 03: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, 12:11:53 PM
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, 03: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, 03: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, 06: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, 06: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, 07: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, 06: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, 10: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, 02: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, 04: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, 05: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, 07: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, 11: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: LambdaCalculus 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, 11: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, 12:02:55 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.

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 09, 2009, 12:14:10 AM
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, 01: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, 08: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, 08: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, 03: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, 10: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, 10: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, 11: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 15, 2009, 12:53:29 AM
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 15, 2009, 12:57:40 AM
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, 01: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, 01: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, 02: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, 08: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, 09: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, 02: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, 12:18:55 PM
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, 12:22:46 PM
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, 09: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, 06: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, 09: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, 10: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, 09: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, 11: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, 11: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, 07: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, 12:18:03 PM
@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, 12:27:52 PM
@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, 12:38:21 PM
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, 12:40:17 PM
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, 12:58:55 PM
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, 01: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, 01: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, 03: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, 11: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, 10: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, 02: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, 10: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, 06: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, 01: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, 01: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, 01: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, 06: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, 08: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, 06: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, 07: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, 09: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, 01: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, 02: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, 11: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, 11: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, 08: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 31, 2009, 12:43:15 AM
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, 08: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, 10: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, 09: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, 04: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, 08: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, 11: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, 12:47:38 PM
@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, 04: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, 06: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, 09: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, 12:28:26 PM
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, 03: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, 10: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, 08: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, 11: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, 01: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, 02: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, 05: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, 06: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, 06: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, 09: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, 11: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, 12:09:08 PM
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, 12:40:57 PM
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, 01: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, 01: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, 02: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, 01: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, 02: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, 02: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, 05: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, 03: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, 04: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, 01: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, 12:16:06 PM
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, 04: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, 12:17:55 PM
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, 12:50:18 PM
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, 04: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, 05: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, 03: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, 04: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, 08: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, 12:23:25 PM
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, 02: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, 04: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, 09: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, 02: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, 04: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, 10: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, 10: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, 02: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, 02: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, 08: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, 08: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, 08: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, 12:13:11 PM
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, 12:10:45 PM
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, 12:16:51 PM
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, 06: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, 08: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, 08: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, 09: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, 11: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, 06: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, 07: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, 06: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, 02: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, 03: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, 12:20:06 PM
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, 01: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, 04: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, 05: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, 05: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, 07: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, 11: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, 07: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, 12:36:16 PM
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, 12:37:59 PM
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, 04: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, 09: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, 09: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, 10: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, 10: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, 12:01:30 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 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, 12:41:58 PM
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, 04: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, 04: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, 05: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, 06: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, 06: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, 01: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, 10: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, 11: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, 03: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, 04: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, 09: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, 10: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 14, 2009, 12:51:21 AM
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, 02: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, 05: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, 05: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, 04: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, 05: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, 06: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, 08: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, 01: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, 01: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, 05: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, 09: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, 03: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, 03: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, 01: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, 07: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, 05: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, 03: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, 06: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, 12:15:15 PM
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, 12:51:06 PM
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, 02: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, 02: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, 03: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, 06: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, 01: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, 06: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, 09: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, 12:10:32 PM
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, 01: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, 02: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, 03: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 24, 2009, 12:52:17 AM

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, 04: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, 09: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, 11: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, 08: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, 05: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, 08: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, 08: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, 09: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, 05: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, 03: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, 09: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, 09: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, 10: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, 12:04:57 PM
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, 10: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, 02: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, 02: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, 07: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, 01: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, 03: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, 04: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, 05: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, 08: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, 09: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, 10: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, 04: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, 05: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, 07: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, 08: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, 11: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, 07: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, 10: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, 11: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 02, 2009, 12:29:06 AM
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 02, 2009, 12:51:34 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 */
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sko on June 02, 2009, 05: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, 05: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, 07: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, 09: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, 09: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, 11: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.

Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: matsch on June 02, 2009, 12:55:37 PM
Quote
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()

Tried to add the GPIO pins setting back. Without success. Working Screen with very weak contrast for my Clip.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Hillshum on June 02, 2009, 12:58:48 PM

Tried to add the GPIO pins setting back. Without success. Working Screen with very weak contrast for my Clip.
As in you weren't able to get the settings back in or that worked but didn't help the problem?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: matsch on June 02, 2009, 01:36:48 PM
Quote
Tried to add the GPIO pins setting back. Without success. Working Screen with very weak contrast for my Clip.

As in you weren't able to get the settings back in or that worked but didn't help the problem?

I compiled with GPIO pins settings back, but this did not help.

The DC-DC converter is disabled in lcd-ssd1303.c.  Does OF also disable the DC-DC converter?
Perhaps my clip OLED-Driver has to run with converter.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on June 02, 2009, 02:10:47 PM
The DC-DC converter is disabled in lcd-ssd1303.c.
Does OF also disable the DC-DC converter?
Yes the init routine is the same than the OF.

You can try enabling the as3514 dcdc like Fuze & e200:
Code: [Select]
ascodec_write(AS3514_DCDC15, X); /* current = X * 1.25mA : ranges from 0 to 0x1f = 38.75mA */
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: matsch on June 02, 2009, 06:15:58 PM
Quote
you can try enabling the as3514 dcdc like Fuze & e200:

Code: [Select]
ascodec_write(AS3514_DCDC15, X); /* current = X * 1.25mA : ranges from 0 to 0x1f = 38.75mA */

OLED Driver of my Clip is supplied by as3514 DCDC. Screen is now bright with code above and X = 0x10. Will test other values for X. Thanks for the tip.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on June 02, 2009, 06:20:42 PM
Cool! Please post a patch to FlySpray when you have something clean.

Also note if it makes any lightning difference with different values.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: fuflo on June 02, 2009, 08:51:29 PM
OLED Driver of my Clip is supplied by as3514 DCDC. Screen is now bright with code above and X = 0x10. Will test other values for X. Thanks for the tip.

i can confirm this as well. i also have european clip v1 without FM. i'm not much of a developer, especially with this low level coding, but i can help test patches :)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on June 03, 2009, 02:38:20 AM
I posted FS#10270  dbop_button_lcd_delays.patch (http://www.rockbox.org/tracker/task/10270) which adds some dbop related delays into the e200v2 Button & LCD drivers.  I believe the lcd delay fixes the "white screen" failures we've been seeing and the button delay will hopefully fix the spacerocks bug at low pclk settings.  I will accept a big "I told you so" from kugel on the button delay even though he was nice enough not to say so...  :P  I believe the lcd delay is not present in the e200v2 OF but is in the fuze OF lcd driver.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on June 03, 2009, 03:16:58 AM
OLED Driver of my Clip is supplied by as3514 DCDC. Screen is now bright with code above and X = 0x10. Will test other values for X. Thanks for the tip.

i can confirm this as well. i also have european clip v1 without FM. i'm not much of a developer, especially with this low level coding, but i can help test patches :)
Can you confirm that you have no radio chip (radio not detected by rockbox) ?
You can check in debug menu -> FM radio.

Perhaps this is the way to detect the Clips which needs this special screen powering.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: fuflo on June 03, 2009, 03:53:30 AM
Can you confirm that you have no radio chip (radio not detected by rockbox) ?
You can check in debug menu -> FM radio.
Perhaps this is the way to detect the Clips which needs this special screen powering.

yeah, debug menu says "hw detected: no"
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on June 03, 2009, 05:47:32 AM
I thought that all Sansa AMS had a FM radio chip built in, and that it was disabled by software.
Probably because it was simpler to have only one board design, and so they avoided to pay taxes for devices using FM reception.

Sandisk released "different" firmware upgrades by providing identical files with a one letter extension indicating region and FM chip presence.

Recently they released firmwares for "all regions" (at least 0x.01.32 , last Clip firmware available today).

So I suppose (without proof) that they built newer boards without a FM chip, and that on these new boards they changed the way the LCD screen is powered. My 2 disassembled clips are "ver 1.5", and the Clip disassembled by anythingbutipod is "ver 1.3".

Note : the OF (verified v29, 30, 32) sets the DCDC15 register to 1, in its lcd_enable() implementation, so if we can't identify models which need this powering we would only "waste" 1.25mA on models which don't need it.

@fuflo & matsch : is your LCD functional when setting the register to 1 ? Is there any visible difference with higher values (up to 31 == 0x1f) ?

If you have disassembled your Clip (if you didn't, no need to open it), what's the hardware revision printed on the board? (between the home button and the directional keypad)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: fuflo on June 03, 2009, 06:52:42 AM
well i tried 0x1, 0x11 and 0x1f and didn't see any visual difference, works with all of them.

my clip was manufactured in 2007 but i don't know what's the revision of it.

the serial/model no. on the box is: SDMX11N-2048K-E70, maybe that helps
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: ecrips on June 03, 2009, 08:46:17 AM
I recently got a Fuze V2 and I thought I'd report on my findings:

The GPIO inputs for USB detect and Left button are the same as the Fuze V1 (using http://github.com/ecrips/Rockbox-FuzeV2/commit/8a9030bbd1f895958b5c455e398cf1ab499c27b5 I successfully get a delay only when holding Left and without USB connected). I limited the RAM to 0.5Mb not because I know it's correct, simply because I don't know for sure I have any more.

I then attempted to cobble together the ClipV2 support that funman has done with bits of Fuze V1 code, but didn't get anything to boot.

So I thought I'd go for something simple and attempted to simply turn the button wheel on and spin in an infinite loop. At which point my Fuze appeared bricked. No amount of holding the power button/plugging into USB etc got it working.

However, once the battery was flat, plugging it into USB got it booting the original firmware again! So I've recovered my device, but I'm a little wary of running random code on it now :)

It does appear that it's possible to disable the "reset" operation on the power switch on Fuze V2s which could make testing interesting!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on June 03, 2009, 10:54:57 AM
I recently got a Fuze V2 and I thought I'd report on my findings:

The GPIO inputs for USB detect and Left button are the same as the Fuze V1 (using http://github.com/ecrips/Rockbox-FuzeV2/commit/8a9030bbd1f895958b5c455e398cf1ab499c27b5 I successfully get a delay only when holding Left and without USB connected).

Cool!
Did you try to control the button light, so at least you have some output before we write a lcd driver?

I limited the RAM to 0.5Mb not because I know it's correct, simply because I don't know for sure I have any more.

Hum I don't remember why I did that: a packed Clip bootloader + packed Clipv2 OF largely fits in 0x5000 = 327680 bytes (384kB, not 0.5MB):

[INFO] Original firmware size:   391804 bytes
[INFO] Packed OF size:           90807 bytes
[INFO] Bootloader size:          45464 bytes
[INFO] Packed bootloader size:   22987 bytes
[INFO] Dual-boot function size:  272 bytes
[INFO] UCL unpack function size: 168 bytes
[INFO] Total size of new image:  114234 bytes

And the bootloader size can even be shortened by removing -mlong-calls option from gcc.

However I suppose that you have plenty of RAM behind that, since on Clipv2 & Fuzev2 the DRAM is mapped at 0x0 (the OF firmware block doesn't fit in 0x50000 bytes, so I suppose that the IRAM size didn't change between AS3525 and this newer SoC believed to be AS3531)

I then attempted to cobble together the ClipV2 support that funman has done with bits of Fuze V1 code, but didn't get anything to boot.

So I thought I'd go for something simple and attempted to simply turn the button wheel on and spin in an infinite loop. At which point my Fuze appeared bricked. No amount of holding the power button/plugging into USB etc got it working.

However, once the battery was flat, plugging it into USB got it booting the original firmware again! So I've recovered my device, but I'm a little wary of running random code on it now :)

It does appear that it's possible to disable the "reset" operation on the power switch on Fuze V2s which could make testing interesting!


You should be able to use the unmodified power_off() function, so you could test your code with a finite number of loops, and then power off to avoid having to empty the battery.

This thing also happened to me with a Clip while developping the bootloader but I don't remember why exactly (perhaps reading/writing from some GPIO pin).

Also note that on Clipv2 you have to press the power button for much longer than for Clipv1 (something like 20seconds)

I'll try to find the LCD code in the OF, since I know a bit the Sansa AMS firmwares and they all are _very_ similar (even between AMS v1 & v2!).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: matsch on June 03, 2009, 01:49:19 PM
Quote
Can you confirm that you have no radio chip (radio not detected by rockbox) ?
You can check in debug menu -> FM radio.

Perhaps this is the way to detect the Clips which needs this special screen powering.

My clip has no radio chip. Submitted patch to flyspray.
http://www.rockbox.org/tracker/task/10273
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: ecrips on June 03, 2009, 05:28:34 PM
Did you try to control the button light, so at least you have some output before we write a lcd driver?

I have attempted to turn it on using the following code:

Code: [Select]
ldr   r0, =GPIOA
ldr   r1, [r0, #0x400]
orr   r1, r1, #0xFF
str   r1, [r0, #0x400]

mov   r1, #0xFF
        str   r1, [r0, #(0xFF<<2)]

mov   r0, #0x3000000
1: subs  r0, r0, #1
bne   1b

b     boot_of

(repeating for GPIOs B, C and D) I'd expect that to configure all pins as outputs and output a 1 on each pin. But I haven't managed to turn the button light on with that code. Although it has just now occurred to me that it's possible the button light is on when a 0 is output... I shall have a go later.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on June 03, 2009, 05:54:44 PM
What if you try only GPIOA_PIN4 ?

By the way if you want to come on IRC we could discuss this "live" (i'm in CEST timezone)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on June 05, 2009, 02:01:19 PM
@kugel:  I know you think we should abandon the 31/32 MHz PCLK rates but I think you should reconsider.  With the DBOP fifo patch(yours) the ui responsiveness is very good at 31 MHz.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on June 05, 2009, 02:21:43 PM
@kugel:  I know you think we should abandon the 31/32 MHz PCLK rates but I think you should reconsider.  With the DBOP fifo patch(yours) the ui responsiveness is very good at 31 MHz.

Have you done battery benches or current messurements? I'm not sure 3x vs 6x makes much difference.

Also, we most definitely need to boost more often with 31MHz, which may result in higher drain again (since the main clock is at 248MHz then).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on June 05, 2009, 02:49:13 PM
Have you done battery benches or current messurements? I'm not sure 3x vs 6x makes much difference.

No benches yet, I just thought your main concern was ui responsiveness which your version of the DBOP fifo patch vastly improves for me at least.  I do seem to remember noticing that the higher PCLK setting did impact battery time when funman ran his benches a few weeks ago.  I don't have enough info to say that I think we should lower it, I'm just saying that ui responsiveness is not a problem at the lower frequency now as far as I can tell.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: matsch on June 05, 2009, 05:03:03 PM
Clipv1 r21190 sporadically stops playing MP3s showing 'filename (root) 1018'.
I think this happens more often when playing large mp3-Files or pressing pause play button several times for one file. Only after reboot the Clip plays again.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on June 05, 2009, 05:09:06 PM
Yeah playback sometimes stops on the Clip.

The problem is known, and specific to the Clip, but no cause has been determined yet.

EDIT: If some people have a m200v4, it would be very helpful to tell if you meet this same bug, so we could relate it to the small amount of memory of these 2 models (2MB)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: iudex on June 06, 2009, 03:30:06 PM
My clip dont want to boot with caching patch.

It shows me:

Loading firmware
LEnght: 63210
CHecksum: 26CED3E
Model name: clip
Loading rockbox.sansa
Sum: 26CED3E
Executing
 >:(
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on June 06, 2009, 07:07:47 PM
My clip dont want to boot with caching patch.

Some people had to update the bootloader to make it work. Did you update it ?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sko on June 06, 2009, 07:11:45 PM
I made a patch for e200v2 which makes the button driver more equal to the one of the fuze (which uses same repeat/acceleration logic since r21166 (http://svn.rockbox.org/viewvc.cgi?view=rev&revision=21166)):


Here is the patch: FS#10284 (http://www.rockbox.org/tracker/task/10284)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kronflux on June 06, 2009, 11:14:14 PM
I made a patch for e200v2 which makes the button driver more equal to the one of the fuze (which uses same repeat/acceleration logic since r21166 (http://svn.rockbox.org/viewvc.cgi?view=rev&revision=21166)):
  • it renames the repeat variable to accel
  • using same comments as on fuze (as they are describing the same)
  • remove wait for fifo empty
  • implement button_delay in the same way as on the fuze
Here is the patch: FS#10284 (http://www.rockbox.org/tracker/task/10284)

Just tested this! seems to work rather well, I definitely prefer it over the way it was.
Running this on my e280v2.
Edit: Also just made the hardware mod that gets rid of the "click" feel in the wheel, and tried it both with this patch and without, and both with the wheel mod and without, this patch is still preferable, to me anyway.
Nice work! thanks a lot!

Don't know if this has been addressed yet, but the player randomly likes to turn the wheel light on during playback, and sometimes when browsing, it flickers.
I think the issue was addressed, but was it ever fixed previously?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on June 07, 2009, 04:19:40 AM
Don't know if this has been addressed yet, but the player randomly likes to turn the wheel light on during playback, and sometimes when browsing, it flickers.

This is a known "problem" also happenning on fuze, and which will eventually be looked at in the future.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on June 07, 2009, 02:30:22 PM
I made a patch for e200v2 which makes the button driver more equal to the one of the fuze (which uses same repeat/acceleration logic since r21166 (http://svn.rockbox.org/viewvc.cgi?view=rev&revision=21166)):
  • it renames the repeat variable to accel
  • using same comments as on fuze (as they are describing the same)
  • remove wait for fifo empty
  • implement button_delay in the same way as on the fuze
Here is the patch: FS#10284 (http://www.rockbox.org/tracker/task/10284)

Just tested this! seems to work rather well, I definitely prefer it over the way it was.
Running this on my e280v2.
Edit: Also just made the hardware mod that gets rid of the "click" feel in the wheel, and tried it both with this patch and without, and both with the wheel mod and without, this patch is still preferable, to me anyway.
Nice work! thanks a lot!
Cool, so I guess it can be committed.

Also, if you don't have the hardware clicks, you can consider tweaking this line "if (++counter >= 2 && queue_empty(&button_queue))". That limits the wheel value posts to match the physical click to scroll 1 item per click in lists.
Quote
Don't know if this has been addressed yet, but the player randomly likes to turn the wheel light on during playback, and sometimes when browsing, it flickers.
I think the issue was addressed, but was it ever fixed previously?
Yea, that's known, but for now it's rather useful. I'm eventually looking into making the buttonlight act as disk indicator on all targets (as an additional option of course).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kronflux on June 07, 2009, 04:40:29 PM
This is a known "problem" also happenning on fuze, and which will eventually be looked at in the future.
Must not be all Fuze models.. I've had my 4gig Fuze running rockbox for a while now, keeping it up to date with the latest svn and occasionally applying patches, and I've never encountered the wheel light flashing, and I used it every day.. any idea which models it applies to? or am I just a lucky one? :P
Also, if you don't have the hardware clicks, you can consider tweaking this line "if (++counter >= 2 && queue_empty(&button_queue))". That limits the wheel value posts to match the physical click to scroll 1 item per click in lists.
any idea how what I'd tweak it to? I'm still very new to all this stuff :)
if this is the wrong place to ask, want to pm me if you don't mind making suggestions?
Quote
Yea, that's known, but for now it's rather useful. I'm eventually looking into making the buttonlight act as disk indicator on all targets (as an additional option of course).
that's a cool idea, the only thing I don't like about it is that the wheel light is very bright, so its very distracting for everyday use, but as you said, optional, so still a good idea.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sko on June 07, 2009, 05:15:45 PM
Cool, so I guess it can be committed.
I posted a second patch to FS#10284 (http://www.rockbox.org/tracker/task/10284), missed one button_delay, but if it's fine it can be commited (from my position so far).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on June 08, 2009, 03:08:52 PM
I did a couple of battery benches over the weekend and got some unexpected results.  I thought I would go for the longest lasting first so I tried svn with FS#10048 applied and modified the clocking to fastbus only, 62 MHz boosted & 31 Mhz unboosted.  I got 12:38 runtime.  Then I tried svn with FS#10048 which is 248/62 synchronous expecting the time to be slightly less.  No way Jose!  15:41 using the higher frequencies.  I'm attaching the text files to this post as It would take me too long to actually learn how to make the graphs....  I guess after this I'm reconsidering my thoughts on the whole lower PCLK frequency issue.  I see no advantage now.

Is there a good way to store a database or collect all the battery bench files in one location to get a better idea of what works best?

I was thinking of modifying clock-target.h to give a choice of pre-configured clocking schemes while also keeping the ability to use the present system if you need more options.  Does this seem like a good idea or unneeded complication?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: matsch on June 08, 2009, 04:05:36 PM
Yeah playback sometimes stops on the Clip.

The problem is known, and specific to the Clip, but no cause has been determined yet.

Stable MP3 playing would be fine. I am not experienced enough to find the root cause, but
I can help testing some ideas to get stable MP3 playing.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on June 08, 2009, 04:40:51 PM
FlynDice : there is a wiki page (http://www.rockbox.org/twiki/bin/view/Main/BatteryRuntime) for battery benches, and even a Sansa category.

To generate graphs I used gnuplot, thanks to a detailed howto (http://www.misticriver.net/forums/rockbox-forums/57498-graphing-battery_bench-linux.html)

matsch: perhaps it would help enabling logf (there is an option when configure script is run) to see if codecs have to say something when playback stops
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: matsch on June 08, 2009, 06:18:44 PM
Quote
perhaps it would help enabling logf (there is an option when configure script is run) to see if codecs have to say something when playback stops

How can i handle logf? Compiled it with option logf, but going to logf results in a black screen, in case of logfdump nothing happens.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on June 08, 2009, 07:10:21 PM
codecs will write into the log, mostly if not always in error cases (FLAC codec seems to always write the number of decoded frames though)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: PouncePony on June 08, 2009, 11:20:27 PM
SVN build after Revision 21228 freezes my 8GB Fuze on boot.  Used OF to format memory - still freezes at boot.

-Pony
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on June 09, 2009, 03:21:28 AM
SVN build after Revision 21228 freezes my 8GB Fuze on boot.  Used OF to format memory - still freezes at boot.

Did you update the bootloader as well ?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: cyclon1978 on June 09, 2009, 04:27:29 AM
similar for me, build from 21232 freezes most times at startup screen (second one, Ver.), every time on video playback, not on mp3 playback. When it freezes, the Scrollwheel LED is on.

Device is an e280, no memory card inserted, fresh formated storage. Bootloader and Rockbox same version.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: PouncePony on June 09, 2009, 07:19:37 AM
SVN build after Revision 21228 freezes my 8GB Fuze on boot.  Used OF to format memory - still freezes at boot.

Did you update the bootloader as well ?

No.  Will try later.  Thanks.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on June 09, 2009, 07:36:02 AM
similar for me, build from 21232 freezes most times at startup screen (second one, Ver.), every time on video playback, not on mp3 playback. When it freezes, the Scrollwheel LED is on.

Device is an e280, no memory card inserted, fresh formated storage. Bootloader and Rockbox same version.

Did you check / formatted the filesystem after rockbox crashes ? It could leave the file system corrupted if it crashes in the middle of a storage I/O operation.

When does it crashes on video playback ?

When it's crashed, is the backlight thread still running ? (hold button will shut off the screen like rockbox normally does).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: cyclon1978 on June 09, 2009, 08:32:36 AM
after a crash the screen goes off after configured time and on with a key press

i had to delete nvram.bin after the last crash to enter rockbox again.

- it freezes entering a deeper folder (music/artist/album/), deleting new dated nvram recovers...
- it freezes on "loading" screen with elephantsdream and other videos are played, deleting new dated mpegplayer config recovers...
- Building database freezes at 142 found (number of files)
- now i can play a singe mp3 file from any folder - no issues for that.
- insert into playlist crashes with "inserted XX tracks" (XX counts up to number of selected files)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: rp on June 09, 2009, 08:40:32 AM
on my e280 there is also a problem with the database.
Every time i try to initialize/update the database it "finishes"(without counting the files) within 1 sec and tells me to reboot.
but after a reboot, it still says that the database isn't initialized
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on June 09, 2009, 08:43:12 AM
rp i had the same problem but it went away after i reformatted the player from the OF
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: rp on June 09, 2009, 08:45:40 AM
I reformatted yesterday and just copied the mp3's to it.
Could there be still a problem with the storage access?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: midijunkie on June 09, 2009, 08:48:50 AM
Reformating didn't do it for me. I had to reflash the bootloader.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on June 09, 2009, 08:50:39 AM
Everything is possible, I just try to get all useful information so someone can understand and fix potential problems.

rockbox is still unsupported on SansaAMS : that means the port is still full of bugs.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: rp on June 09, 2009, 08:52:43 AM
I know I know and I'm not bitching here around what doesn't work, I just want to help to fix those bugs.  ;)

If you need more debug information, I will try to gather it.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: cyclon1978 on June 09, 2009, 09:42:43 AM
there are working e280's out there with build 21232 ?

i have ~1,5 gig data on the player

could someone with a working player describe how much files he/she has on it, internal or external storage?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on June 09, 2009, 09:51:50 AM
I played audio for 6 hours on my e200v2 using a freshly formatted disk and the latest bootloader.  No issues.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: cyclon1978 on June 09, 2009, 10:14:06 AM
ITS WORKING!

Video Playback is great.

I have only deleted 90% of my files, so player is nearly empty, just one video and a couple of mp3s.

Now i will test it with a fresh set of mp3's which were never on the player...

ISSUES ARE BACK!

Copied 1.8 Gig mp3s to the player (670 files), all issues back like described in my previous post. To recover, i needed to reformat player and put everything newly on it - but only 10 mp3s - works great again. It seems that it depends on memory position rockbox is writing to.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on June 09, 2009, 02:20:28 PM
I just posted FS#10308 (http://www.rockbox.org/tracker/task/10308) to flyspay to add some preconfigured frequency configurations to clock-target.h.  As a note, there are 2 configurations which use 32MHz for dbop which will let e200v2 users use their radio for now until we find a better solution. There is a tradeoff there but if you simply must have your radio....
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on June 09, 2009, 03:10:33 PM
Please test FS#10309 (http://www.rockbox.org/tracker/task/10309) : my Fuze would deadlock in the SD driver because of data timeouts, but with this patch it doesn't seem to.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: ej0rge on June 09, 2009, 03:26:56 PM
Alright, my C250v2 is on it's way to funman.  ;D

Also, if any developers need fuze or fuze v2 spares (except screens!), i may have 'em.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on June 09, 2009, 03:59:18 PM
I've put up a patch to fix the buttonlight here: http://www.rockbox.org/tracker/task/10306

Please test, I may have overlooked some conditions.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kronflux on June 09, 2009, 05:13:18 PM
I've put up a patch to fix the buttonlight here: http://www.rockbox.org/tracker/task/10306

Please test, I may have overlooked some conditions.

so far, during general playback, and when switching themes(the two times I noticed the problem most) it works great!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: iudex on June 09, 2009, 05:18:10 PM
So:
1. Clip playback stops randomly (all bitrates, especially 320kbit/s).
2. After that sometimes I can resume.
2. Down button sometimes doesn't work.
 :)

Clip formated, new build, new bootloader with 32 OF.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on June 09, 2009, 05:25:31 PM
iudex, thanks but these problems are already known ..
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: matsch on June 09, 2009, 05:39:27 PM
codecs will write into the log, mostly if not always in error cases (FLAC codec seems to always write the number of decoded frames though)

get no info from logf if Clip MP3 playing stops randomly

EDIT:

from 'View buffering thread' I get PCM 0/176400 if MP3 playing stops. Perhaps this is helpful.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on June 09, 2009, 07:51:33 PM
codecs will write into the log, mostly if not always in error cases (FLAC codec seems to always write the number of decoded frames though)

get no info from logf if Clip MP3 playing stops randomly

EDIT:

from 'View buffering thread' I get PCM 0/176400 if MP3 playing stops. Perhaps this is helpful.

You'll probably have to insert your own debug statements to print things into the log.  Its unlikely someone has already added the correct ones in expectation of deadlock issues on future targets.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: daytona955 on June 10, 2009, 03:47:37 AM
I just posted FS#10308 (http://www.rockbox.org/tracker/task/10308) to flyspay to add some preconfigured frequency configurations to clock-target.h.  As a note, there are 2 configurations which use 32MHz for dbop which will let e200v2 users use their radio for now until we find a better solution. There is a tradeoff there but if you simply must have your radio....
The weird thing is, the performance hit is minimal. I sort of hinted at this:
http://www.rockbox.org/tracker/task/10267#comment30797
For test_codec I get:
DBOP62M 31M
MP3 VBR5593%591%
OGG551%549%
The test_disk figures are also broadly similar.
But even stranger is that the test_fps figures are completely identical:
LCD Update
1/1 44.7
1/4173.5
LCD YUV
1/129.5
1/4 113.5
I would have expected the DBOP clock to affect LCD update most...
These figures are from an otherwise unchanged r21234 build. On an e260v2.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on June 10, 2009, 12:25:54 PM
Okay, it only took me 2days but i finally got the plotting thing to work.  One is SVN before FS#10048(mmu), one is with mmu and 62/31 fastbus only, and finally the winner is 248/62 synchronous bus.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: matsch on June 10, 2009, 05:37:21 PM
Playing MP3 with r21228 does not work on Clip v1. MP3 files are directly skipped with the message 'codec failure'.

R21207 was OK.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on June 10, 2009, 05:44:50 PM
please make sure you rebuilt the codecs (make && make zip) and not only rockbox (make bin) and give a try to FS#10309 (http://www.rockbox.org/tracker/task/10309)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: helios on June 10, 2009, 06:58:46 PM
rockbox-r21245 on my Sansa e200v2 with 2 MB flash, no SD card, appears to run fine - after I also upgraded the bootloader. I was not sure whether I had to scramble the bootloader, but since scramble.c was already compiled after making the bootloader and mkamsboot didn't complain I assume it has been scrambled by making the bootloader already.

Well it works. I am able to play a mpeg video now. Video and music are perfectly in sync. ;) jpeg images are rendered way faster at least in my subjective perception. mpeg3, ogg vorbis, flac playback appears to be just fine - it doesn't appear to boost that often anymore. some c64 sid files play, some do not, but that didn't change to previous versions. Well thanks - its getting better all the time. I did not apply FS#10309, so far it appears to work without it or it has been applied meanwhile.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on June 11, 2009, 12:23:39 AM
well I'm back to having problems with the 8GB sd card.  If I format it it works great for awhile. Then it starts acting up on me until I reformat it again and it works great for awhile and then......   I'm hoping funman's FS#10309 is going to help this but we will see.  Funman is there an easy or intelligent way to check the card after it gets borked up to see what's getting changed on it?  I think I can still access the card on my desktop machine.  I'm pretty sure something on the card is getting altered as rockbox  boots up without any problems once the card gets reformatted.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: matsch on June 11, 2009, 04:33:20 AM
please make sure you rebuilt the codecs (make && make zip) and not only rockbox (make bin) and give a try to FS#10309 (http://www.rockbox.org/tracker/task/10309)

After rebuilding codec and applying patch FS#10309 same result. What is your clip v1 doing?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on June 11, 2009, 06:41:25 AM
@flyndice : there is nothing to check, if rockbox SD driver is buggy it will randomly write bad data to the card, and could corrupt your files, your filesystem, or both. Perhaps you can run md5sum of known files to see if they changed.

@matsch : my clip works fine (r21245 + fs#10309), did you check your filesystem/reformat before using fs#10309 ?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: werich on June 11, 2009, 11:47:47 AM
Hello, my testing results are:

my fuze 8GB with 8GBsd finally works with r21245 (with and without fs#10309, actual bootloader, reformatted) before that it froze on startup since FS#10048 was included in SVN. But there seems to be problems with the 4GB barrier?!

Building up the database stops after reading half of the internal songs, always at the same number. SD card sums up to that number with no errors, if inserted. After build DB fails, the filesystem is corrupted.

The player doesn't recognize internal filesystem anymore, if i try to access one song from the second half of the internal memory (its nearly full and newly copied in one rush after reformatting the player). Playing music from first half or sd-card is running fine and speed with FS#10048 is awesome!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: matsch on June 11, 2009, 12:00:04 PM
Quote
@matsch : my clip works fine (r21245 + fs#10309), did you check your filesystem/reformat before using fs#10309 ?

Now I did reformat clip,  install bootloader again, but r21245 + fs#10309 leads to
skipping MP3s and showing 'codec failure' before skipping
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on June 11, 2009, 12:56:16 PM
Thanks to all you

I'll resume my understanding of the current situation:


If you think you have a fix for this, here is how to test it :
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: matsch on June 11, 2009, 01:26:01 PM
Quote
@matsch : my clip works fine (r21245 + fs#10309), did you check your filesystem/reformat before using fs#10309 ?

Now I did reformat clip,  install bootloader again, but r21245 + fs#10309 leads to
skipping MP3s and showing 'codec failure' before skipping

Sorry, I made a compile error. Now it works with r21245.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on June 11, 2009, 01:31:34 PM
But there seems to be problems with the 4GB barrier?!

Building up the database stops after reading half of the internal songs, always at the same number. SD card sums up to that number with no errors, if inserted. After build DB fails, the filesystem is corrupted.

The player doesn't recognize internal filesystem anymore, if i try to access one song from the second half of the internal memory (its nearly full and newly copied in one rush after reformatting the player). Playing music from first half or sd-card is running fine and speed with FS#10048 is awesome!

I just committed a potential fix as r21248 : we didn't check if the data transfer used for bank selection succeeded or not. Now it will retry indefinitely until it succeeds, just like normal data transfers.

Can you give it a try ?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: werich on June 11, 2009, 05:59:26 PM
tested r21248 (after format from the OF) on fuze 8GB (microSD temporarily removed cause it seems to work, as before).

Putting only a few files on it worked as it should (including building a correct DB) - but with more songs it didn't play these new ones, DB build stops immediately with 0 songs (not like before as it recognized at least the first 4GB correct). The accessible memory-border seems to be much lower now - 1 GB estimated. Maybe the 1GB with SD driver access funman mentioned at IRC yesterday?

Good thing is the filesystem corruption seems to be gone.

(edited: made it more clear)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on June 11, 2009, 08:39:24 PM
OK this looks like previously the bank switching failed, and now the initialization of bank switching fails.

To confirm you could format your Fuze with a size-limited file system:

mkfs.vfat -F 32 /dev/sdb $((0x7A7800/4-0xF000)) # for 1GB filesystem, test with r21248
mkfs.vfat -F 32 /dev/sdb $((0x7A7800-0xF000)) # for 4GB filesystem, test with r21247

and see if rockbox functions properly.

I had a look at the disassembly again and I found these:

I could perform some tests if I could reproduce this problem but "unfortunately" my Fuze works perfectly ..
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: matsch on June 12, 2009, 03:41:55 PM
I observed 'view buffering thread' of Clip v1 while playing mp3.
MP3 playing stops occasionally when buffer usefl is filled up. Buffer pcm is 0.

I reduced buffer size by changing 'Max Entries in File Browser' to 4450
and 'Max. Playlist Size to 1000'. With this settings the bug can be repoduced with a certain mp3 file.
Shortly after starting play I hear a hissing noise and playing stops. After changing back the settings the file plays on.
some files play fine with the 4400/1000 setting, some not.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on June 13, 2009, 04:48:41 AM
Before the thread becomes filled with loads of bug reports about SD/internal storage:


I insist on the random behaviour because storage access works fine for some people and some revisions, and doesn't work the day after, even if the difference between the two builds are not related to Sansa AMS.


If the file system is corrupted, plugins and codecs which are loaded from the storage can't obviously be relied upon, so any crash report (data abort at XX ..) is basically useless.

Easy solution : don't use them.

If you want to use the unstable, unsupported, unreleased development version of rockbox, you should use r21227 or anterior.


How to report that your Sansa doesn't work: please do not, we already know that our code is broken.


Let me add that my Fuze 4GB worked very fine (I still see unfrequent corruption of the LCD display, but that has always been) yesterday, but not today; even if no related changes have been committed.
That seems like an extra argument to the randomness of the problems we have.

EDIT: my Fuze infinitely loops into sd_transfer_sectors() because the SD controller reports a DATA TIMEOUT (bit 3 of MCI_STATUS).
Still the exact same problem I saw before committing r21247 to set timeouts specified in SD Specification.
Still random though : my Fuze boots after I added debug code in INT_NAND() ..


@matsch : thanks for the report, I'll try to reproduce when I find some time
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: freddy on June 13, 2009, 08:08:16 AM
Hi people

I just tried rockboy and it works quit  :) well after a small patch to the button code. I made a little patch that makes the scroll wheel work in rockboy again. Most games I tried work very well already. Should I make an FS entry for this patch ?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on June 13, 2009, 11:56:21 AM
Hi people

I just tried rockboy and it works quit  :) well after a small patch to the button code. I made a little patch that makes the scroll wheel work in rockboy again. Most games I tried work very well already. Should I make an FS entry for this patch ?

Yes, and we also need your real name.

I haven't updated my fuze recently but I've not encountered SD weirdnesses so far.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: freddy on June 13, 2009, 01:18:03 PM
http://www.rockbox.org/tracker/task/10327 Here is the FS entry  :)

My fuze isn`t having any problems with SD I am running r21265
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: GodEater on June 13, 2009, 01:22:54 PM
Can you please go back to the task and give us your full realname please. If you don't, your patch will get rejected.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: porio on June 15, 2009, 09:15:41 AM
Hi everybody,

I've  been trying rockbox for some weeks in my Clip. Most of the time it rocks!! If it wasn't for the freezing problem...
But I have realized, with several SVNs, that the probability of freezing is almost certain after skipping a track. If I don't skip, I can usually play a full album without issues. I can even fool around with sound settings, applications, file browsing, etc. In the Anythingbutipod forum someone else reported the same.
Has anybody else noticed that? Wouldn't it be an important clue about what the origin of the freezing is?

I hope I'm not introducing noise with this, I'm definitively in the user's side but eager to help debugging. Thank you all for the effort!

Regards
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: ku-ku on June 15, 2009, 01:19:06 PM
I've installed the 21288 build with a bootloader of the same revision on my 8gb fuze with an 8gb card. The same problem with internal memory. But I do can use rockbox without a problem with my 8gb card and database works too when there are no files on the internal memory. And I am using it now because I can't stand original firmware. By the way if I try to use original firmware when there are  files on an internal memory my player can't display all the files neither on a card nor on a player. And there is a note on the sansa forum: Song database supports up to 8000 songs (requires device format through settings menu for libraries larger than 4000 files) . But when I tried to format my player in such a way rockbox refused to load till I format the player through windows format utility.

P.S. Sorry. I've checked rockbox after formatting from original firmware menu and rockbox works.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: hex on June 16, 2009, 12:35:33 AM
So I ordered an 8GB Fuze with the expectation that I could use the built-in OGG/MP3/FLAC capability to keep me satisfied until a stable version of Rockbox was released for it.

As a long-time user of Rockbox for iPod Nano, I was looking forward to gapless and crossfading playback (among other cool features).  One of the first things I did once I opened the package was to update the firmware...  to V02.02.26A.

So I have a second-version Fuze that will not have a version of Rockbox for some time.  What kind of information do you guys need to get cracking on the V2 build?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on June 16, 2009, 01:32:14 AM
What kind of information do you guys need to get cracking on the V2 build?

How much spare time do you have available and can you learn C......  ;)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: hex on June 16, 2009, 01:38:31 AM
How much spare time do you have available and can you learn C......  ;)
I'm a Computer Science student on summer break.  You tell me.  :-P

I'm proficient in C++ and some assembly.  This seems like a great opportunity to get my feet wet in low-level C and asm, but I certainly don't want to brick the device.

If I can spare the disassembly of my brand new player, I would be happy to provide you whatever you need.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on June 16, 2009, 01:48:20 AM
@funman:

system-as3525.c lines 300-302 the comment does not seem to match what the ascodec_write code actually does or am I missing something ....again.   P128 as3525 datasheet
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on June 16, 2009, 01:51:30 PM
@ hex : ecrips has already done a dual boot support for Fuzev2, now you can read the disassembly of your OF and try to get LCD working (better contact ecrips first to share the work).

See FS#10047 (http://www.rockbox.org/tracker/10047) : it's for the Clipv2 but the link to Fuzev2 work by ecrips is in the ticket.

@ FlynDice : Perhaps the comment could be reworded: you can experiment with removing this line and booting rockbox : keeping the power button pressed for 1 or 2 seconds will hard shutdown the player, while if this code is run you'll need to keep pressing for 10 seconds.

@ ku-ku : have you read this (http://forums.rockbox.org/index.php?topic=14064.msg151588#msg151588) post ? Because your post just looks like a bug report which is not helping development.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: hex on June 16, 2009, 05:49:44 PM
@ funman:  I'm thoroughly confused.  I searched the forums for ecrips, and the only thing that came up was your post.  How can I PM (or otherwise contact) this user?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on June 16, 2009, 06:25:58 PM
hex:  http://forums.rockbox.org/index.php?topic=14064.930
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on June 16, 2009, 08:12:10 PM
I just postedFS#10344 (http://www.rockbox.org/tracker/task/10344) which lowers the core voltage of the processor when it is running at less than 200 Mhz.  I got just under 18 hours on the battery bench.  Here's a graph for comparison.  This patch is in purple marked Lower Voltage.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: bertrik on June 18, 2009, 03:06:23 AM
I experimented a bit with the memory layout of my sansa clip, in particular with the location of the stacks. I moved them from DRAM to IRAM (in firmware/target/arm/as3525/apps.lds) and decreased the CODEC_SIZE a bit to make room (in firmware/export/config-clip.h). I have not seen any playback stops anymore (I played and skipped around for several hours).
This probably isn't a proper fix, but at least it may give a clue on what could be causing these playback stops.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: notlistening on June 18, 2009, 02:08:21 PM
Side note on the FM receiver on the E200 Europe sold as non radio version. Following the wiki on how to upgrade the firmware i got a dual boot system for rockbox and wanted to test the OF to see if what i had read earlier in the forums the all e200's have radio capabilities was accurate.

The menu was there in the OF and I could access it, but no sound. It would tune to the frequency of known stations but still no sound. Then loaded rockbox and it just hungs when i try and run radio, bar the once when it got into the radio menu but t hung soon after.

This all ended up with me (i think being in radio mode in the OF) and having the player plugged into the wall using a wall charger and pushing the power buttons so that it reports going into standby mode. After switching the player back on radio now works in the OF always but not rockbox.

Just thought i should report this behavior even if it is irrelevant. Seems it might be a feature of the OF maybe only when using radio for the first time?

Tom
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on June 18, 2009, 02:25:26 PM
notlistening have you checked FS#10267 (http://www.rockbox.org/tracker/task/10267) ?

Now you should update your forum signature (perhaps change it to "not listening to any radio") :)

ej0rge sent me a c200v2 and i could get lcd to work (still buggy : sometimes there's no output in the bootloader), and it looks like it has the same problem than e200v2 for the radio, and the same problem than clip for playback.

Hopefully it will help fixing those ..
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sko on June 22, 2009, 03:48:54 PM
Hi, back again, had not much spare time last two weeks. I updated FS#10284 (http://www.rockbox.org/tracker/task/10284) with my actual attempt of an unified driver for fuze and e200v2.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: aaron424 on June 27, 2009, 12:05:17 PM
the fuze v2 does not even have a development version yet, right?
"Fuze v2
Sansafix at the Sansa forums has announced that a v2 of the Fuze has been released. There are no noticeable differences, but there is a different firmware version that is incompatible with V1 Fuze firmwares. Presumably based on an AS353x CPU like the ClipV2.

The v2 devices are in the wild. Attached are photos of the upperside of the board and the underside."
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on June 27, 2009, 03:07:28 PM
the fuze v2 does not even have a development version yet, right?

Correct.  See this page for an overview of whats done on each AMS device:

http://www.rockbox.org/twiki/bin/view/Main/SansaAMS
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on June 29, 2009, 07:59:53 AM
Hi all,

I have committed r21550 which fixes a problem in SD bank selection (also used at startup to enable access to the whole 1st bank).

If you still experience problems after updating to this revision please tell us, and precise if you see filesystem corruption or deadlock at startup.

To rule out problems with previous filesystem corruption, please format your player and reinstall rockbox before reporting.

P.S. I hope nobody will report any problem ;)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: notlistening on June 29, 2009, 09:20:33 AM
Hate to be the bearer of bad news. r21550 has not fixed the issues for me. I am using a e260v2 and I am getting file corruption on every disk write. I have tested with a brand new rockbox build, formatted using the OF and reloaded everything.

Firstly Database initialization hangs but speech continues to give uodates and back light etc are functioning.

Saving of setting changes are being kept but there are problems being made att he time of the filesystem. I also haveed my sound and theme settings in a .cfg file to disk.

I ran fsck before ruuning rockbox again and no wrrors and after testing the above features I got this output from fsck:

 fsck 1.41.4 (27-Jan-2009)
dosfsck 3.0.1, 23 Nov 2008, FAT32, LFN
FATs differ but appear to be intact. Use which FAT ?
1) Use first FAT
2) Use second FAT
? 2
/SANSA E2.60
  Contains a free cluster (3). Assuming EOF.
/SANSA E2.60
  File size is 8 bytes, cluster chain length is 0 bytes.
  Truncating file to 0 bytes.
/SYS_CONF.SYS
  Contains a free cluster (4). Assuming EOF.
/SYS_CONF.SYS
  File size is 316 bytes, cluster chain length is 0 bytes.
  Truncating file to 0 bytes.
/MUSIC
  Contains a free cluster (5). Assuming EOF.
/##MUSIC#
  Contains a free cluster (6). Assuming EOF.
/RECORD
  Contains a free cluster (7). Assuming EOF.
/AUDIBLE
  Contains a free cluster (10). Assuming EOF.
/PHOTO
  Contains a free cluster (11). Assuming EOF.
/VIDEO
  Contains a free cluster (12). Assuming EOF.
/##PORT#
  Contains a free cluster (13). Assuming EOF.
Reclaimed 48 unused clusters (1572864 bytes).
Free cluster summary wrong (120838 vs. really 123443)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on June 29, 2009, 10:04:56 AM
I've similar issues on my clip (the FS is totally broken after *very* few writes), but they're not related to rockbox (it's broken after using the OF too). So it might be as well a hardware issue as with my clip.

I'm going to test myself a bit too (my fuze functioned fine so far).

€dit: I just got the same fsck output as in the above post. But actually, those folders are created by the OF and I didn't touch them ever. I suspect the OF is just doing it's magic hackery with the filesystem, and that it's not a Rockbox issue.

PS: WTF is /SANSA E2.60 (or /SANSA FU.ZE respectively) for a folder. Did the OF mess up nameing the partition (could that be why linux doesn't see the Dap's name after a fresh reformat?).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on June 29, 2009, 05:54:23 PM
I have seen those names in the OF code but not sure what they mean.

The partition created by the OF has no label, I think linux has a builtin list of USB VID/PID to give a name.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: werich on June 29, 2009, 10:04:14 PM
Quote
I have committed r21550 which fixes a problem in SD bank selection (also used at startup to enable access to the whole 1st bank).

OK - at least I can only report good things:
I'm using the actual r21572 build, and it works like a charm on my Fuze 8GB including 8GB microSDHC.

No disc corruption so far (2hours of excessive testing across internal mem and microSD including mp3, ogg, mod and flac mix, crossfade, coverflow, mpegplayer video, radio etc.) and no broken filenames anymore. I didn't even had to reformat my fuze, just replaced the .rockbox folder. Aside from very few random freezes (once the radio after scan&save, once after inserting mod file into playlist) it seems quite stable to me.

Note: I checked the file system with chkdsk /f under windows, but "no errors" imply an intact FAT32, or?!

Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on June 30, 2009, 02:51:56 AM
Looks good!

I'll look at adding some code to see if freezes are related to SD driver.

Yeah I think "no error" imply an intact FAT32 filesystem ;)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: ku-ku on June 30, 2009, 04:57:43 PM
It still hangs when I try to delete some directories on an 8gb card or create a bookmark for some files but it seems that all the other problems have gone. A card has been formatted before trying this new build.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Hillshum on June 30, 2009, 06:54:20 PM
When I try to boot anything r21578 or later, my Clip won't get past the bootloader.
Edit: It's not that simple. I'm still figuring it out

Edit2: Looks like it happens at random between r21577 and r21580.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on July 01, 2009, 01:22:37 AM
I put in a fix for the bug in r21577 causing random lockups.  I think the input to the ADC was getting changed from CVDD while waiting for the voltage to be read and we were getting stuck in that loop.  The input to the ADC now gets set inside the while loop so if it does get changed while waiting it will be reset to CVDD the next time around the loop.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: notlistening on July 01, 2009, 05:03:07 AM
I have very poor sight and therefore pay more attention to what I am hearng. I have noticed when playing some audiobooks which are very quiet anyways that there seems to be another background sound behind the mp3 track. My first suspicion is that there is noise coming from the FM radio but it is soo quiet that i can not tell, but something is there and it is annoying.

I will produce a slient track and play it to see if i can pick up on the interferance in the background to help point to where it is comming from.
   
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on July 01, 2009, 07:07:56 AM
I have very poor sight and therefore pay more attention to what I am hearng. I have noticed when playing some audiobooks which are very quiet anyways that there seems to be another background sound behind the mp3 track. My first suspicion is that there is noise coming from the FM radio but it is soo quiet that i can not tell, but something is there and it is annoying.

I will produce a slient track and play it to see if i can pick up on the interferance in the background to help point to where it is comming from.
   

I haven't noticed that yet, but there are similar issues on the v1's. I guess you can't make cheap players while having a decent build quality which isolates background noises.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: mc2739 on July 01, 2009, 08:31:16 AM
It looks like r21577 is also causing problems with the microsd (at least on e200v2).  It works fine with r21576.  It was not corrected with r21584

Symptoms are:

1) power up with microsd inserted - <microSD1> shows under files, but no files are listed under <microSD1>. 
System -> Debug -> View disk info shows "Not Found!" for [micro SD1]. 
Removing and inserting microsd does not help or or cause a hang.

2) insert microsd after power up causes a hang (backlight thread stills functions).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on July 01, 2009, 08:32:34 AM
It looks like r21577 is also causing problems with the microsd (at least on e200v2).  It works fine with r21576.  It was not corrected with r21584

Symptoms are:

1) power up with microsd inserted - <microSD1> shows under files, but no files are listed under <microSD1>. 
System -> Debug -> View disk info shows "Not Found!" for [micro SD1].  Removing and inserting microsd does not help or or cause a hang.

2) insert microsd after power up causes a hang (backlight thread stills functions).

Can you try disabling interrupts in cpu_set_frequency()?

Upon inserting a MicroSD an interrupt is generated, changing the cpu frequency while that might cause problems.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: fragilematter on July 01, 2009, 09:01:19 AM
I can confirm that behaviour on an e250v2. Also, if you go into System ->Rockbox Info the MSD free space/capacity are shown correctly, so the microsd is accessed and it locks up when trying to view the contents...
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on July 01, 2009, 09:11:20 AM
I put in a fix for the bug in r21577 causing random lockups.  I think the input to the ADC was getting changed from CVDD while waiting for the voltage to be read and we were getting stuck in that loop.  The input to the ADC now gets set inside the while loop so if it does get changed while waiting it will be reset to CVDD the next time around the loop.

The fix is wrong, the adc input could still be changed in a tick interrupt happens after it was set and before it was read.

I suppose the battery readout is called from a tick task and change the ADC source but I didn't verify.

The correct fix like kugel suggested is to disable interrupts while waiting for the voltage change
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on July 01, 2009, 09:28:53 AM
I can't reproduce the problems on my Fuze. But I also never had problems with my MicroSD.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Hillshum on July 01, 2009, 11:22:59 AM
My Clip's working fine now!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: porio on July 02, 2009, 09:19:13 AM
My Clip's working fine now!
Please, could you be more specific? What build are you using?
I've tried builds 21578, 21593 and 21613 and still can't get past the bootloader. Old build 21506 works (as well as many other older than that), but with the known random freezing issues.
I formatted the device and that didn't make any difference.
The bootloader build I have is 21444, can that make a difference? I tried compiling the bootloader from source... well actually I did it, apparently the compling process was successful, my Clip did the firmware upgrade but then it didn't work. I got a little scared and had to go back to build 21444 of the bootloader. What could I have done wrong? Where (or how) can I get a 'good' recent bootloader build?
BTW, I have a 4Gb Clip (v1, of course)

Thanks!

Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on July 02, 2009, 09:28:58 AM
Yes, please update the bootloader before reporting problems with booting.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: porio on July 02, 2009, 09:38:01 AM
Yes, please update the bootloader before reporting problems with booting.
Thanks! Should I compile it from source or there is another way to get it?
(as I told before, my first attempt at compiling was unsuccessful, though I can try again...)

EDIT: I just compiled the bootloader from source version 21610. My Clip freezes at boot. Also, it can't boot to OF unless I plug it to the computer. May I have done something wrong?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Hillshum on July 02, 2009, 10:24:40 AM
I'm running r21579 for my bootloader with r21613 for the main build. Both work fine, with just the issue of playback stopping.

BTW, the playback crashes happen more on higher bitrates.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: porio on July 02, 2009, 11:29:34 AM
Yes, please update the bootloader before reporting problems with booting.
Thanks! Should I compile it from source or there is another way to get it?
(as I told before, my first attempt at compiling was unsuccessful, though I can try again...)

EDIT: I just compiled the bootloader from source version 21610. My Clip freezes at boot. Also, it can't boot to OF unless I plug it to the computer. May I have done something wrong?

UPDATE: My bootloader from version 21610 is working, just the dualboot is wrong (I must have done something wrong, I will try to read again the documentation but any help will be apreciated).
As for Rockbox itself, version 21506 runs fine but 21610 does not. After the boot screen, it goes black and the only way to get out of it is holding up the power switch for 10-15 seconds.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Hillshum on July 02, 2009, 11:58:16 AM

UPDATE: My bootloader from version 21610 is working, just the dualboot is wrong (I must have done something wrong, I will try to read again the documentation but any help will be apreciated).
As for Rockbox itself, version 21506 runs fine but 21610 does not. After the boot screen, it goes black and the only way to get out of it is holding up the power switch for 10-15 seconds.

The next step is to narrow down which specific revision it was that broke it. Figure it out by trying the revision halfway between 21506 and 21610, then if it works, try a revision halfway between that and 21610...

Hold down the left/prev button when turning it on to get the OF
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on July 02, 2009, 12:13:43 PM
BTW, the playback crashes happen more on higher bitrates.

The bug seems to be related to small buffer size, like when at some time the buffer needs to be filled but there is not enough room available.

This will happen on Clip/m200v4 and c200v2 because they only have 2MB of RAM.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: porio on July 02, 2009, 03:02:03 PM
The next step is to narrow down which specific revision it was that broke it. Figure it out by trying the revision halfway between 21506 and 21610, then if it works, try a revision halfway between that and 21610...
Build 21572 gets past the bootloader and works fine; builds 21583-21610 don't. I don't know how to get revisions between daily builds, but I don't think it's necessary because there was only one change for the Sansas that day.

Maybe the fix for FS#10344 didn't work for me?

Hold down the left/prev button when turning it on to get the OF
Yes, I didn't notice that the button had changed and was stubbornly doing it with the home button!!
Title: Everything seems to works on E260
Post by: Messerjocke on July 03, 2009, 03:35:26 AM
I've build and installed a fresh SVN checkout (r21619) on my E260 / 4GB SDHC; and for me everything seems to work stable and snappy. Even video playback.. superb!

You have done a great job  :)

Is there anything left where I could assist in testing/debugging?
Title: Re: Everything seems to works on E260
Post by: funman on July 03, 2009, 05:43:09 AM
Maybe the fix for FS#10344 didn't work for me?

You're right, FlynDice is working on it.

Is there anything left where I could assist in testing/debugging?

Not really, just report when you see a problem with storage (internal and/or µSD)
Title: Re: Everything seems to works on E260
Post by: sko on July 03, 2009, 09:16:39 AM
I've build and installed a fresh SVN checkout (r21619) on my E260 / 4GB SDHC; and for me everything seems to work stable and snappy. Even video playback.. superb!

You have done a great job  :)

Thats my opinion too. I'm very happy with my e250v2, everything works fine! Really a great job! I'm currently testing everything, but nearly no issues so far. I had one data abort with the following conditions:
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Hillshum on July 03, 2009, 09:43:02 AM

Thats my opinion too. I'm very happy with my e250v2, everything works fine! Really a great job! I'm currently testing everything, but nearly no issues so far. I had one data abort with the following conditions:
  • playlist with mp3 files followed by ogg files
  • last mp3 was on the last 10 % of time
  • I skipped the track and instead of playing the ogg file the player showed data abort
Have you been able to reproduce it at all?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sko on July 03, 2009, 09:48:31 AM
Have you been able to reproduce it at all?
Yes, but I have not tried other ogg files (didn't have more for testing), so I don't know if the file was corrupted. Imo this should be tested by someone else too, to make sure whether it is an rockbox issue or not. The mp3 files had 320 kBit/s and the ogg files 128 kBit/s.
Title: Re: Everything seems to works on E260
Post by: funman on July 03, 2009, 10:45:02 AM
I had one data abort

When you see a data abort, you should write down the address written on screen, and disassemble your current rockbox.elf (or the codec you use if the data abort is in the codec), to see which code does produce it.

Or you can come on irc to give the elf file + faulty address to a developer (it's a bit big to be attached to the forum thread)
Title: Re: Everything seems to works on E260
Post by: sko on July 03, 2009, 10:54:51 AM
When you see a data abort, you should write down the address written on screen, and disassemble your current rockbox.elf (or the codec you use if the data abort is in the codec), to see which code does produce it.

Or you can come on irc to give the elf file + faulty address to a developer (it's a bit big to be attached to the forum thread)
Yes, I'll do that next time. I'll try it again if I am at home, maybe it was related to the sd-bug and it has been fixed with the last commits (it happened before these fixes).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: fragilematter on July 04, 2009, 02:55:01 AM
Hey guys! Just a quick follow-up on the micro sd not working problem on (some of) the e200s. If it wasn't clear already, this problem is induced by FlyingDice's low core voltage patch.
I reverted system-as3525.c to r21282 (pre FS#10344) and the sd is working just fine.

I may come back with a week's worth of data aborts (if any) during this holiday. Cheers!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on July 04, 2009, 08:36:17 AM
Yes that's the same as MC2739 reports also.  I have had what seems to be the same problem in the past but I'm not experiencing it now.  Just to clarify, we're talking 8GB microsd on an e200 right?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: fragilematter on July 04, 2009, 09:17:03 AM
Nope, it's just a 1gig Kingmax micro-sd on an e200 (e250 to be precise). Dunno, some sd cards might need a more precise timing and the voltage switch is throwing the timing a bit off, just guessing here...
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Hillshum on July 04, 2009, 09:46:39 AM
My 2gb SanDisk (plain ole SanDisk, nothing fancy) uSD isn't working in my e260v2.

Also, test_disk has given me a couple of
*PANIC*
flush_fat_sector() - Could not write sector 321 (error -101)

with two different sectors on write & verify. I have gotten plenty of clean runs as well, though I suspect hardware issues.

Additionally, the database isn't updating itself like it should. I unplug from USB having transferred a bunch of files, boot into rockbox, and then need to reboot again to get the database updated.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: mc2739 on July 04, 2009, 10:16:40 AM
My card is a 4GB SanDisk brand. The player is an e260v2.

I also found that if I boost the CPU through the System -> Debug -> CPU Frequency screen and then insert the msd card, it works properly and can see all files on the card.  As long as the CPU stays boosted (i.e. CVDDP is 1.2V) the card will work.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on July 04, 2009, 10:47:14 AM
Apparently voltage scaling is responsible for breaking SD access on some Clips as well (thanks for dfkt for bug report).  We should probably revert it for now until we have a good fix and can have more people test it.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Hillshum on July 04, 2009, 06:18:45 PM


Thats my opinion too. I'm very happy with my e250v2, everything works fine! Really a great job! I'm currently testing everything, but nearly no issues so far. I had one data abort with the following conditions:
  • playlist with mp3 files followed by ogg files
  • last mp3 was on the last 10 % of time
  • I skipped the track and instead of playing the ogg file the player showed data abort
I'm getting about the same on my e200v2. It happens anytime a song of one codec ends and the thing tries to start the next song of a different codec. So far I've tried wma, ogg, and mp3. What happens varies. Sometimes I get a data abort message, sometimes a prefetch abort, sometimes it locks up and takes a hard reset (though some threads remain active).
Here's the two data abort addresses I wrote down:
6f6c4120
62694c20
PM me for my rockbox.elf

Edit: I can switch songs halfway through just fine (even with crossfade)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on July 04, 2009, 06:58:24 PM
Apparently voltage scaling is responsible for breaking SD access on some Clips as well (thanks for dfkt for bug report).  We should probably revert it for now until we have a good fix and can have more people test it.

I thought FlynDice has a fix for that?



Thats my opinion too. I'm very happy with my e250v2, everything works fine! Really a great job! I'm currently testing everything, but nearly no issues so far. I had one data abort with the following conditions:
  • playlist with mp3 files followed by ogg files
  • last mp3 was on the last 10 % of time
  • I skipped the track and instead of playing the ogg file the player showed data abort
I'm getting about the same on my e200v2. It happens anytime a song of one codec ends and the thing tries to start the next song of a different codec. So far I've tried wma, ogg, and mp3. What happens varies. Sometimes I get a data abort message, sometimes a prefetch abort, sometimes it locks up and takes a hard reset (though some threads remain active).
Here's the two data abort addresses I wrote down:
6f6c4120
62694c20
PM me for my rockbox.elf

Since 0x6******* is not a correct address on AMS, this clearly shows a bug in SD driver (when the codec is transferred from storage to RAM) / or memory corruption but this one is unlikely.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on July 04, 2009, 07:01:20 PM
I can confirm the codec bug but I get 0x3067C528.

Edit:  bah no .map files for svn builds anymore, i'll repeat it now for a local build so i can see what function that is.

Edit2:  Using my own build switching from MP3 to Vorbis gives 0x3067C648, which is in codec_main().  Random guess: we're not flushing something correctly when loading the codec.

Edit3:  We don't flush the icache when loading a new codec as far as I can tell.  This is a problem on ARM9 since:

Quote
Secondly the split cache introduces problems with self modifying code being first executed, then treated as data, manipulated and an attempt is then made to execute the altered code before it is flushed from the instruction cache.

Such code fragments will break.

Basically the instruction and data caches are not coherent, so I think we need to handle flushing the icache.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on July 04, 2009, 07:32:35 PM
Flushing the icache before calling codec_main fixes this problem for me.  I'll see about committing it now.

Edit:

Should be fixed in SVN.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: thund3rman on July 05, 2009, 09:43:32 PM
Hello,
I own a Sansa Fuze 4GB with an SD card of 4GB also. I've been using rockbox, but now I tried to update to the latest revision and I only get a white screen on boot. Bootloader seems fine because I can boot OF and I can see the first lines in the rockbox boot process. After loading the firmware, I see two or three more lines which I can't read (they scroll too fast) and then the screen turns white.

This happens with or without the SD card. The firmware was compiled following the instructions on the website.

I can't identify the latest working revision because I didn't save a copy, but at least by the time 3.3 was released rockbox worked ok on my Fuze.

Is this a known issue? How can I debug this problem?

Thanks
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on July 05, 2009, 10:04:08 PM
Its due to voltage scaling.  I get it sometimes on my Fuze.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: thund3rman on July 05, 2009, 11:02:05 PM
I get it everytime... Is there a way to fix this or a release which doesn't show the problem?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on July 05, 2009, 11:17:57 PM
I get it everytime... Is there a way to fix this or a release which doesn't show the problem?

Use an old build or revert the voltage scaling patch.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on July 06, 2009, 01:27:41 AM
Wow, that'll teach me to go away for the weekend...

For what it's worth I ran the fix that funman committed yesterday all weekend with absolutely no lockups on my e280v2.  I was waiting to see how this would hold up and, for me at least, it has been solid. I played off of my 8Gb microsd with no hiccups at all.  I see from the forum traffic and irc that this has not been the case for a lot of others though.

I cannot argue with Saratoga's recommendation to revert this for now, especially if the fix funman committed yesterday is still causing problems.  The benefit is solely longer runtime and the general useability problems it has been causing seem to outweigh the benefit right now.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on July 06, 2009, 01:28:50 AM
I cannot argue with Saratoga's recommendation to revert this for now, especially if the fix funman committed yesterday is still causing problems.  The benefit is solely longer runtime and the general useability problems it has been causing seem to outweigh the benefit right now.

Alright, then let's do it.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: jago on July 07, 2009, 08:24:51 AM
For information:

Sansa e260 (r21686)

In rare cases I experience deadlocks or last time a error (flush_fat_sector() could not write sector 479 (error-101)) while I am deleting files/folders on internal SD.
After rebooting I can delete same file/folder without problems.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: epithetless on July 07, 2009, 11:39:23 AM
For information:

Sansa e260 (r21686)

In rare cases I experience deadlocks or last time a error (flush_fat_sector() could not write sector 479 (error-101)) while I am deleting files/folders on internal SD.
After rebooting I can delete same file/folder without problems.

Does it still happen with a more recent build (post-r21687, when voltage scaling was disabled)?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: thund3rman on July 07, 2009, 05:46:51 PM
Thanks for that, now I can use rockbox again!:D
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: jago on July 08, 2009, 05:35:57 AM
Hallo,
just tried the latest revision and did some test_disk runs on it.
At a first glance it looks really good. Seems it was really the voltage scaling causing these errors.
But i keep an eye on it. Thanks.

Edit:
Unfortunatly this was not the solution. Nothing has really changed. The same errors like before. (Yes, I formated the SD before it.)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Hillshum on July 08, 2009, 11:56:15 AM
I'm still getting uSD lockups, even without voltage scaling. If I put my 2gb SanDisk card into my e200v2 while it's running, it will lockup when I try to open the file browser. If I boot while the card is in, it hangs on the boot screen.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on July 08, 2009, 11:58:30 AM
I'm still getting uSD lockups, even without voltage scaling. If I put my 2gb SanDisk card into my e200v2 while it's running, it will lockup when I try to open the file browser. If I boot while the card is in, it hangs on the boot screen.

What was the last revision the card worked with?

If you post in this very development thread, then please don't just post bug reports or problems. Help development or stop posting here.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on July 08, 2009, 06:49:08 PM
@Hillshum:

Have you tried reformatting the card?  I have had what sounds like the same problem and formatting the card made it work again.  This was pre voltage-scaling times i'm talking about now.

re: voltage scaling

I have been able to duplicate the condition described by MC2739 regarding the microsd card by taking the voltage down to 1.05v in my e280v2 but other than that I have no other progress to report but I'm still looking...
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: unemongod on July 08, 2009, 07:02:43 PM
I wonder if the voltage scaling for the CPU is affecting the uSD card voltage also.  That might explain why some cards seem more sensitive than others to the corruption.  Unfortunately, I am not yet familiar enough with this platform to confirm it, and I cannot afford to destroy my only fuze right now.  Maybe I can find a uSD interface adapter to put a VM on, anyone know of such a beast?


Also, I have noticed that the USB code does not differentiate between power and data connections, if I apply a charging voltage only, it reboots immediately into the Sansa FW.  I am also concerned that the fs is not being committed and closed cleanly when this happens.  Does rockbox use a sync or async filesystem?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on July 08, 2009, 09:01:30 PM
Also, I have noticed that the USB code does not differentiate between power and data connections,

Thats because we don't have a USB stack yet, so we don't have anyway to tell if a voltage on the USB lines is a device or a charger.

I am also concerned that the fs is not being committed and closed cleanly when this happens.  Does rockbox use a sync or async filesystem?

Rockbox uses FAT or FAT32 depending on volume size and how you've formatted it.  Why are you concerned thats its not closed correctly?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on July 09, 2009, 02:47:48 PM
Also, I have noticed that the USB code does not differentiate between power and data connection
 Does rockbox use a sync or async filesystem?

press center btn while connecting usb & rockbox will charge without rebooting

afaict rockbox uses sync filesystem but some storage i/o is multithreaded so the fs could be corrupted... in rare cases anyway
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Hillshum on July 09, 2009, 03:52:46 PM
@Hillshum:

Have you tried reformatting the card?  I have had what sounds like the same problem and formatting the card made it work again.  This was pre voltage-scaling times i'm talking about now.


It works now. Sorry for forgetting to reformat and then bothering you all
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: JdGordon on July 10, 2009, 12:49:32 AM
/me is rather late to the party...

funman, am I correct that buttons in the same column cant be used together as combos? i.e home+up on the clip?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on July 10, 2009, 01:38:55 AM
re:voltage scaling

Well, I've tracked it all the way down to bit 31 of the OCR register of the uSD card: Card power up status bit, line 279 of ata_sd_as3525.c.  I tried upping the max tries to 500 with no luck.

   "2) This bit is set to LOW if the card has not finished the power up routine."

So the card is not able to finish the power up routine with the processor core voltage at 1.05 and for some of us 1.10 it seems.  I cannot find anywhere in the datasheet where it would hint that CVDD would affect PVDD or IOVDD where I would assume we're drawing power for the SD card from.  There are settings for both of these peripheral voltages(AS3514_SYSTEM) but we leave them at their default(higher voltage) settings as far as I can tell.

I'll toil away a bit longer on this I guess.

Of course I'm learning all this as I go so please speak up if you've got a suggested direction to follow!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on July 10, 2009, 07:20:01 AM
@JdGordon : right

@FlynDice : if the card power up doesnt finish in N loops rockbox should just ignore the card no? (and not deadlock)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on July 10, 2009, 07:23:36 AM
@JdGordon : right

@FlynDice : if the card power up doesnt finish in N loops rockbox should just ignore the card no? (and not deadlock)

I rather think it should try harder.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on July 10, 2009, 02:10:01 PM
@funman:

I think we have 2 separate problems with the way voltage scaling was being implemented.

  I think the deadlocks were being caused by the loop that was waiting for the voltage reading to be >= 1.20v.  I believe using adc_read in the loop fixes that problem.

  There seems to be an additional unrelated problem with the uSD card power up at the lower CVDD settings for some reason.  The card will init fine at boot-up when CVDD is at 1.20v, and also if you force a boosted state through the debug menu, CVDD also at 1.20.  But whenever CVDD is low the card fails to power up.

  This leaves rockbox in a state where it thinks it has a microsd installed but coughs when it tries to access the non powered up card.  The fix you put in this morning helps it fail more gracefully but I think the problem to be figured out here is how to get the card to power up correctly with CVDD at a lower setting.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on July 10, 2009, 03:34:17 PM
The OF seems to use 1.10V for CVDD (on Fuze and Clip at least) so there must be something it does and we are not doing.

Do you still get µSD cards not working with CVDD voltage less than 1.20V ?

If yes which error code does the SD driver reports?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on July 10, 2009, 08:44:23 PM
My uSD card works fine at 1.10v but others were having what sounds like this same problem at 1.10v.  mc2739 described the problem quite well and it is just what I'm seeing when I take CVDD down to 1.05v.

sd_init_card() is returning a -2 now indicating a timeout on the card power up, also it is tripping the panicf down in the sd_thread.

EDIT:  I have tried goosing the voltage a bit on the uSD card and also adding extra delay between MCI_POWER_UP and MCI_POWER_ON with no change in the result.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: mc2739 on July 11, 2009, 12:16:58 PM
with r21780 and unboosted cvdd=1.05v on microSD insert I get:

*PANIC*
microSD init failed : -4


If microSD is inserted on boot, I do not get a panic, <microSD1> is listed under Files but no files or folders are listed under <microSD1>. Shortly after I enter <microSD1>, the unit locks (backlight timeout still works).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: jberkenbilt on July 11, 2009, 05:30:05 PM
This is my first post to the forums, though I've been a happy Rockbox user for some time.  I just got a Sansa Fuze v2 to replace my iRiver H320 which finally died.  I'm heartened to see that the v1 is starting to work, and am eager to see some progress on the v2 Fuze.  I would be willing to donate a v2 Fuze or make a PayPal donation to cover a device if it would help, and I would also be willing to try experiments with my device.  I have 20+ years of programming experience (though not a whole lot of free time) and an equal amount of Unix sysadmin experience, so making dd images of the flash, compiling builds, formatting the drive and recovering from data corruption, etc., should not be a problem.  I'll check back here from time to time to see whether there's interest in my offer to donate a device and to find out how to do that.  Is just making a donation in PayPal with a comment appropriate?  Thanks, and I wish the developers the best of success in getting the Fuze v2 into the fold.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on July 11, 2009, 05:50:09 PM
I just got a Sansa Fuze v2 to replace my iRiver H320 which finally died.  I'm heartened to see that the v1 is starting to work, and am eager to see some progress on the v2 Fuze.  I would be willing to donate a v2 Fuze or make a PayPal donation to cover a device if it would help, and I would also be willing to try experiments with my device.

I think someone here would be glad to accept a donation of a V2 Fuze.  Would you be willing to mail your new Fuze to someone rather then make a donation?  Its tricky to make sure someone buying a V2 Fuze for development actually gets a V2 Fuze (the last 3 I bought were all V1s).   And of course you might get lucky and get a V1 fuze and be able to start using it right away . . .
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on July 11, 2009, 06:30:12 PM
with r21780 and unboosted cvdd=1.05v on microSD insert I get:

*PANIC*
microSD init failed : -4

This means the send_cmd() failed, which is quite rare (we don't support recovery if sending a command failed, but this should be trivial to implement).

Can you check if the command fails because of a timeout or something else ? Just add panicf() in send_cmd() before the places where it return false.

If microSD is inserted on boot, I do not get a panic, <microSD1> is listed under Files but no files or folders are listed under <microSD1>. Shortly after I enter <microSD1>, the unit locks (backlight timeout still works).

It's a bit strange, I thought r21776 would remove the possibility of a deadlock ..
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: jberkenbilt on July 11, 2009, 08:11:03 PM

I think someone here would be glad to accept a donation of a V2 Fuze.  Would you be willing to mail your new Fuze to someone rather then make a donation?  Its tricky to make sure someone buying a V2 Fuze for development actually gets a V2 Fuze (the last 3 I bought were all V1s).   And of course you might get lucky and get a V1 fuze and be able to start using it right away . . .

Yes, I would be willing to do that, and I would also be willing to buy another one from the same place and ship it in its original packaging, etc.  Probably shipping mine is the least risky in terms of guaranteeing that whoever gets it gets a v2.  Where did you get your V1 from?  Maybe I should order one from there. :-)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: mc2739 on July 11, 2009, 11:12:48 PM
Can you check if the command fails because of a timeout or something else ? Just add panicf() in send_cmd() before the places where it return false.

The command fails with MCI_CMD_TIMEOUT (status = 4)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on July 12, 2009, 09:20:28 AM
Can you modify send_cmd to retry on error (at least 1 time) and see if it will eventually succeed?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: mc2739 on July 12, 2009, 05:03:08 PM
Can you modify send_cmd to retry on error (at least 1 time) and see if it will eventually succeed?

I tried this and still get the same timeout, although I'm not positive I did the retry properly.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on July 12, 2009, 06:47:21 PM
The SD spec says that if a command CRC check fails the card will not change its state, and no error recovery procedure is described (I understand that sending the command should be retried)

For some reason the transfer line will not function properly (see this post (http://forums.rockbox.org/index.php?topic=22137.msg153168#msg153168) about data transfers).

Can you attach your diff here so we can check if it's correct?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: mc2739 on July 12, 2009, 10:31:28 PM
Can you attach your diff here so we can check if it's correct?

Here is the diff I used to test (I had to rename to .txt to attach)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on July 13, 2009, 12:28:49 AM
EDIT: Don't waste a whole lot of time here, while it may not be precisely correct I think the code does what it needs to do.

@funman:

re SDHC determination:
  I've attached a flowchart I found on a webpage that illustrates the way I read the SD docs as far as SD_SEND_IF_COND (CMD8) is concerned regarding getting a response or not.  I can't say that this is the correct interpretation or not it just illustrates how I read the docs.  I found the following comment in ata-sd-pp.c which seems to illustrate the opposite interpretation:

    /* Check for SDHC:
       - non-SDHC cards simply ignore SD_SEND_IF_COND (CMD8) and we get error -219,
         which we can just ignore and assume we're dealing with standard SD.
       - SDHC cards echo back the argument into the response. This is how we
         tell if the card is SDHC.
     */

I believe this is incorrect.  I think the absence of a response indicates a non v2 card, which would of course be non hc but I think you could have a non hc v2 sd card that would give you a response with the correct voltage and check pattern.
 
The way I read the docs, the way we can tell if we've got an sdhc card is by sending acmd41 with the CCS(30) bit set to tell it the host can use hc, and then reading the CCS bit it sends back after power up to see if the card is hc.

Or am I missing something again....?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on July 13, 2009, 07:16:52 AM
mc2739 : your patch looks correct, I don't know what's the problem ..

Perhaps we should try to reinitialize completely the card when a problem happens, like ata-sd-pp.c does.

FlynDice: thanks for pointing this out, the variable sdhc should in fact be named sd_v2, since its only use is for setting bit 30 in acmd41 argument.

High Capacity or Standard Capacity is determined by CSD structure in sd_parse_csd().
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: jberkenbilt on July 14, 2009, 01:01:36 PM

I think someone here would be glad to accept a donation of a V2 Fuze.  Would you be willing to mail your new Fuze to someone rather then make a donation?  Its tricky to make sure someone buying a V2 Fuze for development actually gets a V2 Fuze (the last 3 I bought were all V1s).   And of course you might get lucky and get a V1 fuze and be able to start using it right away . . .

Yes, I would be willing to do that, and I would also be willing to buy another one from the same place and ship it in its original packaging, etc.  Probably shipping mine is the least risky in terms of guaranteeing that whoever gets it gets a v2.  Where did you get your V1 from?  Maybe I should order one from there. :-)

So, uh, how would I go about finding someone to accept the donation and figuring out where to send it to?  I could look at the svn logs to see who is working on this, or I could email the address to which PayPal donations are made, or I could wait to see if someone posts interest here in receiving it.  Or is there some different option?  I would very much like to make the donation to someone who is interested in getting the Fuze v2 to work, but don't worry...there are no strings attached.  I'm not going to suddenly expect quick results or even a change in priorities.  I do open source work myself and know how it works. :-) I don't even need to know who receives the donation as long as it goes to someone who will actually benefit from it.  If no response, I'll try emailing the address that receives PayPal donations and go from there.  Thanks!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on July 14, 2009, 01:23:58 PM
All developers working on the Sansa AMS port read this thread, so if one of them is interested he will likely step up.

I would gladly work on it, but i have already a lot of other priorities and I hope someone else will want to make work on Fuzev2 happen quicker.

One of those priorities is working on the Clipv2 port which is (hopefully) very similar to Fuzev2, just like Fuzev1 code is similar to Clipv1.

Some work on Fuzev2 has already been made, so the Fuzev2 is able to dual-boot, but there is still no LCD or complete buttons/wheel support.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: - on July 14, 2009, 04:39:54 PM
I've got rockbox (version: r21520M-090714 ) on my sansae200v2 :

-Bootloader works pretty fine.
-Even if the backlight from the WheelLight is disabled, when my sansa is "computing", it's lighting.
-There is no possibility of seeking an mp3 file.
-The database building is crashing.
-Except the "database crash", I don't have many crashes.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: jberkenbilt on July 14, 2009, 08:53:44 PM
A developer contacted me by private message, and we have arranged transfer of the device.  I'll be putting in the mail tomorrow so it can start it's journey across the Atlantic ocean, hopefully arriving before the Fuze v3 comes out. :-)  Thanks!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sko on July 15, 2009, 02:35:19 AM
I've got rockbox (version: r21520M-090714 ) on my sansae200v2 :

-Bootloader works pretty fine.
-Even if the backlight from the WheelLight is disabled, when my sansa is "computing", it's lighting.
-There is no possibility of seeking an mp3 file.
-The database building is crashing.
-Except the "database crash", I don't have many crashes.
I can't reproduce your problems, you should try again with a new build since 21520 is rather old (as currently 21877 is the latest revision).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: mc2739 on July 15, 2009, 10:24:11 AM
I've got rockbox (version: r21520M-090714 ) on my sansae200v2

It is not appropriate to post about bugs on modified builds. Please build from a clean and updated svn checkout and then verify that you are still having problems with that build.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on July 15, 2009, 07:33:15 PM
@mc2739:

      Would you post the cpu boosting voltage scaling fix you and kugel came up with a few days ago in irc on FS so we could get some more people to try it out?  It worked very well for me with CVVD at 1.05 volts and I would expect it to work very well at the 1.10 setting for everyone.

I would rather find a way to make the uSD card work without boosting but that's proving to be a bit difficult right now...
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on July 15, 2009, 07:34:14 PM
It was basically just boosting in sd_enable().
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: mc2739 on July 15, 2009, 08:13:51 PM
@FlynDice

Here is a link to the patch:  http://pastie.org/542480
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on July 15, 2009, 08:23:42 PM
This is the *developement* thread, not the *bug report* thread. Please move bug reports to the official test builds thread.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Hillshum on July 27, 2009, 10:53:28 AM
I assume I can post bugs with the Clip here, seeing as there is no test thread?

On my Clip, the moment I turn on crossfade, playback crashes. Disabling crossfade gets playback working again (I think a reboot is needed).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on July 27, 2009, 11:24:39 AM
debug -> buffering thread shows the audiobuffer is -244144 bytes (minus 238kB)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on July 27, 2009, 04:30:25 PM
I've been busy studying up on SD cards lately and thought I would pose some questions and observations here as this area seems to have quieted down.

In looking at the code it appears that we assume the internal card is simply another sd card that is embedded in the device.  I am speculating that perhaps this is not the case or they are different enough that they need to be treated slightly differently.

It appears we can access the embedded card using the NAND_BASE address and the pl180 offsets  so it is at least compatible in this way.  It seems to need a higher clock frequency to operate though.  Funman mentioned the OF targets 65 MHz for the embedded and 20 MHz for the uSD.

Saratoga tested the frequency for the SD card and found it running at PCLK speed (62MHz) which is too fast for the specand leads me to believe that PCLK = MCLK for the uSD card.  We need <=25MHz for standard speed and <= 50MHz for HS.  We have to divide MCLK to get the card clock speed MCICLK  so our choices here are actually PCLK/2 =31MHz for HS and PCLK/4 = 15.5 MHz for standard speed.  Saratoga said the OF uses 16 MHz for standard speed which is the OF PCLK(64MHz) / 4.

The other thing I've been thinking of here is that our embedded card is at least a consistent, fixed object, even if we don't completely know all of it's characteristics, and in fact it seems be less problematic than the uSD card.  On the other hand the uSD card can vary in size, speed, and specification and should require a bit more probing for card related info.

Also, I'm assuming we have 2 pl180's working here at the 2 base addresses or am I mistaken?

Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on July 27, 2009, 06:14:29 PM
I've been busy studying up on SD cards lately and thought I would pose some questions and observations here as this area seems to have quieted down.

In looking at the code it appears that we assume the internal card is simply another sd card that is embedded in the device.  I am speculating that perhaps this is not the case or they are different enough that they need to be treated slightly differently.

It appears we can access the embedded card using the NAND_BASE address and the pl180 offsets  so it is at least compatible in this way. 

Yes the internal storage is just a SD card, controlled by the 2nd pl180 controller (with NAND_BASE base address)

It seems to need a higher clock frequency to operate though.  Funman mentioned the OF targets 65 MHz for the embedded and 20 MHz for the uSD.

I only saw this info in a table used in clocking code, I can't tell for sure how that works (perhaps the MCI_CLOCK divider is different)


Saratoga tested the frequency for the SD card and found it running at PCLK speed (62MHz) which is too fast for the specand leads me to believe that PCLK = MCLK for the uSD card.  We need <=25MHz for standard speed and <= 50MHz for HS.  We have to divide MCLK to get the card clock speed MCICLK  so our choices here are actually PCLK/2 =31MHz for HS and PCLK/4 = 15.5 MHz for standard speed.  Saratoga said the OF uses 16 MHz for standard speed which is the OF PCLK(64MHz) / 4.

By the way the OF PCLK seems to be dynamic, but I still don't understand when/how pclk changes.


The other thing I've been thinking of here is that our embedded card is at least a consistent, fixed object, even if we don't completely know all of it's characteristics, and in fact it seems be less problematic than the uSD card.  On the other hand the uSD card can vary in size, speed, and specification and should require a bit more probing for card related info.

I tried in my tests to modify MCI_CLOCK and it always failed, but I didn't try to modify it only for µSD cards.

I should receive a problematic card by the post, I'll look again at the code when I'm able to reproduce problems with SD card.

Also, I'm assuming we have 2 pl180's working here at the 2 base addresses or am I mistaken?

You are right and not mistaken.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on July 28, 2009, 12:45:18 AM
I have used these 2 patches to test the SD behavior.

This patch leaves the internal SD alone and lowers the uSD frequency to 15.5 MHz.  I can navigate the files on the uSD but the files will not play.  I tried modifying the delays to get the files to play but have been unsuccessful so far.
http://pastie.org/561237

I believe this patch only enables the ide ahb interface & clock (CGU_IDE bits 6:7) for the internal card and not the uSD.  Rockbox runs just fine with the ide stuff disabled for the uSD.  If I disable it for the internal card though I get an SD transfer error....     
http://pastie.org/561241
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on July 28, 2009, 03:15:28 AM
This patch leaves the internal SD alone and lowers the uSD frequency to 15.5 MHz.  I can navigate the files on the uSD but the files will not play.  I tried modifying the delays to get the files to play but have been unsuccessful so far.
http://pastie.org/561237

Did you try with a 48MHz PCLK? So the µSD freq would be 24MHz (closer to 25)

I believe this patch only enables the ide ahb interface & clock (CGU_IDE bits 6:7) for the internal card and not the uSD.  Rockbox runs just fine with the ide stuff disabled for the uSD.  If I disable it for the internal card though I get an SD transfer error....     
http://pastie.org/561241

Hopefully this can save a bit of battery, but I think this should be discussed with the people designing the storage layer (gevaerts) because every target needs to be changed.

Note that we could make the code specific to as3525 by moving it from sd_enable()
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on July 29, 2009, 02:10:16 AM
Hopefully this can save a bit of battery, but I think this should be discussed with the people designing the storage layer (gevaerts) because every target needs to be changed.

I wasn't trying to save power with this but simply to investigate how this thing is put together...

The uSD works fine without clk_ide but the internal fails.
Do you suppose clk_ide could be wired into the internal pl180's MCLK?

I do not doubt your statement that the internal card is indeed just an SD card.  My thought is that unlike a uSD card that needs to respect a specification so it can be used with any number of other devices that also use that spec, our "internal sd" is hardwired into the device so the designer would have more control over how it is operated.

I don't know if any of this really matters all that much, I'm just trying to understand what's going on here.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on July 30, 2009, 08:45:22 AM
Do you suppose clk_ide could be wired into the internal pl180's MCLK?

No idea .. we know it's used somehow, but not in which way
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on August 04, 2009, 11:52:35 PM
This is an eMMC document but with all the similarities between SD and MMC it fills in a lot of the holes that are missing in the simplified SD 2.0 spec.

http://www.jedec.org/download/search/JESD84-A44.pdf
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: breno on August 09, 2009, 05:38:01 PM
Just installed Rockbox on my sansa c240v2 (r22231) and the system overall is working fine but with some major problems:
- When playing any music it plays for 1 second them crashes
- Volume buttons dont seem to work

Besides that, it's working:
- Radio is working (change volume in the menu)
- Microsd (it recognizes the files at least)
- Plugins (games work fine except for doom that gives me some z_malloc errors and them restarts the system)
- Display (seems to bem ok)
- USB Charge works (changes to OFW)
- Dual boot works fine (holding the right key when turning on)

I compiled it using cygwin.
Has someone got rockbox to work on c200v2 yet? which release was it?

thx guys!

Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on August 10, 2009, 02:52:38 AM
Hi, some things are still to be fixed on c200v2: see this page (http://www.rockbox.org/twiki/bin/view/Main/SansaAMS).

All these are known: only the button cross work (not volume -/+, hold, and rec), doom doesn't and will never work, playing music crashes.

What does the radio debug screen say ? (system -> debug -> radio), FM radio worked fine on my c200v2 when i tried it
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: breno on August 10, 2009, 08:21:00 AM
Hi, some things are still to be fixed on c200v2: see this page (http://www.rockbox.org/twiki/bin/view/Main/SansaAMS).

All these are known: only the button cross work (not volume -/+, hold, and rec), doom doesn't and will never work, playing music crashes.

What does the radio debug screen say ? (system -> debug -> radio), FM radio worked fine on my c200v2 when i tried it

Well actually the radio is now working, dont know why it wasnt working yesterday but somehow is working now.
Playing music still crashes. So why on the SansaAMS page it shows that Playback is working?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on August 10, 2009, 09:07:56 AM
PCM driver works fine, but there is a problem in rockbox generic buffering code, when there is only a few memory available (this is the case for clip, m200v4 and c200v2).

I added a red message in the comments for those 3 players.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: iudex on August 10, 2009, 12:34:47 PM
Is it possible to disable Crossfade to earn more memory?
(Did you understood this?:) )
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on August 10, 2009, 12:56:46 PM
Crossfading is already disabled, removing it completely from the compiled code would earn a bit of memory and prevent people enabling it from seeing crashes.

I would prefer to see if crossfading can be enabled at runtime by using audiobuffer size checks, perhaps someone can work on this when looking at the playback crashes on c200v2/clip/m200v4
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on August 10, 2009, 01:05:41 PM
Making it a compile time option controlled by the config-XXX.h files might be even better, since it would maximize the saved memory on low mem targets.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: breno on August 10, 2009, 01:28:30 PM
If you guys need someone to test something in the c200v2 build, I can compile a new build and see how it is working. And send the debug info for you guys.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: matsch on August 10, 2009, 04:52:48 PM
MP3 playing seems to be stable with PCLK 31 Mhz, FCLK 62 MHz and IDE_FREQ 31 MHz
for CLIP V1. At least I did not experience a runtime error while playing for some hours in
contrast to the 248/62/90 MHz setting.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on August 10, 2009, 05:25:40 PM
The playback stopping is a bug in buffering, not in clocking.

The clock speeds are the same on all other Sansa AMS models.

You can trigger the bug by using an even smaller audio buffer (using static unsigned char[A_LOT]; in firmware code for example)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: breno on August 11, 2009, 12:04:12 AM
I've noticed you have made some changes regarding low ram devices like mine in the latest releases. I've compiled the r22249.

Music playback is still the same, mp3 plays for a second them stops and flac dont even plays anything. After trying to play something i still can go back to the menu but the activity icon stays on and i cant do anything else (like going to fm radio) - this was already like this in previous builds, im just explaining how it is working on my c240v2.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on August 11, 2009, 02:25:43 AM
I posted FS#10507 (http://www.rockbox.org/tracker/task/10507) to flyspray tonight which lets me run my uSD card at 31 MHz which is within the SD specs.  I also ran it at 15.5 which would be the non-highspeed setting and it ran fine.

EDIT: Nevermind, this does not run at the lower freqs, the bypass bit is still set... :-\
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: matsch on August 11, 2009, 05:01:19 PM
Quote
The playback stopping is a bug in buffering, not in clocking.

If there is a bug in buffering, the frequency of runtime error caused by this bug depends on
clocking and audio buffer size. Difficult for me to understand why clocking has an effect.
 
 
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on August 11, 2009, 06:54:13 PM
If there is a bug in buffering, the frequency of runtime error caused by this bug depends on
clocking and audio buffer size. Difficult for me to understand why clocking has an effect.

He said clocking isn't related to it.

Did anyone try flyndice's patch with the problematic microsds, or impact to transfer rate?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: freqmod on August 14, 2009, 10:20:22 AM
If buffering is the problem then FS#9332, should fix it. (you'll have to change a strncpy to strlcpy  to make it compile).

I have tried it for a few minutes with an usage that results in the buffering problems w/o the patch and currently it works quite well. I got a codec error when i changed a track, but the next track started as usual.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on August 17, 2009, 01:10:34 PM
STOP POSTING BUG REPORTS IN THIS THREAD. THIS IS FOR DEVELOPEMENT.

Post them here instead: http://forums.rockbox.org/index.php?topic=22137
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: pixelma on August 17, 2009, 06:13:39 PM
What does the radio debug screen say ? (system -> debug -> radio), FM radio worked fine on my c200v2 when i tried it

Well actually the radio is now working, dont know why it wasnt working yesterday but somehow is working now.
Playing music still crashes. So why on the SansaAMS page it shows that Playback is working?

This reminds me of the early days of the c200 v1 port - the radio wasn't detected sometimes (reboot helped) or the tuner got confused sometimes (starting radio in the OF helped). There were a few related fixes but the former still happens to me, very very seldom though. All I'm saying is that it could either be a general problem - and/or something that already happened in a similar way during the c200 v1 development.

Sansa AMS developers: Feel free to remove this post if you don't think it adds something useful, or move.
Title: Testing Rockbox
Post by: krloz on August 22, 2009, 08:20:26 PM
Hello! I am new to this forum. I don't have the required level of developing knowledge for RockBox but I do have a Sansa E250v2 and really want to collaborate testing the new port! please tell me how can I test RockBox on mi device
Title: Re: Testing Rockbox
Post by: yapper on August 22, 2009, 08:25:59 PM
I do have a Sansa E250v2 and really want to collaborate testing the new port! please tell me how can I test RockBox on mi device

See this topic: http://forums.rockbox.org/index.php?topic=22137.0
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Orivej Desh on August 30, 2009, 04:00:06 AM
Hello there!

I've got Sansa Clip (v1) 2gb with FM radio and having a problem of black screen. When I turn the player on, I hear a quiet click in headphones but display remains black. Unlike matsch's (http://forums.rockbox.org/index.php?topic=14064.msg150808#msg150808), my display is completely black and when I plug in USB, nothing shows up on screen. This proves that something is running, because when I turn the player off, pluggin in USB shows standard connected/charging screen.

I tried to increase dcdc voltage as described here (http://forums.rockbox.org/index.php?topic=14064.msg151005#msg151005) with no success. (I have recompiled both rockbox and bootloader).

Dual boot doesn't work either. Neither repeated tapping on the |<< (or any other) button, nor holding it long has any effect. OF boots only after plugging and unplugging USB.

Tested with svn r22531 and gcc 4.3.3.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on August 31, 2009, 01:57:34 PM
Can some e200v2 owner test the two lastest patches I posted to http://www.rockbox.org/tracker/task/10272 please?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: X-Dan on September 11, 2009, 03:12:29 AM
Hi everybody!

And Thank you all for the great work you have all done :-)

I have just a question. I want to know if someone has or will implement the line out dock functionnality?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: iudex on September 12, 2009, 05:50:03 AM
One question:
Does anyone working on buffering problem on Clip?
I can test all your work.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: matsch on September 13, 2009, 02:24:16 PM
One question:
Does anyone working on buffering problem on Clip?
Please try patch #10605. Should give some playback improvement.
Side effect on changing form mp3 to ogg playing possible.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: cpnfantstk on September 13, 2009, 10:39:58 PM
Would patch #10605 apply to the M240v4 as well ?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on September 13, 2009, 10:49:06 PM
Yes, however I investigated 10605 tonight and I don't think it will make very much difference.  The first case it addresses shouldn't happen if you only listen to MP3, and the second seems to occur so rarely I was not able to encounter it. 
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: matsch on September 14, 2009, 08:55:47 AM
Yes, however I investigated 10605 tonight and I don't think it will make very much difference.  The first case it addresses shouldn't happen if you only listen to MP3, and the second seems to occur so rarely I was not able to encounter it. 
When I apply the patch to my clip, it makes a difference. In case of skipping a file manually, the codec (50kB) is loaded into the ring buffer. If it is not loaded a crash occurs less often. As to the second patch: How stable it is i cannot tell, but I had some album play with skipping and no crash occured. The albums crashed before the patch.
I like to point out, that the patch is not solution of the playback issue, but an improvement.
Understanding buffering.c is difficult. Especially moving a handle in the ring buffer with move_handle and buffer_handle
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on September 14, 2009, 11:02:44 AM
If you didn't see this already you might find it interesting:

http://www.rockbox.org/mail/archive/rockbox-dev-archive-2009-09/0049.shtml
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on September 21, 2009, 04:49:42 PM
I'm not really getting any good results while investigating the AMS Sansa SD
situation so I thought that I would just toss out some of my thoughts and observations
for your reading enjoyment.  Consider it fodder for future wisecracks perhaps or
maybe a futile gesture to the AMS Rockbox Gods to open my eyes so I may just
see what must plainly be there....

There are 2 different problems with the sd cards that I'm aware of:

1. We're running them too fast and out of spec at 62 MHz
2. I can read from the uSD but not write to it nor delete from it reliably.
    The Internal card works fine with both operations.
    I can copy a file USD -> INTERNAL  but not INTERNAL -> uSD
    I can read and play files from the uSD just fine.

Besides being removeable, the most obvious difference in the configuration
between the cards is that the uSD is connected to the bus through GPIOD.
I tried commenting out the GPIOD_DIR &= ~(1<<7) we use to keep the buttonlight
off on disk access with no luck.

My goal for awhile now has been simply to get the SD cards running below the
specification limit of 50 MHz.  I have been able to do this only by lowering
PCLK to below 50 MHZ as I cannot get any setup where MCICLK != PCLK to function
over the data pins.  The cards are set at 400 kHz for the ident mode and they
initialize just fine but that communication happens over the cmd pin and not over
the data pins. I believe the significant difference is the fifo involvement
with the data lines but I'm not sure about that.  The fifo should act as
a buffer between the two clock domains when PCLK != MCICLK so that is what
draws my attention here.The linux driver for the pl180 uses the fifo half
full and half empty interrupts for dma control and we don't. I thought
that having the pl180 control the dma transfers handled the fifo and
dma requests but I'm still trying to figure this part out.  I understand
what interrupts are and how they work(barely) but actually implementing them
is a bit beyond me at this point, if that's even the solution here?


Things I have tried with results/observations:

I'm not advocating using all these things it's just what I have tried...

I have been able to run the cards within spec from 30-50 MHz by lowering
PCLK to this range.  That's the only way I can do it.  The clock bypass bit
must be set, the cards will not work without it.

Omitting the SD_SET_BLOCKLEN command for initialization works fine.  We
assume a 512 for transfers and this is in fact the default value so issuing
this command is redundant.

I have been able to switch to high speed timings by using the SD_SWITCH_FUNC
command for both the internal and microSD cards with no problems.

I have been able to initialize the cards while running them at full speed
(62 Mhz) with no problems.  I believe the 400kHz Ident freq is a holdover
from MMC Cards.  We are sure we're dealing with an SD card because that's
all that fits.....  The SD spec does say you should send a 400 Khz clock
during the ident phase but I believe that's just for compatibility with
MMC cards.

I omitted the SD_SET_BUS_WIDTH command and can't notice a difference.  This
is the command to change from 1 bit to 4 bit data bus.  We have been issuing
this to the cards without changing the controller to 4 bit mode.  I cannot
get 4bit mode to work at all with the internal card but with the uSD I
can display folders and album art. I cannot play music though.  I adjusted
the burst size for pcm dma with no luck.

I enabled the synchronization logic for DMA and found no difference.  The
pl081 docs say the logic must be enabled if the peripheral sending the request
and the SDMAC controller are in different clock domains.

I modified the debug viewHW page to reliably display the sd freqs.  Because
we turn off the controllers between disk accesses you need a disk access
to get a reading.  Inserting the uSD will get you a reading.

I'm pretty much stalled out here so maybe someone else can help connect
the dots!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on September 21, 2009, 06:29:20 PM
Did you find anything that should be fixed in SVN regardless of the clocks? It looks like we should look into using the fifo for example.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on September 21, 2009, 11:44:05 PM
I don't think SVN needs to be changed until we figure out how to use the FIFO if that is indeed the problem.  Current SVN actually works quite well from a typical user point of view.  We can playback from either card just fine, we just know that the cards are overclocked and we can't write reliably to the uSD.  I bet 80 % of users would never notice themselves without being told...
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: yelped on September 22, 2009, 12:33:00 PM
I copied over files to my microSD card several times already, and I've never had any problems with it. It's a SanDisk 8GB Class 2 card.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on September 22, 2009, 03:38:54 PM
@yelped:

Which player?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: yelped on September 22, 2009, 06:44:05 PM
Fuze v1.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on September 23, 2009, 06:05:59 PM
Could I get some results from both fuzev1 and e280v2 with current svn copying a file from internal sd to microsd.  Please identify the make, class and size of the microsd also.

I'd like to figure out if this is a card related issue, or an e280v2 only issue.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on September 24, 2009, 02:53:26 AM
r22814 Fuzev1

internal -> µSD = SD transfer error : 0x2 (DATA CRC FAIL)
µSD -> internal = OK

Transcend µSDHC 4GB Class 6
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: mc2739 on September 24, 2009, 09:22:51 AM
r22814 e260v2

internal -> µSD = OK
µSD -> internal = OK

SanDisk µSDHC 4GB Class 2
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: notlistening on September 24, 2009, 10:36:38 AM
r.22077M - e250v2
& r. 22819 because i thought my revision was a bit old ;)

internal -> µSD = OK
µSD -> internal = OK

SanDisk µSDHC 8GB Class 2
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: j8048188 on September 24, 2009, 11:07:10 AM
r2273-090921
e280v2

internal -> µSD = OK
µSD -> internal = OK
Sandisk µSD 2gb class2

internal -> µSD = OK
µSD -> internal = OK
Sandisk µSD 512mb Class2
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on September 24, 2009, 12:11:15 PM
Thanks guys.

I'm assuming this is a problem with certain cards then and not players...

I have an 8GB Transcend class 6 µSDHC & get CRC failures similar to funman.

Sounds like the Sandisk class 2's work just fine.

Now can I get some results for Sandisk class 4 & 6  and non Sandisk any classes that don't work.

I'm wondering if this is a class 6 problem or perhaps Transcend.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: ku-ku on September 24, 2009, 01:33:35 PM
All the builds I've tried and the latest 22819

internal -> µSD = SD transfer error : 0x2
µSD -> internal = OK
Silicon Power SDHC 8gb class 6
Transcend 8gb SDHC class 6
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sko on September 24, 2009, 04:17:54 PM
r.22077M - e250v2
& r. 22819 because i thought my revision was a bit old ;)

internal -> µSD = OK
µSD -> internal = OK

SanDisk µSDHC 8GB Class 2
Same here with r22820.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: yelped on September 24, 2009, 06:32:54 PM
I tried again with my Fuze and 8GB SanDisk microSDHC Class 2 card, both ways, several files, and no problem. Thank G-d!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on September 24, 2009, 09:49:51 PM
I added a delay to writes to the microSD and my class 6 card works fine now.  Does yours....?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: ku-ku on September 25, 2009, 09:08:51 AM
It certainly works now ;D. I was able to create bookmarks now on my both cards without a single failure. Writing on my cards works too now. I am able to copy files from internal memory to sd card and deleting files and folder. Nevertheless one attempt of more than two dozen to delete different folders failed with "transfer error : 0x2" message, but after reloading a player I could delete this folder.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: musojon74 on September 25, 2009, 06:58:30 PM
Hey guys :)

Nice work on the development - Rockbox is working pretty awesome here :)

OK I've got a Fuze V1.  I'm using r22777-090921.  I have an Integral 16gb class 2 card - if I can run any tests which help with the sd corruption checking please let me know (I've been only playing stuff really and loading player with usb connect in OF mode).  Also, OT, let me know any other stuff you want me to try and test. Thanks again for all your hard work.

Muso
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Hillshum on September 25, 2009, 07:15:38 PM
Try writing files to the SD card from within Rockbox, as well as deleting and creating folders
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: musojon74 on September 26, 2009, 07:14:22 AM
Ok have created 10 folders in quick succession looking good.  Will copy some mp3s around now quickly and see if that breaks anything.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: ku-ku on September 27, 2009, 07:30:18 AM
I found out that I have more chances to get transfer error : 0x2 when I try to delete a folder in a
subfolder with very big number of folders (more than 100, in my case) on my both cards - transcend 8gb class 6 and silicon power 8gb class 6.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on September 28, 2009, 12:06:09 PM
flyndice have you tried reading the extended status register ?

it should be acmd13, then read the status on data line (using DMA)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on September 28, 2009, 06:17:44 PM
I tried reading that with your patch that used DMA and have not been able to get that to work yet.

I still can't  get the cards to operate without the bypass bit set.

I can set high speed timing with no problem.  In fact, changing to highspeed timings allowed me to copy a single file from the internal to the uSD card without the delay I added recently, but any copy with a directory involved would fail.

I have partial operation on both cards with 4 bit widebus.  I can browse files and display album art but cannot play music off of a card in widebus mode.  It seems that the transfer never stops.  In View I/O ports you can see the sd card transfering data on the GPIOD display.   The 4 lsb's are the 4 data bit pins.

I have added a few things to the dma driver and now have normal playback without changing the AHB priority with  CCU_SCON = 1 in system-as3525.  I have this line commented out and my player is playing normally.

I have been spending today trying to understand wakeup's and dma_callback today without much luck so far but I haven't spent a whole lot of time on this yet.

I'll post some patches later tonight or maybe tomorrow, I've got 170 people waiting for me to take them to San Francisco in 20 mins.....







EDIT:  @ku-ku:  I changed the delay to a check for FIFO activity which should handle your large number of folders.  Would you test and let us know?

Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: ku-ku on September 30, 2009, 10:24:47 AM
I could replicate the error trying to delete some folders before r22850 patch was committed. With r22850 patch I have no errors at all. It seems it works perfectly now.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: epithetless on September 30, 2009, 05:04:05 PM
Just so I can get a wider perspective on the issue: Are other Fuze owners seeing sporadic LCD glitches, where the entire screen distorts for a split-second and then returns to normal? I've noticed this ever since I began using Rockbox on my Fuze in early July, and it has persisted up through the most recent builds (I'm on r22850 at the moment). I find it happening most after I've just returned to the WPS from the file browser, or shortly following an unlock of the hold switch -- both with music playing -- but I haven't found a reliable way of prompting it. Is this behavior isolated to my device or is it just some of the Fuze's "unstable" status showing through?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on September 30, 2009, 05:16:14 PM
Its really easy to see in mpegplayer on my Fuze.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: epithetless on September 30, 2009, 05:21:59 PM
Its really easy to see in mpegplayer on my Fuze.
Okay, so it sounds like some kinks in the display still need to be worked out. Glad it's not just my unit!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on September 30, 2009, 06:21:41 PM
Its really easy to see in mpegplayer on my Fuze.
Okay, so it sounds like some kinks in the display still need to be worked out. Glad it's not just my unit!

http://www.rockbox.org/tracker/task/10603 fixes that. The problem is that the hold button can't be read for some reason.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: yelped on October 01, 2009, 11:16:01 AM
Its really easy to see in mpegplayer on my Fuze.
Okay, so it sounds like some kinks in the display still need to be worked out. Glad it's not just my unit!

http://www.rockbox.org/tracker/task/10603 fixes that. The problem is that the hold button can't be read for some reason.

I never use the hold button, and I get occasional LCD Glitches.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: epithetless on October 01, 2009, 12:01:30 PM
Its really easy to see in mpegplayer on my Fuze.
Okay, so it sounds like some kinks in the display still need to be worked out. Glad it's not just my unit!

http://www.rockbox.org/tracker/task/10603 fixes that. The problem is that the hold button can't be read for some reason.

I never use the hold button, and I get occasional LCD Glitches.

I think what kugel means is that the patch which fixes the LCD glitches has the side-effect of rendering the hold switch inoperable on the Fuze.


On a different note:

Is anyone else seeing a decrease in scroll wheel accuracy on their Fuze following the commit of r22863 (http://svn.rockbox.org/viewvc.cgi?view=rev;revision=22863)? Quite often now, when scrolling through a list, my pointer jumps 1 step in the opposite direction of the way I was scrolling at the very end...
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Dhraakellian on October 01, 2009, 11:12:23 PM
Is anyone else seeing a decrease in scroll wheel accuracy on their Fuze following the commit of r22863 (http://svn.rockbox.org/viewvc.cgi?view=rev;revision=22863)? Quite often now, when scrolling through a list, my pointer jumps 1 step in the opposite direction of the way I was scrolling at the very end...

I can confirm this (using r22864).  Good to see I'm not going mad the only one experiencing this.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Joe Blow on October 02, 2009, 12:16:45 AM
Quote
Is anyone else seeing a decrease in scroll wheel accuracy on their Fuze following the commit of r22863 (http://svn.rockbox.org/viewvc.cgi?view=rev;revision=22863)? Quite often now, when scrolling through a list, my pointer jumps 1 step in the opposite direction of the way I was scrolling at the very end...

I found my scroll wheel accuracy decreased.

Running rev 22864, Sansa E280 v2

I didn't spend a lot of time playing with it, but I noticed it just didn't feel right.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on October 02, 2009, 06:13:33 AM
I think it's more fluently for fast scrolling, but it's possible that I didn't think enough about slow scrolling. I'll have a look.

May I remember you again? This thread is not a support channel. It's for development. Please stop flooding the thread with questions (and answers...) about installing and sort of.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: epithetless on October 02, 2009, 11:05:39 AM
I think it's more fluently for fast scrolling, but it's possible that I didn't think enough about slow scrolling. I'll have a look.

Thanks.

May I remember you again? This thread is not a support channel. It's for development. Please stop flooding the thread with questions (and answers...) about installing and sort of.

If that includes my posts about my experiences with LCD glitches and scrolling accuracy, I apologize. I thought they were sufficiently "development-oriented." If not, where -- now that the "Official Test Builds" thread has been closed -- is the appropriate place to raise and discuss issues like that?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: mc2739 on October 02, 2009, 12:01:31 PM
where -- now that the "Official Test Builds" thread has been closed -- is the appropriate place to raise and discuss issues like that?

Any issues with the Fuze and e200v2 should be reported on the Flyspray tracker.

Issues with any other of the AMS models (clip, c200v2, etc) should be reported in this thread only if it has not been previously discussed.  There is no benefit in posting additional reports on issues that the developers already know about, unless there is information that could be useful in correcting those issues.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: epithetless on October 02, 2009, 12:06:47 PM
where -- now that the "Official Test Builds" thread has been closed -- is the appropriate place to raise and discuss issues like that?

Any issues with the Fuze and e200v2 should be reported on the Flyspray tracker.

Issues with any other of the AMS models (clip, c200v2, etc) should be reported in this thread only if it has not been previously discussed.  There is no benefit in posting additional reports on issues that the developers already know about, unless there is information that could be useful in correcting those issues.

Understood. Thanks.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on October 04, 2009, 01:35:14 PM
I used a bit my Fuze with the class 6 Transcend SDHC without problems.

Do any of you have a problem to report about storage with a current build ?

The release candidates builds of mkamsboot had no bug report so they work fine, the code changed a bit since then but there were no functional changes so we can rebuild it and label it 1.1 final.

I will have a look again at recording (fs#10371)

There are some patches floating around where you could help:

One more thing is needed for Fuzev1/e200v2 : finish the manual (AlexP started working on it, I'm not sure if there he opened a patch on the tracker yet)

My opinion is that once the manual is finished we can label Fuzev1 and e200v2 as stable.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: HankB on October 05, 2009, 12:42:24 PM
Any issues with the Fuze and e200v2 should be reported on the Flyspray tracker.
Where can I find guidelines for doing this in a manner that will be most useful to the devs?

I just decided that I would be more helpful if I kept a recent release loaded on my Fuze and reported any difficulties I encounter rather than try to find the most stable one and let others test the bleeding edge.

I just loaded r22777-090921 and believe I provoked a deadlock by inserting a microSD card and going to Rockbox -> Files. The player became unresponsive to further input except to bring the screen back after it turned off. I was able to power down after holding the power slider to "off" an extended time.

I just checked the bug tracker and searching for Fuze, only found one entry.

Thanks again for all of the effort you folks put into this.

best,
hank

Edit: found guidelines at http://www.rockbox.org/wiki/FlySprayHowto

But I am unable to reproduce the problem.  :(
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on October 05, 2009, 01:26:19 PM
I just loaded r22777-090921
You shouldn't report any issues with an outdated build, always use the current build (available from the left menu on the website)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on October 09, 2009, 05:25:31 PM
I posted a patch to http://www.rockbox.org/tracker/task/10667. tell me if it improves things please (most importantly on the e200v2).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on October 09, 2009, 11:28:51 PM
I just posted FS#10669 (http://www.rockbox.org/tracker/task/10669) to try to implement voltage scaling once again.  I made the assumption that the problem remaining with the previous implementation was a microsd card issue but I would also be  interested how it performs on the clip as there were some bug reports on that last time.  I have purposely set the reduced voltage on the low side to coax the bugs out if they are there...    Feedback on Flyspray appreciated!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: daniel_at on October 10, 2009, 07:13:00 AM
Hello,

just short notice:

I d/l the latest fuzeV1 ( http://forums.sandisk.com/sansa/board/message?board.id=sansafuse&thread.id=33874 )  original firmware, and found that the SVN-mkamsboot does not know this version (1.2.28). I tried it, patching, booting (OF and RB) works. On a 8GB, Fuze V1.

Code: [Select]
Index: mkamsboot.c
===================================================================
--- mkamsboot.c (Revision 23063)
+++ mkamsboot.c (Arbeitskopie)
@@ -196,6 +196,7 @@
     { MODEL_FUZE,   "1.01.15", "df0e2c1612727f722c19a3c764cff7f2" },
     { MODEL_FUZE,   "1.01.22", "5aff5486fe8dd64239cc71eac470af98" },
     { MODEL_FUZE,   "1.02.26", "7c632c479461c48c8833baed74eb5e4f" },
+    { MODEL_FUZE,   "1.02.28", "5b34260f6470e75f702a9c6825471752" },

     { MODEL_C200V2, "3.02.05", "b6378ebd720b0ade3fad4dc7ab61c1a5" },


Daniel
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on October 10, 2009, 07:22:07 AM
thanks for testing daniel, it's r23067 (one day too late for mkamsboot 1.1 though)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: yelped on October 12, 2009, 11:15:33 PM
What's wrong with the mp3encoder included with Rockbox? It outputs a lot shorter files with squeaky voices. Does this happen on all targets, or only on the Fuze? If so, why?

Thanks a lot for the great work.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on October 13, 2009, 02:33:05 AM
@funman

re ata_sd_as3525.c:   Tell me if I'm understanding correctly

line 130  #define UNALIGNED_NUM_SECTORS 10

738        if(transfer > UNALIGNED_NUM_SECTORS)
739            transfer = UNALIGNED_NUM_SECTORS;
740        if(write)
741            memcpy(uncached_buffer, buf, transfer * SECTOR_SIZE);

It seems we are using transfers of at most 10 sectors(1280 Byes), memcpy to uncached buffer, then dma uncached buffer to MCIFIFO(drive).  I assume this is so the dma can use an uncached, aligned buffer.
I hope this is a silly question ;),  if we're going to end up memcopying the whole thing to the buffer anyway, why don't we just memcopy to the FIFO in the first place...?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on October 13, 2009, 04:26:06 AM
Good point.

We also do a memcpy from MCIFIFO when reading to use an aligned & uncache buffer to be sure the data cache in synchronized with memory (no data in the cache).

Ideally we would only use aligned buffers and sizes multiple of 32 (cache size) and use cache invalidating functions but we would need to check all calls to storage_(read/write)_sectors. You could keep an eye on FS#9708 because I think that's exactly what they are doing.

When we were not using DMA but direct copy from/to the FIFO in the isr we sometimes had problems where we wouldn't be fast enough to fill/empty the FIFO and transfer would fail. Now perhaps the situation changed since the icache is enabled.

I think we should wait until DMA is enabled on PP and remove the memcpy, I just assume DMA is faster than a FIFO copy in the isr. Of course feel free to make benchmarks ;)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: bony on October 14, 2009, 09:31:16 AM
I get an error * Panic * SD transfer error: 0x8 when I try to initialate the database.

Sansa e260v2
r23166-091014

Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on October 14, 2009, 10:52:43 AM
Do you have a µSD inserted ?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: bony on October 14, 2009, 11:27:38 AM
It crashes whether the µSD is inserted or not.

It counts up to about "127xx found" and crashes (there a about 450 music files on the internal disc).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on October 14, 2009, 11:39:26 AM
Does checking the filesystem (chkdsk.exe / fsck.vfat or dosfsck) help?

Or deleting database_tcd.* ?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: bony on October 14, 2009, 02:37:45 PM
chkdsk.exe did it. Thank You!
And it works much better, than the original db. Nice work, respect! :-)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on October 14, 2009, 03:12:49 PM
I'm hoping this could be due to invalid FAT filesystem leading to transfer_sectors request for invalid sectors.

However I can not be sure of that.

Ideally we would check that the sectors requested do fit in the size of the block device, but we do not know the number of blocks for 4GB and +

The size reported by CSD register is the size of 1 bank and we do not know the number of banks.

I have not found how the OF deals with this (and it HAS to deal with it for USB MSC), so I suggest these:

Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on October 16, 2009, 02:36:08 AM
Looks like another rocky road for voltage scaling:

Fuze Whitescreen Report (http://www.rockbox.org/irc/log-20091016#06:17:41)

Any ideas?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on October 16, 2009, 08:26:09 AM
hmm.. perhaps he can try with 1.15V
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: LiquidAcid on October 16, 2009, 10:34:44 AM
Hi, I just updated my Fuze to r23201-091016 and I'm also experiencing this whitescreen issue. I can see the bootloader output, but after that the screen turns white. Kinda looks like the lamp application is loaded :D
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on October 16, 2009, 10:40:55 AM
Hi, I just updated my Fuze to r23201-091016 and I'm also experiencing this whitescreen issue. I can see the bootloader output, but after that the screen turns white. Kinda looks like the lamp application is loaded :D

With, or without microsd inserted?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on October 16, 2009, 10:41:46 AM
Hi, can you try this build ? I changed the low voltage to 1.15V instead of 1.10
Code: [Select]
$ cat rockbox.sansa.bz2.?.txt > rockbox.sansa.bz2
$ bunzip2 rockbox.sansa.bz2
$ cp rockbox.sansa /path/to/.rockbox

EDIT: removed binaries since .txt attachments get line endings changed by server ..
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on October 16, 2009, 10:48:23 AM
I was wondering how this is possible if we use the same setting as the OF.

Is the microsd detection somehow failing at boot? Or maybe we don't wait long enough between settting the voltage and boosting.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: LiquidAcid on October 16, 2009, 10:50:07 AM
With, or without microsd inserted?
It doesn't matter for me whether the card is inserted or no. I have a SanDisk 8GB microSDHC card, not sure about detailled specs.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on October 16, 2009, 10:51:18 AM
I was wondering how this is possible if we use the same setting as the OF.

Are you sure the OF use 1.10V ?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: LiquidAcid on October 16, 2009, 10:54:25 AM
Hi, can you try this build ? I changed the low voltage to 1.15V instead of 1.10
Code: [Select]
bunzip2: Data integrity error when decompressing.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on October 16, 2009, 10:59:34 AM
server adds crlf to .txt files ..
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: LiquidAcid on October 16, 2009, 11:03:24 AM
Nope, doesn't work for me. Displays still turns white once the bootloader is through. Again tested both with and without the microSD card.

EDIT: Just logged into IRC, same nick as here. In case you want me to test some more without spamming the board.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: epithetless on October 16, 2009, 11:34:40 AM
With the thought that this may not yet be known and may aid in development:

I am able to bypass the whitescreen on my 8GB Fuze v1 once it appears by repeatedly pressing the Play button. The time (and number of presses) it takes varies. The menu then displays normally. However, there is tremendous lag in player response time after this point, to the degree that it makes operation unfeasible. I don't know if this behavior is merely a result of the distressed loading process, but perhaps someone with more coding savvy will find the information useful...


[I've edited the above post to provide more detail. The procedure (repeatedly-pressing-Play-to-bypass-the-whitescreen) seemed more effective with r23199 than with the most recent build (r23203), but it still works after a fair amount of button pressing.]
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: LiquidAcid on October 16, 2009, 11:37:45 AM
At what point exactly do you press play? Does it matter how long the whitescreen is already displayed?

I'm asking because I can't seem to reproduce this. Pressing play doesn't give me the normal menu screen on my Fuze v1.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on October 16, 2009, 12:38:47 PM
@ Those with fuzes getting white screens:

Would you please try changing line 369 in system-as3525.c from CVDD_1_10 to CVDD_1_20.
  This keeps the voltage scaling code in place we just don't lower the voltage to 1.10 volts, it "changes" it to 1.20v where it already is.

If this solves the white screen would you then try going back to CVDD_1_10 and then comment out line 342:
        while(adc_read(ADC_CVDD) < 480)
  This is the check that the voltage has returned to 1.20 before we boost the frequency.

If that works uncomment and I would be interested if changing the value from 480 to either 470 or 460 works.
  This cheats down just a little bit from the 1.20V we're looking for.

Thanks!

EDIT:
I've lowered the voltage check to 1.175 volts and it seems to do the trick.
Thanks liquidAcid for all the testing!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on October 16, 2009, 02:58:39 PM
I was wondering how this is possible if we use the same setting as the OF.

Are you sure the OF use 1.10V ?

That was according to you. Use looked at the disassembly and told that :)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on October 19, 2009, 12:02:22 PM
I think I've figured out the CLKIDE link.  I think CLKIDE is MCLK for the pl180 controller for the internal SD.  I ran test_disk on the internal SD with IDECLK at 82 MHz, 62MHz, and 24 MHz and I think the results point strongly to this conclusion.  See the attached file.

I'm not looking for agreement here, I'm looking for reasons to disprove this hypothesis!
Fire away.


Edit:
Assuming this is correct I have been able to run the internal at 24.8 MHz and it works fine but feels a bit sluggish.  Once again I cannot run data without the bypass bit set so I can't run the controller MCLK at 49.6 and divide by 2 to get MCICLK = 24.8 MHz. I have to run the controller at 24.8 MHz and that slows things down...

Another thought is that we are overclocking the internal card much more than we thought.  The internal card is a v1(I tested on my e280v2 and I'm assuming the same for the rest of the as3525's) and , in fact will not accept the switch to HS timings. Which means the spec frequency is 25 MHz max.  We're currently running at 82 MHz MCLK with bypass meaning the card is being clocked at over 3 x the maximum!!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on October 21, 2009, 08:07:16 AM
The slowdown is a bit less than 50% so that looks OK.

We should compare to the OF transfer speed in USB mode
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Urutoraman on October 21, 2009, 09:24:36 PM
Is this the right forum to post?
I was using Rockbox fine on my e280v2 for a week and decided to load the current build 2 days ago. Now I am getting this *PANIC* SD Transfer Error: 0x8 all the time. r23313. 

Have an A-Data MicroSDHC with 4GB.

Weird part is that if I navigate through the Database menu I can get songs to play from the microSD card but after a few minutes it skip and I get the SD Transfer error again.

Tried a chkdsk but it didn't found any issues on the SD card.

Any thoughts?

By the way... Good work.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on October 22, 2009, 12:17:18 AM
Have I done this correctly?  I tried to add ISR INT_MCI1 and INT_IDE to demonstrate that MCI_MASK1(INTERNAL_AS3525) is masking for INT_IDE.  I made  MCI_MASK0(drive)=0 and MCI_MASK1(drive) = MCI_ERROR | MCI_DATA_END(ie I swapped them).  My aim was to run the code using the two Mask1 registers(replacing the current MASK0 registers) to show that the internal drive MASK1 is doing masking on INT_IDE.  Rockbox operates quite normally this way but is my logic sound enough to draw this conclusion?

Yes I know we don't need them right now but I'd like to understand how these things are put together better..... ;)

see http://pastie.org/664619

EDIT:

@ Urutoraman

I would be interested in knowing what system/debug/View disk info reports for the Speed of your card.
The internal is displayed first then if you push the select button it should cycle through your disks.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on October 22, 2009, 06:45:59 AM
flyndice: my way to be sure my code runs is to add a panicf() in the isr ;)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Urutoraman on October 22, 2009, 09:21:59 PM
EDIT:

@ Urutoraman

I would be interested in knowing what system/debug/View disk info reports for the Speed of your card.
The internal is displayed first then if you push the select button it should cycle through your disks.
Here it is

D% Rev 1.9
Prod: 0/2008
Ser#: 0x193025CB
M=1D, 0=AD
Blocks: 0x00775400
Speed: 50Mbits/s
Taac: 10.0ms
Nsac: 0 clk
R2W: *2
IRMax: 10.45mA
IWMax: 100.200mA

 
Update:
r23327-091024 Let me go into Files-><microSD 1> and browse the directories without any error.  But once I choose a song it play for some minutes and then BANG!! *PANIC* SD Transfer Error: 0x08.   Or sometimes it just a black screen and a player reset.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on October 25, 2009, 12:11:15 AM
@ Urutoraman:

Would you be able to go back and try r23192?  That's just previous to the reimplementation of voltage scaling...


@funman:

Well that was too easy, thanks.  MCI_MASK1 for the internal does indeed mask INT_IDE.  I'm just trying to provide some comic relief with my Rube Goldberg coding tendencies...
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on October 25, 2009, 07:07:44 AM
Well that works too :P

About IDE: in system-as3525.c:  system_init() we have this:
Code: [Select]
CCU_SRC = 0x1fffff0 & ~(1<<18); /* FIXME */
bit 18 is the reset bit for an IDE peripheral (there is 2), the internal SD doesn't work if we reset the peripheral, perhaps you have an idea of what we could do to configure it again properly after reset?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Urutoraman on October 25, 2009, 11:34:20 AM
@ Urutoraman:

Would you be able to go back and try r23192?  That's just previous to the reimplementation of voltage scaling...

If you can point me out where to download it from.  I overwrote mine by mistake.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on October 25, 2009, 03:43:21 PM
Well, you can't download it you would need to build it.

You said you tried chkdsk, did you also try formatting?


EDIT:
RE: MCLK for internal SD = IDECLK

I believe I've proved this hypothesis wrong now or at least not completely correct.  While trying to change the references to CGU_NAF_CLOCK_ENABLE to IDE_CLK_ENABLE I found that the MCI_CLOCK register(MCI_NAND on p2 of View HW info) was not being disabled(ie 0x00000000) while there was no disk access.  I think I was lucky and the CGU_NAF_CLOCK_ENABLE is enabled in the bootloader so when I took out the references to it I just kept it from being shut down during sd_enable(false).  This seems to confirm that MCLK does indeed come from PCLK for the internal disk also.

I will revert r23350  shortly as that assumes IDECLK is used as MCLK for the internal disk..
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: NaFIann on October 26, 2009, 11:58:01 AM
Hi, I don't know if this is the right place, but I just wanted to inform you guys that there is a new OF for sansa fuze out in the wild, that mkamsboot doesn't want to work with.
(link (http://forums.sandisk.com/sansa/board/message?board.id=sansafuse&thread.id=33874))

Also, thanks for all the hard work - I am installing rockbox on my V1 fuze now (was a big fan of it on my V1 e270) and going to give it a test run. I'll post my findings here :)

[edit]
Preliminary findings:
- also having problems with a horizontal line right underneath the status bar in the main menu 'flickers'; it sometimes turns to black or some colour.
- a few lines of pixels at the top of the screen are eclipsed by some of the lacquer when you look straight at the screen. This is not really the fault of rockbox itself, but does present a ui problem: if you leave it to theme developers to workaround, some of the plugins (games for example) will have a few 'hidden' pixels, but the only other obvious fix is to have some pixels on always off and pretend the screen is smaller than it really is. I don't have a good solution to this, but just thought i'd throw it in the group here.

All else: music playback, sd card, fm tuner, scrollwheel etc. work fine for me so far.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on October 26, 2009, 02:11:23 PM
Hi,

We don't plan to make new releases of mkamsboot for every new OF release, so mkamsboot 1.1 will reject Fuze OF *.28, you'll have to wait for the next release.

Alternatively you can build mkamsboot from SVN (this OF has been tested and its checksums committed), or wait the next release of the rockbox utility (which will accept this Fuze OF), or use *.26 version or older.

About the missing pixels, this can change between different models because of bad case design : I can see all the pixels on my own Fuze, but previous Fuzes I had exhibited this problem.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: OldOne on October 27, 2009, 01:12:21 PM
Hello,

My experience with recent releases concering sdhc card.

I have a E260v2 with a PQI 8gb microSDHC card that has worked very well with most versions until about 091016.  After that my microSDHC card will not read properly.  I have tried 091027 along with several in between and it still does not read sdhc properly. Reverting to the 091012(newest that I have that works) version works fine.   

The PQI brand class 6 sdhc card has seemed to work better than a previous A-Data card although it also works fine with the 091012 version.

Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on October 27, 2009, 01:17:19 PM
can you define "not read properly" ?

have you tried formatting the card ?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: OldOne on October 27, 2009, 02:01:58 PM
Funman,
Thanks for quick reply,  I thought I would pass on my experience with recent daily builds.

Properly means to allow view, access, and playing  directories and files.

With the release of 091012 I can can select Files | < microsd> | and see a listing of the directories and files and select any directory or file.  With later releases, ( I haven't tried them all), Main menu | Files | <microsd> shows only the First directory( no other directory or files in the root on microsd> on the disk and if I select it, Rockbox locks and requires a hard( 5 second or more) turnoff.

I think it was somewhere around 091015 or so when I had problems and 091012 was the last working one I had.

Browsing the main disk seems to work fine on any release.    I have formatted the main and microsd  twice.  Everything works great right now with the 091012 release.

Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on October 27, 2009, 02:13:14 PM
The voltage change was committed between the 12nd and the 16th so that could be a reason.

FlynDice what do you think ?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on October 27, 2009, 03:23:52 PM
I'm thinking voltage scaling.  I did remove the BUSWIDTH and BLOCKLEN commands on the 12th but besides that voltage scaling is the only significant change during that period. Since this only seems to affect the uSD and not the internal SD I really suspect it's voltage scaling.

OldOne, are you able to build your own from SVN?  It sounds as if you've just been using the daily builds.

EDIT:  After thinking about this for a bit I'm slightly puzzled now as the voltage should be raised to normal(1.20v) during disk accesses now that we boost on disk access.

OldOne, can you go into System/Debug/CPU frequency and scroll counterclockwise.  The frequency should go from 62000000 to 248000000 and then go back and try to browse your uSD files.  We're manually boosting both the frequency and voltage by doing this.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: OldOne on October 27, 2009, 05:34:29 PM
FlynDice

I have tried several microSd cards with the latest release and some work fine.

The Adata 8 gb card that occaisionally would panic and would not read is working fine with the new release .  A Transcend 2 gb card also seems to work ok.

The PQI 8gb cards that seemed better on earlier releases don't work any better with the debug procedure you asked me to try.   

The AData card failed on one of the releases about 091021 but is working now 091027.

I have the most music on the PQi cards.  So the problem seems to be only on PQI cards with the current release and boosting does not seem work.  They work fine on 091012.

Thanks for the reply

Edit:

After some more testing with the newest release and 091012:

Going to Debug | Disk info shows 25 mhz for microsd0 in both releases
info for microsd1  shows 25 mhz in the 091012 release but 50 mhz in the 091027 release.  Some microsd cards must not like the added clock speed.

I haven't setup to build my own releases but would like to try a new build with voltage scaling but with 25 mhz speed for sd1.

So for now I am running the 091012 release.  When there is an update to daily build that changes the speed, I will try it.  Are the patches and bugs the best place to monitor changes in daily builds?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on October 28, 2009, 07:32:26 PM
@OldOne:

The cards are all running overclocked right now at PCLK frequency(62 MHz).  The internals are v1 cards that should use a maximum of 25 MHz, but they don't really give us problems.  If the uSD card is a v2 card we assume it is high-speed capable and switch it to HS timings. HS timings are good from 0 - 50 MHz.  Unfortunately we cannot get either card to function at a different frequency than PCLK right now and are searching for a reason why.  There is no difference in the clock speeds for the two builds you have mentioned.  In both builds you can look on the View HW debug page and see the card frequencies.  It needs a disk access to get a reading  so just insert/eject a card and you should see 62 MHz.  The speed value for the card is not a MHz value but instead a Mbit/sec  value for the transfer speed on 1 data line  (which is all we can use right now also although there are 4 available).  On the 12th I rearranged the HS timing code to be run before the code which checks on the card data so the disk info display would show us 50 MBits/s if we indeed did get a switch to HS timings.

If you can browse the files on your card I'm thinking the problem happens sometime after the init phase and is more likely to be related to when the disk is transferring data.

I think you said you already tried chkdisk. 

I've run into some problems if i've ejected the card while the OF was refreshing the database, that tends show up as  an init problem though.

Formatting the card sometimes works but if your card is working with the Oct 12 build I wouldn't think it was necessary....
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: OldOne on October 29, 2009, 08:27:10 AM
Thanks for the reply FlynDice.  I remembered that the cards were running oveclocked at one time. While viewing the debug info I noticed the difference in info shown between the releases and the cards.  Thanks again for your knowledge and time.  Rockbox is a great improvement over the original Sansa.  I guess I like the option of choosing from the file menu as well as the database.  Video playback is better and the files are smaller than the ones needed for the Sansa firmware.

I will continue to monitor the changes and test releases as I have time. As you continue development,  I will be reading this topic to see if I need to try a new daily build.  I have started reading the bugs and patches too.

No more posts til I have more info.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on November 01, 2009, 02:18:59 PM
Hi,

Some news on recording: it now works on my Fuze although there are occasional panics (unhandled IRQ with unknown source).

Entering rec screen crashes on Clip (with source == microphone since FM is broken)

Could you test on e200v2 and m200v4/c200v2 please?

EDIT: reported to work on e200v2

I suspect small buffer will be a problem but you never know ..

Use the last patch on FS#10371 (http://www.rockbox.org/tracker/task/10371?project=1&string=recording&pagenum=2)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: mitch_de on November 03, 2009, 01:48:10 PM
WARINING :
The newest build r23498-091103 for SANSA V2 , (website newest builds) DL is linked WRONG !
Means if you click SANSA V2 you get complete other firmware (never had that before).
Named of z.ip as it should (sansa...) but : I looked in the info text (.rockbox ) and found:

Target: ondiofm
Target define: -DARCHOS_ONDIOFM
Manufacturer: archos
Version: r23498-091103
Binary: ajbrec.ajz
Binary size: 258300
....
I was a bit ?? about an file ajbrec.ajz in the roor of the unzipped  so i take a look closer.
Normaly i didnt do that and drag& drop the .rockbox to my SANSA .
I believe archos fimrware would be an bad idea ...
I now dl the dialy build (always some builds back to the newest) and wait for an fix of that link.
But i dont complain! Its up to us to take the brain +time first take a look whats in the dl.
So perhaps an hint to look into that dl before putting it on the player - at least with dl of the high frequnty newest builds.

For that closer look ,the sansa V2 builds shoudl have in info.txt as :
Target: e200v2
Target id: 51
Target define: -DSANSA_E200V2
Binary: rockbox.sansa




Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Narann on November 12, 2009, 07:09:20 AM
Alternatively you can build mkamsboot from SVN (this OF has been tested and its checksums committed)
I've done it! Damn I'm too happy! (I'm not a dev ;) )
It take me littles hours but it work! Now I have Rockbox with 1.2.28F OF :)

The link with all:

Just renamme the "patched.bin" in "fuzeA.bin" and copy it in the root directory of your sansa fuze.

But, if you don't thrust me (I can understand), you can patch yourself with the give mkamsboot.exe

Enjoy! ;)

Edit:  Link removed.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on November 12, 2009, 02:30:22 PM
Please don't distribute software on the forums you don't have permission to distribute (the OF bin file).

Just post the mkamsboot binary instead.

Edit:  heres a link to just the mkamsboot binary if anyone wants it:

http://duke.edu/~mgg6/rockbox/mkamsboot.exe
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: NTS1 on November 16, 2009, 01:35:21 AM
Narann,

Cheers for all your hard work.

Thanks to your mkamsboot.exe I now have my Fuze dual booting with Rockbox and the latest Sansa firmware. This is a huge improvement over the old firmware usually needed to get Rockbox working, it gives direct folder access to files etc. It's very useful to be able to switch between this and Rockbox to compare sound quality etc.

Many thanks again!  :)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Toxeus on November 19, 2009, 02:58:34 PM
Hope it's right topic to ask:
is there any way to disable pause from turning the hold switch up (in sansa clip build)?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: AlexP on November 19, 2009, 04:40:54 PM
is there any way to disable pause from turning the hold switch up (in sansa clip build)?

Could you rephrase this, I have no idea what you mean :)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Toxeus on November 20, 2009, 12:39:49 AM
My english is quite bad, sorry

When i turn the hold button from on to off and if i push it too far (toward the power off position) my playback pause. It doesn't happen on fuze and it's pissing me off on clip  >:(
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: mc2739 on November 20, 2009, 07:51:35 AM
When i turn the hold button from on to off and if i push it too far (toward the power off position) my playback pause. It doesn't happen on fuze and it's pissing me off on clip  >:(

The Fuze has a protection so that the power switch is not read immediately after the hold switch is released.  I have created FS#10796 (http://www.rockbox.org/tracker/task/10796) to add this same protection to the Clip.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Llorean on November 20, 2009, 10:18:54 AM
Just to be clear, moving the hold switch up was stopping the music, not pausing it.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Urutoraman on November 20, 2009, 10:30:30 PM
It's been a while.
The SD Card error still an issue for me.
Is my SHDC Card too fast ?
Navigation of the microSD is fine without any errors, but once I start playing a song it crashes around 2 to 3 min later.  Any parameter that can be set?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: mc2739 on November 21, 2009, 03:07:05 AM
I have discovered some interesting info regarding the ##MUSIC# and ##PORT# directories that show in the root files list in Rockbox on the AMS devices.

As stated previously in this thread, these directories are used for MTP mode in the OF.  They are not visible in Linux or Windows due to the attribute byte being set to 0x18 (directory & volume id).  I found it odd that they show up in Rockbox.  Using a logf build, I learned that when Rockbox parsed the directory entries, these two directories had an attribute byte of 0x10 (directory).

I verified with a disk editor that these directories did indeed have the attribute byte set to 0x18.  I also tried adding a directory to my e260v2 and setting its attribute byte to 0x18.  This directory was not visible in Rockbox.

Since Rockbox saw these directories with a 0x10 attribute byte and the disk editor saw them with a 0x18 attribute byte, I deduced that the OF must be changing the attribute.  To test, I booted the OF and then pulled the battery.  I then boot Rockbox to see if the directories were still visible and they were.  I then attached the USB cable with the battery removed, ejected the device, and removed the USB cable.  When I rebooted Rockbox, the directories were not visible.  After restarting the OF or entering USB mode, they became visible again.

I am not sure if any of this is really important, but it is something that has confused me since Rockbox has been working the AMS devices.

If anyone thinks this info needs to be on the SansaAMS wiki page, let me know and I'll add it there and remove this post.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on November 21, 2009, 09:03:10 AM
@Urutoraman:  I'm still looking at the sd card driver to try to fix several issues, see my earlier response to OldOne.  There are still some issues going on that we don't really understand.  At this point it's mostly experimenting to find clues that will help put the puzzle together...
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on November 21, 2009, 01:45:08 PM
Clipv1 is now supported, but it still needs improvements to the keymaps and FM driver.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: klaxon on November 22, 2009, 10:59:36 AM
I have a Clip V1 and i have a Divide by Zero error at 3020F1AC with many songs.
I have the r23692 version.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on November 22, 2009, 11:16:41 AM
there is still bugs on the Clip, you can track progress on FS#10605 (http://www.rockbox.org/tracker/task/10605)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: cpnfantstk on November 22, 2009, 07:27:27 PM
Does support include the M240v4 ? i thought that the Clip and M200 series are identical in hardware with the same buffering memory as mentioned  way back on this thread.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on November 22, 2009, 07:34:40 PM
They should be in the same state, but Clipv1 has a lot of testers while m200v4 has very few. If you confirm it works pretty fine then it can move into the same category
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: cpnfantstk on November 22, 2009, 08:00:12 PM
Have no problem doing that with my M240 as far as testing but what build do I use and where to get it? With my Gigabeat, I just go to current or stable build and thats it.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on November 22, 2009, 08:20:09 PM
I put download links for the m/c200 on the SansaAMS wiki page for people who don't feel like compiling their own builds. 
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Urutoraman on November 22, 2009, 09:26:55 PM
@Urutoraman:  I'm still looking at the sd card driver to try to fix several issues, see my earlier response to OldOne.  There are still some issues going on that we don't really understand.  At this point it's mostly experimenting to find clues that will help put the puzzle together...

Just to be sure it is a speed issue, I went to Best Buy and bought a microSD 8GB from PNY for $22 bucks, it is a class 4. They only have it for that price these 4 days.   Went back home, transferred a bunch of music (around 4GB) and swapped the 4GB A-Data with this 8GB PNY.

Guess what.  Not a single hiccups, no more SD Panic errors.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: MartyLK on November 23, 2009, 12:59:26 AM
Is there a bootloader and RB build available for the c200v2 yet? I've looked on the "status summary of unstable and unusable ports." page but haven't seen anything.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: mc2739 on November 23, 2009, 02:30:18 AM
Is there a bootloader and RB build available for the c200v2 yet? I've looked on the "status summary of unstable and unusable ports." page but haven't seen anything.

Check the SansaAMS (http://www.rockbox.org/wiki/SansaAMS#Installation_for_Unusable_other) wiki page.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: MartyLK on November 23, 2009, 12:36:10 PM
Thanks guys. I have a Rockbox'd c250v2 now.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: tofmin on November 23, 2009, 01:01:58 PM
Hi.
Trying to install RB on Sansa c240 v2.

Quote
- Make sure your player is in MSC mode.
Done.

Quote
- Download and Extract the normal build (rockbox.zip) onto your device.
Done (http://build.rockbox.org/data/rockbox-sansac200v2.zip).

Quote
- Create a folder 'rbinstall' in your on the Desktop
- Extract the OF, the bootloader AND mkamsboot into that folder.
- Open a new command promt window (Windowskey+R->cmd.exe). CD to the 'rbinstall' folder ('cd Desktop\rbinstall')
- Run mkamsboot from the command line window you opened in the previous step, passing the name of the OF file you've downloaded and the the bootloader file you've downloaded, as well as a name you can chose yourself for the patched output file
(e.g. 'mkamsboot.exe fuzea.bin bootloader-fuze.bin patched.bin')
Done (click to view image (http://i47.tinypic.com/675wro.png)).

Quote
- Copy the output file to the root of your device and rename it to whatever the OF file you've downloaded was named
Done. Name changed to "C200PA.bin" (image (http://i50.tinypic.com/34zc3lk.png)).

Quote
- Safely reject, unplug USB and wait for the firmware update to finish.
Done. Firmware is updating.

Quote
- You've successfully installed the bootloader and Rockbox. It boots by default. For booting the OF press |<< very quickly or plug the cable in while it's off.
Fail. Rockbox don't start. What I'm doing wrong?

PS. Sorry for bad english.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on November 23, 2009, 01:10:37 PM
Fail. Rockbox don't start. What I'm doing wrong?

Does the bootloader start?

Does it give an error message? (unable to open .rockbox/rockbox.sansa or similar)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: tofmin on November 23, 2009, 01:19:06 PM
Quote
Does the bootloader start?

Does it give an error message? (unable to open .rockbox/rockbox.sansa or similar)

Nope. Nothing is happend. Sansa booting with OF (on screen with language selection).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: MartyLK on November 23, 2009, 01:58:24 PM
Just as a report, I am using a Lexar 16GB MicroSDHC card loaded with FLAC. Music doesn't want to play from this card or FLAC files. I was able to get the c250 to play MP3 files on a 4GB card, but I haven't tried any other capacity yet.

I also noticed the Disk Cache setting is missing in this port. That has helped on other RB DAPs.

EDIT - Just updating the report on the playability of RB on the c200v2. I inserted an 8GB Sandisk card with OGG files. I was able to get a song playing, but hitting skip caused the player to stop playing. It skips fine enough, but won't play. This applies to the 4GB Sandisk card as well.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on November 23, 2009, 03:13:29 PM
Quote
Does the bootloader start?

Does it give an error message? (unable to open .rockbox/rockbox.sansa or similar)

Nope. Nothing is happend. Sansa booting with OF (on screen with language selection).


Post the file sizes of the bootloader, OF, and patched firmware.

MartyLK:  Does playback from the internal memory work?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on November 23, 2009, 03:15:27 PM
martlyk: note c200v2 still suffers form the same (known) playback bug than the Clip, which is tracked on FS#10605

tofmin: there is some possibilities:
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: tofmin on November 23, 2009, 03:40:50 PM
saratoga:

1. OF from Sandisk forum: http://forums.sandisk.com/sansa/board/message?board.id=c200&thread.id=2029 (Americas and Pacific ver).
Size:  5 243 904
MD5: b6378ebd720b0ade3fad4dc7ab61c1a5
Same as this: http://daniel.haxx.se/sansa/v2/c200/c200pa.bin

2. Bootloader from: http://download.rockbox.org/bootloader/sandisk-sansa/c200v2/
Size:  53 392
MD5: 7a81d843c4d4e4cf6230737fe6766117

3. Patched bin file:
Size: 5 243 904 (same as OF).


funman:

- right bin file and device is unplugged (checked, maaany times :) )


PS. Thanx guys! Great job with RB.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: MartyLK on November 23, 2009, 04:08:24 PM
Quote
Does the bootloader start?

Does it give an error message? (unable to open .rockbox/rockbox.sansa or similar)

Nope. Nothing is happend. Sansa booting with OF (on screen with language selection).


Post the file sizes of the bootloader, OF, and patched firmware.

MartyLK:  Does playback from the internal memory work?
Unfortunately no, it doesn't. It will play when it is powered on and a song is selected...of a format that it likes...but once the skip is pressed, it stops playing
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on November 23, 2009, 04:09:59 PM
saratoga:

1. OF from Sandisk forum: http://forums.sandisk.com/sansa/board/message?board.id=c200&thread.id=2029 (Americas and Pacific ver).
Size:  5 243 904
MD5: b6378ebd720b0ade3fad4dc7ab61c1a5
Same as this: http://daniel.haxx.se/sansa/v2/c200/c200pa.bin

2. Bootloader from: http://download.rockbox.org/bootloader/sandisk-sansa/c200v2/
Size:  53 392
MD5: 7a81d843c4d4e4cf6230737fe6766117

3. Patched bin file:
Size: 5 243 904
Same as OF.


funman:

- right bin file and device is unplugged (checked, maaany times :) )


PS. Thanx guys! Great job with RB.


If the patched and unpatched files are identical, then you probably haven't actually patched them and instead just renamed the file without patching it.  Start over, this time making sure you actually patch it.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: tofmin on November 23, 2009, 04:22:39 PM
Quote
If the patched and unpatched files are identical, then you probably haven't actually patched them and instead just renamed the file without patching it.  Start over, this time making sure you actually patch it.

Only size is equal. OF = patched = 5 243 904
MD5 checksums and modification dates are different.

BTW: http://i47.tinypic.com/675wro.png - Patching Succeeded!   ( ?? )
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on November 23, 2009, 05:29:17 PM
Please remember that asking for help installing rockbox is off topic in this forum. 
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: ClevelandTony on November 24, 2009, 08:39:52 PM
Gentlemen! Just Rockboxed my Fuze v1.
You guys fecking own! This thing went from mediocre to flat out amazing.
(My first experience with RB)
LONG story short I used to have a v2 Fuze. I acceidentally plugged it into a bad USB port and it became superheated. Didn't totally fry though, just fried the battery. Battery life is very short.

Wound up gettiing a refurb Fuze on Ebay and it just hapened to be a v1. So I RB'ed it.

As a thank you, I would like to offer my Fuze V2 to any developer here that wants it. I will pay shipping in the US.I don't know how much help it will be with the borked battery life, but if it will, it's yours.

Let me know.

Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: MartyLK on November 24, 2009, 11:24:15 PM
Another update to the functionality of RB on the c200v2. Playback stops after one song. Once the first playing song finishes, the next song is queued but it won't play. I don't know it the issue is with only my c250 or not. I have formatted the MSC side and installed music on the MSC mode as well as the MTP. But neither mode makes any difference. The menu system and options all seem to function normally.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: rock_c250 on November 25, 2009, 07:51:55 AM
My c200v2 stopped many times after two songs. Some times after one. But it played 20 mins mp3 without stopping. Once stopped some times it won't play until restart. Some times it plays after stop and start a new mp3 again. May be a random playback crash as known.

Album art, Menus, EQ, database looks working perfect.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on November 25, 2009, 08:53:06 AM
1-in settings..recording..clear recording directory does not delete them
2-manual does not describe how to record (start, stop etc)
Q?:is there a way to set the recording 'to' directory?

1. The clear recording directory does not delete recordings, it resets the recording save directory back to the root directory.

2. The manuals are updated nightly and should now have the recording sections included.

A. Yes.  In the file browser, highlight the directory you wish to use for recording and bring up the context menu (long select).  Scroll down to "Set As Recording Directory" and press select.

This thread isn't for support questions.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: mc2739 on November 25, 2009, 10:19:52 AM
This thread isn't for support questions.

Sorry.

@TimNixon - Recording questions moved here: http://forums.rockbox.org/index.php?topic=23245.0
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: OldOne on November 25, 2009, 02:55:09 PM
FlynDice,

I have installed a cygwin environment and built 23131 with newer versions of ata_sd_as3525.c as well as pl180.h (for needed includes) but nothing else changed and they worked with all my cards.  Even newer versions of ata_sd_as3525.c after voltage scaling. (I don't believe voltage scaling is taking place with the old system_as3525.c)

The newest version 23745 will work with any card if I boost the CPU frequency before inserting the card.  My Pqi 8gb class 6 cards ( the ones I wished worked) will work with CPU boosted.

If I unboost the card stops working( attempting to go to  Files | microsd1 |   goes to first screen and system  usually freezes and requires a hard power off. 

Is there some way to be sure the voltage is boosted before we access the microsd card.  I am trying to read system_as3525.c  to better understand.  I think some cards just overclock better than others.  Is there a way for me to turn off reduce the amount of voltage scaling and build my own new version?  Will we ever be able to run the cards at 50 instead of 62?

PS  All my cards work fine in original firmware or card reader.

Thanks to all.   I am happy to build and try any suggested changes if that will help.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on November 25, 2009, 07:26:05 PM
@OldOne:

Yes, I have been working on getting the cards to run at lower frequencies along with enabling 4-bit widebus but I have been unsuccessful on both so far.  I had the cards running at 31 MHz at one point but not reliably, and that is not woking right now anyway.

The voltage and frequency scaling actually happens in system-as3525.c so if you're interested, that's the place to look, see

 void set_cpu_frequency(long frequency)

near the end.

We do, in fact boost both voltage and frequency when a uSD card is present during a disk access.  You can find that in ata_sd_as3525.c

 void sd_enable(bool on)

near the end also.

If you've got a build environment set up I would suggest changing line 379 of system-as3525 from CVDD_1_10 to CVDD_1_20 which will keep the voltage scaling code in place but will not actually reduce the voltage.  ie it "changes" from 1.20v to 1.20v...

Please let me know your results!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: OldOne on November 25, 2009, 10:55:59 PM
FlynDice,

Built latest with the change you suggested on voltage.  My PQI cards work fine.  i will read some more and let you know if I have any ideas.

Thanks
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: ClevelandTony on November 26, 2009, 10:18:45 AM
Just an FYI for the devs.
When I installed Rockbox I had some DRM audiobooks on my player. Bootiing back to the Sansa OF and they still worked. But I wanted to test that I could still load new DRM files.
Went to the library website and was able to download, copy, and play a new DRM title.
So DRM is not broken on m Sansa. Thanks.

(Saratoge, this is Peregrine from the Sansa forum. Wantd to wait to post result here until I tried a new title.)


//edit// As for the offer for my Fuzev2... I should have been more specific. The battery still works but it only lasts for 3 or 4 hours at best.

It's not totally dead.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: johnc60 on November 27, 2009, 08:14:49 PM
I installed the latest build of Rockbox (r23773) on an m250v4 per the instructions and things seem to work pretty good.

One problem that I came across is that the audio is very low, as installed.  When I raise the volume up beyond the -2dB setting, the music will play at the higher volume for a short time (seconds) and then the player just turns off.  There are no warning messages.  It just dies.  Restarting the player returns it to the previous volume level.  The original firmware plays very loud with no problems across the entire range of volume settings.

Any ideas?  Any additional info needed?

-John
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on November 27, 2009, 08:28:36 PM
edit:  Sorry, read "m200v2" as "e200v2". 

FWIW, its less confusing if you call it an m200v4, since the m200v2 is probably not what you have :)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: mc2739 on November 27, 2009, 08:48:56 PM
When I raise the volume up beyond the -2dB setting, the music will play at the higher volume for a short time (seconds) and then the player just turns off.

If you check the Current Status chart on the SansaAMS wiki page (http://www.rockbox.org/wiki/SansaAMS) you will see that this is a known problem on the m200 "v4" port (OF v4.xx.xx).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: johnc60 on November 27, 2009, 10:40:31 PM
Right.  I corrected it to say v4.  I was just following the title which says (v2).   :)  I actually have a v2 also.  Thanks for the pointer to the chart.  I've read that chart before but it didn't stick in my head.

I think it might be a power issue.  If I disable the backlight, the volume can be raised up a few dB before it dies.

The Rockbox code must be setting up the audio amp or pre-amp in some strange manner on this platform or the codec is not delivering the correct input levels to the audio amp.   Even at low to moderate volume, the audio is distorted.  With the original firmware, the audio is clean even at ear-deafening volume levels.

Is it possible that the audio level is too low at the input of the final audio amp?  Therefore, we have to crank it way up just to get a decent volume causing huge power draw and the power regulator shuts down?

-John

Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on November 28, 2009, 06:01:34 PM
I took a quick look at line out.  According to this thread:

http://www.head-fi.org/forums/f6/sansa-fuzes-diylod-v1-v2-guide-56k-421318/

The Fuze OF pulls one of the dock pins high (3v).  I have confirmed this on my Fuze.  A dock then connects this to another pin  We currently do not know how to pull this pin high, but its probably one of the handful of unassigned GPIO pins.

According to this thread:
http://forums.rockbox.org/index.php?topic=22942.0

DBOP_DIN9 changes when a fuze dock (which uses external power to pull the dock pin high so scanning isn't needed) changes.  But thats also GPIOB7, which apparently did not change according to that thread, so I'm a little confused.

Edit:  I tried manually putting 3v on the dock pin and looking for a change in debug menu, but I didn't see anything.  Looking more carefully at the debug menu output, I see that the GPIOB7 pin is configured as output currently, so I suppose I shouldn't see anything.  On the upside, assuming I did this right, I was able to rule out GPIOA0, and GPIOC0/1.  That only leaves some of the shared GPIO/DBOP pins unaccounted for.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: yelped on November 28, 2009, 07:32:36 PM
Is there a line-in wired in?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on November 28, 2009, 07:40:09 PM
Is there a line-in wired in?

If there is, the Sandisk firmware/accessories don't use it. 

Edit:  Soap sent me this link:

http://www.chargeconverter.com/shop/connnopod.htm

If you want to look for recording, the break out board there would be an obvious way to see if any of the pins work as line in.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: MartyLK on November 29, 2009, 12:50:44 AM
I'm happy to report that I turned off the Shuffle and now my c200v2 will continue to play music after the first full song and after a track skip. Before, my c200v2 would stop playing after the first song played through or after a track skip. Now, however, with Shuffle off, it will continue to play without stopping.

EDIT - Ooops, I spoke too soon. My c200v2 plays more than one track, but stops after about the 3rd track.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on December 01, 2009, 06:43:36 PM
DBOP_DIN9 changes when a fuze dock (which uses external power to pull the dock pin high so scanning isn't needed) changes.  But thats also GPIOB7, which apparently did not change according to that thread, so I'm a little confused.

We're currently only configuring those pins for output for which we know there's a button on it so the dock pin might go invisible in the debug screen. With bertrik's dbop patch, we won't be reading buttons from GPIO but only via DBOP anymore though.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on December 01, 2009, 07:03:42 PM
I need some tests on targets other than e200v2 for this:

http://www.rockbox.org/tracker/task/10825
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on December 01, 2009, 07:31:38 PM
About the people reporting c200v2 bootloader doesn't work: rockbox reads buttons with DBOP while mkamsboot still use GPIOC.

Adapting mkamsboot to use DBOP might be worth a try (paying _special_ care of course)

bertrik do you feel like doing it ?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on December 01, 2009, 07:43:30 PM
About the people reporting c200v2 bootloader doesn't work: rockbox reads buttons with DBOP while mkamsboot still use GPIOC.

Adapting mkamsboot to use DBOP might be worth a try (paying _special_ care of course)

bertrik do you feel like doing it ?

I don't think that's critical. Wasn't there 1 or 2 buttons which can be read with GPIO on the c200v2?

DBOP is a bit more complex, especially in asm. Could we compile the isolated dbop read function from C code and incorparate that?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on December 01, 2009, 08:00:22 PM
It seems it just doesn't work right according to multiple posts on this thread.

I don't think writing this code in assembly is complex (the function is lcd_dbop_read() )
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: fredex on December 01, 2009, 10:37:59 PM
I just wanted to let all you guys who've worked on the Sansa e200 v2 port that it is so far working GREAT on my 4 gig e200 v2. I've not tested the voice menus yet, but so far all I've tried works well.

I do have a question: though it's not a big deal for me I'd be curious to know if there is a way to limit the FM radio to only those channels available in the US (or whatever jurisdiction the listener is in).

Thanks a bunch!

I originally purchased the sansa because of an online review I saw of Rockbox running on the Sansa e200, only to find that Rockbox didn't work on the v2 (I hadn't previously known there WAS a v2), so I'm now very pleased to see it working. Your efforts are appreciated.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on December 01, 2009, 11:11:33 PM
Anyone got any ideas for me here?  When I try to run the sd cards at 31 Mhz now it seems I'm up and running but all the text is missing on the screen.  I get nice color icons and I can browse the files on both disks, but all the text is blank.  If I select a playlist I can get album art to display but music will not play.  Anyone been here before?


EDIT:
@Fredex:

Long select (press & hold disk inside wheel)FM Radio:  then go down to region and short select.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: sqgl on December 02, 2009, 10:12:50 AM
Is speed implemented yet on c250 v2? (ie independent of pitch).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on December 03, 2009, 12:31:32 AM
This isn't specific to the c200v2, but is implemented for all models (including this one).

However as playback is broken on c200v2 you might not enjoy it at the moment.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: epithetless on December 04, 2009, 04:35:23 PM
Following the recent AMS SD-related commits (the ones that started with r23829), my 8GB Fuze (+8GB Class 2 SanDisk microSDHC card) now often hangs on the startup screen displaying the build. A hard reset is required to exit.

I've also experienced a couple instances of audio output stopping seemingly randomly. At these points, the backlight still works, the WPS continues to display elapsed time, and the progress bar continues to move as normal, but the player is unresponsive to any further button presses. Again, a hard reset must be performed to exit. When I restart the player and resume playback, it returns to the song and section that was playing before the previous startup, acting as though none of the playback done during the session with the hang-up ever happened.

I'm on r23842 at the moment. Has this behavior appeared for anyone else? I will post a bug report if so.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: danthegoodman on December 04, 2009, 07:24:38 PM
Quote
Following the recent AMS SD-related commits (the ones that started with r23829), my 8GB Fuze (+8GB Class 6 SanDisk microSDHC card) now often hangs on the startup screen displaying the build. A hard reset is required to exit.

yes, I've been having that issue too. I can't even get past that screen without reinstalling rockbox.  :-\
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: MartyLK on December 04, 2009, 08:36:18 PM
Following the recent AMS SD-related commits (the ones that started with r23829), my 8GB Fuze (+8GB Class 6 SanDisk microSDHC card) now often hangs on the startup screen displaying the build. A hard reset is required to exit.

I had that happen to mine today. I finally removed the card, booted, powered off, re-installed the card and all is well.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on December 04, 2009, 10:50:31 PM
I spoke with topik today in irc who was experiencing this problem with a fuze and an 8gb class 2 sandisk card.

For those experiencing this problem would you first try removing the uSD card and see if rockbox runs ok without the card inserted.

If it does would you then  insert the card and see if it inits properly(you can browse files and play music from it).

Would you then go to system/debug/View disk info and see what the Speed value is, press select to get microSD 1(uSD card)

You should see either 25.0 or 50.0  MBit/s.

Then would you report back here with player type and sd card info, manufacturer, size, speed class(small number in circle), and speed you got from the debug page.

Sorry for your problems!  Thanks for your help!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: epithetless on December 05, 2009, 01:07:44 AM
It's hit-or-miss as to whether my microSDHC card freezes the player (either during bootup with it already inserted or when inserting it after bootup), but when it does work, the details are as follows:

Speed (from debug screen): 25.0MBit/s
Manufacturer: SanDisk
Size: 8GB
Speed Class: 2*

[*My apologies for mis-stating it as class 6 earlier; I was thinking of a different card at the time.]

I should also add that the audio playback halting/freezups I've experienced have occurred with music that's stored on the microSDHC card, not the internal memory (so far, at least) -- Which leads me to think that problems exist with the current microSD implementation even beyond the initialization stage.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on December 05, 2009, 03:03:15 AM
@epithetless

If you can build would you try this patch?

http://pastie.org/728675

Thanks.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: epithetless on December 05, 2009, 03:34:15 AM
@epithetless

If you can build would you try this patch?

http://pastie.org/728675

Thanks.

Unfortunately, I haven't worked my way up to compiling and patching builds yet, and I'm slammed with other work at the moment, so it will be a while before I have the time to sit down and sort through it.

Can someone else assist FlynDice with this or compile and share a build utilizing his patch?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: BlastTyrant on December 05, 2009, 07:47:22 PM
I'm getting the Fuze freezing issue also. I'm able to reproduce it fairly well.

First some basic info:
2GB Fuze
8GB Transcend microSD Card
Class 6
microSD speed from debug menu: 25.0MBit/s
Currently running r23854-091205
Previously running r23781 - didn't have this issue when running this build.

I'll first report that it doesn't freeze at all when the microSD card is removed.

Specifics on reproducing the freeze (if I'm not currently having the freezing issue):
At this point RB will usually freeze up on every 2nd boot on the boot screen where it displays "Ver. r23854-091205" right after it displays the "Boot Ver. 1.0RC" part of the boot screen.

Sometimes it will freeze up on every boot for 3-4 boots in a row.

When the player freezes a hard shut down is required.

*note that this is when the microSD card is in the player



The only thing that seems to stop the freezing problem 100% is to remove the microSD card when I boot the player.

It seems that the player is less likely to freeze on boot if I go to resume playback and listen to music for at least 2 minutes.



I'm going to try to read up on getting set up with a build environment either tonight or tomorrow so that I can test FlynDice's patch. Hopefully that will go smoothly ;)

If anyone needs any more information let me know and I'll try my best to accommodate you.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: 7o9 on December 06, 2009, 02:46:07 AM
The patch is now commited as r23870.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on December 06, 2009, 02:54:51 AM
I have committed the patch above that moves the boost from SD identification freq to SD operating freq to after the switch to HS timings happens.  I'm not sure why this all worked fine at 62 MHz and now at the lower freq problems arise.  This seems to get the cards through the init process for now though so it's a first step.

When the cards get switched to HS timings we can actually see that from the info on the view disk info debug page.  If the switch to HS timings is successful the speed will show 50 MBits/s.  If we get this we can run the card at 31 MHz and be within the spec.  If not we are running slightly over spec, the limit being 25 MHz for a standard speed card.  My problem here is that we run PCLK at 62 MHz and we can only divide this by 1 or even integers (1,2,4,6...) so our next lower frequency is 15.5 MHz.  Using 15.5 I get data crc failures presently during writes on both internal and uSD cards and I'm not quite sure why.

Right now I'm looking at the data crc failures. I think this is the preferred solution.  If unable to overcome that then I think lowering PCLK to ~50 MHz solves our overclocking problem but may have other negatives associated with it.

Anyway, please yell loudly if you are still experiencing problems & thanks to those testing & helping out!

EDIT: Divider is even ints not power of 2...
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: epithetless on December 06, 2009, 03:58:52 AM
Sadly, I'm still experiencing some system freezes during startup with my microSDHC card inserted, when inserting it with Rockbox already on, and when playing music from the card. :(

As before, the "View disk info" screen under the debug menu lists the card's speed as 25.0Mbit/s. (To refresh, it's an 8GB Class 2 SanDisk microSDHC card.)

Thanks for your work on this, FlynDice!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: BlastTyrant on December 07, 2009, 03:36:36 AM
I have committed the patch above...
I just put r23879 on my Fuze. The freezing issue is completely resolved for me now. I've booted it about 30 times since putting the new build on and it didn't freeze once.

MicroSD card is still running at 25MBits/s.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: epithetless on December 07, 2009, 06:30:23 PM
Well, I haven't had any issues since my last post, so perhaps they were just a fleeting residual effect of resuming playback immediately after updating to the newer build. Thanks again, FlynDice.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on December 07, 2009, 09:42:43 PM
Glad to hear things are working good now.

Could I get some tests on this:   http://pastie.org/732553
This patch runs the internal at 15.5(sort of see below..), standard uSD at 15.5, and HS uSD at 31

I think I have solved the problem with crc failures on sd writes at 15.5 MHz.  For some reason we need a small delay after we send the write command to the controller before we start the transfer when writing to the cards at 15.5 MHz.

I am now almost certain that the internal controller uses the IDE clock as it's MCLK.  For some reason It needs both  IDE_CLK and NAF_CLK enabled to function which is where my confusion came from several weeks ago.  With this thought in mind it should be possible to run the internal cards at 25 MHz, High speed uSD cards at 31 MHz and standard speed uSD cards at 15.5 MHz.  That would be all cards running at their max frequency within the specs.  We could choose to lower that later if tests show an advantage power wise.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: BlastTyrant on December 08, 2009, 10:56:37 AM
Glad to hear things are working good now.

Could I get some tests on this:   http://pastie.org/732553
This patch runs the internal at 15.5(sort of see below..), standard uSD at 15.5, and HS uSD at 31
...

OK, I finally got set up on my Ubuntu install to make Rockbox builds.

I applied your patch to r23895 and put it on my Fuze.

I didn't experience any problems with it when I was testing it for about 15 minutes. I booted it multiple times with different cards and tested playback. I'll leave it on there for a little while. Let me know if you need a more extensive test.

Here's the info that I got while running the patched build:

With my 8GB Class 6 Transcend uSD:
HW Info*:
   SD: 15MHz
   uSD: 31MHz
Disk info:
   Speed: 25.0MBit/s

I also tested it with a 2GB Class 2 Kingston uSD and got the same results.

*The 'Actual' column reading was the same as the 'Set' column reading while it was filling the buffer. I didn't know if you needed me to include this, but I figured it couldn't hurt.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on December 08, 2009, 03:15:55 PM
Shouldn't class 6 cards be 50MBit/s? Those are rated for over 10MB usually (which we can't handle anyway but we do manage to be faster than 25MBit/s if the cards allow it).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on December 08, 2009, 03:53:44 PM
@BlastTyrant:

The speed value is a maximum value which we aren't actually running the card at. I believe your card(s) is indeed successfully switching to 50.0.  The initial screen which appears for View disk info shows [microSD 0], which is the internal SD card, which is a v1 and does indeed not switch to 50.0.  Press the select button while in the View disk info page and it will cycle to  [microSD 1] which is the uSD.

Since your card is running at 31 MHz, the code checked on the speed value reported in the card's CSD register and found it to be 50.0 so it divided PCLK by 2 to get 31 MHz.  Otherwise it would have divided by 4 to run at 15.5.

EDIT: ---------->  Thanks to all for taking the time to test for me!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: BlastTyrant on December 08, 2009, 05:21:20 PM
@BlastTyrant:
...Press the select button while in the View disk info page and it will cycle to  [microSD 1] which is the uSD....

Well, I feel kind of stupid now  ;)

Yes, when I press the select button it brings up microSD 1 and it shows that the speed is in fact 50.0MBit/s

Sorry about the confusion, and I'm glad that I can help.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on December 09, 2009, 01:53:58 AM
Alright, once again calling all testers.

I especially would like to make sure this runs well on a clip.

This patch changes the assumption for MCLK on the internal pl180 controller from PCLK to IDE_CLK.

Please see http://www.rockbox.org/tracker/task/10838 and leave me some feedback with your results!

Thanks.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: daniel_at on December 09, 2009, 04:47:39 PM
Hi hackers,

I also have problems with a recent SVN (r23905), Fuze V1 and microSD. Just updated the fw and bootloader and now my Fuze cant be switched on with an MicroSD card inserted (Hama 2GB - dont know further details).

The bootloader can load RB, the status-bar (battery, clock...) gets renderd, but instead of the menu the Rockbox-Bootupsplash stays and the device locks up. Sometimes led/background fades out and in at buttonpress, sometimes a full lock up.

If I insert the card while RB is running, I get instantaneously
Code: [Select]
*PANIC* microSD init failed: -9 (and sometimes i get -3; but mostly -9).
So I cant visit the debug-screen, with card inserted.

Without a microSD card inserted, everything works fine.

[Edit]
Just downdated to r23836: Booting with/without and/or later inserting now works. The debug screen says:
Code: [Select]
G20D REV 7.12
M=27 O=PH
Blocks: 0x003cd000
Speed: 25MBits/s
Taac: 50.0ms
Nsac: 0clk
R2W:*2

[/Edit]

[Edit 2]
Some further test: Still using bootloader r23836 but testing different RBs
r23900 is the last one that boots/works on insert
r23901 after this change to ata_sd_as3525.c RB fails again to boot with inserted microSD and Panics at insert

[/Edit 2]

bye,
Daniel
 
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on December 09, 2009, 10:57:12 PM
@ daniel_at:

The -9 is a failure during the init stage where the card is being deselected in order to read the csd register.  In the revision that breaks for you I had moved the point where we bring the cards up to operating speed to just after this point so we could look at the speed value from the csd register and set the card frequency appropriately.

If you can build can I get you to try adding a delay to line 336 of ata_sd_as3525.c:

335                  return -8;
336          mci_delay();
337    }

I'll attach a diff also if you'd rather do that.

I think this should work.  The problem you're running into is that the card is now running at 400kHz at this point as opposed to 31 MHz before.

Let us know how you make out!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: daniel_at on December 10, 2009, 05:10:51 AM
Hello FlynDice,

Thx for the quick response - seems youre right. I added the delay, now booting and inserting is possible again, without crashing.

Further I noticed that in the debug screen, my microSd card is now listed with Speed: 50MBit/s (where it had only 25M with the previous build)

Filelisting and playing is also working

Thx.
Daniel
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on December 10, 2009, 08:46:03 PM
Still need someone to test FS#10838 (http://www.rockbox.org/tracker/task/10838)  on a clip &/or fuze please.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on December 10, 2009, 10:50:18 PM
FlynDice, looks like it is working on both Clip & Fuze

Do you think we'll have to upgrade the bootloaders for 3.5 release after all the modifications you made to SD driver ?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: BlastTyrant on December 10, 2009, 10:55:35 PM
Still need someone to test FS#10838 (http://www.rockbox.org/tracker/task/10838)  on a clip &/or fuze please.

Just patched r23928 with the diff and tested it out for 20 minutes or so. I did 15 power on/off and let it play for around 15 minutes. I had no issues running it on my Fuze.

IDE is set to 50MHz. Actual shows 49MHz.
SD (internal ?) is running at 25MHz.
8GB cl6 Transcend uSD is running at 31MHz (50.0MBit/s).
1GB cl2 Sandisk uSD is running at 15MHz (25.0MBit/s).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on December 10, 2009, 11:21:05 PM
funman

I don't think we would have to but quite honestly you would probably have a better feeling for that than I do.  I'm running a bootloader built off of r23799 right now but I was running off of one from August until just before that.  We would still be overclocking the internal card with the present bootloader but it seems to work fine.  I guess what it comes down to is if we want to spend the time to make it technically correct or is the fact that it "just works" good enough?

Once again , thanks all for the testing!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on December 10, 2009, 11:57:26 PM
We don't even know what the internal memory is speced for, so if its working I wouldn't worry too much about trying to conform to some spec that may not even apply.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on December 13, 2009, 11:10:02 AM
Well, I have finally managed to get 4 bit widebus working  ;D !!

I had to fly all night though so I'm going to get some shuteye and clean it up when I'm a little more coherent.

In order to head off kugel's question I'll post the speed tests now.  UNS = UNALIGNED_NUM_SECTORS


http://pastie.org/741378
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on December 13, 2009, 11:20:27 AM
Nice, it shows some decent speed ups! But only for reads (create/write is still slow)? That seems strange.

SVN has gotten pretty slow?

BTW, my fuze stopped working. It just doesn't turn on anymore. The last time I used it was thursday. I turned it off normally after listening to radio.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on December 13, 2009, 11:54:41 AM
Nice, it shows some decent speed ups! But only for reads (create/write is still slow)? That seems strange.

The 1MB write is basically 4x faster, so its probably just a limitation of the internal memory controller for smaller writes, since those often involve lots of costly copying and rewriting of sectors.

BTW, my fuze stopped working. It just doesn't turn on anymore. The last time I used it was thursday. I turned it off normally after listening to radio.

Want my Clipv2 to play with ;)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on December 13, 2009, 11:58:39 AM
Nice, it shows some decent speed ups! But only for reads (create/write is still slow)? That seems strange.

The 1MB write is basically 4x faster, so its probably just a limitation of the internal memory controller for smaller writes, since those often involve lots of costly copying and rewriting of sectors.
Where are those writes faster? They are only faster with a bigger buffer (64 UNS). And they're slower without compared to my tests I made a while back (see FS#10805)

Quote
BTW, my fuze stopped working. It just doesn't turn on anymore. The last time I used it was thursday. I turned it off normally after listening to radio.

Want my Clipv2 to play with ;)

No thanks, I have a FuzeV2 rotting around myself :)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: DavidW on December 15, 2009, 10:14:30 AM
For the last two days, I have been having trouble with the database on my Fuze V1.  It will initialize properly, but later I get a database is not ready error.  When I try to initialize again it fails with some write error to the internal flash disk.  (Sorry I can't give the exact error now I am not sure I want to intentionally cause this to happen again.)  If I run scandisk on the internal disk it seems to fix everything but a couple of time it left files I could not delete on the disk.  These files finally went away when on one occasion the entire .rockbox directory was corrupted. 

Can anyone tell me if this is an issue with my player or is it a software problem?  I am currently using r23989-091214.

Thanks,
David
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on December 15, 2009, 02:05:09 PM
@DavidW:

Sorry to hear about the problems.  A couple of days ago I put in the change for 4 bit widebus on the SD cards so that may be a possible culprit here but you would be the first reporting problems.  I'm working with an e280v2 and I have just initialized my database and rebooted to commit it and it is functioning normally for me.

I would try the following:

In the .rockbox folder you should find several files named database_(X).tcd.  X runs 0-8 and theres an idx also.  Delete those and try to reinitialize the database.

If that doesn't work I would try formatting the internal disk with the OF and then reinstalling.

If that fails then copy down your steps to reproduce this and any error messages and let us know.

Good Luck!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: OldOne on December 15, 2009, 02:17:33 PM
Hello,

Oldone here.  I only have an E260v2. I also had some problems with corruption on my internal card while trying the new builds with the wide bus update mentioned a few posts up.

I have been experimenting with all of the changes in the SD card module and haven't noticed any problems until the widebus change.  After the file corruptions,  I switched back to 23935.  I have also found that by changing the lowered voltage from 1.10 to 1.15, my troublesome PQI class 6 8gb cards work fine.  This has worked since about 23830. I build one with 1.10 voltage for my standard use and one with the voltage reduction set at 1.15.  I name the 115 version rock115.sansa and copy into the .rockbox directory.  When I want to listen to something on my troublesome cards, I just run the modified version.

I will wait on some more testing before using the widebus changes again.  The change was made at version 23977 I believe.  I have tried every change or patch for the SD cards Only changing the voltage scaling from 1.10 to 1.15 makes my PQI cards work perfectly.  Is there someway to switch up the speed or voltage sooner in the card access process(Does that make sense?) Is it possible to set the lower voltage to something between  1.10 and 1.15?  

By the way my SD cards seemed to work OK with widebus.  I tried copying from the card to internal card when the corruption on internal card occurred.

I have ordered some refurb 1 gb clips from woot.  I hope they are v1's so I can play with rockbox on them.

Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: epithetless on December 15, 2009, 10:41:39 PM
I am also experiencing some newfound data corruption following my update to a post-"4 bit widebus mode" build (r24003, to be exact). Here's how it happened: After editing a WPS file on my Fuze and shutting the player off, any attempts to start the Fuze now result in the splashscreen coming up, a "scanning disk.." dialog box appearing for a second, and then "Data abort at 30800968" displaying. Any press of a button reboots the player and repeats the cycle, whether or not my microSDHC card is installed.

Looking at the contents of the .rockbox folder from my computer, I'm now seeing several new gibberish files and folders, the folders named "è;Å;" and the files named "è;ï;", ".", "c", "i", and "x".
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on December 16, 2009, 12:47:42 AM
Ok, I'm getting it now also.  For some reason the /.rockbox/playlist_control file is getting corrupted,  for me at least.  But test_disk write & verify passes and I can copy files from the uSd to the internal with no corruption at all.

EDIT:  I have changed the small write delay for non-HS uSD cards to a small write delay for all non-HS sd cards which includes the internal SD cards.  This seems to solve the problem for me so I committed the change.  For those experiencing problems would you please try it out now and let me know your results good or bad. Thanks!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: epithetless on December 16, 2009, 02:32:56 AM
Interestingly, at this point, the latest build I have which doesn't result in the "Data abort at 30800968" message during bootup is r23903 -- if directory cache is enabled. When directory cache is off, Rockbox boots without error. This is true of the most recent build, r24020, as well.

After my initial "Data abort at 30800968" encounter, I ran Check Disk on the internal memory, formatted it using the OF, formatted it with the Panasonic SDFormatter v2.0, flashed the Fuze with an unpatched SanDisk firmware file, and reflashed it with a patched firmware file -- all in an effort to weed out any lingering issues -- but the problem persists (as I said, as long as directory cache is on). Any thoughts on this, FlynDice?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: ChiefAlex on December 16, 2009, 08:18:14 PM
Since today, i get following after some seconds booted Rockbox:
*PANIC*
SD Xfer read err:0x8 Disk0
Anyone knows whats the reason?

regards,ChiefAlex
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on December 16, 2009, 08:47:19 PM
@ChiefAlex:

Thanks for the report and the error code, I haven't seen the read errors before.  That's a data timeout on the internal disk.

Which player are you using?


EDIT:

@ all:  For what it's worth my e280V2 is not displaying any of these problems right now.  I don't say that to discount the problems being experienced but to explain why this is becoming tricky to fix...

EDIT2:

@ epithetless:

"Data abort at 30800968"  seems to fall in the memcpy function as I look at rockbox.map.  It's always 30800968 correct?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: epithetless on December 17, 2009, 01:12:10 AM
@ epithetless:

"Data abort at 30800968"  seems to fall in the memcpy function as I look at rockbox.map.  It's always 30800968 correct?

Yes, it's always 30800968.

Are any other Fuze users seeing this data abort once directory cache is enabled? The strange thing is I'd actually had directory cache enabled for a long time (as in many months) without any issue, but once the data corruption occurred yesterday, even builds which accepted directory caching before now fail with the abort message. Running Check Disk, thoroughly reformatting the device, and reflashing the firmware haven't changed this. :(
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: ChiefAlex on December 17, 2009, 06:58:49 AM
Hi FlynDice,
I use the Sandisk Fuze V1.
Some more ino: When i connect player to PC some "Files" are visible in the root folder. They have no-displayable names and cant get deleted. only way to fix it (for me) format the player via Windows. FAT or FAT32 seems to make no difference?

With a very old build from xx.09.09 this not occur. Thanks god i had this zip on my PC.
If you need more info about settings/whatever feel free to say, ill do my best to fix this.
Just DLed Rev.24039, lets see if it still occur
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: samstar on December 17, 2009, 12:55:49 PM
Hi all,
I have a sansa e260v2 w/ a kingston 2gb uSD card, and I've been following all of your work for quite some time.  This is my first time posting.  First let me say I'm very impressed at the progress being made here.  It's brought my music player back to life, as the OF was too frustrating to work with.  Much thanks to you all.

I wanted to confirm that updating my sansa from revision 2373X (give or take a few numbers) to 20429 yesterday also gave me corruption problems.  I spent the time formatting the internal memory after the update, and uploading the songs to it.  Whenever I tried to initialize the database, it would always respond after a reboot that the database needed to be initialized.  Cleaning the drive with chkdsk only temporarily solved the problem, and let me access the database for about ten minutes before it became corrupted.  I tried creating playlists from the file browser then, only to find that all the playlists I saved became corrupted as well.  It came to the point where linux would no longer recognize the partition as a usb storage drive when plugged in with the OF running.  I'd have to use the OF to reformat the drive first.  Also, I would often get panic errors, but I didn't have the presence of mind to write them down >:(

After reverting my player to rev. 23929 (before the 4-bit widebus update) I have been able to initialize the database and create and move files without any corruption issues at all.  For the record, I've not had any corruption issues with the uSD card for any of the revisions.

If I can be of any other assistance, please let me know!
Thanks again!
Sam
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on December 17, 2009, 02:28:19 PM
Well, after leaving my player on all night I came back to find several strange files in my .rockbox folder this morning  :-\...

I have reverted the 4 bit widebus for now until this is figured out.  I'm sorry for the inconvenience, I'll test this better before it comes back.

Please let me know if you are still getting problems now!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: pwhodges on December 17, 2009, 06:51:12 PM
I loaded Rockbox on my e280v2 for the first time yesterday (r24036).  It played ogg files happily for a while, and then I paused it and left it to turn off.  When I returned an hour later and turned it back on, every attempt to play a file gave "codec error" - for both ogg and mp3.  I looked at the .rockbox directory and found it full of corrupt filenames - single letters, "É;É;", and so on; some had mad sizes, GB more than the Sansa's memory. 

Paul
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: samstar on December 17, 2009, 07:57:34 PM
Updated to rev24060, put memory through its paces, copying files, creating databases, etc.  All work flawlessly so far.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: mc2739 on December 17, 2009, 09:06:22 PM
I loaded Rockbox on my e280v2 for the first time yesterday (r24036).  It played ogg files happily for a while, and then I paused it and left it to turn off.  When I returned an hour later and turned it back on, every attempt to play a file gave "codec error" - for both ogg and mp3.  I looked at the .rockbox directory and found it full of corrupt filenames - single letters, "É;É;", and so on; some had mad sizes, GB more than the Sansa's memory. 

Paul

Please update to the latest build.  This problem was corrected in builds r24054 and r24055.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on December 18, 2009, 12:53:58 AM
For those who found corrupt file names in their .rockbox directory I would suggest formatting the internal drive with the OF.  It seems the damage is all contained within .rockbox but I have been unable to delete just the .rockbox directory.  Simply reinstalling an updated revision will not remove the damaged files.

Once again, my apologies for letting this slip through.  I used both test_disk and various size file/directory copies from disk to disk to test and found no problems.  I'm a bit busy in the role of Santa's elf at the moment but I'll get 4 bit widebus up on flyspray shortly and see if we can figure it out.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: mc2739 on December 18, 2009, 07:15:29 AM
The "Data abort at 30800968" looks like it might be another problem. Check FS#10860 (http://www.rockbox.org/tracker/task/10860) for more details.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: yelped on December 18, 2009, 01:51:29 PM
Before I updated to the build that reverted the 4-bit wide bus, almost my whole .rockbox directory got deleted.

But now it looks OK.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: peppi on December 23, 2009, 03:29:56 PM
installed rb r24102-091223 on my Sansa e280v2 using original firmware  03.01.16e.

first look is fine! waiting for a long time getting back to rockbox on my device (had a ipdod nano before). short I am happy!! thanks to all of you doing all this work. it is a xmas present for me.

And now the best: It learned a new feature radio FM not available before!

I hope the information I posted is somewhat helpful to you.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: pentavalle on December 25, 2009, 06:13:46 AM
Hi, i just want to say that current dev build r24112 of rockbox for e200v2 is wrongly compiled for ipod. see inside http://build.rockbox.org/data/rockbox-sansae200v2.zip, it contains rockbox.ipod.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Jason Arthur Taylor on December 29, 2009, 10:10:14 PM
I got a Sansa Clip+ for Christmas.  I got 15 more days to stick whatever firmware I feel like on it and still be able to return it to Sansta.

Officially, Rockbox does not work on the Clip+.  I think the Clipplus and ClipV2 are similar chips, from what I saw so far.  This thread is 90 pages.  Could some kind sole (FlynDice?) shed some color or gut feelings on the chances I would have in getting rockbox working on this sansa clipplus 2gb unit in the next couple of months?  Seems like development is really taking off for rockbox, but fact is, seems like the smart thing to do is return this since it isn't supported.  Of course, that is the reason newer things aren't supported.  So if everyone did what I am probably going to do, rockbox would only worko n 1 machine, which would really suck.  I might be able to put up a $$ bounty to get rockbox working on the clip+ but it would not  be much since I am dirt poor.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: yapper on December 29, 2009, 10:20:49 PM
Please read the sticky at the top of the New Ports section http://forums.rockbox.org/index.php?topic=21176.0

Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on December 29, 2009, 10:22:10 PM
Could some kind sole (FlynDice?) shed some color or gut feelings on the chances I would have in getting rockbox working on this sansa clipplus 2gb unit in the next couple of months? 

Sandisk hasn't released a firmware update yet for the Clip+, and without one we have no way to try and patch the firmware and upload a bootloader.  
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: GodEater on December 30, 2009, 03:03:41 AM
I might be able to put up a $$ bounty to get rockbox working on the clip+ but it would not  be much since I am dirt poor.

It is unlikely that offering a bounty of any amount would be accepted. The reasons for this have been covered before, but in brief :

Anyone taking the bounty would basically be profiting from a massive amount of work that has already been done by other Rockbox developers, which is somewhat unfair.

Edit: Since we've had this question before, and since it's starting to come up with some regularity, I've now updated the wiki page about donating to Rockbox : http://www.rockbox.org/wiki/DonatedMoney
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on December 30, 2009, 04:24:44 AM
Could some kind sole (FlynDice?)

Wow, now I'm getting called a fish outside of the poker game... :P

I think I can say with certainty that the clip+ will not be running a usable form of rockbox in the next 15 days.  On the other hand it seems  that most targets are not being sold at retail when rockbox becomes usable on them.  If you return the clip+ and wait for rockbox to be usable there's a pretty good chance it won't be available then, just ask all the fuze v2 & clip v2 owners.  If you want to get an idea about how long it's going to take, go back in the forum and look around Sep 08 when funman started the real heavy lifting for this thing, and follow the progression.  In the meantime the OF is not all that terribly bad from what I've heard.  Good Luck!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: florin on December 31, 2009, 05:17:24 AM
Maybe sending a Clip+ to someone would help? Or in other words, is anyone interested in porting Rockbox to the Clip+ but doesn't has the player?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: GodEater on December 31, 2009, 05:24:27 AM
Even if a developer has a Clip+ right now, you're still not going to see a port done in 15 days.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: Jason Arthur Taylor on January 01, 2010, 03:46:17 PM
Wow, now I'm getting called a fish outside of the poker game... :P
hehe.  I need to learn to spel sumdai.  I had to google to know that a fish is a player who loses $$.

Quote from: FlynDice
I think I can say with certainty that the clip+ will not be running a usable form of rockbox in the next 15 days. 

Sorry for being unclear, since GodEater repeats this error, but I never asked that.  I think I just asked what the chances were in the next couple of months.:
Quote
Could some kind sole (FlynDice?) shed some color or gut feelings on the chances I would have in getting rockbox working on this sansa clipplus 2gb unit in the next couple of months?
The 15 days is how long I had to test it on behalf of anyone who had a potential port working who was afraid to brick their plus and wanted a guinea pig (since I would have a good chance of returning it even if bricked).
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: GodEater on January 01, 2010, 03:50:15 PM
Even two months is extremely unlikely.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: jonstrength on January 04, 2010, 07:07:33 PM
Is it worth trying the test builds on my fuze? Are they functional at all and is it easy to revert back to the original firmware?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on January 04, 2010, 07:10:55 PM
Yes, Yes and Yes, but if you don't develop you should better use the rockbox utility (http://www.rockbox.org/wiki/RockboxUtility)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: epithetless on January 04, 2010, 08:58:34 PM
...Unless you have a v2 Fuze, in which case you shouldn't bother.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: tessarakt on January 05, 2010, 09:52:36 AM
I installed rockbox on an e200v2 yesterday. Works fine, except for a very high energy consumption. I could not find anything on the Wiki page, so I am asking here: Is this known? Do you have an idea as to the reason? Anything I can do as a layman?

Cheers,

Jens
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on January 05, 2010, 10:03:25 AM
http://www.rockbox.org/wiki/SansaRuntime

Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: BlueHazzard on January 07, 2010, 11:13:34 AM
Hallo,
i just updated my sansa e250v2 to the actual rev r24195. Now i get a lot of *Panic* always i made something on the sd card.

The error:
"*PANIC*
SD Xfer read err:0x8 Disk1"

my SD Card: kingston 4GB microSD HC
in the rb disk info is written that the speed is 50MBit/s

thanks
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on January 08, 2010, 01:53:23 AM
@BlueHazzard

Do you have another card to try?  That error is a data timeout while trying to read from the uSD card, I would suggest running chkdsk or fsck on your uSD card to see if the filesystem is damaged.  There aren't any recent changes to the SD driver that I can pin that on.  If you can see that the speed is 50MBit/s I'm guessing that the card initializes alright and you're getting the panics while playing or trying to play?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: TimNixon on January 08, 2010, 10:02:09 AM
Congrats to the team, especially for fixing the mpeg playback.
Probably not the right place to ask, but I see the remaining needs as USB support, and perhaps enabling line-out on the griffin dock.
Is there any action planned on these items? I know there's a thread about the griffin docks lineout (http://forums.rockbox.org/index.php?topic=22942.0)

Thanks again
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on January 08, 2010, 10:08:12 AM
Is there any action planned on these items? I know there's a thread about the griffin docks lineout

We don't plan anything, but as far as I know no one is actively working either.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: BlueHazzard on January 08, 2010, 10:41:43 AM
@BlueHazzard

Do you have another card to try?  That error is a data timeout while trying to read from the uSD card, I would suggest running chkdsk or fsck on your uSD card to see if the filesystem is damaged.  There aren't any recent changes to the SD driver that I can pin that on.  If you can see that the speed is 50MBit/s I'm guessing that the card initializes alright and you're getting the panics while playing or trying to play?

Hello,
no i haven't a other card to try... And yes, I get the error while playing. I can play a few seconds and then cames the panic...
I don't think, that the file system is corrupt, because the original firmware has no problem....
My first version is very very old. I don't remember anymore the revision... But i think that was a rev before the tries with voltagescaling and so on....

thank's
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: OldOne on January 08, 2010, 12:36:25 PM
I have posted before that some cards have problems with the voltage scaling.

My solution has been to have second build of rockbox with the voltage scaling set to 1.15 rather than 1.10 to use for my problem cards.

You can try going from the main menu to system then debug then CPU frequency.  Rotate the wheel counter clockwise a click or 2 and CPU from 62000000 to 248000000 and boost counter 1.  Press left button to return to menu and try playing from card again.  This raises the voltage as well as cpu speed.   If boosting  solves your playback from card then your card is one that needs a little higher voltage to work properly. 

To undo the boost go back to CPU Frequency and turn wheel to right until it returns to boost counter 0.   

The voltage scaling helps with battery life and is desired but I have 2 PQI cards that dont work properly at the 1.10 level. 

I wonder if the 1.125 level is a possible choice.  FlynDice would know.

Let us know if boosting as described above makes any difference.

Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: tomers on January 09, 2010, 04:20:07 AM
I have posted before that some cards have problems with the voltage scaling.

Is it possible that the driver will have some sort of internal database of different cards, to help it decide the proper voltage to use?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on January 09, 2010, 10:56:44 AM
@BlueHazzard

Since you've updated from a much older build I would tend to agree with  what OldOne posted above.  There is no 1.125 setting, you can use 1.05, 1.10(current), 1.15, or 1.20.  If you can build it's a rather simple adjustment to line 396 of system-as3525.c from CVDD_1_10 to CVDD_1_15.

Does anyone have any thoughts on perhaps disabling voltage scaling again?  It appears right now it only adds about 30 mins runtime.  I have tried to reproduce the results I was getting back in June(17 hrs) but have been unable to do so. 
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: kugel. on January 09, 2010, 11:27:03 AM
We do it wrong if the OF handles those cards and also has voltage scaling.

Also, we boost on any microSD access (and thus raise the voltage), so in theory all cards should work if they work without voltage scaling. It looks like the switching doesn't work right yet.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: BlueHazzard on January 09, 2010, 02:05:43 PM
I have found that sometimes i can access the card in the "explorer" and play the files.
The manual boosting is working, when i boost then i can access the card without any problems...

So i think also that the problem is the correct boosting on card access.

At the moment i have slight problems with cygwin, so i can't compile, but I' m working on it....

thanks 
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: mc2739 on January 11, 2010, 09:06:28 PM
Does anyone have any thoughts on perhaps disabling voltage scaling again?  It appears right now it only adds about 30 mins runtime.

It looks like voltage scaling is causing problems with recording to the microSD card. See FS#10810 (http://www.rockbox.org/tracker/task/10810)

I think it would be a good idea to disable the voltage scaling and see if the microSD problem reports decrease.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: saratoga on January 12, 2010, 02:08:37 PM
Has running the core at 200MHz max and keeping voltage low been tried?  I wonder if that also has SD issues.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on January 12, 2010, 02:56:31 PM
Has running the core at 200MHz max and keeping voltage low been tried?  I wonder if that also has SD issues.

Yes I've tried it but my player/uSD card are not particularly fussy it seems....
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: psychowood on January 12, 2010, 07:00:10 PM
Sandisk has just released the first firmware update (http://forums.sandisk.com/sansa/board/message?board.id=clipplus&thread.id=2911) for the Clip+.

This does mean that we've got da bootloada, don't we?  ;D
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: FlynDice on January 12, 2010, 07:22:27 PM
I have disabled voltage scaling with r24217.  The code is still in place but I've #ifdef'd it with HAVE_ADJUSTABLE_CPU_VOLTAGE. If you want to continue using it just define that at some point and it should include the code.

If you are one of the folks that have been having uSD card issues would you please let us know if this takes care of your issues.

Thanks!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on January 12, 2010, 09:39:31 PM
This does mean that we've got da bootloada, don't we?  ;D

No, that just means work can began on Clip+, so don't expect da bootloada anytime soon.

The file format is identical to other Sansa AMS, with only a new ID for Clip+ (0x28)

With a very quick look, the firmware looks like Clipv2, so Clip+ owners should look if the buttons known on Clipv2 are also present on Clip+

Don't hesitate to ask for help though, as before this step is done you can very easily brick your devices.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: JdGordon on January 12, 2010, 09:48:52 PM
funman: I've got a clip+ in peices, can you kick me in the right direction to get things going? or alternatively do you want it?

hehehehe.... I've got a modified bootloader on my clip+...

edit2: no i dont :p i have a very light brick
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: funman on January 12, 2010, 11:01:34 PM
So current code in SVN works, but enabling the same USB check than Clipv1 & v2 bricked JdGordon's Clip+ :(

The OF might rely on a specific value of GPIOA_DIR, so be sure to restore all the registers you modify.

EDIT: You could check buttons by trying this (don't forget to save & restore the registers you modify!):


I think they are all the 8 buttons but power and hold

The LCD is accessed using SSP, unlike all other models which use DBOP
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: OldOne on January 14, 2010, 10:17:09 AM
Re:Voltage Scaling

Just some brief tests.  Yes my problem PQI 8gb cards work fine with voltage scaling disabled.
My A-Data card was corrupted when recording to it with voltage scaling enabled.  Otherwise it worked perfectly at 1.10.  I will run a battery bench both ways to get an idea of how it affects battery life and post the results.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: FlynDice on January 23, 2010, 02:13:40 AM
@funman:

Could you give a quick update the status for the clipv2.  If I've pieced things together correctly you've got it booting with an operating display and the sd storage makes it past the initialization stage,  but you don't know how to initiate a transfer yet.  How am I doing so far?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: funman on January 23, 2010, 08:34:51 AM
FlynDice, you got it right.

Also all the buttons are working, it can help while debugging (like printing some message and waiting a button press before continuing execution).

Unhelpful reportedly had some problems with initialization but it sometimes worked, so this problem can be left for later.

sd-as3525v2.c has all the info I found so far, continue the reverse engineering is left as an exercise to the reader :)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: FlynDice on January 26, 2010, 08:32:22 PM
Clip+ 2Gig on the way.

Willing to risk bricking 1 unit for the project......



EDIT:
@funman:

Looking at the diff you gave me for dualboot.s and trying to understand the process.  We're reading and testing pin A1.  So I get the dualboot bootloader installed and then I turn the player on and hold a button.  If It boots with a delay we've found a match, if there is no delay we shutdown and start again with a different button.  Is this the general idea?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: funman on January 29, 2010, 11:16:59 AM
Looking at the diff you gave me for dualboot.s and trying to understand the process.  We're reading and testing pin A1.  So I get the dualboot bootloader installed and then I turn the player on and hold a button.  If It boots with a delay we've found a match, if there is no delay we shutdown and start again with a different button.  Is this the general idea?

Right, although we don't know if holding one particular button will set or clear A1.

First thing I would do is use unmodified dualboot.S (mkamsboot won't work out of the box, i'll let you figure why).

If it produces a brick we'll know there is something seriously wrong.

Then boot without pressing any button, then pressing one button, then pressing another one.

Just look at the delay presence in the majority of the boots and you'll know the default state.

Then boot pressing all buttons one by one and check if the default state change.


Note: looking at my previous post, it mentions setting GPIOB pin 1 and waiting a hair, I'm not sure if i've put that in the diff I sent you.

Writing a pin is more difficult, I'm not sure if you can know the previous value to restore it after your code has run. (Sounds a bit paranoiac if this pin is changed by button code in OF, but you never know..)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: FlynDice on January 29, 2010, 03:54:13 PM
I'm assuming I can just use a clipv2 bootloader build for this right?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: funman on January 29, 2010, 04:50:57 PM
Any binary will fit as long as you run scramble -add=cli+ on it, else mkamsboot will refuse it.

You can select sansaclipplus in configure but i'm not sure if the bootloader builds.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: FlynDice on January 30, 2010, 01:57:16 AM
@funman:

I've got a patched firmware with unmodified dualboot.s ready to go.     scramble -add=cli+ did the trick.  As far as the modified dualboot.s goes the diff you gave me does not set the GPIOB pin, is that something I need to add now or would that be the next step?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: funman on January 30, 2010, 02:11:08 AM
Not sure if it's needed, testing will tell!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: funman on January 30, 2010, 05:02:04 PM
I just ran battery bench on my Fuze to calculate proper current drawing from the battery (it would be nice to have normal battery life estimation in the 3.5 release)

Runtime: 8h40

The first message of battery_bench tells the battery level was 91%, the second one 92%, so it was not completely full. I believe I had waited until the OF stops displaying the charging icon before running the test, I will check for the next bench.

Correcting with the battery level, 8h40 / 92 * 100 = 9h25


I think it's weird because the benchmark ran 2 months ago on SansaRuntime (http://www.rockbox.org/wiki/SansaRuntime) shows almost 12h


If there are a lot of differences between different Fuzev1, I'm not sure which values we should use for battery life estimation.


Here is my config.cfg:
Code: [Select]
volume: -8
repeat: all
selector type: pointer
idle poweroff: 5
brightness: 7
show files: all
rec format: mpa3
tagcache_autoupdate: on
fmr: /.rockbox/fmpresets/dijon.fmr
font: /.rockbox/fonts/13-Nimbus.fnt
wps: /.rockbox/wps/star.wps
lang: /.rockbox/langs/francais.lng
backdrop: /.rockbox/backdrops/andreo.bmp
button light timeout: 3

brightness and button light timeout shouldn't affect the bench because I only looked 2 or 3 times to see if the Fuze was off.

Could volume affect the benchmark if there are no headphones plugged in ?

EDIT: played mp3 44.1kHz joint stereo at 128kbps
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: saratoga on January 30, 2010, 05:47:13 PM
It may just be differences in battery capacity.  You could test the OF to be sure (record the OF via line in on your PC and see how long it takes the wav to go silent). 

Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: FlynDice on January 31, 2010, 01:05:29 AM
I got 9:48 on my e280v2 with r24382

No clip+ today, hoping for Monday now.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: funman on January 31, 2010, 12:48:13 PM
In fact it seems my battery won't go past 91%, running bench with backlight always on
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: mc2739 on February 01, 2010, 06:55:27 AM
@funman

Normal battery bench results posted on SansaRuntime (http://www.rockbox.org/twiki/bin/view/Main/SansaRuntime)

Battery bench with backlight on resulted in 7:10:14.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: funman on February 01, 2010, 07:12:09 AM
With BATTERY_CAPACITY = 730,

That gives:

CURRENT_NORMAL = 730 / (10+37/60.) = 69mA per hour
CURRENT_BACKLIGHT = (730/(7+10/60.)) - (730 / (10+37/60.)) = 33mA per hour

EDIT: not sure if mA per hour makes sense ..
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: mc2739 on February 01, 2010, 07:35:50 AM
funman,

my battery capacity is 750mAH, not 730mAh.

It was bought as a refurb, so may not have the original battery.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: tessarakt on February 01, 2010, 10:16:34 AM
Is it normal that the battery percentage jumps up and down? It was at 39%, then I had the light on and it moved down until 34%, then it went up to 40% again while I did not touch it, now it is at 35% again ...
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: saratoga on February 01, 2010, 11:29:01 AM

EDIT: not sure if mA per hour makes sense ..

Battery capacity has units of mA*hours, so its actually mA*hours per hour which is simply mA.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: funman on February 01, 2010, 11:32:20 AM
Is it normal that the battery percentage jumps up and down? It was at 39%, then I had the light on and it moved down until 34%, then it went up to 40% again while I did not touch it, now it is at 35% again ...

Which model ?

With "I had the light on", do you mean the LCD backlight was active ?

What is your setting for backlight timeout ?

If you go into the debug screen of battery you can see a graph with the voltage, is it jumping up and down or only decreasing ?

(I assume yes, but are you using a current build of today?)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: tessarakt on February 01, 2010, 12:36:04 PM
e280v2. Yes, I mean active LCD backlight. I have to look for the exact settings later, but it switches off after some seconds without input. (It seems as if the battery "recovers" in phases where the backlight is off.) I'll look at the battery debug screen later. Yes, I updated to a build of today this afternoon.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: FlynDice on February 01, 2010, 09:55:52 PM
@funman:

I have flashed my clip+ with the unmodified dualboot.S code.  It seems to work just fine but there does not seem to be a any extra delay in addition to the boot time for an unpatched firmware(as it appeared there should be from looking at dualboot.S).  I tried upping the delay value from 0x500000 to 0x5000000 & 0x50000000  with no difference in the results.  Looking closer now and scratching my head.  Am I being a bit too paranoid do you suppose? ???


Edit:
After looking through the code more closely I still think I should be seeing a delay with the patched firmware in relation to the unpatched and I do not.  After I copy the newly patched firmware file to my clip+ it does do the upgrading firmware routine.  And when I turn it back on it starts up asking for settings like it normally does after a firmware upgrade.  However, there is no added delay when booting.  In all cases there is about a 1 sec lag between pushing the power switch and seeing the OF splash start up.  This leads me to believe that the delay code(5 sec in SVN & much more in my modified) in dualboot.S is somehow not running.

Here are the steps I used to produce my patched firmware:
- I built a clipv2 bootloader (I don't really think this matters as I'm not running actual rockbox code yet....)
- I used scramble -add=cli+  to produce bootloader-cli+.sansa
- I modified mkamsboot to work for clip+(just removing the #if (0)) and built it.
- I ran mkamsboot to produce patched firmware named Rclppa.bin
- I loaded the patched firmware on the clip+ and renamed to clppa.bin
- After seeing no delay the first time, I modified dualboot.S to try to increase the delay but was not successful.

Here is the diff and console output that I saw.       http://pastie.org/807886

The patched firmware that I used seemed to work identically to the unpatched. 
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: mc2739 on February 03, 2010, 06:18:51 PM
@FlynDice

Check your forum PMs
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: FlynDice on February 03, 2010, 07:15:04 PM
@ mc2739:

You got it exactly right Thanks!!!!   ;D

I still had to modify the delay as the 0x500000 only delayed about .5 secs and was not very obvious.  I wonder if this means the processor is being clocked a lot higher?  We'll see!



EDIT:

I'm attaching a .pdf with my results for GPIOA.  I've got to figure out where to go from here so If someone has an idea please speak up. 

I would find it odd if this wasn't a keyscan type thing similar to the clip & clipv2 but I can't make it fit together in my head just yet.  Moving on to GPIOB,C,D with the same code does not seem logical to me.

EDIT:

Just went back & found funman's post with some hints --> http://forums.rockbox.org/index.php?topic=14064.msg160803#msg160803

EDIT:

I've found all of the buttons except pwr now.  There is no hold button.  The OF implements the hold function with a long home press.
New .pdf attached.

EDIT:

I now have Dualboot working with left button.  No Rockbox code yet, just a delay to simulate branching to rockbox.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: funman on February 05, 2010, 07:23:43 AM
good job!

Did you forget to update dualboot.c / dualboot.h when the delay wasn't changed?

I have one remark before you commit your diff:

You should find the USB pin: I see that the OF writes GPIOB before reading buttons, if you skip this step reading the left button might just not work on some specific Clip+.

That's the same process than checking buttons, you can add the check after checking for left button since you know it works on your Clip+.
EDIT: only add the check after left button in your test build, once you found the USB pin it should be the first check (as it is in dualboot.S) as I believe it's much less likely to fail than a button check.


Once it's done you should commit it, so you can start LCD code and maybe be helped by others :)

I'll look at making the Clip+ bootloader target build
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: funman on February 05, 2010, 10:59:25 AM
Just found this (http://hi.baidu.com/serial_story/blog/category/%D4%AD%B4%B4%BB%F2%D5%FB%C0%ED) on google.

In the first post:
Quote
WARNING: drivers/usb/host/as352xhcd.o(.text+0x2be0)

In the third post:
Quote
AS353X NAND Driver, (c) 2010 austriamicrosystems

And a bit more down:
Quote
insmod /lib/modules/2.6.28.4-as353x-patch-svn1406/kernel/drivers/usb/gadget/dwc_otg/dwc_otg.ko
dwc_otg: version 2.60a 05-JUN-2009
...
dwc_otg: Detected: Synopsys DWC OTG 2.60a Core

If one of you can write chinese and feel like asking them where they got their linux sources and if they are willing to share, perhaps we could find some SD code!

Note we already have the source for dwc_otg (link on the SansaAMS page)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: FlynDice on February 05, 2010, 01:33:07 PM
Did you forget to update dualboot.c / dualboot.h when the delay wasn't changed?

Yes that was exactly the problem but mc2739 was clever enough to figure it out for me so I could continue!

I have checked all 32 GPIO pins and USB does not set any of them high so far as I can see.  There are some pins that seem to be set high always and I'm going to check them to see if perhaps USB will pull them down low.

As far as writing to GPIOB goes, what do I need to write? I'm assuming you mean change the gpio_dir to 1 for output, write a value(0xff or 0??) and then switch the gpio_dir back to 0 and read the pin?

I see you've been busy working on the clip+ build also.  I'm very confident in my left button dualboot so I think I'll take a break from chasing GPIO pins and see what happens if I let rockbox try to boot!


Edit:  Bootloader builds just fine but no sign of anything on clip+ when I let rockbox try to boot.

Long pwr press to reset and dualboot into OF lets me plug usb back in and flash the original OF firmware back to it.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: funman on February 05, 2010, 03:12:48 PM
As far as writing to GPIOB goes, what do I need to write?
saved_gpiob = GPIOB_DIR;
GPIOB_DIR = saved_gpiob | (1<<0);
GPIOB_PIN(0) = 1;
i = 500;
while(i--) ;
GPIOB_DIR = saved_gpiob

and then read the buttons.


The backlight might be different for Clip+, what would help debugging is to find the button light.

Note if you power on the Clip+ fast after power off there might still be data in GRAM, and if you plug the USB cable it might power a bit the LCD and you could see something on the screen, that worked for the Clipv2.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: FlynDice on February 05, 2010, 04:12:13 PM
The backlight might be different for Clip+, what would help debugging is to find the button light.

Unfortunately there seems to be no buttonlight on the clip+ :(

EDIT

Using the GPIOB write did not change the results at all it seems.  Here's the code I used:    http://pastie.org/812138

When booting to the rockbox bootloader there was no sign of life at all.  I tried holding/pressing buttons, plugged in USB listened on headphones, shined a light on the screen etc..     Nothing, nada ,zilch.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: funman on February 06, 2010, 10:05:55 AM
If it didn't make a difference I think it should be used, because there could be a difference on some models.

Now let's hunt the USB pin !

EDIT: Now it seems it is never explicitely read in Clipv1/Clipv2 but rather written to .. Not sure how else we could detect rather than by brute force like you did..

EDIT2: We could use adc_read(VBUS): it reports ~ 0.16V when usb isn't plugged and around (a bit less) 5V when USB is plugged. Would i2c read in mkamsboot be overkill ?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: FlynDice on February 06, 2010, 11:24:31 AM
I found the clip+ pwr button on D6 by using the  GPIOB write with this code:  http://pastie.org/812463

It was very tricky as it's difficult to press the pwr button to turn it on and then press it again quickly enough to have it read....
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: bertrik on February 08, 2010, 12:59:14 PM
I did a few battery runtime benches on my clip v1.

Somehow my clip v1 (1GB with FM) seems to get a lot longer runtime than those of other people.
I'm getting more than 8h with rockbox while other people seem to get only around 5h30.

I wonder what causes these runtime differences between people. I think it's not just a bad battery because people with low runtime in rockbox still seem to get normal runtimes in the OF.

To experiment a bit, I ran a benchmark with the CPU voltage regulator forced in a different mode: "direct length regulation" instead of auto (which probably chooses the "charge pump with length regulation" mode under light loads). With this change I got 5h48 runtime instead of 8h14, much closer to the result of other people.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: saratoga on February 08, 2010, 01:26:09 PM
Its possible we don't init some piece of hardware, and some clips default to different settings.  I know with PP different PP devices would boot with random pieces of hardware enabled, resulting in different idle currents until we figured out how to turn them off.  Something similar may be happening here.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: matsch on February 08, 2010, 04:07:01 PM
I did a few battery runtime benches on my clip v1.

Somehow my clip v1 (1GB with FM) seems to get a lot longer runtime than those of other people.
I'm getting more than 8h with rockbox while other people seem to get only around 5h30.

To experiment a bit, I ran a benchmark with the CPU voltage regulator forced in a different mode: "direct length regulation" instead of auto (which probably chooses the "charge pump with length regulation" mode under light loads). With this change I got 5h48 runtime instead of 8h14, much closer to the result of other people.

There is bit 7 in AS314_CP_DCDC3_SETTING  which defines a lower margin for changing to length regulator when setting to 1. In rockbox it is set to 0.  Maybe there are some clips having a lower input voltage for the regulator. The voltage margin after the charge pump voltage divider is to low and they stay in length regulation.  There is register IOVDDp in the as3525 data sheet. If it is set to 1 (2.99V) risk is higher for length regulator only.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: FlynDice on February 08, 2010, 05:39:12 PM
This is how I understand the charge pump/length regulation scheme.  There are some charts in the datasheet graphing voltage vs current for both methods of regulation.  The charge pump is the more efficient method to provide current but cannot maintain the voltage in the desired range at higher current draws.  When the voltage drops too much it switches to length regulation to provide the needed current and maintain an acceptable voltage.  So if you change the switching margin what you are doing is allowing the voltage to get lower before switching to length regulation.  I don't know if that's OK or not...  I checked on an almost empty battery and it was still running in charge pump mode.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: FlynDice on February 09, 2010, 01:45:29 AM
@ funman:

Here is the code I tested for clip+ dualboot: http://pastie.org/815858.  It seems to work as far as branching to the OF when a button is pushed but there's something weird going on if there's no button pushed.  It should just take an extra 4 secs then boot the of. Instead it just stays dark.  I thought perhaps it was just the timer on the lcd but pushing a button won't wake the display.  Interestingly, a normal power off pwr button press does power down normally.  No need for the long power reset.  I tried removing the last 4 sec delay and this was still happening.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: funman on February 09, 2010, 04:55:17 AM
Hm i spotted one problem: I forget to modify r1 after writing new GPIOB_DIR and before writin B0

Also can you try without resetting B0 ?

If this doesn't work then I have no idea and you should forget everything I said ..
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: funman on February 09, 2010, 05:04:50 AM
There's a number on the bottom of my Clip v1 (1GB with FM), saying BB0806AYJK. Perhaps this can be correlated to rockbox runtime.

Mine is BE0712A0LK and has a short battery life, I would think this is a serial number and not a hardware revision like is written on the PCB
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: FlynDice on February 09, 2010, 01:25:40 PM
@funman

I tried the modifications you suggested but still no luck.  The dualboot function with the left & home keys works with that code, ie if you press one of the buttons during boot the of boots fine, but if you don't hold a button the of won't boot.  Just to check on my test setup I substituted the code that I know works and the of booted fine without a button press.  I'm going to correct the error I made in unsetting B0 but I think that's all I should do for right now.

EDIT:  Here's the code I used :  http://pastie.org/816726

EDIT:  I can confirm that the clip+ has the same cp15 id register value: 0x41069265 as the clipv2 so ARM926EJ-S.
           I can get some yes or no answers using a delay so let me know if you have questions that fit that profile.

EDIT:  CCU_VERS  main version id : 2  sub version id: 3

EDIT:  It seems I can also find values in registers bit by bit but it takes a lot more work....
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: ranma on February 11, 2010, 07:25:38 AM
Since my original report on the 'Sandisk - Installation/Removal' subforum was delted I'll report it here, where it should be appropriate:

I tried installing rockbox on my c240v2 according to the instructions in the "Installation for Unusable (other AMS Sansas)" section of http://www.rockbox.org/wiki/SansaAMS

I ran into the  "C200V2 bootloader installed but no effect" issue, but was able to work around it by patching dualboot.S, apparently the USB pin check is borked for my device and always branches to the original firmware even if the device is not plugged into USB.
See also http://forums.rockbox.org/index.php?topic=23263.msg162027#msg162027

After flashing the firmware with my updated dualboot, it now tries to boot rockbox, but apparently fails.

The exact behaviour differs depending on whether or not .rockbox/rockbox.sansa is there, so I'm assuming that the second-stage bootloader works so far.
However as far as I understand the second stage is supposed to turn on the lcd, show a splash and report an error there if rockbox.sansa is missing. My lcd does not turn on though.
What I do see:

If .rockbox/rockbox.sansa is not there:
Middle button light turns on for some time, device powers off.

If .rockbox/rockbox.sansa is there:
Middle button light turns on for some shorter time, turns off, both middle button and menu turn on
for some longer time, both turn off, pattern repeats.

If I boot while holding right it boots the original firmware just fine, so my patched dualboot works for me.

I tried building a newer second stage bootloader from svn than the Nov. 21st 2009 version at http://download.rockbox.org/bootloader/sandisk-sansa/c200v2/bootloader-c200v2.sansa
But the behaviour stayed the same after flashing that one.

Hope that helps. :)

Index: dualboot.S
===================================================================
--- dualboot.S  (revision 24590)
+++ dualboot.S  (working copy)
@@ -93,12 +93,14 @@
 #endif
 
 #ifdef USB_PIN  /* TODO : remove this check when we'll have an USB driver */
+/*
         ldr     r0, =GPIOA
         mov     r1, #0
         str     r1, [r0, #0x400]
         ldr     r1, [r0, #(4*(1<<USB_PIN))]
         cmp     r1, #0
         bne     boot_of
+*/
 #endif
 
         /* Here are model specific tests, for dual boot without a computer */
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: funman on February 11, 2010, 09:37:29 AM
So the problem is the USB check gives a false positive ?

What happens if you power it with the USB cable ?

Some c200v2 might need something more to enable the backlight, just like what happened on the Clipv1
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: ranma on February 11, 2010, 11:38:57 AM
So the problem is the USB check gives a false positive ?

What happens if you power it with the USB cable ?

Some c200v2 might need something more to enable the backlight, just like what happened on the Clipv1

As said on irc, if I shine a bright flashlight on the display I can see that it's just the backlight that is not powered.
New info:
If I put an infinite loop into the as3525 reboot function, it stops at the 'usb inserted' logo, so that seems to be the point where it reboots. (USB is not attached at this point)
If I change usb_detect to always return USB_EXTRACTED it does not reboot and I can navigate the menu!
And it mp3 playback works on a first quick test. It even changed over to the next mp3 (now on the third one).
Now if only the backlight would work...
Maybe the GPIOs are different on this one? Since both USB_DETECT and BACKLIGHT don't work?

[edit]
Ok, I've got it.  On my c200v2 backlight is controlled by A7 instead of A5.
I now have working backlight.
Also interesting:
Even though I've disabled the USB detection it reacts to USB plug/unplug as if a button was pressed.
i.e. the buttonlight goes on and display is switched on if it was off.
[/edit]
[edit3]
Ok, I've now found out that the reaction to USB plug/unplug is due to the SYS_CHARGER_CONNECTED and SYS_CHARGER_DISCONNECTED events.
[/edit3]

[edit2]
Here are modified binaries if someone wants to try (on his own risk!):
http://uguu.de/~ranma/rockbox-c200v2/
Index: firmware/target/arm/as3525/sansa-c200v2/backlight-c200v2.c
===================================================================
--- firmware/target/arm/as3525/sansa-c200v2/backlight-c200v2.c   (revision 24590)
+++ firmware/target/arm/as3525/sansa-c200v2/backlight-c200v2.c   (working copy)
@@ -30,7 +30,7 @@
 
 bool _backlight_init(void)
 {
-    GPIOA_DIR |= 1<<5;
+    GPIOA_DIR |= 1<<7;
     return true;
 }
 
@@ -47,12 +47,12 @@
 #ifdef HAVE_LCD_ENABLE
     lcd_enable(true); /* power on lcd + visible display */
 #endif
-    GPIOA_PIN(5) = 1<<5;
+    GPIOA_PIN(7) = 1<<7;
 }
 
 void _backlight_off(void)
 {
-    GPIOA_PIN(5) = 0;
+    GPIOA_PIN(7) = 0;
 #ifdef HAVE_LCD_ENABLE
     lcd_enable(false); /* power off visible display */
 #endif

Index: firmware/target/arm/as3525/usb-as3525.c
===================================================================
--- firmware/target/arm/as3525/usb-as3525.c   (revision 24590)
+++ firmware/target/arm/as3525/usb-as3525.c   (working copy)
@@ -61,9 +61,11 @@
 int usb_detect(void)
 {
 #ifdef USB_DETECT_PIN
+   /*
     if (GPIOA_PIN( USB_DETECT_PIN ))
         return USB_INSERTED;
     else
+    */
 #endif
         return USB_EXTRACTED;
 }
[/edit2]
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: bertrik on February 11, 2010, 03:43:42 PM
Regarding the power consumption issue: I asked jobec to check the contents of the SYSTEM and CVDD registers on his power-hungry clip v1. They were exactly the same as on my clip (SYSTEM=0x29 -> PVDD trimmed to 17/18 and CVDD=0x04 -> completely normal). So that doesn't explain anything, although it is slightly peculiar that PVDD is trimmed down a bit by default. We didn't check the USB_UTIL register yet though, it could still be that we're accidentally wasting power somehow on USB.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: mtee on February 11, 2010, 04:07:45 PM
Hi FlynDice,

I've been trying a little bit with the clip+ port, and I think I bricked mine. :(
I built a bootloader -> scrambled -> mkamsboot -> copied the binary image to the device's storage, then after a successful firmware upgrade, it went dead. Since it worked for you, then I'm sure I've missed something in the middle.
Anyway, I'll probably buy another one later, but until then, I'll try to help with other stuff.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: FlynDice on February 11, 2010, 06:12:45 PM
@ mtee:

Before you call it bricked try holding the pwr button for 10 sec straight to try to reset.  Did you get a branch to the of with left or home pressed?  As of now if you let it boot to the rockbox code the clip+ shows absolutely no response and appears bricked, but will reset with an extra long pwr press.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: mtee on February 11, 2010, 06:42:37 PM
@ mtee:

Before you call it bricked try holding the pwr button for 10 sec straight to try to reset. 

Tried that once I did the firmware replacement, but the device still didn't work.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: ranma on February 12, 2010, 04:43:22 AM
Battery bench on my c240v2:

Quote
Battery bench run for Sandisk Sansa c200v2 series version

Battery type: -352317087 mAh      Buffer Entries: 1000
  Time:,  Seconds:,  Level:,  Time Left:,  Voltage[mV]:, C:, S:, U:
00:02:15,  00135,     000%,     00:01,         4960,     A,  -,  -
00:03:15,  00195,     000%,     00:01,         5024,     A,  -,  -
00:04:15,  00255,     000%,     00:01,         5024,     A,  -,  -
00:05:15,  00315,     000%,     00:01,         5024,     A,  -,  -
00:06:15,  00375,     000%,     00:01,         4960,     A,  -,  -
00:07:15,  00435,     000%,     00:01,         4960,     A,  -,  -
00:08:15,  00495,     000%,     00:01,         4960,     A,  -,  -
00:09:15,  00555,     000%,     00:01,         4960,     A,  -,  -
00:10:15,  00615,     000%,     00:01,         4897,     A,  -,  -
00:11:15,  00675,     000%,     00:01,         4897,     A,  -,  -
00:12:15,  00735,     000%,     00:01,         4897,     A,  -,  -
00:13:15,  00795,     000%,     00:01,         4833,     A,  -,  -
00:14:15,  00855,     000%,     00:01,         4833,     A,  -,  -
00:15:15,  00915,     000%,     00:01,         4833,     A,  -,  -
00:16:16,  00976,     000%,     00:01,         4833,     A,  -,  -
00:17:16,  01036,     000%,     00:01,         4770,     A,  -,  -
00:18:16,  01096,     000%,     00:01,         4770,     A,  -,  -
00:19:16,  01156,     000%,     00:01,         4770,     A,  -,  -
00:20:16,  01216,     000%,     00:01,         4770,     A,  -,  -
00:21:16,  01276,     000%,     00:01,         4738,     A,  -,  -
00:22:16,  01336,     000%,     00:01,         4706,     A,  -,  -
00:23:16,  01396,     000%,     00:01,         4706,     A,  -,  -
00:24:16,  01456,     000%,     00:01,         4706,     A,  -,  -
00:25:16,  01516,     000%,     00:01,         4706,     A,  -,  -
00:26:16,  01576,     000%,     00:01,         4642,     A,  -,  -
00:27:16,  01636,     000%,     00:01,         4642,     A,  -,  -
00:28:16,  01696,     000%,     00:01,         4642,     A,  -,  -
00:29:16,  01756,     000%,     00:01,         4642,     A,  -,  -
00:30:16,  01816,     000%,     00:01,         4642,     A,  -,  -
00:31:16,  01876,     000%,     00:01,         4579,     A,  -,  -
00:32:16,  01936,     000%,     00:01,         4579,     A,  -,  -
00:33:16,  01996,     000%,     00:01,         4579,     A,  -,  -
00:34:16,  02056,     000%,     00:01,         4579,     A,  -,  -
00:35:16,  02116,     000%,     00:01,         4579,     A,  -,  -
00:36:16,  02176,     000%,     00:01,         4579,     A,  -,  -
00:37:16,  02236,     000%,     00:01,         4579,     A,  -,  -
00:38:16,  02296,     000%,     00:01,         4515,     A,  -,  -
00:39:16,  02356,     000%,     00:01,         4515,     A,  -,  -
00:40:16,  02416,     000%,     00:01,         4515,     A,  -,  -
00:41:16,  02476,     000%,     00:01,         4515,     A,  -,  -
00:42:16,  02536,     000%,     00:01,         4515,     A,  -,  -
00:43:17,  02597,     000%,     00:01,         4515,     A,  -,  -
00:44:17,  02657,     000%,     00:01,         4515,     A,  -,  -
00:45:17,  02717,     000%,     00:01,         4452,     A,  -,  -
00:46:17,  02777,     000%,     00:01,         4388,     A,  -,  -
00:47:17,  02837,     000%,     00:01,         4452,     A,  -,  -
00:48:17,  02897,     000%,     00:01,         4452,     A,  -,  -
00:49:17,  02957,     000%,     00:01,         4452,     A,  -,  -
00:50:17,  03017,     000%,     00:01,         4452,     A,  -,  -
00:51:17,  03077,     000%,     00:01,         4452,     A,  -,  -
00:52:17,  03137,     000%,     00:01,         4452,     A,  -,  -
00:53:17,  03197,     000%,     00:01,         4388,     A,  -,  -
00:54:17,  03257,     000%,     00:01,         4388,     A,  -,  -
00:55:17,  03317,     000%,     00:01,         4388,     A,  -,  -
00:56:17,  03377,     000%,     00:01,         4388,     A,  -,  -
00:57:17,  03437,     000%,     00:01,         4388,     A,  -,  -
00:58:17,  03497,     000%,     00:01,         4324,     A,  -,  -
00:59:17,  03557,     000%,     00:01,         4324,     A,  -,  -
01:00:17,  03617,     000%,     00:01,         4324,     A,  -,  -
01:01:17,  03677,     000%,     00:01,         4324,     A,  -,  -
01:02:17,  03737,     000%,     00:01,         4324,     A,  -,  -
01:03:17,  03797,     000%,     00:01,         4324,     A,  -,  -
01:04:17,  03857,     000%,     00:01,         4324,     A,  -,  -
01:05:17,  03917,     000%,     00:01,         4261,     A,  -,  -
01:06:17,  03977,     000%,     00:01,         4261,     A,  -,  -
01:07:17,  04037,     000%,     00:01,         4261,     A,  -,  -
01:08:17,  04097,     000%,     00:01,         4261,     A,  -,  -
01:09:17,  04157,     000%,     00:01,         4261,     A,  -,  -
01:10:18,  04218,     000%,     00:01,         4261,     A,  -,  -
01:11:18,  04278,     000%,     00:01,         4261,     A,  -,  -
01:12:18,  04338,     000%,     00:01,         4261,     A,  -,  -
01:13:18,  04398,     000%,     00:01,         4261,     A,  -,  -
01:14:18,  04458,     000%,     00:01,         4197,     A,  -,  -
01:15:18,  04518,     000%,     00:01,         4197,     A,  -,  -
01:16:18,  04578,     000%,     00:01,         4197,     A,  -,  -
01:17:18,  04638,     000%,     00:01,         4197,     A,  -,  -
01:18:18,  04698,     000%,     00:01,         4197,     A,  -,  -
01:19:18,  04758,     000%,     00:01,         4134,     A,  -,  -
01:20:18,  04818,     000%,     00:01,         4134,     A,  -,  -
01:21:18,  04878,     000%,     00:01,         4134,     A,  -,  -
01:22:18,  04938,     000%,     00:01,         4070,     A,  -,  -
01:23:18,  04998,     000%,     00:01,         4134,     A,  -,  -
01:24:18,  05058,     000%,     00:01,         4134,     A,  -,  -
01:25:18,  05118,     000%,     00:01,         4070,     A,  -,  -
01:26:18,  05178,     000%,     00:01,         4070,     A,  -,  -
01:27:18,  05238,     000%,     00:01,         4070,     A,  -,  -
01:28:18,  05298,     000%,     00:01,         4006,     A,  -,  -
01:29:18,  05358,     000%,     00:01,         4006,     A,  -,  -
01:30:18,  05418,     000%,     00:01,         4006,     A,  -,  -
01:31:18,  05478,     000%,     00:01,         4006,     A,  -,  -
01:32:18,  05538,     000%,     00:01,         3943,     A,  -,  -
01:33:18,  05598,     000%,     00:01,         3943,     A,  -,  -
01:34:18,  05658,     000%,     00:01,         3752,     A,  -,  -
01:35:18,  05718,     000%,     00:01,         3879,     A,  -,  -
01:36:18,  05778,     000%,     00:01,         3879,     A,  -,  -
01:37:18,  05838,     000%,     00:01,         3879,     A,  -,  -
01:38:19,  05899,     000%,     00:01,         3816,     A,  -,  -
01:39:19,  05959,     000%,     00:01,         3816,     A,  -,  -
01:40:19,  06019,     000%,     00:01,         3816,     A,  -,  -
01:41:19,  06079,     000%,     00:01,         3816,     A,  -,  -
01:42:19,  06139,     000%,     00:01,         3752,     A,  -,  -
01:43:19,  06199,     000%,     00:01,         3752,     A,  -,  -
01:44:19,  06259,     000%,     00:01,         3752,     A,  -,  -
01:45:19,  06319,     000%,     00:01,         3688,     A,  -,  -
01:46:19,  06379,     000%,     00:01,         3688,     A,  -,  -
01:47:19,  06439,     000%,     00:01,         3688,     A,  -,  -
01:48:19,  06499,     000%,     00:01,         3688,     A,  -,  -
01:49:19,  06559,     000%,     00:01,         3625,     A,  -,  -
01:50:19,  06619,     000%,     00:01,         3625,     A,  -,  -
01:51:19,  06679,     000%,     00:01,         3625,     A,  -,  -
01:52:19,  06739,     000%,     00:01,         3625,     A,  -,  -
01:53:19,  06799,     000%,     00:01,         3561,     A,  -,  -
01:54:19,  06859,     000%,     00:01,         3561,     A,  -,  -
01:55:19,  06919,     000%,     00:01,         3561,     A,  -,  -
01:56:19,  06979,     000%,     00:01,         3561,     A,  -,  -
01:57:19,  07039,     000%,     00:01,         3561,     A,  -,  -
01:58:19,  07099,     000%,     00:01,         3561,     A,  -,  -
01:59:19,  07159,     000%,     00:01,         3561,     A,  -,  -
02:00:19,  07219,     000%,     00:01,         3498,     A,  -,  -
02:01:19,  07279,     000%,     00:01,         3498,     A,  -,  -
02:02:19,  07339,     000%,     00:01,         3561,     A,  -,  -
02:03:19,  07399,     000%,     00:01,         3498,     A,  -,  -
02:04:19,  07459,     000%,     00:01,         3498,     A,  -,  -
02:05:20,  07520,     000%,     00:01,         3498,     A,  -,  -
02:06:20,  07580,     000%,     00:01,         3498,     A,  -,  -
02:07:20,  07640,     000%,     00:01,         3434,     A,  -,  -
02:08:20,  07700,     000%,     00:01,         3434,     A,  -,  -
02:09:20,  07760,     000%,     00:01,         3434,     A,  -,  -
02:10:20,  07820,     000%,     00:01,         3498,     A,  -,  -
02:11:20,  07880,     000%,     00:01,         3498,     A,  -,  -
02:12:20,  07940,     000%,     00:01,         3434,     A,  -,  -
02:13:20,  08000,     000%,     00:01,         3434,     A,  -,  -
02:14:20,  08060,     000%,     00:01,         3434,     A,  -,  -
02:15:20,  08120,     000%,     00:01,         3434,     A,  -,  -
02:16:20,  08180,     000%,     00:01,         3434,     A,  -,  -
02:17:20,  08240,     000%,     00:01,         3434,     A,  -,  -
02:18:20,  08300,     000%,     00:01,         3434,     A,  -,  -
02:19:20,  08360,     000%,     00:01,         3434,     A,  -,  -
02:20:20,  08420,     000%,     00:01,         3434,     A,  -,  -
02:21:20,  08480,     000%,     00:01,         3434,     A,  -,  -
02:22:20,  08540,     000%,     00:01,         3434,     A,  -,  -
02:23:20,  08600,     000%,     00:01,         3434,     A,  -,  -
02:24:20,  08660,     000%,     00:01,         3434,     A,  -,  -
02:25:20,  08720,     000%,     00:01,         3370,     A,  -,  -
02:26:20,  08780,     000%,     00:01,         3307,     A,  -,  -
02:27:20,  08840,     000%,     00:01,         3370,     A,  -,  -
02:28:20,  08900,     000%,     00:01,         3370,     A,  -,  -
02:29:20,  08960,     000%,     00:01,         3307,     A,  -,  -
02:30:20,  09020,     000%,     00:01,         3307,     A,  -,  -
02:31:20,  09080,     000%,     00:01,         3307,     A,  -,  -
02:32:20,  09140,     000%,     00:01,         3307,     A,  -,  -
02:33:21,  09201,     000%,     00:01,         3243,     A,  -,  -
02:34:21,  09261,     000%,     00:01,         3243,     A,  -,  -
02:35:21,  09321,     000%,     00:01,         3243,     A,  -,  -
02:36:21,  09381,     000%,     00:01,         3243,     A,  -,  -
02:36:48,  09408,     000%,     00:01,         3211,     A,  -,  -
02:37:48,  09468,     000%,     00:01,         3243,     A,  -,  -
02:38:48,  09528,     000%,     00:01,         3243,     A,  -,  -
02:39:48,  09588,     000%,     00:01,         3180,     A,  -,  -
02:40:48,  09648,     000%,     00:01,         3180,     A,  -,  -
02:41:48,  09708,     000%,     00:01,         3180,     A,  -,  -
02:42:49,  09769,     000%,     00:01,         3180,     A,  -,  -
02:43:49,  09829,     000%,     00:01,         3180,     A,  -,  -
02:44:49,  09889,     000%,     00:01,         3180,     A,  -,  -
02:45:49,  09949,     000%,     00:01,         3180,     A,  -,  -
02:46:49,  10009,     000%,     00:01,         3180,     A,  -,  -
02:47:49,  10069,     000%,     00:01,         3148,     A,  -,  -
02:48:49,  10129,     000%,     00:01,         3180,     A,  -,  -
02:49:49,  10189,     000%,     00:01,         3180,     A,  -,  -
02:50:49,  10249,     000%,     00:01,         3116,     A,  -,  -
02:51:49,  10309,     000%,     00:01,         3180,     A,  -,  -
02:52:49,  10369,     000%,     00:01,         3116,     A,  -,  -
02:53:49,  10429,     000%,     00:01,         3116,     A,  -,  -
02:54:49,  10489,     000%,     00:01,         3180,     A,  -,  -
02:55:49,  10549,     000%,     00:01,         3180,     A,  -,  -
02:56:49,  10609,     000%,     00:01,         3116,     A,  -,  -
02:57:49,  10669,     000%,     00:01,         3116,     A,  -,  -
02:58:49,  10729,     000%,     00:01,         3116,     A,  -,  -
02:59:49,  10789,     000%,     00:01,         3084,     A,  -,  -
03:00:49,  10849,     000%,     00:01,         3116,     A,  -,  -
03:01:49,  10909,     000%,     00:01,         3052,     A,  -,  -
03:02:49,  10969,     000%,     00:01,         3052,     A,  -,  -
03:03:49,  11029,     000%,     00:01,         3052,     A,  -,  -
03:04:49,  11089,     000%,     00:01,         2989,     A,  -,  -
03:05:49,  11149,     000%,     00:01,         2989,     A,  -,  -
03:06:49,  11209,     000%,     00:01,         2925,     A,  -,  -
03:07:49,  11269,     000%,     00:01,         2925,     A,  -,  -
03:08:50,  11330,     000%,     00:01,         2862,     A,  -,  -
03:09:50,  11390,     000%,     00:01,         2830,     A,  -,  -
03:10:50,  11450,     000%,     00:01,         2798,     A,  -,  -
03:11:50,  11510,     000%,     00:01,         2798,     A,  -,  -
03:12:50,  11570,     000%,     00:01,         2798,     A,  -,  -
03:13:50,  11630,     000%,     00:01,         2766,     A,  -,  -
03:14:50,  11690,     000%,     00:01,         2734,     A,  -,  -
03:15:50,  11750,     000%,     00:01,         2734,     A,  -,  -
03:16:50,  11810,     000%,     00:01,         2734,     A,  -,  -
03:17:50,  11870,     000%,     00:01,         2734,     A,  -,  -
03:18:50,  11930,     000%,     00:01,         2734,     A,  -,  -
03:19:50,  11990,     000%,     00:01,         2734,     A,  -,  -
03:20:50,  12050,     000%,     00:01,         2671,     A,  -,  -
03:21:43,  12103,     000%,     00:01,         2385,     A,  -,  -
03:21:43,  12103,     000%,     00:01,         2353,     A,  -,  -
03:22:19,  12139,     000%,     00:01,         2226,     A,  -,  -
03:22:20,  12140,     000%,     00:01,         2226,     A,  -,  -
03:23:20,  12200,     000%,     00:01,         2289,     A,  -,  -
03:24:20,  12260,     000%,     00:01,         2544,     A,  -,  -
03:25:20,  12320,     000%,     00:01,         2544,     A,  -,  -
03:26:20,  12380,     000%,     00:01,         2544,     A,  -,  -
03:27:20,  12440,     000%,     00:01,         2544,     A,  -,  -
03:28:20,  12500,     000%,     00:01,         2544,     A,  -,  -
03:29:20,  12560,     000%,     00:01,         2544,     A,  -,  -
03:30:20,  12620,     000%,     00:01,         2544,     A,  -,  -
03:31:20,  12680,     000%,     00:01,         2544,     A,  -,  -
03:32:20,  12740,     000%,     00:01,         2480,     A,  -,  -
03:33:20,  12800,     000%,     00:01,         2544,     A,  -,  -
03:34:20,  12860,     000%,     00:01,         2544,     A,  -,  -
03:35:20,  12920,     000%,     00:01,         2480,     A,  -,  -
03:36:20,  12980,     000%,     00:01,         2480,     A,  -,  -
03:37:20,  13040,     000%,     00:01,         2480,     A,  -,  -
03:38:20,  13100,     000%,     00:01,         2480,     A,  -,  -
03:39:20,  13160,     000%,     00:01,         2353,     A,  -,  -
03:40:20,  13220,     000%,     00:01,         2416,     A,  -,  -
03:41:20,  13280,     000%,     00:01,         2353,     A,  -,  -
03:42:20,  13340,     000%,     00:01,         2353,     A,  -,  -
03:43:20,  13400,     000%,     00:01,         2289,     A,  -,  -
03:44:20,  13460,     000%,     00:01,         2289,     A,  -,  -
03:45:20,  13520,     000%,     00:01,         2289,     A,  -,  -
03:46:20,  13580,     000%,     00:01,         2226,     A,  -,  -
03:47:20,  13640,     000%,     00:01,         2226,     A,  -,  -
03:48:20,  13700,     000%,     00:01,         2162,     A,  -,  -
03:49:20,  13760,     000%,     00:01,         2162,     A,  -,  -
03:50:20,  13820,     000%,     00:01,         2035,     A,  -,  -
03:50:24,  13824,     000%,     00:01,         1939,     A,  -,  -
03:51:24,  13884,     000%,     00:01,         2035,     A,  -,  -
03:52:24,  13944,     000%,     00:01,         2098,     A,  -,  -
03:53:24,  14004,     000%,     00:01,         2098,     A,  -,  -
03:54:24,  14064,     000%,     00:01,         2098,     A,  -,  -
03:55:24,  14124,     000%,     00:01,         2098,     A,  -,  -
03:56:24,  14184,     000%,     00:01,         2067,     A,  -,  -
03:57:24,  14244,     000%,     00:01,         2035,     A,  -,  -
03:58:24,  14304,     000%,     00:01,         2035,     A,  -,  -
03:59:24,  14364,     000%,     00:01,         2035,     A,  -,  -
04:00:24,  14424,     000%,     00:01,         2035,     A,  -,  -
04:01:24,  14484,     000%,     00:01,         2035,     A,  -,  -
04:02:24,  14544,     000%,     00:01,         2035,     A,  -,  -
04:03:24,  14604,     000%,     00:01,         1971,     A,  -,  -
04:04:24,  14664,     000%,     00:01,         1971,     A,  -,  -
04:05:24,  14724,     000%,     00:01,         1971,     A,  -,  -
04:06:24,  14784,     000%,     00:01,         1908,     A,  -,  -
04:07:24,  14844,     000%,     00:01,         1908,     A,  -,  -
04:08:24,  14904,     000%,     00:01,         1908,     A,  -,  -
04:09:24,  14964,     000%,     00:01,         1908,     A,  -,  -
04:10:24,  15024,     000%,     00:01,         1908,     A,  -,  -
04:11:25,  15085,     000%,     00:01,         1908,     A,  -,  -
04:12:25,  15145,     000%,     00:01,         1908,     A,  -,  -
04:13:25,  15205,     000%,     00:01,         1908,     A,  -,  -
04:14:25,  15265,     000%,     00:01,         1908,     A,  -,  -
04:15:25,  15325,     000%,     00:01,         1908,     A,  -,  -
04:16:25,  15385,     000%,     00:01,         1908,     A,  -,  -
04:17:25,  15445,     000%,     00:01,         1844,     A,  -,  -
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: funman on February 12, 2010, 07:38:23 AM
Ok, I've got it.  On my c200v2 backlight is controlled by A7 instead of A5.
I now have working backlight.
Also interesting:
Even though I've disabled the USB detection it reacts to USB plug/unplug as if a button was pressed.
i.e. the buttonlight goes on and display is switched on if it was off.

bertrik can you test if setting both A5 & A7 has any incidence ?

Ok, I've now found out that the reaction to USB plug/unplug is due to the SYS_CHARGER_CONNECTED and SYS_CHARGER_DISCONNECTED events.

Can you see if a GPIO pin is changed when inserting USB (in debug menu > view ports) ?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: ranma on February 12, 2010, 09:09:24 AM
Ok, I've now found out that the reaction to USB plug/unplug is due to the SYS_CHARGER_CONNECTED and SYS_CHARGER_DISCONNECTED events.

Can you see if a GPIO pin is changed when inserting USB (in debug menu > view ports) ?

I checked that, unfortunately I don't see any change on the ports if I plug in USB.
Neither on GPIO nor on DBOP_DIN.

[edit]
I had a look at the AS3525 datasheet. There is the AS3514 IRQ_ENRD_0 register, which is already used to check for the charger status (bit 5) and it provides usb status (bit 3).

I added IRQ_ENRD_0 readout to the GPIO debug function and indeed it changes from 0x00 to 0x28
when i plug in USB (charger connected, usb connected). Maybe that could be used instead of GPIO?
[/edit]

[edit2]
BTW I checked DCDC15, it doesn't affect brightness.
The way the OF behaves it looks like it's doing PWM in software for the brightness controls.
If I wave my Sansa, on the brightest settings I see a continuous light,
on the lowest settings it looks like 50% duty cycle, on medium setting more like 75%.
I've pimped the GPIO debug screen to include more stuff I was interested in:
ADC values (BVDD, VRTC, UVDD, CHGI, VBE1, VBE2, BTMP, CVDD), DCDC15 (to doublecheck that was really set by my modified brightness setting function), IENRD0 and CHARGER registers of AS3514.
[/edit2]

[edit3]
With this usb detection within booted rockbox works for me (using as3514 to read usb state and a seperate thread since usb_detect is called from the timer tick). Possibly the thread should sleep less long since usb.c also debounces the usb_detect value AFAICS.
[edit4]
Well, the as3525 is debouncing this one in hardware so it should be okay
[/edit4]
Code: [Select]
Index: usb-as3525.c
===================================================================
--- usb-as3525.c (revision 24590)
+++ usb-as3525.c (working copy)
@@ -28,6 +28,8 @@
 #include "usb-target.h"
 #include "power.h"
 #include "as3525.h"
+#include "ascodec.h"
+#include "thread.h"
 
 #if defined(SANSA_CLIP)
 #define USB_DETECT_PIN 6
@@ -39,6 +41,11 @@
 #define USB_DETECT_PIN 1
 #endif
 
+static long detect_stack[DEFAULT_STACK_SIZE/sizeof(long)];
+static const char detect_thread_name[] = "usbdetect";
+static unsigned int detect_thread_entry = 0;
+static int detect_state = USB_EXTRACTED;
+
 void usb_enable(bool on)
 {
 #ifdef HAVE_USBSTACK
@@ -51,19 +58,26 @@
 #endif
 }
 
+static void detect_thread(void)
+{
+    while(1)
+    {
+        if (ascodec_read(AS3514_IRQ_ENRD0) & (1<<3))
+            detect_state = USB_INSERTED;
+        else
+            detect_state = USB_EXTRACTED;
+        sleep(HZ/10);
+    }
+}
+
 void usb_init_device(void)
 {
-#ifdef USB_DETECT_PIN
-    GPIOA_DIR &= ~(1 << USB_DETECT_PIN); /* set as input */
-#endif
+    detect_thread_entry = create_thread(detect_thread, detect_stack,
+                          sizeof(detect_stack), 0, detect_thread_name
+                          IF_PRIO(, PRIORITY_SYSTEM) IF_COP(, CPU));
 }
 
 int usb_detect(void)
 {
-#ifdef USB_DETECT_PIN
-    if (GPIOA_PIN( USB_DETECT_PIN ))
-        return USB_INSERTED;
-    else
-#endif
-        return USB_EXTRACTED;
+    return detect_state;
 }
[/edit3]
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: FlynDice on February 12, 2010, 02:18:16 PM
Well I hope it's not just because I'm lucky that myclip+ is still breathing but let me at least document here what I did with it.

I've got a 2Gb clip+.
When I got it I plugged in USB and let it charge until the battery was full.
Then I turned it on and checked out the OF for a bit then turned it off.
Then I upgraded the OF with clppa.bin dated 16 December 2009, 20:37 from clipplus01.02.09.zip
Then I turned it on and checked out the new OF for a bit then turned it off again.
I modified mkamsboot.c so that clip+ would work and patched the firmware.
I did have a bit of a problem here that you can read from posts a few pages back including pastie diffs  http://forums.rockbox.org/index.php?topic=14064.msg161589#msg161589.
Once I figured things out I made a correctly patched firmware with svn dualboot.S(~.5 sec delay) and loaded it successfully.
Hard to see a .5 sec delay so I made it a 6 second delay, patched & loaded succesfully.
I then started testing buttons with this code: http://pastie.org/822205     with results shown in the .pdf attached to this post:   http://forums.rockbox.org/index.php?topic=14064.msg161676#msg161676
At this point I attempted to see I f I could make dualboot work by simply reading C3(left button), if high immediate branch to OF, if not 6 sec delay and it worked.
I then used this as my "escape hatch" for testing more code that involves setting B0 etc.

I have successfully dualbooted with the current code over 50 times while checking for delays trying to read registers one bit at a time....

My hope is someone can spot something different here that may be significant.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: funman on February 12, 2010, 03:28:20 PM
mt do you still have the clppa.bin you copied on your clip+ ?

btw the delay to power off is longer on Clipv2/+ than Clipv1 and closer to 15/20 seconds.

If you're sure it is dead, could you open it and try the e200v2 recovery trick ?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: FlynDice on February 13, 2010, 05:05:16 AM
@funman:

I think the GPIOB(0) only needs to be set in order to read D6 (power).  Here's my commented disassembly: http://pastie.org/823431.

The OF appears to set B0, read D6, unset B0, read the rest of the pins & set flags in r0 if pin is set,  and finally reads pin D6 again only if it was set from the first read.  I guess this is the way to detect the long press.  I've not quite finished but the rest appears to be simply shifting the flags around to frame the return.  And of course there could be another gotcha in another section of code....

Comments welcomed as usual!

EDIT:  Updated disassembly pastie
EDIT2:  Updated disassembly pastie

EDIT3:  It appears the OF returns from the button reads without resetting GPIOB_DIR(0) or GPIOB_DIR(6)to input.

I also just noticed at 7a54 sets pin B6 to output (but doesn't set the pin) before the second D6 button read.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: ranma on February 13, 2010, 07:37:41 AM
Damn, I bricked my C240v2 while playing with dualboot.S...
dualboot.S is not at fault, but rather I forgot to copy dualboot.h in addition to dualboot.c and so mkamsboot copied only part of dualboot into the new firmware. :P
I tried shorting the flash so it'll boot the 'USB boot promer', which makes it show up on usb.
However it reports lun 0 as a single 512 byte sector (Sense Key : Medium Error, Add. Sense: Recorded entity not found) and lun 1 as 'not present', so doesn't help.

[edit3]
FWIW, this is my dualboot.S modification, trying to use the audio master i2c to read irq_enrd0 for usb status... Doesn't work, but should have let me recover because it's after the normal button check.

Code: [Select]
Index: rbutil/mkamsboot/dualboot/dualboot.S
===================================================================
--- rbutil/mkamsboot/dualboot/dualboot.S (revision 24590)
+++ rbutil/mkamsboot/dualboot/dualboot.S (working copy)
@@ -28,11 +28,12 @@
 #endif
 
 /* AS3525 hardware registers */
-.set GPIOA,     0xC80B0000
-.set GPIOB,     0xC80C0000
-.set GPIOC,     0xC80D0000
-.set GPIOD,     0xC80E0000
-.set CGU_PERI,  0xC80F0014
+.set GPIOA,          0xC80B0000
+.set GPIOB,          0xC80C0000
+.set GPIOC,          0xC80D0000
+.set GPIOD,          0xC80E0000
+.set CGU_PERI,       0xC80F0014
+.set I2C_AUDIO_BASE, 0xC8070000
 
 
 /* Vectors */
@@ -93,12 +94,14 @@
 #endif
 
 #ifdef USB_PIN  /* TODO : remove this check when we'll have an USB driver */
+/*
         ldr     r0, =GPIOA
         mov     r1, #0
         str     r1, [r0, #0x400]
         ldr     r1, [r0, #(4*(1<<USB_PIN))]
         cmp     r1, #0
         bne     boot_of
+*/
 #endif
 
         /* Here are model specific tests, for dual boot without a computer */
@@ -186,15 +189,18 @@
         cmp     r2, #0              @ test input from pins
         bne     boot_of             @ branch directly to OF if either pin high
 #elif defined(SANSA_C200V2)
-        /* check for RIGHT on C6, should changed to LEFT as soon as it
-         * known in which pin that is in order for consistency  */
+        /* check for LEFT or RIGHT on C6 */
         ldr     r0, =GPIOC
         mov     r1, #0
-        str     r1, [r0, #0x400]      /* set pin to output */
+        str     r1, [r0, #0x400]      /* set all GPIOC to input */
 
         ldr     r1, [r0, #256]        /* 1<<(6+2) */
-        cmp     r1, #0                /* C6 low means button pressed */
+        cmp     r1, #0                /* C6 low means r-button pressed */
         beq     boot_of
+
+//        ldr     r1, [r0, #16]         /* 1<<(2+2) */
+//        cmp     r1, #0                /* C2 low means l-button pressed */
+//        beq     boot_of
 #elif defined(SANSA_M200V4)
 .set row, (1<<5) /* enable output on A5 */
 .set col, (1<<0) /* read keyscan column A0 */
@@ -213,7 +219,59 @@
         #error No target-specific key check defined!
 #endif
 
+        /* enable i2c audio master clock */
+        ldr     r0, =CGU_PERI
+        ldr     r1, [r0]
+        orr     r1, r1, #(1<<17)
+        str     r1, [r0]
 
+.set pclk, 62000000
+.set i2c_clk, 400000
+.set i2c_prescaler, ((pclk + i2c_clk -1) / i2c_clk)
+.set I2C2_DATA,  0x00
+.set I2C2_SLAD0, 0x04
+.set I2C2_CNTRL, 0x0c
+.set I2C2_DACNT, 0x10
+.set I2C2_CPSR0, 0x1c
+.set I2C2_CPSR1, 0x20
+.set I2C2_SR,    0x30
+.set I2C2_SADDR, 0x44
+.set AS3514_I2C_ADDR, 0x46
+.set AS3514_IRQ_ENRD0, 0x25
+        ldr     r0, =I2C_AUDIO_BASE
+        /* setup prescaler */
+        ldr     r1, =i2c_prescaler
+        str     r1, [r0, #I2C2_CPSR0]
+        mov     r1, r1, lsr #8
+        str     r1, [r0, #I2C2_CPSR1]
+        /* setup i2c slave address */
+        mov     r1, #(AS3514_I2C_ADDR << 1)
+        str     r1, [r0, #I2C2_SLAD0]
+        mov     r2, #0x51
+        str     r2, [r0, #I2C2_CNTRL]
+
+        /* wait for not busy */
+i2c_busywait:
+        ldr     r1, [r0, #I2C2_SR]
+        tst     r1, #1
+        bne i2c_busywait
+
+        /* read irq_enrd0 */
+        mov     r1, #AS3514_IRQ_ENRD0
+        str     r1, [r0, #I2C2_SADDR]
+        orr     r2, r2, #(1 << 1)
+        str     r2, [r0, #I2C2_CNTRL]
+        mov     r1, #1
+        str     r1, [r0, #I2C2_DACNT]
+i2c_wait:
+        ldr     r1, [r0, #I2C2_DACNT]
+        cmp     r1, #0
+        bne     i2c_wait
+
+        ldr     r1, [r0, #I2C2_DATA]
+        tst     r1, #(1 << 3)
+        bne     boot_of
+
         /* The dualboot button was not held, so we boot rockbox */
         ldr     r0, ucl_rb_end      /* Address of compressed image */
         ldr     r1, ucl_rb_size     /* Compressed size */
[/edit3]

[edit]
I hereby request this small change that would have protected me from this mistake by making
gcc bail if dualboot.h and dualboot.c are mismatched:

CC dualboot.c
dualboot.c:63: error: conflicting types for ‘dualboot_c200v2’
dualboot.h:6: error: previous declaration of ‘dualboot_c200v2’ was here
make: *** [build/dualboot.o] Error 1

Code: [Select]
Index: mkamsboot/dualboot/bin2c.c
===================================================================
--- mkamsboot/dualboot/bin2c.c (revision 24590)
+++ mkamsboot/dualboot/bin2c.c (working copy)
@@ -90,6 +90,7 @@
     }
 
     fprintf(cfile,"/* Generated by bin2c */\n\n");
+    fprintf(cfile,"#include \"%s\"\n\n", hfilename);
     fprintf(hfile,"/* Generated by bin2c */\n\n");
 
     for(i=0; i < argc - 2; i++) {
[/edit]

[edit2]
Opened tracker item: http://www.rockbox.org/tracker/task/11009
[/edit2]
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: mtee on February 13, 2010, 02:53:15 PM
mt do you still have the clppa.bin you copied on your clip+ ?

btw the delay to power off is longer on Clipv2/+ than Clipv1 and closer to 15/20 seconds.

If you're sure it is dead, could you open it and try the e200v2 recovery trick ?

The image I used is here : mtarek.com/rockbox/output.rar

I have tried that recovery method but it still didn't work. There's the solution of attaching an external card reader to the NAND flash and writing the OF image back onto it, but I'm not sure if it would work, plus I don't think it would save me much compared to just buying another clip+.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: FlynDice on February 15, 2010, 02:59:52 AM
I checked to see if the second D6 read would somehow catch the USB presence for clip+ but I'm not able to find a difference. :(
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: ranma on February 16, 2010, 10:27:34 AM
I'm going to try to find out the JTAG pinout on my C240v2.
Here is what I've got so far (measured voltages and on the supply pads also the resistance to make sure they are supply pads. At about 0.5 Ohms I'm pretty sure they are :)):

Code: [Select]
USB

    1 GND
 F  2 2.4V
 L  3 2.4V
 A  4 2.4V
 S  5 2.4V
 H  6 0V (TRST?)
    7 VCC

RAM

And I soldered wires to the pads:
http://uguu.de/~ranma/S6000731.JPG

Now I have to figure out how to best proceed in testing the pins...
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: saratoga on February 16, 2010, 11:12:02 AM
Now I have to figure out how to best proceed in testing the pins...

This can probably help:

http://forums.rockbox.org/index.php?topic=14064.msg129684#msg129684

Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: funman on February 17, 2010, 06:14:47 PM
Quick update:

LCD now works on Clip+ since r24729.

It's at the same state than Clipv2, i.e. only buttons & lcd work, still not storage.

Further development is still blocked until someone figures how to use the SD controller.

mkamsboot reported to work (r24727) on my Clip+, FlynDice one and 2 other testers from the irc channel (tested 2GB, 4GB and 8GB).

If you want to help you can test it on your Clip+ and report if it bricked it or not (still not sure what happened on the 2 bricked Clip+)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: ranma on February 18, 2010, 12:27:46 AM
Now I have to figure out how to best proceed in testing the pins...

Battle plan:

Either the 0V pin is TRST and TDO is tristated during reset or it's TDO and TRST is floating.
Check if it can be pulled up (TRST) or not (then it's most likely TDO).
Assuming it's TRST, check the other pins for 0V or 3V, I'd expect TDO to have logic level now.
For the remaining 3 pins there should only be 3! = 6 possible combinations left.
I also bought two 74HC00, LEDs and resistors to build a SR flop for manual clocking and to show the pin state.

[edit]
Ok, unfortunately TDO is tristated as long as the state machine is not in a 'shift data' mode.
But I got the pinout now:
Code: [Select]
C240v2 JTAG pinout

USB

    1 GND
 F  2 TDO
 L  3 TCLK
 A  4 TMS
 S  5 TDI
 H  6 TRST
    7 VCC

RAM
TRST is asynchronous, just checked that.
Here ist the test rig I used for figuring out the pinout:
http://uguu.de/~ranma/jtag_test_rig.jpg
Two 74HC00 Quad NANDs, 2 NANDs form a SR-Flipflop to debounce the clock switch (left), 4 drive the upper LEDs for monitoring which pin is TDO, 2 are unused (inputs tied to gnd).
TMS is fed in using the dark blue jumper cable.
TRST is the white cable on the right side pulled up to VCC using a 10K resistor.

Unfortunately the girl with the Jtagkey wasn't at the hacker space today, so I can't go on and try to upload a debricker just yet.
[/edit]
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: saratoga on February 18, 2010, 11:24:27 AM
Unfortunately the girl with the Jtagkey wasn't at the hacker space today, so I can't go on and try to upload a debricker just yet.

If you can get JTAG running while in some part of the OF, it would be really interesting to know what settings it uses for the various AS3525v2 clocks and voltage regulators.  We're clearly not setting a few things correctly and knowing the OF settings would be useful to figure out what.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: funman on February 18, 2010, 12:05:54 PM
If you can get JTAG running while in some part of the OF, it would be really interesting to know what settings it uses for the various AS3525v2 clocks and voltage regulators.

You mean AS3525? The v2 is only in Clipv2/Clip+/Fuzev2 not in c200v2.

Not sure how c200v2's battery life but I would expect it to be lower than OF like the other AMS, and indeed JTAG could be very helpful.

Can you insert breakpoints ? I think it's the only way to be able to know what the i2c registers are set to (Reading a register isn't simply a load), unless we find that the OF keeps a cached table of registers content
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: FlynDice on February 18, 2010, 05:40:02 PM
Having display makes things so much easier! ;)

Clip+  pin A2 is unset for uSD present.

USB detect is not on any of the GPIO pins.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: embrion on February 23, 2010, 03:02:16 PM
Hi

any ideas about improving batterylife? I've tested my v1 Fuze and got 11:50h while OF gives me ~22h. OF was tested by repeating the same track so I believe caching gave me some of that 22h but still it's a lot more than RBX.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: saratoga on February 23, 2010, 03:42:09 PM
Hi

any ideas about improving batterylife? I've tested my v1 Fuze and got 11:50h while OF gives me ~22h. OF was tested by repeating the same track so I believe caching gave me some of that 22h but still it's a lot more than RBX.

Yes we've talked about this a lot.  Basically various core clocks are set too high and probably some hardware isn't turned off properly.   
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: kronflux on February 23, 2010, 04:09:46 PM
I don't know what you guys did, but my e200v2, I haven't updated for a good few weeks. I just compiled the latest svn, and wow! changing tracks and whatnot used to be really slow for me. it could take up to 5 or 6 seconds just to change to the next track when you press next or previous track. now it's instantaneous! very impressed! and I just tested doom for the heck of it too. aside from it being too tiny since its not landscape view, it works great! thanks guys! keep up the amazing work!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: embrion on February 23, 2010, 05:32:49 PM
Yes we've talked about this a lot.  Basically various core clocks are set too high and probably some hardware isn't turned off properly.   
Yeah, I read about it. Also something about some hardware differences between (at least Fuze) 1.x revisions. Well, somehow they manage to keep one OF firmware version for all revisions 1.x so maybe some kind of detection?
In my case it would be probably only clocking as I tested without powering off.
Any plans on looking for minimal clocking? I know that everybody is working now on Clip+ etc but improving existing, more mature ports would also be welcomed :)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: saratoga on February 23, 2010, 07:52:25 PM
Any plans on looking for minimal clocking? I know that everybody is working now on Clip+ etc but improving existing, more mature ports would also be welcomed :)

Don't let me get in your way.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: bertrik on February 24, 2010, 05:53:44 AM
Regarding the runtime issue:
1) A known problem is that some revisions of the radio chip seem to initialise in a powered-on state, wasting about 15 mA. With a runtime of 11h50m, current is about 550mA/11h50m = 46.5 mA. Without the 15 mA waste, runtime could be about 17h27m.
2) I think we are pretty conservative already with respect to disabling and enabling various peripherals. You could look up the CGU_PERI value in the debug/hwinfo menu and check the bits against the datasheet. Last time I looked at it on my clip, I couldn't find any unneeded peripherals wasting power.
3) We have configured the internal clocks for maximum performance (for example 248 MHz max processor clocks). Maybe the OF clocks a little lower. Also with a lower clock (below 200 MHz), the processor voltage can be reduced from 1.2V to 1.1V, theoretically saving about 16% on processor current.

Can you report back with the following:
1) enable the radio, go to the debug/radio menu and note the first two numbers (1st will be 1242)
2) go to the debug/hw info menu and note the CGU_PERI value
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: ranma on February 24, 2010, 07:33:58 AM
Ok, since Tooru didn't have her JTAGKey with her yesterday and akizukidenshi has a reasonably priced ft2232 board I went ahead and bought one today for 1700 Yen (plus 150 Yen for the experimenting board).

http://uguu.de/~ranma/c200v2_jtag_ft2232c.jpg

Now I have to figure out openocd, but I got it working so far:

[edit]
Now successfully debricked!
Uploaded new first stage bootloader using
"halt" "load_image /home/ranma/ocd_repair.bin 0"
resumed execution from address 0 ("resume 0"), booted into OF and flashed a working image. :)
(Hard part: Hold down battery on battery contacts so I can unplug usb to trigger flashing...)
[/edit]

[edit2]
Code: [Select]
CGU regs OF in USB mode, no uSD
> mdw phys 0xC80F0000 0x20
0xc80f0000: 00002630 00002630 00000000 00000000 0000001d 0ee34395 00002001 00000032
0xc80f0020: 00000003 00000000 000000ff 000000ff 000000c9 00000191 00000008 00000000
0xc80f0040: 00002630 00002630 00000000 00000000 0000001d 0ee34395 00002001 00000032
0xc80f0060: 00000003 00000000 000000ff 000000ff 000000c9 00000191 00000008 00000000
>

CGU regs OF without USB, but powered over USB, no uSD
0xc80f0000: 0000261b 00002630 00000000 00000000 00000029 0ee3438d 00002001 00000032
0xc80f0020: 00000003 00000003 000000ff 000000ff 000000c5 00000189 00000008 00000000
0xc80f0040: 0000261b 00002630 00000000 00000000 00000029 0ee3438d 00002001 00000032
0xc80f0060: 00000003 00000000 000000ff 000000ff 000000c5 00000189 00000008 00000000

CGU regs OF without USB, but powered over USB, uSD plugged in
0xc80f0000: 0000261b 00002630 00000000 00000000 00000029 0ee3c38d 00002001 00000032
0xc80f0020: 00000003 00000001 000000ff 000000ff 000000c5 00000189 00000008 00000000
0xc80f0040: 0000261b 00002630 00000000 00000000 00000029 0ee3c38d 00002001 00000032
0xc80f0060: 00000003 00000000 000000ff 000000ff 000000c5 00000189 00000008 00000000

CGU regs OF without USB, but powered over USB, uSD plugged in, playing mp3
0xc80f0000: 0000261b 00002630 00000000 00000000 00000011 0ef3c38d 00002895 00000032
0xc80f0020: 00000003 00000001 000000ff 000000ff 000000c5 00000189 00000008 00000000
0xc80f0040: 0000261b 00002630 00000000 00000000 00000011 0ef3c38d 00002895 00000032
0xc80f0060: 00000003 00000000 000000ff 000000ff 000000c5 00000189 00000008 00000000

OF audio master i2c
0xc8070000: 00000028 0000008c 0000008c 00000053 00000000 00000000 00000000 00000009
0xc8070020: 00000001 00000098 00000004 00000000 00000000 00000000 00000000 00000000
0xc8070040: 00000000 00000025 00000025 00000025 00000003 00000000 00000000 00000000
0xc8070060: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[/edit2]

[edit3]
Code: [Select]
CGU regs OF without USB, battery power, no uSD, playing mp3
0xc80f0000: 0000261b 00002630 00000000 00000000 0000001d 0ef343d1 00002895 00000032
0xc80f0020: 00000003 00000003 000000ff 000000ff 000000c5 00000189 00000008 00000000
MCI_CLOCK:
0xc8000004: 00000301
0xc8020004: 00000000

CGU regs OF with USB, battery power, uSD present, playing mp3
0xc80f0000: 0000261b 00002630 00000000 00000008 0000001d 0ef3c3d1 00002895 00000032
0xc80f0020: 00000001 00000000 000000ff 000000ff 000000c5 00000189 00000008 00000000
MCI_CLOCK:
0xc8000004: 00000301
0xc8020004: 00000301


[/edit3]

Code: [Select]
> scan_chain
   TapName             Enabled  IdCode     Expected   IrLen IrCap IrMask
-- ------------------- -------- ---------- ---------- ----- ----- ------
 0 as3525.cpu             Y     0x00922f0f 0x00922f0f     4 0x01  0x03
> halt
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x20000053 pc: 0x000000bc
MMU: disabled, D-Cache: disabled, I-Cache: disabled
> arm reg
System and User mode registers
      r0: 00000000       r1: 00009db1       r2: 00000051       r3: 0004ff57
      r4: 0000000f       r5: 0004ff59       r6: 00000000       r7: 8022d509
      r8: 71800c18       r9: 0a20824c      r10: f0b50281      r11: 32006423
     r12: 8001bfad   sp_usr: 0390c0bc   lr_usr: 1bd02082       pc: 000000bc
    cpsr: 20000053

FIQ mode shadow registers
  r8_fiq: 94900252   r9_fiq: 1011ec30  r10_fiq: 3c30898a  r11_fiq: 31487004
 r12_fiq: e0201b14   sp_fiq: 5ca90381   lr_fiq: 2200a108 spsr_fiq: a000007a

Supervisor mode shadow registers
  sp_svc: 8104e3f8   lr_svc: 800002b4 spsr_svc: 60000034

Abort mode shadow registers
  sp_abt: 62050851   lr_abt: 411c08d8 spsr_abt: 20000018

IRQ mode shadow registers
  sp_irq: 8104e080   lr_irq: 8001c750 spsr_irq: 60000073

Undefined instruction mode shadow registers
  sp_und: 5f918607   lr_und: 80ea28d0 spsr_und: 300000f4
>

Here is the openocd config:
Code: [Select]
telnet_port 4444
gdb_port 3333

interface ft2232
ft2232_layout oocdlink
ft2232_vid_pid 0x0403 0x6010

jtag_ntrst_delay 100

set _CHIPNAME as3525
set _ENDIAN little
set _CPUTAPID 0x00922f0f

#jtag scan chain
jtag newtap $_CHIPNAME cpu -irlen 4 -expected-id $_CPUTAPID

set _TARGETNAME $_CHIPNAME.cpu
target create $_TARGETNAME arm920t -endian $_ENDIAN -chain-position $_TARGETNAME -variant arm920t

# FIXME: copied from samsung config
$_TARGETNAME configure -work-area-phys 0x200000 -work-area-size 0x4000 -work-area-backup 1
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: mc2739 on February 24, 2010, 07:45:32 AM
2) go to the debug/hw info menu and note the CGU_PERI value

On the e200v2, I am not seeing a CGU_PERI value on the "View HW Info" debug screen.


Edit: I found it. I did not realize there was another screen displayed when the down button was pressed.

1) radio ID: 1242 0850
2) CGU_PERI: 0F93018F
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: funman on February 24, 2010, 10:37:23 AM
CGU register dump from OF in USB mode.
0ee34395

2) CGU_PERI: 0F93018F

I see we leave ROM clock enabled unlike the OF, I'll run a battery bench to see if it changes anything to disable it
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: embrion on February 24, 2010, 11:26:17 AM

Can you report back with the following:
1) enable the radio, go to the debug/radio menu and note the first two numbers (1st will be 1242)
2) go to the debug/hw info menu and note the CGU_PERI value

1) 1242 1053
2) CGU_PERI: 0F93018F
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: FlynDice on February 25, 2010, 01:55:02 AM
I cleaned up the sd-as3525v2 init_controller and sd_init_card code and I get much more reliable boots into the main code now.  Update your bootloader also.

edit:  Still need to disable i&dcache
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: funman on February 25, 2010, 07:04:18 AM
I see we leave ROM clock enabled unlike the OF, I'll run a battery bench to see if it changes anything to disable it

No significant difference : 5h15 runtime
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: embrion on February 25, 2010, 01:22:04 PM
and how long was it before change?
I'm willing to test everything unless it can brick my Fuze (yeah, I know everything can but I think lovering voltage or clocking is less probable in hurting anything )
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: funman on February 25, 2010, 01:34:06 PM
and how long was it before change?

No significant difference

It was not different = it was the same (5h15 or so).

You can read (and post) battery benches on SansaRuntime (http://www.rockbox.org/wiki/SansaRuntime).

Btw i'm running a bench with radio, hard part will be to benchmark the OF (I don't want to check the Clip every 10 minutes).

I think saratoga suggested to plug the Clip to soundcard input, record it and then analyse the wav file. Would it change current consumption if something is plugged on the jack or not ?
(If it's the case I need to benchmark rockbox with the jack plugged as well)
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: saratoga on February 25, 2010, 01:54:22 PM
I think saratoga suggested to plug the Clip to soundcard input, record it and then analyse the wav file. Would it change current consumption if something is plugged on the jack or not ?
(If it's the case I need to benchmark rockbox with the jack plugged as well)

Typical line in impedance is very large, so its not much different then driving the air (nothing plugged in).  Will definitely use a bit less power then headphones.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: funman on February 26, 2010, 07:47:31 AM
rockbox runtime with FM : 7h 40 minutes (starting at 97% battery)

EDIT: some findings on Clip+/SD

I added a sleep(HZ) after the clock is switched to 400kHz, and card powering up succeeds

Then I wondered why card stays in identification mode after it sent its RCA: so I send a SD_SEND_STATUS to the card just after switching clock to full speed and it responds:

0xD5554520 => status = 2 = identification

And here comes the weirdness:

I noticed that the disk info debug menu gave weird information (ridiculously small number of blocks), so I printed the CSD in rockbox.sansa and it gives:

Note how the last one is identical to the status we got from the previous command (and also how it is completely different from the expected CSD for my Clip+ 4GB).

Perhaps we should check MCI_RAW_STATUS from the isr to see if a command was not sent correctly?

BTW here is the list of CSDs for Clipv2 and Clip+ that I have (they should be in correct order, with first 32 bits being bits 127:96 of the CSD):

Code: [Select]
    /* Clipv2 1GB */
    0x00260032,
    0x5F5983D3,
    0xBEFBCFFF,
    0x92404019,

    /* Clipv2 2GB */
    0x00260032,
    0x5F5A83D3,
    0xBEFBCFFF,
    0x9280401B,

    /* Clip+ 4GB */
    0x400E0032, //127:96
    0x5B590000, //95:64
    0x1D8A7F80, //63:32
    0x0A4040B9, //31:0

    /* Clip+ 8GB */
    0x400e0032,
    0x5b590000,
    0x3b377f80,
    0x0a4040af,

    /* Clip+ 2GB */
    0x00260032,
    0x5F5A83AE,
    0xFEFBCFFF,
    0x928040DF,

Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: mc2739 on February 26, 2010, 06:06:13 PM
I noticed that the disk info debug menu gave weird information (ridiculously small number of blocks), so I printed the CSD in rockbox.sansa and it gives:
  • card_info.csd[3] = 0x03534453
  • card_info.csd[2] = 0x44303447
  • card_info.csd[1] = 0x80234829
  • card_info.csd[0] = 0xD5554520

This looks to me to be the CID instead of the CSD

[3] and [2] decode as:
127:120 = Manufacturer ID = 0x03 for Sandisk
119:104 = OEM/Application ID = "SD" ASCII Code 0x53, 0x44
103:64 = Product Name = "SD04G" ASCII Code 0x53, 0x44, 0x30, 0x34, 0x47
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: ranma on March 01, 2010, 12:58:04 AM
Chasing mkamsboot weirdness again.
It's still possible to get a borken mkamsboot if you don't make clean after changing dualboot. :/
Below prevents that but is rather hacky, it would be better to generate dependencies for the .c-files and include those in the makefile...

Code: [Select]
Index: Makefile
===================================================================
--- Makefile    (revision 24914)
+++ Makefile    (working copy)
@@ -47,6 +47,9 @@
 LIBOBJS := $(patsubst %.c,%.o,$(addprefix $(OBJDIR),$(LIBSOURCES)))
 EXTRADEPS := $(LIBUCL)
 
+dualboot.o: dualboot.h
+mkamsboot.o: dualboot.h
+
 $(OBJDIR)%.o: %.c
        @echo CC $< $
        $(SILENT)mkdir -p $(dir $@)

[edit]
funman: Your dbop patch works for me
Below is my current version of dualboot.S
This combines your dbop patch with my 'use i2c for usb status'.
BTW the reason my usb status check was not working at first was that
I didn't clear the interrupt mask and the bootloader runs with interrupts enabled...
So when the I2C read finished it would get an interrupt, execute the nops and
data words until running into start again. Lather, rinse, repeat. :)

I first tested this using JTAG, then flashed it and tested it again:
Power on with USB unplugged, left button not pressed: Boots rockbox
Power on with USB plugged in, left button not pressed: Boots OF
Power on with USB unplugged, left button pressed: Boots OF
Power on with USB unplugged, right button pressed: Boots OF (old button code)
Power on with USB unplugged, down button pressed: Boots rockbox (just for cross-checking ;))

BTW, the audio master usb status bit also gets set if it's only power and not the data lines.
However the OF handles this situation correctly and does not go into usb storage mode.

Code: [Select]
Index: rbutil/mkamsboot/dualboot/dualboot.S
===================================================================
--- rbutil/mkamsboot/dualboot/dualboot.S (revision 24980)
+++ rbutil/mkamsboot/dualboot/dualboot.S (working copy)
@@ -22,24 +22,27 @@
 .text
 
 /* AS3525 hardware registers */
-.set GPIOA,     0xC80B0000
-.set GPIOB,     0xC80C0000
-.set GPIOC,     0xC80D0000
-.set GPIOD,     0xC80E0000
-.set CGU_PERI,  0xC80F0014
+.set GPIOA,          0xC80B0000
+.set GPIOB,          0xC80C0000
+.set GPIOC,          0xC80D0000
+.set GPIOD,          0xC80E0000
+.set CGU_PERI,       0xC80F0014
+.set CGU_DBOP,       0xC80F0038
+.set DBOP,           0xC8120000
+.set I2C_AUDIO_BASE, 0xC8070000
 
 
 /* Vectors */
 
         ldr   pc, =start    /* reset vector */
-        /* next vectors are unused */
-        .word   0
-        .word   0
-        .word   0
-        .word   0
-        .word   0
-        .word   0
-        .word   0
+        /* next vectors are unused, halt cpu */
+1:      b 1b
+1:      b 1b
+1:      b 1b
+1:      b 1b
+1:      b 1b
+1:      b 1b
+1:      b 1b
 
 /* These values are filled in by mkamsboot - don't move them from offset 0x20 */
 
@@ -88,12 +91,14 @@
 #endif
 
 #ifdef USB_PIN  /* TODO : remove this check when we'll have an USB driver */
+/*
         ldr     r0, =GPIOA
         mov     r1, #0
         str     r1, [r0, #0x400]
         ldr     r1, [r0, #(4*(1<<USB_PIN))]
         cmp     r1, #0
         bne     boot_of
+*/
 #endif
 
         /* Here are model specific tests, for dual boot without a computer */
@@ -170,14 +175,63 @@
         cmp     r2, #0              @ test input from pins
         bne     boot_of             @ branch directly to OF if either pin high
 #elif defined(SANSA_C200V2)
-        /* check for RIGHT on C6, should changed to LEFT as soon as it
-         * known in which pin that is in order for consistency  */
+        ldr     r0, =CGU_DBOP
+        mov     r1, #(1<<3)         @ DBOP freq = PCLK, clock enabled
+        str     r1, [r0]
+
+        @ only for LCD ?
+        ldr     r2, =GPIOB
+        mov     r1, #0xc
+        str     r1, [r2, #0x420]    @ GPIOB_AFSEL
+        ldr     r2, =GPIOC
+        mov     r1, #0xff
+        str     r1, [r2, #0x420]    @ GPIOC_AFSEL
+
+        ldr     r0, =DBOP
+        ldr     r1, =0x6e167
+        str     r1, [r0]            @ DBOP_TIMPOL_01
+        ldr     r1, =0xe007e007
+        str     r1, [r0, #4]        @ DBOP_TIMPOL_23
+
+        mov     r1, #10
+1:      nop
+        subs    r1, r1, #1
+        bne     1b
+
+        mov     r1, #(1<<12)        @ 16 bit data width
+        orr     r1, r1, #(1<<16)    @ enable write
+        orr     r1, r1, #(1<<19)    @ tri-state output
+        str     r1, [r0, #8]        @ DBOP_CTRL
+
+        ldr     r1, =0xf0ff         @ precharge
+        str     r1, [r0, #0x10]     @ DBOP_DOUT
+
+2:      ldr     r1, [r0, #0xc]      @ DOBP_STAT
+        ands    r1, r1, #(1<<10)
+        beq     2b                  @ make sure fifo is empty
+
+        mov     r1, #31
+        orr     r1, r1, #(1<<12)    @ 16 bit data width
+        orr     r1, r1, #(1<<15)    @ start read
+        orr     r1, r1, #(1<<19)    @ tri-state output
+        str     r1, [r0, #8]        @ DBOP_CTRL
+
+3:      ldr     r1, [r0, #0xc]      @ DOBP_STAT
+        ands    r1, r1, #(1<<16)
+        beq     3b                  @ wait for valid data
+
+        ldrh    r1, [r0, #0x14]     @ DBOP_DIN
+
+        ands    r1, r1, #(1<<2)     @ bit 2 unset = button left pressed
+        beq     boot_of
+
+        /* check for LEFT or RIGHT on C6 */
         ldr     r0, =GPIOC
         mov     r1, #0
-        str     r1, [r0, #0x400]      /* set pin to output */
+        str     r1, [r0, #0x400]      /* set all GPIOC to input */
 
         ldr     r1, [r0, #256]        /* 1<<(6+2) */
-        cmp     r1, #0                /* C6 low means button pressed */
+        cmp     r1, #0                /* C6 low means r-button pressed */
         beq     boot_of
 #elif defined(SANSA_M200V4)
 .set row, (1<<5) /* enable output on A5 */
@@ -197,7 +251,63 @@
         #error No target-specific key check defined!
 #endif
 
+        /* enable i2c audio master clock */
+        ldr     r0, =CGU_PERI
+        ldr     r1, [r0]
+        orr     r1, r1, #(1<<17)
+        str     r1, [r0]
 
+.set pclk, 62000000
+.set i2c_clk, 400000
+.set i2c_prescaler, ((pclk + i2c_clk -1) / i2c_clk)
+.set I2C2_DATA,  0x00
+.set I2C2_SLAD0, 0x04
+.set I2C2_CNTRL, 0x0c
+.set I2C2_DACNT, 0x10
+.set I2C2_CPSR0, 0x1c
+.set I2C2_CPSR1, 0x20
+.set I2C2_IMR,   0x24
+.set I2C2_SR,    0x30
+.set I2C2_SADDR, 0x44
+.set AS3514_I2C_ADDR, 0x46
+.set AS3514_IRQ_ENRD0, 0x25
+        ldr     r0, =I2C_AUDIO_BASE
+        /* disable i2c interrupts */
+        mov     r1, #0
+        str     r1, [r0, #I2C2_IMR]
+        /* setup prescaler */
+        ldr     r1, =i2c_prescaler
+        str     r1, [r0, #I2C2_CPSR0]
+        mov     r1, r1, lsr #8
+        str     r1, [r0, #I2C2_CPSR1]
+        /* setup i2c slave address */
+        mov     r1, #(AS3514_I2C_ADDR << 1)
+        str     r1, [r0, #I2C2_SLAD0]
+        mov     r2, #0x51
+        str     r2, [r0, #I2C2_CNTRL]
+
+        /* wait for not busy */
+i2c_busywait:
+        ldr     r1, [r0, #I2C2_SR]
+        tst     r1, #1
+        bne i2c_busywait
+
+        /* read irq_enrd0 */
+        mov     r1, #AS3514_IRQ_ENRD0
+        str     r1, [r0, #I2C2_SADDR]
+        orr     r2, r2, #(1 << 1)
+        str     r2, [r0, #I2C2_CNTRL]
+        mov     r1, #1
+        str     r1, [r0, #I2C2_DACNT]
+i2c_wait:
+        ldr     r1, [r0, #I2C2_DACNT]
+        cmp     r1, #0
+        bne     i2c_wait
+
+        ldr     r1, [r0, #I2C2_DATA]
+        tst     r1, #(1 << 3)
+        bne     boot_of
+
         /* The dualboot button was not held, so we boot rockbox */
         ldr     r0, ucl_rb_end      /* Address of compressed image */
         ldr     r1, ucl_rb_size     /* Compressed size */
[/edit]
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: funman on March 02, 2010, 07:16:42 AM
Below prevents that but is rather hacky, it would be better to generate dependencies for the .c-files and include those in the makefile...

I added something similar in r24915 after kugel found this problem (svn up before sending patches!), but I agree generating dependencies would be better.

funman: Your dbop patch works for me
Below is my current version of dualboot.S
This combines your dbop patch with my 'use i2c for usb status'.
BTW the reason my usb status check was not working at first was that
I didn't clear the interrupt mask and the bootloader runs with interrupts enabled...
So when the I2C read finished it would get an interrupt, execute the nops and
data words until running into start again. Lather, rinse, repeat. :)

I would like to know the opinion of bertrik on the addition of i2c code, this would replace the "USB_PIN" check and work on every c200v2 and on Clip+.

Just one note: you forgot to set PCLK frequency in CGU_PERI. I suggest using the 24MHz clock (clk_sel == 00b and no divider)

About the missing vectors, could we just use "bx lr" for fiq and irq? for fault handlers an infinite loop would be fine since we don't know if we can return safely.

BTW, the audio master usb status bit also gets set if it's only power and not the data lines.
However the OF handles this situation correctly and does not go into usb storage mode.

This is not a big problem for now, perhaps the OF does this check with the usb controller
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: ranma on March 02, 2010, 11:51:58 AM
About the missing vectors, could we just use "bx lr" for fiq and irq? for fault handlers an infinite loop would be fine since we don't know if we can return safely.

IIRC "subs pc, lr, #4" is the proper way to return from interrupt handlers.
On the other hand I don't see why any interrupt should happen at that stage.
And if the interrupt request is not cleared it might generate the next interrupt right away.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: torne on March 02, 2010, 12:11:50 PM
Yes, subs pc, lr, #4 is for irq/fiq returns. bx will return to the wrong instruction and won't change mode back to svc.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: funman on March 03, 2010, 07:15:42 PM
I committed the simplest change: replace the vectors by infinite loops

bertrik said he was ok with the principle of using i2c in dualboot, so I think now the only problem is we don't explicitely set PCLK in CGU_PERI.

At the moment we only enable GPIO peripheral and the PrimeCell PL061 GPIO controller doesn't seem to have any requirement on clock frequency.

CGU_PERI &= ~0x7f should be alright for i2c, I am not too sure about DBOP since now we run it at 62MHz. Perhaps we'll need to modify the timing registers.

We also need to check what the CGU_PERI (divider and clock selection) bits are on as3525v2.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: funman on March 03, 2010, 08:22:52 PM
rockbox runtime with FM : 7h 40 minutes (starting at 97% battery)

OF runtime with FM : 8h 50 minutes.

This is much closer than with audio files, so explicitely powering the FM off at startup could give nice results.

EDIT: Change committed, I get 1h30 more runtime on Clipv1 (just like Jouni Paulus reported on SansaRuntime (http://www.rockbox.org/wiki/SansaRuntime))
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: embrion on March 05, 2010, 08:48:13 AM
Thanks, I'll check with mu Fuze and report back.

EDIT: ok, NO IMPROVEMENT in my case
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: ranma on March 07, 2010, 12:39:43 PM
CGU_PERI &= ~0x7f should be alright for i2c, I am not too sure about DBOP since now we run it at 62MHz. Perhaps we'll need to modify the timing registers.

Bootup status on CGU_PERI is already 0x0f810000 (after the 'enable GPIO clock code'),
so &= ~0x7f should be unecessary, but can't hurt. :)
I added 'infinite loop if right pressed' to my bootloader to verify this:

Code: [Select]
> halt
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x60000053 pc: 0x00000084
MMU: disabled, D-Cache: disabled, I-Cache: disabled
> arm disassemble 0x70 6
0x00000070      0xe59f0164      LDR r0, [r15, #0x164]
0x00000074      0xe3a01000      MOV r1, #0x0
0x00000078      0xe5801400      STR r1, [r0, #0x400]
0x0000007c      0xe5901100      LDR r1, [r0, #0x100]
0x00000080      0xe3510000      CMP r1, #0x0
0x00000084      0x0afffffe      BEQ 0x00000084
> reg r0
r0 (/32): 0xC80D0000
> mdw phys 0xC80F0000 0x20
0xc80f0000: 00002630 00006a2f 00000000 00000008 00000051 0f810000 0000010d 00000011
0xc80f0020: 00000001 00000001 00000020 00000020 000000cd 00000191 00000000 00000000
0xc80f0040: 00002630 00006a2f 00000000 00000008 00000051 0f810000 0000010d 00000011
0xc80f0060: 00000001 00000000 00000020 00000020 000000cd 00000191 00000000 00000000
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: funman on March 07, 2010, 07:55:14 PM
Can you post a patch (without DBOP modifications since it's unrelated) on flyspray so we can test on each model before committing ?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: ranma on March 08, 2010, 12:14:55 PM
Can you post a patch (without DBOP modifications since it's unrelated) on flyspray so we can test on each model before committing ?

Here you go:
http://www.rockbox.org/tracker/task/11085
http://www.rockbox.org/tracker/task/11085?getfile=21542
Tested on my C240v2.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: funman on March 09, 2010, 11:31:34 AM
thanks! i committed it for c200v2 only, I'll try on my devices so we can remove the USB pin and use this code on all devices.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: mc2739 on March 09, 2010, 08:00:51 PM
thanks! i committed it for c200v2 only, I'll try on my devices so we can remove the USB pin and use this code on all devices.

Tested on e200v2 - no problems noted
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: FlynDice on March 13, 2010, 01:32:47 AM
Just a little update on progress (or lack thereof) for for me with the clip+.

I have found that I only need to disable the Dcache.  The player boots up fine with just the Icache and mmu enabled.  I have not played around with the memory mapping and cacheable areas yet but will get there eventually.  The problem with the dcache enabled has been getting the SD card past the ident state while initializing.  For some reason the card is sending back an rca of 0x0000XXXX.  I can get it past there to the STBY   state by issuing a second SD_SEND_RELATIVE_ADDR command, but then I cannot get it to TRAN state with a SD_SELECT_CARD cmd.

While investigating the Dcache I found that the 926ejs has a test & clean cache coherency function that may come in useful later.  It seems it knows if the cache is dirty and will loop until clean.

I have found a spot(0x6464) in the of's send_cmd function that sets or unsets B5 depending on the disk but I haven't been able to see a difference when I've used it.

As far as clocks go, the plla/b registers are different but it seems most all of the rest of the clock registers still use bits 1:0 as clock select and most are set to 1 for plla.  CGU_INTCTRL (offset 0x20) seems it may be different from as3525v1 as it is also has 1 stored to it but that is a read only bit for CGU_INTCTRL in the as3525v1.  I think  the CGU_PROC register is the same as v1  and the dividers work just like the v1.

Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: funman on March 13, 2010, 05:48:43 AM
Perhaps B5 is to select internal/µSD ?

I don't remember seeing a different base address like (there are 2 PL180 controllers in the AS3525v1), and MCI_HCON only reports 1 card present.

The code is a bit after a read of GPIOA A2 which is tells if an µSD card is present.

About CGU_PROC here is what I found:

C code of that function (I simplified the setting of CGU_* by setting only the divider bits, other bits are not modified):
Code: [Select]
static inline void delay(void) { int i = 40; while(i--) ; }

void mod_cgu (void)
{
    max_div_peri = ((peri_setting >> 2) & 0xf) + 1;
    min_div_proc = ((proc_setting >> 4) & 0xf) + 1;

    div_proc = min_div_proc * max_div_peri;
    if(div_proc > 0xf)
        div_proc = 0xf;

    if(min_div_proc > 0xf)
        min_div_proc = 0xf;

    CGU_PROC = (proc_setting & 0xf) | ((div_proc - 1) << 4);
    delay();

    int div_peri = 1;
    /*
     * pclk: faster -> slower
     * fclk: slower -> faster
     */
    while(div_proc > min_div_proc && div_peri < max_div_peri)
    {
        if(div_peri < max_div_peri)
        {
            CGU_PERI_DIV = div_peri; /* bits 7:2 */
            delay();
            div_peri++;
        }

        if(div_proc > min_div_proc)
        {
            CGU_PROC_DIV = (div_proc - 2); /* bits 7:4 */
            delay();
            div_proc--;
        }
    }
}

Perhaps tuning some delays might make the Clip+ boot with modified (= faster ?) CGU_PROC

BTW 0x0000XXXX is correct for RCA, it is a 16 bits register.
Though it's OK to store it on 32 bits, because all (?) commands needing RCA as an argument only need "stuff bits" as 31:16
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: FlynDice on March 13, 2010, 08:33:50 AM
Perhaps B5 is to select internal/µSD ?

Yes this is what I think also.

I don't remember seeing a different base address like (there are 2 PL180 controllers in the AS3525v1), and MCI_HCON only reports 1 card present.

I think the MCI_HCON value is reporting 2 cards.  Look at the HCON_NUM_CARDS macro in the linux patch.

BTW 0x0000XXXX is correct for RCA, it is a 16 bits register.

But the RCA is the 16 MSB and if it sends  0x0000XXXX then it's using an RCA of 0x0000 which is not going to work for the SD_SELECT_CARD cmd.  Using an RCA of 0 for the SD_SELECT_CARD cmd actually deselects the card.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: funman on March 14, 2010, 04:59:00 PM
BTW 0x0000XXXX is correct for RCA, it is a 16 bits register.
But the RCA is the 16 MSB and if it sends  0x0000XXXX then it's using an RCA of 0x0000 which is not going to work for the SD_SELECT_CARD cmd.  Using an RCA of 0 for the SD_SELECT_CARD cmd actually deselects the card.

Oops right.

I just tried a build with only dcache disabled, and I'm printing the RCA.

It alternates between 0x0 and 0xD555 .. weird. Perhaps we need to loop until we receive a correct RCA ?

EDIT: I tried to print the CID, and there is only one 32 bits word set: 0xC0FF8000 which is the response to the previous command.

So it looks like the responses are late / or stay in the register for too long / or we read them too quickly (much likely)

EDIT2: Fixed (in svn) : I added a (probably much too long) delay before reading response and my Clip+ boots fine with both caches ON.

The delay can certainly be lowered, right now boot time is quite much longer than before (although should not be more than 4 seconds: 2 in bootloader, 2 in rockbox.sansa).

Now internal storage works (please report bugs), let's focus on sound and µSD !

It'd be nice to know if this code also works on Clipv2
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: FlynDice on March 15, 2010, 12:12:51 AM
@funman:

SD seems to work great now with both caches enabled.

I have been struggling with the CGU_PERI clock select register for awhile.  For some reason b 1:0 are being cleared and I cannot find where this is happening in our code.  I tried to put a panic right after it gets set in system-as3525.c to be sure it was being set correctly but I get a dark screen that won't recover.  I'm wondering if this is some sort of fallback that the chip does on it's own if the settings are screwed up a bit, ie going to a safe 24 MHz frequency with clk_main?

The radio seems to work.  I can scan channels and it seems to find the right presets and the mode will change from stereo to mono if i unplug the headphones.

I will post a patch with some cache coherence functions that take advantage of the test & clean function that the 926ejs has available.  They are supposedly more efficient than the regular arm cache coherence functions and I did find some versions in the OF.  They are much simpler, you don't need to supply a range, it can tell if the cache is dirty and just cleans it until there are no more dirty lines.  See p2-23 of the ARM926EJ-S TRM.

I'll look at adding the LP bits to MCI_PWREN, adding HS, and 4bit bus and see how things work.

In the linux patch there is some info on the AS3543 vs the AS3514, It looks quite similar but I have not really studied it yet.  Maybe a clue or 2 for sound?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: funman on March 15, 2010, 05:44:21 AM
I had some problems with SD yesterday: I played around with the plugins and some would randomly crash, sometimes with undefined instructions.

I suppose we don't properly check if a transfer was successful or not, when writing works it will be easier to use test_disk plugin.

For the sound I had tried the definitions of i2c registers in as3531 datasheet without luck, there was not much difference with as3514 (the mute bit for headphones is shifted by one).

About CGU_PERI, I have no idea right now : perhaps the bits give some status ? Something like "clock is now stable".. I suppose we'll find the explanation in the OF

EDIT: it seems bits 1:0 are never set, perhaps it assumes PLLA as source ?

We could check by either using only PLLB, or measuring the speed of some peripheral ?

EDIT2: the LCD doesn't use DBOP so we need to find another peripheral
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: FlynDice on March 15, 2010, 08:17:59 AM
re: PCLK source

This gets set in line 301 0f system-as3525.c as  AS3525_PCLK_SEL.  Instead of using the macro I tried setting this to both 1 for PLLA and 3 for FCLK and when the player booted up in the debug page it showed b1:0 of CGU_PERI as both being 0.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: ranma on March 15, 2010, 09:18:53 AM
funman:
I had a look at recording. It seems to fault and the fault handler itself is faulting in memset16, called from lcd_clear_viewport.  The memset16 disassembly looks like every 4th word was overwritten with zeroes:

This is what it's supposed to look like
Code: [Select]
30200f08 <memset16>:
30200f08: e3100002 tst r0, #2 ; 0x2
30200f0c: 13520000 cmpne r2, #0 ; 0x0
30200f10: 10c010b2 strneh r1, [r0], #2
30200f14: 12422001 subne r2, r2, #1 ; 0x1
30200f18: e1811801 orr r1, r1, r1, lsl #16
30200f1c: e1a03001 mov r3, r1
30200f20: e3520008 cmp r2, #8 ; 0x8
30200f24: ba00000f blt 30200f68 <memset16+0x60>
30200f28: e52de004 str lr, [sp, -#4]!
30200f2c: e1a0c001 mov ip, r1
30200f30: e1a0e001 mov lr, r1
30200f34: e2522020 subs r2, r2, #32 ; 0x20
30200f38: a8a0500a stmgeia r0!, {r1, r3, ip, lr}
30200f3c: a8a0500a stmgeia r0!, {r1, r3, ip, lr}
30200f40: a8a0500a stmgeia r0!, {r1, r3, ip, lr}
30200f44: a8a0500a stmgeia r0!, {r1, r3, ip, lr}

And this is the actual disassembly:
Code: [Select]
> arm disassemble 0x30200f08 16
0x30200f08      0xe3100002      TST r0, #0x2
0x30200f0c      0x13520000      CMPNE r2, #0x0
0x30200f10      0x00000000      ANDEQ r0, r0, r0
0x30200f14      0x12422001      SUBNE r2, r2, #0x1
0x30200f18      0xe1811801      ORR r1, r1, r1, LSL #0x10
0x30200f1c      0xe1a03001      MOV r3, r1
0x30200f20      0x00000000      ANDEQ r0, r0, r0
0x30200f24      0xba00000f      BLT 0x30200f68
0x30200f28      0xe52de004      STR r14, [r13, #-0x4]!
0x30200f2c      0xe1a0c001      MOV r12, r1
0x30200f30      0x00000000      ANDEQ r0, r0, r0
0x30200f34      0xe2522020      SUBS r2, r2, #0x20
0x30200f38      0xa8a0500a      STMGE r0!, {r1, r3, r12, r14}
0x30200f3c      0xa8a0500a      STMGE r0!, {r1, r3, r12, r14}
0x30200f40      0x00000000      ANDEQ r0, r0, r0
0x30200f44      0xa8a0500a      STMGE r0!, {r1, r3, r12, r14}

[edit]
Getting hotter:
The triggering function seems to be enc_set_parameters()  in apps/recorder/pcm_record.c
Explains the overwrite pattern:
It initializes chunk->flags with 0, struct enc_chunk_hdr just so happens to be 4 words. :)
[/edit]
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: pbxy on March 15, 2010, 10:32:25 AM
It'd be nice to know if this code also works on Clipv2

Using r25204 the main binary finally loads successfully. :)
Some buttons don't work: left, down, hold, vol up.

http://www.imagebanana.com/img/j61f6av2/happyclipv2.jpg

Great work! Thank you a lot! :D

Edit: Yes, FM is detected!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: funman on March 15, 2010, 11:21:13 AM
Nice! Is the FM detected? (you should have the FM menu entry if it was)

About the buttons perhaps modifying the button driver like the Clipv1 would help: read only 1 row at each tick, and prepare the next row to be read at the next tick. Can you look at it ?

Not sure why hold button doesn't work though.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: pbxy on March 15, 2010, 03:21:32 PM
About the buttons perhaps modifying the button driver like the Clipv1 would help: read only 1 row at each tick, and prepare the next row to be read at the next tick. Can you look at it ?

That works fine for all the buttons except for hold.
Also, "View I/O ports" doesn't show a change of GPIOA when hold is active.

FM Radio: It even finds stations!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: funman on March 15, 2010, 03:33:40 PM
About the buttons perhaps modifying the button driver like the Clipv1 would help: read only 1 row at each tick, and prepare the next row to be read at the next tick. Can you look at it ?

That works fine for all the buttons except for hold.
Also, "View I/O ports" doesn't show a change of GPIOA when hold is active.

Can you post a patch with your changes on flyspray ?
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: pbxy on March 15, 2010, 04:23:24 PM
Can you post a patch with your changes on flyspray ?

Here it is: FS#11111 (http://www.rockbox.org/tracker/task/11111). Nice number!
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: saratoga on March 15, 2010, 05:05:51 PM
Can you post a patch with your changes on flyspray ?

Here it is: FS#11111 (http://www.rockbox.org/tracker/task/11111). Nice number!

Is your name really Pascal Below?  If not, you need to fix that before your patch can go into SVN.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: pbxy on March 15, 2010, 05:09:43 PM
Yes, that's my real name.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 v4, clip v1, v2 & +, and Fuze v1 & v2
Post by: saratoga on March 15, 2010, 05:49:24 PM
Ok then that should be fine.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on March 16, 2010, 03:35:07 PM
I would like to make a new release of mkamsboot, which includes the fix for c200v2, and Clip+/Fuzev2 patching (even if those are still unusable at this moment).

That would also include the md5sums of OFs versions released since mkamsboot 1.1

Can someone test if Clipv2 OF v2.01.35 can be used without bricking your clipv2? md5sum of OF (http://mp3support.sandisk.com/firmware/test/clipv2.zip) is a3cbbd22b9508d7f8a9a1a39acc342c2
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: ranma on March 17, 2010, 01:04:34 PM
I've polished my patch for software backlight brightness control and created a task on flyspray for it:
http://www.rockbox.org/tracker/task/11119
I also added my usb detect patch to the tracker:
http://www.rockbox.org/tracker/task/11120

Still pending:
c200v2 variant detection using gpioa7.
Waiting for feedback from bertrik (sent him an email with preliminary patch and compiled rockbox.sansa / english.lng).

For reference:
OF does variant detection by setting a7 to input and reading it back.
If 0 => my variant, a5 is buttonlight, a7 is backlight, d7 is 'menu' text light below power/menu button, no usb detect pin found so far
If 1 => other variant, a5 is backlight, d7 is buttonlight
OF (c200-03.02.05) has fiq handler for backlight pwm at 0x3d38, which reads the model variable from 0x202e9 (at 0x3d48) and backlight toggling at 0x3d8c (on) and 0x3da0 (off).
This variable is set by init_hardware(0x8000) subroutine, which also checks for another pullup/pulldown value on a1 on my model (usbdetect on other variant) and stores that at 0x202e8.

[edit]
OF VIC vectors:
Code: [Select]
> mdw phys 0xC6010100 0x10
0xc6010100: 00003d2c 00003bf4 00008e9c 00003d08 00003cfc 00003d14 00003d20 00003cf0
0xc6010120: 00000000 00003c5c 00003c74 00000000 00000000 00000000 00000000 00000000
> mdw phys 0xC6010200 0x10
0xc6010200: 00000021 00000024 00000023 0000002e 0000002d 00000025 00000027 0000002c
0xc6010220: 00000000 0000003d 0000003e 00000000 00000000 00000000 00000000 00000000

irq1 / timer1 => 0x3d2c
irq4 / dmac => 0x3bf4
irq3 / usb =>0x8e9c
irq14 / i2sout => 0x3d08
irq13 / i2sin => 0x3cfc
irq5 / nand => 0x3d14
irq7 / mci irq0 => 0x3d20
irq12 / i2caudio => 0x3cf0
irq29 / gpio a => 0x3c5c
irq30 / gpio b => 0x3c74

The gpio a handler checks for a6 and acks a6.
The gpio b handler is a bit more complicated, but it definitely acks b0.
[/edit]
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: just_me on March 18, 2010, 05:44:17 PM
@funman
> #define USB_PRODUCT_ID 0x74d1

Maybe add the USB ID for

Sansa Clip+ (mtp) or
Sansa Clip+ (msc)

to "The USB ID Repository"
https://usb-ids.gowdy.us/read/UD/0781/
as well?

Greetings,
Frieder
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on March 19, 2010, 11:17:24 AM
the entry already present is for mtp (0x74d0), 0x74d1 is msc

I don't know how to edit entries, nor do i have a login so feel free to complete/correct this list
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: just_me on March 19, 2010, 11:48:05 AM
thanks, done.
(as a human operator checks it it will probably take a while until it really shows up)
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: lazy on March 21, 2010, 02:16:33 PM
I would like to make a new release of mkamsboot, which includes the fix for c200v2, and Clip+/Fuzev2 patching (even if those are still unusable at this moment).

That would also include the md5sums of OFs versions released since mkamsboot 1.1

Can someone test if Clipv2 OF v2.01.35 can be used without bricking your clipv2? md5sum of OF (http://mp3support.sandisk.com/firmware/test/clipv2.zip) is a3cbbd22b9508d7f8a9a1a39acc342c2

does that fix the boot for the c200v2 that did not boot before
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on March 21, 2010, 02:20:39 PM
includes the fix for c200v2

does that fix the boot for the c200v2 that did not boot before

Yes, i still want to wait until someone with a clipv2 test the last OF, so in the meantime you can build your own from svn
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: FlynDice on March 22, 2010, 02:23:25 AM
Just a little clip+ update.  If you haven't seen it by now, funman found the magic line to get sound!  I played music all day today with no problem whatsoever(with playback that is).  I am still working on writes to the SD cards with very little luck so far.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: mitk on March 22, 2010, 04:13:34 AM
FlynDice, funman: Is this code in svn? I've flashed clip+8G with firmware made from svn r25276 and got ATA error. Is it consequence of differences between 2g and 8G clip+ or just I need to wait for your code in to svn?

Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on March 22, 2010, 05:09:36 AM
It works no brick as of yet says Version V02.01.35A and like I said it did not brick

Thanks, mkamsboot 1.2 on its way to the download server

FlynDice, funman: Is this code in svn? I've flashed clip+8G with firmware made from svn r25276 and got ATA error. Is it consequence of differences between 2g and 8G clip+ or just I need to wait for your code in to svn?

All the code is in SVN.

I just tried r25287 (both normal build & bootloader) and it works fine, so sorry that there are differences between the Clip+ FlynDice uses and yours.

I believe bug reports will not be useful until he gets SD fully working, but perhaps you can try to build other revisions and last revision until it works.

If you identify a certain commit which made your Clip+ work/not work then you should say which one it is (unless it says so in the commit message already).
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: pbxy on March 22, 2010, 07:16:41 AM
Just a little clip+ update.  If you haven't seen it by now, funman found the magic line to get sound!

Works great on ClipV2, too. :)
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: FlynDice on March 22, 2010, 10:32:44 AM
@ mitk

What number was your ata error?
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: mitk on March 22, 2010, 01:05:01 PM
FlynDice: It is ATA error: -2

After press ON to debug:
GPIOA: 24 DIR: 20
GPIOB: C4 DIR: E5
GPIOC: 41 DIR: 00
GPIOD: 9F DIR: 00

CP15: 0x0005107D

And after press LEFT:
*PANIC*
ata: -2

It is svn r25276. I will check it with newer version.

Edit:

I've made format my player and tried to run r25276 again and it works, so there is no case.


Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: ranma on March 23, 2010, 07:35:30 AM
Quote from: lazy link=topic=14064.msg163949#msg163949
does that fix the boot for the c200v2 that did not boot before

It should boot, but the fix for the backlight is not in svn yet.
You still need this patch, to get a working backlight, a more proper fix will come later.

Code: [Select]
Index: rockbox-pwm/firmware/target/arm/as3525/sansa-c200v2/backlight-c200v2.c
===================================================================
--- rockbox-pwm.orig/firmware/target/arm/as3525/sansa-c200v2/backlight-c200v2.c 2010-03-18 01:11:34.328140932 +0900
+++ rockbox-pwm/firmware/target/arm/as3525/sansa-c200v2/backlight-c200v2.c 2010-03-18 01:13:26.107078294 +0900
@@ -37,12 +37,12 @@
 
 static void _ll_backlight_on(void)
 {
-    GPIOA_PIN(5) = 1<<5;
+    GPIOA_PIN(7) = 1<<7;
 }
 
 static void _ll_backlight_off(void)
 {
-    GPIOA_PIN(5) = 0;
+    GPIOA_PIN(7) = 0;
 }
 
 void _backlight_pwm(int on)
@@ -56,7 +56,7 @@
 
 bool _backlight_init(void)
 {
-    GPIOA_DIR |= 1<<5;
+    GPIOA_DIR |= 1<<7;
     return true;
 }
 
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on March 23, 2010, 02:39:48 PM
mkamsboot 1.2 is now available at the usual location (http://download.rockbox.org/bootloader/sandisk-sansa/mkamsboot/)
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: stel on March 23, 2010, 03:28:40 PM
I'm another happy RB clip+ user but I've come across a problem. I don't know if it's too early days to report it (just say if it is).
Symptoms are exactly the same as FS#11114 but I'm using MPC files. Sometimes I can get to the end of a track and then it data aborts but I never get to play more than one track and it happens both on both internal & external memory.
I haven't had any issues so far with mp3 files :)

Example error I've had before the clip+ locks up or restarts:

data abort at 30006D14
FSR 0x8
(domain 0, fault 8 )
address 0x74E452F7
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: FlynDice on March 23, 2010, 03:33:10 PM
Well I almost have sd-as3525v2.c send_cmd() working with the CD int but it seems playing music gets in the way... ;)

If you understand Stkov ata/sd and/or data aborts could you do me a favor and comment on:

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

I can load & run rockbox from the main SD, browse files & display album art, but as I said, playing fails.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: bYOndo on March 25, 2010, 06:26:35 AM
Just flashed my ClipV2 8GB, no problems at all. Finally, thanks for your _great_ work!
A mere detail: mkamsboot asks for "m300a.bin" but the OF is named "m30pa.bin", I renamed it and it worked.
A strange behaviour In RB: when you press pause or switch off the clip during music playing, it makes a little "buzz" sound.
The booting time is even faster than OF :)

Massimo

edit:
ops...my fault regarding OF filename, it was my too little attention on copy&paste of mkamsboot command line :)   
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: bYOndo on March 25, 2010, 10:09:46 AM
Just flashed my ClipV2 8GB, no problems at all. Finally, thanks for your _great_ work!
A mere detail: mkamsboot asks for "m300a.bin" but the OF is named "m30pa.bin", I renamed it and it worked.
A strange behaviour In RB: when you press pause or switch off the clip during music playing, it makes a little "buzz" sound.
The booting time is even faster than OF :)

Massimo
   

yea but just rename the FW back to m30pa.bin after you should be fine but I have a 2G clip V2 so mabey it is different Rockbox runs fine for me :) don't know where you are hearing the buzz sounds I dont hear anything maybe you messed with the gain?

it's barely audible, but it's there, it's like an electric discharge sound effect (if you know the song "(-) Ions" by Tool, that sound!)
it's related to "fade on pause" option, because if I disable it, this issue disappears. 

Quote
EDIT: One more thing there seems to be a problem with the database I cant export/import settings any idea when this will be fixed?

funman has just replied to it :) Let's wait!

Massimo 
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: misterhh on March 26, 2010, 02:25:21 AM
I just installed rockbox on my 4GB Clip+, rebooted into rockbox successfully, and played that block-breaking game. Then I selected Chopper, and I'm pretty sure it bricked. I cant turn it on, or connect it via USB. I know this is risky no-warranty software, but is there any way to force reset, etc?

edit: woah that was a scare, I held down the power button for 15 seconds then tried again and it turned on.
Title: Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
Post by: oxide on March 26, 2010, 09:37:41 AM

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.

The Clip v2 with the Sandisk 02.01.32 firmware does indeed play flat. In fact, it plays about 19 cents or 1/5 of a semitone flat. Enough to where it makes it so that if I play along on an in-tune guitar with a track that I know is in tune, it's out-of-tune with the Clip v2 with 02.01.32 firmware. Sandisk recently released new 02.01.35 firmware that fixes this pitch problem - the Clip v2 with 02.01.35 firmware now plays pretty much in tune.

HOWEVER! Doing the "play-along" test, I notice that the new Rockbox for the Clip v2 (thanks for all the hard work, guys!) also plays noticeably flat. I'm not sure if it's the exactly the same amount flat as the 02.01.32 firmware (someone with instrumentation will have to measure it), but it's noticeably flat.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: bertrik on March 26, 2010, 10:11:18 AM
Rockbox on AMS sansa (at least the clipv1, fuzev1 and e200v2) plays with a sample rate error of about 0.15%. It is possible to reduce this to 0.04% error by either 1) changing the entire clocking scheme of the AMS  sansa or by 2) enabling a separate PLL for generation of the sample rate clock.
Option 1) is a bit controversial because it affects other sub-systems too (like maximum attainable CPU speed, display update rate, clocks for SD card access).
Option 2) takes a bit more power from the battery than we currently do, reducing runtime by approximately 2.5%
See the following patch for an implementation of option 2: http://www.rockbox.org/tracker/task/10906
The same trick can probably also be used to reduce the error on clipv2 players.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: bYOndo on March 27, 2010, 05:57:17 AM
Rockbox on AMS sansa (at least the clipv1, fuzev1 and e200v2) plays with a sample rate error of about 0.15%. It is possible to reduce this to 0.04% error by either 1) changing the entire clocking scheme of the AMS  sansa or by 2) enabling a separate PLL for generation of the sample rate clock.
Option 1) is a bit controversial because it affects other sub-systems too (like maximum attainable CPU speed, display update rate, clocks for SD card access).
Option 2) takes a bit more power from the battery than we currently do, reducing runtime by approximately 2.5%
See the following patch for an implementation of option 2: http://www.rockbox.org/tracker/task/10906
The same trick can probably also be used to reduce the error on clipv2 players.

And a permanent pitch modification? Maybe thru a string on config.cfg. It's less elegant and I don't know how much power it drains, I test a 440hz sample with a tuning fork next to the other ear and with a 101.1% of pitch correction it sounds perfectly in tune.
It changes both time&pitch so it's correct, isn'it?

just my 2 cents.
Massimo
 
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: FlynDice on March 27, 2010, 06:32:22 PM
A bit more SD related info.  I believe the controller we're dealing with is The Synopsys DesignWare® Mobile Storage Host Controller.  Here is a link to a document with some info on page 119 - 120: 

https://www.synopsys.com/dw/doc.php/doc/dwf/manuals/dw_frg.pdf

There is another 3 page .pdf available with a little bit more info but you need to register to access it.  I did and there wasn't much more info there.  They call it a datasheet but it's not the datasheet that would really help us.  The one thing i did pick out of it though is that there are separate clocks to the card interface unit and the bus interface unit.  I'm guessing CGU_MEMSTICK is going to the BIU and the CGU_BASE + 0x3C that is now renamed CGU_SDSLOT is going to the CIU.  That would make sense with the frequencies we are running those at.  CGU_IDE is still required as in the as3525v1 for reasons we still don't fully understand.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on March 27, 2010, 11:01:06 PM
EDIT: backlight brightness fixed, bootloader updated
EDIT2: this means you shouldn't follow these directions

Looking for fuzev2 testers, the LCD started working today

There seems to be 2 different LCD types, at least me and kugel have the same type, so I would like to know if other people have the (hypothetical) other type of LCD on their fuzev2.

To test:

If your fuzev2 doesn't display anything when booting rockbox code, power it off by keeping power pressed for ~20 seconds, then power it with left key pressed to boot the OF and update with an unmodified OF (http://mp3support.sandisk.com/firmware/fuze/fuze02.03.31.zip).

Then come to us on the forum or irc so we can try custom code on your player
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: FlynDice on March 28, 2010, 07:30:06 PM
Well I have tracked the write errors down to what I believe is a FIFO problem but I haven't been able to fix it yet.  SD writes fail because we keep getting a FRUN error (FIFO over/underrun).  I have tried changing the FIFOTH values but have had no luck yet.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on March 30, 2010, 11:30:37 AM
Just throwing random ideas:

Could it be that we need different DMA settings when doing writes?
Have you tried PIO mode instead of DMA for writes?
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: FlynDice on March 31, 2010, 01:08:01 AM
Have you tried PIO mode instead of DMA for writes?

Funny that you bring this up as i just found a spot in the disassembly where it chooses dma or pio depending on a 1 or 0 value.

I haven't actually tried too much the past couple of days as my laptop screen died when i was off at work on a trip.  Researching a replacement now.

I have played with the fifoth settings a bit and different dma settings with no luck.  If I'm reading the controller "info" correctly(I can't call it a datasheet...) this fifo is actually 4096 words deep and we actually "roll our own" FIFO depth by setting the MCI_FIFOTH watermark values.   There is a macro in the linux patch that describes how to find the FIFO depth.

I don't think I'm going to get much done in the next few days besides finding a new laptop but I'll dive back in after that!
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: fpsvash on March 31, 2010, 02:07:07 AM
EDIT: backlight brightness fixed, bootloader updated

Looking for fuzev2 testers, the LCD started working today

There seems to be 2 different LCD types, at least me and kugel have the same type, so I would like to know if other people have the (hypothetical) other type of LCD on their fuzev2.

To test:
  • download this patched OF version 2.3.31 (http://rafael.carre.perso.sfr.fr/fuzpa.zip) and a current build (http://build.rockbox.org/data/rockbox-sansafuzev2.zip)
  • unzip both archives on the root of the fuzev2
  • unmount/eject and disconnect: firmware update starts, player powers down itself
  • Keep pressing Left and power on : OF start (it'll work as before, you can shut it down at this point)
  • Power on without touching left : you should see the rockbox bootloader and then the rockbox menu
  • Since buttons do not work yet, you must force a power off by keeping power button pressed for ~20 seconds

If your fuzev2 doesn't display anything when booting rockbox code, power it off by keeping power pressed for ~20 seconds, then power it with left key pressed to boot the OF and update with an unmodified OF (http://mp3support.sandisk.com/firmware/fuze/fuze02.03.31.zip).

Then come to us on the forum or irc so we can try custom code on your player
This worked fine for me and I'll gladly be a tester if you need me.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: luca on March 31, 2010, 09:22:35 AM
My FuzeV2 is working really well  ;D I put some music on the uSD and it has been playing for more than half an hour with absolutely no glitches. The only thing I could notice is that the clock is offset by a constant: at 14:41 local time, it showed 05:10, but I've no idea of whether RB was using 12-hrs or 24-hrs mode for display. The offset is constant since at 15:24 it shows 05:53, the difference (about 9hrs 31mins) is the same.
Congratulations for the great work :)
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: keland44 on March 31, 2010, 11:30:19 AM
EDIT: backlight brightness fixed, bootloader updated

Looking for fuzev2 testers, the LCD started working today

There seems to be 2 different LCD types, at least me and kugel have the same type, so I would like to know if other people have the (hypothetical) other type of LCD on their fuzev2.

To test:
  • download this patched OF version 2.3.31 (http://rafael.carre.perso.sfr.fr/fuzpa.zip) and a current build (http://build.rockbox.org/data/rockbox-sansafuzev2.zip)
  • unzip both archives on the root of the fuzev2
  • unmount/eject and disconnect: firmware update starts, player powers down itself
  • Keep pressing Left and power on : OF start (it'll work as before, you can shut it down at this point)
  • Power on without touching left : you should see the rockbox bootloader and then the rockbox menu
  • Since buttons do not work yet, you must force a power off by keeping power button pressed for ~20 seconds

If your fuzev2 doesn't display anything when booting rockbox code, power it off by keeping power pressed for ~20 seconds, then power it with left key pressed to boot the OF and update with an unmodified OF (http://mp3support.sandisk.com/firmware/fuze/fuze02.03.31.zip).

Then come to us on the forum or irc so we can try custom code on your player

hey just wanted to let you know I got it going on one of my v2 fuze's i have with me now and it comes up when I get home if i remember i'll get it going on my other one
like you said the buttons don't function but it does display the rockbox software and I can go back and forth between the of and rockbox
if there is something else I can help out with let me know do I have two of these I can use to test for you at least till possibly this weekend
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: dsimcha on March 31, 2010, 12:53:45 PM
My FuzeV2 is working really well  ;D I put some music on the uSD and it has been playing for more than half an hour with absolutely no glitches. The only thing I could notice is that the clock is offset by a constant: at 14:41 local time, it showed 05:10, but I've no idea of whether RB was using 12-hrs or 24-hrs mode for display. The offset is constant since at 15:24 it shows 05:53, the difference (about 9hrs 31mins) is the same.
Congratulations for the great work :)

I'd like to help with testing this thing.  I've got RB on my FuzeV2, and it boots and all, but I can't figure out how to navigate the menus given that the scroll wheel doesn't work yet, blocking further testing.  Tips?
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: mate on March 31, 2010, 02:47:43 PM
@dsimicha

wait until kugel figures out how to use it;)
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: keland44 on April 01, 2010, 11:22:48 AM
EDIT: backlight brightness fixed, bootloader updated

Looking for fuzev2 testers, the LCD started working today

There seems to be 2 different LCD types, at least me and kugel have the same type, so I would like to know if other people have the (hypothetical) other type of LCD on their fuzev2.

To test:
  • download this patched OF version 2.3.31 (http://rafael.carre.perso.sfr.fr/fuzpa.zip) and a current build (http://build.rockbox.org/data/rockbox-sansafuzev2.zip)
  • unzip both archives on the root of the fuzev2
  • unmount/eject and disconnect: firmware update starts, player powers down itself
  • Keep pressing Left and power on : OF start (it'll work as before, you can shut it down at this point)
  • Power on without touching left : you should see the rockbox bootloader and then the rockbox menu
  • Since buttons do not work yet, you must force a power off by keeping power button pressed for ~20 seconds

If your fuzev2 doesn't display anything when booting rockbox code, power it off by keeping power pressed for ~20 seconds, then power it with left key pressed to boot the OF and update with an unmodified OF (http://mp3support.sandisk.com/firmware/fuze/fuze02.03.31.zip).

Then come to us on the forum or irc so we can try custom code on your player

hey just wanted to let you know I got it going on one of my v2 fuze's i have with me now and it comes up when I get home if i remember i'll get it going on my other one
like you said the buttons don't function but it does display the rockbox software and I can go back and forth between the of and rockbox
if there is something else I can help out with let me know do I have two of these I can use to test for you at least till possibly this weekend

just wanted to let you know I was able to get it going on my v2 fuze and the visual was able to come up and let me see rockbox and going back to the OF pressing the left button works also.
Keep up the great work.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: sierra2kilo on April 01, 2010, 01:39:59 PM
I'm having trouble getting it working on my clipv2. The bootloader installs and boots fine, but it doesn't want to load the patched firmware (and I've tried patching and loading it twice), due to the checksum not matching.

It's supposed to be this: 2A4F256
But it's getting this: SA4F26A

Length is 6BDC0, if that's helpful, and I used 2.01.32.

Any ideas?

Thanks!
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on April 01, 2010, 01:49:43 PM
Download current build (http://build.rockbox.org/data/rockbox-sansaclipv2.zip) and unzip it on the player
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: sierra2kilo on April 01, 2010, 08:20:05 PM
Download current build (http://build.rockbox.org/data/rockbox-sansaclipv2.zip) and unzip it on the player

Now I'm getting a mismatch of -255 and -269.

???
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: kaps on April 01, 2010, 08:58:44 PM
EDIT: backlight brightness fixed, bootloader updated

Looking for fuzev2 testers, the LCD started working today

There seems to be 2 different LCD types, at least me and kugel have the same type, so I would like to know if other people have the (hypothetical) other type of LCD on their fuzev2.

To test:
  • download this patched OF version 2.3.31 (http://rafael.carre.perso.sfr.fr/fuzpa.zip) and a current build (http://build.rockbox.org/data/rockbox-sansafuzev2.zip)
  • unzip both archives on the root of the fuzev2
  • unmount/eject and disconnect: firmware update starts, player powers down itself
  • Keep pressing Left and power on : OF start (it'll work as before, you can shut it down at this point)
  • Power on without touching left : you should see the rockbox bootloader and then the rockbox menu
  • Since buttons do not work yet, you must force a power off by keeping power button pressed for ~20 seconds

If your fuzev2 doesn't display anything when booting rockbox code, power it off by keeping power pressed for ~20 seconds, then power it with left key pressed to boot the OF and update with an unmodified OF (http://mp3support.sandisk.com/firmware/fuze/fuze02.03.31.zip).

Then come to us on the forum or irc so we can try custom code on your player

Just booted both OF and Rockbox perfectly fine.  Was able to browse all menus on Rockbox, play music, skip, pause, etc.  Powered off easily.  I'm willing to help with whatever testing needed.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: kugel. on April 02, 2010, 06:58:12 AM
My FuzeV2 is working really well  ;D I put some music on the uSD and it has been playing for more than half an hour with absolutely no glitches. The only thing I could notice is that the clock is offset by a constant: at 14:41 local time, it showed 05:10, but I've no idea of whether RB was using 12-hrs or 24-hrs mode for display. The offset is constant since at 15:24 it shows 05:53, the difference (about 9hrs 31mins) is the same.
Congratulations for the great work :)

I might add that there's the possibility of losing the DRM-capabilities of the OF when you set correct time for the time. We had this on the v1 devices IIRC.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: ramdumbum on April 02, 2010, 01:50:50 PM
4GB Sansa Clip+ : RB r25404 : 8GB uSD

I've been using r25404 for few days now with no major headaches (tried r25416 but no RB boot after several attempts; rebooted OF and downgraded RB back to r25404). 

Got around no disk write by writing my own config.cfg file then manually saving it via the PC into the root of RB. 

So far no disk write has not really been a bummer even though I can't save the bagillion dollars I won playing the blackjack game.  Sometimes hit and miss with the apps and games-- meaning the occasional error message and reboot.  No biggy because my little clip+ is so much more useful. 

Thank you to all the developers.

-ps I must admit that I am eagerly awaiting the disk write breakthrough because keeping a Last.fm log would be the bees knees :).
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Dumas on April 02, 2010, 02:55:58 PM
Fuze V2:

Been bug-hunting.  Almost everything works.  Everything I've found that DOESN'T work seems to be directly related to the read-only thing.  The only crash I've had so far was with a bad mp3 that also killed Winamp on my PC.  I haven't got too much time on my hands, but I'll keep playing with it.

Feel free to tell me to RTFM, but I have a couple of questions:

-Has anyone done temporary workarounds in the past for read-only-mode use?  I can't confess to knowing much of Rockbox's guts yet, but could we generate the database, for example, on our computers instead?

-Do we have a standard list of test files for each of the file types Rockbox plays?  I mean, I have loads of mp3's, but I may not have them in a wide variety of bitrates for example.  I certainly don't have every one of the less-common file types.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: saratoga on April 02, 2010, 03:01:34 PM
-Do we have a standard list of test files for each of the file types Rockbox plays?  I mean, I have loads of mp3's, but I may not have them in a wide variety of bitrates for example.  I certainly don't have every one of the less-common file types.

http://download.rockbox.org/test_files/
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on April 03, 2010, 07:21:27 AM
Just to remind you this is not a support thread.


Some of these items are already explained in the rules of this forum (http://forums.rockbox.org/index.php?topic=21176.0), please read them.

What you can do to help if you're not a developer:

If you don't respect those rules your posts will be deleted.
Title: Re: SanDisk Sansa c200v2 SS
Post by: manotroll on April 03, 2010, 01:59:44 PM
dismantling the v2 sansa C240
1 comment
the model itself has 1 battery following photo
link behind image(http://img144.imageshack.us/img144/8075/sansatras.th.jpg) (http://img144.imageshack.us/i/sansatras.jpg/)

voltage is between 0.96 ~ 1.0 v
has 2 chip and do not know what the main

front image
has 1 chip but the numbering of the display both above and below
I hope it helps somehow
image link(http://img96.imageshack.us/img96/2765/sansafrente.th.jpg) (http://img96.imageshack.us/i/sansafrente.jpg/)
Title: Re: SanDisk Sansa c200v2 SS
Post by: saratoga on April 03, 2010, 02:20:06 PM
dismantling the v2 sansa C240

You can find this info and a lot more here:

http://www.rockbox.org/wiki/SansaC200v2
http://www.rockbox.org/wiki/SansaAMS
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: manotroll on April 03, 2010, 02:26:21 PM
just took these pictures because it was written that ecord physician several versions of this model just tried to help

chips back and front of the link that are different from what I have
it will be red and that this influences into something?
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: saratoga on April 03, 2010, 02:39:00 PM
Flash memory and RAM chips are interchangeable, so often different models can be used.  The model number on the AMS 3525 is a bit different, not sure what that means. 

Does rockbox run normally on your player?
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: manotroll on April 03, 2010, 02:50:23 PM
The rockbox does not operate normally in the player only the buttons were lit but soon extinguished, and if he turns up the volume again after 10 seconds and goes out again nothing appears on the display turns black
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: saratoga on April 03, 2010, 02:52:13 PM
The rockbox does not operate normally in the player only the buttons were lit but soon extinguished, and if he turns up the volume again after 10 seconds and goes out again nothing appears on the display turns black

Does this fix it:

http://forums.rockbox.org/index.php?topic=14064.msg164038#msg164038
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: manotroll on April 03, 2010, 03:11:57 PM
The rockbox does not operate normally in the player only the buttons were lit but soon extinguished, and if he turns up the volume again after 10 seconds and goes out again nothing appears on the display turns black

Does this fix it:

http://forums.rockbox.org/index.php?topic=14064.msg164038#msg164038

how to fix this but put in bootloader-c200v2.sansa sansac200v2, or rockbox?
not possible and you already put a version with this fix so I can take the test?
looking for one of anlugo espesifico to see a bar that moves as I put up or down the blue light burns brightly and then goes low light menu button does not light but
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: saratoga on April 03, 2010, 03:17:30 PM
You could do both, but just rockbox should be enough to see if it works.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: manotroll on April 03, 2010, 03:25:15 PM
min and could modify to send me a link page pm or e-mail
because I do not know copille any type of file
thanks
I'm doing this procedure within win should be made by linux?
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Chronon on April 03, 2010, 10:22:13 PM
Here are instructions for building from source if you are on Windows:
http://www.rockbox.org/wiki/SimpleGuideToCompiling

You will have to set up a build environment in either Cygwin, VMWare (or other virtual machine), or CoLinux. 
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: ramdumbum on April 04, 2010, 04:47:05 AM
4GB Sansa Clip+ : RB r25464 : 8GB uSD

I just installed r25464 and I'm getting a lot more stable behavior since attempting changing my functioning player
Quote
I've been using r25404 for few days now with no major headaches (tried r25416 but no RB boot after several attempts; rebooted OF and downgraded RB back to r25404).

And everything seems to be functioning normally; The apps and games that are available in the clip+ distro function as expected, I can load a preset file into the fm and scan through my local stations, but I'm having problems with music playback detailed as follows:

*PANIC*
wait for TRAN state
   failed (STBY)  1


The above error message is what the player displays sporadically while playing music (mostly mp3 (V0) and FLAC), but more often and nearly always after skipping tracks. 
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: saratoga on April 04, 2010, 04:55:13 AM
^^ I think changing the core clock speed screwed up the SD driver.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: FlynDice on April 04, 2010, 12:30:03 PM
@ramdumbum:

That's a good clue for how it may be breaking though so thanks for posting that.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: ramdumbum on April 04, 2010, 12:35:58 PM
After some more specific playing around I think I concur with saratoga
Quote
^^ I think changing the core clock speed screwed up the SD driver.
because I am not getting the afore mentioned *PANIC* error while playing from the on board SD.  The error is still occurring but only when I play files from the uSD card.

I'm not getting the error after extensive skipping and switching between tracks saved on the internal (on board) SD.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: ranma on April 06, 2010, 12:44:48 PM
how to fix this but put in bootloader-c200v2.sansa sansac200v2, or rockbox?
not possible and you already put a version with this fix so I can take the test?
looking for one of anlugo espesifico to see a bar that moves as I put up or down the blue light burns brightly and then goes low light menu button does not light but

Please try this precompiled version:
http://uguu.de/~ranma/rockbox-c200v2/rockbox-c2x0v2-backlightpatch-20100407.zip
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: tofmin on April 06, 2010, 01:55:03 PM
Please try this precompiled version:
http://uguu.de/~ranma/rockbox-c200v2/rockbox-c2x0v2-backlightpatch-20100407.zip

Oh my God! It's alive! Thank U!
Still testing but for 30 min everything is OK.

Sorry 4 bad english.


[edit]
uSD - works
radio - works
playback - works
settings - works
additional font & styles - works

some games - crash
buttonlight - blinking sometimes
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: ramdumbum on April 07, 2010, 02:30:37 AM
Just wanted to say that with the release of r25494 I have not been experiencing the *PANIC* error message nearly as often; in fact I've only had one such fault even while playing and skipping through tracks on the external SD.  On a minor note, I am getting stalls when exiting games (specifically the spacerocks game).  I haven't attempted this on all the games; however, I can exit the blackjack game without any errors. 

Thanks to all the developers for all the great work!
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Shiftlock on April 07, 2010, 05:45:13 AM
Please try this precompiled version:
http://uguu.de/~ranma/rockbox-c200v2/rockbox-c2x0v2-backlightpatch-20100407.zip

Sorry for my ignorance, but what device is this for?  On my Fuze V2 it gives a "Bad checksum" error, but version 25504 (from http://download.rockbox.org/daily/sansafuzev2/rockbox-sansafuzev2.zip) works fine.  Are the Rockbox firmwares interchangeable between all the Sansa models in the title of this thread?  If not, wouldn't it make sense if each model had it's own thread?

Again, I apologize if these are dumb questions.  I've read the manual, FAQ, and wiki, but I'm new to all of this.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: tofmin on April 07, 2010, 05:50:20 AM
Quote
Sorry for my ignorance, but what device is this for?

Sansa c240/250 v2.

BTW: Build 25508 works great too. No more buttonlight blinking, no games crashing. Only sometimes the radio option do not appear in main menu after turning on the device.

Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Shiftlock on April 07, 2010, 09:45:54 AM
Sansa c240/250 v2.

BTW: Build 25508 works great too. No more buttonlight blinking, no games crashing. Only sometimes the radio option do not appear in main menu after turning on the device.

Using 25504 on the Fuze V2, the "FM Radio" option is missing from the main menu.  I assumed that's because it's not yet supported.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: vadik on April 07, 2010, 12:18:53 PM
Oh, hello there. I have a Sansa Clip v2 running OF V02.01.35P. After it got Rockbox (now a local build of r25508), it tends to crash when exiting applications.

I'm just trying to make my way around the code, and have some questions:

- Why is writing to SD disabled? What does "until stable" mean?

- Where's the code that boots OF when left button is pressed? I'm a little thick, couldn't find it for this platform.

- How do you normally debug Rockbox (esp. if you can't write to storage)?

Thank you.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on April 07, 2010, 12:30:30 PM
Using 25504 on the Fuze V2, the "FM Radio" option is missing from the main menu.  I assumed that's because it's not yet supported.

Quote
Sorry for my ignorance, but what device is this for?
Sansa c240/250 v2.
Only sometimes the radio option do not appear in main menu after turning on the device.

http://www.rockbox.org/wiki/SansaAMS#Port_Status
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on April 07, 2010, 12:33:04 PM
- Why is writing to SD disabled? What does "until stable" mean?

Because it doesn't work. "Until stable" means it's disabled until it works in a stable way (in fact it looks like it never worked even in an unstable way).

- Where's the code that boots OF when left button is pressed? I'm a little thick, couldn't find it for this platform.

Look at rbutil/mkamsboot , especially dualboot/dualboot.S, but I advice you don't modify this code because it's very easy to brick your Clip if you do so.

- How do you normally debug Rockbox (esp. if you can't write to storage)?
Thank you.

Print something on the screen (like in the debug menu for example)
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: saratoga on April 07, 2010, 12:47:22 PM
- How do you normally debug Rockbox (esp. if you can't write to storage)?

We have logf, which stores messages to a queue in memory which can be viewed from the debug menu.  To use it, you must configure a build with logf, and then include ROCKBOX_HAS_LOGF in each file you want to log.  See firmware/logf.c
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: torne on April 07, 2010, 12:50:25 PM
The per-file define to enable logf is LOGF_ENABLE. ROCKBOX_HAS_LOGF is what configure sets to include the logf code.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Oysterville on April 07, 2010, 01:09:55 PM
For whatever it is worth, I just signed up for an account in this forum to thank specifically the developers working on the port to the Sansa Fuze v2, and in general ALL of the Rockbox developers.  The way you have been able to squeeze extra functionality out of these mp3 players, even if they are early beta like this port, is amazing and I for one applaud your efforts.

-Dave
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: wildmetal on April 07, 2010, 01:27:51 PM
Greetings!
I have just made an acount on this forum to let you know of my troubles with rockbox on my v2 fuze and i can try diferent build's on my fuze to help find the bugs on v2.
The only build that doesn't give me the  "Bad checksum" on my v2 fuze is this http://download.rockbox.org/daily/sansafuzev2/rockbox-sansafuzev2.zip
And with this build i can browse the contents of the internal memory and the sd card but when i play a song it plays fine but when it should pass to the next song it crashes.
Also i have been trying some games and some of them crashes when exiting.

Cumps
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: FlynDice on April 07, 2010, 03:47:18 PM
It seems that r25502 "Bookmark.c cleanup, still no functional changes... yet" has broken playback from the uSD on my clip+.  I looked quickly and can't see quite why this would be yet.  It also prevents the player from booting with uSD installed.

Anyone else notice this?  Or am I just special again...  ;)
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on April 07, 2010, 03:53:35 PM
See http://www.anythingbutipod.com/forum/showthread.php?t=53702&page=8

Same build works differently on 2 Clip+ -> non-deterministic bug again?

Today I tried to use different transfer request sizes (DMA_S4 / DMA_S1) : no result.

I tried to panicf() from the ISR when the error bits were set but nothing happened, I could insert µSD and see the info in debug menu > disk info, but entering the filebrowser locked the Clip+
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: keland44 on April 07, 2010, 04:39:24 PM
Greetings!
I have just made an acount on this forum to let you know of my troubles with rockbox on my v2 fuze and i can try diferent build's on my fuze to help find the bugs on v2.
The only build that doesn't give me the  "Bad checksum" on my v2 fuze is this http://download.rockbox.org/daily/sansafuzev2/rockbox-sansafuzev2.zip
And with this build i can browse the contents of the internal memory and the sd card but when i play a song it plays fine but when it should pass to the next song it crashes.
Also i have been trying some games and some of them crashes when exiting.

Cumps

i've noticed the same thing with the 0407 build for today maybe tonights build will be different hopefully
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: FlynDice on April 07, 2010, 06:12:47 PM
I was convinced I had solved the random freezups last night by not turning off the dma synchronization logic.  We disable this logic right now and for the v1's I think it's ok but for the v2's I think we probably should leave it enabled for the sd controller.  The manual says that if the dma controller and the peripheral are using the same clock you can disable this logic to get better throughput.  I think with the v2's though we are definitely on 2 different clocks.  Well, I added this change to what I was working with and got 8 straight hrs with no lockup last night.  I turned the unit off at that point, reverted to svn and started adding my changes part by part to see what the magic piece was and now I can't seem to get back there.  I figured it was either only configuring the FIFO once or the DMA sync logic but perhaps it  is a timing issue and some of the debug code I had in place was making it work.  Still investigating...  I have tried different watermark levels and different dma sizes and like funman have had similar results.

As far as SD writes go the problem to solve now is a FIFO over/underrun error whenever we try to write to the card.  We do get data into the FIFO as you can read the MCI_FIFO_COUNT to see how many bytes are there but I have not yet gotten to looking at  the MCI_TCBCNT & MCI_TBBCNT registers (card byte count & bus byte count) nor any sd card response values which may help.

Edit:

On further thought perhaps playing with the software hold enabled on the clip+ is what helps.  Testers?  please report your results good or bad!
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: yelped on April 07, 2010, 10:03:33 PM
Thanks for the update and "Keep up the great work"!

(Delete this post when you're done reading it) ;)
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: vadik on April 08, 2010, 10:52:50 AM
Look at rbutil/mkamsboot , especially dualboot/dualboot.S, but I advice you don't modify this code because it's very easy to brick your Clip if you do so.

Thanks. I just wanted to flip the condition to boot OF by default, which is unlikely to brick the device. (Famous last words, I know.)

As far as SD writes go the problem to solve now is a FIFO over/underrun error whenever we try to write to the card.  We do get data into the FIFO as you can read the MCI_FIFO_COUNT to see how many bytes are there but I have not yet gotten to looking at  the MCI_TCBCNT & MCI_TBBCNT registers (card byte count & bus byte count) nor any sd card response values which may help.

Quite interesting.  I took a look at the code and the AS3525 datasheet (linked to from the SansaAMS wiki page), but is it the correct datasheet for the SoC inside Clipv2?  For one, the SD controller's base address is different (SD_MCI_BASE 0xC8020000 in as3525.h and the datasheet, SD_BASE 0xC6070000 in sd-as3525v2.c).  Are there other secret documents I have yet to find?

Edit: found the MMC/SD Controller Interface spec (I think this is the right model):
http://download.chipestimate.com/dscache/techdocs/PL180_TRM.pdf
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: wildmetal on April 08, 2010, 12:06:10 PM
Greetings!
I have tried the new build but i'm still getting the "Bad checksum" error on my v2 fuze  >:(
Do i need to make a new patched OF for the build's to run?

Cumps
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: FlynDice on April 08, 2010, 01:44:31 PM
@vadik

One of the big differences in the v1 and v2 chips is the sd controller(s).  The as3525v1 has 2 pl180 controllers(1 paired with internal, 1 paired with uSD) that we have documentation for and understand quite well.  The v2's have a different controller and setup.  I think we have identified the controller (find it in one of my previous posts) which has both the internal and uSD attached to it.  Unfortunately all we have are some lunux patches, marketing sheets, and our own exprimenting to "deduce" how we need to use it.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: keland44 on April 08, 2010, 04:51:43 PM
just to report this http://download.rockbox.org/daily/sansafuzev2/rockbox-sansafuzev2-20100408.zip build works pretty well on my v2 fuze 4gb when i get home i'll test it on my other v2 fuze to see how it works
but the playback seems to be working pretty well on this one i haven't tested any of the other stuff
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: vadik on April 08, 2010, 08:52:50 PM
I think we have identified the controller (find it in one of my previous posts) which has both the internal and uSD attached to it.  Unfortunately all we have are some lunux patches, marketing sheets, and our own exprimenting to "deduce" how we need to use it.

Synopsys DesignWare® Mobile Storage Host Controller?  This seems to be a spec for hardware designers: https://www.synopsys.com/dw/doc.php/iip/DWC_mobile_storage/latest/doc/dwc_mobile_storage_db_eval.pdf .  It says:

Quote
1.2.6 Example Linux Demonstration Software Package Features
❖ DWC_mobile_storage controller-specific host-driver APIs
❖ DWC_mobile_storage controller-independent, SD_MMC_CEATA protocol-specific bus-driver APIs
Note: The software driver is available on request. Contact Synopsys support center for more information.

Seems worth a try.  (There are more documents at http://www.synopsys.com/dw/ipdir.php?c=dwc_mobile_storage , but you can only download two without signing up for an account.)

Oh, and can you point me to the Linux patches?

Now, something else I don't get.  What exactly is this AS3525v2?  (A quick google search brought lots of Rockbox references.)  Is it ARM926EJ-S?  (Not that I know the difference)  Is it a variant of AS3525 hacked by SanDisk or something different?  Is there a spec or at least a summary of differences between AS3525 and v2?

Thanks for answering...  And for writing Rockbox, while I'm at it.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: saratoga on April 08, 2010, 09:17:48 PM
Seems worth a try. 

It has been tried.  Do a search for Synopsys in this thread. 

Now, something else I don't get.  What exactly is this AS3525v2?  (A quick google search brought lots of Rockbox references.)  Is it ARM926EJ-S?  (Not that I know the difference)  Is it a variant of AS3525 hacked by SanDisk or something different?  Is there a spec or at least a summary of differences between AS3525 and v2?

The ARM926EJ-S is a CPU, the AS3525 is a system on a chip.  The V2 (also called +) is some customized version that uses the ARM926EJ-S instead of an ARM922 CPU, has more memory, and some changed hardware (e.g. SD controller). 
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: wildmetal on April 09, 2010, 06:03:22 AM
just to report this http://download.rockbox.org/daily/sansafuzev2/rockbox-sansafuzev2-20100408.zip build works pretty well on my v2 fuze 4gb when i get home i'll test it on my other v2 fuze to see how it works
but the playback seems to be working pretty well on this one i haven't tested any of the other stuff

Greetings!
I have tried this build and the playback works well now, some games still crash.
Maybe this is a stupid question but i have been loocking for the builds for the v2 fuze and don't find them only for the v1 fuze maybe thats why i only get the "bad chesum" error, where in the download section is the v2 builds please, because i would like to try all the new builds for the v2 and report the bugs i found.

Cumps
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Xanikseo on April 09, 2010, 09:21:10 AM
@wildmetal: All the daily builds for fuzev2 are here (http://download.rockbox.org/daily/sansafuzev2/). The newest file is always http://download.rockbox.org/daily/sansafuzev2/rockbox-sansafuzev2.zip. Whatever the day, that file will always be the most up-to-date.

EDIT: There also seems to be a "current" build for the v2 here (http://build.rockbox.org/data/rockbox-sansafuzev2.zip). The most up-to-date of all the options if I'm not mistaken.

BTW I'd just like to take the opportunity to thank all the rockbox developers :D, it's a great project, and I'm so pleased that you've started working on the fuze/clipv2 and clip+.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: wildmetal on April 09, 2010, 11:03:44 AM
Thanks for your reply Xanikseo, i'm already testing a new build and for now the playback works great in the internal memory and on the sd card.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: smartboyathome on April 09, 2010, 11:04:39 AM
You probably know about this, but I thought I would mention it anyway. I was playing around with a build I checked out last night on my Fuze v2 and found that with some of the applications (especially some games and demos) you get flickering and some of the colors get distorted. In addition, it seems that you can't exit the chess game unless you completely reboot the device. I'll try to build a new build today and see if I can find any more bugs in it, so far great job guys! :D

EDIT: After more testing, doom doesn't work giving error "Undefined instruction at 30134348" (I wasn't expecting it to work, just testing), and the text editor completely crashes the player with a black screen.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: wildmetal on April 10, 2010, 05:47:24 AM
Greetings!
I have tried the build from 10/04 and it gives me a white screen when entering in rockbox.
I'm using the from 09/04 and the playback works well, i have tried the game doom but it doesn't work.
I can play bubbles while listening to music but the screen flickers at the botton and this game exit fine with out any problem.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on April 10, 2010, 11:58:48 AM
Some plugins leave me with a black screen when I exit them (Tested on the Clipv2/Clip+/Fuzev2), but keys still work (I can power off fine).

For example: chopper, demistify

I commented out backlight_use_settings() in chopper.c and now it works fine.

backlight_use_settings just reset the timeout to the global_settings value, so it seems to load the value 0 for global_settings.backlight_timeout (0 = never enable the backlight).

Shouldn't global_settings.backlight_timeout be filled with the default value (index=3, timeout = 10sec), or whatever is in the config.cfg file I have ?

I couldn't see where global settings are set to the default values (if they are at all), also I thought it's weird that firmware/backlight.c::lcd_sleep_timeout_value[] is not static (perhaps it was previously used by other files ?).

Can someone put some light over this ?
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Xanikseo on April 10, 2010, 01:08:57 PM
Using the current build on the Fuzev2, I notice the screen only flickers and shows distortions when a larger than small amount of what's on the screen changes, for example when you scroll quickly, or view the fire demo. When only small sections of the screen change and slowly, like when you scroll slowly within one page of a playlist, this doesn't occur.

EDIT: Flickering is unlikely when no music is playing. Can scroll very quickly with no flickering. When playing music, using the scroll wheel at the bottom of a playlist, where there is no movement, does cause flickering. Well I suppose it's just down to how much the chip is working, more work = more flickering.

Also, I think you may already be aware of this, but you can't reduce the volume very much. Anything lower than -39db has no effect on the volume.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: tofmin on April 10, 2010, 02:02:18 PM
Sansa c240 v2.

Every build above 25508 crashing. Can't access to database, setings. Can't skip next/prev song. Don't works cuesheets support... Something wrong happend :(

BTW. Where I can download old b25508?

Sorry 4 bad english
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: ssorgatem on April 12, 2010, 02:48:43 AM
EDIT: backlight brightness fixed, bootloader updated
EDIT2: this means you shouldn't follow these directions

Looking for fuzev2 testers, the LCD started working today

There seems to be 2 different LCD types, at least me and kugel have the same type, so I would like to know if other people have the (hypothetical) other type of LCD on their fuzev2.

To test:
  • download this patched OF version 2.3.31 (http://rafael.carre.perso.sfr.fr/fuzpa.zip) and a current build (http://build.rockbox.org/data/rockbox-sansafuzev2.zip)
  • unzip both archives on the root of the fuzev2
  • unmount/eject and disconnect: firmware update starts, player powers down itself
  • Keep pressing Left and power on : OF start (it'll work as before, you can shut it down at this point)
  • Power on without touching left : you should see the rockbox bootloader and then the rockbox menu
  • Since buttons do not work yet, you must force a power off by keeping power button pressed for ~20 seconds

If your fuzev2 doesn't display anything when booting rockbox code, power it off by keeping power pressed for ~20 seconds, then power it with left key pressed to boot the OF and update with an unmodified OF (http://mp3support.sandisk.com/firmware/fuze/fuze02.03.31.zip).

Then come to us on the forum or irc so we can try custom code on your player
this is not working for me. I must have done something wrong, but when I install the patched OF, everything goes as if it were an unmodified OF. And this happens to me not only with that file, but with every other firmware version i've tried to patch with mkamsboot. I've double-checked i'm using the correct (patched) firmware file and not the original, but my v2 fuze just seems to ignore the RB bootloader.

What amb I missing/doing wrong? I even tried patching with bootloader compiled with arm-elf and arm-elf-eabi chainloads, just in case it made any difference, but without results.

May the problem be that i have the other (hypothetical) LCD type?
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: saratoga on April 12, 2010, 03:02:26 AM
Are you booting with the USB plugged in?
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: ssorgatem on April 12, 2010, 03:19:25 AM
Are you booting with the USB plugged in?

No, I disconnect it from the usb, then upgrade begins, finishes and it powers off. Then I power it on, it shows the splash screen, then database refresh, then language &region selection. Rebooting doesn't show up anything different from OF.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: wildmetal on April 12, 2010, 06:41:13 AM
The builds from 12/04 and 11/04 after some time of playback crashes.
I'm using the build from 09/04 because the palyback in this one works fine.
I can search especific bugs if you tell me witch ones to look for.

cumps
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: ssorgatem on April 12, 2010, 08:43:54 AM
I've tried patching latest OF with  both mkamsboot and bootloader compiled from subversion, without succes.


My v2 fuze won't even try to boot rockbox, just as if the firmware weren't patched.

Any ideas?
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on April 12, 2010, 08:47:03 AM
May the problem be that i have the other (hypothetical) LCD type?

No, else your player would boot and show an empty screen (only backlight).

This could be the same problem we had on c200v2 : USB detection is unreliable and dualboot code always boot to OF.

Are you ready to test modified dualboot code and risk bricking your Fuzev2 ?

Do you feel confident working with patches (we can give you clear instructions, but if you mess up your Fuze is dead)
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: ssorgatem on April 12, 2010, 08:51:53 AM
Yes and yes :)

Of course I would prefer not to brick my fuze, but it has the screen badly scratched and since I got a nokia 5800 xpressmusic in november, I don't use it anymore... but rockbox could change that.

Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on April 12, 2010, 08:58:48 AM
If you can come on irc that would be simpler (look on the left : Support -> IRC)
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: ranma on April 12, 2010, 10:15:39 AM
Sansa c240 v2.

Every build above 25508 crashing. Can't access to database, setings. Can't skip next/prev song. Don't works cuesheets support... Something wrong happend :(

Can you be a bit more precise on 'crashing'?
Does it boot fine, but you can't navigate the menu?
You can start a song, but skipping to next/previous doesn't work?

Really exactly after 25508?
Because that looks unrelated: http://svn.rockbox.org/viewvc.cgi?view=rev&revision=25508
Quote
Gigabeat S: Extend the upper temperature range for battery charging to 50C: OK and 45C: Resume. Currently extended disk activity can cause it to detect overtemp which doesn't quite seem correct. Add macros for the range so that they may be target-specific.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: notlistening on April 12, 2010, 11:51:59 AM
Clip+ observations:

1. When loading a new build of rockbox,  a couple of time I find that the very first time i play a song I just get white noise from the player. After that first play it is fine and great every time after. Even after a reboot. Just testing this appear to be a reproducible by koading the OF playing a sound switching it off and then back to rockbox the first song you play or even speech kill the player and give this white noise effect.

2. If the database is not refreshed in the OF and i force it to shutdown then rockbox takes an age to boot. After a full refresh we have normal boot times for rockbox.

3. Rockbox seems to run for much longer than the OF is that because the low battery level has not been set and is there the potential to damage the battery but draining it too much? Might it be good to warn users of this?

Great job everyone so far.

NL
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: tofmin on April 12, 2010, 11:56:08 AM
When I turn on "cuesheet support" I can't skip to next/prev track. Player hangs in database (sometimes) and I've got randomly "dark blue screens" (in Settings, Database or just after turning on).

If cuesheet support is off, then next/prev buttons works again but player still hangs sometimes with "blue screen" on the LCD and when I use some applications (ie: fire, fft)

Hmm, I remember 25508 coz this was first build which I installed on my player (and tested him almost two days) after apply "backlight patch" for the c200:
http://svn.rockbox.org/viewvc.cgi?view=rev&revision=25499


Sorry 4 bad english. Again. And thx for great job U done!
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on April 12, 2010, 01:35:24 PM
1. When loading a new build of rockbox,  a couple of time I find that the very first time i play a song I just get white noise from the player. After that first play it is fine and great every time after. Even after a reboot. Just testing this appear to be a reproducible by koading the OF playing a sound switching it off and then back to rockbox the first song you play or even speech kill the player and give this white noise effect.

Can't reproduce on my side

2. If the database is not refreshed in the OF and i force it to shutdown then rockbox takes an age to boot. After a full refresh we have normal boot times for rockbox.

It could be because the filesystem is damaged

3. Rockbox seems to run for much longer than the OF is that because the low battery level has not been set and is there the potential to damage the battery but draining it too much? Might it be good to warn users of this?

Rockbox will shutdown when the battery is empty so there is no risk, it runs much longer because we're better at codecs than the OF!
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Xanikseo on April 12, 2010, 04:23:04 PM
Another thing I've noticed on the Fuzev2 (using current build): When skipping tracks, the song mentioned after "Next track:" is the current one playing, it doesn't tell you what the next song will be. You have to leave the now playing screen and return to it to see the next song. Skipping tracks happens to cause the wheel light to flicker on and off annoyingly for about a second as well.

I've found that fiddling with the EQ settings also often causes the Fuze to freeze, needing a hard reset.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on April 13, 2010, 09:59:07 AM
Just to let you know Clipv2 and Clip+ were promoted down to the "'Unusable" category.

That means there's pretty much no point into using them if you're not developing patches for them.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Xanikseo on April 13, 2010, 03:58:02 PM
Got more evidence that the amount of work the cpu is doing has an effect on distortions and flickering in the lcd (like when scrolling fast while listening to music).

If you boost the cpu frequency in the debug menu, the screen starts flickering, even without any music playing. I'm not going to pretend that I know what I'm talking about :P, but could this be a sign of the refresh rate of the lcd and the cpu frequency being out of sync or something?
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: ranma on April 15, 2010, 07:04:41 AM
When I turn on "cuesheet support" I can't skip to next/prev track. Player hangs in database (sometimes)

Hmm, indeed. Never tried cuesheet support before, maybe its an issue with the limited ram size?

and I've got randomly "dark blue screens" (in Settings, Database or just after turning on).

That's a known problem, sometimes the LCD controller gets reset or something... Maybe due to the DBOP noise problem seen on key reads.

If cuesheet support is off, then next/prev buttons works again but player still hangs sometimes with "blue screen" on the LCD and when I use some applications (ie: fire, fft)

Hmm, I remember 25508 coz this was first build which I installed on my player (and tested him almost two days) after apply "backlight patch" for the c200:
http://svn.rockbox.org/viewvc.cgi?view=rev&revision=25499

Sorry 4 bad english. Again. And thx for great job U done!

I tried "cuesheet support" with r25499 and it doesn't work there either, so it's not a regression.
Please remember that C200v2 support is still unstable, and some things might also just be a bit difficult to get to work because of the small amount of RAM (2MB) this hardware has (e.g. recording).
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: saratoga on April 15, 2010, 01:30:51 PM
If cuesheet support tries to allocate more memory then we can afford, we should probably disable it.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: ranma on April 16, 2010, 12:48:23 AM
If cuesheet support tries to allocate more memory then we can afford, we should probably disable it.

It's allocating ~72KB at least (struct cuesheet is freaking big), so that really might be the reason...
99 (MAX_TRACKS) struct cue_track_info are (((80*3+1)*3+4)*99) => 71973 Bytes

Let's see. With cuesheet enabled:
Quote
pcm: 0/176400
alloc: 0/91552
usefl: 0/91552

Without cuesheet:
Quote
pcm: 0/176400
alloc: 0/164624
usefl: 0/164624

So it's 73072 Bytes and practically half of the memory still 'available'.

[edit]
Verifying it's a memory issue:
For the most part the pcm buffer still seems to be larger than necessary, so I halved it, trading it in for 88200 additional Bytes of alloc/usefl.
Now with cuesheet enabled:
Quote
pcm: 0/88200
alloc: 0/179480
usefl: 0/179480
And skipping to next/previous track works _most_ of the time.
Sometimes it still stops playing though, with pcm and alloc/usefl fully filled.
[/edit]

[edit2]
BTW, compiling with '-Os' gives me about 32KB more available memory than the default '-O', maybe that should be made default in configure as with some other archs (e.g. sh, m68k)
[/edit2]

[edit3]
When it stops playing and just sits there with filled buffer not doing anything, it seems to be sitting in codec_pcmbuf_insert_callback in
Code: [Select]
186        while ((dest = pcmbuf_request_buffer(&out_count)) == NULL)
187        {
188            cancel_cpu_boost();
189            sleep(1);    <---- sleeping here
190            if (ci.seek_time || ci.new_track || ci.stop_codec)
191                return;
192        }
Debugger:
Code: [Select]
(gdb) target remote localhost:3333
Remote debugging using localhost:3333
[...]
(gdb) bt
#0  switch_thread ()
    at /home/ranma/src/rockbox-c240v2/firmware/target/arm/system-arm.h:242
#1  0x3003002c in codec_pcmbuf_insert_callback (ch1=<value optimized out>,
    ch2=<value optimized out>, count=47)
    at /home/ranma/src/rockbox-c240v2/apps/codec_thread.c:189
#2  0x30208684 in tree_gui_init ()
    at /home/ranma/src/rockbox-c240v2/apps/tree.c:301
#3  0x00000450 in ?? ()
#4  0x00000450 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) frame 1
#1  0x3003002c in codec_pcmbuf_insert_callback (ch1=<value optimized out>,
    ch2=<value optimized out>, count=47)
    at /home/ranma/src/rockbox-c240v2/apps/codec_thread.c:189
189                 sleep(1);
(gdb) print dest
$1 = 0x0
(gdb) print out_count
$2 = 47
(gdb)
[/edit3]

[edit4]
The problem seems to be that the pcm buffer is completely filled according to one metric (pcm: 88200/88200 in buffering thread debug, pcmbuf_request_buffer returns NULL) and completely empty according to another (pcmbuf_unplayed_bytes is 0, pcmbuffer_fillpos is 0).
[/edit4]

[edit5]
Ok, I think the problem here was just that with a reduced pcm buffer size
the PCMBUF_TARGET_CHUNK and PCMBUF_MINAVG_CHUNK defaults are too big.
With those two reduced to 8192 and 6144 it seems to run pretty well even with a pcm buffer of just 44100 Bytes.   With a pcm buffer that small I do hear occasional short buffer underruns though.

And the hang with unreduced pcm buffer size and cuesheet support enabled is a different kind of hang than what I was seeing here.

BTW, I compared the target configs for the different Sansa 2MB targets and
c200v2 has the biggest PLUGIN_BUFFER_SIZE define of them all.
By reducing it from 0x60000 to 0x45000 like in sansaclip.h or sansam200v4.h
we'd gain enough memory (110592 Bytes) to make cuesheet support work I think.
[/edit5]
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on April 16, 2010, 01:46:28 PM
Perhaps we should disable the few plugins which use a lot of memory
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Timar on April 19, 2010, 10:11:18 AM
Hi,

as I've posted here: http://www.anythingbutipod.com/forum/showpost.php?p=463457&postcount=186 I get playback crashes with all recent rockbox builds on my Clip+. Today I've tried the new 25676. While it crashes as usual it now displays a debug message (reproducable). I thought I'd post it here for it may be usefull for bugfixing:
Code: [Select]
Data abort at 30057FC4
FSR 0x8 (domain 0, fault 8)
address 0xFFFFFFFF
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on April 19, 2010, 10:50:16 AM
unsurprisingly the error is in set_cpu_frequency() which is known to be buggy.

If you force the CPU to always be at maximum (in debug menu -> cpu frequency; set the counter to 1 or more), it shouldn't happen anymore.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Timar on April 19, 2010, 03:01:36 PM
Great, that solved the problem... thanks! So I guess the older builds run stable because they don't have that feature?

Is there any way to save that setting into a cfg file to default it on startup?
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on April 19, 2010, 04:28:06 PM
Is there any way to save that setting into a cfg file to default it on startup?

No.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: ranma on April 20, 2010, 12:03:48 PM
Did some power draw measurements on my C200v2 today:
(http://uguu.de/~ranma/s6001740s.jpg)

OF:
Quote
Playing mp3, display off:
3.85V,  28mA

Playing mp3, display full brightness, buttonlights on:
3.80V,  68mA

rockbox:
Quote
Not playing, settings menu, display full brightness, main buttonlight on:
3.79V,  64mA (Not 68mA because 'menu' light is off I suppose)

Not playing, settings menu, display full brightness, main buttonlight off:
3.81V,  51mA

Not playing, settings menu, display off, buttonlights off:
3.84V,  34mA

Playing mp3, now playing screen, display full brightness, main buttonlight on:
3.76V,  78mA

Playing mp3, now playing screen, display full brightness, main buttonlight off:
3.78V,  65mA

Playing mp3, now playing screen, display off, main buttonlight off:
3.81V,  48mA

[edit]
At funmans suggestion I did a readout of the ascodec state on
both original firmware and rockbox:

Code: [Select]
--- originalfirmware.ascodec.readout.txt 2010-04-21 23:00:48.868252431 +0900
+++ rockbox.ascodec.readout.txt 2010-04-21 23:00:37.391522447 +0900
@@ -1,9 +1,9 @@
 0x00: 00000000
 0x01: 00000000
-0x02: 00000003
-0x03: 00000043
+0x02: 000000c5
+0x03: 00000045
 0x04: 00000000
-0x05: 00000000
+0x05: 00000080
 0x06: 00000000
 0x07: 00000000
 0x08: 00000000
@@ -12,15 +12,15 @@
 0x0b: 00000000
 0x0c: 00000000
 0x0d: 00000000
-0x0e: 00000019
-0x0f: 00000059
+0x0e: 00000016
+0x0f: 00000056
 0x10: 00000000
 0x11: 00000000
 0x12: 00000000
 0x13: 00000000
 0x14: 00000060
-0x15: 0000003f
-0x16: 00000006
+0x15: 00000007
+0x16: 00000000
 0x17: 00000000
 0x18: 00000000
 0x19: 00000000
@@ -30,22 +30,22 @@
 0x1d: 00000000
 0x1e: 00000000
 0x1f: 00000000
-0x20: 00000031
-0x21: 00000016
-0x22: 0000005c
-0x23: 0000000b
+0x20: 00000039
+0x21: 00000004
+0x22: 00000081
+0x23: 00000000
 0x24: 00000000
 0x25: 00000000
 0x26: 00000010
-0x27: 00000001
-0x28: 000000f3
+0x27: 00000030
+0x28: 00000023
 0x29: 00000040
-0x2a: 000000b7
-0x2b: 00000043
+0x2a: 00000092
+0x2b: 00000042
 0x2c: 0000008b
 0x2d: 00000035
 0x2e: 00000002
-0x2f: 000000f5
+0x2f: 000000f7
 0x30: 00000000
 0x31: 00000000
 0x32: 00000000

Main differences are as follows, I'd guess at most the bias current and load setting changes would make a difference in power draw:
Quote
0x02: (HPH_OUT_R)
OF: 0x03: [edit]Overcurrent timeout 256ms[/edit]
RB: 0xc5: 'Do not change, default 0' bit is set to 1[edit]Overcurrent timeout 0ms[/edit]

0x05: (SPH_OUT_L)
OF: 0x00: output normal
RB: 0x80: output muted (power up default)

0x15: (AudioSet_2)
OF: 0x3f: Bias current reduction 50%, AGC disabled
RB: 0x07: No bias current reduction, AGC enabled

0x16: (AudioSet_3)
OF: 0x06: 32 Ohm load or more, cm buffer on, zero cross update disabled
RB: 0x00: 16 Ohm load, cm buffer on, zero cross update enabled

0x20: (System)
OF: 0x31: PVdd unreduced
RB: 0x39: PVdd Vnom*17/18

0x21: (DCDC3)
OF: 0x16: BVDD 3.1V CVDD 1.1V
RB: 0x04: BVDD 3.6V CVDD 1.2V (probably halted it in boost mode?)

0x22: (Charger) [Was not plugged in in both cases, running on battery]
OF: 0x5c: NTC supply on, 100mA, 4.2V, charger enabled
RB: 0x81: NTC supply off, charger disabled

0x23: (DCD15)
OF: 0x0b: 13.75mA [Well, this regulator should be unused, maybe dead code in OF?]
RB: 0x00: off

0x28: (RTCV)
OF: 0xF3: Supply 2.5V
RB: 0x23: Supply 1.2V
[/edit]

[edit2]
I just noticed that the rockbox current draw values might be completely off,
I measured them with a local patch that may have caused BVDD to stay
on the boost value...


No, for one thing it's CVDD, the BVDD 3.6V thing shouldn't really come into play until the battery is nearly empty.
And the voltage scaling code does not get compiled in AFAICS, so it just stays at 1.2V CVDD.

Still the additional current due to higher CVDD shouldn't be too big, I'd expect about 20% increase (1.2^2/1.1^2).
The difference I measured here is more like 70%...
[/edit2]
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on April 21, 2010, 02:28:08 PM
Thanks!

I'll try a bench with modified audioset2 and audioset3 to see if it changes anything. no change

You have dumped CGU registers already, now the only difference I can think of is in GPIO registers ? Can you dump and GPIO_DIR (+0x400) and GPIO_DATA (+0x0) ?

This could give a clue at how c200v2 power is drawn if some PIN is set, but hopefully we could identify the code using it in the OF and compare with other models.




Oh well I remember some code which put SDRAM in self-refresh mode, and most of the audio codecs are loaded in IRAM, so the SDRAM could be disabled (I don't know if this can account for high power usage)

The datasheet for the SDRAM chip (linked from wiki SansaC200v2) has current values page 4, but i'm not sure which one apply (I suppose the correct value is weighted from all of them)

In OF, 0x301C enters self refresh mode (next function leaves the mode), parent 0x1CD8 is called multiple times (I have not identified callers though)

In your post (http://forums.rockbox.org/index.php?topic=14064.msg162645#msg162645) I see that external memory clocks are enabled when playing mp3, perhaps it's enabled/disabled at some high frequency?
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Timar on April 24, 2010, 02:14:42 PM
While with boosted CPU, playback is much more stable, sometimes the Clip still crashes showing the following debug message
Code: [Select]
Data abort at 30026264
FSR 0x8 (domain 0, fault 8)
address 0xB48AD288
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Xanikseo on April 24, 2010, 03:30:48 PM
As it seems the weird flickering issue on the fuzev2 happens when the frequency is boosted - you can see this by boosting the FCLK manually in the debug menu: distortions, flickering and shifting start immediately, even when not doing anything - and as I'm not a developer, I just decided to simply play around with the CPU frequency for the Fuzev2 by changing AS3525_DRAM_FREQ in clock-target.h and see what happens.

So I decided to change the initial dram frequency back to the old 60MHz, and noticed the distortions were taking up less of the screen, and were not so annoying. Then I increased the initial dram frequency again to 80MHz, and lo and behold the problem is noticeably better. No distortions at all when switching tracks, no weird shifting on the screen etc. I then decided to boost the FCLK frequency from the debug menu, and even though FCLK should be at the same frequency as when DRAM was 40MHz, or 60MHz for that matter, distortions were much much less annoying and less frequent.

I've come to the conclusion that this LCD problem is specifically down to the ratio between the DRAM frequency - or at least one of the frequencies dependant on DRAM frequency - and the FCLK frequency. 40MHz is 6x less than 240MHz, 60MHz is 4x less, and 80 is of course 3x less, and the lcd is much much better.

What could be going on?

EDIT: Just discovered that the fire plugin is great way of both introducing lcd problems and seeing them very clearly. 80MHz still causes flickering/distorting a little, 160MHz was again less. I'm pretty certain there's a link between the ratio of DRAM to FCLK and the lcd problem.

I have a funny feeling it's due to the infamous set_cpu_frequency(), perhaps increasing the delay will help, as there seems to be less problems the closer the dram frequency to fclk?
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on April 24, 2010, 05:19:56 PM
Code: [Select]
Data abort at 3002624

You wrote 7 digits but the correct number has 8, can you post the exact number, and the revision you were using ?

What could be going on?

Probably a race condition between LCD code and button code, like what happened on Fuzev1 and e200v2.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: kugel. on April 24, 2010, 08:49:36 PM
It's pretty clear that the current delays needed for switching to "button mode" (by setting the undocumented CGU_IO bit 12) are not high enough to work in boosted mode.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: ranma on April 25, 2010, 02:44:50 AM
Thanks!

I'll try a bench with modified audioset2 and audioset3 to see if it changes anything. no change

I did some tests myself with the multimeter and did find some power savings with those bits set:

Code: [Select]
Setting   Draw
[Idle]
0         35mA
1         35mA
2         35mA
3         35mA
4         32mA
5         32mA
6         32mA
7         32mA

[Playing]
0         50mA
1         48mA
2         46mA
3         45mA
4         46mA
5         46mA
6         43mA
7         42mA

[pcmbuf in iram, Playing]
0         48mA
1         47mA
2         45mA
3         44mA
4         45mA
5         44mA
6         42mA
7         41mA

0: No power saving options
1: AS3514_AUDIOSET3 0x06
2: AS3514_AUDIOSET2 AUDIOSET2_IBR_DAC_50
4: CVDD_1_10

OF
Idle      26mA
Playing   28mA

Quote
You have dumped CGU registers already, now the only difference I can think of is in GPIO registers ? Can you dump and GPIO_DIR (+0x400) and GPIO_DATA (+0x0) ?

Well, dumping the data register doesn't seem to work with the processor stopped, apparently it always reads back as 0. Here are the gpio directions,
it's setting a few additional gpios as output.
Code: [Select]
0xc80b0400: 000000b3
0xc80c0400: 00000070
0xc80d0400: 00000000
0xc80e0400: 00000080

GPIOA: Backlight, main buttonlight, three unknowns...
GPIOB: FM sda/scl and display reset line
GPIOD: Menu button light

Quote
Oh well I remember some code which put SDRAM in self-refresh mode, and most of the audio codecs are loaded in IRAM, so the SDRAM could be disabled (I don't know if this can account for high power usage)

The datasheet for the SDRAM chip (linked from wiki SansaC200v2) has current values page 4, but i'm not sure which one apply (I suppose the correct value is weighted from all of them)

In OF, 0x301C enters self refresh mode (next function leaves the mode), parent 0x1CD8 is called multiple times (I have not identified callers though)

I put hw breakpoints on both and only 0x1cd8 triggers
[edit]
(triggers while playing mp3, didn't check other use cases)

I tried changing the GPIOA settings in rockbox to match OF, but didn't see any differences in power draw regardless of whether setting the additional output bits to 0 or to 1.
[/edit]
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: saratoga on April 25, 2010, 01:05:10 PM
When does 0x1cd8 trigger?  During playback or some other time?
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Timar on April 26, 2010, 04:31:13 AM
You wrote 7 digits but the correct number has 8, can you post the exact number, and the revision you were using ?

I've updated the OP (it took a while to reproduce, it's at 30026264). The crash occurs on track change/skip only.

EDIT: Revision was r25705
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: cris on April 26, 2010, 07:49:21 AM
This is my first post.

Can I first say kudos to all of you who are working on getting a rockbox build working for the Fuze v2. I have for the first time tried the build (and rockbox) on my Fuze 2 and see great potential.  I used the daily build from yesterday (25 April) and a pre-patched firmware .31 version from one of the developers here which was posted on the Sansa forum.  It worked!

Of course there are lots of bugs but no complaints.  Here are some I wanted to report:

1) Volume - the volume will often lock and then it cannot be changed with the scroll wheel or the menu (sometimes the menu will work.
2) Screen flicker - noted already
3) Cue files do not work yet
4) Crashes when flicking through EQ presets (not always)
5) Crashes always when you scroll through some of the higher (or minus that should be) DB values for precut - mine crashes always when scrolling around -4.5/5 DB
6) the Volume seems uncomfortably loud on my in-ear headphones but perfect for my full size headphones.  Is this normal (tried the precut but it crashes)
7) Will sound quality improve in later builds?  It is good but it lacks, what to me is the full bodied sound of the current .31 firmware of the Sansa when listening to flac files.  I am a believer in not using EQ as my headphones sound great with no EQ on the sansa and the fuze sounds excellent through my stereo amp with no EQ so I am thinking of sound quality "out of the box" (of course with the wonderful features of crossfeed and dithering!!! - brilliant)
8) To get round the non-saving issue for settings, I wrote a fixed.cfg file (note the manual has a value of 60 for volume!!!! I think this needs to be -60 to stop your brains being blown out ;-).  In the fixed cfg file I can't seem to successfully be able to set Crossfeed or Dithering but setting volume, bass and treble works fine (as does setting a new theme, which is great because I don't have to change the theme on every boot ;-) due to lack of writing support).


Once again, a big thank you.  I will donate something to the fund in due course.
Happy also to test daily builds and feed back.

Cris


Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on April 26, 2010, 09:55:54 AM
It's pretty clear that the current delays needed for switching to "button mode" (by setting the undocumented CGU_IO bit 12) are not high enough to work in boosted mode.

I added ridiculously long delays after switching CCU_IO in button-fuzev2.c without any visible effect on screen.

EDIT: a delay *before* any operation at the start of the function fixes the glitches
EDIT2: fixed in svn
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on April 26, 2010, 06:37:33 PM
I have something regarding the volume on Fuzev2 (the fact that you can't decrease it below -39dB). I read on the sansa forums a while ago about DIY "line out". They have figured out a pin configuration for what people think might be line-out, except you can actually decrease the volume, but not by very much. This sounds like our problem here. Perhaps we are experiencing this, and are actually using the wrong pins (sorry, don't know if that's the right technical word :P) for audio, ie (some sort of) line-out instead of headphone out?

Found it: http://forums.sandisk.com/sansa/board/message?board.id=sansafuse&thread.id=7792&view=by_date_ascending&page=1

cris' post triggered this thought, since he was saying that the audio had a different feel to it. I figured using rockbox to decode flacs shouldn't really affect audio quality.

From the forum thread:
Quote
The volume needs to be at about 50% or greater (doesn't really increase much from that point on)

This is different from rockbox:

On rockbox, the real volume is completely unaffected by settings the low 50% of the volume range, but still can go quite high.

With the line out cable, the real volume is affected (although only a bit) by the up 50% of the volume range.

I didn't read the whole thread as I'm not sure if it's related to the volume problem.

EDIT: fixed in r25732

By the way AMS didn't answer to my request of the as3543 datasheet :(



About the sound quality I'm completely unconvinced, it sounds perfectly fine to me, although I'm admittedly not an audiophile at all.

I will trust you only if you can back your claim of different sound quality with computer-made analysis of the output (with lossless source and good analogue recording equipment I think)
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: LucaLeonardo.Scorcia on April 27, 2010, 04:47:22 AM
FuzeV2: I can confirm no more flickering with the latest SVN. Locks up when changing EQ settings, sometimes (unfrequent) while playing unboosted. Today I had five lockups and two panics: Undefined instruction at 3005F740, Undefined instruction at 3005F760.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Xanikseo on April 27, 2010, 12:08:07 PM
Wow, volume really works :), another good job funman :D. I don't know if this is intentional, but -74dB doesn't mute the sound, should it?

I'm finding now that during playback (q8 oggs), I get a lot of skipping, it just sounds a bit dodgy now...

I got a crash while switching tracks (not sure if it's related):
Code: [Select]
Prefetch abort
at A742D41C
FSR 0x1
(domain 0, fault 1)

EDIT: Getting a lot of crashes without error reports during playback. Can barely play a few songs before a crash...
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on April 27, 2010, 12:32:36 PM
However, I'm finding now that during playback (q8 oggs), I get a lot of skipping, it just sounds a bit dodgy now...

I can reproduce it too, investigating...

EDIT: fixed in r25740

I got a crash while switching tracks (not sure if it's related):
Code: [Select]
Prefetch abort
at A742D41C
FSR 0x1
(domain 0, fault 1)

EDIT: Getting a lot of crashes without error reports during playback. Can barely play a few songs before a crash...

Make sure you boosted the CPU before reporting crashes (read last pages of this thread)
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Xanikseo on April 27, 2010, 03:18:44 PM
Great, sounds much better!

Also, I've noticed that using the hold switch now takes a while to take effect. Sometimes it takes more than 2 seconds for rockbox to detect it, sometimes not at all! I haven't noticed this before.

EDIT: And another thing :P (god this german oral practice really makes me procrastinate), if you scroll through a long playlist quickly, you can sometimes suddenly jump straight to the end, which can't be right (the playlist I am using is ~500 tracks).

But I have noticed that the button light doesn't flash annoyingly between switching tracks anymore, which is good :D.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on April 27, 2010, 05:03:38 PM
Also, I've noticed that using the hold switch now takes a while to take effect.
Fixed
if you scroll through a long playlist quickly, you can sometimes suddenly jump straight to the end
Probably caused by r25736/FS#11172 : i'll let kugel comment on this
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Xanikseo on April 27, 2010, 05:55:08 PM
Wow quite a successful day ;)!

Can confirm that the hold switch is instantly detected. However (yes, unfortunately there is a but) sometimes the backlight flashes on and off quickly for about a second or two before the backlight finally turns off. It doesn't always happen, but I think it mainly happens during heavy cpu load. If you boost cpu through debug menu, it is easily reproducible. Unfortunately another case of extra delays for the boost :P?..

EDIT: WTF? Sometimes backlight randomly flashes while in hold??? (After unboosting cpu). Ok this is weird, it seems that when the cpu is boosted, it randomly makes the backlight flash (but only when in hold I think)...
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: bilditup1 on April 27, 2010, 05:56:08 PM
Hey all-
Just now, I crashed after selecting an mp3, with the following error:

data abort
at 30027024
FSR 0x8
(domain 0, fault 8)
address 0xBB0F879F

I'm not sure if this was already addressed; if so, sorry. This is from the latest nightly (25733).
-e

UPDATE: Another thing- I'm not sure if this is standard behavior or not, but after shutting down from rockbox, if I connect a USB chord in the Fuze, the original firmware is loaded up and a connection is established, without having to slide the power button...is it staying after shutdown?
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on April 27, 2010, 06:23:21 PM
Can confirm that the hold switch is instantly detected. However (yes, unfortunately there is a but) sometimes the backlight flashes on and off quickly for about a second or two before the backlight finally turns off. If you boost cpu through debug menu, it is easily reproducible. Unfortunately another case of extra delays for the boost :P?..

Yes hold doesn't work when boosted, so possibly the delay needs some tweaking.
EDIT: fixed
EDIT2: fixed properly :p

Hey all-
Just now, I crashed after selecting an mp3, with the following error:

As I just wrote today:
Make sure you boosted the CPU before reporting crashes (read last pages of this thread)

You can do so by increasing the counter in debug menu -> cpu frequency

Another thing- I'm not sure if this is standard behavior or not, but after shutting down from rockbox, if I connect a USB chord in the Fuze, the original firmware is loaded up and a connection is established, without having to slide the power button...is it staying after shutdown?

Plugging USB powers the device, I think it's not documented by rockbox as it's a feature of the hardware (nothing to do with rockbox).

Fuzev2 automatically boots to OF if USB is detected at boot time (we use this as a recovery method).

This is documented in the Fuzev1 manual (http://download.rockbox.org/daily/manual/rockbox-sansafuze/rockbox-buildch3.html#x5-280003.1.3) where most of the content should apply to fuzev2 as well (although not guaranteed).
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: bilditup1 on April 27, 2010, 07:24:54 PM
Aight, so I guess I'll boost the freqs and try to reproduce the error. Sorry for not paying more attention.
-e

Update:

I began to try the newest build today, but it seems microSD support is broken; my card is not recognized. Reverting back to 25733 from 25747 fixes this. Again, apologies if this is not helpful.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Xanikseo on April 28, 2010, 12:34:53 PM
OK some updates...

Hold definitely totally works now, which is great!
The button light has started flashing again while switching tracks though :(. EDIT: Only when unboosted though...
While boosted in debug, and when switching track, I got this error (2 times so far):

Code: [Select]
Data abort
at 30027024
FSR 0x8
(domain 0, fault 8)
address 0xBB0F89FF

In r25750, I got this error while doing the same:
Code: [Select]
Data abort
at 30026FD8
FSR 0x8
(domain 0, fault 8)
address 0xBB0F89BF

I notice that your most recent svn submission seems to have solved all plugin problems, funman :).

EDIT: Switching tracks seems to be generally very slow when done from the now playing screen. While viewing the playlist and selecting files to play, switching is fast. I think it just takes some time to gather the various data in the tags of the current file playing (while in now playing screen), before it even considers playing the next track?

Yes, it seems that when selecting a new file, and then if you jump to the now playing screen, you can't do anything for about 2 seconds. If you don't go to the now playing screen, there's no problem.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on April 28, 2010, 03:14:05 PM
it seems microSD support is broken; my card is not recognized. Reverting back to 25733 from 25747 fixes this.

can you compile your own build ? If so try to change the udelay(1000); into udelay(10000); in firmware/target/arm/as3525/sd-as3525v2.c
EDIT: 10000 might be too high for the function so no need to try : it won't work

Again, apologies if this is not helpful.

You gave a clear description with 2 revisions : working and not working. Sounds like an helpful report to me :)


- pasting what I posted on ABI -

I've put a Clip+ custom build (http://rafael.carre.perso.sfr.fr/rockbox-r25750M-100428-clipplus.zip) on my ISP homepage, can you give it a try ?

I had one crash with it but it seems much more stable than current builds, so I'd be interested to know how it works for other people.

It's based on current SVN + a patch (http://pastie.org/939487) which could give a hint on how to fix the problems properly. And it should work with any bootloader.

No need to force CPU boosting with it (the patch affects the function which changes CPU frequency so if you force boosting then the patch won't run at all).


EDIT: better use a current build, i've pushed some modifications.

I could play a full album on Clip+ / Fuzev2, got a single crash on Clipv2 but different from what I used to see.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Timar on April 28, 2010, 04:31:00 PM
I had one crash with it but it seems much more stable than current builds, so I'd be interested to know how it works for other people.

That's great news, thanks! Runs stable so far (a half an hour)... all other recent builds crashed after 20 seconds of playback at the latest if unboosted :)

EDIT: Still running stable. There's another nice side effect of the new build. On all other builds as well as on the OF there was a buzzing sound at the end of the fade-out as well as at the begin of the fade-in of playback (it was much more distracting on the rockbox though). This sound is completely gone now 8)
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: bilditup1 on April 29, 2010, 12:09:24 PM
Hmm. In 25753, microSD(HC?) support still seems to be screwy.
On start up, an 8GB microSDHC card I've put in doesn't show up. If I insert, remove it a few times, eventually, I get the following screen (black text on white background):

Code: [Select]
*PANIC*
microSD init failed : -8

A regular 2GB microSD card was recognized with no problems.
Any suggestions, guys?

UPDATE: Good pt - this was a Fuze v2.

Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Timar on April 29, 2010, 06:15:14 PM
On my 8gb Clip+, an 8gb MicroSD card works flawless...
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: FlynDice on April 30, 2010, 12:24:04 AM
@Timar

Can you startup with your uSD inserted?   I have been unable to for some time now and I think I have tracked it down to INT_GPIOA not being triggered for some reason on startup.  I can get it to init normally if I wait until rockbox is running but if I try to boot with the card inserted I hang at the rockbox logo.  Anyone else seeing this on clip+?
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: mitk on April 30, 2010, 02:48:01 AM
I've no such problem with clip+ 8G and Sandisk 16G uSDHC card inserted. svn:25754
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Timar on April 30, 2010, 02:51:07 AM
Can you startup with your uSD inserted?
Yes, on all recent rockbox builds, the MicroSD support worked for me, no hangups at startup. Strange... maybe it's dependant of the SD card's parameters? (I'm using an 8gb Sandisc card)
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: bilditup1 on April 30, 2010, 02:51:27 AM
On my Fuze v2, I can startup with a usDHC inserted, but the 8gb card will not be recognized (the 2gb one will). Reverted back to 25733 for the meantime.
-e
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Timar on April 30, 2010, 08:29:27 AM
Got a playback crash on r25761:
Code: [Select]
Data Abort @ 30026228
FSR 0x8 (0, 8)
0xB48ACDA0

EDIT: On Clip+. This crash occured a few times since upgrading from funman's custom build to the latest SVN. I also get "Can't load codec" error msgs.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on April 30, 2010, 08:54:24 AM
That would be in apps/gui/skin_engine/skin_display.c::evaluate_conditional()

If I compare to my rockbox.elf it crashes on line 589 when accessing *value.

I have no idea if it could come from a bug in this code or from mem corruption.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: FlynDice on April 30, 2010, 12:27:24 PM
Well I have my daughter's rockboxed fuzev2 today and I get the same uSD problems as with the clip+ so maybe it's the card.  We had problems with these same Transcend class 6 SDHC cards with the as3525v1 development but that involved the slow times while in the PRG state and not GPIOA.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: DonDan on April 30, 2010, 01:07:26 PM
Hi to everyone!
I use a fuzev2 8GB with a 8GB Transcend cl6 uSDHC card.
On all recent rockbox builds (r25733-r25763) i was able to boot with an 8GB uSDHC inserted, but I can only browse the files, if I want to play a file from it, it goes to the WPS but it doesn't load the tag and it gets stuck on 0:00 seconds (not reading the file?). I am still able to change the volume and to exit the WPS but if I try to go again to the "Files"-Menu or the "Plugin > Games"-Menu it hangs (hold still works but nothing else, need to reboot).

From the internal memory I can browse and play music. Sometimes the music stops after 10-15 songs and after that I cannot load any files anymore (Music or Plugin).

With the r25753-r25763 builds all plugins work great. No black screen after quitting anymore. Volume control works. Doom works. Image viewer works!

Looking forward to read/write support for the internal/external memory. Everything else is working pretty well in the latest build!

Great job folks! Thumbs up!
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: FlynDice on April 30, 2010, 04:54:26 PM
Seems a good old dose of fsck has cleared up my booting problems.  Good thing I spent all that time tracking it down to INT_GPIOA..... >:(

I'm still not able to play off of the uSD though.

Now, back to pio writes with a poor attitude!
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 01, 2010, 03:30:39 AM
On my Fuze v2, I can startup with a usDHC inserted, but the 8gb card will not be recognized (the 2gb one will). Reverted back to 25733 for the meantime.

Can you replace "udelay(1000)" by "sleep(1)" in firmware/target/arm/as3525/sd-as3525v2.c and see if the card works?
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: bilditup1 on May 01, 2010, 06:26:34 PM
I'll try to do this tomorrow night when I'm home; thanks for the suggestion.

-e
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: kugel. on May 01, 2010, 10:32:43 PM
It's possible that r25770 fixed the microsd problems for some of you.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: bilditup1 on May 03, 2010, 02:39:57 AM
Funman - the change you suggested appears to have worked perfectly, both if the card was already in at startup and on insertion. You can go ahead and patch it in. (This was tried with the latest build, 25791).

-e
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: kugel. on May 03, 2010, 02:55:23 AM
What about the latest build without funman's change? I committed a fix which potentially solves the problem. If it doesn't it would be helpful if you change the "udelay(1000)" so that it fits your cards (e.g. maybe higher it until your cards work).
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: bilditup1 on May 03, 2010, 06:50:20 AM
If you're referring to changes you made in 25770, I tried it without success. Did you change anything since then in 25791?
What is the technical issue here? Why is it preferable to supply udelay with a higher or lower number than just sleep(1)?
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: kugel. on May 03, 2010, 07:21:19 AM
If you're referring to changes you made in 25770, I tried it without success.  Did you change anything since then in 25791?
Yes, I meant that. And no I haven't made further changes.
Quote
What is the technical issue here? Why is it preferable to supply udelay with a higher or lower number than just sleep(1)?

Sleep(1) is 10 times longer. Delays should be as low as possible since they block other tasks (although sleep() only blocks the current one), forcing the cpu to do nothing.
I'm also curious why udelay(1000) doesn't work, since I calculated the 1000 from the old delay which worked for everyone.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: bilditup1 on May 03, 2010, 08:54:27 AM
Interesting. So do you have any other suggestions then? Should I proceed by using random inputs for udelay less than 10000? I'd like to help but really don't quite know what's flying here ;)
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: kugel. on May 03, 2010, 10:41:48 AM
Interesting. So do you have any other suggestions then? Should I proceed by using random inputs for udelay less than 10000? I'd like to help but really don't quite know what's flying here ;)
Yes, you could bisect the needed delay. E.g. start with 5000, then try 2500 or 7500 depending on the success, then 1250 or 3750 (assuming 2500 worked). Basically always half the interval, and add or subtract it from the current number, until the interval is like 50.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 03, 2010, 06:18:28 PM
Write support committed in r25799, should work on all models including µSD.

Unless of course the µSD isn't detected in the first place :)

EDIT: Please run a battery bench (http://www.rockbox.org/wiki/PluginBatteryBenchmark) and post the results (with model, revision, volume, and DSP effects enabled), and pray for it doesn't crash while benching :)
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: xiang on May 03, 2010, 06:48:34 PM
holy shit.. i've waited so long for this!!! thanks!! i'll donate some money to u guys. when are the new builds up?
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 03, 2010, 06:57:38 PM
The current builds are at the usual address:
Clipv2 (http://build.rockbox.org/data/rockbox-sansaclipv2.zip)
Clip+ (http://build.rockbox.org/data/rockbox-sansaclipplus.zip)
Fuzev2 (http://build.rockbox.org/data/rockbox-sansafuzev2.zip)
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Finixlives on May 03, 2010, 08:18:47 PM
(Fuze V2)
Well i got home from school today to be delightfully surprised that memory is no longer read only :D
I've done very very little testing (only the rockboy plugin) and i can save games on the game, but not with the save state. Another thing to note is that when i shut down rockbox and then turn it back on the save is erased. Ill be testing more things out and give more feed back later.

PS: Thanks for the great work you Developers are doing!
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: bilditup1 on May 03, 2010, 08:58:49 PM
So I tried the official build of 25799, as well as a few of my own changing the udelay params in sd-as3525v2.c.

The official build (which I'm assuming has udelay at 1000) hangs forever at boot with an 8gb uSDHC. The same behavior occurs with every build I've made, including sleep(1), udelay (5000), and udelay(3750) which all worked with the earlier revision 25791. These builds also failed to recognize the card on insertion after startup, except for (3750). However, this support was very glitchy - flashing click wheel, slow loading of next folder (like a .5-1.0 sec delay), freezes on trying to access, etc. This only happened once - when I tried to put this build back on (25799/3750), I could not replicate results (other than the hang at startup). So I reverted back to 25791/5000 for now, which seems the most stable.

What is there to be done...?
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Jennifur on May 03, 2010, 09:05:30 PM
Using a FuzeV2 with an 8GB Kingston Class 4 uSD card. It freezes with the build r25799-100503 when the uSD card is inserted. It will not detect the uSD after it is inserted while Rockbox is running. The builds with read only support will not see the uSD card either. The OF can read/write to both the internal memory and uSD. The previous version that I used was r25758-100429 from SVN.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: bilditup1 on May 03, 2010, 09:22:28 PM
Yeah jennifur - the last ready-made build this works with is 25733. If you modify the file I wrote about above (funman/kugel's suggestion) and make your own build, you could work with 25791. (I'm also using an 8gb Kingston Class-4). Read the thread in the middle of the last page for more info.

Devs- one more thing. My builds show up with an "M" after the build number. Should this be cause for concern?

-e
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: saratoga on May 03, 2010, 09:26:33 PM
Devs- one more thing. My builds show up with an "M" after the build number. Should this be cause for concern?


'M' = 'modified'

Just means you edited the source code.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Jennifur on May 03, 2010, 09:38:18 PM
Checking it out now and will try udelay (5000). I will let you know how it turns out.

Yeah jennifur - the last ready-made build this works with is 25733. If you modify the file I wrote about above (funman/kugel's suggestion) and make your own build, you could work with 25791. (I'm also using an 8gb Kingston Class-4). Read the thread in the middle of the last page for more info.

Devs- one more thing. My builds show up with an "M" after the build number. Should this be cause for concern?

-e

Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Vague Rant on May 04, 2010, 01:57:32 AM
So far write support on Clip+ seems to be working perfectly, no crashes yet and I've been messing with settings, writing a scrobbler log, creating a database, etc. My microSD is working perfectly, but has never given me any trouble while others had issues, so that's not really useful information. If it is an access speed issue that would make sense, as the mSD I'm using is a 2GB Kingston (produced in Japan); these are noted for their access speeds and my original use for it was somewhere this was important--so now that it's been commandeered for my Clip+ it makes sense that it's worked well here also.

I'm currently running audio through a speaker, so I'm not sure of the mechanics re: power usage, as the speaker is itself powered. For that reason (and also because it's not fully charged yet) I haven't run a battery bench but I will do so shortly using headphones.

EDIT: Does Rockbox on these devices currently write anything in RAM to disk upon shutdown? I played a single album with logging enabled, switched off the player, and opened the log in QTScrobbler (and also Notepad++ to verify) and only the first five tracks (of a 13-track album) appeared in the .scrobbler.log. It is reproduced below.

Code: [Select]
#AUDIOSCROBBLER/1.1
#TZ/UNKNOWN
#CLIENT/Rockbox sansaclipplus $Revision: 23447 $
Patrick Wolf The Magic Position Overture 1 280 L 1274541921
Patrick Wolf The Magic Position The Magic Position 2 233 L 1274542220
Patrick Wolf The Magic Position Accident & Emergency 3 196 L 1274542457
Patrick Wolf The Magic Position The Bluebell 4 74 L 1274542655
Patrick Wolf The Magic Position Bluebells 5 314 S 1274542730
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: 7o9 on May 04, 2010, 06:39:06 AM
As I reported on IRC, my initial testing of the write support on my Clip+ seems very successful.

I haven't tried extended tests but I saved settings and made bookmarks on both internal and uSD.

Great job guys, even if it's not all perfect, this update makes my Clip+ so much more awesome!
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: bYOndo on May 04, 2010, 07:28:08 AM
Wow! thanks funman and flyndice, as usual, you're great!
on my clipv2, r25799-100503, everything works fine, unless "pitch" function; if modified frequently, it leads to great unstability.
here is the error:
Code: [Select]
Data abort
at 30030688
FSR 0x8
(domain 0, fault 8)
address 0xE59FF024

it can be reproduced by keeping "-2%" or "+2%" button pressed for a certain period.
and with "clipline" theme, the "pitch" screen glitches.

Massimo

edit: after some test, I realized that it's not so reproducible. Some time there's the "abort" message, other time it simply freezes, other time it scrambled the file duration on WPS, but playback keeps working. 
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Jennifur on May 04, 2010, 02:11:35 PM
Tried what bilditup1 said. It works, it can read the uSD card. Though, I can't get the database to build. I will try it with the latest SVN build and see if that will work.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: bilditup1 on May 04, 2010, 02:32:48 PM
jennifur - write support was only enabled by 25779, the same release that hangs on startup.
Looks like flyndice modified the file (http://svn.rockbox.org/viewvc.cgi?view=rev;revision=25811) though in the very latest build, 25811, so we should probably try that. I'm having trouble checking out SVN right now, however.

-e
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Jennifur on May 04, 2010, 02:46:58 PM
I had no problem checking out to 25811. I'm going to test it now.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Xanikseo on May 04, 2010, 03:12:46 PM
Can confirm writing to my 8gb kingston class 4 µSD works! Dayam :), I can finally use the database properly! Great work!

Still got this problem with scrolling (you suddenly jump straight to the bottom/top if you are scrolling any faster than slowly), probably caused by r25736 link to post (http://forums.rockbox.org/index.php?topic=14064.msg165787#msg165787). kugel :) please fix this!

Button light now flashes like crazy while switching tracks :O! Still takes a while to switch tracks as well, as soon as you press skip twice in a row, you have to wait like 5 seconds for anything to happen. I suppose these delays still need to optimised, but we know that already right :P? It's great that we've got write support now though, I reckon a lot of crashing was caused by some vital files being read-only.

EDIT: OK, some more helpful info about switching tracks: you can only switch tracks after the first five seconds of the current song have played. As soon as you have passed around 5~6 seconds of the current track, switching tracks happens quickly. If you skip a track before the first 5~6 seconds of the current track have played, the next track will only start playing as soon as you reach ~5 seconds.

Another (totally unrelated) thing I have discovered. After you exit the pitch detector plugin, the sounds being picked up by the microphone are still recorded, and you can still hear them quietly in your earphones.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Timar on May 04, 2010, 03:25:18 PM
Thanks to all the developers for the rapid improvements! Write support works flawlessy so far. One exeption: I can't get the recorder to work.

I've tried to run a battery bench but I've given up. I hardly get more than one or two hours of playback before the Clip crashes. Maybe I'll try again without crossfeed/EQ...
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: marc2003 on May 04, 2010, 03:55:52 PM
just to echo the above post, thanks for all the recent updates.

i'm currently 10 hours into a battery bench on my clip v2/r25799/database enabled/ogg q5. i'll post full results when complete. still 40% battery left so i'm aiming for around 16 hours i think.

playback is running fine although cpu frequency has to be boosted. i can barely last 20 minutes without it.

edit: i haven't tested this build unboosted but all recent builds have been problematic for me and i have no reason to think the new addition of write support is going to fix that?? absolutely no problems boosted though.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: izzy84075 on May 04, 2010, 04:08:14 PM
Just flashed my Fuzev2 with the patched .31 OF from a few pages ago and started playing around with it.

Not sure whether this is a known thing or if it's on purpose, but with r25811-100504, the scroll wheel light flickers while building the database. Default settings on everything except the "Wheel Light Timeout" is set to "Off".

It's actually kind of nice if it's on purpose, but if it's not, what else is it doing?
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: bilditup1 on May 04, 2010, 04:12:08 PM
I just tried 25811, and still have SD problems: hangs at boot, and doesn't load SD if inserted after booth, this is for several different values for udelay()/sleep(). Reverted to 25791 for now.

-e
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Jennifur on May 04, 2010, 04:19:04 PM
I just tried 25811, and still have SD problems: hangs at boot, and doesn't load SD if inserted after booth, this is for several different values for udelay()/sleep(). Reverted to 25791 for now.

-e


I'm also still experiencing this. Anything else that could cause this?
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: FlynDice on May 04, 2010, 05:35:43 PM
@Those having uSD problems:

Would you please check that your file system is not damaged by running either chkdisk or fsck depending on your OS.
If you still have the same symptoms please post the following info;


I was actually having the problem where boot hangs if the uSD card is present but running fsck cleared that up.  And yes the card worked just fine in the OF.

Thanks!
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: MasterFen on May 04, 2010, 05:41:45 PM
Do you think we could reinstate the Clip+ port as an unstable port, rather than an unusable one?
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Jennifur on May 04, 2010, 05:48:59 PM
Did a chkdisk and it came out clean. Still won't work with rockbox. Hangs on boot with it in, and won't see it after inserting it. The odd thing is, it detects both the internal memory and the external uSD in the disk info under the debug menu after inserting it. I'm using an 8GB Class 4 card from Kingston.

@Those having uSD problems:

Would you please check that your file system is not damaged by running either chkdisk or fsck depending on your OS.
If you still have the same symptoms please post the following info;
  • Card Manufacturer
  • Card Capacity
  • Card Speed Class(2,4,6 usually has a small circle around it on your card)


I was actually having the problem where boot hangs if the uSD card is present but running fsck cleared that up.  And yes the card worked just fine in the OF.

Thanks!
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 04, 2010, 05:53:26 PM
on my clipv2, r25799-100503, everything works fine, unless "pitch" function; if modified frequently, it leads to great unstability.
Thanks for the info, I will try to reproduce.

Button light now flashes like crazy while switching tracks

the scroll wheel light flickers while building the database
Yes it does that, just ignore it until someone fixes it.

i'm currently 10 hours into a battery bench on my clip v2/r25799/database enabled/ogg q5. i'll post full results when complete. still 40% battery left so i'm aiming for around 16 hours i think.

playback is running fine although cpu frequency has to be boosted. i can barely last 20 minutes without it.

edit: i haven't tested this build unboosted but all recent builds have been problematic for me and i have no reason to think the new addition of write support is going to fix that?? absolutely no problems boosted though.

It's still not fixed although it is a bit better now (i got 10 hours on Clip+ before it crashed, 2 or 3 hours on Clipv2).

Ideally the bench should operate in normal conditions but a bench with the CPU boosted will be nice to have anyway.

The Fuzev2 worked all the 18h20, perhaps the difference with PCLK (40MHz on Fuzev2, 24MHz on Clips) plays here?

Do you think we could reinstate the Clip+ port as an unstable port, rather than an unusable one?

Yeah I think we could, dunno what the other devs think

If you still have the same symptoms please post the following info;
  • Card Manufacturer
  • Card Capacity
  • Card Speed Class(2,4,6 usually has a small circle around it on your card)

Please post the infos of your card
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Jennifur on May 04, 2010, 05:59:00 PM
I did, it was my last line in my post. It is a 8GB card, manufactured by Kingston, and it is a class 4 card.
If you still have the same symptoms please post the following info;
  • Card Manufacturer
  • Card Capacity
  • Card Speed Class(2,4,6 usually has a small circle around it on your card)

Please post the infos of your card
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 04, 2010, 06:09:02 PM
Oops didn't see it sorry :-[

battery bench for fuzev2 attached (it starts at 94% but the OF said charge was complete)
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: pbow9 on May 04, 2010, 06:09:46 PM
@Those having uSD problems:

Would you please check that your file system is not damaged by running either chkdisk or fsck depending on your OS.
If you still have the same symptoms please post the following info;
  • Card Manufacturer
  • Card Capacity
  • Card Speed Class(2,4,6 usually has a small circle around it on your card)


I was actually having the problem where boot hangs if the uSD card is present but running fsck cleared that up.  And yes the card worked just fine in the OF.

Thanks!

I have some different uSD cards to try. The 2gb non-SDHC card I have does not hang up.

Two cards that do:

Kingston  4gb Class 4 SDHC, labeled as C04G (I think it's actually Toshiba flash from what I'm seeing in search results).
Toshiba 16gb Class 2 SDHC, labeled as C16G

I've run chkdsk on the 16gb, but it made no difference.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: marc2003 on May 04, 2010, 06:50:46 PM
i'm currently 10 hours into a battery bench on my clip v2/r25799/database enabled/ogg q5. i'll post full results when complete. still 40% battery left so i'm aiming for around 16 hours i think.

playback is running fine although cpu frequency has to be boosted. i can barely last 20 minutes without it.

edit: i haven't tested this build unboosted but all recent builds have been problematic for me and i have no reason to think the new addition of write support is going to fix that?? absolutely no problems boosted though.

It's still not fixed although it is a bit better now (i got 10 hours on Clip+ before it crashed, 2 or 3 hours on Clipv2).

Ideally the bench should operate in normal conditions but a bench with the CPU boosted will be nice to have anyway.

i'm more than happy to try another benchmark (unboosted) when this has finished. should i try again on r25799 or try the latest?
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: bilditup1 on May 04, 2010, 07:05:56 PM
Chkdsk found no problems and did not help issues with the new build.

My card is an 8GB Class-4 Kingston. It is marked "CO8G JAPAN" and "SDC4/8GB 07".

A non-HC 2GB card, also Kingston Class-4, was recognized without problems. It is marked "SD-CO2G JAPAN" and "SDC/2GB 29".

EDIT:

I just tried again. While the Fuze hung-up when the card was present at startup, it was successfully recognized when inserted afterward. However, clicking through and opening folders are now a mite sluggish in comparison with 25791. Also - this behavior is not consistent: I've tried turning on and off the Fuze several times, and then inserting the card.

EDIT 2:
This only happened twice so far, and the second time, it was after popping the card in and out several times on the same boot without success. Thrice, I got a "*PANIC* microSD init failed: -3" and then a reboot. One time, the thing decided to reboot on card insertion without any message at all. Oh, and all of this is with udelay set to 5000, which is probably not the optimal number, but there is no reason to believe that 1000 will work, and I don't want to keep doing trial and error before the startup issue is fixed.

When I tried to build a db, I likewise got the flickery scroll light at the beginning of the scan, but it stopped at some point, and is only present when the screen backlight is on (e.g. it returns when I push a button during the db build).

EDIT 3:
This PANIC seems to relate to this do-while in sd-as3525v2.c:
Code: [Select]
    do {
        /* this timeout is the only valid error for this loop*/
        if(TIME_AFTER(current_tick, init_timeout))
            return -2;

        /* app_cmd */
        send_cmd(drive, SD_APP_CMD, 0, MCI_RESP, &response);

         /* ACMD41 For v2 cards set HCS bit[30] & send host voltage range to all */
        if(!send_cmd(drive, SD_APP_OP_COND, (0x00FF8000 | (sd_v2 ? 1<<30 : 0)),
                        MCI_RESP, &card_info[drive].ocr))
            return -3;
    } while(!(card_info[drive].ocr & (1<<31)) );

Of course, I couldn't tell you what that means exactly. Some bit is being set for SDHC (v2). I was getting -2 errors back when udelay was 1000 with the older build 25791 (timeouts). So is the problem here, or in send_cmd()? I really dunno :) Just curious, askin' questions...
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Jennifur on May 04, 2010, 07:22:57 PM
EDIT:
After reading bilditup1's post. I tried for myself. It will still hang with the card inserted when you turn the player on. Inserting the card right after start does not work either. What does work is, turning on the player without the uSD card, play a track from the internal memory, and then insert the uSD card. It will detect it and play from it just fine.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: bilditup1 on May 04, 2010, 08:04:19 PM
Yep, Jennifur is right: it seems to work if you play a file, but not before then. Thanks for figuring it out ;)

-e
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: marc2003 on May 04, 2010, 08:27:05 PM
right, my battery test has just finshed. 14h21m in the end.

sansa clip8gb v2
r25799
ogg q5, 11 track album, avg 143kbps
cpu boosted (i'll try again unboosted when it's charged again)
volume -14 (i had to put player in another room because that's quite loud indoors :p)

edited with attachments instead of external links.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 04, 2010, 09:53:40 PM
thanks,

in fact it would be better if you run the same settings (including boosting) but with LCD always on, so we can make the difference and measure current use of the LCD screen.

revision shouldn't matter has there has been no changes likely to affect current use, so use whatever you want.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: marc2003 on May 04, 2010, 10:09:40 PM
in fact it would be better if you run the same settings (including boosting) but with LCD always on, so we can make the difference and measure current use of the LCD screen.

ok, no problem.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 05, 2010, 12:27:16 AM
FM should work on Fuzev2 now, but there is some hint that it may not work on some models.

If you have a fuzev2 with FM working in OF but not detected by rockbox please tell
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: saratoga on May 05, 2010, 12:49:01 AM
I changed rockbox to use the settings ranma took from the c200v2 using JTAG.  According to him, this saves 5 mA, so battery life will hopefully improve.  I've tested with RMAA on a few players and so no difference in output quality.

If anyone else wants to compare with RMAA or a battery bench, feel free.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: A1Fiddler on May 05, 2010, 02:02:16 AM
FM should work on Fuzev2 now, but there is some hint that it may not work on some models.

If you have a fuzev2 with FM working in OF but not detected by rockbox please tell

My FuzeV2 has working FM in OF but Rockbox build 25814 does not recognize it (no menu item).
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: saratoga on May 05, 2010, 02:07:42 AM
FM should work on Fuzev2 now, but there is some hint that it may not work on some models.

If you have a fuzev2 with FM working in OF but not detected by rockbox please tell

My FuzeV2 has working FM in OF but Rockbox build 25814 does not recognize it (no menu item).

Either you've got the build number wrong, or you didn't update to a build with FM.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: A1Fiddler on May 05, 2010, 02:50:41 AM
FM should work on Fuzev2 now, but there is some hint that it may not work on some models.

If you have a fuzev2 with FM working in OF but not detected by rockbox please tell

My FuzeV2 has working FM in OF but Rockbox build 25814 does not recognize it (no menu item).

Either you've got the build number wrong, or you didn't update to a build with FM.

Maybe I'm confused then. The build number is right. I used the latest build from this page: http://www.rockbox.org/dl.cgi?bin=sansafuzev2
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: bilditup1 on May 05, 2010, 02:57:40 AM
SD finally works fine, with no modifications to udelay, in 25821. FM Radio also works. Thanks alot guys! Will look into running battery bench for you guys.

-e
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: saratoga on May 05, 2010, 03:08:37 AM
FM should work on Fuzev2 now, but there is some hint that it may not work on some models.

If you have a fuzev2 with FM working in OF but not detected by rockbox please tell

My FuzeV2 has working FM in OF but Rockbox build 25814 does not recognize it (no menu item).

Either you've got the build number wrong, or you didn't update to a build with FM.

Maybe I'm confused then. The build number is right. I used the latest build from this page: http://www.rockbox.org/dl.cgi?bin=sansafuzev2

http://build.rockbox.org/data/rockbox-sansafuzev2.zip

In the future, please take care to make sure you've updated.  If you hadn't mentioned the version, no one would have realized you were running an older build and it would have looked like a bug.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: saratoga on May 05, 2010, 03:23:19 AM
Anyone feel like trying out this bootloader for the fuzev2:

http://duke.edu/~mgg6/rockbox/bootloader-fuzev2.sansa

If it works I'll get it uploaded to the download server. 
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: florin on May 05, 2010, 04:45:54 AM
Any ideas as why volume is very low? Maximum volume in Rockbox corresponds to ~60% in OF (Rest of the World). 8 GB Clip+. Cleared settings, latest build (r25824). Previously I had 25493 and I didn't have this issue. I could try a more recent build, but I don't know where to get it from.

Regarding SD, I have a 16 GB class 2 Toshiba card and everything seems fine.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: marc2003 on May 05, 2010, 09:16:15 AM
right, my battery test has just finshed. 14h21m in the end.

sansa clip8gb v2
r25799
ogg q5, 11 track album, avg 143kbps
cpu boosted
volume -14

test repeated with back light on: 9h39m

any other tests you want doing, give us a shout. i'm not much use for anything else. :/
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Phil2991 on May 05, 2010, 09:22:52 AM
Anyone feel like trying out this bootloader for the fuzev2:

http://duke.edu/~mgg6/rockbox/bootloader-fuzev2.sansa

If it works I'll get it uploaded to the download server. 

Saratoga, I am trying to test your bootloader but I am getting the following error when I run mkamsboot to patch OF 2.3.31:


C:\rockbox\Patched_firmware>mkamsboot.exe fuzpa.bin bootloader-fuzev2.sansa rockbox_fuzpa.bin
mkamsboot Version 1.2


This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[ERR]  Original firmware unknown, please try an other version. Tested Fuze versi
ons are : 2.01.17, 2.02.26
[ERR]  Could not load fuzpa.bin


Is there an updated version of mkamsboot that I should be using to patch the OF?
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: mc2739 on May 05, 2010, 10:00:01 AM
I would like to dust off my M240 and install rockbox . Should I use the Clip V1 files to install since I don't see separate files for the M200V4 series?

The clipv1 files will not work on an m200v4. The current build for the m200v4 is located here: http://build.rockbox.org/data/rockbox-sansam200v4.zip

... I am getting the following error when I run mkamsboot to patch OF 2.3.31:

The 2.03.31 version of the Fuzev2 OF is supported in svn mkamsboot, but not in the released version.  Your options are to build the current version of mkasmboot or use an older OF (2.03.17 or 2.03.26) that is supported by the release version of mkamsboot.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: ranma on May 05, 2010, 10:01:45 AM
Quote
03:12 < funman> ranma: is there any markings on the Clip+ battery ?

Code: [Select]
|  BAK 323036P
   9F30 1.07Wh
+ 3.7V 290mAh

(http://uguu.de/~ranma/clip%2b_battery.jpg)
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Timar on May 05, 2010, 10:20:24 AM
Got a crash while setting up the EQ (Clip+, r25799):
Code: [Select]
D.a. at 000075C8
FSR 0x8 (d. 0, f. 8)
addr.  0x70E5A0FC
Btw. there's a small visual glitch in the graphic eq menu which makes the upper eq bar slip up into the yellow row and leaves the according space at the bottom blank.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: robertwalker62 on May 05, 2010, 10:56:27 AM
Tried the latest build with both my Clip+ and Fuzev2 today - certainly stable enough, but the maximum volume level is too quiet to be of any practical use.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: startsync on May 05, 2010, 11:48:14 AM
A big thank you to all those who have gotten the port this far!
Anyone feel like trying out this bootloader for the fuzev2:

http://duke.edu/~mgg6/rockbox/bootloader-fuzev2.sansa

If it works I'll get it uploaded to the download server. 

It works perfectly.

On the other hand, the Fuze will freeze during the FM Radio Autoscan if I give any sort of input after the LCD turns off. It will also freeze if I mute it and then try to change the station.
(r25828)
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: marc2003 on May 05, 2010, 12:40:43 PM
just tried a couple of todays builds unboosted on my clip v2. still not much joy....

r25815  - 40 minutes
r25831 - 15 minutes
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Phil2991 on May 05, 2010, 12:56:58 PM
A big thank you to all those who have gotten the port this far!
Anyone feel like trying out this bootloader for the fuzev2:

http://duke.edu/~mgg6/rockbox/bootloader-fuzev2.sansa

If it works I'll get it uploaded to the download server. 

It works perfectly.

On the other hand, the Fuze will freeze during the FM Radio Autoscan if I give any sort of input after the LCD turns off. It will also freeze if I mute it and then try to change the station.
(r25828)


I ran into the issue with the FM Radio Autoscan also...
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: ultr on May 05, 2010, 02:56:20 PM
Just installed rockbox on fuzev2 using this bootloader http://duke.edu/~mgg6/rockbox/bootloader-fuzev2.sansa

Generally works OK.
Plays music :) Menu works.
Radio not tested yet.

Unfortunately after ~10 minutes of playing music, while searching the playlist, I got black screen with:
Data abort
at 30056548
FSR 0x8
(domain 0, fault 8)
address 0x9543543B

Plugging USB when the player is turned off boots OF.

Also the screen is a bit too wide and battery icon hides under the top edge of the screen. Probably OF does not use all available pixels.
Title: Adventure in Clip+ world
Post by: notlistening on May 05, 2010, 04:04:07 PM
Hi,

A few observations about the clip+ in day to day use. I still get the data aborts every so often quite randomly.

I am also getting a weird problem when trying to change track after about half an album of skipping around and listening to music the advance button becomes unresponsive to change track. It will fast forward but not skip. The skip back button will rewind and skip to the beginning of the track and when push it starts to skip all over my music collection. This is with the default setting on. It should not move from the currently selected album as far as i understand.

Added: There now seems to be a high pitched noise than is comming from the screen when the system is running Rockbox. It is quite quiet but noticeable. Anyone else hearing this?
 
NL
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: izzy84075 on May 05, 2010, 04:14:21 PM
Updated to r25831 earlier today.

Radio option shows up in the main menu, but it froze on the autoscan thing. Scroll wheel light still flickers like crazy. And the theme does go under the case a bit, but I don't mind that.

Other than those things, it's been working perfectly for me. 8GB Fuze v2 with a 16GB Sandisk microSD card. Ran for 8 hours or so last night with no problems, battery was at 50% when I got home. Mix of FLAC, OGG, MP3, AAC and several other file types.

Great job, guys! Let me know if there's anything I can do to help out.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: bilditup1 on May 05, 2010, 05:52:02 PM
I am over 14hrs into a battery test, but still have ~40% left. This behavior looks odd; this is way too good and I should probably stop. Is it because the album is only 40 min of mp3s (big, alt-preset-extreme ones at that)?

-e
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: saratoga on May 05, 2010, 05:59:20 PM
I am over 14hrs into a battery test, but still have ~40% left. This behavior looks odd; this is way too good and I should probably stop. Is it because the album is only 40 min of mp3s (big, alt-preset-extreme ones at that)?

Why does it look too good?  IIRC the last tests we had of the clip were something like 19 hours, and I bet we can do better then that on the Fuze.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: bilditup1 on May 05, 2010, 06:04:14 PM
Well didn't several ppl here say their Fuzes conked out at around 16hrs? Probably I'm remembering it wrong...
Now up to 15hrs, 5min. Volume is at -20db; EQ is flat; album is on the microSD card. Does the headphone used affect battery life, if volume is kept the same?
(The album, for the heck of it, is Saxophone Colossus.)
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Llorean on May 05, 2010, 06:31:09 PM
Turning the backlight on to check percentages basically isn't a good idea. The backlight can drain an awful lot of power relative to other things.

If you want to do a battery bench, you shouldn't touch the player once it's started.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: bilditup1 on May 05, 2010, 06:38:47 PM
Oh boy. Shoulda thought of that one. Should I stop then? Apologies for the hijacking of this here thread.
-e
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 06, 2010, 12:36:13 AM
Turning the backlight on for 10 seconds every hour will not be a problem.

When I run bench without headphones it's how I check if the player crashed or not.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Llorean on May 06, 2010, 12:41:16 AM
That's nearly three minutes of backlight time for an 18 hour player.

I have several players where the battery level will go down multiple percentages in three minutes of backlight time.

If you want to do an accurate battery bench, you shouldn't turn the backlight on at any point during it. If you want an approximate bench, sure, it's fine. You'll know that it's a bit short due to the backlight use.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Jennifur on May 06, 2010, 12:47:51 AM
Also the screen is a bit too wide and battery icon hides under the top edge of the screen. Probably OF does not use all available pixels.
I'm experiencing this too, but it might just be the screen isn't aligned properly. The top left seems a bit higher than the top right. As soon as I get it open I'll find out for sure. On that note. Can anyone give me a link to show me how to get this thing open?

Also, can I just keep it on hold and play all my music instead of an album for the battery bench? I usually keep it with me and listen to music most of the day and would really dislike not having it with me.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 06, 2010, 12:50:31 AM
On fuzev2 3 minutes of backlight will get the battery level down by 0.27% so it's small enough to ignore it.

http://www.anythingbutipod.com/archives/2008/03/sandisk-sansa-fuze-disassembly.php : steps to open fuzev1, but keep in mind that it's very easy to break it or to not be able to remount it.

EDIT: I have 2 benches of fuzev2 already: 18h20 playing mp3, and 8h20 playing mp3 with LCD on.

There is a different setting for current use when recording, I'm not sure if it's important for flash targets like the Sansas, but it would be nice to have a bench when recording just to be sure (record the microphone since FM seems to be buggy)
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Llorean on May 06, 2010, 01:21:47 AM
On fuzev2 3 minutes of backlight will get the battery level down by 0.27% so it's small enough to ignore it.
That would mean the player can power the backlight for 18 hours if doing nothing else. Is this really true?
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 06, 2010, 01:38:32 AM
On fuzev2 3 minutes of backlight will get the battery level down by 0.27% so it's small enough to ignore it.
That would mean the player can power the backlight for 18 hours if doing nothing else. Is this really true?

I have 2 benches of fuzev2 already: 18h20 playing mp3, and 8h20 playing mp3 with LCD on.

18h20 - 8h20 = using backlight reduce capacity by 10 hours

100 * 3 / (10*60) = 0.5%

using the backlight for 3 minutes will use an additional 0.5% of the battery (difference with the previous 0.27% probably comes from rounding)
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: bilditup1 on May 06, 2010, 03:25:15 AM
Dual boot works like a charm now with the the latest commit. Per saratoga, mkamsboot (the patcher) in the rbutil folder must be built from the source, as well as the bootloader itself (../tools/configure, 63, b for Fuze). The precompiled version of mkamsboot at download.rockbox.org only works with firmwares older than 02.03.31 (the current one).

My battery gave out at 15:48 without backlight (except for a few checks); have yet to make the graph, sorry.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 06, 2010, 03:49:11 AM
Please also post the complete battery_bench.txt and tell which settings you used (volume, DSP, eq) and what files you played (some codecs are more intensive than others)
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Timar on May 06, 2010, 05:59:31 AM
The build 25836 seems to have massively improved stability for my Clip+. I get none of those weird crashes/hangups anymore I got frequently with 25799. Did you make any changes regarding stability issues (4-bit bus!?)?

Battery bench is running :)

UPDATE: I have the same problem described in the adjacent post  - battery only charges 2/3 max with rockbox
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: notlistening on May 06, 2010, 07:35:34 AM
Ciip+ again,

Charging the battery stops at 63% and in rockbox info shows 63% even though the charger is still plugged in, shouls say charging. This problem has existed for about a month. OF reports 67% when checked and the OF will continue to charge beyond this limit.

NL
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: bYOndo on May 06, 2010, 08:27:11 AM
clipv2, r25836-100505
update on "pitch" function unstability: when the player crashes (but it doesn't everytime...) it gives me:

Code: [Select]
Undefined instruction at 30048CC4

when it does not crash, I can go back to WPS and file duration isn't scrambled anymore, it's always correct.

Massimo
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 06, 2010, 09:17:10 AM
Code: [Select]
Undefined instruction at 30048CC4

Points to the instruction right after a "bl set_cpu_frequency"



I have opened FS#11246 (http://www.rockbox.org/tracker/task/11246) which should get a bit more battery life on AMSv1 and hopefully on v2 too (still testing).

Can you give it a try and also comment on where to run this code ?

sdram code is only in the bootloader but I have put it in system_init() to avoid the need to update bootloaders.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: FlynDice on May 06, 2010, 01:41:31 PM
re: abi forums and "temp brick" reports.

Please don't be alarmed by ^^^ there are no bricks being reported!  Just a temporary unresponsiveness for 2-3 mins.

From practical experience I think this is related to the v1.0 bootloader.  I was using one I compile myself for awhile and then last week tried the v1.0 to see if it made any difference with some of the things I was working on.  It didn't but I started to get these "temp bricks". Holding the pwr button for 10 secs did not reset but 20 secs did reset.  I'm now running a bootloader  produced from r25821 and have not had any more of these "temp Bricks" so I've got the feeling this is bootloader v1.0 related.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: bilditup1 on May 06, 2010, 01:48:56 PM
I got lazy about this graph thing. Anybody have a simple tool to do it for me?
My battery_bench.txt is attached.

My Fuze v2, build 25836, quit at 15:48:06, after starting at 93% (but 100% according to the OF). This is with 5-track alt-present-extreme LAME-encoded mp3 album that was 40 minutes long. Flat EQ, no replay gain, and volume at -20db.

In other news - I tried playing some NSFs and SPCs today on a whim. The NSFs played fine, but the scroll light was at the disco. SPCs played at an absurdly low volume, and also had scroll light problems. I don't know if these are issues specific to this port or Rockbox in general. While plugged in, it looks like the light now comes on and off at random during mp3 playback, too.

I've experienced a few crashes while scrolling through menus, with and without music playing, but otherwise, everything looks stable. Will investigate charges of volume being too low next - yay dual boot!
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 06, 2010, 03:12:25 PM
re: abi forums and "temp brick" reports.

From practical experience I think this is related to the v1.0 bootloader.

Very likely, there were some fixes added after bootloader release: I think of the cache functions particularly, and also some race condition with the PMU ascodec register.

I got lazy about this graph thing. Anybody have a simple tool to do it for me?
Have a look at gnuplot

My battery_bench.txt is attached.

My Fuze v2, build 25836, quit at 15:48:06, after starting at 93% (but 100% according to the OF). This is with 5-track alt-present-extreme LAME-encoded mp3 album that was 40 minutes long. Flat EQ, no replay gain, and volume at -20db.

Thanks, did you force CPU boosting?

I had 18:20 on my fuzev2 (starting with 100% in OF and 94% in rockbox)

While plugged in, it looks like the light now comes on and off at random during mp3 playback, too.

Yeah this is normal, read the last pages of this thread.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: yimmu on May 06, 2010, 05:45:39 PM
Battery benchmarking for Fuze v2, build r25814.
Volume was at -14db, playing a 17 track mp3 album at 128kb/s which was being played off a µSD card, with the equalizer was set to the preset 'rock'.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: bilditup1 on May 06, 2010, 09:16:50 PM
I forced nothing; I'm not quite sure how to boost speeds at all. Maybe the backlight was on when I wasn't looking (in my pocket). Maybe I checked the player one too many times. Maybe it's because the tracks were on the microSD? Should I try again? Will look up gnuplot.

I'd like to echo problems with recording (panics right and left when trying to change options) and charging (stops at ~67%).

-e
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 07, 2010, 03:25:50 AM
Some bench results:

FS#11246 definitely helps a little bit with Clipv1.

It seems to help as well with Fuzev2 although the bench didn't complete.

I have recording problems on all models too: Fuzev2/Clipv2/Clip+.

I don't know if the shorter runtime comes from µSD, only testing from internal storage can tell :D

Btw when I run my tests I don't have headphones plugged, so perhaps I'm cheating?

[EDIT] : Adding Fuzev1 benches:
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 07, 2010, 04:10:14 AM
right, my battery test has just finshed. 14h21m in the end.

sansa clip8gb v2
r25799
ogg q5, 11 track album, avg 143kbps
cpu boosted
volume -14

test repeated with back light on: 9h39m

any other tests you want doing, give us a shout. i'm not much use for anything else. :/

Can you give a try to FS#11246 (http://www.rockbox.org/tracker/task/11246) with CPU boosted?

With the 2nd patch you will need to update the bootloader from SVN, come on IRC if you don't feel confident with doing it
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: marc2003 on May 07, 2010, 04:37:30 AM
i'll give it a bash. i'm just reading through the instructions on the wiki for patching.

edit: sorted. i'm just waiting for the battery to charge and then i'll begin benching.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: bilditup1 on May 07, 2010, 05:35:48 AM
Ah, I was going to ask if having headphones in affects battery life as well. I had mine in the whole time.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: cris on May 07, 2010, 10:36:19 AM
To all the developers...huge thanks, progress in the last few days has been great.  Tried several builds in the last few days and for playing music, looking at photos etc things are very stable (few crashes with graphical eq).

Funman - I did not respond to your comments responding to my comment about the sound with no EQ on Rockbox compared to stock OS - have been busy.  I did a back to back listening test with the earlier build and the sound is different (to my ears) than the stock OS.  I won't go as far as saying I am an audiophile but I think I have a good pair of ears...without wanting to use adjectives, the sound on the stock OS was a bit 'warmer' and perhaps a bit more forward.  This does not mean it is better, just different. Of course I could be imagining it.  I haven't compared later builds because I don't care to boot into the original OS since I have got used to the Rockbox sound and the features are SOOOOO much better than the original OS.

Cris
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: saratoga on May 07, 2010, 11:20:49 AM
I did a back to back listening test with the earlier build and the sound is different (to my ears) than the stock OS.  I won't go as far as saying I am an audiophile but I think I have a good pair of ears...without wanting to use adjectives, the sound on the stock OS was a bit 'warmer' and perhaps a bit more forward.  This does not mean it is better, just different. Of course I could be imagining it.  I haven't compared later builds because I don't care to boot into the original OS since I have got used to the Rockbox sound and the features are SOOOOO much better than the original OS.

I did RMAA tests the other day and the two are identical, so you are probably imagining it.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Timar on May 07, 2010, 02:13:13 PM
Volume on the Clip+ is still considerably lower than on OF, despite this commit: http://svn.rockbox.org/viewvc.cgi?view=rev&revision=25831 (doesn't seem to have had any effect for me)
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 07, 2010, 04:59:22 PM
should be fixed for good with r25890
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: marc2003 on May 08, 2010, 01:01:18 AM
With the 2nd patch you will need to update the bootloader from SVN, come on IRC if you don't feel confident with doing it

oh FFS. i can't even read. i totally missed the part in bold. i only applied the first patch.  :/

having said that, i still got 15h22m which is an extra hour. i'll try the 2nd patch later.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Timar on May 08, 2010, 03:38:00 AM
should be fixed for good with r25890
Sorry, but I can't hear any difference with r25894. Volume is still considerably lower than on the OF (without the EU volume cap and with all replaygain, EQ settings etc. turned off on both)

UPDATE: while unboosted playback on r258614 - r25869 was perfectly stable for me, I get frequent crashes again with r25894 (including "temporary bricks"!)... there must have been some changes made between -69 and -94  which result in the same situation as in r25799.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 08, 2010, 10:08:26 AM
With the 2nd patch you will need to update the bootloader from SVN, come on IRC if you don't feel confident with doing it

oh FFS. i can't even read. i totally missed the part in bold. i only applied the first patch.  :/

having said that, i still got 15h22m which is an extra hour. i'll try the 2nd patch later.

Thanks, the 2 patches have the same functionality so it didn't really matter. I just wanted to be sure it gave a bit more runtime, I got 15hours+ too on my Clipv2.

I have committed this patch, so we'll release new bootloaders for Fuzev2/Clip+/Clipv2 sometime soon.

should be fixed for good with r25890
Sorry, but I can't hear any difference with r25894. Volume is still considerably lower than on the OF (without the EU volume cap and with all replaygain, EQ settings etc. turned off on both)

Hm then I don't know, my Clip+ had high volume before r25890.

I tried modifying each of the 8 bits of AUDIOSET2 register, and only having the bit 6 set had an effect.

Since this issue appeared with r25821, then the problem must be in AUDIOSET2 register. Try modifying this register until you can tell what affects volume.

firmware/driver/audio/as3514.c => look for AUDIOSET2, the code executed on as3525v2 is the code inside "#ifdef HAVE_AS3543".
There is only 8 bits, so only 255 possibilities. And since the value currently written is 0, only 254 possibilities left.

UPDATE: while unboosted playback on r258614 - r25869 was perfectly stable for me, I get frequent crashes again with r25894 (including "temporary bricks"!)... there must have been some changes made between -69 and -94  which result in the same situation as in r25799.

I can't see anything between those 2 revisions which would affect crashes.

Remember these crashes just seem to happen randomly so they could be affected by the speed of wind, the color of my horse (he's white btw), or what you ate the day before ...

So far people reported that messing with DSP parameters (pitch, equ) would make crashes much more likely, this will help when I try to fix them but I don't know when since i'm not sure what's going on down there in this chip..


EDIT:
YES WE KNOW THE VOLUME IS LOW
DON'T REPORT IT AGAIN AND AGAIN, READ THE PREVIOUS REPLIES BEFORE POSTING PLEASE
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: cris on May 09, 2010, 06:45:27 AM
Funman

Thanks for the note on the sound tests.

25904 Build - Had a crash today (hopefully didn't damage my speakers :-( ).  I was trying to change the stereo width on the fly and it just crashed...lesson learnt.  To all of you connecting your Rockbox fuze to your hifi, if you care about your speakers, turn down the volume before trying to change settings whilst it is playing. I've reverted to the previous build for now.

Cris

Edit:  found this old thread so it does not appear that this is an unknown issue, some other users have had it -  http://www.anythingbutipod.com/forum/showthread.php?t=17166

It reports exactly the same problem I had.  I also just extract the new build over the old one without deleting the old one first which one of the users seems to think might have caused the problem...not sure.


Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: 7o9 on May 09, 2010, 07:46:15 AM
funman, with version r25906-100509 i see a lot more crashes on my Clip+ than before (the older more stable one i used was r25831-100505).

These are two recent ones:

Code: [Select]
Undefined instruction at 3004996C
Code: [Select]
Data abort
at 30049DEC
FSR 0x8
(domain 0, fault 8)
address 0xE3530044

The first one is just after starting rockbox and entering the main menu. The second one is while playing mp3's.

My bootloader is r25906-100509 as well.

Edit: another one while playing the same mp3's:

Code: [Select]
Undefined instruction at 3002496C
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: PockyMaster on May 09, 2010, 08:40:46 AM
Played off a class 4 4gb generic microSD card with 14 mp3s encoded in VBR in repeat.

Sorry for the crude graph.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Xanikseo on May 09, 2010, 12:06:35 PM
There has been an improvement in sound quality in the recent builds on the Fuze v2! It sounds warmer, tighter and somehow more natural, in fact very much like the OF.

EDIT: Does r25890 have anything to do with it? If so, then yes, funman, there is a change in quality, but *definitely* for the better!
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: bilditup1 on May 09, 2010, 05:50:54 PM
I've come across something weird - after fiddling with the Hotkey settings (new feature from 25906), when going back to the WPS, the Album Art wouldn't show. Had to go to the next track for it to show. Dunno how reproducible it is yet though. (Build: 25916)

-e
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 09, 2010, 11:54:19 PM
I disabled dynamic CPU frequency in r25924

Power use will increase a bit but at least it will confirm that there are still weird crashes even with this functionality off

(well I hope it will still crash for everyone because for me it does)
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: cris on May 10, 2010, 04:38:31 AM
Sorry if this is a stupid question.  How can I update to a more recent bootloader.  I have a pre-patched OF provided by Funman a few weeks back.  Where can I find the updated bootloader (the website still shows 22 March - I appreciate these are the stable versions)?

Thanks

Cris
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: marc2003 on May 10, 2010, 05:11:50 AM
(well I hope it will still crash for everyone because for me it does)

well my clip v2 has never crashed when boosted (touch wood).

i ran into this stability problem over a month ago now and i remember on ABI you telling me to boost the cpu frequency. since then, it's been rock solid. admittedly i only use it for an hour or 2 a day but i have successfully completed several battery benchmarks without issue.

unboosted, the longest i've managed is 50 minutes. and sometimes it will crash within seconds of starting playback. i've never seen any error messages though. most of the time it just goes off. one time the screen just froze and i had to hold the power button to turn it off

@cris. at the moment, i think your only option would be to read the "how to compile" guide found on the wiki pages.

Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: MasterFen on May 10, 2010, 06:26:25 AM
I'd like to report a bug with the Clip+ port (although it probably happens in all the other Sansa AMS ports too) regarding clearing all my settings back to default.

It does what it's meant to do but for some reason whenever the line selector is in any subfolders in the "Plugins" section, it does not show; it scrolls and selects things as usual except you have no idea what you've selected. The problem seems to go away after a reboot back into Rockbox.

Can anybody see if it happens in any of the other AMS ports?
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: ranma on May 10, 2010, 11:03:11 AM
GPIO registers of OF vs Rockbox on C200v2.
Last time I tried reading those I used the wrong address (0xc80[bcde]0000 instead of 0xc80[bcde]03fc) for reading the data and always got 0 because of that (low address lines are ANDed with the data byte on reads and select which bits are written to on writes). RIS is kind of interesting because it shows which bits have seen a high->low transition (reset by writing to IC).

Code: [Select]
OF, USB connected, both buttonlights + display on
  DATA     DIR      IS       IBE      IEV      IE       RIS      MIS      IC       AFSEL
A 000000a7 000000b3 00000000 00000000 00000000 00000000 00000012 00000000 00000000 00000000
B 0000007e 00000070 00000000 00000000 00000001 00000001 0000007c 00000000 00000000 0000000c
C 000000ff 00000000 00000000 00000000 00000000 00000000 000000ff 00000000 00000000 000000ff
D 0000009f 00000080 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

OF, USB disconnected, both buttonlights + display on
  DATA     DIR      IS       IBE      IEV      IE       RIS      MIS      IC       AFSEL
A 000000a7 000000b3 00000000 00000000 00000000 00000000 00000012 00000000 00000000 00000000
B 0000007e 00000070 00000000 00000000 00000001 00000001 0000007c 00000000 00000000 0000000c
C 000000ff 00000000 00000000 00000000 00000000 00000000 000000ff 00000000 00000000 000000ff
D 0000009f 00000080 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

OF, USB disconnected, buttonlights + display off
  DATA     DIR      IS       IBE      IEV      IE       RIS      MIS      IC       AFSEL
A 00000007 000000b3 00000000 00000000 00000000 00000000 000000b2 00000000 00000000 00000000
B 0000007e 00000070 00000000 00000000 00000001 00000001 0000007c 00000000 00000000 0000000c
C 000000ff 00000000 00000000 00000000 00000000 00000000 000000ff 00000000 00000000 000000ff
D 0000001f 00000080 00000000 00000000 00000000 00000000 00000080 00000000 00000000 00000000

Rockbox (locally modified r25924), USB disconnected, main buttonlight + display on
  DATA     DIR      IS       IBE      IEV      IE       RIS      MIS      IC       AFSEL
A 000000a5 000000b3 00000000 00000004 00000000 00000004 000000b2 00000000 00000000 00000000
B 0000007e 00000070 00000000 00000000 00000000 00000000 0000007c 00000000 00000000 0000000c
C 000000ff 00000000 00000000 00000000 00000000 00000000 000000ff 00000000 00000000 000000ff
D 0000001f 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

Rockbox (locally modified r25924), USB disconnected, buttonlights + display off
  DATA     DIR      IS       IBE      IEV      IE       RIS      MIS      IC       AFSEL
A 00000005 000000b3 00000000 00000004 00000000 00000004 000000b2 00000000 00000000 00000000
B 0000007e 00000070 00000000 00000000 00000000 00000000 0000007c 00000000 00000000 0000000c
C 000000ff 00000000 00000000 00000000 00000000 00000000 000000ff 00000000 00000000 000000ff
D 0000001f 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

Rockbox (vanilla r25924), USB disconnected, main buttonlight + display on
  DATA     DIR      IS       IBE      IEV      IE       RIS      MIS      IC       AFSEL
A 000000b6 000000a0 00000000 00000004 00000000 00000004 000000a0 00000000 00000000 00000000
B 0000007e 00000030 00000000 00000000 00000000 00000000 0000003c 00000000 00000000 0000000c
C 000000ff 00000000 00000000 00000000 00000000 00000000 000000ff 00000000 00000000 000000ff
D 0000001f 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

Rockbox (vanilla r25924), USB disconnected, buttonlights + display off
  DATA     DIR      IS       IBE      IEV      IE       RIS      MIS      IC       AFSEL
A 00000016 000000a0 00000000 00000004 00000000 00000004 000000a0 00000000 00000000 00000000
B 0000007e 00000030 00000000 00000000 00000000 00000000 0000003c 00000000 00000000 0000000c
C 000000ff 00000000 00000000 00000000 00000000 00000000 000000ff 00000000 00000000 000000ff
D 0000001f 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

I'm guessing that port B0 (interrupt enabled on OF) may be used for remote control via the docking connector (http://www.amazon.com/dp/B000IBJKIE).

My locally modified version sets the LCD reset GPIO (B6) and the unknown port A GPIOs to output to match OF more closely.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: vadik on May 10, 2010, 12:20:40 PM
(well I hope it will still crash for everyone because for me it does)

well my clip v2 has never crashed when boosted (touch wood).

Same here.  Clip v2, r25914 (both bootloader and rockbox).  Without boosting the CPU, crashes within two minutes (playing an MP3); boosted, survives for an hour.

Will it help if I run battery bench on my clip v2, or do we have enough statistics?
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 10, 2010, 12:25:06 PM
r25914

Please don't report bugs with builds older than r25924 (and always use very recent builds because development happens fast on those)
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: bilditup1 on May 10, 2010, 03:58:38 PM
There are some interesting uSD-power-related patches in 25936...charging up my battery for an overnight test (it probably won't finish 'till tomorrow afternoon).
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Xanikseo on May 10, 2010, 05:47:32 PM
I have no idea if this is due to rockbox on the fuze, or a problem with rockbox in general, but there are problems playing OGGs with 48KHz sample frequency. There is a sharp crackling in the background, making it impossible to listen to.

http://www.mediafire.com/?myjmdtjyyt5
Screw that, just a case of clipping on RG.
It isn't RG clipping, it's just that using RG with a 48KHz sample rate causes this crackling noise.

BTW haven't had any crashes so far with cpu frequency scaling disabled.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: saratoga on May 10, 2010, 05:50:14 PM
I have no idea if this is due to rockbox on the fuze, or a problem with rockbox in general, but there are problems playing OGGs with 48KHz sample frequency. There is a sharp crackling in the background, making it impossible to listen to.

Here is such a sample http://www.mediafire.com/?tdgztnm3hnm.

Try it in the sim, and then file a bug report.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Xanikseo on May 10, 2010, 06:17:21 PM
Argh simulator is crashing atm in wine whatever file I play (didn't used to before). Trying in VM will post results here.
Ok, seems to be a problem with RB in general. Filing bug report - done, link (http://www.rockbox.org/tracker/task/11258?project=1&type=2&order=dateopened&sort=desc)
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: GodEater on May 11, 2010, 06:44:47 AM
Why on earth would you run the sim in Wine? It compiles just fine for linux.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: bYOndo on May 11, 2010, 08:30:11 AM

Please don't report bugs with builds older than r25924 (and always use very recent builds because development happens fast on those)

r25939-100510: my clipv2 seems much more stable now!
I tried my personal "pitch stressing test" many times and no "undefined instruction" or "data abort" has happened.
crossed fingers... ;)
I didn't modified anything about cpu boosting, I don't even know how I can do that, so it's just the default settings.

Massimo
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: bilditup1 on May 11, 2010, 09:20:12 AM
New battery bench is attached for build 25936.

I kept all the settings the same:
5-track jazz album, 40 minutes, ~190-210kbps mp3
Volume -20db
Flat EQ
No backlight
No RG
Headphones plugged in

Time was 15:24. This is 24 minutes shorter than build 25821. I guess this is due to the changes funman made in 25924? I don't know how much, if at all, this was mitigated by saratoga's changes in 25936 to sd-as3525v2.c.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Xanikseo on May 11, 2010, 09:24:05 AM
Why on earth would you run the sim in Wine? It compiles just fine for linux.
I don't have to compile anything if I download the windows binary ;). I know this goes against the grain :P, but it was late and I didn't want to read any instructions :D.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 11, 2010, 10:25:30 AM
r25939-100510: my clipv2 seems much more stable now!
I didn't modified anything about cpu boosting, I don't even know how I can do that, so it's just the default settings.

Yes boosting/unboosting has been disabled so it defaults to boosted.

It's stable for me, I completed 2 battery_bench cycles on Clip+/Clipv2 (Fuzev2 2nd bench still going).

Time was 15:24. This is 24 minutes shorter than build 25821. I guess this is due to the changes funman made in 25924? I don't know how much, if at all, this was mitigated by saratoga's changes in 25936 to sd-as3525v2.c.

Small variations are frequent I think, not necessarily linked to a different revision (Try running 2 benches on the same revision and see if they change).



Current theory on set_cpu_frequency(): instruction caching and/or icache content goes wrong while PCLK is lower than 24MHz (happens for a really short time).

Invalidating the icache before returning seems to help, the crashes are at least less frequent.

If this is the case we need to make sure the code after lowering PCLK and until the icache invalidation (included) is not in the icache.

EDIT: doing it like the OF (increase/decrease the dividers one by one) seems to work too; and the advantage is that we can explain why: "the OF does it"
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Xanikseo on May 11, 2010, 02:15:16 PM
So far the suggested patch (loop) looks more stable than the first patch, funman, unfortunately it results in scrolling to be incredibly slow.
EDIT: Not just scrolling, but everything: most notably backlight fading, volume fading

The first one isn't so stable, I can get crashes quite easily...

(Unrelated) Oh! And playing 48KHz OGGs now works perfectly :D! Great!
I tend to get crashes at the end of tracks though now (introduced sometime between r25956 and r25936)... I suspect the two are related somehow, perhaps the dsp related submissions?

Haha finally, an error message (couldn't see them as backlight was always off)
Code: [Select]
Data abort
at 300506D8
FSR 0x8
(domain 0, fault 8)
address 0xEBE4300F
EDIT: Cannot reproduce this crashing if I disable crossfade.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 11, 2010, 02:44:46 PM
So far the suggested patch (loop) looks more stable than the first patch, funman, unfortunately it results in scrolling to be incredibly slow.
EDIT: Not just scrolling, but everything: most notably backlight fading, volume fading

The first one isn't so stable, I can get crashes quite easily...

Thanks for testing, I made a mistake in the 2nd patch and updated it.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Xanikseo on May 11, 2010, 03:16:44 PM
Yes your new loop patch patch seems to have fixed the slowness. For some bizarre reason, there is no more crashing at the end of tracks with or without crossfade, now that I am using your patch :o. Baffling as this shouldn't have anything to do with cpu boosting...
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: ubbut on May 11, 2010, 06:06:45 PM
@Xanikseo
I a experienced the same problem (clip+ crashes at the end of a track) and currently i have to wait until the battery is low the boot again.

Is there any possibility to reset the device?

edit: ok just got it: you have to hold the power button very very long (i only tried to hold it very long)

thx

I will also test the new patch and see if it still crashes
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: ssorgatem on May 11, 2010, 06:46:54 PM
Has anyone tested rockbox for the fuzev2 built with the eabi toolchain? I'm currently running it, and it works great!  (in previous revisions it wouldn't even boot).

So far, I haven't had any issue I wouldn't have had with a "normal" build.

PD: is doom working for anyone?
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: mc2739 on May 11, 2010, 06:52:07 PM
Has anyone tested rockbox for the fuzev2 built with the eabi toolchain? I'm currently running it, and it works great!  (in previous revisions it wouldn't even boot).

So far, I haven't had any issue I wouldn't have had with a "normal" build.

PD: is doom working for anyone?

Doom is known to have problems when using the eabi toolchain.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: ssorgatem on May 11, 2010, 07:57:17 PM
True, with non-eabi doom.rock it works :) (in a eabi-built rockbox)
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 11, 2010, 11:30:28 PM
doing it like the OF (increase/decrease the dividers one by one) seems to work too; and the advantage is that we can explain why: "the OF does it"

Doesn't work



With FS#11257 (http://www.rockbox.org/tracker/task/11257) recording should work fine (only tested on Clip+ so far)
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: torne on May 12, 2010, 06:59:14 AM
True, with non-eabi doom.rock it works :) (in a eabi-built rockbox)
Doing that is rather dodgy and it's a miracle it works - EABI and the old toolchain are not supposed to be compatible with each other. Doom doesn't work with EABI on *any* device at the moment, it's nothing specific to the sansas.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: ssorgatem on May 12, 2010, 07:06:58 AM
True, with non-eabi doom.rock it works :) (in a eabi-built rockbox)
Doing that is rather dodgy and it's a miracle it works - EABI and the old toolchain are not supposed to be compatible with each other. Doom doesn't work with EABI on *any* device at the moment, it's nothing specific to the sansas.

Yes, I know, I was just playing with it  ;D

As far as i've tested, eabi rocks do work in non-eabi rockbox and the other way around, too (I discovered this having two separate builds in my fuze: non-eabi and eabi).
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: torne on May 12, 2010, 07:11:53 AM
This will only work for plugins which don't use plugin api functions that do certain things that differ between EABI and OABI. The complete list is rather esoteric and I'm not sure whether we actually *have* any plugin api functions that fall under that category, so... who knows.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Xanikseo on May 12, 2010, 08:29:15 AM
doing it like the OF (increase/decrease the dividers one by one) seems to work too; and the advantage is that we can explain why: "the OF does it"
Doesn't work
You mean it doesn't make crashing less frequent? That's a shame... It somehow fixes a new the problem of crashing at the end of tracks though, although it may not fix the root of the problem. I've been using your patch, and it seems quite stable, I find it hard to crash.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 12, 2010, 08:31:31 AM
I have no crashes with SVN so less frequent crashes isn't a solution, unless they are infinitely less frequent (i.e. there are no crashes either)
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Xanikseo on May 12, 2010, 12:48:13 PM
But SVN doesn't enable cpu boosting...  If this is still going in the right direction, as in less crashes, couldn't this be added to svn, but still keep cpu scaling off? Unless of course you are sure that it doesn't really affect the frequency of crashes at all.

I don't get crashing anymore btw in SVN at the end of tracks.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 13, 2010, 02:16:53 AM
If it's not a fix then it doesn't belong to SVN.



New bootloaders v2.0 released for Clipv2/Clip+/Fuzev2, instructions and URLs on the wiki (http://www.rockbox.org/wiki/SansaAMS) as usual.

They increase battery life and get rid of some crashes at boot (the players would boot with a black screen).

The fuzev2 bootloader on the server displays 'Boot Ver. Ver. 2.0' (2 times 'Ver.') so before it is updated you can get a bootloader without the typo here (http://omploader.org/vNGJiaA/bootloader-fuzev2.sansa)
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: marc2003 on May 13, 2010, 03:11:02 AM
nice work with the new bootloaders. but i think clip+ users need a new version of mkamsboot if they want to use the latest OF??
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 13, 2010, 04:39:34 AM
there will be no new version of mkamsboot, we won't be making a new release each time Sandisk release a new firmware for any of the supported models.

The choices are:
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: MasterFen on May 13, 2010, 05:13:08 AM
Disregard Funman's last post, I used the normal instructions from the SansaAMS Wiki page (http://www.rockbox.org/wiki/SansaAMS) and got the new bootloader 2.0 installed on my Clip+ just using the Mkamsboot from the normal link.

I don't know if it's a new version of MKB but it seems to work just fine.

UPDATE

(http://i249.photobucket.com/albums/gg222/MasterFen/DSC00010.jpg)
It's hard to make out, but it does say 2.0. The only problem is it hangs on shutdown, just not turning off after "Shutting Down" is shown on-screen.

Tl;dr - It works, but you'll have to do the "Hold power and >|| buttons" trick to get it to turn off.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Vague Rant on May 13, 2010, 05:34:55 AM
There's no reason to disregard funman's post, it's still accurate; the firmware version linked on the wiki is the one previous to the latest update from Sandisk, as that is the version supported by mkamsboot, which will not be updated in line with official Sandisk releases.

I have a Clip+ too with the new bootloader and have no problems with shutdowns, have you tried deleting/re-copying Rockbox (you may wish to back up your settings first)?
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: MasterFen on May 13, 2010, 05:48:08 AM
Ok, I'll try that in a while. I can't do it now due to me having to copy some files to a flash drive (which takes up my last USB port >:() so I'll report back once I've done what you suggested.

UPDATE

Good news, it does shut down!  :D Although it now takes about the same time to shut down as the OF.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: bYOndo on May 13, 2010, 06:23:40 AM

New bootloaders v2.0 released for Clipv2/Clip+/Fuzev2, instructions and URLs on the wiki (http://www.rockbox.org/wiki/SansaAMS) as usual.

They increase battery life and get rid of some crashes at boot (the players would boot with a black screen).

The fuzev2 bootloader on the server displays 'Boot Ver. Ver. 2.0' (2 times 'Ver.') so before it is updated you can get a bootloader without the typo here (http://omploader.org/vNGJiaA/bootloader-fuzev2.sansa)

Is it my impression, or clipv2 speed w/ new BL and r25977 is much more improved? Database buildings took me a couple of seconds (reboot included), blazing fast! Never seen on any other RB'ed player...
Thanks once more funman,  now developers, make "pitch" modification permanent or commit FS#10906 (http://www.rockbox.org/tracker/task/10906), please! :) or is it too early?

Massimo


 
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 13, 2010, 06:59:07 AM
Is it my impression, or clipv2 speed w/ new BL and r25977 is much more improved? Database buildings took me a couple of seconds (reboot included), blazing fast! Never seen on any other RB'ed player...

I don't think the bootloader has any effect, but in current revisions the default CPU speed is fixed at 240MHz instead of 24MHz so it might feel faster (and draw more power)

Thanks once more funman,  now developers, make "pitch" modification permanent or commit FS#10906 (http://www.rockbox.org/tracker/task/10906), please! :) or is it too early?

This patch won't apply to as3525v2, we don't know how to program the PLL so we use the only known setting: 240MHz.

I don't even know how inaccurate we are for each audio frequency (12 frequencies from 8kHz up to 96kHz) given this PLL rate.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: ubbut on May 13, 2010, 09:07:59 AM
hey nice work!
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Xanikseo on May 13, 2010, 11:57:54 AM
I also confirm that shutting down takes much longer with the new bootloader on fuzev2

All those who want to use the new OF versions, but are getting errors from the current mkamsboot, because it's out of date, and don't know/can't be bothered to compile from svn: here is a linux binary freshly compiled from SVN.

http://www.datafilehost.com/download-00385efd.html

I've tested it, and it works with 2.03.31 OF on Fuzev2 for example.
EDIT: Here's a patched firmware for Fuzev2: http://www.datafilehost.com/download-dd4104c1.html
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: henriquemaia on May 13, 2010, 02:23:23 PM
I'm also getting the long shutdown times and playback doesn't resume as it used to. Upon restart I get the message "nothing to resume" (though it was playing upon shutdown).

I'm using the new booloader and r25997-100513.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: mc2739 on May 13, 2010, 03:00:43 PM
The slow shutdown appears to have been introduced with r25989, not the bootloader.  If you have an older revision, you can switch back to that until this problem gets resolved.

edit: This problem is causing settings not to be saved on shutdown, which will cause playback resume issues that have been noted.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: nickdc on May 13, 2010, 03:27:06 PM
I also confirm that shutting down takes much longer with the new bootloader on fuzev2

All those who want to use the new OF versions, but are getting errors from the current mkamsboot, because it's out of date, and don't know/can't be bothered to compile from svn: here is a linux binary freshly compiled from SVN.

http://www.datafilehost.com/download-00385efd.html

I've tested it, and it works with 2.03.31 OF on Fuzev2 for example.
Could u make a win version?
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: chaos123 on May 13, 2010, 04:42:53 PM
I also confirm that shutting down takes much longer with the new bootloader on fuzev2

All those who want to use the new OF versions, but are getting errors from the current mkamsboot, because it's out of date, and don't know/can't be bothered to compile from svn: here is a linux binary freshly compiled from SVN.

http://www.datafilehost.com/download-00385efd.html

I've tested it, and it works with 2.03.31 OF on Fuzev2 for example.
Could u make a win version?

You can get a win version here http://www.anythingbutipod.com/forum/showpost.php?p=469376&postcount=87
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 13, 2010, 05:33:41 PM
The slow shutdown appears to have been introduced with r25989, not the bootloader.

should be fixed in r26003, thanks
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: henriquemaia on May 13, 2010, 05:44:58 PM
The slow shutdown appears to have been introduced with r25989, not the bootloader.  If you have an older revision, you can switch back to that until this problem gets resolved.

edit: This problem is causing settings not to be saved on shutdown, which will cause playback resume issues that have been noted.

Thanks for pointing that out. I've installed an archived build and now things are ok once again.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: FlynDice on May 14, 2010, 02:05:25 PM
I was under the impression that uSD was working pretty well until talking to funman in irc today.  Anyone else having problems you can describe for me?
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Jennifur on May 14, 2010, 02:46:52 PM
I was under the impression that uSD was working pretty well until talking to funman in irc today.  Anyone else having problems you can describe for me?

Which revision is causing the problem? I'm using r25938M-100514 right now and it works just fine. I was using r25983-100513 for a bit and that works fine. Except I noticed the volume was a bit lower than r25938M-100514.

Also, how do I stop the list from jumping from the top to the bottom when I scroll through the playlist? It works fine if I move the scrollwheel slowly. If I start scrolling sharply, or speed up scrolling too quick it will jump. It does get a bit annoying after a while.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: luca on May 14, 2010, 02:49:41 PM
Well, there's the issue with buttonlight flickering when accessing uSD, but it's not a big deal (FuzeV2 8GB + 8GB uSD). Can be reproduced by selecting microSD in the File Browser: the buttonlight turns off immediately before showing the root directory. Any other button press turns it on again. Probably something when selecting the card, since subsequent accesses (browsing other folders) don't exhibit this behaviour.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 14, 2010, 02:56:43 PM
I just tried inserting/removing a couple of times the 2 µSD cards I have on fuzev2/clip+, as well as turning on the devices with the card inserted.

I couldn't reproduce any problem, I'll try to use the cards more extensively and report if I still see a problem.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Jennifur on May 14, 2010, 02:57:41 PM
Well, there's the issue with buttonlight flickering when accessing uSD, but it's not a big deal (FuzeV2 8GB + 8GB uSD). Can be reproduced by selecting microSD in the File Browser: the buttonlight turns off immediately before showing the root directory. Any other button press turns it on again. Probably something when selecting the card, since subsequent accesses (browsing other folders) don't exhibit this behaviour.

I kind of like the button light flickering during uSD access. Not sure what effect it has on battery life though. Maybe it could become an option to have it on/off? The wheel light option has no effect on it by the way.
Title: FM radio and voicing
Post by: lecky on May 14, 2010, 05:50:02 PM
Hi all,
I have clip plus and testing with voicing (voiced menus and spelled filenames). Voicing works everywhere except the situation when is the radio turned on. Is there some hardware limitation specifically on clip plus (voicing with enabled radio works e.g. on fuze v1) or is it a bug?
Btw many many thanks for your great work.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 15, 2010, 05:30:59 AM
Well, there's the issue with buttonlight flickering when accessing uSD

Fixed in r26031

Voicing works everywhere except the situation when is the radio turned on. Is there some hardware limitation specifically on clip plus (voicing with enabled radio works e.g. on fuze v1) or is it a bug?

It's a bug, fixed in r26045



BTW if you see ATA error -18 with builds >= 26028 please check the filesystem with chkdsk.exe / fsck before reporting it
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Xanikseo on May 15, 2010, 07:58:16 AM
I got white screens of death with panics, and got -18 errors after r26028. fsck didn't help at all, I had to format the fuze and restore all the files again not to get this which took ages. I suppose it has to be done some time... Is r26028 extremely sensitive or something :P?
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: marc2003 on May 15, 2010, 08:19:54 AM
26050 should fix the panic -18 error.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Xanikseo on May 15, 2010, 10:59:19 AM
Got more info on the button wheel flashing. It doesn't flash when it is supposed to be on. It flashes when after it is switched off automatically, but it won't flash while in hold. This is observed while updating the database with songs from µSD.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 15, 2010, 12:22:23 PM
r26059 should fix it once for all
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: nViATi on May 15, 2010, 01:30:45 PM
Does anyone else notice hissing in their Rockboxed C200v2 with sensitive headphones? It's always present, even during playback. The original firmware C200v2 doesn't hiss, and neither did the C200v1 OF or Rockboxed.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: bilditup1 on May 15, 2010, 04:50:15 PM
I'm definitely having problems with uSD. I got a hang on boot with 26026. With 26064, it boots all the way, but crashes when I try to navigate in the uSD. This happened multiple times. This is, again, on an 8GB Fuze v2 with an 8GB Class 4 Kingston uSD.

UPDATE: I'm not quite sure whether this is actually a Rockbox problem. The Sansa firmware also recently froze up on boot, and removing the SD let it complete. I've also successfully booted Rockbox and managed to navigate through and play songs without a crash (at least for a few minutes now). Sorry for the knee-jerk alarm-sounding ;)
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 16, 2010, 01:23:14 AM
I had a crashed while waiting for TRAN state yesterday (didn't think to write down the state in which it was).

I'll try highering the delay from 1 sec to 2 secs

EDIT: crashed again in state DATA
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Xanikseo on May 16, 2010, 01:19:55 PM
Just like to report that the scroll-wheel randomly stopped working on r26086. Cause is not known, but this has never happened before... A reset fixed the problem.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Jennifur on May 16, 2010, 02:11:50 PM
Just like to report that the scroll-wheel randomly stopped working on r26086. Cause is not known, but this has never happened before... A reset fixed the problem.
This happened to me quite a few times. I thought it was just me messing around with the scrollwheel code. I'm trying r26092-100516 right now to see if that fixes it.

EDIT:
r26092-100516 has the same problem. I had it paused while it was on the charger for about 20 min while I was doing something else. The scroll-wheel stopped working. The previous version I used that worked just fine was: r25938-100514 with and without me messing around with the scroll-wheel code.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 17, 2010, 05:09:39 AM
Perhaps the problem is caused by r26060 ? Can you check if reverting the commit helps?
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: bor_ka on May 17, 2010, 06:27:02 AM
I believe I've detected a bug in the r25299. Sansa Fuze v1, 8GB. May be I can trace it, but I need help.

In short - player hangs in database population. More detailed description and steps to reproduce are in the FlySpray http://www.rockbox.org/tracker/task/11267. BTW, look at my last comment, the initial description was not accurate (!).

I can build custom fw, and may be debug it - but need a help, since I've never worked with the external hardware. Linux/BSD/kernel/C though are Ok :).
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: csavery on May 17, 2010, 06:49:25 AM
Regarding scrollwheel freezing. I get this in r26096 after some minutes of no button activity while playing.
I reverted to 26059 and 26060 and both didn't freeze for me.
I'm on r26060 now and letting it go longer without button activity to see if freezing occurs.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: saratoga on May 17, 2010, 11:27:44 AM
I believe I've detected a bug in the r25299. Sansa Fuze v1, 8GB. May be I can trace it, but I need help.

In short - player hangs in database population. More detailed description and steps to reproduce are in the FlySpray http://www.rockbox.org/tracker/task/11267. BTW, look at my last comment, the initial description was not accurate (!).

I can build custom fw, and may be debug it - but need a help, since I've never worked with the external hardware. Linux/BSD/kernel/C though are Ok :).


I see you're using some odd compiler version as well as EABI.  Does this still occur if you use the normal compiler (4.0.3)?
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: nomak on May 17, 2010, 03:23:23 PM
Hello! Thanks for GREAT work! I use rockbox first time. Maybe I do smth wrong...But i can't clear dynamic playlist and to do other delete operations(delete folders, files doesn't work) rockbox r26043-100515 Fuze V2

Now evrything OK. I pressed >|| instead of central button to confirm delete operations.
- Sometimes can't exit from rockpaint.
- once in brickmania in 24(or higher level)  ball was disappeared in right bottom corner , so I must to play again from 1st level =)
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Xanikseo on May 17, 2010, 04:57:58 PM
Try the most recent build here (http://build.rockbox.org/data/rockbox-sansafuzev2.zip).

I'm so pleased that AMS are willing to give the datasheet for rockbox development :). http://svn.rockbox.org/viewvc.cgi?view=rev&revision=26116
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 17, 2010, 06:12:43 PM
I'm so pleased that AMS are willing to give the datasheet for rockbox development :). http://svn.rockbox.org/viewvc.cgi?view=rev&revision=26116

Looking at the commit log I think I must precise I got the datasheet for the AS3543 (audio front end and power management unit), not the "AS3525v2" which is only the name we gave to this SoC, not knowing what it is exactly (well it's a newer version of as3525, or at least compatible).

kudos to them !
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: bilditup1 on May 17, 2010, 06:36:13 PM
The 'auto-reboot to OF on USB' feature from 26116 is really cool. Kudos to funman et al for working on this, and to AMS for being considerate. I wonder though, funman - did you ask them for other datasheets as well, or was this the most important one? What's the upshot of getting these sheets from an audio perspective?
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 17, 2010, 06:48:26 PM
Well I only asked for this one (yesterday), I wouldn't know what else I could ask for.

As for audio, I don't know, audio works pretty well already.

It seems even line out works, but we need to detect dock plugging (tenfoot is working on it)
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: csavery on May 17, 2010, 07:56:17 PM
funman: I'm still seeing scrollwheel lock up in r26114. I have an idea what it is but I'm not familiar with the code so I'm pretty much just poking in the dark and just putting this out there as a question.

In button-fuzev2.c there is the change as of r26060,

long v = (time - last_wheel_post);
    if (v < WHEEL_LOOP_INTERVAL) /* avoid too frequent updates */
        return ;

I see v is defined as long and not unsigned long. According to my calcs with timer freq of 1.5 MHz this will wrap into a negative number in about 23 minutes. This is round about the time taken for the scroll wheel to lock up. So I had the idea that if the scroll wheel doesn't move for 23 minutes and no event is posted then the time delta would be negative and cause this function to return without processing the event for another 23 minutes until it wraps positive again. Is this possible?

In my tests it takes approx this much time to freeze and only with no wheel activity. Unfortunately due to how long you have to wait it's rather slow to test.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: ssorgatem on May 17, 2010, 08:08:13 PM
I've observed the scrollwheel freeze too, after leaving the fuze some minutes inactive (they may well hace been more than 23 minutes)
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 17, 2010, 08:19:17 PM
csavery: it looks possible, i have seen the wheel stop working and work again when testing charging.

I didn't measure the time elapsed but it might have been multiples of 23 minutes.

Instead of counting the number of timer ticks I think we should just count rockbox ticks separately because they overflow in much longer time (248 days with HZ=100).

If you have a patch can you post it on flyspray?

thanks!



If you use a current build with Clip+ it will try to reboot to OF on USB plug, but with current mkamsboot it will fail and power off the Clip+
So you should:

I'm not sure if we will make a mkamsboot release soon because there is some good progress on USB support in rockbox on all the models (AMSv1 & v2), perhaps we should just wait for the drivers to work.

What is the opinion of the other devs on this?
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: saratoga on May 17, 2010, 08:26:24 PM
Even if we have USB working, we still need to do a new bootloader/mkamsboot release to make it boot rockbox on USB insert right?

In that case I would prefer to wait until either USB is working, or until it looks like its going to be a while before USB works.  Updating the bootloader isn't that risky, but its kind of a mess.  Maybe we could just disable rebooting on USB insert?
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Jennifur on May 17, 2010, 09:18:16 PM
Even if we have USB working, we still need to do a new bootloader/mkamsboot release to make it boot rockbox on USB insert right?

In that case I would prefer to wait until either USB is working, or until it looks like its going to be a while before USB works.  Updating the bootloader isn't that risky, but its kind of a mess.  Maybe we could just disable rebooting on USB insert?

I agree with saratoga on this. Also, it is nice having it charge and be able to play at the same time instead of booting into the OF which doesn't allow this.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: saratoga on May 17, 2010, 09:38:23 PM
Also, it is nice having it charge and be able to play at the same time instead of booting into the OF which doesn't allow this.

As funman said, you can already do this by holding a button while plugging in USB.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: csavery on May 17, 2010, 09:42:46 PM
funman: I'm testing a version of button-fuzev2.c adapted to HZ timer. It seems to be working and I'm just waiting about 30 minutes to see how it behaves. If it works then I'll make a patch. Keep in mind that I've only been coding in Rockbox for a couple days so I'm not sure it wouldn't have other side effects.

edit: Seems to work. I have posted patch in Flyspray. I hit save too quickly and forgot to set correct patch info. Maybe someone with edit rights can fix that?  ::)
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: bor_ka on May 18, 2010, 03:25:19 AM
I see you're using some odd compiler version as well as EABI.  Does this still occur if you use the normal compiler (4.0.3)?

Well, I thought that eabi is the preferred way (looking at the speed comparison on the fuze). And the 4.4.3 is the recommended for eabi. Will try 4.0.3 though.

P.S. The database update does not freeze if there is no playback, and if I "play" with the scrollweel (turn it back and forth every 30 secs or so).
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 18, 2010, 03:32:21 AM
I have posted patch in Flyspray. I hit save too quickly and forgot to set correct patch info. Maybe someone with edit rights can fix that?  ::)

I edited FS#11288 (http://www.rockbox.org/tracker/task/11288)
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: mitk on May 18, 2010, 03:56:31 AM
Funman: I'm charging clip+ under Rockbox. Started from 62%, now have 74% and still going up.
Firmware, bootloader and mkamsboot from r26125

Edit:
Charging stalled at 99%, 4.210 V. Status is charging, it didn't stop..
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: bor_ka on May 18, 2010, 04:06:39 AM
Update on FS#11267 (http://www.rockbox.org/tracker/task/11267). Fuzev1 hangs if playback is on, and database is updated in the background. It hangs even on the "official" 3.5.1.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: csavery on May 18, 2010, 07:12:07 AM
Updated patch FS#11288 (http://www.rockbox.org/tracker/task/11288) for fixing scroll wheel lockup after 20 minutes.
Should work, please test when you have time.  ;D
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: max242 on May 18, 2010, 05:38:47 PM
I strongly believe that the issues i'm having getting pictureflow correctly building the cache of  thumnails on my sansa fuze v1, is related to the issue bor_ka is reporting on him building the tag cache/database correctly.

The pictureflow thread can be found here: http://forums.rockbox.org/index.php?topic=24496.0, and also started at r25299.

So when i today saw r26116 is fixing an issue introduced in r25299, i tried again building at first the database, then the pictureflow cache.  But still no success in building the pictureflow cache.

I have seen a message from funman stating he has issues building the tag cache/database properly, which i think might be related to what bor_ka is saying.

Bor_ka did you ever try to use pictureflow, and also see your sansa freeze/lockup somewhere during the thumbnail generation process?  It fails on me nearly every time!

But unfortunately i have absolutely no clue on what is causing these issues, and i guess wild guessing is not really permitted in this thread (interrupts, maybe?).

The only thing i know for sure is that the picture flow freeze issue didn't occur in r25298, and does occur ever since r25299

We really should try to find the root cause of these issues, so we can nail them down, and squash them forever.  Can some of you guys give some hints on what we can do to locate the troublesome code?

Also, since i'm pretty sure the pictureflow freeze issue, and the database building freeze issue are related, i think it would be better to rephrase FS#11267 http://www.rockbox.org/tracker/task/11267 to something like 'Freeze on sansa fuze v1 during tag cache/pictureflow cach building', or something more reasonable.  Is this possible?

I'm sorry for this (very) long post, but i just wanted to make sure you all are aware of this.  And if this post is not in the proper place, move it to a position which does make sense, i just didn't want this info to get lost.

Keep on rockboxing!

Marc
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 19, 2010, 10:07:36 AM
the fuzev1 freeze issues should be fixed in current svn (for me they are)
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Ahcsas on May 19, 2010, 04:01:59 PM
Rockbox runs very well on my Clip+  :) ,

but I have a lot of artefacts (clicking and whirring sound) during navigation (browsing database, open&close plugins/games, at each memory access [when the memory access-symbol is on the display).

When I hear music (on low volume) I can hear the artefacts also. With OF I have this problem not.

------------------------------------------------
Firmware, bootloader and mkamsboot from r26150.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 19, 2010, 05:43:44 PM
I think I hear that one in the OF too, perhaps it's less noticeable since the OF has no plugins/games ;)



I have a put a patch for set_cpu_frequency() : FS#11297 (http://www.rockbox.org/tracker/task/11297)

Please report on the flyspray task if it works or not for you
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: bor_ka on May 20, 2010, 07:18:13 AM
the fuzev1 freeze issues should be fixed in current svn (for me they are)

Unfortunately for me - not :( r26185, the bug as described in my FS#11267 is still there. I noticed, though, very big speedup in database scanning, and overall menu responsiveness.

And who can edit FS#11267, especially the title and description? Me not.

By the way, fuze hangs only if there is simultaneous playback and database population. If And the card is 16GB Class 2 Kingston - may be it depends on the card speed?

max242

Pictureflow scanning for me works Ok. No hangs. Some jpegs are not displayed though...
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: athatai on May 20, 2010, 08:47:40 AM
funman, I own a Clip+ and am using 26179 and it looks like the USB charging is broken. I tried it on my PC and the screen blacked out with no music. The wall charger does not seem to work either (same problem).
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 20, 2010, 09:10:10 AM
I have a put a patch for set_cpu_frequency() : FS#11297 (http://www.rockbox.org/tracker/task/11297)

It doesn't work.

And who can edit FS#11267, especially the title and description? Me not.

If you have comments related to the ticket please add them on flyspray.

I own a Clip+ and am using 26179 and it looks like the USB charging is broken. I tried it on my PC and the screen blacked out with no music. The wall charger does not seem to work either (same problem).

If you use a current build with Clip+ it will try to reboot to OF on USB plug, but with current mkamsboot it will fail and power off the Clip+
So you should:
  • Reinstall the bootloader (the last bootloader will work) with a mkamsboot build from SVN or wait for a new mkamsboot release.

Did you follow these instructions? Charging works fine for me.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: athatai on May 20, 2010, 09:56:36 AM
funman,

Thanks for the suggestion. I'll try that later tonight. I simply did not connect the dots :) Now I understand...
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Jennifur on May 20, 2010, 11:07:28 AM
Updated patch FS#11288 (http://www.rockbox.org/tracker/task/11288) for fixing scroll wheel lockup after 20 minutes.
Should work, please test when you have time.  ;D

The patch works perfectly. I've yet to have the scroll-wheel freeze now. Thank you so much.

Also, ran the battery bench. Got about the same runtime as the OF.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: thor777 on May 20, 2010, 02:02:31 PM
Does anyone else notice hissing in their Rockboxed C200v2 with sensitive headphones? It's always present, even during playback. The original firmware C200v2 doesn't hiss, and neither did the C200v1 OF or Rockboxed.

I'm noticing hiss on my rockbox'd Fuze v2 as well.  I'm using RE0s and r26155.  This happens whether it's directly connected to Fuze HP or through my Cmoy amp.  The hissing starts at around -10db and it's really apparent at 0db.  I can get around this by turning up the pre-amp from replay-gain and lowering the volume within Rockbox, so it's not a really big deal for now....but the OF (v02.03.31) does not have any hiss even when I turn the volume to max (on Fuze and/or on amp).
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 21, 2010, 07:56:07 AM
My clipv2 have much more hiss than my Clip+ and Fuzev2.

Using FS#11297 (http://www.rockbox.org/tracker/task/11297) I noticed that it is different (lasts less longer but happens more often) when the CPU is boosted, and it also seems different with 24MHz or 40MHz CPU clock.

It's absent when listening to FM radio.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: csavery on May 21, 2010, 10:55:27 AM
I can't hear any hiss on my Fuze v2 even at loud volumes.
Is it possibly codec dependent. I'm using mp3 (@320).
I do get clicks when play changing events occur like pause, resume, stop, shutdown.
Shutdown clicks even if play already stopped.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: markun on May 21, 2010, 10:58:19 AM
I made some changes to try to improve the audio quality of Clipv2, Clip+ and Fuzev2. I personally don't hear any difference on my Clip+ but maybe it helps for some of you:

http://www.rockbox.org/tracker/task/11304
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Xanikseo on May 21, 2010, 01:13:21 PM
New OF 02.03.33 has been released for fuzev2. For those who cba/don't know how to compile from svn:
new linux (64-bit) mkamsboot binary (http://www.datafilehost.com/download-c9ac8ee8.html). EDIT2: PM me if you want a prepatched firmware.

EDIT:  I appreciate your effort but we are not authorized by Sandisk to distribute the OF.  This is the reason that you have to download & provide your own copy to mkamsboot when you patch your firmware.  Please do not post links to patched firmware on the forums.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Vague Rant on May 21, 2010, 01:17:34 PM
I believe patched firmwares are not linked on purpose; while they're made freely available online, they presumably are not released under any sort of open license, and so modified versions can't be released by third parties legally. To be honest, they're not likely to care or do anything about it, but Rockbox does everything it can to remain 100% above-board.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Xanikseo on May 21, 2010, 01:34:12 PM
I offer it at my own risk. If sansa want me to remove it, then I will!
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Jennifur on May 21, 2010, 02:44:12 PM
New OF 02.03.33 has been released for fuzev2. For those who cba/don't know how to compile from svn:
new linux mkamsboot binary (http://www.datafilehost.com/download-c9ac8ee8.html)

EDIT:  I appreciate your effort but we are not authorized by Sandisk to distribute the OF.  This is the reason that you have to download & provide your own copy to mkamsboot when you patch your firmware.  Please do not post links to patched firmware on the forums.[/url]


You should let people know the mkamsboot binary you provide is for 64bit systems.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: csavery on May 21, 2010, 03:22:23 PM
I just compiled a new mkamsboot. It's not working due to a new model_id of 0x71.
Looking at the code I see the new version 2.03.33 is in the list but the 0x71 model_id isn't there.
Are we expected to add this id ourselves or what is the trick to getting a working mkamsboot?
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Jennifur on May 21, 2010, 03:53:06 PM
I just compiled a new mkamsboot. It's not working due to a new model_id of 0x71.
Looking at the code I see the new version 2.03.33 is in the list but the 0x71 model_id isn't there.
Are we expected to add this id ourselves or what is the trick to getting a working mkamsboot?


What model of Sansa?

I have a FuzeV2 and the SVN version works just fine for me. I grabbed the V2.0 boot loader from a few pages back. The firmware from Sansa, and compiled mkamsboot from the SVN. If you want, you can PM me and I can upload it somewhere for you.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: csavery on May 21, 2010, 04:02:41 PM
Sansa Fuze v2
I'd like to be able to build myself from svn. I have r26239 just checked out.
My fuzpa.bin file has model id 0x71 at location 0x219 - I checked with hex viewer.
So mkamsboot is correctly saying it's not known mode id.
I could add the 0x71 model id to the table in mkamsboot but I don't want to make a bad firmware image by mistake.

edit - just checked out 26241 but no change in mkamsboot.

Is there more than one version of mkamsboot in svn? I am compiling the one under rbutil/mkamsboot.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Jennifur on May 21, 2010, 04:15:17 PM
Sansa Fuze v2
I'd like to be able to build myself from svn. I have r26239 just checked out.
My fuzpa.bin file has model id 0x71 at location 0x219 - I checked with hex viewer.
So mkamsboot is correctly saying it's not known mode id.
I could add the 0x71 model id to the table in mkamsboot but I don't want to make a bad firmware image by mistake.

edit - just checked out 26241 but no change in mkamsboot.

Is there more than one version of mkamsboot in svn? I am compiling the one under rbutil/mkamsboot.

I'm looking through mkamsboot.c now, and the code is indeed there.

Code: [Select]
    { MODEL_FUZEV2, "2.01.17", "8b85fb05bf645d08a4c8c3e344ec9ebe" },
    { MODEL_FUZEV2, "2.02.26", "d4f6f85c3e4a8ea8f2e5acc421641801" },
    { MODEL_FUZEV2, "2.03.31", "74fb197ccd51707388f3b233402186a6" },
    { MODEL_FUZEV2, "2.03.33", "1599cc73d02ea7fe53fe2d4379c24b66" },
};

Using SVN version 26241.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: csavery on May 21, 2010, 04:23:56 PM
Yes, but look further down. It does a check in a function called get_model - this returns unknown with the new 2.03.33 image - well, the one I have anyway - just downloaded from sansa site.

I added,

case 0x71:

and then compiled and ran mkamsboot. It succeeds with this model_id value added. I haven't copied it to my Fuze yet because I'd like to confirm somehow that others have seen this new model_id in 2.03.33. The md5 checks out so I don't see how others could not have 0x71 in their OF file as well.

The model_id is not the version # but seems it should refer to the device model. Of course, my device has changed but I am definitely seeing the value 0x71 in location 0x219 in the latest OF image fuzpa.bin

Maybe this is why they rolled 2.02.31 -> 2.03.33 ?
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Jennifur on May 21, 2010, 04:29:13 PM
Yes, but look further down. It does a check in a function called get_model - this returns unknown with the new 2.03.33 image - well, the one I have anyway - just downloaded from sansa site.

I added,

case 0x71:

and then compiled and ran mkamsboot. It succeeds with this model_id value added. I haven't copied it to my Fuze yet because I'd like to confirm somehow that others have seen this new model_id in 2.03.33.

The model_id is not the version # but seems it should refer to the device model. Of course, my device has changed but I am definately seeing the value 0x71 in location 0x219 in the latest OF image fuzpa.bin



I see it too. Yet when I patched the OF I didn't get(notice) the error. I can try again and see if I get it.

EDIT:
I didn't get the error at all. This is the output from mkamsboot

Code: [Select]
jennifur@alice:/mnt/disk$ mkamsboot fuzpa_orig.bin bootloader-fuzev2.sansa boot.bin
mkamsboot Version r26241-100521
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] Original firmware MD5 checksum match
[INFO] Model: Sansa Fuze v2 - Firmware version: 2.03.33
[INFO] Firmware patching has begun !

[INFO] Original firmware size:   168920 bytes
[INFO] Packed OF size:           90016 bytes
[INFO] Bootloader size:          76240 bytes
[INFO] Packed bootloader size:   33945 bytes
[INFO] Dual-boot function size:  364 bytes
[INFO] UCL unpack function size: 168 bytes
[INFO] Total size of new image:  124493 bytes

[INFO] Patching succeeded!
jennifur@alice:/mnt/disk$
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: csavery on May 21, 2010, 04:36:00 PM
That's weird. It's exactly what I get after I add the model id.
How could the md5 match the one embedded in mkamsboot when the model byte 0x71 != 0x70 ?
Baffling... I guess I'll wait a bit before trying to boot on it.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Jennifur on May 21, 2010, 04:43:56 PM
I ran md5sum on the OF and got the same result as in mkamsboot.c. Can you try downloading the firmware once again and run md5sum on it?
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 21, 2010, 05:00:16 PM
get_model() isn't called if the md5sum of the OF is in the list.

Btw, before we add an OF release it is always tested on a real device first.



I see indeed that the model id has changed from 0x70 to 0x71 so it makes me wonder:

Perhaps we should not rely on this field to detect model of the OF ?

What if Sandisk decides to release a Clip+ firmware with model id = 0x71 too ?
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: csavery on May 21, 2010, 05:07:09 PM
I just checked it all again. Downloaded again, ran md5sum at linux prompt. Matches value in mkamsboot.
Mine is 1599cc73d02ea7fe53fe2d4379c24b66
Opened fuzpa.bin in hex editor again and double checked value at 0x219 is 0x71

Looking at mkamsboot code I see the model id is only checked when the md5 doesn't match.
So it must be that the model id increment has not yet been added into a new mkamsboot.

I think what *must* of happened is that at first I compiled mkamsboot with r26185 and it didn't yet have the correct md5 for 2.03.33 so it failed and gave me the wrong model id reason. Then after I updated and re-compiled I didn't realize it wasn't the model id but the md5 that was actually wrong before.

I just verified this by removing the "case: 0x71" I had added and the result is good OF.

Except... the mkamsboot DOES need to have the new model_id value added since otherwise it DOES give the wrong error message about model_id.

I guess I should add a bug in FlySpray for that then.

Update - funman: Ahh, yes, thank you for checking that. I see it too. Probably just needs a second case statement so it now accepts either model id. It's no longer unique.

Anyway, happy here. Firmware upgrade worked ok. Should I add a bug or patch for this?

As of r26239 I am not hearing clicks any more during play state changes. Sweet. Thanks!
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 21, 2010, 05:30:11 PM
Should I add a bug or patch for this?

Well I'm not sure what to do, see my post just above

As of r26239 I am not hearing clicks any more during play state changes. Sweet. Thanks!

Hmm I didn't know about this : is it caused by r26238 ? (r26237 still has them?)
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: csavery on May 21, 2010, 06:43:31 PM
Actually I'm noticing it in r26239 still. It happens during pause at the end of the fade and during play before the fade starts. It fades down and then a little "phhht" sounds occurs, or when play is pressed after a pause it makes a slight "phht" and then fades up. During shutdown it may happen a couple times or just once. It pretty much always there, though I've noticed a few times when pause is quiet.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: NightWalker on May 21, 2010, 07:38:22 PM
I have a fuvev2 and a clip+
Rename and erase on SD fails with
*PANIC* wait for TRAN state failed <PRG> 1 on both (Not something new)
Using a 16GB class 6 card and the current build (r26241)
everything works fine with 4GB class 2 card
Keep up the great work!

Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 22, 2010, 02:07:03 PM
@FlynDice

sd_wait_for_state() timeouts after 1 second, is that an arbitrary choice ?

I looked for maximum delays after STOP_TRANSMISSION in the spec but I didn't find any

Quote from: spec page 29
As soon as the data transfer is completed, the card will exit the data write state and move either to
the Programming State (transfer is successful) or Transfer State (transfer failed).

I think TAAC / NSAC / TRAN_SPEED don't take in account how much time the card spends in PROGRAMMING state.

I tried to read linux source code for MMC/SD but it is a nightmare of object code, I can grep for STOP_TRANSMISSION but I don't know where/when it is issued.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: FlynDice on May 22, 2010, 06:43:52 PM
The one second is indeed arbitrary I think.  Perhaps just increasing it will take care of that problem or we could wait for the card to signal not busy after the transfer is complete.  Since the card is basically programming the info on its own and we don't need to manage it I think just increasing the timeout here would be the preferable solution if it works.  I'll have time later tonight to look at this, I'm between flights right now.

 I can't access the irc logs  and flyspray for some reason so I can't see if you got my message about the cpu_freq_patch that I left in the log.   With v10 I did get my clip+ to run down to empty by clearing my settings.  However when I juiced it back up and looked at the hardware page I noticed that there was no frequency switching going on, just a steady 40 MHz until there was a card access.  It seems that 40 MHz is enough performance that boosting is not needed at least without the equalizer & compressor enabled.  If I enable the compressor and equalizer I get boosting on a regular basis and the clip+ crashes after about 30 mins.


EDIT:

http://pastie.org/973066 will definitely solve the card stuck in PRG state problem.  It passes write & verify but I got mixed results for speed, some faster some slower on tests.  I can't be sure that it won't introduce something else though without more widespread testing. ;)
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 23, 2010, 06:32:02 AM
The one second is indeed arbitrary I think.  Perhaps just increasing it will take care of that problem or we could wait for the card to signal not busy after the transfer is complete.  Since the card is basically programming the info on its own and we don't need to manage it I think just increasing the timeout here would be the preferable solution if it works.  I'll have time later tonight to look at this, I'm between flights right now.

http://pastie.org/973066 will definitely solve the card stuck in PRG state problem.  It passes write & verify but I got mixed results for speed, some faster some slower on tests.  I can't be sure that it won't introduce something else though without more widespread testing. ;)

OK, going to test it. No idea for the the slower speed though.

I'll see if yielding while the card is busy affects speed too much, it shouldn't change a lot since we yielded anyway if the card was in programming state, unless if had finished programming immediately.

EDIT: I got some "read multiple blocks failed" when playing off µSDHC class 6 on Clip+. I'll try to add back the wait for state TRAN after the busy wait.
EDIT2: same crashes, I'll now try with extended delay when waiting for TRAN state

I can't access the irc logs  and flyspray for some reason so I can't see if you got my message about the cpu_freq_patch that I left in the log.

I think logbot is on the same server than the website so no irclogs until the site is back. (and messages while the site went down won't be logged).

With v10 I did get my clip+ to run down to empty by clearing my settings.  However when I juiced it back up and looked at the hardware page I noticed that there was no frequency switching going on, just a steady 40 MHz until there was a card access.  It seems that 40 MHz is enough performance that boosting is not needed at least without the equalizer & compressor enabled.  If I enable the compressor and equalizer I get boosting on a regular basis and the clip+ crashes after about 30 mins.

It still boosts but if it's fast enough you won't have the time to see it in the debug page.

DSP settings and voices make crashing happen more quickly, I'll run my tests with it enabled.

Here are some results with cpufreq:

With v10 (I think it's that one, can't access flyspray, anyway it was CPU@40MHz and no delays when changing freqs) on Clip+ playing from internal I had 15h15 runtime, so even if we make it work it makes battery life not better if not worse, probably because of the higher DRAM/PCLK freq (40MHz instead of 24).

On Fuzev2 I got 19h from internal, 11h33 from µSD (Samsung 1GB, not HC, no class). I'll try with the Transcend SDHC 4Gb class 6, some messages on the forum said higher class cards crashed more.

I also tried another version for Clips which use 24MHz PCLK, but doesn't go lower than 24 when switching (24, 30, 60), and it crashed quite fast (freezes, data abort in thread code).

I wonder if there is anything special about Fuzev2 or if we just didn't see any crash because we tested this model less.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 23, 2010, 07:11:15 AM
get_model() isn't called if the md5sum of the OF is in the list.

Btw, before we add an OF release it is always tested on a real device first.



I see indeed that the model id has changed from 0x70 to 0x71 so it makes me wonder:

Perhaps we should not rely on this field to detect model of the OF ?

What if Sandisk decides to release a Clip+ firmware with model id = 0x71 too ?

I checked other firmwares and this field has already changed in the past:

It is 0x23 on the one c200v2 OF we have, and on the last 2 Fuzev1 OFs.

So we must disable this check completely because it is not representing of the model.

EDIT: I have a patch for that, just waiting for svn to be up again.

To be clear, if you use released binaries or unmodified SVN there is no risk of bricking.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: DonDan on May 23, 2010, 10:34:04 AM
I have tested the "as3525v2-cpufreq-v10" patch with the 26241 revision on a fuze2 8GB with a transcend CL6 8GB uSD .

I still have a few crashes with the v10, when recording and when browsing  the PictureFlow demo. During playback with crossfeed enabled and everything else disabled, I have no crashes at all.

Without the "as3525v2-cpufreq" patch I can record Mic/Radio for more than 4 hours without a crash (tested with output to mp3 and wv).

I have done a battery-bench with a 33 min rock music album with 258 VBR (Lame3.99 --vbr-new -V 0) with Crossfeed enabled (forgot to disable), playback from internal memory. Earplugs with impedance = 16 Ohm and volume set to -20dB.
It lasts for 12h and 30 min, "Battery bench ended, reason: power off", no crash.

If you need more fuze2 testing give a shout!


EDIT: I can't reproduce the PictureFlow freeze, maybe it is some PictureFlow specific bug.
The Recording crashes come every time, it is just a matter of time, sometimes just a few seconds other times I must wait for 30 min. I doesn't matter if the source is radio or mic neither if the output is mp3 or wv.
The error message is always the same:

*PANIC*
unhandled IRQ (source unknown!)


Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 24, 2010, 10:34:32 AM
The Recording crashes come every time, it is just a matter of time, sometimes just a few seconds other times I must wait for 30 min. I doesn't matter if the source is radio or mic neither if the output is mp3 or wv.
The error message is always the same:

*PANIC*
unhandled IRQ (source unknown!)


I have just made a commit (r26250) which should make this panic message a bit more precise, I suspect it should now show I2SIN interrupt.

Can you confirm?



FlynDice, I have put a patch for SD on FS#11312 (http://www.rockbox.org/tracker/task/11312)
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: DonDan on May 24, 2010, 01:09:34 PM
Now I get under the same conditions as before the following error:
(I cannot read the entire error msg because it clips right after INT_DMA)

*PANIC*

Unhandled masked IRQ 04: INT_DMAC...
(status 0x00000000)

in the builds before you disabled the dynamic CPU frequency I was always getting the following error when recording:

*PANIC*
i2sin error: 0x4E = push


The PictureFlow freeze is not related to this issue, as csavery confirmed, it is a PictureFlow specific bug. FS#11286 (http://www.rockbox.org/tracker/task/11286)
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 24, 2010, 01:24:01 PM
Now I get under the same conditions as before the following error:
(I cannot read the entire error msg because it clips right after INT_DMA)

*PANIC*

Unhandled masked IRQ 04: INT_DMAC...
(status 0x00000000)


The entire error msg is here, it's not clipped.

If it still happens with r26257 I guess we'll need to handle i2sin fifo errors one way or another.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: DonDan on May 24, 2010, 05:38:33 PM
with r26259
the recording does not work at all:

the vu-meter gets stuck in the first second and if you press play to start the recording a filename appears, but the  the time field does not change  and the vu-meter does not move. You still are able to stop the recording but the file is not saved. Gain an Volume still responds to any user induced change. Also no crashing at all ;).
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 24, 2010, 06:34:18 PM
Should be fixed in r26270
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: DonDan on May 25, 2010, 05:59:35 AM
Still getting almost the same error, status changed a little:

*PANIC*

Unhandled masked IRQ 04: INT_DMAC
(status 0x00000010)


Using r26279 with as3525v2-cpufreq-v10.diff
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Ahcsas on May 25, 2010, 11:42:31 AM
I can't create a bootloader for the Clip+ from r26260 until r26280 (current).

The Issue must be in r26260, building a bootloader from r26259 works.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 25, 2010, 12:26:04 PM
Should be fixed in r26285, but you should really use the binary bootloader on SansaAMS wiki page; we don't check regularly if bootloaders work or not.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: jfinnie on May 26, 2010, 02:06:45 AM
I just wanted to quickly say big kudos to all you developers working on Sansa AMS - I've installed R26289 on my clip+, and after compiling mkamsboot from SVN source the player seems to work absolutely great (before that, kept rebooting on connection of USB to PC).

The wiki pages are very clear and informative, and got me compiling within an hour - and that was including installing the dev environment and doing an SVN checkout.

I haven't been this impressed with an open source project in a long time.  Keep up the good work guys! :)
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: MasterFen on May 26, 2010, 05:11:26 AM
Would you mind uploading your compiled version somewhere? I have the same reboot on usb problem.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: marc2003 on May 26, 2010, 09:20:28 AM
my first ever crash with cpu at full speed. r26311. this happened about 2 minutes after starting playback. i didn't see any messages so i turned back on, enabled backlight always on and it crashed again within minutes leaving me this message....

*PANIC*
Unhandled masked IR
Q 04: INT_DMAC (sta
tus 0x00000010)

clip v2, playing ogg, no eq/effects.

EDIT: i created my own 26310 build from SVN  and it appears to be ok. i then put 26311 back on and it crashed again within a minute. i just need to test 26310 for a lot longer to be sure.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: mitk on May 26, 2010, 11:59:50 AM
Same for me. I've got 3 crashes in 2 hours with Fuze v1 and r26311. Don't have any panic message because of no backlight enabled. I think it's related.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 26, 2010, 12:12:36 PM
Yeah indeed it is caused by r26310, thanks for the report.

I'm working on a fix.

BTW I think it's the same bug than the panics with recording reported earlier (same message), and some other bugs I have seen related to USB/charger plugging

EDIT: should be fixed in r26316 (only for playback/recording, did nothing for USB/charger interrupt)
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: jfinnie on May 26, 2010, 02:47:30 PM
Would you mind uploading your compiled version somewhere? I have the same reboot on usb problem.

Here is a link to my compiled version of mkamsboot:
http://www.mediafire.com/?jtmihgmtw2y
Compiled yesterday under Cygwin, revision 26289. 
I used this to build a firmware image for my Clip+ and it worked, though of course use at own risk.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: ssorgatem on May 26, 2010, 04:33:35 PM
I have currently two weird issues with my fuzev2:

1 -  Apparently randomly, the screen goes blank. This can happen from the first moment the screen is on, it can happen after the "ver 2.0" screen, and the white screen remains blank; or it can show a blank screen instead of the boot "ver 2.0" screen and then  show rockbox normally. It can also become blank during playback.

 It can also happen that it boots fine, but the colors are very weak, oo have very high brighness or something (black looks light grey). And sometimes it boots normally. It can even be difficult to get one of these white screens when you're intending to do so, and sometimes you can get rid of them, rebooting again and again into a blank screen.

 In all cases rockbox itself still works; I can hear the menus and the usual stuff guided through voice.

 I've tried to see in which revision or when it did happen. Results of my research: the rockbox version doesn't matter; it to be something bootloader-related, and I've tested too older mkamsboot but it's still there.

However, if I install an old patched firmware file I have, with the old bootloader (not "Ver 2.0"), it doesn't happen. I upgraded to the v2 bootloader last week; maybe tuesday or wednesday, but I started to notice the white screen issue this monday. If it's something related to the bootloader, I might have been "lucky" and haven't get a white screen in those first days (I didn't use the fuze too much those days, either), so my hipothesis is that it's bootloader related.Where could I find older working bootloader builds? Or which revisions are known to work? (I know bootloader's status isn't checked regularly).

UPDATE: Using a bootloader built from svn seems to solve the problem (I can't be 100% sure about it until some more hours of testing)

And the second one:

2 - [Not sure if it's fuzev2-specific]I have an artist called "Têtes Raides".They're all mp3 files (the only mp3 files I have) and are tagged as ID3v2.3 ISO  8859-1 (all my music is tagged with these tags, they're the better supported by the OF).

The problem: yesterday, it showed under database/artist as "T[]tes Raides". Also, no unicode character from songs or albums from that artist was shown correctly. I can see unicode characters from other artists, and it even shows correctly (Têtes Raides) under the file browser (so it's not a font issue).

The weirdest: today, I find that, under Database/Artist I have two entries: "Têtes Raides" and "T[]tes Raides". I haven't touched my music in the player. Also, the albums listed for each are different, and unicode characters under "Têtes Raides" are shown correctly, whereas in "T[]tes Raides" they aren't.

Any ideas about why is this happening?

UPDATE: Both entries show exactly the same albums and songs... but one shows them correctly,  while the other doesn't. However, even if I play a non-correctly shown file, it will show correctly on the WPS.


UPDATE: I just needed to rebuild the database, and then it showed properly. Thanks to funman for suggesting it.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: DonDan on May 27, 2010, 11:49:47 AM
I have done some new recording tests with rev. r26316.

I was able to record from mic to WV for 4 hours without a crash, I aborted my self the recording, everything went alright. Nice!!! :) 
As you have foreseen, funman! 

Recording from radio also went OK, made a recording with 1,5 hours, then the battery got empty and it shutdown.  Maybe it was a crash, because I got no file with the recorded data.

I also got a freeze once after 3 sec with rec source radio, maybe not relevant, just bad luck?
Afterward I recorded for 57 min from radio to WV, battery got empty again but this time the recorded data was saved to a file. Charging battery for more radio -> WV testing...I will report later.

 
I have noticed that if a crash occurs during a recording, there is no file with the recorded data. It would be a really awful scenario if you have, lets say recorded a 2 hours session, and in the last few minutes it crashes. You would have lost the entire recording.
Is it possible to manage that, if a crash occurs the recorded date doesn't get lost?  This way it would be still awkward but it would not be a total disaster.

EDIT: Got a freeze after 1h 5min recording from mic! It looks like the recording feature is still not reliable.  :'(
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: saratoga on May 27, 2010, 12:04:45 PM
I have noticed that if a crash occurs during a recording, there is no file with the recorded data. It would be a really awful scenario if you have, lets say recorded a 2 hours session, and in the last few minutes it crashes. You would have lost the entire recording.

If you lose power while writing the fat table isn't properly closed.  Run check disk and it'll be updated and you'll get your file.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: DonDan on May 27, 2010, 12:10:35 PM
Would this also apply to a crash during the recording or only to shutdowns caused by power down?
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: saratoga on May 27, 2010, 12:14:07 PM
Would this also apply to a crash during the recording or only to shutdowns caused by power down?

I can't think of any difference between the two, so presumably. 
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: DonDan on May 27, 2010, 01:57:31 PM
I have noticed that if a crash occurs during a recording, there is no file with the recorded data. It would be a really awful scenario if you have, lets say recorded a 2 hours session, and in the last few minutes it crashes. You would have lost the entire recording.

If you lose power while writing the fat table isn't properly closed.  Run check disk and it'll be updated and you'll get your file.

Why is the File Allocation Table is only written at the end of recording process?Would it not be better if it is done at the beginning to ensure you find the file without a fdisk procedure in case of a power down or crash?
Am I missing something?
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Vague Rant on May 27, 2010, 02:18:59 PM
That would conflict with the very concept of the FAT, which you might think of as a book index which lists where everything can be found--the difference being that the FAT also has to know how large the file is ("how many pages it takes up"). The nature of a recording is that it's constantly growing in size, so adding it to the FAT record at the beginning wouldn't make any sense.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: saratoga on May 27, 2010, 02:27:41 PM

Why is the File Allocation Table is only written at the end of recording process?Would it not be better if it is done at the beginning to ensure you find the file without a fdisk procedure in case of a power down or crash?
Am I missing something?

Yes, that its not the 1970s and none of us is Bill Gates.  Go ask him why he designed FAT the way he did.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Xanikseo on May 28, 2010, 11:42:22 AM
I've noticed that since r26335 (it may have been introduced earlier) I have to wait for "Refreshing your media" to finish in OF, after whenever I have used Rockbox (even when just switching on rockbox, and powering off again).

Also I can't charge anymore with a wall-charger, without it booting into OF (yes, ok you can hold down select). Surely I should be able to use a wall-charger without booting into OF, since I can't really transfer any data with a wall-charger? Or is it because we don't know how to detect if someone is just using a charger or is in fact connecting to a computer?
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Rob2222 on May 28, 2010, 12:22:17 PM
Hello,

my brand new FuzeV2 doesnt want to flash a patched firmware, however the original fuze02.03.33 FW he flashes flawlessly.

I tried 02.03.33 from http://forums.sandisk.com/sansa/board/message?board.id=sansafuse&thread.id=38046
with mkamsboot.exe from http://forums.rockbox.org/index.php?topic=14064.msg167356#msg167356
and output was http://pastie.org/981998

I also tried 02.02.26 from http://daniel.haxx.se/sansa/amsfw.html
with mkamsboot.exe from http://download.rockbox.org/bootloader/sandisk-sansa/mkamsboot/win32/
outpus reported success, also.

Renamed output.bin to fuzpa.bin. After disconnecting mass-storage-usb the player doesnt start the flash process.
With original fuzpa.bin he starts flash process after disconnecting mass-storage-usb.

30 minutes ago I flashed my also new Clip+ with the same mkamsboot.exe without problems.

Any hints? I can upload the output.bin if wanted.

If I don't need to set up a own compile chain it would be very nice.

EDIT: Same problem by 2 user here: http://forums.sandisk.com/sansa/board/message?board.id=sansafuse&message.id=42952#M42952
You can only flash 03.31 and 03.33. Hmm...

EDIT2: It doesnt want to flash the original 2.1.17, 2.2.26, 2.2.28, too.
It only flashes The 2.3.31 and the 2.3.33.

Looks like it has an additional check.

BTW, here is a dirlist:
 Datenträger in Laufwerk G: ist SANSA FUZE
 Volumeseriennummer: 0CF5-6F32

 Verzeichnis von G:\

01.01.1980  00:00    <DIR>          MUSIC
01.01.1980  00:00               320 SYS_CONF.SYS
01.01.1980  00:00    <DIR>          RECORD
01.01.1980  00:00    <DIR>          AUDIBLE
01.01.1980  00:00    <DIR>          PHOTO
01.01.1980  00:00    <DIR>          VIDEO
01.01.1980  00:00    <DIR>          PODCASTS
01.01.1980  00:00    <DIR>          AUDIOBOOKS
01.01.1980  00:00            51.237 RES_INFO.SYS
01.01.1980  00:00                83 version.sdk
01.01.1980  00:00             7.800 VIDEO_BM.SYS
01.01.1980  00:00               114 DID.bin
01.01.1980  00:00         1.862.468 MTABLE.SYS
               6 Datei(en),      1.922.022 Bytes
               7 Verzeichnis(se),  7.675.346.944 Bytes frei

Any new file maybe?



BR and thanks in advance
Robert
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: csavery on May 28, 2010, 01:00:04 PM
I've noticed that since r26335 (it may have been introduced earlier) I have to wait for "Refreshing your media" to finish in OF, after whenever I have used Rockbox (even when just switching on rockbox, and powering off again).

I've had this same behavior with r26251.
I don't think it's Rockbox causing this since it is the OF that is deciding to refresh media.
It may be the 02.3.33 OF as it was about the same time I rebuilt my firmware file. I wonder if Sansa set it to detect changes it didn't used to and which files it may now be detecting?

Update - I reverted back to firmware based on 2.2.26 and it does the same thing now. I think this means that Rockbox is now altering some file that the OF detects as needing a media refresh...

It's quite annoying when doing development as it means having to wait for refreshes at least twice as many times. I don't think the OF has any smart key presses for bypassing the refresh - only cool rockbox devs can think of that it seems.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: FlynDice on May 28, 2010, 01:25:10 PM
EDIT2: It doesnt want to flash the original 2.1.17, 2.2.26, 2.2.28, too.
It only flashes The 2.3.31 and the 2.3.33.

Looks like it has an additional check.


That's what it seems like to me also.  I had no problem updating with OF V02.03.31A with current SVN mkamsboot.  The OF must now be doing some kind of additional check on this file before commencing the update process.

It seems V02.03.31A will indeed use a Patched fuzpa.bin though.  If you can flash 2.3.31 back onto your player you may be able to use that to flash a patched firmware.


Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Rob2222 on May 28, 2010, 01:45:18 PM
@FlynDice/All

Even with running 2.3.31 it wont flash anything other then 2.3.31-Org and 2.3.33-Org. :(

BR Robert
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: djphatic on May 28, 2010, 02:13:35 PM
It seems V02.03.31A will indeed use a Patched fuzpa.bin though.  If you can flash 2.3.31 back onto your player you may be able to use that to flash a patched firmware.




So flashing the player back to 02.03.31A you were able to get Rockbox to install? I my firmware version always showed P instead of A e.g. 02.03.31P and it does now even with Rockbox installed.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Rob2222 on May 28, 2010, 02:31:26 PM
@djphatic:
The letter behind the firmware number changes regarding the region setting.
(A=America, F=Europe and P=Pacific (Rest of World)

So you have now 2 Fuze's there, one which accepts patched and older formwares than .31 and one version that only accepts .31 and .33 original, or?

Can you see any difference on these units? Any big difference in the serial number?
Maybe differences in the system files in the root folder?
Could you maybe compare that?
Where you got the working unit from? Was that a new purchase? Meaning a new unit.

BR Robert
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: mitk on May 28, 2010, 02:46:44 PM
I've noticed that since r26335 (it may have been introduced earlier) I have to wait for "Refreshing your media" to finish in OF, after whenever I have used Rockbox (even when just switching on rockbox, and powering off again).

Also I can't charge anymore with a wall-charger, without it booting into OF (yes, ok you can hold down select). Surely I should be able to use a wall-charger without booting into OF, since I can't really transfer any data with a wall-charger? Or is it because we don't know how to detect if someone is just using a charger or is in fact connecting to a computer?

You noticed this behavior with uSDHC card inserted?
Please take a look at http://www.rockbox.org/tracker/task/11325?project=1&show_task=&order=id&sort=desc.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: nissin on May 29, 2010, 07:50:15 AM
@djphatic:
The letter behind the firmware number changes regarding the region setting.
(A=America, F=Europe and P=Pacific (Rest of World)

So you have now 2 Fuze's there, one which accepts patched and older formwares than .31 and one version that only accepts .31 and .33 original, or?

Can you see any difference on these units? Any big difference in the serial number?
Maybe differences in the system files in the root folder?
Could you maybe compare that?
Where you got the working unit from? Was that a new purchase? Meaning a new unit.

BR Robert

I've flash my fuze V2 without any problem.

Here are some details:
Stock firmware version: v02.01.17
The device has updated to v02.03.33P before flashing to rockbox.
Patched firmware transfer to the device using MSC mode.
I did not insert memory card during the flash process.

File size of patched firmware: 15,728,640 Bytes
CRC32: C2B8E669
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Rob2222 on May 29, 2010, 08:17:21 AM
My Fuze2 had 02.03.31 on it as it came.
My patched firmware has the same CRC sum.
Already checked MD5 hash with someone in #rockbox, was even, too.

Did you first updated to 02.03.33-org and then to 02.03.33-patched?

BR Robert
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Jennifur on May 29, 2010, 11:13:06 AM
My Fuze2 had 02.03.31 on it as it came.
My patched firmware has the same CRC sum.
Already checked MD5 hash with someone in #rockbox, was even, too.

Did you first updated to 02.03.33-org and then to 02.03.33-patched?

BR Robert

I did first flash from 02.03.33-org to the 02.03.33-patched. That worked fine for me. I used a svn version of mkamsboot and the boot loader that funman posted a few pages back. I can't remember whch svn version I had since the hard drive I had it on died. I can try re-flashing it with the stock OF and then flash it with the patched one when I get back today and see if that will work.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Rob2222 on May 29, 2010, 11:57:45 AM
@Jennifur:
Can you post a CRC or a MD5 of your .33OF and your patched .33?
The test would be nice along with the MD5 sums.
If this works for you, then the difference is surely not in the .33OF and must be in the player.

@All
Can it be that they (my fuze2) checks 0x408="0x24" or 0x460="0x44" in the code area? At least its even in .31 and.33 (which player accepts) and its even in the older original-FW which may player doesnt accept. But its different from new to old.

BR Robert
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: djphatic on May 29, 2010, 07:07:28 PM
@djphatic:
The letter behind the firmware number changes regarding the region setting.
(A=America, F=Europe and P=Pacific (Rest of World)

So you have now 2 Fuze's there, one which accepts patched and older formwares than .31 and one version that only accepts .31 and .33 original, or?

Can you see any difference on these units? Any big difference in the serial number?
Maybe differences in the system files in the root folder?
Could you maybe compare that?
Where you got the working unit from? Was that a new purchase? Meaning a new unit.

BR Robert

Yes I have 2 fuzes at the moment. I have not tried older firmwares with the new one as I do not want to risk losing Rockbox on this player.

No physical differences between the 2 players and I did not notice any different files or folders on the root of the internal memory.

Non-friendly serial = BI1004CAHK-8GB
Rockbox friendly serial = BI1004CAAK-8GB

The first player was from a UK seller on ebay, brand new and sealed. The second player was from Amazon UK.

Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Rob2222 on May 29, 2010, 09:09:52 PM
Interesting, mine non-RB-friendly has the same "serial"-number.
So it must be a model/submodel number:
I have too: BI1004CAHK-8GB

Could maybe some FUZE-V2 owners with players that accept a RB-Bootloader-patched-Firmware post their model number here?

BR Robert
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Jennifur on May 29, 2010, 09:17:10 PM
@Rob2222
The output of cksum and md5sum on the OF are as followed:
jennifur@alice:~/rockbox/rbutil/mkamsboot$ cksum fuzpa.bin
1724160563 15728640 fuzpa.bin
jennifur@alice:~/rockbox/rbutil/mkamsboot$ md5sum fuzpa.bin
1599cc73d02ea7fe53fe2d4379c24b66  fuzpa.bin

The output of cksum and md5sum on the patched firmware are as followed:
jennifur@alice:~/rockbox/rbutil/mkamsboot$ cksum boot.bin
847109887 15728640 boot.bin
jennifur@alice:~/rockbox/rbutil/mkamsboot$ md5sum boot.bin
65d84013a988c098cd23b2f45dd6311c  boot.bin

I would tell you the serial number of my Fuze, but that wore off.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Rob2222 on May 29, 2010, 09:28:34 PM
@Jennifur:

Thank you. I just RE-CHECKED both MD5 sums, they are equal to the files i tried with.
So we are using the same files. So when you can upgrade from .33OF to .33RB than there is something in the player different. :(
Would you like to try reflashing .33OF and then .33RB?

BR
Robert
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Jennifur on May 29, 2010, 09:41:03 PM
@Jennifur:

OK I just RE-CHECKED both MD5 sums, they are equal to the files i tried with.
So we are using the same files. So when you can upgrade from .33OF to .33RB than there is something in the player different. :(
Would you like to try reflashing .33OF and then .33RB?

BR
Robert

I did after checking the crc and md5. I got sick of the slotmusic icon after the first time I flashed.(I accidently hit North America when I started the OF after flashing the first time.)

EDIT:
If it helps. I got my Fuze for a Christmas gift. So it would look like something in the most recent batch of the players are preventing non-stock firmware being used. If the extended warranty on mine covers normal wear and tare I can try exchanging mine for a newer one.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 30, 2010, 05:25:25 AM
Could maybe some FUZE-V2 owners with players that accept a RB-Bootloader-patched-Firmware post their model number here?
BI0905BLCK-8GB
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: DonDan on May 30, 2010, 06:15:14 AM
Could maybe some FUZE-V2 owners with players that accept a RB-Bootloader-patched-Firmware post their model number here?

B10909BMYK-8GB

$ cksum.exe fuzpa_*bin
2176550167 15728640 fuzpa_02.03.31_OF.bin
1258673945 15728640 fuzpa_02.03.31_pached_ver2.0.bin
1724160563 15728640 fuzpa_02.03.33_OF.bin
847109887 15728640 fuzpa_02.03.33_pached_ver2.0.bin

$ md5sum.exe fuzpa_*bin
74fb197ccd51707388f3b233402186a6 *fuzpa_02.03.31_OF.bin
326bed432ac27923df2100a5097369e2 *fuzpa_02.03.31_pached_ver2.0.bin
1599cc73d02ea7fe53fe2d4379c24b66 *fuzpa_02.03.33_OF.bin
65d84013a988c098cd23b2f45dd6311c *fuzpa_02.03.33_pached_ver2.0.bin


Same check/md5 sums here. It works with  both of them. Downgrading from 33_patched to 31_patched is also possible.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: ssorgatem on May 30, 2010, 07:51:18 AM
Could maybe some FUZE-V2 owners with players that accept a RB-Bootloader-patched-Firmware post their model number here?

BH0906BMTK-4GB

It's black and seems to not behave exactly like the rest in in stuff about USB. My girlfriend has also a blue 4Gb fuzev2 which behaves exactly like my fuzev2, but it's SN isn't anymore there.

I haven't tested unpatched .33, but unpatched .31 allowed me to install patched .26 and .33, and patched .33 allowed me to install too patched .26 and .31. Both of them were bought last august from an online seller (Pixmania), and were new units, coming with firmware .26
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: id on May 30, 2010, 07:56:56 AM
Could maybe some FUZE-V2 owners with players that accept a RB-Bootloader-patched-Firmware post their model number here?

BI0912BMTK-8GB
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 30, 2010, 10:13:20 AM
Can you test FS#11330 (http://www.rockbox.org/tracker/task/11330) on Clip v1/v2/+ ?

It gets between 5 and 10 minutes more runtime but I want to be sure it's real and not random variation.

Just run battery_bench with and without the patch, using the same settings, and post both files on the ticket.

Thanks
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Julian67 on May 30, 2010, 11:02:22 AM
Could maybe some FUZE-V2 owners with players that accept a RB-Bootloader-patched-Firmware post their model number here?

B10901BKHK-8GB
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: FlynDice on May 30, 2010, 02:15:08 PM
Could maybe some FUZE-V2 owners with players that accept a RB-Bootloader-patched-Firmware post their model number here?

BH0812BKGK-4GB       Flashes all firmware just fine.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Rob2222 on May 30, 2010, 10:27:09 PM
OK, I'll getting the serials together. And as long as I'm following this thread I will keep this post updated.

Fuze units where you can flash what you want:

BH 0812 BKGK-4GB
BI  0901 BKHK-8GB (2 unit already)
BI  0903 BLAK-8GB
BI  0905 BLCK-8GB
BH 0906 BMTK-4GB
BI  0909 BMYK-8GB
BI  0912 BMTK-8GB
BI  1001 BMTK-8GB
BI  1003 BMTK-8GB
BH 1004 CABK-4GB
BI  1004 CAAK-8GB (2 units already)


Units that doesnt accept firmwares other then 02.03.31-OF and 02.03.33-OF:

BI  1004 CAHK-8GB (3 units with this number already)

The numbers look like the date code YYMM.
For the letters I dont really have an idea.

EDIT: Actual 04.June.2010

BR Robert
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Jennifur on May 31, 2010, 02:22:05 AM
OK, I'll getting the serials together. And as long as I'm following this thread I will keep this post updated.

Fuze units where you can flash what you want:

BH 0812 BKGK-4GB
BI  0901 BKHK-8GB
BI  0905 BLCK-8GB
BH 0906 BMTK-4GB
BI  0909 BMYK-8GB
BI  0912 BMTK-8GB
BI  1004 CAAK-8GB


Units that doesnt accept firmwares other then 02.03.31-OF and 02.03.33-OF:

BI  1004 CAHK-8GB (2 units with this number already)

The numbers look like the date code YYMM.
For the letters I dont really have an idea.

BR Robert

First two letters of the code, e.g. BH and BI would seem like it indicates the capacity. BH for 4GB and BI for 8GB. As you said the middle four numbers look like a date code. The last four letters are what I'm stuck on. A part of me wants to say one or two letters indicate colour, but I can't be 100% sure.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: lazo on May 31, 2010, 06:01:36 AM
Silver Fuze v2, serial: BI 0903 BLAK - 8GB
Successful Rockbox installation on OF 02.02.26 and 02.03.31
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Rob2222 on May 31, 2010, 06:37:35 AM
So, regarding the Fuzu wont accept RB-Flash:

So I have calles Sandisk about the "issue" and the nice women said that they are aware of it, the ready it already in the forums and im the second person that asks fot that. At the same sentence she says also, that she is sorry, but that this (issue) is made that people "dont make this" (... use alternative firmware?!) anymore.
She still tries to help and is trying to get a official announcement for that.

I think I wait for 2-3 days and then im returning my unit and trying to get another one.

BR Robert
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 31, 2010, 07:37:42 AM
First two letters of the code, e.g. BH and BI would seem like it indicates the capacity. BH for 4GB and BI for 8GB. As you said the middle four numbers look like a date code. The last four letters are what I'm stuck on. A part of me wants to say one or two letters indicate colour, but I can't be 100% sure.

Last part could be an increasing number: my Fuzev1 4GB is
Code: [Select]
BH0707AXWK-4GB
So I have calles Sandisk about the "issue" and the nice women said that they are aware of it, the ready it already in the forums and im the second person that asks fot that. At the same sentence she says also, that she is sorry, but that this (issue) is made that people "dont make this" (... use alternative firmware?!) anymore.
She still tries to help and is trying to get a official announcement for that.

I am not sure why they care at all, perhaps they were returned several "defective" players with rockbox installed?


EDIT:

You can try this to see how the protection they added is effective:
Be sure you want to risk bricking your fuze by running modified code

Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: skaos on May 31, 2010, 09:56:46 AM
Maybe the third letter is hardware version/revision? Maybe someone can open a "C" player to see if there's any differences?
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: nissin on May 31, 2010, 10:00:33 AM
Hello,

my brand new FuzeV2 doesnt want to flash a patched firmware, however the original fuze02.03.33 FW he flashes flawlessly.

I tried 02.03.33 from http://forums.sandisk.com/sansa/board/message?board.id=sansafuse&thread.id=38046
with mkamsboot.exe from http://forums.rockbox.org/index.php?topic=14064.msg167356#msg167356
and output was http://pastie.org/981998

I also tried 02.02.26 from http://daniel.haxx.se/sansa/amsfw.html
with mkamsboot.exe from http://download.rockbox.org/bootloader/sandisk-sansa/mkamsboot/win32/
outpus reported success, also.

Renamed output.bin to fuzpa.bin. After disconnecting mass-storage-usb the player doesnt start the flash process.
With original fuzpa.bin he starts flash process after disconnecting mass-storage-usb.

30 minutes ago I flashed my also new Clip+ with the same mkamsboot.exe without problems.

Any hints? I can upload the output.bin if wanted.

If I don't need to set up a own compile chain it would be very nice.

EDIT: Same problem by 2 user here: http://forums.sandisk.com/sansa/board/message?board.id=sansafuse&message.id=42952#M42952
You can only flash 03.31 and 03.33. Hmm...

EDIT2: It doesnt want to flash the original 2.1.17, 2.2.26, 2.2.28, too.
It only flashes The 2.3.31 and the 2.3.33.

Looks like it has an additional check.

BTW, here is a dirlist:
 Datenträger in Laufwerk G: ist SANSA FUZE
 Volumeseriennummer: 0CF5-6F32

 Verzeichnis von G:\

01.01.1980  00:00    <DIR>          MUSIC
01.01.1980  00:00               320 SYS_CONF.SYS
01.01.1980  00:00    <DIR>          RECORD
01.01.1980  00:00    <DIR>          AUDIBLE
01.01.1980  00:00    <DIR>          PHOTO
01.01.1980  00:00    <DIR>          VIDEO
01.01.1980  00:00    <DIR>          PODCASTS
01.01.1980  00:00    <DIR>          AUDIOBOOKS
01.01.1980  00:00            51.237 RES_INFO.SYS
01.01.1980  00:00                83 version.sdk
01.01.1980  00:00             7.800 VIDEO_BM.SYS
01.01.1980  00:00               114 DID.bin
01.01.1980  00:00         1.862.468 MTABLE.SYS
               6 Datei(en),      1.922.022 Bytes
               7 Verzeichnis(se),  7.675.346.944 Bytes frei

Any new file maybe?



BR and thanks in advance
Robert


From the Release Notes of 02.03.31
*Max volume level is lowered in Normal volume setting to comply with new European Union requirement

I guess this maybe the reason that Sandisk prevent units with newer OF flash to older firmware.
Not sure if this applies to all units or European units only.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Vague Rant on May 31, 2010, 10:31:33 AM
I guess this maybe the reason that Sandisk prevent units with newer OF flash to older firmware.
Not sure if this applies to all units or European units only.

Don't have a Fuze to verify, but do have a Clip+ which is practically the same thing; as far as I know the C+ is identical worldwide and the only region difference is selectable in software: after updating, the Clip+ asks for your region and I believe this impacts the FM range but more importantly, whether the volume limit is enabled (this of course means that it's probably ideal to choose America, etc. regardless of your real locale).

If that's the reasoning for blocking off updates, it seems fairly silly since the volume limit is circumvented so easily.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: csavery on May 31, 2010, 01:39:13 PM
If that's the reasoning for blocking off updates, it seems fairly silly since the volume limit is circumvented so easily.
Ya, I doubt this is the reason. It's more likely related to either liability or business deals. Perhaps they need to make sure that SlotRadio (which I have zero interest in) is not bypassed since they may have contracts that require all units sold can use it.

I think it's only a matter of time before this is worked out. We probably need to start thinking of new units as Fuze v3. Since the 02.3.33 OF works fine in older units it seems to imply a possible hardware ID or change that is detected and used for basis of behavior. I was able to downgrade on my unit without problem.

Also I still haven't heard whether users that cannot install RB have tried with different Region settings? I usually use "Rest of World" - which has no SlotRadio anyway. If the restriction is related to that then perhaps that is enough to allow upgrading.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 31, 2010, 04:28:04 PM
as far as I know the C+ is identical worldwide and the only region difference is selectable in software

there might different hardware revisions:
1 have 2 clipv1 which have "M300 VER1.5" on the PCB, and 2 fuzev1 which say "FUZE REV_1.2" and "FUZE REV_1.41"



I bricked my fuzev1 and fuzev2 today doing something stupid, but good news follow:

I could unbrick the fuzev2 (back to business), the fuzev1 (although the OF won't start), and an old clipv1 I had bricked one year+ ago (although the battery doesn't seem to charge).

I'll see if I can have the fuzev1 and clipv1 working fully and I'll update the wiki pages with what I did.

Basically it's the e200v2 method, except the pins to short are at a different location (always close to the bottom left corner of the NAND, on either side of the PCB).

I only had to unmount the front covers, no need to unscrew the PCB or unplug the screen, only the fuze button board.

Opening the devices is still required, so not a user-friendly unbrick method.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: HorizonGrey on May 31, 2010, 05:18:31 PM
Just rockbox'd my fuze v2 serial BI0903BLAK-8GB, works great thanks everyone for the hard work. I have patiently waited for this to be completed and not disappointed!
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: id on May 31, 2010, 05:39:31 PM
Something weird just happened with my Fuze v2. I compiled a Rockbox from source ( Version: r26433-100531 ) and installed it.
Then I wanted to test USB charging mode so I pressed left button and pluged the USB.
Since I've done that everything is off and it's not responding to anything.
I tried holding power button for a whole minute, I tried plugging it in and out from USB. Nothing works and nothing shows up in dmesg.

Has anyone any idea what happened to my Fuze ?
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 31, 2010, 05:57:43 PM
have a look at this post (http://www.anythingbutipod.com/forum/showpost.php?p=474553&postcount=5)
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on May 31, 2010, 06:36:01 PM
there could be a bug in USB detection but it's not clear what happens there (or if there is any bug at all)

btw, to prevent rebooting you have to press center button.

left button is the one to press when you power up with the power button and want to boot OF

I could unbrick the fuzev2 (back to business), the fuzev1 (although the OF won't start), and an old clipv1 I had bricked one year+ ago (although the battery doesn't seem to charge).

I'll see if I can have the fuzev1 and clipv1 working fully and I'll update the wiki pages with what I did.

I created SansaAMSUnbrick (http://www.rockbox.org/wiki/SansaAMSUnbrick).
If you find spelling errors or want to clarify the wording, feel free ^^

I had to copy the whole reserved part from another Fuzev1 to have the OF work on this one.

The bootloader r20603 came with it and it seems it's much faster than the v1 bootloader - perhaps something to come in the next days.

The Clipv1 works fine except I had removed the jack from it to make a longer jack cable.

I soldered the jack from another PCB but now I have a lot of noise in the phones.

Also the battery doesn't seem to charge (in the OF or rockbox).

When I boot rockbox and plug USB the voltage readout decreases to ~3.0V and rockbox battery debug says charger absent / discharging, although the charger icon is shown in the status bar.



bertrik tried to find the pins on c200v2 without luck so far and JDGordon will try on Clip+.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: lazy on June 01, 2010, 12:35:37 AM
for some reason, my clip+ stopped charging via usb via rockbox at ~68%
using the build r26441 i think (whatever was on the site 3 days ago)

tired replugging, didnt do anything, booted back to original firmware to charge it now
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on June 01, 2010, 01:14:08 AM
Check the battery debug menu so you can give more info with your report
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: lazy on June 01, 2010, 10:41:17 AM
i just fully charged it via OF
should i let it drain, then do the debug?
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Xanikseo on June 01, 2010, 04:01:56 PM
This is gonna sound trivial compared to bricked fuzes and bootloader-patched-fws not working, but the backlight doesn't fade in smoothly anymore on the fuzev2 :P. It kinda switches on, off and on again, without really fading in nicely. This has been going on for a few days I reckon... Sorry I didn't report this earlier
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Vague Rant on June 01, 2010, 04:31:55 PM
i just fully charged it via OF
should i let it drain, then do the debug?

As a general rule, it's probably most practical to debug any problems you're having while you're having them rather than after the event. Not saying this wouldn't provide any useful information, but would most likely have been more helpful during the issue.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: mbr on June 02, 2010, 05:45:07 AM
Quote
  • Open a working OF file in an hex editor and swap 2 characters
  • The characters must be distant of a multiple of 4 bytes, because the checksum is calculated as a sum of 32bits numbers
  • For example swap a character at position N and position N+4, the firmware will be different but the checksum will be the same
  • At position 0x38090 (outside the firmware block, in the "drmndt_pers" library block) there is the string "http://go.microsoft.com/fwlink/?LinkId=28745", make that be ":ttph//go.microsoft.com/fwlink/?LinkId=28745" (h and : swapped)
  • Try to patch that OF, see if it works (I don't know how to display this string, it must be related to WMA drm)
  • At position 0x216d9 (inside firmware block), there is the string "Hiphop", make that "oiphHp", see if the OF can be patched

I just bought a Sansa Fuze. It has the serial number BI 1004 CAHK - 8GB. It is not possible to install a patched 2.3.31 firmware with rockbox bootloader.

But I modified the 2.3.31 firmware with a hex editor (HipHop->oiphHp). The modified firmware installs without any problem.

[EDIT]
Additionally modified "http://" to ":ttph//". Update also flawless. It seems that at last the checksum didn't change.
[/EDIT]
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Rob2222 on June 02, 2010, 08:27:38 AM
I didnt had the time for report yet,
but I had the same results as MBR. Hex-Edited firmware he accepts.

Also updated my stats post about this issue:
http://forums.rockbox.org/index.php?topic=14064.msg167599#msg167599

(I will keep this post updated when I get new information for now)

BR Robert
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: lazy on June 02, 2010, 09:58:25 AM
i'm charging it now, how do i get to the debug menu while it's charging, i have no access to anything while it's charging
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: saratoga on June 02, 2010, 10:07:59 AM
i'm charging it now, how do i get to the debug menu while it's charging, i have no access to anything while it's charging

Are you charging in the OF?  If so, you should probably be charging in rockbox so you have access to rockbox menus.  Hold center while you plugin the USB cable to charge in rockbox (see the manual).
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Xanikseo on June 02, 2010, 10:24:44 AM
OK so these "fuzev3"s (okok fuzev2s) obviously calculate the checksums and make sure they match with known values. This begs the question: how will it accept new fws released by sansa, since it can't know the md5sums before they are released? Maybe if we change the version number reported by fuzpa.bin to 02.03.35 or something, it would accept the fw, since it checking the md5sum of an unreleased fw should be pointless (I'm hoping sansa had some sense)?

Or maybe Sansa aren't planning to release anymore fw updates.... Which would be disappointing.

EDIT: Rob2222: I also have a BI  0901 BKHK-8GB, and can flash whatever I want.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: lazy on June 02, 2010, 10:41:33 AM
i just plug it in, and it boots to rockbox with a usb plug pic (and cant do anything else)
i just plugged it in with centre pressed and it appears to be charging and can move around

but just now, i plugged it in (with the usb plug pic) for an hour, and it didnt charge again (checked battery, was still at 1%)
the last thing i did that might have caused this is that i plugged it into a usb wall charger (from phone)
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Jennifur on June 02, 2010, 10:47:37 AM
This is gonna sound trivial compared to bricked fuzes and bootloader-patched-fws not working, but the backlight doesn't fade in smoothly anymore on the fuzev2 :P. It kinda switches on, off and on again, without really fading in nicely. This has been going on for a few days I reckon... Sorry I didn't report this earlier

Make sure Backlight Fade In and Backlight Fade out are on. Its under Settings -> General Settings -> Display -> LCD Settings
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Xanikseo on June 02, 2010, 11:00:28 AM
Backlight fade in and out are both set as yes in settings as always.

I've noticed that backlight fade in and out are fine just after you switch on. But as soon as you play a file, fade in is not smooth, even if playback is paused, and no matter what screen you are on.

Ah! I stopped playback altogether by holding down home, and fade in and out are smooth again.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Rob2222 on June 02, 2010, 11:04:50 AM
Xanikseo:
Its more probable that the new units check a flag/byte/mark in the new firmware at a specific location, that the old firmware and the RB firmware doesnt have.
Even more player has a reserved (hidden) storage area where the first half is the firmware-file-data and the second half has data, too.
In the data in the second half of the reserved space can be a difference, too.
But to see this data you have to open the unit and connect it in the "recovery" mode like found out and described by funman in the SansaAMSUnbrick (http://"http://www.rockbox.org/wiki/SansaAMSUnbrick") wiki article.

BR Robert
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Xanikseo on June 02, 2010, 11:13:18 AM
Quote from: Rob2222
Its more propable that the new units check a flag/byte/mark in the new firmware at a specific location, that the old firmware and the RB firmware doesnt have.
Even more player has a reserved (hidden) storage area where the first half is the firmware-file-data and the second half has data, too.
In the data in the second half of the reserved space can be a difference, too.
But to see this data you have to open the unit and connect it in the "recovery" mode like found out and described by funman in the SansaAMSUnbrick wiki article.
Ah ok, so the rockbox bootloader modifies the part of the fw file which the new fuzes check, or at least inserts code above the flag/byte/mark which is checked.

There was some talk a few weeks ago (http://forums.rockbox.org/index.php?topic=14064.1830) about some byte being different in the new 02.03.* fws. I take it this is related...
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: Rob2222 on June 02, 2010, 11:16:58 AM
But the "bad" fuzes accept 02.03.31 AND 02.03.33.

BR Rob
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: lazy on June 02, 2010, 12:41:35 PM
from my last post, battery is at 2%

something is definitely wrong

here is the battery debug screen
(http://img189.imageshack.us/img189/700/dsc00118vf.th.jpg) (http://img189.imageshack.us/i/dsc00118vf.jpg/)

Version: r26334-100527, seems like not the latest one
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on June 02, 2010, 12:46:40 PM
Check the 2nd screen (navigate with up & down) while charging
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: lazy on June 02, 2010, 01:14:36 PM
it appears to be charging again

i charged it from last post till now on OF, then i switched back to rockbox to check out those other debug battery screens
now, the status of the battery (from rockbox info screen) is charging

maybe i just needed to jumpstart the charging

will keep updated when the battery hits 70% charge

edit
done charging, no clue what happened before
Title: clip+ 4gb radio problem
Post by: lecky on June 04, 2010, 04:08:20 AM
Hi all,
I have sansa clip plus 4gb and rockbox build r26518M-100603 and i don't see the radio item on the main screen. On another device (clip plus 8gb) with same build there is a radio item in the menu and radio perfectly works. Do you have some ideas what can be wrong?
Thanks
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: mc2739 on June 04, 2010, 07:17:22 AM
Hi all,
I have sansa clip plus 4gb and rockbox build r26518M-100603 and i don't see the radio item on the main screen. On another device (clip plus 8gb) with same build there is a radio item in the menu and radio perfectly works. Do you have some ideas what can be wrong?
Thanks

This was also reported in the #rockbox irc channel.  It looks like there may have been a change in the radio hardware.

I believe that bertrik said he would be looking into this radio problem at devcon, which starts today.
Title: Re: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Post by: funman on June 05, 2010, 10:01:48 AM
PORT IS ALMOST FINISHED

Check the current status here (http://www.rockbox.org/wiki/SansaAMS).

If you need user support, check out the manual (http://www.rockbox.org/manual.shtml).

If you want to help with development, get in touch with us using IRC or development mailing list.