[Buildroot] Best way of building for unknown architecture

[Buildroot] Best way of building for unknown architecture

[Kevin Chadwick]

Hi,

	Openembedded, T2 and NuttX seem to support arm7-m (cortex-m3)
	but I like buildroot. Is the best way of building to use Little
	endian generic and the GCC compiler or is it fairly easy to add
	a new architecture variant that I could possibly send a diff
	for later.

	Similarly is it easier to use the kernel patch config and kernel
	config options or is it fairly easy to add a Target
	architecture.

Thanks,

Kc

-- 
_______________________________________________________________________

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
_______________________________________________________________________

[Buildroot] Best way of building for unknown architecture

[Thomas Petazzoni]

Le Fri, 17 Aug 2012 18:39:55 +0100,
Kevin Chadwick <ma1l1ists@yahoo.co.uk> a ?crit :

> 	Openembedded, T2 and NuttX seem to support arm7-m (cortex-m3)
> 	but I like buildroot. Is the best way of building to use Little
> 	endian generic and the GCC compiler or is it fairly easy to add
> 	a new architecture variant that I could possibly send a diff
> 	for later.

Adding a new target architecture variant just requires a few lines of
code in target/Config.in.arch. If you give some hints, I'm pretty sure
someone will be kind enough to help you making the necessary changes.

> 	Similarly is it easier to use the kernel patch config and kernel
> 	config options or is it fairly easy to add a Target
> 	architecture.

In 'make menuconfig', Kernel submenu, there is an option to point to
kernel patches needed for your platform.

Best regards,

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

[Buildroot] Best way of building for unknown architecture

[Kevin Chadwick]

On Fri, 17 Aug 2012 19:43:10 +0200
Thomas Petazzoni wrote:

> > 	Openembedded, T2 and NuttX seem to support arm7-m (cortex-m3)
> > 	but I like buildroot. Is the best way of building to use Little
> > 	endian generic and the GCC compiler or is it fairly easy to add
> > 	a new architecture variant that I could possibly send a diff
> > 	for later.  
> 
> Adding a new target architecture variant just requires a few lines of
> code in target/Config.in.arch. If you give some hints, I'm pretty sure
> someone will be kind enough to help you making the necessary changes.
> 

This patch seems to add the --with-arch="armv7-m" and
--with-tune="cortex-m3" when cortex-m3 is selected.


--- target/Config.in.arch.old	2012-08-15 11:11:48.000000000 +0100
+++ target/Config.in.arch	2012-08-20 07:48:03.224810072 +0100
@@ -172,6 +172,8 @@
 	bool "arm1176jz-s"
 config BR2_arm1176jzf_s
 	bool "arm1176jzf-s"
+config BR2_cortex_m3
+	bool "cortex-m3"
 config BR2_cortex_a8
 	bool "cortex-A8"
 config BR2_cortex_a9
@@ -204,6 +206,7 @@
 	default ARM_SA1100	if BR2_sa1100
 	default ARM_XSCALE	if BR2_xscale
 	default ARM_IWMMXT	if BR2_iwmmxt
+	default ARM_CORTEXM3	if BR2_cortex_m3
 	default ARM_CORTEXA8	if BR2_cortex_a8
 	default ARM_CORTEXA9	if BR2_cortex_a9
 
@@ -734,6 +737,7 @@
 	default arm1136jf-s	if BR2_arm1136jf_s
 	default arm1176jz-s	if BR2_arm1176jz_s
 	default arm1176jzf-s	if BR2_arm1176jzf_s
+	default cortex-m3	if BR2_cortex_m3
 	default cortex-a8	if BR2_cortex_a8
 	default cortex-a9	if BR2_cortex_a9
 	default strongarm110	if BR2_sa110
@@ -841,6 +845,7 @@
 	default armv6j		if BR2_arm1136jf_s
 	default armv6zk		if BR2_arm1176jz_s
 	default armv6zk		if BR2_arm1176jzf_s
+	default armv7-m		if BR2_cortex_m3
 	default armv7-a		if BR2_cortex_a8
 	default armv7-a		if BR2_cortex_a9
 	default armv4		if BR2_sa110


www.linux-arm.org/LinuxKernel/LinuxM3 suggests that the following should
be added to build busybox


-mthumb -Wl,-elf2flt=-s -Wl,-elf2flt=16384

and I think

-mfloat-abi=soft might be a good idea for this cpu too


I have successfully built arm binaries with the inbuilt toolchain
manually using

-march=armv7-m -mtune=cortex-m3 -mthumb -mfloat-abi=soft

but the -Wl linker option flags fail and I am not sure how to add
-mthumb and -mfloat-abi=soft to buildroot though it does already have
--with-float=soft enabled?

________________________________________________________________________

I wanted to test it so I extracted a fresh buildroot and pointed the
external chain to the already built uclibc internal toolchain
(built before patching with above) where I had selected NO_MMU before
building.

When I ran make I got

Checking external toolchain settings
MMU support available in C library, please enable BR2_USE_MMU

This chip has no MMU but does have an MPU, do I need to rebuild the
toolchain with this patch, bypass/fix this error or enable MMU and
select not to use MMU or something else?

Thanks,

	Kc

[Buildroot] Best way of building for unknown architecture

[Thomas Petazzoni]

Hello,

Le Mon, 20 Aug 2012 17:27:49 +0100,
Kevin Chadwick <ma1l1ists@yahoo.co.uk> a ?crit :

> This patch seems to add the --with-arch="armv7-m" and
> --with-tune="cortex-m3" when cortex-m3 is selected.

Correct.

> www.linux-arm.org/LinuxKernel/LinuxM3 suggests that the following
> should be added to build busybox
> 
> -mthumb -Wl,-elf2flt=-s -Wl,-elf2flt=16384

-mthumb can be added to the BR2_TARGET_OPTIMIZATION option, though at
some point, it might be good to add an option to build ARM code with
the ARM instruction set, or the Thumb instruction set, or the Thumb-2
instruction set.

The elf2flt option define the stack size, and we have a similar need
for Blackfin. Maybe we need to define a "Flat" ABI for ARM, and when
this option is enabled, offer an option to define the default stack
size passed to elf2flt.

> and I think
> 
> -mfloat-abi=soft might be a good idea for this cpu too

If you select BR2_PREFER_SOFT_FLOAT, then the compiler will be built to
generate soft float code by default, so there's nothing to do.

> I have successfully built arm binaries with the inbuilt toolchain
> manually using
> 
> -march=armv7-m -mtune=cortex-m3 -mthumb -mfloat-abi=soft
> 
> but the -Wl linker option flags fail and I am not sure how to add
> -mthumb and -mfloat-abi=soft to buildroot though it does already have
> --with-float=soft enabled?

Hum, I would have to test myself to give more details here.

> I wanted to test it so I extracted a fresh buildroot and pointed the
> external chain to the already built uclibc internal toolchain
> (built before patching with above) where I had selected NO_MMU before
> building.
> 
> When I ran make I got
> 
> Checking external toolchain settings
> MMU support available in C library, please enable BR2_USE_MMU
> 
> This chip has no MMU but does have an MPU, do I need to rebuild the
> toolchain with this patch, bypass/fix this error or enable MMU and
> select not to use MMU or something else?

It is due to the fact that the uClibc headers define __ARCH_USE_MMU__.
This is because uClibc has been built with MMU support. In fact, the
Buildroot toolchain backend for now doesn't support building non-MMU
toolchains. But it could probably be added relatively easily.

In toolchain/uClibc/uclibc.mk, you would have to tweak the
uClibc .config (like we already do for many options) so as to disable
the ARCH_USE_MMU uClibc option when BR2_USE_MMU is disabled.

Something along the lines of (completely untested):

diff --git a/toolchain/uClibc/uclibc.mk b/toolchain/uClibc/uclibc.mk
index 9d0b6db..0eb11c0 100644
--- a/toolchain/uClibc/uclibc.mk
+++ b/toolchain/uClibc/uclibc.mk
@@ -245,6 +245,9 @@ ifneq ($(UCLIBC_TARGET_ENDIAN),)
                -e 's/.*\(ARCH_WANTS_$(UCLIBC_TARGET_ENDIAN)_ENDIAN\).*/\1=y/g' \
                $(UCLIBC_DIR)/.oldconfig
 endif
+ifeq ($(BR2_USE_MMU),)
+       $(SED) 's,.*ARCH_USE_MMU.*,# ARCH_USE_MMU is not set,g' $(UCLIBC_DIR)/.oldconfig
+endif
 ifeq ($(BR2_LARGEFILE),y)
        $(SED) 's,.*UCLIBC_HAS_LFS.*,UCLIBC_HAS_LFS=y,g' $(UCLIBC_DIR)/.oldconfig
 else

However, besides this option, you will also probably need to adjust the
uClibc configuration to add support for FLAT binaries.

The no-MMU support for ARM is basically non-existent for now in
Buildroot, but I'm interested in having that integrated, so I'll try to
help you getting this working.

Hope this helps,

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

[Buildroot] Best way of building for unknown architecture

[Kevin Chadwick]

On Tue, 21 Aug 2012 09:35:27 +0200
Thomas Petazzoni wrote:

> 
> -mthumb can be added to the BR2_TARGET_OPTIMIZATION option, though at
> some point, it might be good to add an option to build ARM code with
> the ARM instruction set, or the Thumb instruction set, or the Thumb-2
> instruction set.
> 

I tried it with -pipe -mthumb and just -mthumb but I don't think it
worked because I get the following error.
________________________________________________________________________

AS lib/crt1.o
libc/sysdeps/linux/arm/crt1.S:1:0: error: target CPU does not support
ARM mode
make[1]: *** [lib/crt1.o] Error 1
make[1]: Leaving directory
`/usr/src/buildroot-toolchain/output/toolchain/uClibc-0.9.33.2'
make: ***
[/usr/src/buildroot-toolchain/output/toolchain/uClibc-0.9.33.2/.configured]
Error 2
________________________________________________________________________

This is the same error as when using the appropriate -mtune=cortex-m3
-march=armv7-m flags manually on the commandline without -mthumb. With
-mthumb added it then compiles fine from the commandline without the
"target cpu does not support ARM mode" error.
 

Is this relevent?

http://lists.uclibc.org/pipermail/buildroot/2008-December/011988.html


> 
> > I wanted to test it so I extracted a fresh buildroot and pointed the
> > external chain to the already built uclibc internal toolchain
> > (built before patching with above) where I had selected NO_MMU before
> > building.
> > 
> > When I ran make I got
> > 
> > Checking external toolchain settings
> > MMU support available in C library, please enable BR2_USE_MMU
> > 
> > This chip has no MMU but does have an MPU, do I need to rebuild the
> > toolchain with this patch, bypass/fix this error or enable MMU and
> > select not to use MMU or something else?
> 
> It is due to the fact that the uClibc headers define __ARCH_USE_MMU__.
> This is because uClibc has been built with MMU support. In fact, the
> Buildroot toolchain backend for now doesn't support building non-MMU
> toolchains. But it could probably be added relatively easily.
> 
> In toolchain/uClibc/uclibc.mk, you would have to tweak the
> uClibc .config (like we already do for many options) so as to disable
> the ARCH_USE_MMU uClibc option when BR2_USE_MMU is disabled.
> 
> Something along the lines of (completely untested):
> 
> diff --git a/toolchain/uClibc/uclibc.mk b/toolchain/uClibc/uclibc.mk
> index 9d0b6db..0eb11c0 100644
> --- a/toolchain/uClibc/uclibc.mk
> +++ b/toolchain/uClibc/uclibc.mk
> @@ -245,6 +245,9 @@ ifneq ($(UCLIBC_TARGET_ENDIAN),)
>                 -e 's/.*\(ARCH_WANTS_$(UCLIBC_TARGET_ENDIAN)_ENDIAN\).*/\1=y/g' \
>                 $(UCLIBC_DIR)/.oldconfig
>  endif
> +ifeq ($(BR2_USE_MMU),)
> +       $(SED) 's,.*ARCH_USE_MMU.*,# ARCH_USE_MMU is not set,g' $(UCLIBC_DIR)/.oldconfig
> +endif
>  ifeq ($(BR2_LARGEFILE),y)
>         $(SED) 's,.*UCLIBC_HAS_LFS.*,UCLIBC_HAS_LFS=y,g' $(UCLIBC_DIR)/.oldconfig
>  else
> 
> However, besides this option, you will also probably need to adjust the
> uClibc configuration to add support for FLAT binaries.
> 


Yep it worked but unfortunately I get

______________________________________________________________________

  CC libc/unistd/usleep.os
  AS libpthread/nptl/sysdeps/unix/sysv/linux/arm/clone.os
  AS libpthread/nptl/sysdeps/unix/sysv/linux/arm/vfork.os
  CC libpthread/nptl/sysdeps/unix/sysv/linux/arm/fork.os
In file included from
  libpthread/nptl/sysdeps/unix/sysv/linux/arm/fork.c:31:0:
  libpthread/nptl/sysdeps/unix/sysv/linux/arm/../fork.c:61:17: error:
  'fork' undeclared here (not in a function)
  libpthread/nptl/sysdeps/unix/sysv/linux/arm/../fork.c:61:23: warning:
  type defaults to 'int' in declaration of '__libc_fork'
  libpthread/nptl/sysdeps/unix/sysv/linux/arm/../fork.c:63:1: error:
  '__libc_fork' redeclared as different kind of symbol
  libpthread/nptl/sysdeps/unix/sysv/linux/arm/../fork.c:61:23: note:
  previous declaration of '__libc_fork' was here
  libpthread/nptl/sysdeps/unix/sysv/linux/arm/../fork.c:227:1: warning:
  type defaults to 'int' in declaration of 'fork'
  libpthread/nptl/sysdeps/unix/sysv/linux/arm/../fork.c:228:1: error:
  'fork' redeclared as different kind of symbol
  libpthread/nptl/sysdeps/unix/sysv/linux/arm/../fork.c:227:1: note:
  previous declaration of 'fork' was here
  libpthread/nptl/sysdeps/unix/sysv/linux/arm/../fork.c:229:1: error:
  '__EI_fork' aliased to undefined symbol '__GI_fork'
  libpthread/nptl/sysdeps/unix/sysv/linux/arm/../fork.c:229:1: error:
  '__EI_fork' aliased to undefined symbol '__GI_fork' make[1]: ***
  [libpthread/nptl/sysdeps/unix/sysv/linux/arm/fork.os] Error 1
  make[1]: Leaving directory
  `/usr/src/buildroot-toolchain-nommu/output/toolchain/uClibc-0.9.33.2'
  make: ***
  [/usr/src/buildroot-toolchain-nommu/output/toolchain/uClibc-0.9.33.2/lib/libc.a]
  Error 2
________________________________________________________________________


This link suggests it may be the kernel headers.

http://old.nabble.com/uClibc-compilation-error-with-nommu-td22424490.html


> The no-MMU support for ARM is basically non-existent for now in
> Buildroot, but I'm interested in having that integrated, so I'll try to
> help you getting this working.
> 

With blackfin working and without major changes and with ucLinux
starting as nommu, I assumed the support was mostly there. Do you think
it will be fairly trivial for us to sort out or I would be better off
looking at ucLinux or Openembedded?

Thanks,

Kc