GP2X Working On Jtag Flash


5465756e

Member
Joined
Dec 7, 2005
Messages
127
I have been looking into this (JTAG flash access) as there are many people with a broken ("bricked") unit at the moment. Here's what I have so far:
-All the buzz is about getting a JTAG cable, however the cable is easy to make. Dygnsys (they build the MMSP2 dev boards used by GPH) use a macraigor compatible cable (info from their website). Schematics for those are available on the web. The JTAG pinout (on the GP2X ext connector) is available from the wiki. (If it is correct.)
-So we need software. This is far more difficult as the JTAG standard only specifies the connection and a few commands, the other commands are chip specific. Unfortunately the specs are not publicly available. I do not know if the
Samsung NAND flash chip has a direct JTAG interface or if the JTAG interface is only connected to the MMSP2 which is then used to access the NAND. On the Dignsys I read that they ship their JTAG probe with GDB. (A GPLed software debugger which
can be used to communicate with some devices via JTAG.) GDB does not support flash chips, but Dignsys said the following to me in an e-mail: "The JTAGProbe is our product that sales with Wiggller Compatible hardware equipment with simple
flash upgrade tool.". I can't really draw a conclusion based on that info about which method to access the NAND is used.
-Dignsys sells their JTAG probe with software for $50,-. However the shipping from Korea is very expensive.
-I've asked GBAX when they will have a JTAG cable (and software) and whether it will be for sale, however they have not yet responded.
-On the GP2X forum I just read the following: "I just wanted to let everyone know that I have spoken with Dynamism and they are getting specifics on stocking JTAG cables. If you are looking for one, Dynamism should have them soon.".
So, I've been thinking about buying a cable from Dignsys. I will definitely do so if I break my GP2x. However I find it rather expensive to do so just to attempt to help the community. (The goal of buying one is just to check out their software part so people can (possibly) build their own cable and reflash their unit.) Also I don't want to check things with my working unit. I have not yet contacted GPH about this.
What do you think? Any new info would be very helpful.

Thanks,
Teun
 
If your serious, join #gp2xdev on efnet and hang around. We already have BDS (Boundary scan) and related source code to the MMSP2 (not the GPH version, but shouldn't take long), and are playing with jtag at the moment.
 
If there's already working code you might not need this, but has anyone seen this? It appears to be a JTAG flashing program modified for the MMSP2. Dunno if it supports the right type of NAND though.
 
I need some advice, I got a 'First Edition' that got bricked, so I sent it back to gp32z.com to get a replacement because they still had some first editions left. Mine got there a little late so if I get a replacement it won't be from the first batch. They still have my old one, so do you think it's worth it to get my bricked one back and flash it myself so I can have a first edition, or should I just get one from the second wave? Mine was bricked pretty easily, so I might want a cable just to un-brick mine if anything ever happens.

Thanx,
Stan
 
Last edited by a moderator:
I'd wait until some successfully managed to jtag a unit, as it appears that the nand is not directly accessible via jtag, so it might mean either wiggling some gpio's, or uploading code to access the nand. First way is probably the easiest, but then your talking hours for a debricker compared to minutes of the second method.

GPH's uboot isn't that stable to be honest, it seems to randomly find the upgrade files on empty SD cards - luckily it isn't often though.
 
Why not just upload U-Boot to RAM and use that to flash the NAND? Byte by byte programming over jtag would be slow indeed.
 
Probably because uboot as standard doesn't support it, and GPH's version likes to flash 2X's with complete garbage (which is what bricks them in the first place).

Much better to upload some reliable software, or overwrite GPH's hideous uboot loader with our own which will flash from SD card, as the loader area is about 16KB which should be enough for a nand flasher and sd loader. May even be able to get a HH menu in there :)
 
I don't understand why we aren't flashing ROM code in a way that prevents bricking in the first place.

For years now, there have been common practices for avoiding bricking by flashing the new ROM code along side the existing ROM code and then adding a JMP instruction to the new ROM code at the head of the "boot list".

That way, when you reboot after flashing, it executes the first JMP into the new ROM code and if the flash worked, the unit runs as expected. However if the flash failed, then the user can hold down some button combo that causes the boot code to execute the second JMP instruction in the "boot list" which jumps to the old, working, ROM code.

I have no idea why UBoot doesn't support this. You wouldn't have to have two copies of the root filesystem, just two copies of the kernel.
 
MiniMoose: uboot does support it, however: GPH also reflash uboot, and secondly, they disabled that option in the retail 2x's (to save 10th of a second on the boot time), although it's there in the dev boards.

The stupid thing is, they disable it in uboot to save 10th of a second, but the kernel they are using is bigger compressed then decompressed, and takes about 3 - 4 seconds to decompress.

A few people are working on code that replaces the uboot loader and allowing reflashing that way, so even if a future firmware reflashes uboot and bricks it, then the pre-uboot loader should still be intact. It'll hopefully support booting from SD (HH-apps), NAND (uboot/linux) and USB (HH-apps).
 
timbobsteve posted on Dec 19 2005 at 04:20 PM said:
HH-apps = ??

sry if it is something obvious.

HH maybe "hardcore homebrew" or "hardware homebrew"

basically anything that runs without, or before linux.

Usually with the purpose being best use of available resources.


On topic, Is Robster? the guy who made the GP32 unbricker?

If so, can he modify that program to unbrick a GP2X, if you guys already are working on it, let us know how it is going, a lot of people have bricks.
 
Last edited by a moderator:
I just had a brainstorm.

The new firmware upgrades from the OS, right?

If people have screwed uBoot and have an OK OS can we boot into the OS using a small program loaded over jtag instead of uBoot, once in the OS, go to the SD and update the firmware, should fix uBoot.

I might be completely nuts, but it could save a lot of time if it is just uBoot that is bad.

That way the bootstrap program might not need SD drivers, and it could just load the OS off of the internal flash.

Could it work?
 
It's possible, but I think the best route is still the "catch all", in which you can debrick regardless of what is wrong.
 
Back
Top