[Buildroot] modifying buildroot for non- linux freertos

[Buildroot] modifying buildroot for non- linux freertos

[Peter Saunderson]

Hi,

I have been using buildroot for embedded linux builds for a while now 
and think its great.  Now I want to use the shell scripts and the 
general buildroot environment to build freertos using newlib rather than 
uclibc.

I have prototyped this but have run into some not unexpected problems 
and thought you guys might be able to help.  If you consider this email 
just spam flame me now and I will go quietly on without further 
disturbing you.

I want to do this because I want control over my build environment, 
because I need OpenOCD, gdb etc etc and because if the tools are ok for 
my embedded linux environment then I can save effort by using close to 
the same tools for simpler freertos solutions.  The buildroot style 
seems just what I need to solve my problem and would allow me to have 
all the control over my build environment that I need in one place.

Stage 1 is to get the tools built and I only need shared libraries so 
that should be simpler.  I keep configuration simple and just have a 
build freertos configuration file (bf1_config) with all the config stuff 
I find I need so I avoid .config and menuconfig for now.  I use the 
scripts in support and build packages from package (so far I found I 
need zlib, perl, mpfr, mpc, m4, libtool, gmp, expat, binutils, automake, 
autoconf).  The tools I am building are patched from files in toolchain 
(so far I have newlib, gdb, gcc).

The problem originates because newlib (http://sourceware.org/newlib/) 
has a different build style to uClibc but using uclibc.mk as a starting 
point for newlib.mk and making major mods I can get most things 
working.  I have built all the output/host/usr/bin tools but 
$(GCC_BUILD_DIR3)/.installed target has not been run so there is no 
$(HOST_DIR)/usr/bin/$(GNU_TARGET_NAME)-cc but my newlib build is trying 
to use it.  So what I think I need to do is delay the build of newlib 
and I am not sure how to do that yet.  So I am puzzling over 
$(GCC_BUILD_DIR1)/.configured:, $(GCC_BUILD_DIR2)/.configured: and 
$(GCC_BUILD_DIR3)/.configured: targets and wondering to myself what bit 
in buildroot sequences these and how can I fit my new newlib targets 
into the right place in the build sequence.  If you have read up to this 
point you may have a view or some tips. Perhaps there is a good guide 
that I have missed that could help?  I did a search of the archive but 
did not find anything that was of immediate assistance.  Perhaps there 
is a better place to ask this question?  Perhaps is such an interesting 
problem that you would like to see me create a new git project for it?

Thanks for your time.

Peter.

[Buildroot] modifying buildroot for non- linux freertos

[Arnout Vandecappelle]

  Hi Peter,

On 15/04/13 23:53, Peter Saunderson wrote:
[snip]
> The problem originates because newlib (http://sourceware.org/newlib/) has
> a different build style to uClibc but using uclibc.mk as a starting point
> for newlib.mk and making major mods I can get most things working.  I
> have built all the output/host/usr/bin tools but
> $(GCC_BUILD_DIR3)/.installed target has not been run so there is no
> $(HOST_DIR)/usr/bin/$(GNU_TARGET_NAME)-cc but my newlib build is trying
> to use it.  So what I think I need to do is delay the build of newlib and
> I am not sure how to do that yet.  So I am puzzling over
> $(GCC_BUILD_DIR1)/.configured:, $(GCC_BUILD_DIR2)/.configured: and
> $(GCC_BUILD_DIR3)/.configured: targets and wondering to myself what bit
> in buildroot sequences these and how can I fit my new newlib targets into
> the right place in the build sequence.  If you have read up to this point
> you may have a view or some tips. Perhaps there is a good guide that I
> have missed that could help?  I did a search of the archive but did not
> find anything that was of immediate assistance.  Perhaps there is a
> better place to ask this question?  Perhaps is such an interesting
> problem that you would like to see me create a new git project for it?

  I'm afraid that the expertise on the internal buildroot toolchain build 
process is not here anymore. Some buildroot developers understand how the 
.mk file works, but not really why things were done in that particular way...

  But anyway, I don't think you really need buildroot for this. Buildroot 
is meant for building packages for the target, and just builds some host 
packages that are needed for building some of these packages. I think 
crosstool-NG is a much better fit for your purpose. It's build system is 
pretty complex, but I think it's still easier to understand than the 
buildroot system. Also, crosstool-NG might be interested in adding 
support for newlib (as an alternative to uClibc) in its core infrastructure.

  BTW, you could also consider looking at musl instead of newlib.

  Regards,
  Arnout
-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] modifying buildroot for non- linux freertos

[Thomas Petazzoni]

Peter, Arnout,

On Wed, 17 Apr 2013 08:23:22 +0200, Arnout Vandecappelle wrote:

>   I'm afraid that the expertise on the internal buildroot toolchain build 
> process is not here anymore. Some buildroot developers understand how the 
> .mk file works, but not really why things were done in that particular way...
> 
>   But anyway, I don't think you really need buildroot for this. Buildroot 
> is meant for building packages for the target, and just builds some host 
> packages that are needed for building some of these packages. I think 
> crosstool-NG is a much better fit for your purpose. It's build system is 
> pretty complex, but I think it's still easier to understand than the 
> buildroot system. Also, crosstool-NG might be interested in adding 
> support for newlib (as an alternative to uClibc) in its core infrastructure.

Crosstool-NG already has support for newlib.

Peter, I agree with Arnout here. The main point of Buildroot is to
build a root filesystem with Linux applications and libraries, and this
is not something you could re-use on FreeRTOS.

You should therefore definitely have a look at Crosstool-NG to produce
a newlib toolchain that works for FreeRTOS.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com