Would It Be A Good Idea To Build A New Os For The Wiz?


lunavorax

Still Fresh
Joined
May 24, 2009
Messages
14
Hello everyone!

I'm the owner of a GP2X Wiz and a Dingoo A320.
Like some Dingoo A320 users, I followed the development of the new GNU/Linux based OS OpenDingux and installed it as soon as it was released.

I though that doing the same for the GP2X Wiz could be a good idea for several reasons:
* Taking advantage of the latest GNU/Linux kernel
--> The wiz currently use GNU/Linux 2.6.24

* Taking advantage of the latest GCC build
--> Better optimizations?

* Better tuning of the OS Kernel
--> Real-time mode, faster boot time, more drivers for usb devices (joysticks, remotes, wifi/bluetooth/ethernet dongles, etc...)

* Getting rid of the unnecessary stuff
--> Flash Player, Original UI (replaced by Gmenu2X)

* Booting the OS from the SD card like for Dingux/OpenDingux
--> Making it easier to upgrade the Wiz

* Your suggestions here

I would like to know if that sounds like a good idea.
 
I think it would be a good idea, as long as it included a better optimized screen rotation routine!

Seriously, if someone could make the screen rotation routine fast enough, I think it could eliminate the diagonal tearing in all the existing games and emulators that have problems with it.

Unfortunately, I don't know enough about programming to be able to accomplish anything like that. :( In addition, I'm not entirely sure it's actually possible to do what I'm suggesting, but I'm just hoping it is!
 
I would love to see faster booting and maybe even instant shotdown :) But it is important that it is backward compatible, so games won't notice the difference.
 
u9i said:
But it is important that it is backward compatible, so games won't notice the difference.

In my humble opinion, I think this should be considered as a non-issue since most of the sortwares for the Wiz are open-source, you'll just need to recompile them with the new toolchain.
Still, there shouldn't any reason not to be "backward compatible" since the OS will still be GNU/Linux based.
 
Last edited by a moderator:
Has someone been able to boot a custom kernel/initrd from the SD card? The firmware updates work like that, so it should be possible... this would be very helpful in order to do non-NAND-destructive experiments with custom firmware...
 
hmn said:
Has someone been able to boot a custom kernel/initrd from the SD card? The firmware updates work like that, so it should be possible... this would be very helpful in order to do non-NAND-destructive experiments with custom firmware...

So far, the kernel and boot loader source code seems to be available at http://dl.openhandhelds.org/cgi-bin/wiz.cgi.
We should head that way first.
 
Last edited by a moderator:
True. What would be very interessting would be an android on sd card. Should not be too hard, chroot into sd card app if /android/ is present if not start normaly. More interessting would be if android managed to get their code into the kernel main line.
 
LunaVorax said:
In my humble opinion, I think this should be considered as a non-issue since most of the sortwares for the Wiz are open-source, you'll just need to recompile them with the new toolchain.
Still, there shouldn't any reason not to be "backward compatible" since the OS will still be GNU/Linux based.
Unfortunately, I suspect it's not quite that simple (I speak from experience!). Firstly, a lot of stuff is not open source, and that which is tends to be old and is a bit of a pain to port (plus somebody actually needs to sit and do it). Also, a lot of things access hardware directly, and subtle changes can break these. Another thing I discovered on Open2x is that a lot of people hardcode things like relaunching the menu upon exit -- it's not a huge issue, but another thing to consider.

Not that this should put you off, but it's not quite like moving from e.g. Debian to Fedora on a desktop.
 
Last edited by a moderator:
Orkie said:
Unfortunately, I suspect it's not quite that simple (I speak from experience!). Firstly, a lot of stuff is not open source, and that which is tends to be old and is a bit of a pain to port (plus somebody actually needs to sit and do it). Also, a lot of things access hardware directly, and subtle changes can break these. Another thing I discovered on Open2x is that a lot of people hardcode things like relaunching the menu upon exit -- it's not a huge issue, but another thing to consider.

Not that this should put you off, but it's not quite like moving from e.g. Debian to Fedora on a desktop.

It'll take time. I knew/suspected theses issues already. If the OS was 100% FOSS it would have been surprising not to see an alternative OS for the Wiz.
But I'm sure this great device deserves better than it's original firmware. I spent some time reading the elinux.org wiki and there's quite a LOT of interesting ideas for the Wiz.

But yeah, it's not a project like when 9yrs old people think they'll just shout the idea and a bunch of random people will make the work overnight for them. It's a durable idea.
I even though about reverse engineering the closed source stuff (ie: GPU driver). Not easy, but so far I know it's not impossible.

Thanks anyway for the warning :)
 
Last edited by a moderator:
If you are interested in the 3D hardware, I know JustBurn had a simple driver of his own working a few years ago.
 
Mmmmm open2x on the Wiz/Caanoo.. My Wiz still works like new, maybe I can work on it sometime soon.

Been taking a break from all forms of productivity, but recently I've been throwing around the idea of porting a bunch of Kenta Cho's stuff from D to C++ for the Wiz.
 
Open2x is a masterful firmware imo. Seeing it on the Wiz/Caanoo would probably bring some people back here.

Would backwards compatibility be possible? I know we have Ginge but not everything works or works 100% with it. Plus seeing a more recent Linux kernal would definitely be a big plus!
 
A year has passed and still my motivation stays the same.
I've been into a very busy year, it won't happen again, I promess.

I'm very happy some people with some background on Open2X getting interested about the idea.
 
Also, since backward compatibility seems to be very important to you all, I'm just being against it because I'm afraid such a "feature" will have a performance impact on the OS and toolchain as well as being a hard thing to handle.
If not, I'll be glad not to be against it anymore.

Anyway, I'll be ordering a Samsung cable tomorrow in order to make my own GP2X Wiz Super Cable (according to theses informations) in order to access all the juicy features of the device (USB Host!!!) but also the RX and TX pins.

I also have to mention that I have no prior experience in embeeded GNU/Linux programming. I have reasonnable C programming skills and consider myself to be an experienced UNIX user.
I'm willing to learn and I'm ready to take time to work with some of you who have the necessary skills to start such a project. I just can't do this alone.
 
Last edited by a moderator:
I have spent some time back then looking into the u-boot sources to understand how the boot process works. I have built a serial cable and tried to boot a self-compiled kernel off of the SD card before, but could not get it to work.
 
I would be interested to have anoter go at this, just to further my understanding of this low level embedded stuff.
 
I plan on cleaning up the u-boot sources (they are a mess) and have another try at understanding the specifics of the Wiz boot process. As I stated before, it should be possible to boot a kernel and file system from SD, as this seems to be how GPH's firmware updates work.
 
I would not dare to mess with the bootloader itself, since it might brick my Wiz and I don't have the equipment to fix that.
 
Last edited by a moderator:
My cleaned up u-boot source code is here: https://gitorious.org/uboot-wiz/uboot-wiz
I started with u-boot 1.1.6 from upstream an then applied the changes from GPH's source piece by piece, cleaning them up in the process.
 
I also succeeded in booting a custom initrd.
 
The boot process works like this:
  • If "polluxb" can be read from SD: Perform u-boot update
  • If "uImage" can be read from SD: Perform kernel update
  • If "uImageUP" and "update.gz" can be read from SD: Boot kernel (uImageUP) with initrd (update.gz) (kernel command line is " mem=42M root=/dev/ram0 initrd=0x800000,16M console=ttySAC0,115200n81")
When using "update.gz" from the firmware package, it performs the NAND filesystem update. I made my own custom initrd by replacing "sbin/init" with a simple "Hello World" program, and was able to boot it instead.
 
The loading of the files from SD card is actually pretty unstable. I could only get it to work from a FAT16 1GB SD card. When the files cannot be read, the Wiz just reboots - the error detection does not seem to work very well.
 
The error handling when loading a file from SD fails is pretty fishy. They changed the FAT loading code to return the file size, or -1 on error,  and then bail if the return code is -1. The problem is that parts of the FAT code still return error codes other than -1 - so there is *still* a chance that you end up flashing garbage files.
 
The next step for me would be to acually boot a more complete system from the SD card. Ideally I would like to have an EXT2 partition on the SD card with the root FS in it, but unfortunately, as mentioned before, u-boot chokes and does not load anything from that card...
 
e0ku.jpg

 
I built a new serial cable and have been experimenting with UART boot.
 
I got MES_DNW running in Wine, uploaded UART.nb0 and got to the boot menu, but then the application froze.

When I send UART.nb0 in Cutecom at 19200 baud, it just receives a handful of garbage bytes afterwards.

I looked at the source for MES_DNW and it seems to switch to 19200 baud for uploading the boot code, and then switches back to the configured baud rate (ie 115200) once it is finished.

I tried to emulate this behaviour in a Python script using pyserial... when I send and read @19200, I get garbage, just like in Cutecom. When I send the image @19200 and then switch to 115200 (like MES_DNW), it only reads two 0 bytes and then times out.
 
I also tried micromon from the Leapfrog hackers, but the boot image it generates is 32MB large (from a 30K elf file) - something must be off with either binutils or the linker script (the resulting file should be <= 16K).
 
 
Back
Top