Support and General Use > Hardware
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
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version