Pocket Go

[miner49er]

Hi there!

I'm trying to build Rockbox for the pocket go. The Pocket Go runs on some kind of ARM CPU and runs a variant of Linux, and has SDL.
I've bodged the generated Makefile configured for SDL and have setup a cross-compiler.

It's mostly building. The rockbox binary is there, as are the codecs and a few .rock files.

It runs, complete with the default theme but doesn't play music files. I'm guessing it has found the codec files has the mp3 files appear in the directory listing.
Also, although the .rock files don't appear through the menu, I can browse the filesystem and locate the .rock files but they refuse to run.

So, my question is: Is LUA a requirement for the SDL build of Rockbox? I ask because when it fails, it fails with LUA:

LD rockbox
GEN buttons.lua
/home/miner49er/src/buildroot-bittboy_newish/output/host/lib/gcc/arm-buildroot-linux-musleabi/9.3.0/../../../../arm-buildroot-linux-musleabi/bin/ld: /home/miner49er/src/buildroot-bittboy_newish/output/host/lib/gcc/arm-buildroot-linux-musleabi/9.3.0/libgcc.a(_dvmd_lnx.o): in function `__aeabi_idiv0':
/home/miner49er/src/buildroot-bittboy_newish/output/build/host-gcc-final-9.3.0/build/arm-buildroot-linux-musleabi/libgcc/../../../libgcc/config/arm/lib1funcs.S:1494: undefined reference to `raise'
collect2: error: ld returned 1 exit status

Any help would be great! Love live Rockbox!

[saratoga]

No, you can disable the Lau plugin if it's not building.

[miner49er]

Oh, great thanks. So you happen to know what flag I have to set to disable lua?

[saratoga]

For testing I would set plugins="no" in the configure script for your target, then once the port is working you can fix the plugins individually if necessary.

[miner49er]

Yes, I know I should just get it working without plugins for now! I do have it building now, fully (minus most plugins) by commenting out the lua/lua.scipts from SUBDIRS.app_build.

I find it odd that the SDL build defines HAVE_TOUCHSCREEN, that causes most of the plugins to not build because of the keymap then not being defined.

So, I need to create a new keymap file I guess. I have some control, I can navigate the menu system for instance...I'm guessing the dpad on this device maps to the arrow-keys on the keyboard.

[saratoga]

I find it odd that the SDL build defines HAVE_TOUCHSCREEN, that causes most of the plugins to not build because of the keymap then not being defined.

Probably so that you can use a mouse when building on a PC.  You'll want to go through and change those defines as appropriate for your hardware.

[b0hoon]

Hi.

I don't want to interrupt, but maybe you should look at apps/plugins/SOURCES file, in order to disable specific plugin.

[miner49er]

Okay, so I have the main binary built and all the codecs but still music is not playing.
My initial thought was that the codec files aren't in the directory but because the themes appear correctly (they didn't when I hadn't set the correct ROCKBOX_SHARE_PATH) I'm not so sure.
I'm focusing on the existing rock files because I'm guessing they are loaded into memory in the same way that the codecs are?
So, I can access the rock files via the menu (in addition to using the file browser), which suggests to me my directory structure is correct.
However the message I get is "Can't open /mnt/apps/rockbox/lib/rockbox/rocks/apps/rando..."
So does this mean there is a problem with the dynamic loading of rocks/codecs?

Any help would be great on this, once I get over this obstacle then I think I can figure the rest out...

[miner49er]

Hi.

I don't want to interrupt, but maybe you should look at apps/plugins/SOURCES file, in order to disable specific plugin.

Thanks but for now I've managed to get something building by commenting out the LUA stuff. This builds the main binary, codecs and touch-screen rocks (not that my device has a touch-screen...but one step at a time!)

[miner49er]

Hi again,

I've noticed that when I try and play an mp3 file, the WPS displays and briefly shows the correct song information - so does this suggest that it _is_ loading the codec but failing to actually play the music?

EDIT: Scratch that - it's literally only showing the file information. I.E. there still seems to be a problem loading codecs and rocks...annoying.

[saratoga]

Metadata is handled before the codec loads so that things like the database can work without having to load and unload the codecs thousands of times. In this case it does sound like either the codecs can't be found or they're not being built right for your device.

[miner49er]

Metadata is handled before the codec loads so that things like the database can work without having to load and unload the codecs thousands of times. In this case it does sound like either the codecs can't be found or they're not being built right for your device.

The files didn't show up when I had the directory structure incorrect (codec files not in the right place), so the fact they are showing up would suggest to me that theya re being found. Do you think I'm correct with that assumption? If so, then it must be they are not being build correctly.

My Makefile is setup like this:

export HOSTCC=$(CROSS_COMPILE)gcc
export HOSTAR=/usr/bin/ar
export CC=$(CROSS_COMPILE)gcc
export CPP=$(CROSS_COMPILE)g++
export LD=/usr/bin/ld

...I've just noticed that HOSTAR and LD are not using the cross-compiler - could this be the problem?

EDIT: I fixed that...still not loading codecs or rocks :-(

[miner49er]

Hi again (please answer somebody!)

I think the codecs and rocks aren't being built using the right compiler.

I have 'fixed' (inverted commas because it doesn't work!) by changing ARCH/ARCH_VERSION to:

export ARCH=arch_arm
export ARCH_VERSION=9

I figured this because the CPU in the pocket go is described as "The F1C100s platform is based on ARM9 CPU"

Problem is, I'm now getting this upon compilation:

.../asm/arm/memset16.S:62: Error: bad instruction `ldrpc cond=eq'

I feel like I'm getting closer...but maybe this is one barrier I won't be able to get over without some help..hint hint :-)

[saratoga]

The ARM9 processors are either arm version 4 or 5, so picking 4 would be most safe if you aren't sure what CPU you have. However, you need to build the codecs with the same tool chain as the rest of the build, so use whatever you set for the main binary.

[miner49er]

Everything is building apart from ASM stuff and it's using the correct compiler - previously the codecs and rocks were building with the wrong compiler, hence the main application building but then not running codecs or rocks.

I get this now:

/home/miner49er/src/rockbox_fromgit/rockbox/firmware/asm/arm/memset16.S: Assembler messages:
/home/miner49er/src/rockbox_fromgit/rockbox/firmware/asm/arm/memset16.S:63: Error: bad instruction `ldrpc cond=eq'
make: *** [/home/miner49er/src/rockbox_fromgit/rockbox/tools/root.make:447: /home/miner49er/src/rockbox_fromgit/rockbox/build_pocketgo/firmware/asm/arm/memset16.o] Error 1

So, for some reason it's get the ldrp command and falls over. I'm guessing a different memset is being coded in ASM for speed? I wonder if there's a flag to use the regular C memset? I'm a bit out of my depth at this point to be honest!

EDIT: I have it building fully now - I hadn't ARCH and ARCH_VERSION correctly
EDIT(AGAIN): ...but still those damn codecs aren't loading!