I just applied your patch and launched compilation. And it's currently compilating (surely I will have problems with SDL, but not with ARM GCC). The rockbox initialization script installs ARM GCC, and configures it automatically. So I just applied your patch, and ran "../tools/configure && make". See http://www.rockbox.org/wiki/LinuxSimpleGuideToCompiling and in particular the part about "./rockboxdev.sh". For the SDL, I think it won't be the same. But rockboxdev.sh it worth reading.

I just applied your patch and launched compilation. And it's currently compilating (surely I will have problems with SDL, but not with ARM GCC). The rockbox initialization script installs ARM GCC, and configures it automatically. So I just applied your patch, and ran "../tools/configure && make". See http://www.rockbox.org/wiki/LinuxSimpleGuideToCompiling and in particular the part about "./rockboxdev.sh". For the SDL, I think it won't be the same. But rockboxdev.sh it worth reading.

I was very suprised that the compilation ended without any error after a normal build (without any of the tweak you mentioned). But of course, the binary that is produced results in nothing more than a black screen...
I'm now going to add the custom libs and paths...

EDIT:
Maybe should add a target arch named "arm-linux" or so to "tools/rockboxdev.sh".

I was very suprised that the compilation ended without any error after a normal build (without any of the tweak you mentioned). But of course, the binary that is produced results in nothing more than a black screen...
I'm now going to add the custom libs and paths...

EDIT:
Maybe should add a target arch named "arm-linux" or so to "tools/rockboxdev.sh".

I tried to compile with arm-linux-gnueabi (provided in Ubuntu packages). It didn't work... I'll now try with your link. But it's for 32 bit, no?
It seems that all the binaries that I create with arm-linux-eabi-gcc segfault...

I don't think so. We are running it on linux...Sorry but this is a bit too complex for my knowledge
Moreover atm I haven't so much time to dedicate on it

@lovasoa: strange for the segfaults...I don't know what could it be the reason but using the sourcery gcc (32 bit on 64 works using the compatibility layer) works perfectly!
And so did the recompilation of the kernel, which is not to be done for various reasons but it worked...

And previously in this topic, slade said that we could compile optimized binaries with , but I can't find it in the Makefile. Shouldn't we add this to the gcc options?

You should tell it to schedule for arm11, but the vfp option shouldn't make a difference; we don't use floating point in rockbox.

Quote:

Originally Posted by lovasoa

And do you know where do all the "Warning: R8 redefined" come from, when we compile ?

Rockbox is usually compiled with gcc 4.4.4 and binutils 2.20.1 (on ARM). In the past when we've had to change gcc versions we encountered quite a few problems due to subtle differences in how different gcc versions work. If possible, I would use gcc 4.4.4. It will save you having to troubleshoot gcc bugs.

You should tell it to schedule for arm11, but the vfp option shouldn't make a difference; we don't use floating point in rockbox.

Rockbox is usually compiled with gcc 4.4.4 and binutils 2.20.1 (on ARM). In the past when we've had to change gcc versions we encountered quite a few problems due to subtle differences in how different gcc versions work. If possible, I would use gcc 4.4.4. It will save you having to troubleshoot gcc bugs.

Oh yes indeed sorry for having forgotten that. I'm using gcc 4.3.2

And yes for optimizations. You need to place that in the line where options like "-W -Wall" etc are

EDIT: I think it will be better to keep the usual /.rockbox folder. So my idea is:
- create a new rom (with some other fixes too possibly) with a folder at root "/.rockbox"
- in the script that launches rockbox, make something like "mount <CWD> /.rockbox [don't remember exactly the command yet ]

In this way you should be able to run rockbox from any directory as positive cons. What do you think?

EDIT2: next step will be to introduce power management. I have necessary informations, but I'm lost in RB code, so help is needed

EDIT3: absolutely. Adding the optimization options worked maybe. I get 13-14 fps in pictureflow instead of 11 (not so much indeed, but may be helpful with battery + random clicking)

EDIT_LAST: okay in this edit I remind we need to activate in some way the specific ARM optimizations coded in RB

think it will be better to keep the usual /.rockbox folder. So my idea is:
- create a new rom (with some other fixes too possibly) with a folder at root "/.rockbox"
- in the script that launches rockbox, make something like "mount <CWD> /.rockbox [don't remember exactly the command yet ]
In this way you should be able to run rockbox from any directory as positive cons. What do you think?

Good idea!
Moreover, I think we should only provide a ROM file, that contains .rockbox and rockbox_launcher.sh and installs them on first boot.

Good idea!
Moreover, I think we should only provide a ROM file, that contains .rockbox and rockbox_launcher.sh and installs them on first boot.

We cannot do that. Space is limited Actually I don't know precisely the limit, but it should be around 20 mb more or less
R0 has some hidden memories (I'm quite sure they are in the IMX37 itself), one for kernel, one for bootloader, one for cramfs and one for sysdata (-> /dev/bml3 is sysdata if I remember well, dd'ing it retrives the sysdata.bin ).
For the bootscript definitely yes, it is also useless having it at root of media0. Keeping it secret in the rom is fine once is final

Uhm...latest latest you mean? I need to try...but maybe it is supposed to don't compile because of something still being worked on?

No... Compilation still works on my iPod. And things that don't compile generally aren't comitted, or are corrected very quickly.

I dived into the reversi bug (that makes the R0 crash), and the bug seems to be in reversi_gui_display_board (in apps/plugins/reversi/reversi-gui.c). But I'm not skilled enough (and don't have enough time) to understand exactly where it comes from...