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

[fragilematter]

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.

Now, if I'll get RB to compile we might even see a menu...

[JdGordon]

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 ).
Is this value going to be the same for all e200's? is there any way it doesn't need to be hard coded?

[mc2739]

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.

[JdGordon]

I've commited that quick fix as a temporary work around untill something better happens.

[Bagder]

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.

[kugel.]

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

[funman]

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.

[kugel.]

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!

[funman]

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

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.

[kugel.]

I set it to 8MB, as the diagnosis mode in the OF tells me

[JdGordon]

@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

[gevaerts]

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

[JdGordon]

yes, but the offset isnt inside the sd driver...
If i ask for sector 0 of drive 0 I want sector 0, not 60441

[kugel.]

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.

[funman]

@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