need help creating a custom BSP using buildroot

Sorry my mistake, I left one file out of the repository thinking it was a patch left over that I had applied, but actually it was a patch buildroot is supposed to apply to uclibc so it belongs in the repo.

If you do another 'git pull' and try again hopefully this time you'll get further along.

tried again, this time I *believe* that I got further along, though now Im running into this error:

Code: [Select]

>>> zlib 1.2.7 Building
/usr/bin/make -j1 -C /data/local/apps/openipcam/build/malv/buildroot-openipcam/output/build/zlib-1.2.7
make[1]: Entering directory `/data/local/apps/openipcam/build/malv/buildroot-openipcam/output/build/zlib-1.2.7'
/data/local/apps/openipcam/build/malv/buildroot-openipcam/output/host/usr/bin/ccache /data/local/apps/openipcam/build/malv/buildroot-openipcam/output/host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  -pipe -Os  -Wl,-elf2flt -DBR_BINFMT_FLAT   -D_LARGEFILE64_SOURCE=1 -DNO_STRERROR -DNO_vsnprintf -DHAVE_HIDDEN -o example example.o -L. libz.a
/data/local/apps/openipcam/build/malv/buildroot-openipcam/output/host/usr/lib/gcc/arm-buildroot-linux-uclibcgnueabi/4.8.0/../../../../arm-buildroot-linux-uclibcgnueabi/bin/ld.real: error: no memory region specified for loadable section `.ARM.extab'

So, now its a problem with zlib...
any ideas?

Ok, so now you've gotten as far as I have.  It's not a problem with zlib, it's just that in your case zlib happens to be the first thing that experiences this problem.  The error you see (about ".ARM.extab") is actually the output from elf2flt, when it tries to convert the ELF output from the compiler to the FLAT binary format.

This is the point I haven't been able to get past, so now your work can begin, if you are willing to help :-)

If you just want to see stuff happen, you should be able to run 'make linux' or similar (see "make help" for details) to just compile the kernel itself, as that part does work.  Of course the kernel panics shortly after bootup because it can't run 'init', since you either haven't compiled it or it's not in FLAT format because of the above problem.

Ok, so now you've gotten as far as I have.  It's not a problem with zlib, it's just that in your case zlib happens to be the first thing that experiences this problem.  The error you see (about ".ARM.extab") is actually the output from elf2flt, when it tries to convert the ELF output from the compiler to the FLAT binary format.

This is the point I haven't been able to get past, so now your work can begin, if you are willing to help :-)

If you just want to see stuff happen, you should be able to run 'make linux' or similar (see "make help" for details) to just compile the kernel itself, as that part does work.  Of course the kernel panics shortly after bootup because it can't run 'init', since you either haven't compiled it or it's not in FLAT format because of the above problem.

Have you seen this?

http://git.buildroot.net/buildroot/commit/?id=57c05432917de3b9aec293d713acafde01ac9b07

http://buildroot-busybox.2317881.n4.nabble.com/git-commit-arch-toolchain-Introduce-binary-format-FLAT-types-td44668.html

Don

Thanks for the tip!  Yes I have seen those commits, unfortunately they only affect two variants of FLAT formats which I believe won't work on the processor used by our cameras (plus I got heaps of other compiler errors when I tried to use those formats instead.)  The only variant I am aware of (normal/plain FLAT) isn't affected by those commits.

At any rate those commits are in the buildroot repo I posted that @changosurf is using.

Thanks for the tip!  Yes I have seen those commits, unfortunately they only affect two variants of FLAT formats which I believe won't work on the processor used by our cameras (plus I got heaps of other compiler errors when I tried to use those formats instead.)  The only variant I am aware of (normal/plain FLAT) isn't affected by those commits.

At any rate those commits are in the buildroot repo I posted that @changosurf is using.

You are very welcome.

I wonder if the errors could be related to these other options not being also set properly?

All segments are linked into one memory region.

Allow for the data and text segments to be separated and placed in different regions of memory.

Allow to load and link individual FLAT binaries at run time.

As mentioned here: http://buildroot-busybox.2317881.n4.nabble.com/git-commit-arch-toolchain-Introduce-binary-format-FLAT-types-td44668.html

Don

I might be wrong, but doesnt this error have something to do with the actual linker script, and not so much the elf2flt stuff? I found some related posts and stackoverflow & some other sites that mention this as being a problem with the design of the actual linker commands within the linker script. Apparently, there needs to be a designated segment of memory that is attached to that section, or something to this effect.

Again, Im not an expert *at all* on this subject. In fact, Im currently in the process of trying to read up on the ld command language in order to try to understand how this works. I was able to dig into the linker script and verify that there was in fact an '.ARM.extab.' section, which apparently is meant to handle 'exception unwinding.'

if someone is more knowledgeable on this subject, please jump in, correct me, and fill us in on how this actually works and why ld is failing & barking about the "no memory region specified for loadable section `.ARM.extab'"...

Well if you're not an expert at this then that makes two of us :-)  Where did you find the linker script that mentions ".ARM.extab"?  I couldn't find it.

If this section is used for exception unwinding then that makes sense that it's missing, because that's a C++ feature along with constructors and destructors (which if you remember you had to disable support for in the uclibc config.)  So I'm not sure whether the problem is that this section is supposed to be present, or whether elf2flt is supposed to cope when it's missing.

I did find these notes on building ARM7 FLAT binaries which talk about modifying the linker script, but as I couldn't find the script I haven't tested any of this.

@TheUberOverLoad: Thanks again for jumping in and helping out - the more people looking at this the better!  I don't think those other options are related to the error.  The options that were added are of "choice" type - this means of the options you listed, you can only pick one of them.  We are picking the first one ("One memory region") as I believe that's the only one that works.  The others may also work one day, but from what I've read they will require a bit more effort to get working - so I figure start with the one that's the most likely to work.  My understanding was that the other options were added to make use of some advanced features of the Blackfin processor, but since these cameras have a NUC745 CPU and not a Blackfin, we may not be able to support those other options.

a couple of quick notes:
within the toolchain output directory, 'output/host/usr/lib/gcc/arm-buildroot-linux-uclibcgnueabi/4.8.0/../../../../arm-buildroot-linux-uclibcgnueabi/bin/', the file 'ld' is a bash script that you can open up and inspect, and 'ld.real' is a binary file, yet which also contains an embedded set of 'plain text' linking commands (you can run 'cat ld.real', and after skipping through a bunch of the binary output, you'll be able to see the command section that Im talking about; it's about half way through the file).

the file which contains the 'ARM.extab' sections is the 'ld.real' binary file. the 'ld' bash script doesnt contain any references to 'ARM.extab'

the 'ld' script contains a reference to the elf2flt option & control structures that handle the condition when the '-elf2flt' switch is used...

the 'ld.real' executable, on the other hand, doesnt contain any references to 'elf2flt'.

Could it be that perhaps the build is somehow misconfigured, and pointing to 'ld.real' instead of 'ld', which would know how to handle the elf2flt switch? (I still dont really have a firm understanding of how all of this works, so I realize that this might be way off)

if not, then whats the purpose of ld.real, and/or its relationship to the ld script?


googling the 'ARM.extab' error, you'll find a few different results.
the one I was referring to was this one:
http://stackoverflow.com/questions/13625245/error-in-cross-compilation-in-case-of-using-new-and-delete

Hmm, so it looks like possibly disabling exceptions might help then?

I would guess "ld.real" is the actual linker program, and "ld" is a script which pretends to be the linker so it can manipulate the command line passed to the linker, or something like that.  This would be because the compiler calls the linker directly, so there's no way of influencing how the linker is called.  By making a script take the place of the linker, the compiler will call the script instead, which can do whatever it wants and then call the real linker when it is happy.

I wouldn't worry too much about the difference between "ld" and "ld.real".  Of course if you need to change the way the linker runs, the "ld" script is likely the place to do it!

I don't believe it's a problem with the -elf2flt switch, because if something didn't understand that it would produce an "unknown command line parameter" error instead.  So I'm confident the correct linker is being called, but quite possibly it is using a linker script that is not compatible with our platform.  The question there is how to change it, and to what?

ok, i get it...yeah, after I posted my last message, I realized that the 'ld' file was just a wrapper script for the 'real ld'  & the elf2flt utility. So, now Im currently studying the ld script in order to try to figure out whats going and why its bombing. I think the  error is definitely somewhere within that script. As a test, I modified the zlib makefile and removed the '-elf2flt' switch from the compiler flags. It was able to make it through the zlib build, but then it bombed elsewhere further down the line.

So, like you said, something is broken during that transition from the compiler to the elf2flt 'shim' and then to the actual linker. And, as you stated, if elf2flt was the problem, it would have barked during the conversion, yet it seems to succeed with no issues. so, it seems like its most likely due to the wrapper script; something's not working like its supposed to within that script.

Again, I need to get a better understanding of the internals of the gnu linker, and also how the wrapper (and elf2flt) go about performing the conversion from elf to flat...
thoughts/feedback?

When you remove the elf2flt option it produces an ELF binary successfully and then continues on with the build, not calling elf2flt at all.  You can actually remove the elf2flt option in the buildroot config, and then the entire build will complete successfully, but with ELF binaries instead of FLAT ones.  So the only problem in the entire build process is the elf2flt conversion.

I have just tried the suggestion on one of the Stack Overflow answers, to pass -fno-exceptions and -fno-rtti to gcc.  It didn't make a difference, warning that these are meant for C++ programs anyway and we're only compiling C stuff.

I'm not sure the ld script is at "fault", but I think the solution lies in that area.  I think we probably need to supply a custom linker script somehow.  You should be able to do that without editing any scripts, hopefully just passing the right command-line parameter.

Oh, just discovered the "ld" script you are referring to, which calls "ld.real", is actually supplied by elf2flt.  It is what handles the "-W,-elf2flt" linker option.  The source for this script is in buildroot/toolchain/elf2flt/elf2flt/ld-elf2flt.in

I guess tweaking this to produce the right linker script is the best bet...

ok, makes sense.
looking at the ld script, it looks like it passes a default linker script if the user doesnt supply one as an argument. The default script is located at 'output/host/usr/arm-buildroot-linux-uclibcgnueabi/lib/elf2flt.ld'...if you have some ability to read&understand linker scripts, then you might be able to decipher what's going on...i do see mention of ctors/dtors, which could have been causing the initial problem during the build?

Anyway, perhaps if we modify or simply substitute that script with a working version, we might be good to go...I just wish i was more up to speed and knowledgeable on the subject of linking & the ld command language

Yes, just looking at that script now.  Based on the suggestions from your earlier link I tried adding "*(.ARM.extab*)" to that file, before the gnu.linkonce.s.* line.  I also added this:

Code: [Select]

__exidx_start = .;
.ARM.exidx : { *(.ARM.exidx*) } > flatmem
__exidx_end = .;

Just before the .bss line/section.  It fixed the extab errors, but now there are new ones:

Code: [Select]

ERROR: reloc type R_ARM_PREL31 unsupported in this context
ERROR: reloc type R_ARM_NONE unsupported in this context
ERROR: reloc type R_ARM_PREL31 unsupported in this context
ERROR: reloc type R_ARM_PREL31 unsupported in this context
ERROR: reloc type R_ARM_PREL31 unsupported in this context
ERROR: reloc type R_ARM_PREL31 unsupported in this context
ERROR: reloc type R_ARM_PREL31 unsupported in this context
...

Not sure what that is trying to tell me...