Hardcore Homebrew (hh)?

[declaration]

[disclaimer] I am not pestering for a release or moaning about lack of progress. Also, there could be threads relating to this question somewhere but I can't see them and the search won't accept HH. [/disclaimer]

I havent been keeping ultra up-to-date with all things GP2X recently, but was wondering about the HH project I heard quite a lot about back in the day. Is it still being worked on? And are people still planning on releasing and supporting a homebrew firmware?

Thanks for any help.

 

[TelcoLou]

Some links

 

[theoddbot]

On the firmware side, Open2x is making slowish progress. Working on a media player at the moment, then back to the menu. We had most of the features of 2.0 working already, but won't be making a release until we manage to replace all of the apps with free equivalents. I guess I'll have to start integrating the changed on the 2.0 kernel side soon, but I don't imagine there will be too many changes.

 

[declaration]

Some links

Yeah, great.

On the firmware side, Open2x is making slowish progress. Working on a media player at the moment, then back to the menu. We had most of the features of 2.0 working already, but won't be making a release until we manage to replace all of the apps with free equivalents. I guess I'll have to start integrating the changed on the 2.0 kernel side soon, but I don't imagine there will be too many changes.

Thanks for the update. Glad to know things are still being worked on : )

 

[Alpha2]

Yeah it's good to hear it's still being talked about as this seemed to be one of the things a lot of people were placing their hopes on for unlocking the full potential of the device.

 

[Crazy Goat]

I never even thought of that - it would seemingly be more powerful without the Linux leering in the background!

 

[Epicenter]

Unless you intend to write your programs in ASM and don't mind missing most of the conventions of a *nix operating system like an actual filesystem, or desperately need the (rather small) footprint of RAM Linux is using, you won't see much real benefit from 'HH'. Most of the speed benefits from running programs heavily utilizing ARM9 ASM can be had from within Linux, however-- the supposed performance gains from cutting Linux of the equation are highly exaggerated.

 

[slygamer]

There is another benefit. Your applications will always work, despite any firmware changes that GPH make. How many threads have you seen due to applications no longer working or working incorrectly after firmware updates? Squidge and Reesy have stated in other threads that are wanting to ditch Linux and have their applications run on the hardware for this reason alone. The hardware will change far less often than the firmware.

 

[Vimacs]

Epicenter, the highest benefit would be the direckt acces to the hardware, and to its irq's. at the moment you have to poll for evrything, that wastest resources and can make controls less responsive, a irq is allways 100% responsive.

 

[Squidge]

Unless you intend to write your programs in ASM and don't mind missing most of the conventions of a *nix operating system like an actual filesystem, or desperately need the (rather small) footprint of RAM Linux is using, you won't see much real benefit from 'HH'. Most of the speed benefits from running programs heavily utilizing ARM9 ASM can be had from within Linux, however-- the supposed performance gains from cutting Linux of the equation are highly exaggerated.

I see the following instant advantages of HH over Linux:

• Access to 64MB of ram instead of 25MB with kludges for another 16MB or so
• The full 64MB being cachable (so faster access)
• Being able to use the full mmsp2 hardware (eg. blitter) at intended speeds
• Updating or switching frame buffers on vsync (at the moment, this has to be polled, guessed, or quad buffered)
• HSync interrupts for raster effects and performance improvements
• Access to the 940 the way it's meant to be (communication via the correct 920->940 pipe instead of via memory)
• Access to various other IRQs such as the sound driver.
• Being able to manage the processor caches manually
• Lower power consumption (and therefore longer battery life) for some emulators and most games, as they can sleep when they have nothing to do rather than be constantly polling for events
• Being compatible with every firmware currently released, as they don't depend on anything provided by it

So, I don't think it's highly exaggerated at all

 

[FluffyPanda]

Just out of interest Squidge, couldn't the same benefits be achieved by using a superior version of linux? I'm thinking that open2x could give us the best of both worlds.

With a community linux you could:

• Avoid breaking compatability (since we'd have the control)
• Cope with future hardware changes
• Add features once and allow thier use in all projects (HH libraries would do much the same thing, but
• Upgrade performance of all apps with a new OS version, rather than a recompile of all affected apps.
• Still gain virtually all the advantages you've listed through kernel modules / options.

Linux does still seem to offer a lot of advantages to me and replacing it looks like a lot more work than modifying it to be more friendly.

Ok, so HH will run on any currently released gp2x, but I think that a "Requires Open2x version x.x.x" note wouldn't be unreasonable.

 

[slygamer]

With a community linux you could:

• Avoid breaking compatability (since we'd have the control)
• Cope with future hardware changes
• Add features once and allow thier use in all projects (HH libraries would do much the same thing, but
• Upgrade performance of all apps with a new OS version, rather than a recompile of all affected apps.
• Still gain virtually all the advantages you've listed through kernel modules / options.

Linux does still seem to offer a lot of advantages to me and replacing it looks like a lot more work than modifying it to be more friendly.

Most of the hard work is already done with sdk2x.

You are also assuming that all applications dynamically link to libraries. For an application to ensure library compatibility, the developer generally compiles the executable as a stand-alone application with no dependencies on external libraries.

Ok, so HH will run on any currently released gp2x, but I think that a "Requires Open2x version x.x.x" note wouldn't be unreasonable.

I would prefer the "Doesn't require any version of Linux" tag on my software. The app will run no matter what version of firmware the may have. Cater for the widest market instead of a limited subset of users who may be using the specific version of Linux your app requires.

 

[FluffyPanda]

You are also assuming that all applications dynamically link to libraries. For an application to ensure library compatibility, the developer generally compiles the executable as a stand-alone application with no dependencies on external libraries.

Actually, I wasn't really thinking about the libraries, but the OS functions. A call to an OS function can take advantage of an increase in efficiency when you upgrade the OS whereas if the function were to be made in a library you would need to recompile to get the same effect. I only say this because most apps are statically linked.

I would prefer the "Doesn't require any version of Linux" tag on my software. The app will run no matter what version of firmware the may have. Cater for the widest market instead of a limited subset of users who may be using the specific version of Linux your app requires.

And yet the OS can offer transparent access to varying hardware. Once the breakout box is in circulation and a new version of the gp2x is being sold (I never had a gp32, but weren't there regular hardware changes? BLU/FLU/BLU+ I hear from time to time). You'll end up with a choice between offering a different .gpe for each hardware revision (and possibly for each hardware configuration - make of wifi card, hard drive external storage or usb thumb drive, usb joystick, etc) or specifying an open2x version number.

Then again, it really doesn't matter as both can happily co-exist. I know I'd be happier programming for linux though as things stand.

 

[Squidge]

Knowing how idle people are with installing applications (not wanting to add additional libraries), I think requiring an entire OS to run an application is going to be more than just a little frowned upon. When GPH release future firmware updates, some people will upgrade regardless of Open2X, and thus break compatibility with the applications.

It's certainly a nice thought, but I think because of fact that we know have gp2x's out there with multiple different versions of firmware/linux/community builds/etc the only way of being compatible with all of them is to use a trampoline to actually jump out of linux and run on the hardware via HH. It's not so nice in the short term, sure, as you loose the development and debugging features of linux, but these can eventually be incorporated into HH-style apps given time.

 

[timbobsteve]

Is there going to be a DevKit for HH?

I don't know any ASM and am still learning C++. Will C++ apps still work in HH or will they have to be re-worked?

Sorry for the n00b questions, but I am still using SDL and from what I can tell that needs linux to work.

Thanks.

 

[Squidge]

C++ may be tricky, but standard C should be ok. You should be able to use a number of library functions, but there will be a lot you can't call, or must be mapped elsewhere, such as the ones that ask linux for help (eg. fopen, malloc, printf, etc).

Eventually there will be replacement functions for all of the ones that currently use linux to get there dirty work done...

 

[slygamer]

Is there an updated sdk2x floating around? There is a link in the wiki to one on the cobbleware site, but that dates from Dec 2005.

 

[Squidge]

dec2005 is the latest release, yes.

 

[dwelch]

dec2005 is the latest release at yes.

How about "Hello World!" example with sdk2x. Maybe it is around here somewhere and I just cant find it.

for fun or curiosities sake, how hard is it to halt the second cpu, copy my app to its memory space, reset start the second cpu and pause/halt the primary cpu? My hope is to avoid dealing with the MMU at this point, avoid linux at this point and jump in head first into HH?

I have see some reference to an swi to reset, I assume that means reset the device, I assume that means after taking over the machine, to avoid having to power cycle, this swi (on the primary cpu I assume) will cause the gp2x to reboot from nv memory and not know I had been messing with Linux's ram/peripherals?

Thanks,
David

 

[Squidge]

The easiest way to take over the machine is to stick a routine in the reset vector and cause a watchdog timeout.

HH was thought to be the best way forwards to get the most performance out of the machine. However, with some hacking, we can get almost identical performance from linux, and reap all the benefits of linux as well (easier developing & debugging, ready made libraries & device drivers, etc).

HH-mode just isn't necessary any more, and with more and more people wanting to use the usb networking and mass storage features (to run apps and stuff from external harddisks, pendrives, etc) it is becoming inpractical.

Of course, if your only interested in HH-mode, then the best way to go is probably by grabbing the latest SDK (still Dec'05 I think), hacking up a u-boot to stop it from booting linux, and uploading your code direct to memory via uboots binary load commands, and executing it from there.