The Need For Linux In The Gp2x

[Squidge]

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

Yes, but don't expect it to happen overnight.

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?

Yes, it's possible, but when you compare the additional performance of shutting down Linux compared to ease of development/debugging under Linux, I think most developers will go for the later.

 

[Epicenter]

The OS is really going to be there or it isn't-- you can't just turn it off when it's inconvenient, or every aspect of the OS that present software relies on won't function at all. What we're using is an extremely stripped-down version of Linux with very, VERY little overhead. The performance differences between effectively utilizing the system with Linux running, e.g. with this hack, and eliminating it altogether, are not night and day, and are not terribly significant. They are also not warranted, as has been said, by the inherent loss of ease of programming, debugging, and usability that comes with that territory.

 

[Winterkid]

Epic, I think he means now and then, for certain programs and apps, to use like UBOOT or something to run some things without having to load the linux system, to use an alternate OS or a custom game that's pure ASM or something. But, still booting with linux the rest of the time, naturally.

 

[Epicenter]

If you read over what he said, he basically described disabling the kernel and and all other processes and leaving only drivers active, within Linux. Not very feasible in practice, the kernel's too integral a component.

 

[Winterkid]

Oh, for that he'd have to find his own drivers for the hardware, I'm guessing with NO linux dependance and ARM compatible, and tailor them to suit his needs. *scratches head* Or he can wish to the programming fairy. *shrug*

 

[loki666]

I'm currently working on a "replacement" of linux: rtems (www.rtems.com)
rtems is POSIX compilant OS (which means all libc functions are there) which fits in only 100kb. I've already ported SDL and it seems to runs just fine. I can access all the memory, and configure interrupts.
As an example, on top of rtems+SDL, i'm currently porting Ur-Quan Masters which is a big SDL game.
Except from getting the right CFLAGS and LDFLAGS to compile and link the game, i had to "tweak" the main() fct to make rtems happy, and voila!
When you start the game, it load the executable in the upper memory and reset the gp2x to boot the rtems exec.

 

[Squidge]

If you read over what he said, he basically described disabling the kernel and and all other processes and leaving only drivers active, within Linux. Not very feasible in practice, the kernel's too integral a component.

Well, you can stop the kernel from task switching - I've done that and it's not too difficult. It's about as far as you'll get with regards to killing the kernel and leaving the drivers active. However, it gives you virtually zero speedup, as not much else is running on the 2x anyway! (The kernel seems to interrupt you ever 50ms or so to do housekeeping and stuff, but that's about all, so that's about every 3 frames for most emu's and not noticable)

 

[crusty]

I'm currently working on a "replacement" of linux: rtems (www.rtems.com)
rtems is POSIX compilant OS (which means all libc functions are there) which fits in only 100kb. I've already ported SDL and it seems to runs just fine. I can access all the memory, and configure interrupts.
As an example, on top of rtems+SDL, i'm currently porting Ur-Quan Masters which is a big SDL game.
Except from getting the right CFLAGS and LDFLAGS to compile and link the game, i had to "tweak" the main() fct to make rtems happy, and voila!
When you start the game, it load the executable in the upper memory and reset the gp2x to boot the rtems exec.

This is an interesting idea, but a quick look at the website indicates
that USB support will not be available until version 4.8 sometime in 2007.

Does your port include cached access to the entire 64 megabytes of ram?

How important to users of the gp2x is the Real Time part of rtems?

 

[Radek]

I'm currently working on a "replacement" of linux: rtems (www.rtems.com)
rtems is POSIX compilant OS (which means all libc functions are there) which fits in only 100kb. I've already ported SDL and it seems to runs just fine. I can access all the memory, and configure interrupts.
As an example, on top of rtems+SDL, i'm currently porting Ur-Quan Masters which is a big SDL game.
Except from getting the right CFLAGS and LDFLAGS to compile and link the game, i had to "tweak" the main() fct to make rtems happy, and voila!
When you start the game, it load the executable in the upper memory and reset the gp2x to boot the rtems exec.

This is an interesting idea, but a quick look at the website indicates
that USB support will not be available until version 4.8 sometime in 2007.

Does your port include cached access to the entire 64 megabytes of ram?

How important to users of the gp2x is the Real Time part of rtems?

From gaming standpoint?

It's irrevelant as games aren't polling user input faster than refresh rate.
So there is nothing what would be warranting rtos type of perfomance.

The part about lower memory usage is more interesting.

 

[loki666]

you can configure memory cache the way you want it for the full 64Mb
currently the firsts 48mb are cached and the latest 16mb are uncached

 

[Dzz]

I'm currently working on a "replacement" of linux: rtems (www.rtems.com)
rtems is POSIX compilant OS (which means all libc functions are there) which fits in only 100kb. I've already ported SDL and it seems to runs just fine. I can access all the memory, and configure interrupts.
As an example, on top of rtems+SDL, i'm currently porting Ur-Quan Masters which is a big SDL game.
Except from getting the right CFLAGS and LDFLAGS to compile and link the game, i had to "tweak" the main() fct to make rtems happy, and voila!
When you start the game, it load the executable in the upper memory and reset the gp2x to boot the rtems exec.

That's very impressive!

How did you do the audio? And how do you do file I/O?

 

[OMars]

I'm currently working on a "replacement" of linux: rtems (www.rtems.com)
rtems is POSIX compilant OS (which means all libc functions are there) which fits in only 100kb. I've already ported SDL and it seems to runs just fine. I can access all the memory, and configure interrupts.
As an example, on top of rtems+SDL, i'm currently porting Ur-Quan Masters which is a big SDL game.
Except from getting the right CFLAGS and LDFLAGS to compile and link the game, i had to "tweak" the main() fct to make rtems happy, and voila!
When you start the game, it load the executable in the upper memory and reset the gp2x to boot the rtems exec.

Are you sure you meant 100kb?! :blink: That's awesome, keep working on it!

 

[loki666]

I'm currently working on a "replacement" of linux: rtems (www.rtems.com)
rtems is POSIX compilant OS (which means all libc functions are there) which fits in only 100kb. I've already ported SDL and it seems to runs just fine. I can access all the memory, and configure interrupts.
As an example, on top of rtems+SDL, i'm currently porting Ur-Quan Masters which is a big SDL game.
Except from getting the right CFLAGS and LDFLAGS to compile and link the game, i had to "tweak" the main() fct to make rtems happy, and voila!
When you start the game, it load the executable in the upper memory and reset the gp2x to boot the rtems exec.

That's very impressive!

How did you do the audio? And how do you do file I/O?

both audio and file I/O is ripped from u-boot 2.0.0
I implemented the audio as a SDL audio driver (using DMA), for file i/o i only had to implement the block driver, the fat layer was already in rtems

and yes I meant 100kb, maybe it's 150kb or so, it depends on the features you are using from rtems

 

[Radek]

I'm currently working on a "replacement" of linux: rtems (www.rtems.com)
rtems is POSIX compilant OS (which means all libc functions are there) which fits in only 100kb. I've already ported SDL and it seems to runs just fine. I can access all the memory, and configure interrupts.
As an example, on top of rtems+SDL, i'm currently porting Ur-Quan Masters which is a big SDL game.
Except from getting the right CFLAGS and LDFLAGS to compile and link the game, i had to "tweak" the main() fct to make rtems happy, and voila!
When you start the game, it load the executable in the upper memory and reset the gp2x to boot the rtems exec.

That's very impressive!

How did you do the audio? And how do you do file I/O?

both audio and file I/O is ripped from u-boot 2.0.0
I implemented the audio as a SDL audio driver (using DMA), for file i/o i only had to implement the block driver, the fat layer was already in rtems

and yes I meant 100kb, maybe it's 150kb or so, it depends on the features you are using from rtems

Given how quickly current firmware can boot an option to use some other os/firmware (by something like GRUB boot manager) would be comfortable. After all GP2x is rather single task machine from users' viewpoints. With so small footprint (150KB!) I can see benefits doing so just for some extra memory especially that there will be provided most of typical os functionality.

Very impressive and possibly very usefull for some programs.

 

[loki666]

well for rtems it would'nt be so simple, you dont boot rtems as you boot linux...
rtems is an executive os, which means rtems kernel is staticly linked with the application.
each application exec is a complete standalone image (like a linux kernel image, but which start only one application)
so the actual way of "booting" rtems apps, is just fine...
1)boot linux
2)select the rtems app with actual game selector
3)use rtems app
4)exiting rtems app will reboot the gp2x

 

[Radek]

well for rtems it would'nt be so simple, you dont boot rtems as you boot linux...
rtems is an executive os, which means rtems kernel is staticly linked with the application.
each application exec is a complete standalone image (like a linux kernel image, but which start only one application)
so the actual way of "booting" rtems apps, is just fine...
1)boot linux
2)select the rtems app with actual game selector
3)use rtems app
4)exiting rtems app will reboot the gp2x

But it does flush Linux completely? If so then it's not a disadvantage.

 

[loki666]

well for rtems it would'nt be so simple, you dont boot rtems as you boot linux...
rtems is an executive os, which means rtems kernel is staticly linked with the application.
each application exec is a complete standalone image (like a linux kernel image, but which start only one application)
so the actual way of "booting" rtems apps, is just fine...
1)boot linux
2)select the rtems app with actual game selector
3)use rtems app
4)exiting rtems app will reboot the gp2x

But it does flush Linux completely? If so then it's not a disadvantage.

yes the Linux is completely replaced by the rtems image,