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

[kugel.]

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

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

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.

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

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.

[funman]

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!

[kugel.]

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.

[funman]

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)

[pbxy]

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.

[mc2739]

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

[sko]

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.

[FlynDice]

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.

[funman]

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 (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:

• GPIO*_AFSEL registers are not modified
• GPIOB_PIN2 is the D/C#pin
• DBOP settings are different from Clipv1 settings

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:

• bit 0 of testin is sda input
• bit 0 of testout is sda output
• bit 1 of testout is direction (set = output, unset = input)
• bit 2 of testout is scl

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

[FlynDice]

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

[Mikerman]

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
 

[Bagder]

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!

[rrwood]

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?

[saratoga]

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.

[funman]

Hello

I opened FS1#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