Re-organized the forum to more cleanly delineate the development section, as the end user support side appears to have taken a life of its own!

Author Topic: need help creating a custom BSP using buildroot  (Read 32976 times)

June 03, 2013, 08:47:43 pm
Id like to try building an updated kernel using the buildroot tool.
However, I need help figuring out how to go about creating a 'vendor package' for the NUC745/W90N745 chip.
I have the old BSP for the 2.4 kernel, but Im not sure how to go about trying to 'patch' it into a newer kernel. Can someone please provide me with some basic instructions on how this process works? which files from the BSP need to be ported over to the new kernel, and what needs to be done to integrate them into the newer build?

  • **
June 04, 2013, 05:00:08 am
I'm in the progress of porting the 2.6 BSP to the git version of the kernel.  It's fairly involved, so unless you have experience writing kernel code it's going to drive you crazy.

I haven't posted my code yet as the port is incomplete, and without any way I can boot to userspace I'm kind of stuck as anything more I port I can't test (e.g. USB support or MTD partitions.)

The real problem is that once you get a recent kernel up and running, there seems to be no way to generate FLAT binaries required by a no-MMU kernel (all the binaries come out in ELF format which is unusable without an MMU.)  buildroot certainly doesn't support this any longer, but they have said they welcome any patches.

I don't foresee any problems porting the rest of the NUC700-series support code to the latest kernel myself, so if you're willing to help, it would be fantastic if you could figure out how to get buildroot to compile FLAT binaries instead of ELF, since this is really what's holding me up and I'm rather stuck on it.  Not to mention that once the NUC700 is supported natively by the kernel, FLAT binary support in buildroot will be required to build any sort of userspace programs without using the Nuvoton/Winbond BSP.

June 04, 2013, 06:17:09 am
I would be glad to help.
I'll start looking into the ZFLAT issue right away.
Im just barely starting to learn about buildroot & its internals, so it will take me a little bit of time to get up to speed. But I will definitely start by focusing on the ZFLAT build problem.

But, if you don't mind, could you please try to explain the overall process of how the BSP code is 'ported' from one kernel to another? This is the main concept Im struggling with; I dont know where to start, what files need to be modified, how to integrate such a port into a kernel build (via buildroot or a git pull, a manual kernel source download, etc.), and basically what the primary/key objectives are in the porting process...

I understand that there is a small subset of files & folders that are specific to our processor (such as vendors/nuvoton, arch/arm/*nuc700*, etc). I understand that these source files contain platform-specific code, but Im not clear on how to integrate those files into the kernel build, and how to make the build configuration correctly 'point to' and integrate those files/directories into the actual build...

BTW,I feel comfortable digging into kernel code, but I do lack experience working with it (which is one of my main motivations for working with this project; to learn more about kernel coding & embedded system development). So, I wouldn't mind 'going crazy' analyzing a bunch of source code in order to try to get the BSP ported to a newer kernel, since I'd consider it a great challenge. I just need some help, tips, & advice on how to get started...

I just performed a quick search and took a look at the configuration options for building the toolchain/uclibc in buildroot. it *appears* that there are options for disabling MMU support, and also for enabling 'elf2flt' functionality. Have you tried these options? if not, how can we go about setting a test build? can you please send me your build config?
« Last Edit: June 04, 2013, 06:30:41 am by changosurf »

  • **
June 06, 2013, 04:18:02 am
Sure I'd be happy to help - I just don't want to waste effort having two people work on porting the kernel and nobody working on getting userspace up and running!

Briefly, you add options to the appropriate Kconfig file so that they appear in 'make menuconfig' or similar.  In our case we're adding a new architecture, so the file will be in the arch/arm/ directory.  Adding the appropriate option allows you to select the new architecture in the kernel config.  This then sets some variables which are passed through to the Makefile, and in there you basically have things that say "if this option is set, compile this file too".

In those files you then implement certain functions the kernel always calls (like a function to print a message very early in the boot process), as well as certain data structures which describe which devices are always present on your platform (in this case things like the built in UARTs and USB ports on the processor itself.)

As for the ZFLAT support, yes I've tried those options but they break with weird compile errors I have yet to figure out.  Someone from the OpenWRT team pointed me at a very old version of buildroot which is supposed to have working ZFLAT support (which could be ported to the latest buildroot) but I haven't had a chance to test it yet.  It's at

The buildroot developers seem quite happy to accept patches to get ZFLAT working again, as well as test configurations they can add to their regular test suite so they can avoid breaking it again.  It is my hope to get an NUC745 config added to buildroot they can use for regular testing to make sure it doesn't break again.

I will try to post my buildroot config and associated NUC700 patches for buildroot this weekend so you can start experimenting.  It seems this is actually an even greater challenge than porting the kernel code itself!

June 07, 2013, 07:35:15 pm
That sounds great; I'll be waiting for your patches/config.

userspace seems alot easier doesnt it?
up until recently, I had a working build environment for the 3.1 kernel (listed in the sticky post in this forum). unfortunately, that build environment was 'damaged' and I could no longer successfullly compile the 3.1 kernel. The repositories listed in the sticky post no longer work (it seems that this project is almost abandoned?). So, I havent been able to 'start from scratch' using the instructions listed here on the forum..

but, during the time I had a compilable kernel, I was working toward building a userspace package that would include webserver & mjpg camera streaming utitlity. The only problem was the stepper motor control. Recently, there was a 'breakthrough' on this, and I was finally able to get some code that would run the motors (more info on this is available in the hacking/mod forum). Unfortunately, I lost my build environment and now Im trying to start over with buildroot.

« Last Edit: June 07, 2013, 07:36:58 pm by changosurf »

  • **
June 09, 2013, 02:46:52 am
Userspace would be easier if it was possible to actually compile a program!  But since it's currently not possible to compile ZFLAT binaries with buildroot, it's a bit of a stumbling block.

I've cleaned up some of the kernel code and I'm pushing it to GitHub here:

If you just want to boot a kernel to see whether it works, try this one.  Just use the "mt" command in the bootloader, and TFTP it onto the device with something like this:
Code: [Select]
tftp -v -m binary -c put zImage

There's still more stuff I have to finish cleaning up (e.g. USB and Ethernet support) so the kernel is still a little incomplete.  The kernel zImage above has all this stuff compiled in it though.

I'll have a go at preparing my buildroot patches next.

  • **
June 09, 2013, 03:15:17 am
And here are my buildroot patches:

You should be able to clone the nuc700 branch of that repo and use the nuc745_defconfig to build it all.  That config will pull the kernel source in from the git repo in my previous post, so you shouldn't have to do anything special there.

But I haven't tested it, so let me know if it breaks :-)

June 09, 2013, 07:39:39 pm
a couple of questions:
1) what toolchain did you use to compile the nuc700 branch?

2) what exactly do I need to do to apply the buildroot patches? how should I use that repository? I apologize, but I need instructions. Im not clear on what to do with the files in that repo.

  • **
June 10, 2013, 01:55:37 am
buildroot automatically downloads and compiles the necessary toolchain, so you don't need one installed on your system already.

If you clone the buildroot repository, that should be pretty much all you need.  If you follow the buildroot manual all you should need to do is select the nuc700 "defconfig", run "make" and then some hours later end up with a working firmware.

Of course this is how it's supposed to work, but since the no-MMU support is a bit flakey, it will most likely just fail somewhere in the build process and then the real work begins, figuring out how to fix it!

June 10, 2013, 05:09:26 am
ok, I cloned the buildroot repo, ran 'make menuconfig', selected the relevant options (target arch, nommu, processor, etc), ran make, and ran into the following errors:
Code: [Select]
buildroot-openipcam/output/host/usr/arm-buildroot-linux-uclibcgnueabi/bin/ld: cannot find crti.o: No such file or directory
buildroot-openipcam/output/host/usr/arm-buildroot-linux-uclibcgnueabi/bin/ld: cannot find crtn.o: No such file or directory

any ideas on how to solve this?
FYI, I found this which I believe describes a similar problem:

however, Im not clear on how to apply that solution this this problem with buildroot.

« Last Edit: June 10, 2013, 05:16:49 am by changosurf »

  • **
June 10, 2013, 04:34:07 pm
Did you switch to the nuc700 branch before compiling?  This is an error that should be fixed by one of my additional commits in that branch.

June 10, 2013, 04:47:32 pm
here's what I did:
Code: [Select]
#inside my working directory
git clone
cd buildroot-openipcam
make clean #just in case
make nuc745_defconfig
#...compilation begins
# bombs on missing crti.o/crtn.o errors
any other ideas?

I'm starting over from scratch right now, deleting/re-cloning the repo to see if it fixes the problem.
FYI, Im building on a 64bit machine (though I dont believe it should even matter, since its cross-compiling for a different arch).

i just tried starting all over, deleted the local copy of the repo, re-cloned it, and ran 'make nu745_defconfig' and 'make', but I still get the same error.
« Last Edit: June 10, 2013, 05:43:43 pm by changosurf »

June 11, 2013, 04:43:10 am
I tried digging through all of the config & makefiles, trying to find the source of the problem with the missing files. I got about as far as seeing that the problem appears to arise in the uClibc build, where there are a few different sets of conditions that determine whether or not to build the crt*.o objects.

I googled the issue, yet I couldnt find much except for some info that indicated that those object libraries are associated with CTOR/DTOR C constructor/destructor routines associated with ELF binary files (I might be incorrect about this though). Since its related to ELF, I dont know if compilation of those objects is necessary.

In any case, I tried editing the file in {build_dir}/toolchain/uClibc folder, and commenting out the line that tries to include those files in the linkage (@ around line 440). The build was able to progress further, but then failed again with the same error at a later step.

So, I can't seem to find the right place in the build process to enable the compilation of those crt*.o files...

  • **
June 12, 2013, 04:53:14 am
You shouldn't have to delete-reclone the repo, you can use a variant of 'git reset' to return it to a fresh state.  You can also run "make O=/path/to/output/dir" to put all the build fluff and the output images in a folder separate to the git repo.  Then cleaning it is as simple as deleting that folder.

You must have the correct branch given that 'make nuc745_defconfig' works.  Try running "git branch" and confirm it says "nuc700" and not "master".  I've updated the default config so try a 'git pull' before going again, however I don't think this will affect your issue.

If you don't have any luck I'll try to build it from scratch this weekend to see if I can replicate the issue.  In the mean time, going into the uclibc config ('make uclibc-menuconfig') and under 'General Library Settings' the option 'Support global constructors and destructors' should be disabled.  If it's not, either the uclibc settings aren't being picked up or I haven't yet told buildroot to force that setting off for ARM7TDMI platforms.

June 12, 2013, 06:00:54 am
tried everything you suggested:
- reset the repo using 'git reset'
- ran the 'git branch' command and verified that I was on the nuc745 branch
- 'make clean && make nuc745_defconfig'
- 'make uclibc-menuconfig' and verified that the 'Support global constructors...' option was DISABLED
- 'make' and still ran into the same errors 'cannot find crti.o/crtn.o...'

so Im pretty much stuck, it seems there's something broken somewhere within the makefiles/config files...