Support and General Use > Hardware
32MB Fuze V1, Checksum error
gevaerts:
Congratulations! Now go for the 64MB Fuze! ;)
sss:
If you get me 64MB modules I can get you a 64MB fuze. They are rare and VERY expensive unless you find some "surplus" (and where would you get surplus 64MB SDRAM chips??)
I have a stock of proper 32MB chips so the next mods I do will use those.
My current modded player has a 16MB chip (original was only 8MB), yet even 16MB was enough to run the Doom II Community Chest III wad (one of the most massive and memory hungry level-packs I could find):
note that the rest of the memory is used by rockbox and of course that's why it doesn't show all 16MB
http://i56.tinypic.com/4hs092.jpg
http://i55.tinypic.com/15of4uc.jpg
http://i55.tinypic.com/rk27ht.jpg
http://i53.tinypic.com/10rijyx.jpg
It runs great!
Like I said (and expected) in previous posts, all I needed to change was:
--- Quote ---the memory model definitions in firmware/target/arm/as3525/memory-init.S (pick one):
--- Code: ---#define MEMORY_MODEL 0x5
--- End code ---
(8MB)
--- Code: ---#define MEMORY_MODEL 0x9
--- End code ---
(16MB)
--- Code: ---#define MEMORY_MODEL 0xD
--- End code ---
(32MB)
--- Code: ---#define MEMORY_MODEL 0x11
--- End code ---
(64MB)
and the "export MEMORYSIZE=XX" variable in both the firmware and bootloader makefiles (generated from the tools/configure script).
--- End quote ---
If you only compile and install only rockbox it will display the newly available memory BUT IT WON'T BE ABLE TO USE IT ALL. If you use beyond the 8MB boundary you would get an error and the player would crash, because the bootloader is still compiled for use with an 8MB fuze. After compiling both rockbox AND the new bootloader (BL file is fed into mkamsboot to generate new fuzea.bin) with the new makefiles and the updated memory-init.S file, I had no more of these errors and I could use as much ram as I pleased. Remember that the patched firmware must be read and applied by booting into the open firmware once.
-------------------EDIT:
After assembling a few fuzes with 32MB chips, I've found that funman was right about one thing:
--- Quote ---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.
--- End quote ---
For the 16MB fuze this did not need to be changed to work.
My 32MB fuzes were a completely different story. When testing I ended up with a totally black screen and very unresponsive fuze until I did a jumper unbrick (http://www.rockbox.org/wiki/SansaAMSUnbrick) and installed a bootloader compiled correctly (the RB firmware should be compiled right too but the bootloader is first and foremost).
I changed
--- Code: ---ldr r1, =DRAM_ORIG+(0x2300*MEM)
--- End code ---
to
--- Code: ---ldr r1, =DRAM_ORIG+(0x2300*16)
--- End code ---
and my 32MB test fuze booted fine. I tried both 32 and 8 in place of 16 just to test and my 32MB test fuze completely failed to boot (unlit black screen).
___
Update:
Although my 16MB fuze is stable, the 32MB fuzes are not. I need to tweak more settings it seems...
sss:
Just want to point out I am continuing this thread over here so you don't need to scroll through three pages of conversation: http://forums.rockbox.org/index.php?topic=26059.0
I am attempting to lead extremely thin wire under the BGA chip, reflow the solder to stick the wire to the J-5 ball, and connect the other end to the A12/pin 36 lead on the ram chip. The BGA balls do not afford a lot of wiggle room so the wire needs to be crazy thin. Damn Sandisk for not routing a trace to A12!
Navigation
[0] Message Index
[*] Previous page
Go to full version