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

[sucitrams]

OK my Sansa is now working too.
I had to dd the original firmware (which is only 15MB in Size and not 30MB like the one dumped from Flash). I don't know why the NAND dump Firmware is always 30MB in Size, when you could also install the 15MB Firmware directly onto NAND.
But it seems, that my NAND has some bad sectors. Everytime at 14MB dd stops working, and said that there's no space left.
So I had to a "dd if=firmware of=/dev/sdb bs=512 count=27000", because Data will be only written, if dd don't break, because of IO Errors etc.
Then the Sansa started normally, but the fonts were missing. So i connected it to USB, copied the original Firmware onto the Sansa and installed it.
After that everything is fine (But I think  my Sansa's life is over, because of defect sectors).


I noticed, that if the NAND (seems) to be empty and you connect the Sansa to PC the "hidden" in my case 1024MB Partition will be active. So you could copy a firmware file directly onto NAND, without bridging the 2 Pins.

[fragilematter]

The same thing happened to me today while trying to recover from the last flash test. When I connected the usb the sansa acted like the pins where bridged. But then I dd-ed the whole big dump and it worked perfectly.

[atomikpunk]

It definitely confirms that the bootloader loads an "emergency" mode when it doesn't find executable code in the flash/rom/whatever. And this can be done by flashing an empty firmware using recovery mode, or by shorting some flash chip pins

The next interesting test would be to check where is located the firmware in the CPU memory map and/or how library blocks are loaded into RAM.

[saratoga]

According to the datasheet, it would have to be at 0x8000_0000 to 0x8001_FFFF (or one of its aliases), since thats the only nonvolatile memory available when the NAND is shorted. 

[funman]

Then the ROM is 128 kB, and the library blocks just can't fit.

The code to load them in RAM from the NAND is in the firmware block, and we must find it or reproduce its functionality.
When it's done no need to look in the library blocks, since we have access to the whole NAND and its FAT32 filesystem.

EDIT: I was looking in wrong places: I just found firmware/drivers/ata_flash.c which is what we need, I'll try to build it and make it fit in my firmware block.

[atomikpunk]

When it's done no need to look in the library blocks, since we have access to the whole NAND and its FAT32 filesystem.

Well it all depends on if we can grow the firmware size or if we can fit the NAND driver in the (little) space we have at the end of the firmware block... 'Cause I suspect it (the NAND driver) to be too large but that a library copy routine be small enough to fit in.

Or maybe there is something that's allows different ROM "pages" to be mapped in and out on demand?

funman: In the mail I sent you yesterday night, you should have the address of the library routine in the clip firmware, you may want to look at that...

[funman]

I was more interested by the gpio function

Now that I took a look at this function it looks like strcpy(), do I miss something ?

EDIT: sorry I was reading disassembly in thumb, and the function just branched to another offset which is strcpy, I'll disassemble it as 32 bits instructions.

[fragilematter]

I've finally managed to map GPIOB on e200v2's. It looks like this:

Code: [Select]

GPIOB_pin0  #0
GPIOB_pin1  #1
GPIOB_pin2  #0
GPIOB_pin3  #0
GPIOB_pin4  power
GPIOB_pin5  #0
GPIOB_pin6  #0
GPIOB_pin7  #1

I was starting to think there was something wrong with the way I tested, because I didn't find any buttons by now, but it seems that it's OK. I'll post the rest of the GPIOs when I'll finish testing.

Edit:

Code: [Select]

GPIOC_pin0  #1
GPIOC_pin1  #0
GPIOC_pin2  #1
GPIOC_pin3  #1
GPIOC_pin4  #1
GPIOC_pin5  #1
GPIOC_pin6  #1
GPIOC_pin7  #0

The GPIOs that are !=0 are consistent with the ones identified as DBOP (LCD display) in the M200 V2 version 4.1.8a firmware analysis from the wiki (http://www.rockbox.org/twiki/bin/view/Main/SansaV2Firmware#GPIOs_Usage).

Edit2:

Code: [Select]

GPIOD_pin0  #1
GPIOD_pin1  #1
GPIOD_pin2  #1
GPIOD_pin3  #1
GPIOD_pin4  #1
GPIOD_pin5  #0
GPIOD_pin6  #0
GPIOD_pin7  #0

It looks like the e200v2's only have the power button directly on the GPIO. Either that or my tests were flawed somehow.

[funman]

Hi guys

I have found a way to extend the allowed size for the bootloader: use memory areas filled with the same word.
I quickly checked for 0x200 sized blocks, and only the Clip firmwares show 1 or 2, so you need to
verify that first.

EDIT:
I also attach a tool to check the size and location of the biggest memory area filled with the same byte, it seems there is room in every firmware

Also I attach a new version of test.S without a bug in button check: the result was stored in r2 but calling clean would modify it (luckily it didn't brick my clip)
/EDIT

We don't know if they are important for the OF, so we memset it before giving it the hand.

I attached test.S tested on Clip firmware v17, the size won is 0x3CC bytes where we can put functions, data, etc ..
Of course before doing that we have to map the RAM at 0x0 because at init only the ROM is mapped.

Note this is a bit hacky to use because you have to write separate assembly code, assemble it and merge it manually at the needed offset, and hardcode the offset/size/value in test.S ... but this will do for now.
Maybe we can modify mkamsboot/Makefile to assemble 2 different files, and look in the memory for a block large enough, then insert the value/size/address in known (by the assembly code) memory locations, like the original entry point is stored now.

By the way I'm still writing a basic driver for the NAND flash, but now I'm stuck on delays: we need to command the WE bit (write enable) and keep it high for minimum 50 ns
The interface for this bit in the AMS3525 is 4 bits which will keep it high for x+2 PCLK# cycles where x is the 4 bits value.

But I've read that the PCLK is 65Mhz, so that means keeping WE high for 17 cycles would last less 0.3 ns ..
I think we need to use a divider for the pclk, but a big divider means reduced CPU clock??

atomic punk: I have found the function which load library blocks; it takes 4 arguments: block name (string), base address, end address, size. But it was not at the same offset, maybe we are not reading the same firmware ?
I am disassembling v29 for Clip

[atomikpunk]

Ok well I guess it's time for me to write

That's a good idea funman, I like. Even though it is risky, we now have at least one valid solution. I'm pretty sure that that needs to be set back to their original value giving the OF firmware the hand because they may be variable initialization values.

As for the button detection stuff, I strongly suggest that we don't make any change to it, at least for now. We wouldn't want to brick any more device, don't we?

For the NAND driver, I would reiterate what kugel said about that task on the bug tracker (http://www.rockbox.org/tracker/task/8843). Most of the NAND driver should be there, ready for us to use.

And hmm, how come you're speaking about a 65MHz clock? Isn't the oscillator a 24MHz? Or is there a frequency multiplier circuit in the SoC?

And about that library loading routine, would you mind refreshing my memory as to its address? I have probably looked at the wrong routine as I did not put much time yet into the clip firmware. Owh, and are you sure that the RAM isn't mapped at boot? If not, there is probably a simple way to map it. There seems to be a "remap" register somewhere I just can't remember where for now, I'll read back the doc.

Great progress guys, I hope for a nice bootloader in the upcoming days or weeks

[funman]

The driver is there but the way to control the nand pins is not exactly the same, plus the driver is in C and it's too big to fit, so I try to squeeze it a bit

I saw the 65Mhz clock in the datasheet section 7.3.12.7 but didn't see a 24 Mhz clock

The routine I saw is at 0x8598, you will probably have noticed it.

About the mapping, I tried writing a value in memory (offset < 0x20000) and read it back, but the comparison failed.

The code I posted maps RAM at 0x0, it's really simple, and I just setup a stack and use it to store registers like lr in function calls, and it works fine.

So next step is to finish the nand driver and put all the (position independant) functions in a block that I can memset() before returning to the OF.

Then FAT32, and winner

[atomikpunk]

Hmm are you sure your code works

Maybe I didn't see something or what, but I see at least 2 problems (please correct me if I'm wrong): 1) You did not copy the ROM content into ram before mapping RAM at 0x00000000, and 2) you execute code from the addresses you swap in the memory map and didn't change the PC or anything before doing so. This will result in: 1) PC eventually pointing to uninitialized RAM, and while the copy process 2) PC pointing to a "copy-in-progress" memory area.

The only reason I think it works for now (and this is absolutely risky as you will see) is either: a) the RAM was previously initialized with the firmware by a "proper" load of the OF, or b) code cache is active and for whatever reason it continues to give valid code even though ROM isn't mapped anymore...

And worst of all: you should check for buttons and choose whether or not to boot custom firmware before anything else. You did changed the memory map register before that check you bad boy.

For the clock, you can clearly see it here between the SoC and the mike.

Indeed about the LoadLibrary routine. In fact I did a little more disassembly of the clip firmware and found everything I already found in the m200 firmware so I feel like home now I'll gladly share my work files if you would like to have a look.

As for the NAND driver, way to go mate.

[funman]

Hmm are you sure your code works

Maybe I didn't see something or what, but I see at least 2 problems (please correct me if I'm wrong): 1) You did not copy the ROM content into ram before mapping RAM at 0x00000000, and 2) you execute code from the addresses you swap in the memory map and didn't change the PC or anything before doing so. This will result in: 1) PC eventually pointing to uninitialized RAM, and while the copy process 2) PC pointing to a "copy-in-progress" memory area.

The only reason I think it works for now (and this is absolutely risky as you will see) is either: a) the RAM was previously initialized with the firmware by a "proper" load of the OF, or b) code cache is active and for whatever reason it continues to give valid code even though ROM isn't mapped anymore...

And worst of all: you should check for buttons and choose whether or not to boot custom firmware before anything else. You did changed the memory map register before that check you bad boy.

The code works (blinks) on my clip and on the e200 of fragilematter.

EDIT3:
I attach proof of concept of a 1st stage bootloader which will run code stored in a hardcoded location. binary is 140 bytes, and may even be reduced to 136 if we remove the possibility for our 2nd stage to return to OF so it should fit in most firmwares.
Note: this code doesn't do anything useful yet except branching to a location where no valid code is so you don't want to run it, but I confirm it works on the Clip: I wrote a BX R1 instruction in this block before branching to it and OF booted.
/EDIT3

1) Yes I don't copy the ROM into RAM, I just assumed it was preloaded and it booted fine, but we may have to copy the whole OF.

2) It's just the best solution because writing code that overwrites the location of the PC would be a bit tricky. I assume after and before the mapping of RAM, the first 128kB are exactly the same data.
Maybe the soc bootloader copy ROM content into RAM at boot ?

I have booted my clip fine after sleeping the whole night, so I'm sure the RAM didn't keep its state
Also I didn't find a way to map both the RAM and the ROM at the same time (at different locations to be able to copy from ROM to RAM)
EDIT: in fact the ROM is mapped at 0x80000000 and 0xC0000000 so we can branch to this location, enable the RAM, copy the firmware to RAM, and continue, but if we an avoid it it's better.
EDIT2: simpler solution, the RAM is mapped at 0x81000000, I attach a proof of concept which copies the whole ROM into RAM before remapping RAM to 0x0.

Finally you think it's the worst thing to change the memory map before returning to OF but I remind you this code is meant to run with a potential bricking OF, and we have to put it in the right state before returning to OF (clear the memory area where we inserted the 2nd part of our code).

I know this is dangerous and this is why I commented the functions called by this first stage : "DO NOT TOUCH"

About the NAND & clock, I will assume that the pclk is 65Mhz and loop over the code that puts WE / RE nand pins to 1 long enough to ensure the minimal delay required by ONFI spec (mode 0)
Thanks for showing me the clock on the pcb btw, I'll go to sleep less stupid tonigh ^^

[kugel.]

It was mentioned earlier in this thread, that most buttons are possibly on ADC, and not GPIO. Maybe we should also have a look at that.

BTW: My Fuze arrived, so I'll hopefully be able to help a bit. It'd be nice if I get can one of you into chat (I use pidgin, so nearly any protocol will be fine), so that I can get faster into this and be able to catch up a bit.

Edit: I'm failing to use linuxstb's amsinfo tool on the Fuze firmware. While the header is dumped without problems, the library blocks are messed up and cause a segfault. Either the tool is broken, or the Fuze firmware format differs. I fear it could be the latter one. Could you guys have a look on the fuze firmware (downloadable at Bagder's site)?

[atomikpunk]

Yes sorry I was away for the day but I wanted to tell you that I'll have a look tomorrow. Until then, good night


Edit: I looked at the fuze firmware. It looks like a valid firmware to me and with the same format as other V2. I'll give a look at amsinfo to see what the problem is But rest reassured, it IS (and its firmware IS) a v2 like all the others