Need help compiling rockbox using devkitARM toolchain.

[gama]

Hello there.

I want to try to build rockbox as an sdl application using the devkitARM toolchain,
My goal is to port it to the Nintendo 3DS.

But for now I am wondering how does rockbox dynamically load codecs?  Are codecs shared libraries?
Does it uses dlopen?

If so, is there another way to load codecs?  Can I link them statically?

Best regards.

[speachy]

I want to try to build rockbox as an sdl application using the devkitARM toolchain,
My goal is to port it to the Nintendo 3DS.

But for now I am wondering how does rockbox dynamically load codecs?  Are codecs shared libraries?
Does it uses dlopen?

If so, is there another way to load codecs?  Can I link them statically?

Codecs (and indeed, Plugins in general) are loaded via dlopen().

It's _possible_ (in the sense that it's all malleable code) to statically link everything in but it's going to bump the total binary (and code in RAM) size by ~5x and you'll need to implement an internal directory/lookup table so the playback engine knows how to look up any given codec.  (There are other technical issues, such as the near-inevitable symbol collisions between 40-ish separate codecs that were never intended to coexist in a single executable)

Oh -- for an idea of the level of effort involved of a hosted SDL-based port, look at the Maemo or Pandora ports for inspiration.

[gama]

Thanks speachy.

It's _possible_ (in the sense that it's all malleable code) to statically link everything in but it's going to bump the total binary (and code in RAM) size by ~5x and you'll need to implement an internal directory/lookup table so the playback engine knows how to look up any given codec.  (There are other technical issues, such as the near-inevitable symbol collisions between 40-ish separate codecs that were never intended to coexist in a single executable)

Actually I did that in the past when porting an obscure music player from the gp32 era to another obscure device.  And indeed renaming functions to avoid symbol collisions was a pain in the ass and I just felt it was not the right thing to do.

I will ask at the devkitpro forums about it, hope dlopen can be implemented with the current toolchain.

Best.

[speachy]

I will ask at the devkitpro forums about it, hope dlopen can be implemented with the current toolchain.

You don't _have_ to use or implement dlopen(); you can implement it the same way that our native targets do things -- effectively, you'd produce a flattened binary file, load that into a buffer, then manually jump into its init/start function.  Codecs (and plugins) aren't supposed to depend on anything other than what rockbox provides, and everything they need is provided in a table supplied to that init/start function.

On hosted platforms, codecs/plugins are already compiled with -fPIC so they are compltely relocatable.  (We don't on hosted platforms as we run bare-metal with a fixed RAM layout.  Not using -fPIC gives us a smidge more performance too, which really makes a difference on 25-year-old microcontrollers..)

[gama]

I found an implementation to load dynamic libraries written for the Nintendo DS.  It works in a similar way to that used for native targets as you described.
I will give it a try.

Thanks again man!

[gama]

@speachy, hi there.

I have made some progress.  For now I started compiling as an sdl application.

There is only one thing left to build the main rockbox binary, the firmware/kernel/thread.c code.  I have been reading the different implementations (unix, win32, arm) but don't know how should I implement it for the 3DS.

If I try to build the arm/thread.c file the assembler fails with:

Code: [Select]

firmware/kernel/thread.o
{standard input}: Assembler messages:
{standard input}:765: Error: bad instruction `ldmiane r4,{ r0,pc }'
make: *** [/home/stalker/3ds-dev/rockbox/tools/root.make:478: /home/stalker/3ds-dev/rockbox/build-n3ds/firmware/kernel/thread.o] Error 1

Can you please let me know of your comments?

[EDIT]

Ok, if I compile the arm/thread.c code within a 3ds example app, the code compiles fine.  There must be something missing in the rockbox makefile.

[amachronic]

As far as I know the 3DS has an operating system of some sort. If you are able to run without it, then the native ARM threading code is what you want. If you're under an OS then you probably want the SDL threading approach.

[gama]

There is another dev who is working on a native port of rockbox.

But I am working on a sdl hosted application.

Yes, homebrew runs on userland, though there is access to certain kernel features to some extent through the toolchain.

There is something I still don't understand, if I use the sdl threads code, does rockbox still needs the store_context, load_context and start_thread implementations?

[EDIT]  It seems the thread-sdl.c code is not being compiled.  Found it, I have to use the HAVE_SDL_THREADS flag.