32MB Fuze V1, Checksum error

[funman]

The bootloader needs to use the SDRAM since we added USB support, because else it wouldn't fit in the 320kB IRAM.

You can see that the .bss segment is located in "DRAM" in rockbox/firmware/target/arm/as3525/boot.lds

You can update to r27877 and use the attached patch which disables lcd scrolling (unused), and use a smaller unicode codepage table (the same than the Archos Player), so the whole bootloader with USB fits in IRAM (r27876 and r27877 are needed fixes for this patch to work)
EDIT: I had change -O into -Os in the Makefile, perhaps you'll need to do the same


Unfortunately while it gives you USB mode, that doesn't give you a way to update the bootloader itself.

It should be possible to tweak some USB device which runs a test on SDRAM but I'm not familiar with the USB code.

Also, in memory_init.S, an important part is:

    ldr     r1, =DRAM_ORIG+(0x2300*MEM)
    ldr     r1, [r1]

Which I believe "programs the SDRAM mode".
The exact address from which we read (0x2300*2 on 2MB models, 0x2300*8 on 8MB models) will program some settings of the SDRAM; but it might not necessarily be 0x2300*32 on 32MB models.

[sss]

I will work on this again this afternoon, but you said,
"Unfortunately while it gives you USB mode, that doesn't give you a way to update the bootloader itself."

How then, do I update the bootloader to be compatible with the new ram?  Isn't that necessary?

[funman]

You must of course update the bootloader while the original memory chip is in place

A bootloader file is 59K, compressed with nrv2e it is 33K (the decompressor is 168 bytes of thumb asm, and is used already in mkamsboot)

You can tweak the bootloader to make some free room for 33K (let's say 34), and modify bootloader so:

- It doesn't look for rockbox.sansa immediately but goes into USB mode (you can already do that while pressing enter button)
- On USB unplug it looks for a specific file (say boot.new), and if it's present it loads this file into a buffer, decompress it, and boot that one.

You need to use self-relocating code so when decompressing the bootloader, it doesn't get in the way of running code (look at mkamsboot/dualboot.S)

That way you could make changes to the SDRAM code and try them almost immediately (only requires a reboot and copy a file), no need to update the bootloader.

Of course when you have figured out the settings you'll need to update the bootloader to a working version but that can be achieved from rockbox (needs some custom code though)

Good luck again!

BTW do you have some pics of the mod?

[sss]

Here is a photo of the modded fuze (currently 16MB)

http://picskip.net/u/26084996.jpg

You can see I blew off two tiny resistors (402s? The real tiny ones.) near the lower left corner, and replaced them with slightly larger ones (larger dimensionally, value is the same).  I tilted one of them so I could see the larger piece contacting the small pads.  I hate those little things.  I take precautions against hot air "hurricanes" but sometimes a tiny resistor or two will sneak off.

Didn't get much of a chance to try working on the software portion today, I'll try again tomorrow.  Sorry for any undue suspense!

EDIT might be a little while until I get to work on this little project again, I will post an update when I gain more free time (and some progress)!

[funman]

The chip seems to be 2Mbit x 4banks x 16, so I think it corresponds to:
128Mb (16Mx8), 4 banks, row length = 12, column length = 10 entry in PL172 datasheet

=> MEMORY_MODEL 0x8 in memory_init.S ?

Also wild guess for the SDRAM Mode register:
0x2300 << 1 for clipv1/c200v2 , their SDRAM has row length = 11
0x2300 << 3 for fuze/e200v2, their SDRAM has row length = 13

If I identified the chip correctly on PL172 datasheet, would it be 0x2300 << 2 ? (row length = 12)

I don't know how to transform a physical address into a ROW+COLUMN address but that might be needed

[sss]

Alright, some free time opened up and I've been thinking about this again.

Funman, while I appreciate the help, there are a few things that remain unclear.

The bootloader needs to use the SDRAM since we added USB support, because else it wouldn't fit in the 320kB IRAM.

You must of course update the bootloader while the original memory chip is in place

You seem to be telling me I need to update the bootloader for any of this to work, and that it cannot be updated unless I revert back to the 8MB/64Mbit chip.  If I remove the 16MB/128Mbit chip that I have soldered on now and replace it with the original chip, I am going to leave it the way it is and start this again on a fresh fuze board (not a NIB fuze obviously).  I have already ordered a used fuze (the one I operated on here was a bit beat-up to start with) to try this mod again in case the current one becomes unworkable.  The current board has taken a lot of hot air and I'm not sure it will take much more.

I've tried the enter button USB mode trick and it failed to work.  This guide (http://www.rockbox.org/wiki/SansaAMSUnbrick) suggests I can update the bootloader-patched OF with USB by connecting jumper pads on the board but I've had no success, "sudo fdisk -l" will just hang after it has listed all of my local drives and will only finish AFTER I've unplugged the fuze from USB, without listing a device number/address for it.  Do you have any other suggestions for how to change bootloaders on my current fuze before I put the 8MB ram chip back?  Once I put that 8MB chip back on, it's staying there.  I'll try the ram swap again on another fuze.

[saratoga]

You might want to look into soldering a JTAG cable to your fuze.  That would let you not only update the bootloader without USB, but also let you manually flip bits in the memory controller.

[sss]

http://www.rockbox.org/wiki/SansaAMSJTAG

I noted JTAG in the wiki but there are no pinouts for the sansa fuze (not v1 nor v2).

[funman]

The problem is that the OF upgrade procedure uses the SDRAM.

The unbrick procedure will never work because the program is written in ROM, so I was suggesting that you use the normal upgrade procedure of the OF with mkamsboot.

If you could use JTAG it would be simpler. You "just" need to:

• Figure out the pinout for Fuze
• Be able to do micro soldering (the pins are really small)

Another option would be to unsolder the NAND flash and change the content yourself with a separate controller

[sss]

The flash chips have finer lead spacing than the ram chips.  I really don't want to be exchanging those when I don't need to.

Without a way to determine the fuze JTAG pinout, JTAG isn't much good.  Supposing we knew which pads were JTAG pads, what would I need to solder?  Are you telling me I need to tap BGA joints from the ARM chip? 

If there is no way to uncover the JTAG pinout, then perhaps the best way would be to try the mod again with the other fuze (should be coming sooner or later), making sure that the bootloader fits in IRAM and works the first time around (or else I'll need to debrick it too).

[funman]

IIUC the JTAG pins are left to the battery wires (pic)

Now you just get to find which wire is which JTAG pin, some people did that on Clip+ / e200v2 / m200v4 / c200v2 but I don't know how.

[sss]

If that is the case, I probably should have started with JTAG 
The pin order should be predictable right?  Similar to the C200v2 pin order?  I like how GND and VCC are at the ends, that's one way to be sure of the connector orientation, and two lines I can verify with an ordinary voltmeter.

By the way, I'd also like to know what that pushbutton to the right of the CPU does.  Is that a reset button?

[funman]

It's the "HOME" button 

You don't have the case anymore? 

[sss]

I didn't look at it much after I took it off, I did reconnect it (big P.I.T.A. to get the control ribbon back in due to shortness of it and the lack of clearance) to try the enter button and a few other button combinations when trying to connect by USB after replacing the chip.

I thought the home button was actually part of the control assembly, but after turning that over and taking a look, I can see that it's just a hollow plastic peg   It's the only button on the front like that!

[sss]

Over the weekend I connected the fuze to my newly received parallel JTAG interface.
It was not easy.  Not so much did it bother me about the size of the tiny pads; what did bother me was that I could not find a connector to attach to the supposed JTAG port on the fuze.  I tried a microdrive ribbon and a ZIF drive connector without success, they were too flimsy and were not meant to be soldered to boards.  I ended up using very thin wire (>32 gauge) and hand soldering each strand in place.  With steady hands, a pointy Hakko tip, and frequent applications of flux it was doable.


You'll notice that I had (temporarily) removed the red power wire going to the battery as soldering things with the power still connected is clearly a bad idea.


I tried using H-JTAG as a e200v2 user had recommended but I did not have much success.  Do any SansaAMS users out there know anything about what settings to use for a JTAG connection to this thing?