[reiboul]

Hi everyone! I'm following the open2x project for some times now, and it is a very interresting projects that tries to create a full GP2X firmware, including bootloader and bonuses that GP2X firmware lacks! and it will allow, by proper boot system, the GP2X to boot much faster :)

I know they have an open toolchain, which I used myself, but don't know much about the state of their firmware : is there a release? is it already usable? or when could it be released? Can it repair broken DMA or such things? can it clean my room and prepare me coffee??

Nobody talks about this project, but I think it s very important to have a good firmware that do not use ugly scripts for a 15s booting, and have quality software built-in, like newer libs and a TinyX server (which will allow easier use of X apps like PDF reader)

[PokeParadox]

Funny, I was also thinking about this the other day. I'd like to know if the Open2X firmware is ready for the end user at all?

I was also wondering if a menu like GMenu2X could be used as default.

I think the Open2X project needs more "pimpin" as I'm sure there are many that haven't even heard of it.

[reiboul]

PokeParadox, on Mar 19 2007, 05:26 PM, said:

Funny, I was also thinking about this the other day. I'd like to know if the Open2X firmware is ready for the end user at all?

Yes it would definitely be cool to have a totally customizable front end, using Gmu or CraigAmp for music, MP2X for videos, a light X text viewer like a tweaked nEdit, or simply Gmenu2x or GP2XMB, which is becoming really cool ;)
But I would say first of all is to have a stable release which is more performant than the original, compatible, and with clean code, allowing easy updates and features adding!

[purple_goat]

funny, just yesterday I was thinking about a custom firmware!
seems like reiboul reads minds :lol:

[reiboul]

And I forgot to mention about SDHC support, which is planned!

[Orkie]

Loads of stuff is happening with Open2x at the moment, we've just been keeping quiet until something usable came about, which happened last week hence why some people may have noticed a slight increase in the mentions of it :)

I don't know a whole lot about the status of things outside my 'field' but I can tell you exactly where the root filesystem is now and where I hope to take it (and this is all the stuff you as a user will see, so it's probably the most interesting).

Firstly, where it is now. Over the last week or so, things have moved very quickly. I've gone from half a bootable system to a pretty complete, bootable system. Currently, there isn't a whole lot new (though it is fairly similar with regards to features to say 2.1.1). It uses newer dynamic libraries so developers will be able to link dynamically, reducing binary sizes hugely (from 1MB to 10KB for a fairly simple program should be a simple case of recompiling). This also speeds up the loading times of applications (assuming they're dynamically linked).
There are more basic Linux command line applications in the firmware itself which will again, be of more interest to developers when debugging.

For a menu, we've decided to use a modified version of GP2XMB (which I've been working on to add extra functionality -- this should be hopefully merged into the main tree when I submit patches to the author), though autorun.gpus are supported (and are faster to load than GPH's firmware because they aren't launched from GP2XMB, but a smaller launch script which runs in an instant) so you can use gmenu2x on SD if you like.

Boot time has been reduced, by how much I'm not entirely certain yet since I've not tested it properly, but I reckon it'll be at least a 1/3 reduction by release.

SD cards should now automount with any supported filesystem (I'm going to compile a few extra ones into the kernel).

I've used a few little tricks to build a backwards compatibility image which contains the entire of 2.1.1 and you can drop back into 2.1.1 through the menu without rebooting for near perfect compatibility (which is the case with Open2x anyway, but there may be one or two early apps that don't work for whatever reason) and to access the applications GPH included (like the movie player etc.). DJWillis has done a bit of work on our own version of mplayer, but if somebody else has the time when a beta firmware is released, it'd be much appreciated if they could build one :)

What isn't supported right at this very moment is USB host and networking, but those are the two things I'm working on now, so hopefully they'll work when there is a release. I'm also working on a nice update system which will mean minimal flashing via u-boot, most things will be handled from within Open2x itself. We've also taken the decision to remove the 'user' portion of the NAND (which some people may be upset about, sorry) to make room for the built in applications, configuration files etc.

Now onto where I'm hoping to go from here. There are currently no built in applications, which is a bit of a pain (though the GPH compatibility layer works for now). As was previously mentioned, the X server will be included directly in the firmware itself and we have plans to try and integrate ParkyDR's GP2Xpdf and any other useful X things that appear. For music, text reader and image viewer, we're still undecided as far as I know, but there are good replacements for all of these out there now. As I said before, you'll have to use the compatibility layer for playing movies for a while, until somebody fixes up a version.

Another feature I'd like to get in (though I can't promise anything yet) is the ability to mount zip files. For those who don't know a lot about *NIX, this will allow the contents of a zip file to be seen as a normal directory by any program so for any emulators which don't support zip loading, you'll be able to roll all your ROM images into one large zip and use them from there.

The last few things that will be in there is a built in mmuhack module (so programs won't need to ship with them -- in fact, the original module won't load into our 2.4.26 kernel, so developers will have to use it but this is now sorted and I have a working module ready). I'd like to have a small daemon which can put the GP2X into a sort of a sleep mode at some point too (set clock speed to 33MHz and disable backlight and whatever else you can). The package manager will make a comeback in a slightly different form that more people may be pleased with, though of course its use won't be mandatory. Some people may have noticed that diemumiee wrote a module which lets you use the GP2X controls as a standard joystick device, this should be in the new firmware too. I may throw a couple of useful resources such as TTF fonts in if there is space at the end.

That's basically everything I can think of off the top of my head.
So in summary:

• It is usable
  
• It will be coming soon
  
• It should offer a significant enough improvement over the GPH firmware that most people will use it

I'll be sending alpha versions out to a few people in the next few weeks (don't ask to be included in this, I don't want to brick people's GP2Xs who I know won't be able to repair them easily) and then sometime after that, there will be a public beta release I expect, but we want to make sure it works and make it worth upgrading to first :)

Hope this answers some questions and explains what has been going on. Feel free to ask any questions.
What a long post!

EDIT: Oh, I do know that SDHC code is working for most cards and it has been integrated into the Open2x kernel tree. Have a look here for more information: http://www.gp32x.com...t...=35840&st=0

And look at our wiki too sometime: http://wiki.open2x.o...title=Main_Page

This post has been edited by Orkie: 19 March 2007 - 05:52 PM

[gnyffel]

That sounds awesome, Orkie. I, for one, look forward to the release, and will be using it when it becomes usable to the end-user.

[reiboul]

Whhoow this answer exceeded what I expected :) And it is all very good news!

So you want to use a packet manager? this would be a cool feature, if only it is supported by developpers.
It allows a Unix-like software handling : You put a package file on the card, and the package manager installs it and delete the package file :)
No need to worry about where to put softwares, all is handled by the packet manager, and all you have to do is to put your roms, MP3 or movies in the directories provided with the frontend, the rest is hidden :ph34r:
By handling the softwares with a package manager, it will allow frontends to automatically have direct links to available applications, without looking through the file system (because it will know where to search)
Linux is wonderfull, isn't it? :rolleyes:

But I think I'm still dreaming...

Anyway, if your firmware is as good as you are telling, no doubt everybody will upgrade (and I trust it WILL be damn good)

The only think I could advise is, please, let some space on the NAND, even if it's only a few megabytes :)
Personally I don't use it much, but it has proven to be useful for copying files from one SD to another while on the move, though I admit I only did it once :ph34r:

This post has been edited by reiboul: 19 March 2007 - 06:21 PM

[PokeParadox]

That does sound great overall. I am kinda bummed about removal of the userNAND area and the descision to use GP2XMB as the menu system (looks pretty but I don't see it as being as functional as GMenu2X... depends how much it is modified I guess), but I guess that comes down to personal preference. The lack of user NAND space means I wouldn't be able to have a NAND install of GMenu2x (as I currently have) and have to copy it onto SD.

I do look forward to the new firmware, however. :)

[Alex.]

This is fantastic news. The shorter boot time and the fact that we will be able to dynamically link libs are the two greatest things I heard around here as of late! Keep up the great work, this will breathe even more life in the little bugger :-)

[NightShadow]

This is great news...

But I have to agree that using GMenu2X would have been a better choice...

Hope something comes out soon... As I see it, 2007 will be the year of the GP2x :-)

[fusion_power]

Sounds good. I thought the project was dead since ages :lol:
I think I wouldn't miss GPH's own firmware, I'm using Gmenu2X since a long time. The only Things from the original Firmware which I still use (via Gmenu) is the Movieplayer , MP3 Player, Txt reader (sometimes), Explorer and of course the whole Setting stuff.

But if the new open Firmware will be faster I'm sure I will give it a try. I hope I can handle this without knowing anything special about Linux. (And I hope there will be skins for the Menus/Apps like for GPH's firmware ;) )
And me, poor 56K Modem User wishes an smaller new Firmware than the horrible 3.0 (which I don't use) ;)

Maybe someone here can make a short Overview/comparing between advantages/disatvantages of GPH and Open2X Firmware(features)? :)

[DJWillis]

Warning: post below is typed while tired and deprived of caffeine :o , sorry if it makes no sense.

The status of Open2x, well I guess its just what Orkie said :D …

Over and above the specifics above there is SDHC support, boot tweaks, and a lot of general background work on things like the toolchains, libs, cleanup etc.

Here are some other things that are in the pipeline but are slow due to time commitments (mostly the stuff I am working on, funny that), off the top of my head...

• Refactoring and cleanup work on the GPH mplayer code.

What more can I say on that, the code as it stands is a bit of a rats nest and I have been working to clean it up and make sure it compiles with the Open2x kernel toolchain. I have also been hacking about with extra codec support (WMV and some containers) but none of that has gone very far. I also want to move it over to something easier to manage config files with from a code perspective then the current INI file approach.

• Newer version of the U-Boot bootloader with the boot from SD capacity of the older Open2x bootloader (ART103's) and a menu wrapping a number of system config options, ability to boot Open2x, GPH 2.*> and many other OS’s.

This would allow you to run say Open2x (or RTEMS, or just raw ARM HH code, or just whatever you want) entirely off an SD and leave the GPH firmware on the NAND if you so wanted. This also has SDHC support for booting your 8GB OS image off an SDHC should you so desire ;) . Enhanced support for fault finding and debugging problems is also in there.

Being a bootloader, flashing it is far from mandatory and in fact not recommended at all if you have no means to unbrick your device should anything go wrong.

• Further work on the 2.4.26 ARM Linux kernel we are using to nail down a few bugs that are still lingering about (mostly USB host and SDHC related).

The stock GPH kernel is 2.4.25 so this is a kernel upgrade from the stock one and was done to allow us to support applications such as the MidiShare platform (Torpor's pet-project). MidiShare turns your GP2X into a real studio grade piece of MIDI hardware.

It also gives us some other nice bonus features being a more recent kernel that we intend to exploit in due course. Additionally it was a good excuse for a cleanup and bringing the kernel code up to scratch and fixing some lingering bugs.

• Additional work on jTAG tools.

In Open2x's SVN there are a few cross platform jTAG tools that are handy should things go wrong. Including a NAND flashing tool to help you wrap U-Boot or the filesystem for flashing via jTAG. Again, only really something for the hackers.



I guess that is all that springs to mind right now, maybe I should turn all this into a new post of sorts or and update on the WiKi, see if we can drum up a little help from people who want to get there hands dirty :D .

Really nice to see people interested in the project again, Open2x has always been bubbling around and SVN is always active with hacking about but there have never been that many people working on it.

As we are finally starting to get to the point of a viable release (in no small part due to Orkie’s tenacity on the subject of the filesystem image) I guess now is the time to drum up some interest and support.

[Orkie]

PokeParadox, on Mar 19 2007, 06:26 PM, said:

That does sound great overall. I am kinda bummed about removal of the userNAND area and the descision to use GP2XMB as the menu system (looks pretty but I don't see it as being as functional as GMenu2X... depends how much it is modified I guess), but I guess that comes down to personal preference. The lack of user NAND space means I wouldn't be able to have a NAND install of GMenu2x (as I currently have) and have to copy it onto SD.

The reasons I chose GP2XMB over GMenu2x are purely that it looks nicer and would be easier for somebody who's never used it before to pick out without reading instructions. It doesn't let you sort things into nice categories, but most people could cope without that anyway. They are both very good.

Since I can see this becoming an issue at some point, how is this as a compromise? GP2XMB is installed by default for the above reason, but I will make a little installer to replace it with GMenu2x or whatever else you might want to use for those who aren't too keen.

As for a bit of user NAND space, I don't know how much space we'll have left over at the end yet, so I can't comment on it yet. I'd rather not have any if possible because it's a bit messy.

[reiboul]

Orkie, on Mar 19 2007, 07:56 PM, said:

As for a bit of user NAND space, I don't know how much space we'll have left over at the end yet, so I can't comment on it yet. I'd rather not have any if possible because it's a bit messy.

So do you think it is easily possible to create a ramdrive (virtual drive located in RAM) to enable file transfert between different cards? It would be a cool bonus :) and why not load small programs in it, so that they could run faster? like 32mb ramdrive + 32mo ram :)
Would it be useful? I mean, programs load stuff they use a lot in memory when they load... So can we expect some performance gain in loading the WHOLE program into a ramdisk? :)
Of course it's not a top-priority task, but it could be useful :rolleyes: