HOWTO: Unbrick 'most' bricked GP2X's

Update: 7th August 2006

I got my Wiggler JTAG setup fixed and now have a working GP2X again (thanks to Jr2Swiss for the salvaged GP2X bits :)).

As I now have everything up and working again I am more then happy to offer to try and unbrick peoples GP2X's if you get stuck yourself.

I am working on a cross-platform JTAG guide to go with this (and trying to make FW 2.0 files for this guide) so expect that in a few days.

Update: 23rd July 2006

I just thought I would quickly put this note at the beginning of the guide to let people know why I have been slow replying to mails and comments about bricked GP2X's (and in some cases, not replying at all I am sorry to say). I have read all the mails and thanks for all the feedback.

Some time ago my GP2X died (not bricked, board fault) about 2 weeks after I broke my jTAG setup. This combined with no small about of personal shenanigans :( has had several effects on my GP2X stuff, it has meant that I am not able to offer to unbrick peoples GP2X's with broken bootloaders at the moment (I do apologise) and secondly as I don't have a working GP2X doing the long overdue update of this guide to firmware 2.0 has been somewhat on hold, oh and of course as some people have noticed my other projects (i.e. ScummVM) have slowed up somewhat.

All being well I will have enough saved up next month to get another GP2X and grab a BoB at the same time and I plan on updating all this guide for the latest firmware (and adding a detailed jTAG guide) as soon as I get a new unit (I have worked most of it out, just need to test it all).
At that point I will be happy to offer to unbrick GP2X's again the same way I used to (for postage and a small donation to the charity of your choice).

Regards John

---------
Original Guide
---------

If you wish to mirror this article please let me know and leave credits.
If this guide looks a little scary contact me, I am happy to unbrick peoples GP2Xs (for now).

---------

Strong Warning: (In case you don’t want to read the whole article)

Do not EVER try and flash your unit with batteries (Even with GPH updates).

I have had several reports of people making things worse as there batteries gave out half way through a flash. A full flash of the file system (gp2x_file.img) can completely drain a set of good high capacity batteries before the flash completes and just the kernel update can drain an average set.

---------

Has your shiny GP2X been subject to some abuse that it was not to happy about?
Have you been messing about with the NAND, shared libraries or some other dark area and watched it all go wrong?

Well if you have and your unit now refuses to reboot into the launcher then this guide may help you out.

All the files used in this guide are based around the GPH 1.0.1 firmware with all the updates as of 29th November 2005 applied, tested and working as well as they normally do. (I.e. eBook reader, mplayer, Music player etc.)

You probably want to keep the kernel and ROOT file system in sync with each other so future updates get applied in a consistent manor. (I.e. if you are using a firmware newer or older then 1.01 then reflash both the kernel and ROOT file system then upgrade again using GPH updates).

Before we start: Warnings!

Put a good hour aside to do this, leaving things half done is not really very clever.

You WILL need a good working SD card that the GP2X can see. FAT32 formatting on the card seems most reliable in tests.

Note: I used a 256MB SanDisk regular SD card without issues throughout. My 1GB Viking SD card also worked. MMC cards are a no-go for this task. Slower SD cards seem on the whole more reliable for this task.

You WILL need a PSU capable of running the GP2X, using batteries when flashing something as delicate as your whole NAND is a VERY bad idea. The flashing really eats batteries and they could well go flat long before a flash is done.

A serial adaptor for the GP2X is very desirable so you can monitor progress of the reflash – I would almost say essential unless you are particularly frivolous.

Note: If you have one, plug it in now and connect to your GP2X via whatever serial port you have it connected to. I use 115200, 8, n, 1, XON XOFF to connect. You will see output to your serial console as soon as your turn the unit on. If you have no serial port on your PC anymore get a cheap USB<>Serial adaptor and use that with the serial lead.

Note: http://www.toyz4boyz.co.uk/ will be selling the serial leads for the GP2X very soon if you need one, see http://www.toyz4boyz.co.uk/gp2x/hardware/serial/. Toyz4Boyz are great for GP32 bits and bobs and I know they have some cool GP2X stuff planned ;-).

Firstly: Identity how seriously your GP2X is bricked

• Does the unit boot into the GPH launcher and play movies, games, music etc.?

Yes: It’s not bricked then, why are you reading this.

No: Carry on ;-).

• Turn the unit off. Remove any batteries.

Note: Some suspect brickings are in fact caused by low batteries.

• Turn on the unit running it from a suitable PSU.

• Do you get a black screen with a GP2X logo in the middle of it?

Yes: Good, your boot loader (U-Boot) is still intact. This guide may be able to help you.

No: Drop me an e-mail or pop into #GP2XDEV on EfNet IRC and I see if I can help you further.

• Do you get a ‘loading’ screen? These are green with a GP2X logo on them and hang around while Linux is being booted?

Yes: Ok, it looks like your Linux kernel is intact. Flash the ROOT file system 1st (See: Reflashing the file system) and then only flash the kernel if you need it (i.e. your GP2X was not running 1.0.1, things are still broke etc.)

No: It looks like something may have damaged your kernel image. Try flashing this 1st (See: Reflashing the kernel) and then only flash the ROOT file system if needed.

The art of reflashing.

The GP2X’s automated SD based reflashing from the boot loader consists of 3 files that contain 3 distinct parts of the system. The combinations of these on the SD effect what happens when U-Boot tries to kick off the flash.

These are… (Linked to zipped downloads)

• gp2xboot.img – U-Boot boot loader image

This will update U-Boot, don’t use it unless you’re directed to. If U-Boot dies your GP2X is bricked well beyond what this guide will help you with and jTAG or a very friendly supplier is your only real option.

• gp2xkernel.img – The Linux kernel image

This is the RAMFS image of the Linux kernel used by the GP2X.

• gp2xfile.img – The JFFS2 ROOT file system.

This is the bulk of your NAND. This contains all the files to get the launcher going, play videos, music, games etc. – Corruption of this is by far the most common cause of bricking.

• 101files.zip – The updates to the file system from the 1.0.1 upgrade.

This is needed to restore your newly flashed ROOT file system to a fully working state. It includes updates to mplayer and some parts of the GPH launcher. The files are also in the 1.0.1 GPH upgrade but I have repackaged them to work with this guide (and more consistently work on GP2X's generally).

Reflashing the file system.

99% of brickings seem to be caused by the root file system becoming corrupt. It is hard to tell exactly what went wrong without the benefit of serial console output.

Anyway, onto restoring the file system.

• Get yourself a copy of gp2xfile.img and extract the zip to the root of an empty freshly formatted, working, SD card. Check the MD5 hash if you want to be sure the image is valid.

• Make sure your PSU and serial leads are connected and working well.

Note: Logging the serial output to a text file is a REALLY good idea.

• Turn off the GP2X if it was on and put the SD card into the GP2X.

• Turn on the GP2X and if all is well you should see output like the following on the serial port after the U-Boot initialisation strings.

“FILE UPDATE ----------------------------
reading gp2xfile.img
READ START 25165824”

Note: If you see “SD Initialize fail..” then go and start again with another SD card, U-Boot does not like your current one. You did put the SD in the GP2X didn’t you not an MMC card.

The unit may then seem to stop for a few secs then showing something similar to that below.

“Why block_cnt == 0??
Why block_cnt == 0??

25165824 bytes read
3 : g_filesize 1800000
gp2xfile.img Update 25165824 0x1804000”

• The LCD on your GP2X should now show a graphic showing a chip and indicating that the firmware is being upgraded. You are now 100% committed to seeing this to its conclusion.

• The next thing you will see on the serial console is…

“NAND write: device 0 offset 0x240000, size 0x1804000”

This is good, it tells us that the image is valid and being written to the NAND.

• Next, things get interesting. The GPH flash code is setup to keep retrying the flash until it completes successfully. This is a good thing as you are going to get lots of errors written to the serial port like these below.

“nand_write_page: Failed write, page 0x000043b4, 6275072 bytes written: ERROR

NAND write: device 0 offset 0x240000, size 0x1804000 ... nand_write_page: Failed write, page 0x00006e53, 11550720 bytes written: ERROR

NAND write: device 0 offset 0x240000, size 0x1804000 ... nand_write_page: Failed write, page 0x00006fb6, 11730944 bytes written: ERROR”

These can be safely ignored. This is normal on the GP2X and it should all reflash successfully given time.

• Go and get a coffee and settle down to watch the screen. This could take up to an hour depending on the retry rate.

• Once the flash completes successfully you will see something similar to

“NAND write: device 0 offset 0x240000, size 0x1804000 ... 25182208 bytes written: OK”

• The unit will now reboot and if all is well load Linux and then load the launcher and your back up and running.

• There is one step you really must do now unless you want to keep reflashing your GP2X and that is REMOVE the gp2xfile.img from your SD card and do not reboot the unit with it on your SD in it unless you want to reflash again.

• Lastly, if you are back into the GPH launcher get your SD card and extract the contents of 101files.zip to the root of the SD card and run '101patch.gpu' from the Utilites menu in the GPH launcher to restore the ability to play Music and Videos.
  

Congratulations on having hopefully unbricked your GP2X.
Please test it and report back.

To view a complete serial log from a successful reflash of the ROOT file system click here.
If you get a SEGFAULT in GP2XMENU when you reboot the GP2X try flashing again.
I had this happen once and I can only put it down to a bad flash.

If you still have problems continue to “Reflashing the kernel”.

Reflashing the kernel.

Reflashing the kernel is actually a fairly simple affair. If you follow the above guide for the file system but substitute gp2xfile.img (and zip) for gp2xkernel.img (and zip) you won’t go far wrong.

The kernel takes almost no time to flash, a few minutes in the worst case. Unlike the file system reflashing the gp2xkernel.img file is also deleted from the SD card as soon as Linux boots to prevent the unit being reflashed on the next reboot.

Reflashing the boot loader.

I am sure you can work out how to do it but my advice is don’t unless you know what you’re doing and have a good reason to do so. You can really badly brick your GP2X with this.

That’s all for now, please leave comments and updates.

John Willis

GP2X GPL Situation

Time for a quick comment on the GP2X GPL situation as I can see it getting out of control very soon if not checked.

This is a quick and not very well edited comment. I will clean it up during the day. It does not read well but what the hell, I got one too many snotty e-mails about the GPL today ;).

In response to numerous posts on the various GP2X boards and continuing grumbling regards GamePark Holdings release of the GP2X Linux Kernel (2.4.25 ARM derived), bootloader (U-Boot 1.0) and distribution tools (BusyBox) I thought I would take the time to put a quick post up with what is being done to resolve the situation in an amiable and responsible fashion.

With that in mind I ask people to consider what the lack of source is currently doing to personally hurt them, is the lack of the BusyBox port causing you sleepless nights, no, I did not thing so ;).

A lot of effort is going into resolving this and frankly all the shouting and stamping of feet is not going to really help. In fact it seems to be causing issues to bubble up that are not really issues.

Please, please have constructive debate, offer to help if you can but all this talk about suing GPH, injunctions and the like really has to take a step back. If you feel so personally aggrieved read and understand the GPL and the role that the owner of that source, copyright etc. plays in starting any enforcement of it.

So now for a bit of a statement of where I personally have got to regarding the source (and no, I am not the only one coaxing GPH).

Open source is really important to me and there is no way I would put a really substantial amount of time into backing the product of a GPL violator. I honestly believe this can be resolved and that GPH have full intention to comply with the licences of the components they have used to bring the GP2X to market. Just give us a little time to work things out and put fears to rest. The best way to enforce the GPL is with discussion and debate not threats.

Here is some background (my own views etc. etc.)

Also, please understand that I have nothing to gain by doing this and it is ‘on my own time’. Open2x is a project I created to work as a repository for this information and is not affiliated to MagicEyes or GPH.

Hint: I want NO more threatening e-mails; I am not tied in any way to GPH other then being a pro-active user. I am withholding nothing. I would see Open2x as proof enough of what I am trying to do.

Negotiating with MagicEyes to get them to release there full Linux Kernel source, U-Boot, distribution etc. etc. was a drawn out an delicate process including some checking of what is there IP, source review etc - This was resolved in a very agreeable fashion and I have nothing but respect for MagicEyes.
This also sets a precedent for GPH and addresses some of there nervousness (after all, they would be releasing MagicEyes source and until recently MagicEyes did not volunteer that source to non-partners, GPL aside MagicEyes provide GPH with the core chips used in the GP2X and no sane business would go out of there way to piss off there only core logic supplier, small delicate steps again).

What would GPH release?

GPH felt very pressured to get the unit out to early adopters as soon as possible with beta software on the device. This was a good thing (tm) ;-) as the device is out there and some of the things people are already working on are truly great (trust me).

The pressure on a small company to get the unit out in volume and fix up the firmware is immense and GPH/GBAX etc. have to get my thumbs up for having the balls to do it, people have put a lot on the line for this. I can testify to that.

GPH are also genuinely concerned so I am told about this possible Chinese clone unit (China, Korea and right and wrong seems a little grey these days) and view releasing the full source as giving the keys to the car away. Reassuring of GPH that this can be mitigated is going on as I write this.

One question I see a lot is what is GPH’s IP (Intellectual Property). It is actually quite simple as I see it, anything that is developed by them for the device that is not routed in a form of open source licence.

As it stands I believe this includes there launcher code, SD based DRM and USB driver code (implemented as user space apps or in silicon). Some of this may be released in time.

This does not include the Linux Kernel (currently NOT using loadable binary modules), U-Boot, BusyBox, Main Mplayer bits and GPL libraries that make up the SDK. They should be open.

The other big question is DRM, well DRM is part of the SD card standard for a start so anything with an SD slot can potentially use it, yes, this does include things like the Sharp Zaurus. DRM is there, it does not have to be used. GPH have stated publicly that they will only use the hardware DRM to protect commercial released published in conjunction with themselves. My understanding of the DRM is that it would not be a great deal of use for anything much else anyway.

GPH took the MagicEyes Linux distribution and somewhat customised this for use on the GP2X. Some of those changes are not the cleanest of hacks and GPH are working to clean up there code into a state where it is fit for release.

I feel this is fair and I for one am happy to work with them to that end. I would prefer to have GPH along for the ride rather then feeling pushed into a corner.

Trust me, if things stagnate then I will be the 1st person banging on there door but behind the scenes things are far from stagnant. In fact there going quite well.

Points of note:

The MagicEyes U-Boot source in Open2x’s CVS works on the GP2X as is, not that you want to flash to bootloader (You REALLY don’t).

The MagicEyes Linux distribution in Open2x’s CVS works on the GP2X without support for the SD/MMC hardware. You need to make a small hack to support the LCD, that is about it. Again there is not much point doing this other then an academic exercise (my reason for doing it).

John Willis