Author Topic: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2 (Read 1366584 times)

kugel. · « **Reply #690 on:** March 07, 2009, 07:24:04 AM »

Quote from: 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?

You're right. It's all SD. The datasheet has information about the AS3525 SD interface.

gerstavros · « **Reply #691 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?

funman · « **Reply #692 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

jomegatau · « **Reply #693 on:** March 09, 2009, 12:14:10 AM »

Quote from: 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?

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

FlynDice · « **Reply #694 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....

TopQuark · « **Reply #695 on:** March 11, 2009, 08:41:04 PM »

Quote from: 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.

I thought the v1 also uses AMS hardware just that it is the older version. No?

saratoga · « **Reply #696 on:** March 11, 2009, 08:58:32 PM »

Quote from: TopQuark on March 11, 2009, 08:41:04 PM

Quote from: 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.

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.

pbxy · « **Reply #697 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.

Funman already mentioned the slight changes 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

Hillshum · « **Reply #698 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

kugel. · « **Reply #699 on:** March 14, 2009, 10:57:58 PM »

Quote from: 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

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.

Hillshum · « **Reply #700 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.

FlynDice · « **Reply #701 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?

kugel. · « **Reply #702 on:** March 15, 2009, 12:57:40 AM »

Quote from: 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. 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.

FlynDice · « **Reply #703 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?

pbxy · « **Reply #704 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