F-200 Differences Between Mk1 And Mk2

[noabody]

I was bored so I decided to open this topic for people to discuss the hardware of the F-200 that shipped with Firmware 4.0.0 dubbed MK1 and the F-200 that shipped with 4.0.2 (4.0.1 in the information screen) dubbed MK2.

It'll be awhile before anyone fully understands the F-200 as it is, let alone having two major hardware revisions in such a short period.

I would guess that the MK1 is already effectively dead, probably heavily based on the first development units. I would guess that the MK2 is what GPH had in mind as their production unit. I wondered if a redesign might be to cut costs. If it uses a better less expensive touch screen and streamlined PCB then maybe.

Personally I have an F-200 MK1 as of late February. I don't have the will or funds to buy another and take them apart to tinker with them until they stop working, that's not my thing. It does seem like some people rather enjoy doing that kind of stuff so this thread is for all of you tinkerers and hackers. I love reading about your exploits.

Have fun.

 

[phi6]

I was bored so I decided to open this topic for people to discuss the hardware of the F-200 that shipped with Firmware 4.0.0 dubbed MK1 and the F-200 that shipped with 4.0.2 (4.0.1 in the information screen) dubbed MK2.

It'll be awhile before anyone fully understands the F-200 as it is, let alone having two major hardware revisions in such a short period.

I would guess that the MK1 is already effectively dead, probably heavily based on the first development units. I would guess that the MK2 is what GPH had in mind as their production unit. I wondered if a redesign might be to cut costs. If it uses a better less expensive touch screen and streamlined PCB then maybe.

Personally I have an F-200 MK1 as of late February. I don't have the will or funds to buy another and take them apart to tinker with them until they stop working, that's not my thing. It does seem like some people rather enjoy doing that kind of stuff so this thread is for all of you tinkerers and hackers. I love reading about your exploits.

Have fun.

Huh?

Am I missing something here? I always thought the MK1 and MK2 were the black versions of GP2X, and the F-200 is the white version with touchscreen and button d-pad rather than joystick.

I thought there was no such thing as F-200 MK-this or MK-that, its just F-200, released in firmware 4.00 and 4.02 later.

Please correct if I'm wrong!

 

[fishybawb]

Huh?

Am I missing something here? I always thought the MK1 and MK2 were the black versions of GP2X, and the F-200 is the white version with touchscreen and button d-pad rather than joystick.

I thought there was no such thing as F-200 MK-this or MK-that, its just F-200, released in firmware 4.00 and 4.02 later.

Please correct if I'm wrong!

There is no official MK2 F200, that's just what people are saying to distingush the ones with the new LCD (shipped with 4.02?) from the original ones.

 

[ledow]

Huh?

Am I missing something here? I always thought the MK1 and MK2 were the black versions of GP2X, and the F-200 is the white version with touchscreen and button d-pad rather than joystick.

I thought there was no such thing as F-200 MK-this or MK-that, its just F-200, released in firmware 4.00 and 4.02 later.

Please correct if I'm wrong!

For a while it looked like the "new" F-200's were actually using a different screen/touch film, but I don't know whether that was conjecture or fact. I seem to remember that the idea was based on the problems with the 4.0.2 / 4.1.0 firmwares (the new F-200's all come with a newer firmware and people had problems with them). I seem to remember a comment from EvilDragon somewhere about it, but I could be wrong. It may be that it was just speculation and the hardware is no different but that in actual fact the latest firmware update fixes what was just a software problem. Or it may be that the new versions do use new hardware but that the new firmware is backwards-compatible and makes them all look the same to the software.

Short of someone opening up an "old" and "new" F-200, you wouldn't find out for sure.

 

[Manjuu]

According to EvilDragon, there is indeed a change in hardware.

Here is the quote for it:

Well, just compared two F200 - the new ones have a much brighter LCD with less scanlines than the old one.

So I guess the old firmware won't work because of LCD drivers.

Gonna open them up and check it out.

EDIT: Old F200 have a different Testing-Points layout on the PCB than new F200. Definately a hardware change.

EDIT2: Yep, as suspected, the new F200 have a completely different LCD!
The old one is the same as the F100 MK2 (just with a touchscreen foil in front of it) and the new one is a LG Philips LCD LB035Q02 - V0.3. Completely different layout on the frontside of the PCB.

 

[EvilDragon]

Yep. And FW4.0.0 doesn't work with those, so that will brick the unit (and gp2xrecovery doesn't work).

Besides the LCD, there's just some different board layout (testing points, etc.) which may simply be because of the new LCD.

The old LCD is basically an F100 MK2 LCD with a touchscreen tacked onto it (I fixed a broken F200 with an F100 LCD). The touchscreen has its own small ribbon cable.

The new LCD is an LCD with touchscreen built-in and only uses one ribbon cable.

 

[noabody]

I thought there was more to it than the screen since the MK1 u-boot is incompatible with the MK2. And yes, I arbitrarily used MK1 and MK2 to designate the F-200 versions. Perhaps F-200 and F-200( B ) would have been more appropriate but since all of the models say F-200( B ) I'd suggest owners make a mental note or relabel the sticker on the back or something.

It's critical anyone interested in upgrading the firmware know which one they have. The easy answer is, did it ship with FW 4.0.0 or 4.0.2 (4.0.1)? Down the road a few months if I decide to sell my GP2X I think the next owner has a right to know what version they are getting. Since my unit now has the patched 4.1.0 there's no way someone could buy it second hand and know which version it is without taking it apart.

In my simplistic way of thinking, I thought the change in video drivers really shouldn't prevent F-200 MK2 users from recovering from the bricking that occurs when flashing the 4.0.0 FW. Really, if you think about it, the GP2X is one of the few devices out there without a thorough software crosscheck to ensure the flashing process will be successful. Most manufacturers build in a great deal of safety into the process because they don't want to have to deal with it as a customer service issue. From what I can tell GPH has no customer service or return procedures.

Certainly u-boot, or more generically firmware upgrade code, should be safeguarded. The firmware upgrade code and recovery should be very low level, no hardware other than that required should be initialized. A specialized keystroke combination should be used to initiate the process and format/test NAND as required. Obviously u-boot should be stored in a protected NAND partition or space.

For example, I flashed an AMI bios motherboard with Award bios. The board was manufactured with both bios at different times. The manufacturer even provided the bios and some basic instructions. The first time I attempted to do this it failed. AMI bios had a keystroke based recovery that would load the BIOS from a floppy disk and I immediately recovered the computer. I noticed during the flashing procedure that a part of the BIOS was not erased. It was the AMI bios recovery code and I had to research the correct option to fully erase and reflash the bios. The second attempt was successful.

Maybe the difference is that this is a linux based system. The proprietary nature of the AMI bios allowed them to protect the boot region of the flash as a separate entity from the program region but you could override that and erase everything.

It almost sounds like the firmware upgrade process erases NAND and fails to write the u-boot which bricks the device. Does the linux kernel even come into play with u-boot? I would think the kernel could panic with an incorrect device driver and prevent getting to the point where the firmware could be reflashed.

It's really a shame that GPH didn't do a better job safeguarding the GP2X. I guess the "user" should inherently know not to do things that are going to brick their device.

 

[ledow]

I thought there was more to it than the screen since the MK1 u-boot is incompatible with the MK2. And yes, I arbitrarily used MK1 and MK2 to designate the F-200 versions. Perhaps F-200 and F-200( B ) would have been more appropriate but since all of the models say F-200( B ) I'd suggest owners make a mental note or relabel the sticker on the back or something.

In the absence of other identifiers, it may be better to find out at which serial number they started issuing the new screens. It's likely they are in a serial "run" of numbers from a certain starting point. Or to provide a utility that can probe the Linux /proc directories to find out what LCD it is using.

Really, if you think about it, the GP2X is one of the few devices out there without a thorough software crosscheck to ensure the flashing process will be successful. Most manufacturers build in a great deal of safety into the process because they don't want to have to deal with it as a customer service issue. From what I can tell GPH has no customer service or return procedures.

There's a certain truth to these statements. I wouldn't say that the GP2X was "one of a few", there are MANY devices that you can firmware-flash without any protection (The BT HomeHub comes to mind because people are doing drive-by flash attacks on it so that they can sniff all your traffic). But firmware updates are NOT to be taken lightly. People still just assume that they "have to" update. They don't. Any firmware can mess up ANY machine (your DSL router, your GP2X, your PC, your Sky digibox, your Wii, your printer, anything that uses firmware - I have personally witnessed at least one example of each of the above dying due to a firmware update) and then you're on your own. Support contracts won't cover BIOS-flashing generally, whether they "allow" it or not. Some manufacturers (a minority in the embedded area, actually) provide safety features such as double-ROM's and recovery processes but you are ALWAYS upgrading firmware at your own risk. Even those manufacturers will be reluctant to take back a bad-Flash'ed board.

And even on the best board, Flash CAN die halfway through a flashing process, or the power can go, or any number of problems.

Certainly u-boot, or more generically firmware upgrade code, should be safeguarded. The firmware upgrade code and recovery should be very low level, no hardware other than that required should be initialized. A specialized keystroke combination should be used to initiate the process and format/test NAND as required. Obviously u-boot should be stored in a protected NAND partition or space.

I believe all of these ideas are present in the Pandora, the GP2X's "successor-in-spirit". Basically, U-boot is made completely read-only and there is NO way to change it without interfacing directly with the hardware (JTAG etc.) The OS, no matter what it does, has no physical way to update the bootloader part of the firmware - at least that's the idea. That means that if someone finds a bug in U-boot (like, say, the ones that caused problems for people switching between new and old GP2X firmwares), then you're stuck with it. It's a good thing, overall, but it has it's pains not only in use but in development, support, repair etc.

Maybe the difference is that this is a linux based system. The proprietary nature of the AMI bios allowed them to protect the boot region of the flash as a separate entity from the program region but you could override that and erase everything.

The OS makes absolutely no difference whatsoever. BIOS functions are BIOS functions and no operating system should be playing with them. Updating firmware is done through hardware-level access no matter what OS you use, or what you boot from. You can flash under Windows, under Linux, under MacOS, under DRDOS/PCDOS (which I believe is what some BIOS update floppies use), or just have a bare "no-OS" floppy that just updates the BIOS. You can flash from anything given the right instructions -which normally consist of just throwing some data to a particular place on a particular bus, a place which is NEVER normally touched - OS's should not write to ANYTHING that they don't know.

If you can overwrite the BIOS in one OS, you can do it in all of them. It's as simple as that. Protected regions are protected in all OS but BIOS upgrades are usually not "protected", they are just a particular place for storage of data that nothing except BIOS update utilities will bother to write to. They might have certain "keys" (e.g. you have to enter your BIOS password), they might need certain sequences but they are all eraseable no matter what the OS. In fact, it's MUCH, MUCH harder to write to a BIOS in a non-mainstream OS because if a vendor-supplied utility isn't ported, it's very difficult to figure out how it's done.

Does the linux kernel even come into play with u-boot?

No. U-boot is a boot loader. It loads before any OS does (the BIOS "hands-off" to U-Boot) and then it lets you select which OS to boot. It's the equivalent of LILO, GRUB, the Windows MBR (boot menu) and similar - they all work BEFORE the OS and can theoretically boot any OS available. The main "bricking" problems come when U-boot is broken. Then NOTHING works, except a JTAG recovery.

I would think the kernel could panic with an incorrect device driver and prevent getting to the point where the firmware could be reflashed.

The GP2X flash process, as far as I can tell, is a little tiny bit shoddy, but not that much different to most BIOS practices on cheap computers. It's just done (by default) in Linux userland, but there's nothing stopping someone booting any compatible OS and repeating the same steps with the same result. It consists of writing some files with "disk images" to the NAND chip. There's no protection.

Basically, the machine starts U-Boot, which boots Linux. As part of the GP2X's Linux normal startup procedure (think AUTOEXEC.BAT) it looks on the SD card for specifically-named files. If it finds them, it copies them over the ones in NAND. There's a file for the kernel, one for U-Boot, one for the filesystem. There is no NAND protection whatsoever, it's just seen as an MTD (memory technology device, think "USB key" if you need an analogy), no matter what the OS. Therefore anything could do this same step at any time with any data but there is only ONE bit of code actually present in the GP2X that writes to this area (the boot scripts) - hence your NAND is only ever written to when you TRY to update the firmware or, theoretically, if someone performs the same step in their flash-new-GP2X-game-that-you've-run-without-checking-what-it-does - the same as ANY other modern computer or mainstream embedded system. Yes, a virus with admin access could potentially re-flash your machine and break it. This isn't news.

However, there seem to be very few integrity checks in the GP2X (which is the same for most embedded systems firmware update procedures that I've seen - everything from HP Laserjet's, Samsung network printers, expensive network switches, DSL and wireless routers etc.) and therefore there's not much you can do to check that the disk you are flashing from is intact. And if you fail halfway through (power failure, broken NAND, bad data from the SD etc.) - you can't get through the corrupt U-Boot to boot the corrupt Linux kernel from it's corrupt Linux filesystem in order to update the firmware. The same as most things that use firmware.

It's not a good design, no. But it's for a very rarely-used function (most people WON'T be updating their firmware), which is quite technical and says it's dangerous, that isn't supported anyway, and that can be recovered from with the right knowledge/hardware.

The only way to "stop" this potential corruption is to make one piece of the chain uncorruptable - the bootloader, U-Boot. (in the same way that your motherboard manufacturer has made their "recovery bootloader" uncorruptable). Which is how the Pandora safeguards it's firmware, I believe, but it means that it's then almost impossible (without doing complicated JTAG interfacing direct to the chips "below" the OS level) to change the actual real bootloader. That may or may not be a problem depending on how well you design the bootloader in the first place and what your users want to do.

In that same way, if you were to run an arbitrary program on your PC, it could update your BIOS as simply as running the "official" BIOS manufacturers restore disks... it's incredibly simple. Some BIOS have certain safeguards (e.g. you must supply the BIOS password etc.) but most of them don't and most of those that do never have the options switched on (I switch them on in the schools I work for - kids love to brick printers and computers if they can). And even with the safeguards, any user DELIBERATELY updating their BIOS is still susceptible to things going wrong - power failures, NAND failures, data being corrupted as it comes over the SD interface.

There are ways to stop it, yes, but even the early Wii's had a firmware problem which wiped out a small minority of the systems on one of the first firmware updates. The XBox did too. You name it, if it has firmware you can make it go wrong and each time you flash you cannot guarantee it will be succesful. All you can (hopefully) guarantee is that there's a good chance you'll get another shot at upgrading the firmware without having to take the thing apart. Even that isn't a guarantee that you'll still be able to apply a full, working firmware to the machine from that point onwards (i.e. if your NAND chip is totally broken then it won't take the new firmware and you're machine will never boot anything other than the bootloader itself).

It's really a shame that GPH didn't do a better job safeguarding the GP2X. I guess the "user" should inherently know not to do things that are going to brick their device.

We got to the crux of the matter eventually, then.

 

[EvilDragon]

I believe all of these ideas are present in the Pandora, the GP2X's "successor-in-spirit". Basically, U-boot is made completely read-only and there is NO way to change it without interfacing directly with the hardware (JTAG etc.) The OS, no matter what it does, has no physical way to update the bootloader part of the firmware - at least that's the idea. That means that if someone finds a bug in U-boot (like, say, the ones that caused problems for people switching between new and old GP2X firmwares), then you're stuck with it. It's a good thing, overall, but it has it's pains not only in use but in development, support, repair etc.

Not exactly - there's a MINIMAL Readonly U-Boot in the Unit which allows the user to reflash.
However, that's just a recovery bootloader, the normal bootloader can be flashed and updated.
But if the flashing fails, using the minimal bootloader you can recover easily.
(and you can't have that many bugs in such a minimal bootloader).

 

[Orkie]

The GP2X flash process, as far as I can tell, is a little tiny bit shoddy, but not that much different to most BIOS practices on cheap computers. It's just done (by default) in Linux userland, but there's nothing stopping someone booting any compatible OS and repeating the same steps with the same result. It consists of writing some files with "disk images" to the NAND chip. There's no protection.

Basically, the machine starts U-Boot, which boots Linux. As part of the GP2X's Linux normal startup procedure (think AUTOEXEC.BAT) it looks on the SD card for specifically-named files. If it finds them, it copies them over the ones in NAND. There's a file for the kernel, one for U-Boot, one for the filesystem. There is no NAND protection whatsoever, it's just seen as an MTD (memory technology device, think "USB key" if you need an analogy), no matter what the OS.

What a padded out post . Flashing mostly takes place in the GP2X bootloader. When you turn on the machine, u-boot checks to see if you are holding start+select. If you are, it inits the SD card and looks for gp2xboot.img (and flashes it if it is found). Regardless of whether that file is found, it moves onto the next bit which is either gp2xyaffs.img, the boot sound or gp2xkernel.img (I can't remember the order). There is no 'protection' as such, but there is error correction so in theory it should never flash half an image.

gp2xyaffs.img is expanded onto the equivalent of /dev/mtd/3 and contains a minimal filesystem which looks for a /mnt/sd/gp2xfs.tar.gz and extracts that to /. It then creates (if one doesn't already exist) a loopback image to use as the user portion of the NAND (I don't quite know why they did this, but they did nevertheless) and fills it with the contents of gp2xnand.tar.gz. It is however very possible to create a custom gp2xyaffs.img with everything in to save any kind of user-mode installation (but it takes a long time to expand big images and the u-boot error correction code is rubbish and tends to mess things up).

It is possible to lock certain mtd devices so they become read-only through the kernel, and GPH really should've done this for /dev/mtd/1 so nobody could write to the bootloader accidentally. If I remember, I'll be doing this with Open2x .

 

[ledow]

Flashing mostly takes place in the GP2X bootloader.

I think you're partly wrong here, but it doesn't really matter. For instance, just telnet into a GP2X and read the init scripts in order - one of them runs a script in (I think) /usr/gp2x/ which does exactly what you describe - checks for the presence of the files on SD and copies them over to the NAND, extracting them as necessary etc. Without a GP2X to hand, I can't double-check the details, and it may be just the filesystem update, and the bootloader/kernel may well be installed the way you describe. But the principal is the same, it's just where it happens that differs... which proves the point about it not mattering what loads because anything can change the NAND if it wants - the bootloader, a root-owned script within the Linux filesystem etc...

The essence of my post is true, even if the exact technical details are not.

EvilDragon, I wasn't aware of the Pandora's particular technique, though, just that there was a "better" method, so thanks for clearing that up. It seems that you chain bootloaders, then, with a mini-loader that's fixed (and therefore always provides a "get-out-of-jail card"), and a "real" bootloader that can be updated. I suppose that theoretically you could even multi-boot between different "firmwares" on a Pandora, then, given enough storage space and a suitable bootloader?

My points still stand - a bad flash can cause you no end of pain even with all the protection in the world, and the best you can do is to "lock" some firmware in "a-bit-firmer-ware", or hardware. So that even if the worst happens, the average non-technical users get another shot at flashing. That doesn't guarantee that you'll be able to flash the firmware part indefinitely or correctly but at least you get a shot without having to build cables, interface with the hardware, send it off for repair etc. The GP2X doesn't have that - you can wipe out the bootloader without any way to restore but JTAG or worse.

But then, judging by reports of modern hardware, the Xbox, the Wii and most cable routers (as well as a ton of other hardware) don't have that either. So it's hardly "bad" for a cheap, handheld console to work the same way. People should just treat firmware updates with care. Don't do it unless you NEED something from the update.

I'm an IT manager and it's common practice when managing hundreds of PC/printers/switches/etc. to NOT flash a firmware unless there is no other way around a critical problem that directly affects you. On a large scale, you can end up bricking more hardware than you fix and even with support warranties you have to "disguise" the fact that it broke during a firmware update and suffer the inconvenience of getting it replaced.

Working off of rumour, I also hear that the Flash parts used for BIOS's etc. (where flashing is expected to be a rarely-used option) tend to only accept a much smaller number of writes than the Flash that you're used to using every day (SD cards, USB keys, SSD drives etc.). This would be understandable from a manufacturer's perspective (and another reason that they don't support flashing), allow the use of lower-cost parts etc. so it seems to hold some sense, if it's actually true.

(P.S. Please note that I have a habit of treating Flash/Firmware/BIOS as interchangeable terms when discussing solid state storage. I know that there are many types of such firmware, EEPROM's, NAND Flash, SRAM etc. but force of habit of using the term "flash the BIOS" means I treat them all as one)

 

[Orkie]

I think you're partly wrong here, but it doesn't really matter.

I'm glad it doesn't matter to you, because I do know how the GP2X firmware gets flashed, better than most . I've never heard of 'less writable' flash being used for BIOS-es, it could be true for some things I guess but on devices like the GP2X, I've never ever encountered it. The GP2X's only problem is that the code is broken and tricks it into thinking the NAND is worn out before it really is.

 

[EvilDragon]

@ledow: Orkie is right, flashing is all done via U-Boot, that's why you can reflash a complete gp2x as long as you have U-Boot on it.
Also, if there's nothing on the gp2x, you can upload and flash U-Boot via JTAG, so everything is done here.

But I think I know what you mean.
The NAND Userarea gets filled from a script (gp2xupdate.gpu) and some gzipped images. THAT'S the script that gets launched and flashed via the boot scripts.
But that's not flashing, that's updating or populating the created yaffs image (the main file area)

 

[ledow]

Orkie/EvilDragon - I stand (slightly) corrected in that a part of the update in done in Linux userland, and obviously some of it is done in U-Boot. I thought the U-Boot bit was more minimal, however. Anyway...

QUOTE
I've never heard of 'less writable' flash being used for BIOS-es, it could be true for some things I guess but on devices like the GP2X, I've never ever encountered it. The GP2X's only problem is that the code is broken and tricks it into thinking the NAND is worn out before it really is.



There was a Register.co.uk article a few years back concerning either some high-capacity (for the time) SSD hard drives or USB sticks - basically the Hong Kong traders were getting one over on the punters by selling literally "less-writable" Flash in them, which died very quickly because it wasn't designed for that many writes (although it WAS writable, and sold as a normal storage device). This was before even wear-levelling was making a big show, though, so I may be using out of date information.

I can't find the article (too much noise, not even details) but this type of Flash may have even been used on quite a big-name device, if memory serves.

 

[noabody]

I'd like your opinions on these two F-200 revisions. In the short term which is better? Is the F-200 MK1 better because it's FW 4.0.0 touchscreen has support of current software, or the F-200 MK2 with it's improved screen. Does it even matter compared to an F-100 MK2 with it's networking capabilities or the impending release of the Pandora?

I know I was a little disappointed in my F-200 MK1 because of that silly vertical white line on the left hand side of the screen, the brightness, and the flickering or scan lines. I immediately noticed those things and I've always been picky when it comes to computer monitors so I guess my eyes are somewhat sensitive. Most of those issues can be improved through software. Does the new F-200 MK2 screen eliminate those problems?

 

[Manjuu]

I'd like your opinions on these two F-200 revisions. In the short term which is better? Is the F-200 MK1 better because it's FW 4.0.0 touchscreen has support of current software, or the F-200 MK2 with it's improved screen. Does it even matter compared to an F-100 MK2 with it's networking capabilities or the impending release of the Pandora?

I only have the "old" F-200 and never had a F-100, so I can't really say much. I do prefer to keep the touchscreen support for the homebrew softwares intact, so I won't be updating my firmware until a solution is found for this (and the autorun). Is it a fact that the new screens are better?

The networking capabilities of the F-100 did intrigue me, but I don't think I really need it. I haven't done anything that would really require it. Although, it would have been nice if the F-200 still had this. I would gladly trade the USB SD card reader capabilities with it, as I only use an external one. As for the Pandora, I won't be getting one though (well, maybe in the future).

I know I was a little disappointed in my F-200 MK1 because of that silly vertical white line on the left hand side of the screen, the brightness, and the flickering or scan lines. I immediately noticed those things and I've always been picky when it comes to computer monitors so I guess my eyes are somewhat sensitive. Most of those issues can be improved through software. Does the new F-200 MK2 screen eliminate those problems?

I'm wondering about these too. Are they corrected?

Although, they don't really bother me that much.