The Need For Linux In The Gp2x

[OMars]

From my understanding, not most programs for the gp2x actually use linux. So I would like to know more about the point of having a linux OS. What are your views on this and is it actually necessary? :huh:

 

[PSyMastR]

Yes.

 

[Shikaku]

Yes and no.

No because you can still make software without linux.

Yes because it is much easier to do ports/make software with linux.

 

[sand_man]

Most of the programs DO use linux.

 

[X-Code]

Not to mention the fact that you can use USB networking as a coding / testing environment... ( ok,not that you couldn't do that with another OS, but Linux is open source, and that is what the whole game is about :lol: ).

 

[aapje89]

almost all programs use linux.

 

[Mr.Jabberwocky]

The way it is, as I see it, without linux the GP2X would have never taken off as it has. It has gained a lot of publicity because it uses linux and has attracted some skilled dev's who may not have given it a second glance otherwise.
Considering the poor press concerning the shortcomings of the hardware, linux has got to be the main selling point that has kept it alive.
At the end of the day, however, I get the impression that it is as much of a hinderance to the real hardcore devs as it is a help. One of the first discussions when it came out was about how to ditch linux in order to access the hardware directly. In reality a small library of input/output functions tailored to the hardware would have done the job as well.
Because it is there programs use it. It is the OS and and its function is to provide methods of access to the peripherals, so of course it is used. If it had a different OS, programs would use that.
So linux is not actually necessary but it is the defining feature that makes the GP2X what it is. The cost to the user is the boot time but the benefits of the opensource community that come bundled with linux far outweigh that.

 

[Epicenter]

Did the GP2X not use Linux, I'd probably never have started programming for it-- at the time I found it, I was looking for a game console to develop for, and not having any luck finding one that really met my expectations. I wanted a powerful processor, a good amount of RAM, a large color palette and some sort of 2D acceleration by way of a blitter, a simple means of development, and some decent amount of familiarity in way of language (e.g. I'd like to use C or C++) for programming it.

Now, the GP2X met all of those requirements in exemplary fashion. The CPU is a beefy 200 MHz ARM9 proc (one of my absolute favorite architectures, by the way), there's ~41 MB of free usable RAM, a full 24-bit color palette, a blitter ... but most important of all, arguably-- it runs Linux, an OS I am familiar with and supports SDL, an open-ended but powerful language that would not tie to me one platform, and that would interoperate well with my favorite language, C. That's what sealed the deal-- knowing I would not need to work my way through a 1000-page tome of a manual to learn a new language or stumble through old mistranslated, general and unspecific tutorials and try to BS my way through programming the machine. Knowing that when I was through, as well, my code would be so portable it would work on the next iteration of the hardware, and the next and the next, my PC, my friend's Mac, my Dreamcast, or a friend's XBox .. just about anything.

Had I needed to write code for a closed-ended proprietary and difficult-to-get-used-to OS like the GP32 for example, I might never have bothered at all. And a lot of the software that attracted me to the system would not likely exist, either. HydraLancer, the lead artist on our team, was drawn to the system by such offerings as being able to run Quake (one of our all-time favorite games to play .. and modify!), Doom, Wolfenstein 3D, and of course his favorite ROMs, as we're both as hardcore retro-gamers as they come.

This is why the promise of "HH" has never held much promise for me. Linux on the GP2X is part of the experience, and except for a few specific applications, should they prove themselves to truly benefit (to live up to the hype of such would likely be an impossible feat as it's been blown up to provide ridiculous imaginary benefits), would be a departure from the ideals that spawned the system in the first place.

 

[Radek]

From my understanding, not most programs for the gp2x actually use linux. So I would like to know more about the point of having a linux OS. What are your views on this and is it actually necessary? :huh:

The point is the same as having an os on machine like PC. To allow higher level abstraction to ease porting and developing of software.
There were some quick (and often not optimal) ports to GP2x at the beginning. Without Linux they couldn't show so fast.

It's like an infrastructure what was already build. It can have its flaws but it is.

Most of criticism of GP2x Linux aroused at its start. It was so-so at best (SD card problems, long boot time, crashes, bugs...) then and now? It boots in a moment, have far better functionality, libs like SDL got a hardware acceleration and a programmer still can go to "the metal" if needed.

 

[Shado23]

The speed and ease of porting software is definitely a big factor,
but the effort needed to replace it has to be considered as well.
You'd have to basically rewrite/port the sd drivers, the filesystems etc.,
and in the end it's probably more work than it's worth.

Actually I think that the same goal (more raw speed) could be reached as well or better,
by just hacking on the linux kernel and making it slimmer, giving it some asm love, scheduler tuning etc.
Thought the open2x project would maybe become such a thing, which might still happen.
But this is of course no easy or quick task, and not immediately rewarding,
so it's no wonder there hasn't happend much in this direction (or I haven't noticed).
Also there's the problem of staying in sync or at least compatible to the official firmware.
Which might of course be dumped alltogether, if there is some serious advantages to the community one.
Well we'll all see how it turns out.

Just my 0.02€.

 

[OMars]

Thank you guys for enlightening me about linux for gp2x.

 

[Ze_ro]

almost all programs use linux.

I was under the impression that ALL of the GP2X programs currently available ran under Linux. The only exception I can think of would maybe be commercial releases that boot off the SD card, but even then I think those run under Linux too... so which ones actually hit the hardware directly?

--Zero

 

[aapje89]

almost all programs use linux.

I was under the impression that ALL of the GP2X programs currently available ran under Linux. The only exception I can think of would maybe be commercial releases that boot off the SD card, but even then I think those run under Linux too... so which ones actually hit the hardware directly?

--Zero

I think certain parts of some emulators, and maybe some 3d rendering engines?

 

[Radek]

almost all programs use linux.

I was under the impression that ALL of the GP2X programs currently available ran under Linux. The only exception I can think of would maybe be commercial releases that boot off the SD card, but even then I think those run under Linux too... so which ones actually hit the hardware directly?

--Zero

I think certain parts of some emulators, and maybe some 3d rendering engines?

Be "hitting hardware directly" we mean not using Linux (even kernel) entirely or just using hardware (read/write to them) registers of MMSP2 chipset?

If it's the latter then it can be done under Linux on GP2x. And there is an excellent topic about it on the dev forum. Plus Linux kernel isn't imposing any big perfomance hit either but it's providing some very handy functionality.

At one point even without os an aplication (or game) would have to implement something like an os. Just to be able to write files. Just to be able to talk to peripherals. Just to handle memory allocation.

Some abstraction layer is a good thing. But if there is a need there is nothing stopping a coder to "hit the hardware directly". The best example is latest Squidge MMU trick.

 

[Sonic-NKT]

there ist a u-boot replacement, this one doesnt use linux

 

[TKF15H]

Just a thought... If you can overwrite kernel code with the MMU hack... isn't it possible to execute GameBoyAdvance code a la gpAdvance?

 

[Ze_ro]

Be "hitting hardware directly" we mean not using Linux (even kernel) entirely or just using hardware (read/write to them) registers of MMSP2 chipset?

I was thinking more along the lines of a program completely shutting down Linux and being the only program running at all. This IS possible right?

--Zero

 

[Epicenter]

Be "hitting hardware directly" we mean not using Linux (even kernel) entirely or just using hardware (read/write to them) registers of MMSP2 chipset?

I was thinking more along the lines of a program completely shutting down Linux and being the only program running at all. This IS possible right?

--Zero

Sure; but the thing is, then you have a program that needs new code for file IO, display, audio, input from the controls, and a whole slew of other things Linux and/or SDL took care of before for most apps. You'd need all of these bits of support implemented in your program and then it essentially IS a small OS. It might not carry as much overhead as Linux, but odds are, it'd get fairly close. It could be made tiny and write most of it in ASM, but there'll also likely be compatibility issues due to things like drivers for the audio needing to be written .. also USB is probably something no one will implement outside of Linux usefully.

 

[DaveC]

Linux on the GP2X is a double edged sword. On one hand it is great as it attracts more users and gets alot of publicity because of it. It attracts devs because they are more familiar with it than some propriatary OS. On the other hand is sucks up precious RAM and CPU, and imposes limitations on how the RAM is used. It segments it up and doesn't allow apps to use the full 64 MB. It would be nice for apps like the NeoGeo emu to be able to use more RAM and cut down on those annoying pauses in large ROMs caused by SD reads. Linux also effects some programs, the lack of raster interrupt pallette switches in DrMD is because of linux.

The Squidge hack kind of gives you a taste of what performance would be if linux wasn't there eating up power and limiting direct access to the hardware.

The best option would be to be able to initially boot into linux and then put it into some kind of "sleep mode" when a power/RAM hungry app is loaded. The only thing still active would be the drivers, every other unneeded process would be flushed. When you exit the app linux would wake up again and reload the needed modules. I don't know if that is possible but it would help with app speed especially emus.

 

[BradN]

I think you're overestimating the processing overhead by any running background processes (if there even are any - run top over usb networking while running an emulator and see what %cpu it gets), but you're right about the memory issues.

I bet a hack similar to the squidge MMU one could be done to route the raster interrupt to the 2nd cpu (which can be guaranteed to be ready to handle it), provided the display actually scans in such a way that it would be useful (does the MK2 interlace the display in a checkerboard pattern like my laptop?)

I don't think a sleep mode as such is possible while preserving drivers - the kernel's kinda a big chunk that doesn't like to separate easily besides loading/unloading modules, and that probably wouldn't affect the size a lot. Any auxiliary programs like a samba server could be unloaded, but then again the user could have shut it off first in that particular case anyway.

A little unrelated, but I think a cool feature would be to allow changing the 32/32 memory split to some other ratio - more RAM for PDA programs would be nice.