What About Open2x?

[Orkie]

Yes, u-boot is on the NAND. The ability to boot from SD refers to the ability to load a kernel from it, which can have a separate SD partition set as it's root device.

I really don't think Linux should becoming 'worn out' by some crashes... Programs don't have to write into the system files (at least not in the important ones)
But one could ever write a program that clear the whole NAND, make it look like a game, and spread it over the GP2X forum... about that : does Open2x log in as root? or does it log into a user with less permissions? You could even make the NAND read-only, but it's a little bit 'too much'

I too don't think there is much of a chance of it being worn out
Open2x has to use root because so many programs depend on it, you can't really use a normal user for a lot of stuff on the GP2X. And yes, it is possible for somebody to spread a program which would clear the NAND, I have written one myself to repair my NAND after loads of blocks got marked as bad when they were not (there isn't much chance of this binary getting out though, I was quite careful who I gave it to so people wouldn't start using it by accident). I think it's fairly unlikely though, and would be totally repairable with Jtag.

 

[DJWillis]

The point of closing off user access to the nand, is of course to stop it getting 'worn out'/ corrupted by some emulator crashing...

I think I read somewhere open2x is bootable from sd, but... out of curiosity, does the uboot go on the nand or is there like some kind of additional memory. I think I know the answer to this already... If I'm right then users really really don't want to go anywhere near the nand...

Edit; wow I should think clearly before typing. What I really meant was if the NAND is up the creek, will uboot be too?

Ok, let’s clear this up.

The MP2520F (the SoC the GP2X uses) has a hardware feature to let it boot of the beginning of the attached NAND chip. The GP2X has no other integrated storage, no nice quick NOR flash, nothing, you have the NAND and the SD slot and that’s it.

The GP2X then has a custom version of the U-Boot bootloader sat at the beginning of the NAND that configures a minimal amount of the hardware and then boots the Linux kernel.

This kernel is also on the NAND and that kernel in turn loads its own ROOTFS also off the NAND. That is the only option you have with the GPH 'stock' version of U-Boot.

What Orkie means by the ‘user’ area of the NAND is the extra partition of storage space the 2.*> series of firmware provide (mounted at /mnt/nand) to fill out the difference from the size of the ROOTFS image and the totally capacity of the NAND (64MB’ish).

If we are going to have a feature rich alternative firmware then that means a lot more will end up in the ROOTFS then the current stock firmware’s meaning that we want to ‘borrow back’ that leftover space that is normally /mnt/nand so we have upto 64MB to play with.

That really is the long and short of it .

Going forward, the Open2x version of U-Boot also supports booting the kernel and ROOTFS off an SD (or SDHC) card instead of the NAND (however you should think twice about upgrading the bootloader unless that functionality is important to you).

Note: At the moment the Open2x U-Boot is still under heavy dev and should not be considered stable or flashed to the NAND by any end users. I am trying to improve the NAND/SD drivers, add more ‘bricking’ protection and upgrade the core to U-Boot 1.2.0 (any offers to help? ).

Just to clarify, Open2x will run from SD just fine provided your U-Boot supports “boot from SD” as the Open2x version does. If you use the stock U-Boot your limited to running Open2x from the NAND only.

Where do the legends of NAND use = BAD come from?

The reasons for a lot of the comments about the inbuilt NAND being unstable or 'flakey' stem from the NAND drivers written for the MP2520F being well frankly a 'bit crappy'. They do not make use of a lot of the features offered by NAND chips to manage bad block relocation, ECC etc. that can make NAND a very solid storage system.

The upshot of this is that if you get problems with the NAND rather then gracefully handling/marking them (as frankly it should) the GP2X can be prone to have a little paddy and sometimes things can go all to pot.

Better NAND drivers, supporting the full feature set etc., and a little rethink about the way we do things would help us around this but with fast big SD cards being so cheap there is little point in putting in a disproportionate effort to make it safe to use what may be as little as a few M/B of left over NAND for normal user use.

It is far better to leave the NAND access to a minimum (less use = less chance of things going wrong of course ) and let people just load up there multi-gigibyte SD cards with all there favourite files .

 

[poddy]

the GP2X can be prone to have a little paddy and sometimes things can go all to pot.

it was all sounding sooo technical till then
sounds fair enough, i have been used to having a few *essentials* on the nand,
but @ the end of the day, there's always a card in the slot....

just laying my hands on a b.o.b. at the moment,
so if youneed another tester soon....

 

[fusion_power]

It is far better to leave the NAND access to a minimum (less use = less chance of things going wrong of course ) and let people just load up there multi-gigibyte SD cards with all there favourite files .

Me as a little End-User can say, thats exactly my GP2X philosophy. SD-POWER! :lol:
I have an MK2 GP2X from ED. I hope my "U-Boot" (?) can handle your Open2X from SD. ^^""""
Uhm, can Open2x speed up the USB connection between PC<->GP2X ? somehow I only have 300-400kb/sec with my USB2.0 connection, with USB 1.1 too and there could be over 900kb/sec. And somehow transfered files are not shown on gp2x until reboot, but that could be an GMenu2X-only problem...
Without my fast SD-card-reader I would be lost.

 

[DemonStar55]

I have an MK2 GP2X from ED. I hope my "U-Boot" (?) can handle your Open2X from SD. ^^""""

I may be wrong, but I believe that is a feature of the Open2x bootloader being developed, thus if you wanted that, when Open2x is released you would have to update your uboot at the same time.

 

[DJWillis]

I may be wrong, but I believe that is a feature of the Open2x bootloader being developed, thus if you wanted that, when Open2x is released you would have to update your uboot at the same time.

Nope, completely correct.

The only caveat there is that based on my current workload I think the firmware may be out, in test forms at least, a fair while before I get a chance to bottom out the last major bugs in the Open2x U-Boot code .

 

[PokeParadox]

I don't have gripes about the NAND being shut off for the end user. It is more that I like to have GMenu2X on the NAND currently since it saves redundant data accross my SD cards. This isn't an issue if Orkie makes his nice script to replace the GP2XMB with GMenu2X

And I think mythical legend of the bad NAND comes from that it is possible for it to wear down. Many think this means it WILL wear down... but that requires many many many writes for the medium to become damaged.

 

[Zeladin]

...Yeah I was just thinking along the lines of, if the nand got irreparably corrupted, like for instance on of my sd cards did, if there was an alternative boot method. However as I suspected there is no other uboot option than the NAND.

I don't really see this as a problem, just that when people are writing to it, it could be as dangerous as flashing the bios on your PC. Good case jtag will fix, bad case permanently corrupted NAND. That sort of corruption can occur if for example you switch off the GP2x while a game is saving to the SD/NAND. Though I still feel there must be some way to rewrite my broken SD, something to do with low level formatting... I sort of felt that it was a good thing if the NAND was a little less easily accessible.

By 'worn out' I was referring to the limited number of read/write cycles for flash memory.... It was just a few random thoughts, rather than anything useful.

Having said that, Scummvm sits on my NAND, though I recently redirected the saves path to the SD... Just cause I'm paranoid... It was a cheap Sd card, but it put me on edge. :unsure:

Btw Open2x is sounding really great, don't rush it though.

 

[Orkie]

...Yeah I was just thinking along the lines of, if the nand got irreparably corrupted, like for instance on of my sd cards did, if there was an alternative boot method. However as I suspected there is no other uboot option than the NAND.

I don't really see this as a problem, just that when people are writing to it, it could be as dangerous as flashing the bios on your PC. Good case jtag will fix, bad case permanently corrupted NAND. That sort of corruption can occur if for example you switch off the GP2x while a game is saving to the SD/NAND. Though I still feel there must be some way to rewrite my broken SD, something to do with low level formatting... I sort of felt that it was a good thing if the NAND was a little less easily accessible.

The most that could get corrupted is the individual partition, so u-boot is perfectly safe. And Jtag can repair pretty much any 'irreparably corrupt' NAND with the fixer I mentioned above
Basically, don't worry, your GP2X isn't likely to be totally trashed through accessing the NAND

 

[Megatog615]

Will Open2x solve the problem of the TV-out not centering/scaling the image on the TV screen correctly(at least in America)? Whenever I play a video through TV-out it's about 1-2 inches off to the right, leaving a black bar on the left side of the screen, and cutting off those 1-2 inches on the right side of the video. Plus, the menu screen is rendered too large, and cuts off about 2 inches from the bottom of the menu screen. Not to mention it looks horrible.

 

[gohmifune]

Hypothetical Question:

If Open2x gets working on the NAND as opposed to the SD card, is would it be possible to have a loadable file on SD cards that contains links, settings and such, so one could switch cards flip a switch and everything they need applicable to that card is working as opposed to having to deal with dead links or loading the FW+apps to every SD card?

 

[PokeParadox]

Hi I've just thought of a couple of features that would be good if Open2X could provide them.

Hotkey on boot to toggle TV-Out mode (so you can quickly overide the setting for if you are on the move vs being at home with your BoB)

Hotkey to toggle USB-Joystick mode. I think it would be good if Open2X could make better provisions than the officla FW does for USB-joystick users. It would be nice if the first USB joystick could be used by default for the Open2X menu and also (if possible) provide a compatibility layer so that programs launched would also use the USB joystick. This would make the 2X easier to use in TV-Mode.

Just a couple of thoughts

 

[Megatog615]

Any thoughts on a release date?

 

[slygamer]

Hotkey to toggle USB-Joystick mode. I think it would be good if Open2X could make better provisions than the officla FW does for USB-joystick users. It would be nice if the first USB joystick could be used by default for the Open2X menu and also (if possible) provide a compatibility layer so that programs launched would also use the USB joystick. This would make the 2X easier to use in TV-Mode.

The menu applications (GP2XMB and GMenu2x) could easily be modified to also read a USB controller, but other applications would also have to be modified to look for and use the USB controller if it exists. Open2X can not magically make USB controllers work for all applications. The reason is that the states of the buttons on the GP2X are read from hardware registers, not via a device driver.

 

[reiboul]

The menu applications (GP2XMB and GMenu2x) could easily be modified to also read a USB controller, but other applications would also have to be modified to look for and use the USB controller if it exists. Open2X can not magically make USB controllers work for all applications. The reason is that the states of the buttons on the GP2X are read from hardware registers, not via a device driver.

Another design error by GPH?

 

[Squidge]

The reason is that the states of the buttons on the GP2X are read from hardware registers, not via a device driver.

Another design error by GPH?

Nope, GPH provided SDL and /dev/gpio. Although some people use one of those, others ignore completely and hack the hardware directly (it's faster than using several software layers to get to the same point).

However, you can use the MMU in fine mode to map the GPIO registers for the joystick to point somewhere else, get something else to read the usb joystick, and then simulate the joystick hardware registers in software. The program hitting the hardware to get it's joystick movements won't know any difference unless it leaves Linux. Of course it wouldn't be easy, but then again, neither was the first mmu hack

 

[Orkie]

Any thoughts on a release date?

Yes, but those thoughts have not become anything certain yet Basically, I'm waiting for help with two bugs then there'll be an 'early' beta version released (they basically make dynamic linking pointless right now, hence why the release is being held back for them).

About the joysticks. As I said before, the module to make the GP2X controls appear as a standard Linux joystick device is in there, so hopefully things will move over to using that. If they do so, any USB joystick will automatically become supported, however I've not even started to get USB host working, it seems to be a bit of a mess...

EDIT: The last few days, I've been busy with other stuff anyway

 

[Megatog615]

I think this topic should be pinned .

 

[DaveC]

Any thoughts on a release date?

About the joysticks. As I said before, the module to make the GP2X controls appear as a standard Linux joystick device is in there, so hopefully things will move over to using that. If they do so, any USB joystick will automatically become supported, however I've not even started to get USB host working, it seems to be a bit of a mess...

EDIT: The last few days, I've been busy with other stuff anyway

Speaking of joysticks you may want to make a provision so that when 2 ordinals are pressed it will automatically give a diagonal. As it is now coders must specifically support it. With the growing numbers of d-pad users (I think there are around 50 or so now with more to come) that is important. If it is transparent to the coder then it will avoid any future compatibility problems. This can be implemented and it won't effect the standard stick users either. Since a d-pad can't hit the in-between switch (not there) and the standard stick can't physically hit 2 ordinals at once they can both be implemented simultaneously.

 

[Megatog615]

Maybe I don't completely understand it, but would this allow for Linux binaries compiled for ARM9 to work on the GP2X, instead of .gpe/.gpu? If so you could technically install almost any Linux utility compiled for ARM9. Is this true?