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

[funman]

I am still looking at how to read from the NAND.
I had a look at the AMS3525 datasheet and firmware/target/arm/ata-nand-telechips.c but I'm not sure how to do that.

So far I suppose there is no direct mapping of the NAND into memory, and we have to issue commands to the nand.
I found the register to read unbuffered data from the ram (NAFDATA), but not how to set from which address we want to read.

EDIT: in fact we have a 16 bit register from where to read / write,
so we first use the command 0x0 (READ)
then write the columns of the memory address we want to read from,
then the rows
then we use the command 0x30 (READ, part 2),
then when the nand signals us it's ready, we read from this 16 bits register.

Hint: keep the ONFI specification handy

EDIT2:
fragilematter to generate a bigger firmware, you can modify mkamsboot.c:
line 185, replace

Code: [Select]

new_paddedsize = PAD_TO_BOUNDARY(firmware_size + bootloader_size);

by

Code: [Select]

new_paddedsize = PAD_TO_BOUNDARY(firmware_size + bootloader_size) + 0x200;

[kugel.]

I just wanted to remind you guys on this task: http://www.rockbox.org/tracker/task/8843

The file contains a lot of code already (and thus information).

E.g. much of NAND driver work.

[atomikpunk]

I had an idea tonight but didn't have time to implement it yet. We said we could increase the firmware block size and use this to put some more code, but why not insert our code in a low usage library block? For example on the clip, the first library block uses 0x12270 bytes out of 0x28000 allocated library block bytes. That leave's us 0x15D90, or in decimal for humans like I think I am: 89488 bytes. I think that ~90k is more than enough to pour in a bootloader

The only catch is the fact we will need to load it into RAM before being able to actually use it, but hey, a library loading routine should be way smaller than a FAT-on-a-NAND library loading routine(s).

kugel: thanks for the reminder, I did take a look a long time ago but now it is much more pertinent

[kugel.]

I think this idea came up earler and was rejected for 2 reasons:

I'd reduce capabilities to use the OF (we don't want to destroy the OF, but rather replace it and offer dual boot)
We would boot in a state where the OF already initialized the/some hardware. Booting Rockbox in such a state would make it dependent on the OF and possibly lead to unexpected behavior.

[atomikpunk]

I'm sorry maybe I wasn't clear enough in my post. What I meant is to use "unused" library space in the firmware file (space filled up with 0xFF or DEADBEEF-padded junk) to put in our code. This wouldn't change anything in the OF since, to my (limited) knowledge, this space is simply not loaded at all by the firmware.

[kugel.]

You said "low usage", not unused. And even if there's an unused part, the second problem is still there. You want to boot into an environment prepared for another piece of software.

[atomikpunk]

Well I showed calculation of the unused space in a particular library block so I thought it was obvious I wasn't thinking about overwriting the OF code

As for the "prepared environment", I don't see why we wouldn't be able to do so, in the first or second "stage" of our bootloader

[Bagder]

As for the "prepared environment", I don't see why we wouldn't be able to do so, in the first or second "stage" of our bootloader

I agree and this is done on a few other targets with success. If we do this for a known OF version we can learn what it sets up for us and not.

And of course over time we make the Rockbox code setup things as good as possible on its own so that we get less and less reliable on the OF init.

Either way, there's nothing saying that a first "ugly" approach can't be done first to get something going and then it can be improved later on. Iterative development is the key to success.

[funman]

I don't understand in which way you want to do it:

- In the bootloader insert a call to the routine which loads library blocks in memory, and then branch to that location.
- In a studied library block, insert a branch in the same way we do it for now in OF with mkamsboot, which will branch to the code we inserted at the end (in the padding)
- Voodoo

[atomikpunk]

Ok maybe I wasn't clear at all after all, so here are my thoughts on this.

• We keep the actual code that hijacks the boot sequence
• If a particular button is pressed/held/whatever, we continue in a so-called "first stage bootloader", else we simply get back to the OF
• The first stage bootloader loads the second stage bootloader from ROM to RAM and branch to it
• The second stage reads the NAND and find the rockbox firmware
• Launch the rockbox firmware

Using this approach we don't rely at all on the OF be it for initialization or anything else because anyway, I don't think they anything we can't do!

There is a bit of development to do to get there, but nothing huge and in fact it can be quite easy and straightforward...

First stage bootloader
The first stage would be located in the firmware block, after the used part (that is after the code and the variable initialization sections). It needs to be as small as possible to fit every possible OF files. If we find out that we can increase the firmware block size, then we are in luck. If not, we may need an alternative location for that. I assume that we will a) have enough space in the OF file without modification, or b) we will be able to increase the firmware block size.

Its job is:

• Intercept a particular signal (a button or something), and if not set, boot back to the OF (its job end up here in this case)
• Find (or maybe it should already know) the second stage bootloader
• Copy it from ROM to RAM
• Jump to it

Second stage bootloader
It would be located in a library block with enough free/unused space to hold it. The best place to put it would be in the "DEADBEEF" area, which is in fact junk in the clip firmware. (reminder: each library block contains: a header, a code section, a variable initialization section, 0xFF padding up to the next 0x200 border, DEADBEEF padding up to the end of the library block). Once loaded into RAM, the first stage bootloader jumps to it.

Its job is:

• Read the NAND flash
• Locate the filesystem
• Read the filesystem and find the firmware file
• Read the firmware file into RAM
• Jump to it

[funman]

First stage bootloader[/b]
The first stage would be located in the firmware block, after the used part (that is after the code and the variable initialization sections). It needs to be as small as possible to fit every possible OF files. If we find out that we can increase the firmware block size, then we are in luck. If not, we may need an alternative location for that. I assume that we will a) have enough space in the OF file without modification, or b) we will be able to increase the firmware block size.

Its job is:

• Intercept a particular signal (a button or something), and if not set, boot back to the OF (its job end up here in this case)
• Find (or maybe it should already know) the second stage bootloader
• Copy it from ROM to RAM

At boot we suppose ROM is mapped at 0x0, and we earlier confirmed that we can not read past the firmware block (at least this not the direct continuation of the firmware file)

So we first need to extend the firmware block, and as far as I know this has never been tried.

My theory is that you simply can not read from the library blocks, because they are loaded on-demand, and no one is ever loaded forever.
If it was the case, then the code would be a part of the firmware block.

We can suppose the library blocks are relocatable (because the code use addresses to the mapping of the block in RAM; which is absolute).
But the firmware block may have absolute offsets to the library blocks, even if we don't see a cross reference into a disassembler.

I expect fragile_matter to flash an extended firmware (by 0x200, then BOOTLOADER_STAGE2_SIZE) and tell us if he still can boot the OF and use it, and tell us the results.

Last note: ROM is 1Mbit (128kB), the one I use (firmware v17) is 120kB, that's 8kB left for the bootloader, would it be enough ?

[sucitrams]

I expect fragile_matter to flash an extended firmware (by 0x200, then BOOTLOADER_STAGE2_SIZE) and tell us if he still can boot the OF and use it, and tell us the results.

I'm not fragile_matter, but I tried to extend the firmware by 0x200 simply by modifying the mkamsboot.c . Then I flashed it and was able to boot the OF, without errors etc.

This is maybe interesting: I flashed the player with the extended firmware, and plugged it back to the PC,  and the firmware file wasn't deleted, as usual.

[funman]

did the player display the message "upgrade completed" ?

also if you read the recovery partition, do you see your extended firmware, or the normal one ?

[sucitrams]

Sorry my fault. 
The extended firmware wasnt flashed. The upgrade didn't complete.

EDIT: I tried to flash the extended Firmware directly onto Flash. The player started, but the Display was full of "damaged" pixels.

EDIT2: I think its over. Everytime i try to write to flash, there are "IO errors", and only 14MB could be written.

[fragilematter]

sucitrams take care when dd-ing stuff directly not to damage the file system. On e200v2's, beyond 31,456,252 Bytes you have a fat header and the music database. Or, if you do write directly to the nand, back up the stuff you have stored on the player.

I'll be resuming almost full time on rockbox testing tomorrow afternoon (I'm still in vacation, I only have one restant exam tomorrow). Hopefully I'll be able to complete the GPIO tests by tomorrow night and also catch up on what's new here.

Edit: if you get write errors try to use a stable usb port (the ones at the back of the computer) and eventually try to use usb 1.1 (modprobe -r ehci_hcd if you don't have a machine with physical usb 1.1 ports).