Gp2x Linuxdev: Using Embedded Linux Systems Stuff?


timofonic

GP Mafia
Joined
May 20, 2004
Messages
399
How it is the GP2X Linux development? Anyone contacted with the guys developing on it?

Here are a list of some interesting projects about embedded systems (thanks Ravnos for a few ones), it could be very interesting if the GP2X Linux developers know it (anyone sending an email to them, for example...):


- OpenWRT: Linux for wireless routers, loading in 2 secons aprox. with a lot of internet services.

- LinuxBIOS: Linux on BIOS computers, doing a lot faster linux loading.

- InitNG: A full replacement of the old and in many ways deprecated sysvinit tool, It is designed with speed in mind because it does as much as possible asynchronously. In other words: It will boot your unix-system much faster, and give you more control and statistics over your system.

- OpenZaurus: Linux for Zaurus PDAs, they are working in 2.6 for it. I think Zaurus stuff will be very useful for GP2X.

- uClinux: Linux for embedded systems, including microcontrollers and other systems without MMU.

- Lynuxworks ARM Linux: Website about one of a lot companies using embedded Linux on ARM9 systems, specially network stuff.

- comp.os.linux.embedded: Newgroup (usenet) about Linux for embedded systems.

- ARM Linux: Official page about Linux for ARM processors family.

- LinuxDevices.com: News page about Linux for embedded systems (PDAs, routers,smarthphones, TabletPC, GPS, PLC, etc...). They mentioned GP2X when the early stage of development (still saying about 32MB ram), it could be very interesting if they analize a final GP2X.

- BusyBox: BusyBox combines tiny versions of many common UNIX utilities into a single small executable. It provides a fairly complete environment for any small or embedded system and has been written with size-optimization and limited resources in mind.

- uCdot: Slashdot-like page about embedded Linux systems.

- Scratchbox: A cross-compilation toolkit designed to make embedded Linux application development easier. It also provides a full set of tools to integrate and cross-compile an entire Linux distribution. cratchbox is used by Maemo development platform (Nokia 770).

- Handhelds.org: Page about open-source OSes on handhelds.


Personally, I think other stuff like using the 7zip SDK (multiplatform and with free and commercial licenses available) could help a lot the more space available on the NAND.
 
GP2X already uses BusyBox. There is also a lot of things on the nand which you can delete because they are simply not used. However, I would suggest that people stay away from the nand as much as possible, as it seems that it is very fragile, and you can easily turn your GP2X into a brick by messing with the contents.
 
the only solution to this stupid SDK question is to put the compiler/libs on-board, and give people an optional source tarball they can download if needed, which, when added to the gp2x 'shipping config', gives you all you need to use theh gp2x for code.

put arm-elf-gcc and a distcc *on* it, and away we go .. no more questions about what platform you need to be on in order to write code for the gp2x: the gp2x *is* the coding platform.

the hassle of maintaining 'two' separate systems to develop software for one, also makes it an imperative that we get on-board code [100% self-hosting/self-compiling would be lovely].

at least, this will be my initial direction once i get the box (i already do this sort of setup for work), and before anyone says 'but, but the gp2x is too slow to write code', i'll just remind you that 64megs of RAM and a 200mhz processor has been more than enough for the development of pretty much all software shipped on the GP2X today ..

you don't need gigahertz computing to compile good code, at least .. you shouldn't need it, by now. gimme my devtools onboard, yo!
 
It won't be slow to what people are used to ten years ago, maybe, but it'll certainly be slow to what people are used to today. Plus it places unnecessary strain on the SD cards/NAND which have finite erase/write cycles. Also, don't forget that 32MB of that 64MB is reserved by the OS, so user apps have about 25MB to play with. Is that still enough for GCC and friends?
 
Ten years ago? I'm sure I don't remember my MegaDrive taking that long to boot? 20 years ago maybe with my ZX Spectrum :p

I'm just kidding, i realise that a *nix system ten years ago may have taken an age to boot B)
 
It won't be slow to what people are used to ten years ago, maybe, but it'll certainly be slow to what people are used to today. Plus it places unnecessary strain on the SD cards/NAND which have finite erase/write cycles. Also, don't forget that 32MB of that 64MB is reserved by the OS, so user apps have about 25MB to play with. Is that still enough for GCC and friends?


ten years ago, my SGI machines were booting in under a minute, same with the Alpha. 10 years before that, my MIPS pizzabox was, also, booting under a minute ..

this fantasy that one 'needs' megahertz to do useful computing/compiling is a shallow view.
 
ten years ago, my SGI machines were booting in under a minute, same with the Alpha. 10 years before that, my MIPS pizzabox was, also, booting under a minute ..

this fantasy that one 'needs' megahertz to do useful computing/compiling is a shallow view.

Yeah but what you suggest would require to write your software on your PC anyway, then move the sources to the GP2X, then compile, then check the error messages, fix 'em on the PC, transfer again, and again and again. No thanks ;)
 
Last edited by a moderator:
I'm sure Squidge reffered to the following and not to the boot-time:

i'll just remind you that 64megs of RAM and a 200mhz processor has been more than enough for the development of pretty much all software shipped on the GP2X today ..

:rolleyes:
 
Any news about the GPH Linux? It's being improved by GPH? Any news about source code petition because it's GPL?
 
Back
Top