Dingoo A320 forum

Hello everyone!

As I've already mentioned a few days ago, I'm currently porting the Gmu music player to the Dingoo.

Unfortunately my Dingoo got broken recently. The MiniSD card is no longer recognized by the device, because two pins of the SD slot have been bent out of shape. I don't know how that could happen. I've already opened the Dingoo and tried to bend the pins back, but actually this was not possible.
That means I don't have a working Dingoo anymore.

The good news is, I've built a Gmu release for you anyway. Which you can download now.

For those of you who don't know Gmu, here is a screenshot of the program. As it is skinable its looks can easily be changed.


Gmu download (beta release)

Beware that this is a beta release. There are still a few things left to do. Also, not all decoders have been included yet.

You need Dingux on your Dingoo to run Gmu!
This is not only a beta release but Dingux itself does not come with a user-friendly interface yet. This means right now it is not as easy to run Gmu on the Dingoo as it is on the GP2X.

Steps required to run Gmu:

1) Extract the ZIP file to your SD card, which has previously been partitioned and formatted such that it holds a Linux root filesystem on an EXT3 partition. You could extract the zip file to root's home directory /root.

2) Make sure you've got the necessary libraries installed. Depending on which root filesystem you are using you might or might not have the required libraries. In Booboo's rootfs SDL is included, but the decoder libs are missing. In this Gmu release I've included the shared object files in the libs directory. You can either copy those files to your system lib directory (/usr/lib) or adjust your LD_LIBRARY_PATH.

3) Run gmu by chaninging to the installation directory first...

$ cd /root/gmu-0.7.0_BETA1-DINGOO

...and then running the gmu binary...

$ SDL_NOMOUSE=1 LD_LIBRARY_PATH=libs/ ./gmu

If you would like to run Gmu each time you boot the Dingoo into Dingux, you could add Gmu to your /etc/rc.local file which will be executed on boot. Adding these lines to your rc.local file should do the trick, if you've extracted Gmu inside root's home directory:

cd /root/gmu-0.7.0_BETA1-DINGOO
SDL_NOMOUSE=1 LD_LIBRARY_PATH=libs/ ./gmu

For more information about Gmu visit the Gmu website.

One more thing, that might be important for new users: The select button has been configured as a meta key, which means when pressing that button, the other buttons have other functions than in their normal state. For the most important ones each function will be shown in Gmu's status bar. With the start button you can toggle between the file browser, the playlist browser and the track information screen.

Bad news about the SD-slot, maybe you can try to contact the seller? And i remember another post about a broken SD-slot.
Great news about the music player, will try it asap, only need a microSD (got an adapter already).

Sorry but i can't use it...
every time that I launch

export SDL_NOMOUSE=1 ; cd /home/gmu ; ./gmu

I get

-sh: ./gmu not found

but I checked and the file exists! Also tried

chmod +x ./gmu

in order to make it executable (and checked permissions with ls -alg)...
Don't know what to do now!

Are you sure that you copied Gmu to /home/gmu ?

Try just go in to the folder where you copied it and the use:
export SDL_NOMOUSE=1 ./gmu

I'm getting the same issue, only started when I installed a clean uclibc rootfs.

I originally had booboo's rootfs with the uclibc rootfs installed on top of it. When I ran some programs, like gmu, I'd get a string of errors, something like:
No version information in libpthread, required by libSDL
*repeats a few times*
Segmentation fault

Now that I've got a clean install, all I get is this:
-sh: ./gmu: not found

Even though the file is definitely there and executable.

I'm guessing there is some library in booboo's rootfs that is missing in uclibc.

I was getting segmentation fault in waternet not so long ago. It happened because few of files in /etc and in its subfolders had wrong permissions. For example rc.S was not executable.

I'm getting problems where it says it doesn't exist either.

I stored it in my vfat partition...I think my rootfs is damaged...it says ls is not found.

EDIT: nm about ls, but it still does say it doesn't see the executable (-sh: ./gmu not found)

This Gmu build requires a real glibc, not the uclibc. If root filesystems with the uclibc are the most commonly used ones, I will build Gmu for uclibc instead.

OK... so that was the issue!
I'm using uclibc rootfs from openhandhelds (i think it's elzekow's one) because booboo discouraged using his own saying it's just for testing.

This makes me think that we definitively have to define a sort of "base configuration" (with also a common repository, being it booboo's google code project page, or openhandhelds) in order to avoid this kind of conflicts in future!

@wejp: thanks for your effort! It will be appreciated!
@grz3siek: what about audio quality? I'm a bit disappointed about the original firmware (Bass response, equalizers distortion, 3D *hahahaha!* effects, ecc...) it would be interesting understand if it's actually a hw or a fw limitation (maybe 16bit processing instead of 24?).

batman52 wrote:This makes me think that we definitively have to define a sort of "base configuration" (with also a common repository, being it booboo's google code project page, or openhandhelds) in order to avoid this kind of conflicts in future!

Yes. I second that. This is a very good idea. We especially need to decide if we use glibc or uclibc and then stick with one of the two. It is fine with me to use uclibc if it has a real advantage over glibc in our case.