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

[saratoga]

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.

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?

[kugel.]

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.

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.

[pbxy]

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).

[FlynDice]

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.

[Hillshum]

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...

[kugel.]

Re-read please. He was talking about the AS3536 datasheet. AMS published the AS3525 one.

[funman]

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?

[calv]

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...

[funman]

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 !

[Hillshum]

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?

[mc2739]

@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.

[michaelc5047]

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.

[yelped]

Hypothetical at this point.

[kugel.]

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.

[funman]

@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

weird.. !