Rockbox Technical Forums

Support and General Use => Hardware => Topic started by: sss on August 20, 2010, 10:26:35 PM

Title: 32MB Fuze V1, Checksum error
Post by: sss on August 20, 2010, 10:26:35 PM
I upgraded my Fuze to 32MB of SDRAM and now when it tries to load the firmware, it says, "Bad Checksum"
(Checksum: 3A27276 Sum: 1E60F0D Length: 91B14   ;D I knew it would bite me with some sort of error with a ram upgrade)

What exactly do I need to do to compile the bootloader and firmware to work with my upgraded fuze v1?

If I also upgraded a fuze v2 in the future, would anything else need to be done (additionally)?
Title: Re: 32MB Fuze V1, Checksum error
Post by: saratoga on August 20, 2010, 10:32:53 PM
You just soldered a new memory module in place?  Are you sure its compatible? 
Title: Re: 32MB Fuze V1, Checksum error
Post by: sss on August 20, 2010, 11:03:09 PM
I am trying to find that out  ;D  It was difficult to find 512MB DIMMs of SDRAM and before I go out and try another, I would like to see if the chips I have work first. 512MB /16 chips = 32MB per chip.  With hot air, soldering is pretty easy.
Title: Re: 32MB Fuze V1, Checksum error
Post by: saratoga on August 20, 2010, 11:15:31 PM
I would find the datasheet for your chip and verify that its electrically compatible with the one you took off, then check if the logical organization of the module is different. 
Title: Re: 32MB Fuze V1, Checksum error
Post by: sss on August 20, 2010, 11:47:00 PM
Saratoga, are you saying that if I put a verified, perfect replacement on, I should be able to boot the Fuze like nothing happened and Rockbox will see the 32MB of RAM without compilation of a new firmware and bootloader??  Are you sure?
Title: Re: 32MB Fuze V1, Checksum error
Post by: saratoga on August 20, 2010, 11:50:16 PM
Saratoga, are you saying that if I put a verified, perfect replacement on, I should be able to boot the Fuze like nothing happened and Rockbox will see the 32MB of RAM without compilation of a new firmware and bootloader??  Are you sure?

Assuming you find one thats electrically compatible and organized the same as the original, it will at least boot.  Then you can work on getting the extra memory to be recognized. 
Title: Re: 32MB Fuze V1, Checksum error
Post by: sss on August 21, 2010, 12:03:06 AM
Okay, getting a replacement shipped might take some time but putting it on should be pretty quick.  What needs to be done to the bootloader and firmware source to see more ram?  Is there any part of that source that hardcodes the ram to 8MB?
Title: Re: 32MB Fuze V1, Checksum error
Post by: saratoga on August 21, 2010, 12:10:07 AM
The memory size is in the configure script, firmware/target/arm/as3525/memory-init.S, and probably some other places.  Theres no AMS target with >8MB of RAM so you'll have to dig around a bit.
Title: Re: 32MB Fuze V1, Checksum error
Post by: funman on August 21, 2010, 08:20:26 AM
You'll probably also need to change the SDRAM settings in memory_init.S

The registers are described in the datasheet (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0215e/I18702.html) for the PL172 memory controller and the settings should be provided by the SDRAM chip manufacturer.

good luck :)
Title: Re: 32MB Fuze V1, Checksum error
Post by: soap on August 21, 2010, 12:06:21 PM
Don't get me wrong, this hack is cool by default.
But may I ask why?
Title: Re: 32MB Fuze V1, Checksum error
Post by: Jennifur on August 21, 2010, 10:01:08 PM
Don't get me wrong, this hack is cool by default.
But may I ask why?


I have thought about doing something like this as well. Can't speak for anyone else, but having the extra RAM would be quite useful for buffering and being able to play GBC roms while listening to music like you can do on the Gigabeat S would be quite nice as well.
Title: Re: 32MB Fuze V1, Checksum error
Post by: sss on August 24, 2010, 01:17:47 AM
I replaced the 32MB chip (4bit) with a chip should be perfectly compatible, the 16MB HYNIX hy57V281620etp-h (16bit, and from a FON 2100).  The datasheets say these two chips are pin for pin compatible and the organization is the same as what was replaced (8MB, 16bit M12L64164A from ESMT).

I did this just to test before I bothered ordering a more ideal chip, the MT48LC32M16A2 (64MB, 16bit Micron chip).
I STILL GET THE BAD CHECKSUM ERROR:
This time the SUM value changed to "175534B"

This means the checksum takes into account the ram module.  How do I get around this?
Title: Re: 32MB Fuze V1, Checksum error
Post by: saratoga on August 24, 2010, 02:11:50 AM
This means the checksum takes into account the ram module.  How do I get around this?

The checksum just steps over the file adding the value of each word.  It does not take into account the memory size as I recall.  More likely its wrong because the memory isn't working the firmware is corrupted as soon as its loaded into RAM. 
Title: Re: 32MB Fuze V1, Checksum error
Post by: funman on August 24, 2010, 02:18:18 AM
You'll probably also need to change the SDRAM settings in memory_init.S

The registers are described in the datasheet (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0215e/I18702.html) for the PL172 memory controller and the settings should be provided by the SDRAM chip manufacturer.

good luck :)

No chance it will work if you don't modify the memory controller setup
Title: Re: 32MB Fuze V1, Checksum error
Post by: sss on August 24, 2010, 08:42:18 PM
When I came home today to try fixing the firmware and bootloader part of this, I realized the fuze would definitely not allow me to change its filesystem (with the USB cable in the device appears to do absolutely nothing, but in fact it gets into a crashed state which requires you to hold the onswitch up for 10+ seconds to reset it so it can attempt to boot again the next time).

So I cannot really boot the fuze, and I cannot connect it to my PC.

I guess the only way to do this is to get the bootloader and firmware right and install it on the fuze DIRECTLY BEFORE removing and upgrading the ram!  Since nobody is exactly sure about everything that must be changed, there is no practical way of doing this!
Other than the memory model definitions in firmware/target/arm/as3525/memory-init.S (pick one):
Code: [Select]
#define MEMORY_MODEL 0x5 (8MB)
Code: [Select]
#define MEMORY_MODEL 0x9 (16MB)
Code: [Select]
#define MEMORY_MODEL 0xD (32MB)
Code: [Select]
#define MEMORY_MODEL 0x11 (64MB)

and the "export MEMORYSIZE=XX" variable in both the firmware and bootloader makefiles (generated from the tools/configure script).  I am not exactly sure of what must be changed, and I need to be completely sure the first time because if it's done wrong, it's a toasted fuze that needs the old memory chip reattached to see the light of day again.  (Do they make 54 pin TSOP sockets so I can swap ram chips without resoldering?)

I have not yet tried the jumper based recovery mode: http://www.rockbox.org/wiki/SansaAMSUnbrick
nor am I sure if it will work or not.  I will probably solder a wires and a switch to those two pads so I can try it without worrying about my tweezers slipping and shorting something.

Is anyone else familiar with memory upgrades on rockbocked players?  Any other tips or pointers?
(thanks for the helpful input so far,  the PL172 datasheet is a bit of a labyrinth to steer through)
Title: Re: 32MB Fuze V1, Checksum error
Post by: funman on August 25, 2010, 07:18:51 AM
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.
Title: Re: 32MB Fuze V1, Checksum error
Post by: sss on August 25, 2010, 10:36:58 AM
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?
Title: Re: 32MB Fuze V1, Checksum error
Post by: funman on August 25, 2010, 01:59:32 PM
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?
Title: Re: 32MB Fuze V1, Checksum error
Post by: sss on August 25, 2010, 10:09:26 PM
Here is a photo of the modded fuze (currently 16MB)
(http://picskip.net/u/26084996.jpg)
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)!
Title: Re: 32MB Fuze V1, Checksum error
Post by: funman on August 26, 2010, 08:25:15 AM
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
Title: Re: 32MB Fuze V1, Checksum error
Post by: sss on August 30, 2010, 12:13:36 AM
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.
Quote
The bootloader needs to use the SDRAM since we added USB support, because else it wouldn't fit in the 320kB IRAM.
Quote
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.
Title: Re: 32MB Fuze V1, Checksum error
Post by: saratoga on August 30, 2010, 01:41:44 AM
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.
Title: Re: 32MB Fuze V1, Checksum error
Post by: sss on August 30, 2010, 08:51:39 AM
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).
Title: Re: 32MB Fuze V1, Checksum error
Post by: funman on August 30, 2010, 09:18:41 AM
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:

Another option would be to unsolder the NAND flash and change the content yourself with a separate controller
Title: Re: 32MB Fuze V1, Checksum error
Post by: sss on August 30, 2010, 04:39:19 PM
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).
Title: Re: 32MB Fuze V1, Checksum error
Post by: funman on August 30, 2010, 05:00:37 PM
IIUC the JTAG pins are left to the battery wires (pic) (http://www.rockbox.org/wiki/pub/Main/SansaAMSUnbrick/fuzev1-recovery.jpg)

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.
Title: Re: 32MB Fuze V1, Checksum error
Post by: sss on August 30, 2010, 05:46:13 PM
If that is the case, I probably should have started with JTAG  ;D
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?
Title: Re: 32MB Fuze V1, Checksum error
Post by: funman on August 30, 2010, 06:36:31 PM
It's the "HOME" button  ;D

You don't have the case anymore?  ;)
Title: Re: 32MB Fuze V1, Checksum error
Post by: sss on August 30, 2010, 08:16:45 PM
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 :P  It's the only button on the front like that!
Title: Re: 32MB Fuze V1, Checksum error
Post by: sss on September 14, 2010, 05:00:42 PM
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.

(http://i54.tinypic.com/de2t5k.jpg)
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.
(http://i52.tinypic.com/14bnqip.jpg)

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?
Title: Re: 32MB Fuze V1, Checksum error
Post by: ranma on September 15, 2010, 04:31:03 AM
I've only used openocd for JTAG so far, but it worked well for me (using a FT2232 board for the JTAG interface).  What kind of parallel JTAG interface did you get? Is it 3V compatible?
For openocd something like http://www.rockbox.org/wiki/pub/Main/SansaAMSJTAG/openocd.cfg
should work, but you'll have to change the interface settings to those required for your parallel interface.

Also, usually if you upgrade the RAM with one of bigger size it generally should work with the old rams settings (but you don't get the bigger size until you've switched to updated settings). If you get checksum errors that's an indication that maybe the ram isn't compatible after all or you've got some bad soldering joints.

For example, on my WRT54GL I replaced the original 16MB ram chip with a compatible 64MB ram chip and it will boot just fine (though in 16MB mode) directly after the upgrade, with the old ram settings.  Then, after flashing the new settings and rebooting I had 64MB of ram.
Title: Re: 32MB Fuze V1, Checksum error
Post by: sss on September 15, 2010, 10:44:08 AM
The JTAG cable is the one from this auction: http://cgi.ebay.com/PC-JTAG-Programmer-Adapter-Debugger-w-JTAG-Cable-New-/250637375168?pt=LH_DefaultDomain_0&hash=item3a5b26d6c0 .  It is supposed to adapt to the target voltage.

Regarding the settings here: http://www.rockbox.org/wiki/pub/Main/SansaAMSJTAG/openocd.cfg , I found those yesterday and tried them in openocd for linux (debian version from repository). Here is my config:
Code: [Select]
telnet_port 4444
gdb_port 3333

interface parport
parport_port 0
parport_cable arm-jtag #have already tried wiggler and wiggler_ntrst_inverted settings here
jtag_khz 6000
##use combined on interfaces or targets that can't set TRST/SRST separately <-Tried the below setting, didn't seem to help
#reset_config trst_and_srst srst_pulls_trst

jtag_ntrst_delay 100

set _CHIPNAME as3525
set _ENDIAN little
set _CPUTAPID 0x00922f0f

jtag newtap $_CHIPNAME cpu -irlen 4 -expected-id $_CPUTAPID
set _TARGETNAME $_CHIPNAME.cpu
target create $_TARGETNAME arm920t -endian $_ENDIAN -chain-position $_TARGETNAME -variant arm920t
$_TARGETNAME configure -work-area-phys 0x200000 -work-area-size 0x4000 -work-area-backup 1
Title: Re: 32MB Fuze V1, Checksum error
Post by: ranma on September 15, 2010, 04:03:22 PM
The JTAG cable is the one from this auction: http://cgi.ebay.com/PC-JTAG-Programmer-Adapter-Debugger-w-JTAG-Cable-New-/250637375168?pt=LH_DefaultDomain_0&hash=item3a5b26d6c0 .  It is supposed to adapt to the target voltage.

Hmm, judging from the picture it's just using a 74hc244 octal tri-state line driver/buffer, which is not a proper level-shifter AFAICS.
It may still work though...

Regarding the settings here: http://www.rockbox.org/wiki/pub/Main/SansaAMSJTAG/openocd.cfg , I found those yesterday and tried them in openocd for linux (debian version from repository). Here is my config:
Code: [Select]
interface parport
parport_port 0
parport_cable arm-jtag #have already tried wiggler and wiggler_ntrst_inverted settings here

The question here is, was there accompanying documentation of the jtag signal to parallel port pin mapping?
If you're unlucky you'll have to edit the openocd source to add the specific mapping and recompile...
Title: Re: 32MB Fuze V1, Checksum error
Post by: sss on September 15, 2010, 07:52:14 PM
Hmm, judging from the picture it's just using a 74hc244 octal tri-state line driver/buffer, which is not a proper level-shifter AFAICS.
It may still work though...

I noticed the simple design and figured it was just another instance of the Chinese using common chips in unusual ways to fit needs.  They do that a lot.  Reminds me of the Chinese flashlights that use more LEDs to make up for a lack of proper current regulation.
Title: Re: 32MB Fuze V1, Checksum error
Post by: ranma on September 16, 2010, 11:47:51 AM
BTW, comparing
http://www.frozeneskimo.com/electronics/wp-content/uploads/Schematics/jtagwigglersch.png
and the pic in the auction you linked to I'd say your interface is most likely wiggler compatible.
Title: Re: 32MB Fuze V1, Checksum error
Post by: sss on September 16, 2010, 04:47:16 PM
That's what I figured.

I might try swapping the #2 and #5 wires around (relative to the fuze), those are nTRST and TCK.  The reason being that the clip+ has a similar eight pin jtag connection with those two pins in opposite positions.  I read somewhere that nTRST isn't even important with arm and that it could simply be left disconnected.

In the meantime I am waiting for another fuze (it's in the mail) I ordered that's almost totally scrap.  I plan on (gently) pulling off the ram module under hot air, cleaning the module and the pads completely (so they are nice and even), and then swapping between one of my good 32MB chips and the old 8MB ESMT chip WITHOUT soldering them to the board.  Light pressure should be enough to keep sufficient electrical contact.

Some of the rest of my fuzes, although sold as "junk", I have managed to repair and they are working fine so I don't want to toy with those yet.  My original fuze is still attached to a jtag cable and I don't want to disturb it much, small wires tend to break off if agitated enough.
Title: Re: 32MB Fuze V1, Checksum error
Post by: ranma on September 17, 2010, 07:10:11 AM
That's what I figured.

I might try swapping the #2 and #5 wires around (relative to the fuze), those are nTRST and TCK.  The reason being that the clip+ has a similar eight pin jtag connection with those two pins in opposite positions.  I read somewhere that nTRST isn't even important with arm and that it could simply be left disconnected.

Well, it's important enough. :)
It should be at least pulled up, since the device has an internal weak pulldown and a low-level on nTRST means 'reset the JTAG state-machine', so you won't get anywhere while it's low...

In the meantime I am waiting for another fuze (it's in the mail) I ordered that's almost totally scrap.  I plan on (gently) pulling off the ram module under hot air, cleaning the module and the pads completely (so they are nice and even), and then swapping between one of my good 32MB chips and the old 8MB ESMT chip WITHOUT soldering them to the board.  Light pressure should be enough to keep sufficient electrical contact.

That would be a neat feat to pull off. :)
I think you can also buy TSOP sockets, but those ain't cheap.

You can figure out the JTAG pinout manually, you just need a debounced switch for manual clocking and some inverters and leds to monitor the pad logic level.
You already know Gnd and Vcc.
Then choose one pin as TRST,  one as TCK.
Use the remaining pins as TMS (use a resistor to drive them so you can still see if the device tries to use one of them as TDO and drive out the result).
Set TRST high.  Set TMS high and clock a few times (IIRC 5?) until you are sure to have reached the test logic reset state.
Clock in TMS 0 1 0 0 (and leave at 0).
Then you should be in the 'shift DR' state.
Send clocks until one of the 'TMS' pins starts toggling (TDO).
If no pin starts toggling you have chosen the wrong pins for TRST and TCK, repeat with a different pin combination.

If you succeeded you know now TRST, TCK and TDO, finding out TMS and TDI should be pretty easy now.

That's how I figured out the pinout on my C200v2.

Your player may also have SRST pad on the JTAG connector, you can find that one using one of the working fuzes.
If pulling one of the pins low using a 10K resistor resets the device then that's SRST.
Title: Re: 32MB Fuze V1, Checksum error
Post by: sss on September 17, 2010, 02:23:47 PM
Before I do anything else, I'm going to try pulling up nTRST with a 10 or 15kohm resistor and giving jtag another go the way it is.  I read about another rockbox user needing to do this with his sansa (forget which model), but at the time I thought he did it to address a flaw in the design of the wiggler he assembled to connect with.  Now that I am hearing this again I think it's worth a shot.  By the way, the scrap fuze I ordered came, but it's a V2 and it doesn't have any external ram  >:(.  Nice to have a spare V2 for testing but not what I was looking for at the moment.  I am going to stick with only 2GB fuzes in the future since most of those seem to be V1s.  I might still try the memory swap test I was planning on doing but I'll have to do it on one of my fully functional V1 fuzes.
Title: Re: 32MB Fuze V1, Checksum error
Post by: sss on October 07, 2010, 06:15:34 PM
SUCCESS  ;D  Got back to this project after finishing several other affairs and getting a new bus pirate to JTAG with.
Posted my JTAG findings in the Wiki here: http://www.rockbox.org/wiki/SansaAMSJTAG

I was having poor luck with my cheap parallel interface so I upgraded to something more useful and I do not regret it!


Now that I have JTAG working, I'm wondering what commands I need to enter to get the registers set correctly so that the extra ram can be properly used (?)
Title: Re: 32MB Fuze V1, Checksum error
Post by: sss on October 20, 2010, 04:51:34 AM
I also succeeded in upgrading the player memory  ;D
I will post photos when I get a chance.

Most of the posters were right (so was my initial intuition).  So long as the ram is compatible, there is no need to mess with any settings (at least to get the player running).  Recognizing the additional ram of course does require special firmware settings.

Here's what happened:

*Got sick of waiting for a few extra semi-broken players to test (USPS lost my damn package), modded another working V1 fuze and somehow it became completely non-working despite doing a perfect soldering job.  Heat must have killed some unusually sensitive component, not worth my time figuring out which one (CPU?)
*Went back to the fuze I had connected to JTAG wires.  Took those off since they were in the way (lot of work for nothing but now we have the Fuze JTAG pinout).  Fluxed the ram chip again, went over my joints another time and NOW the thing boots!  :o  Apparently there was in fact a bad joint somewhere I had long overlooked.  I couldn't believe it.

Well it was fun, I have a bunch of extra chips so I will get to work on whipping up a few 32MB fuzes out of what I have left and what I can find.
I have a few friends who wanted one, so after I'm done with those, I will put together a handful for rockbox users who've always wanted a 32MB fuze!

Sorry this project took so long!  I had a few other priorities and I really stuck this on the back burner for quite a while!  Had I known for a fact it was just a bad joint all along, I would have gotten on this a lot sooner.
Title: Re: 32MB Fuze V1, Checksum error
Post by: gevaerts on October 20, 2010, 08:17:47 AM
Congratulations! Now go for the 64MB Fuze! ;)
Title: Re: 32MB Fuze V1, Checksum error
Post by: sss on October 20, 2010, 09:36:48 PM
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://i56.tinypic.com/4hs092.jpg
(http://i55.tinypic.com/15of4uc.jpg)
http://i55.tinypic.com/15of4uc.jpg
(http://i55.tinypic.com/rk27ht.jpg)
http://i55.tinypic.com/rk27ht.jpg
(http://i53.tinypic.com/10rijyx.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: [Select]
#define MEMORY_MODEL 0x5 (8MB)
Code: [Select]
#define MEMORY_MODEL 0x9 (16MB)
Code: [Select]
#define MEMORY_MODEL 0xD (32MB)
Code: [Select]
#define MEMORY_MODEL 0x11 (64MB)

and the "export MEMORYSIZE=XX" variable in both the firmware and bootloader makefiles (generated from the tools/configure script).

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.

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: [Select]
ldr     r1, =DRAM_ORIG+(0x2300*MEM)to
Code: [Select]
ldr     r1, =DRAM_ORIG+(0x2300*16)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...
Title: Re: 32MB Fuze V1, Checksum error
Post by: sss on October 25, 2010, 02:37:37 AM
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!