Rockbox Development > New Ports

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

<< < (89/386) > >>

kugel.:

--- Quote from: mc2739 on November 10, 2008, 07:55:36 AM ---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.

--- End quote ---
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: ---     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
--- End code ---

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

--- Quote ---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");
--- End quote ---

to test the whole memory.

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

Navigation

[0] Message Index

[#] Next page

[*] Previous page