GP2X Programming New Gp2x Bootloader

[Dex]

I am starting a new project, to make a new boot loader, for gp2x and other ARM chips, it will be written in full asm and much smaller than u-boot (and any such offshots), it will be part of my work to port my x86 OS (Dex4u), its main job will be to look for a default file on the SD card, if found load and jump to it. if not it will load a mini OS (Arm port of Dex4u), which will include menu, media player, built in function to help coder's.

Yes this will do away with linux, but if you want to code good games etc, thats what you will need to do, as in take all the layers that get in your way and slows your program down, linux is great for a PDA device, but not for a gaming or hackers OS (as in hardware hacker's).
I have a full Dev setup to help me code this, including two gp2x, bob, fasm assembler, and some program that run on Dex4u to help debug and flash etc.

Any body who want to join or has any ?, or point to make, are welcome.

 

[YakumoFuji]

as long as you can initialise all the support chips and such of the device... it might be intersting but uboot does everything thats required. (why cant you use uboot?) uboot doesnt mean you have to use linux.

-stu / http://mega-tokyo.com/osfaq2java script:ShowHide('qr_open','qr_closed');
Fast Reply

 

[xafier]

I think you'll find theres already a simple hardware OS in works, not sure how complete it is, but it was been worked on mainly by Rob Brown? with the help of others on IRC as far as I'm aware...

it was called HH for some reason, I believe he got a very stable SD driver written and quite a lot of the basic OS... but I can't be totally sure, he also started work on an SDK for writing programs for pure hardware

you should probably come into #gp2xdev on efnet and talk to some of the guys in there, as theres not much use in duplicating work... unless you plan to do this regardless as a personal project, in which case you may still want to look at whats already been done

 

[BradN]

I bet lots of stuff could be accomplished with linux hacks ala the MMU hack, etc. Making a functional OS is a lot of work, and then getting rid of subtle bugs is even harder. Although even just having a good, capable bootloader would be a good thing, and it never hurts to have options in the OS area either.

Even if the OS part of it never comes to be, a bootloader with a decent boot menu could be good for running programs that utilize heavily hacked linux (to the point it's no longer compatable with the stock kernel). Think emulators with hooks in the (stripped down) kernel to handle advanced video tricks and things like that. Or if kernel compatability issues become a problem due to upgrades, you could just use it to select an appropriate boot kernel for your program.

 

[Dex]

First thanks for your inputs, here are some reasons for my plans to rewrite boot loader.
1. It will give me a better understanding of ARM and the way it set thingsup (90% of my work is x86 asm).
2. It will be written in full ASM (No C code ).
3. It will be written with a new assembler (New to ARM that is) FasmArm a add on to fasm, this assembler will be part of a ASM Dev Package, with this assembler, you will be able to assemble "???.gpe" "???.bin""??? .img" etc as esay as

c:\FasmArm test.asm test.gpe <enter>

4. The HH work of people like "Rob Brown" is very welcome and a big help, but most of it is still C code, which is just not for me.
5. I have made a x86 OS http://www.dex4u.com/ and want to port it to another processor, this is one of the goals to make it portable in design, if not a code way.
6. I can make lots of interesting program to help gp2x/arm asm Dev's, that will run from Dex4u on a PC, as fasm assembler, basic gp2x debugger is already done and ported to Dex4u.

Things can be made much smaller and better in full asm. example, is a bootable MiniDos OS, i made that can run lots of old dos programs and games, but is less than 2k, or a MiniOS i made, that as full 32bpp graphics, runs in 32bit pmode, built in ATAPI driver and CD play, but fits in to the boot sector of floppy (512bytes).
screenshot: http://www.dex4u.com/cdpod.htm

I have always found the best way to fully understand something, is to start at the very basics and work your way through any problems.

Or maybe i am do this because i am just a control freak .

 

[BradN]

I might be interested in your MiniDos OS for my Sanyo MBC-55x hobby project (I wrote a BIOS for the old 80's partial IBM compatable) - FreeDOS is somewhat of a memory hog on it, so if your DOS runs in 16 bit and is even marginally compatable with simple programs (nasm, etc), I wouldn't mind taking a look.

My BIOS is only 3KB or so UPX compressed (and includes a rather bizarre feature - 256 bit AES disk encryption), so a 2KB DOS add-on could be quite impressive to include in it.

 

[Lint]

wouldn't be easier and specially safer to just develop a module that shut down linux and boot your new os? then someday you start developing a bootloader that loads your OS the same way the module does...

all you have to do is get kernel-sided, remount everything as read-only and wipe all linux off (everything in asm, as you wish), as long as you're kernel sided, you can claim all memory back and set new interrupt vectors for everything...

also this could be much better for users who are afraid on bricking the gp2x by installing a new bootloader

 

[Dex]

Your right Lint, that is the way i am planing on testing, the bootloader and OS, but once the bugs are our and it works, i will flash it to nand, than it will be just as easy to boot linux off the SD card.
If you take the DS, SP, PSP, XGP, or even the xbox, cube, ps2 etc, they all have onething in common a very minimal OS.
Regards Dex.

 

[Epicenter]

Yes this will do away with linux, but if you want to code good games etc, thats what you will need to do, as in take all the layers that get in your way and slows your program down, linux is great for a PDA device, but not for a gaming or hackers OS (as in hardware hacker's).

I commend you on your efforts, but this isn't true. You can write extremely fast games and programs under Linux; it steals very little CPU time and with 64MB of RAM, its memory footprint is largely insignificant. If there is any obstacle to my present development it's lack of a true 2D accelerator and SD DMA, not Linux being in the way.

 

[Squidge]

The only real thing that Linux slows down is not caching all your memory properly, but this is fixed with my MMU hack. Kicking out Linux completely doesn't give enough performance improvement to be worth it, specially when compared to the convenience of Linux when testing & debugging your apps (I got the performance difference to < 1%)

 

[Parkydr]

Your main interest is obviously to port Dex4u to the GP2X. Fair enough, if I had an OS, I would probably want to port it to the GP2X (and sparc too )

You could use uboot to load it, but if writing a boot loader interests you then do it.

That you'd enjoy doing it should be the main motivation behind any project, but if getting rid of Linux is your main motivation then it's not worth the effort.

Edit: As regards to C, 5 years of assembler, using a custom OS, in my first job cured me. You can't image how wonderful printf looked after that (although I prefer cout now)

 

[DJWillis]

Dex,

As I said on IRC I think your nuts to want to write your own bootloader as I doubt very much many people will use it as there is nothing greatly wrong with the U-Boot setup and my worry is that having a non U-Boot based bootloader may lead to issues with stock (and community, U-Boot derived) compatibility.

As for running the device without Linux, that’s a choice your free to make, Linux on the GP2X is fairly lightweight but that does not make things like Loki’s RTEMS port any the less cool , more OS’es are no bad thing for a hacking platform .

Anyway, that aside the ARM PDF's and Rob's SDK2X code will be your intimate friends, if your looking for examples that are not at least partly C code your out of luck I am afraid as I only know of closed source ARM micro bootloaders.

In the short term I would suggest that a combination of an Open2x version of U-Boot that can boot from the SD and the SDK2X trampoline to boot ELF's from within Linux are a decent baseline to work from. Especially while you find your feet with the delights of ARM’s quirks .

Good luck anyway and as I said before if I can help with info I will.

 

[Lint]

Getting rid of Linux could be an awesome thing for me
I mean, everytime I play any xvid on my gp2x, after 1 or 2 minutes the video stops and system halts (sometimes only the application halts, sometimes the whole operating system)

On a new OS one could make a standard interface to be used by games (so you don't have to statically link each file) and actually control caching without squidge's mmu hack (which can lead gp2x into halting when not properly implemented), also someone could lesser system security as linux is made to run on a multiuser fashion with mem protections and etc but all programs on gp2x run as root, so there's no point on having a multiuser basis (then it could be much easier to upload kernel-sided code, a little less easy than a single address spacing OS)

I agree that it will not mean a hell lot more of performance, and also can lead to some difficulties like not being able to telnet into the device until someone develop a new tcp/ip stack and usb gadget interface... but any attempt into developing an option to Linux OS will stomp on this....

it's quite odd for me to be talking about removing Linux when I only have linux on my PC

 

[gfoot]

I think a better option is to figure out why the system halts, and stop it doing that. If you really wanted to, you could probably make your entire game run as a kernel module anyway. Personally I accept that Linux is blocking your access to some things (interrupts in particular) but it's not that hard to write kernel modules to manage these things.

Writing your own OS is a fun project, though, and I've been doing a lot of reading on the ARM architecture recently which often drifts off into specifications of the bootup sequence for embedded systems programmers and so on. It does seem interesting.

 

[Dex]

First thanks, for all you advice, it is most welcome, also if i was doing this project from a improve performers point of view, there would be many things that i would do to linux ( as a lot of you have started to do and great work too) before going to the dramatic steps of getting rid of it.
But the main motivation is to port my OS to another processor, but if i can help users and coders of the gp2x or any other Arm users then so much the better.
As for performac improvements, i know there will be some, but how much will be down to the coder of the program, as you will have dirct acess to all hardware, and as we learn more about what this baby can do, all our programs will speed up.

To give you some idea of what i am about, here is the spec for the Xbox OS

While the Xbox kernel is based on the NT/Windows 2000 kernel, it's extremely lean. There's no virtual memory paging, and only a single process is allowed (though that process can spawn multiple threads). The entire kernel fits into 150KB--far less than the 1MB original goal.
The development library is polling-based rather than event driven (unlike Windows). This was due directly to feedback from game developers.
The game owns the hardware--it runs in ring 0, and has direct access to all hardware (including CPU and graphics).
Memory allocation is the responsibility of the app--there's no front-end memory allocation.
While the APIs were familiar (Direct3D, DirectSound), the back ends were different, and highly tuned to the Xbox hardware. However, the input API is different from DirectInput on the PC.
One thing that went wrong was the design of the main Xbox controller. There have been comments that the Xbox controller is very large, and Isensee even put up a cartoon from Penny Arcade that poked fun at the controller design. Somewhat defensively, Isensee suggested that the feedback from the US on the controller was highly positive. However, Microsoft slipped up by not doing usability testing in other markets -- particularly the Asian market. The result was a fire drill to get out a new controller for the smaller hands prevalent in non-US markets.
Isensee encouraged developers to make more extensive use of the Xbox audio subsystem. The ability of the system to generate Dolby Digital 5.1 on the fly, as well as the ability to have user-created soundtracks (by ripping your own music onto the Xbox hard drive) is unique to the console industry.
Another problem was the Xbox main menu (known as the Dashboard). The team thought they'd taken into account international issues by using Unicode--but failed to adjust for the sheer volume of text--particularly German text, which can run much longer than the same text in English.

Full story here: http://www.extremetech.com/article2/0,1697,1670116,00.asp
As we all know M$ do not noted for there small program, but even they cut win2000 down to 150k and remember the xbox is just a 700+Mgz PC .

The debug stuff is no problem, as i am code programs to debug from Dex4u on my PC, that will be one of the first thing to make for the bootloader a serial.inc, as i already can dump full u-boot and linux stuff to a program in Dex4u on the pc.

Regards Dex.

PS: @DJWillis, i think you have mixed me, up with my nephew ,as i do not use IRC, but he does and is a keen member of the Dev team.

 

[DJWillis]

PS: @DJWillis, i think you have mixed me, up with my nephew ,as i do not use IRC, but he does and is a keen member of the Dev team.

That's it . There can't be 'that' many people to I have spoken at length about this with.

 

[YakumoFuji]

dont forget to add anything interesting to the osfaq remember. http://mega-tokyo.com/osfaq2

 

[Lint]

I think a better option is to figure out why the system halts, and stop it doing that. If you really wanted to, you could probably make your entire game run as a kernel module anyway. Personally I accept that Linux is blocking your access to some things (interrupts in particular) but it's not that hard to write kernel modules to manage these things.

I don't think debugging kernel-sided things is the easiest thing in the world, specially when you're not able to telnet (right about now I'm not capable 'cuz I'm using a 2.4 series linux) and is even unable to determine what's the exact reason for that (I've tried all combinations of programs/codecs/resolutions/etc and the same movie sometimes halt the application sometimes halt the kernel), also I am not capable of compiling any of that gph's code with my devel environment.. so I'm in a pretty lame situation :rolleyes:

and there's much of chance that you end up messing up the kernel if you try to pause it (having a 64mb memory dump and having to leave the hardware exactly the same as before the module was loaded), if you try to remove the multitasking code from memory it's likely to be a non-returning function, as with a reboot would save you from having to generate that 64mb mem dump and taking all the care to give back linux control on things, but you'll have to have the filesystem in a clean state before doing that, also reading 64mb from SD may take more time than a reboot :lol:

 

[Dex]

@YakumoFuji, The "mega-tokyo.com/osfaq2" is more to do with x86 Deving, thats is another reason why a port to another processer. will be a big help to other OS dev's, as theres little info on other processer Deving.

Normaly you would uses a already available boot loader, but ARM is not like the x86, where most of the work is done by the BIOS, the bootloader in the ARM need to set a lot more up, which we will need to control.
Anyway i have set a part on the Dex4u forum for this project, you are welcome to join, i will also post any interesting info here.

http://jas2o.forthworks.com/dexforum/index.php?board=24.0

 

[YakumoFuji]

dex, ya but the more you can add to the faq the better..

(ps.. the faq, thats my site... df.. mega-tokyo etc...)