Rockbox Development > New Ports
SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
TopQuark:
--- 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.
--- End quote ---
I thought the v1 also uses AMS hardware just that it is the older version. No?
saratoga:
--- 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.
--- End quote ---
I thought the v1 also uses AMS hardware just that it is the older version. No?
--- End quote ---
They use an AMS DAC, but a PP CPU. The AMS CPU used in the V2 is actually the first AMS CPU model.
pbxy:
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:
I get the same scrollwheel issues (reverse direction etc) on my e200v2 in the OF as well as rockbox
kugel.:
--- 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
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version