EABI version mismatch?

Started by Mantanuska, January 06, 2013, 11:18:15 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Mantanuska

Hello,
I am used to writing code on windows, so my knowledge of linux is somewhat lacking so I apologize if this is a stupid question.

I am trying to complie ML using the prebuilt toolchain from here https://launchpad.net/gcc-arm-embedded

I get one error repeated several times before it ends with make: *** Error 2

it reads something like this: Source object [ ] has EABI version 0, but target magiclantern has EABI version 5.

The google has nothing for me on this matter.

What am I doing wrong?

An exact copy of the error:
/home/alan/gcc-arm-none-eabi-4_6-2012q2/bin/../lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/bin/ld: error: Source object ../../src/libs/arm-elf-O3/libm.a(lib_a-sf_copysign.o) has EABI version 0, but target magiclantern has EABI version 5
/home/alan/gcc-arm-none-eabi-4_6-2012q2/bin/../lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/bin/ld: failed to merge target specific data of file ../../src/libs/arm-elf-O3/libm.a(lib_a-sf_copysign.o)

meeok


g3gg0

Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

nanomad

I'm uploading the none-eabi version of the libraries (along with a modified makefile). Looks like it's working fine
EOS 1100D | EOS 650 (No, I didn't forget the D) | Ye Olde Canon EF Lenses ('87): 50 f/1.8 - 28 f/2.8 - 70-210 f/4 | EF-S 18-55 f/3.5-5.6 | Metz 36 AF-5

g3gg0

Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

meeok

What does newlib give us and what requires it?

g3gg0

okay let me explain the whole story in this thread.
wanted to write that in wiki or in an extra post.


until now the magic lantern binary was linked to a static address in RAM.
the "loader" part of ML patched the canon memory structure to *do*not* use the memory where the "loader" will put ML code.
this address was preconfigured in Makefiles:
e.g.
RESTARTSTART   = 0x00069500  (5D3)
or
RESTARTSTART = 0x00C80100 (7D)

that means, ML must definitely get loaded there and there was no other choice.
until now this wasnt a big problem, we were fine with that.

the only downside of that static linking is now when i try to load ML into master processor on 7D.
when we start via autoexec.bin, i can not easily put the ML code for master in bootloader mode.
i have to start up normally and then i have easy access to master's memory.

but i can not patch the memory structures anymore to make canon keep fingers off the memory address i will load ML to.
the master firmware already has started, so there is no way to patch the structures.
so i made the magic lantern code to get "position indepent" using the -fPIC (Position Indepent Code) flag.
that required some fixing of function pointers etc, but thats okay now.
i've put all the code to make Magic Lantern load anywhere. just put it somewhere in memory and execute it from there.

the only problem was: libmath (filename: libm.a) - it is precompiled and lies in your compiler toolchain.
unfortunately there are functions in that library that dont work in a -fPIC environment, like powf().
so i've put precompiled libmath versions into the respository which support it.
now depending on your compiler version (arm-elf, arm-none-eabi, ...) you have to pick the right one.
and as i am lazy, i just put "my" version arm-elf into repository.


new possibilities with -fPIC:
- load main ML binary *after* camera has started into some malloc'ed memory (using some small loader-autoexec.bin)
- options for starting up ML (like a boot loader screen to select which version to load etc)
- split code and data sections across memory regions if we can not get a block that is large enough
- run magic lantern on dual-digic cameras without using FIR
- uhm. that should be enough :)

disadvantages:
- all ml-addresses/canon-functions/canon-addresses are looked up in a huge table (.got, Global Offset Table)
- this is a little bit slower (dont think its noticeable at all on normal code)
- linking is done "late" by patching all those addresses in the table during startup
- pointers to functions that are placed in structures like in the menus must get fixed (using PIC_RESOLVE(...))

the -fPIC build is working on 7D at the moment.
the 5D3 is hanging on startup, i think its because of not using cache hacks there, but copying canon firmware. not sure though.
didnt test the others.

you can enable -fPIC by setting CONFIG_PIC=y in the target's makefile

thats it ;)
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

scrax

Quote from: g3gg0 on January 06, 2013, 03:39:59 PM
you can enable -fPIC by setting CONFIG_PIC=y in the target's makefile

I've added CONFIG_PIC=y in 600D makefile and then
make clean; make 600D
compiled ok, and loaded like before, how to check if it worked?
I'm using ML2.3 for photography with:
EOS 600DML | EOS 400Dplus | EOS 5D MLbeta5- EF 100mm f/2.8 USM Macro  - EF-S 17-85mm f4-5.6 IS USM - EF 70-200mm f/4 L USM - 580EXII - OsX, PS, LR, RawTherapee, LightZone -no video experience-

meeok

Quote from: scrax on January 06, 2013, 04:16:49 PM
compiled ok, and loaded like before, how to check if it worked?
It didn't. The bootloader script needs to be modified to take advantage of the feature.
Edit: maybe a bit quick off the mark. The feature didn't need to do any work because the program was laid out where it should be. Check the file size if you want to know if it had any effect. Probably need to dig through assembly files if you wish to know if it actually is position independent. Compile with -save-temps or disassemble the binary and look for jumps or reads to ML areas that are absolute rather than relative.

@g3gg0: Can we import the libmath source so it would be compiler / toolchain independent?
How easy is splitting code and data sections? Surely that would require patching of the global table?
Can please you give us a run down on using PIC_RESOLVE and other do's and dont's.

Otherwise sounds great. Its a pity though that the ARM946 doesn't have virtual memory :(

g3gg0

i would check location.map. after i checked in a small fix, it links now like this:

../../src/libs/arm-elf-O3-fPIC/libm.a(lib_a-wf_pow.o)
...


                [u]0xe0000000                [/u]. = [u]0xe0000000[/u]

.text           [u]0xe0000000    [/u]0x5065c
                0xe0000000                _text_start = .
*(.text)


but it doesnt boot on 600D :(

yes, we could add newlib to our source, but this would be a kind of overkill imho.
for PIC_RESOLVE(x) see boot-hack.c line 448 where the tasks are overridden.
any function pointers to functions located at 0xE000.... will get fixed to match the ML loading offset.
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

1%

I had same problem as OP and I just commented out the L flags.

Is there a slave proc on 6D for video encoding? It would explain having to load the INI file and MVR config stuff being blank even though there is a "CBR" style rate control function. Does it work this way on 5DIII, they seem very similar.

johnnyrun

Hi all.
I've got the same problem here. Sorry for the necropost.
These are the packages installed in linux mint.

ii  binutils-arm-none-eabi                      2.24-2ubuntu2+4                                     amd64
ii  gcc-arm-none-eabi                           4.8.2-14ubuntu1+6                                   amd64       
ii  libc6-arm64-cross                           2.19-0ubuntu2cross0.10                              all         
ii  libc6-armel-cross                           2.19-0ubuntu2cross1.104                             all         
ii  libc6-armhf-cross                           2.19-0ubuntu2cross1.104                             all         
ii  libc6-dev-arm64-cross                       2.19-0ubuntu2cross0.10                              all         
ii  libc6-dev-armel-cross                       2.19-0ubuntu2cross1.104                             all         
ii  libc6-dev-armhf-armel-cross                 2.19-0ubuntu2cross1.104                             all         
ii  libc6-dev-armhf-cross                       2.19-0ubuntu2cross1.104                             all         
ii  libnewlib-arm-none-eabi                     2.1.0-3                                             all         
ii  linux-libc-dev-arm64-cross                  3.13.0-12.32cross0.10                               all         
ii  linux-libc-dev-armel-cross                  3.13.0-12.32cross1.104                              all         
ii  linux-libc-dev-armhf-cross                  3.13.0-12.32cross1.104                              all 

1% talks abot an "L" flag. But I don't find it. Where is it?


Thank a lot

a1ex

ML has some pre-compiled libraries, so I'd say try this one: https://launchpad.net/gcc-arm-embedded

johnnyrun

Thanks for reply.
I was not pinning the PPA package.
Now I get
"make[1]: *** No rule to make target `/usr//lib/gcc/arm-none-eabi//libgcc.a', needed by `gcc-libgcc.a'.  Stop."


but It's another story