ARM Cortex-M support
cover ARM Cortex-M support
Hello,
This series of patches brings to Buildroot the support for ARM Cortex-M systems. We already had the choice of Cortex-M3 in menuconfig, but that was pretty much it. This set of patches bring support for:
- Building a Cortex-M toolchain with the internal toolchain backend. This is based on an initial patch from Paul Enman, around which numerous fixes have been added.
- Cortex-M4, including EABIhf for FPv4-SP, the FPU used in some Cortex-M4. Note however that there doesn't seem to be any FPU support in the kernel yet for ARMv7-M, so in practice this cannot be used today.
- Two defconfigs for Cortex-M4 platforms from STMicro. Those defconfigs were submitted by Lee Jones, and are included in this patch series after being tweaked to generate working configurations with the internal toolchain backend (plus other tweaks/simplifications).
- Misc other fixes/improvements related to Cortex-M support, or building toolchains for Thumb/Thumb2.
The whole thing has been tested on STM32F429.
Thanks!
Thomas
Lee Jones (2):
configs/stm32f429_disco: new configuration for STM32F429 Discovery
board
configs/stm32f469_disco: new configuration for STM32F469 Discovery
board
Paul Enman (1):
uclibc: Enable compile in thumb mode when selected
Thomas Petazzoni (13):
arch/arm: introduce and use BR2_ARM_CPU_ARMV7M arch/arm: Cortex-M3 provides only Thumb-2
arch/arm: add Cortex-M4 entry
uclibc: disable DOPIC on ARM noMMU
uclibc: NPTL thread implementation only available on MMU platforms
musl: build broken on Thumb, use ARM mode
toolchain-buildroot: update glibc comment for noMMU
toolchain-buildroot: don't show musl on noMMU platforms arch/arm: add support for hard-float on Cortex-M4 package/Makefile.in: adjust LDFLAGS for elf2flt
elf2flt: use new upstream site and add ARM patch
elf2flt: disable Werror to avoid build issues
afboot-stm32: use the Buildroot toolchain
arch/Config.in.arm | 33 +- board/stmicroelectronics/busybox-minimal.config | 1057 ++++++++++++++++++++ board/stmicroelectronics/stm32-post-build.sh | 8 + board/stmicroelectronics/stm32f429-disco/flash.sh | 20 + ...49-disco-don-t-force-init-in-chosen-boota.patch | 32 + .../stmicroelectronics/stm32f429-disco/readme.txt | 30 + board/stmicroelectronics/stm32f469-disco/flash.sh | 20 + .../linux/0001-kernel-add-top-compatible.patch | 25 + .../patches/linux/0002-kernel-new-dts-file.patch | 114 +++ .../linux/0003-kernel-config-frag-ram.patch | 28 + .../patches/openocd/0001-add-config.patch | 37 + .../patches/openocd/0002-flash-nor.patch | 37 + .../stmicroelectronics/stm32f469-disco/readme.txt | 19 + .../0001-Use-ld-instead-of-gcc-for-linking.patch | 61 ++ boot/afboot-stm32/afboot-stm32.mk | 2 +- configs/stm32f429_disco_defconfig | 18 + configs/stm32f469_disco_defconfig | 19 + package/Makefile.in | 2 +- .../0001-allow-to-build-arm-flat-binaries.patch | 123 +++ package/elf2flt/elf2flt.mk | 8 +- package/musl/musl.mk | 5 + package/uclibc/Config.in | 2 + package/uclibc/uclibc.mk | 28 +- toolchain/toolchain-buildroot/Config.in | 4 + 24 files changed, 1721 insertions(+), 11 deletions(-) create mode 100644 board/stmicroelectronics/busybox-minimal.config create mode 100755 board/stmicroelectronics/stm32-post-build.sh create mode 100755 board/stmicroelectronics/stm32f429-disco/flash.sh create mode 100644 board/stmicroelectronics/stm32f429-disco/patches/linux/0001-ARM-stm32f249-disco-don-t-force-init-in-chosen-boota.patch create mode 100644 board/stmicroelectronics/stm32f429-disco/readme.txt create mode 100755 board/stmicroelectronics/stm32f469-disco/flash.sh create mode 100644 board/stmicroelectronics/stm32f469-disco/patches/linux/0001-kernel-add-top-compatible.patch create mode 100644 board/stmicroelectronics/stm32f469-disco/patches/linux/0002-kernel-new-dts-file.patch create mode 100644 board/stmicroelectronics/stm32f469-disco/patches/linux/0003-kernel-config-frag-ram.patch create mode 100644 board/stmicroelectronics/stm32f469-disco/patches/openocd/0001-add-config.patch create mode 100644 board/stmicroelectronics/stm32f469-disco/patches/openocd/0002-flash-nor.patch create mode 100644 board/stmicroelectronics/stm32f469-disco/readme.txt create mode 100644 boot/afboot-stm32/0001-Use-ld-instead-of-gcc-for-linking.patch create mode 100644 configs/stm32f429_disco_defconfig create mode 100644 configs/stm32f469_disco_defconfig create mode 100644 package/elf2flt/0001-allow-to-build-arm-flat-binaries.patch
Signature · 1 line
2.6.4
PATCH 1/16 arch/arm: introduce and use BR2_ARM_CPU_ARMV7M
All ARM cores should select a BR2_ARM_CPU_* option. Currently, the cortex-m3 does not, which this commit fixes by introducing a BR2_ARM_CPU_ARMV7M option.
--- arch/Config.in.arm | 4 ++++ 1 file changed, 4 insertions(+)
arch/Config.in.arm +4 -0
@@ -52,6 +52,9 @@ config BR2_ARM_CPU_ARMV6 config BR2_ARM_CPU_ARMV7A bool +config BR2_ARM_CPU_ARMV7M + bool + choice prompt "Target Architecture Variant" depends on BR2_arm || BR2_armeb
@@ -171,6 +174,7 @@ config BR2_cortex_m3 bool "cortex-M3" select BR2_ARM_CPU_HAS_THUMB select BR2_ARM_CPU_HAS_THUMB2 + select BR2_ARM_CPU_ARMV7M config BR2_fa526 bool "fa526/626" select BR2_ARM_CPU_HAS_ARM
Signature · 1 line
2.6.4
PATCH 1/16 arch/arm: introduce and use BR2_ARM_CPU_ARMV7M
Quoted 5 lines · Thomas Petazzoni
All ARM cores should select a BR2_ARM_CPU_* option. Currently, the cortex-m3 does not, which this commit fixes by introducing a
BR2_ARM_CPU_ARMV7Moption.Signed-off-by Thomas Petazzoni <[email protected]>
Regards,
Arnout
Quoted 27 lines
--- arch/Config.in.arm | 4 ++++ 1 file changed, 4 insertions(+)arch/Config.in.arm +4
-0@@ -52,6 +52,9 @@ config BR2_ARM_CPU_ARMV6 config BR2_ARM_CPU_ARMV7A bool +config BR2_ARM_CPU_ARMV7M + bool + choice prompt "Target Architecture Variant" depends on BR2_arm || BR2_armeb@@ -171,6 +174,7 @@ config BR2_cortex_m3 bool "cortex-M3" select BR2_ARM_CPU_HAS_THUMB select BR2_ARM_CPU_HAS_THUMB2 + select BR2_ARM_CPU_ARMV7M config BR2_fa526 bool "fa526/626" select BR2_ARM_CPU_HAS_ARM
Signature · 6 lines
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: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
PATCH 2/16 arch/arm: Cortex-M3 provides only Thumb-2
In reply to Thomas PetazzoniThe Cortex-M cores only support Thumb-2, not Thumb. In fact, Thumb-2 is a superset of Thumb, and we could have a single option for both in Buildroot, since -mthumb on ARMv4/v5 means original Thumb, while -mthumb on ARMv7 means Thumb 2. However, for clarity, it makes sense to have two separate options. But in this case, Cortex-M3 should not advertise that it supports Thumb, as in fact selecting Thumb would generate Thumb-2 code.
--- arch/Config.in.arm | 1 - 1 file changed, 1 deletion(-)
arch/Config.in.arm +0 -1
@@ -172,7 +172,6 @@ config BR2_cortex_a17 select BR2_ARCH_HAS_MMU_OPTIONAL config BR2_cortex_m3 bool "cortex-M3" - select BR2_ARM_CPU_HAS_THUMB select BR2_ARM_CPU_HAS_THUMB2 select BR2_ARM_CPU_ARMV7M config BR2_fa526
Signature · 1 line
2.6.4
PATCH 2/16 arch/arm: Cortex-M3 provides only Thumb-2
Quoted 2 lines · Thomas Petazzoni
The Cortex-M cores only support Thumb-2, not Thumb. In fact, Thumb-2 is a superset of Thumb,
If thumb2 is a superset of thumb, then CPU_HAS_THUMB2 should selectCPU_HAS_THUMB. And according to [1], it really is a superset.
Quoted 3 lines
and we could have a single option for both in Buildroot, since -mthumb on ARMv4/v5 means original Thumb, while -mthumb on ARMv7 means Thumb 2.
Well, I think the main reason to have the CPU_HAS_THUMB2 option is to allow
packages to depend on it, e.g. because there is some thumb2 assembly in it.
Quoted 15 lines
However, for clarity, it makes sense
to have two separate options. But in this case, Cortex-M3 should not advertise that it supports Thumb, as in fact selecting Thumb would generate Thumb-2 code.Signed-off-by Thomas Petazzoni <[email protected]>--- arch/Config.in.arm | 1 - 1 file changed, 1 deletion(-)arch/Config.in.arm +0
-0
arch/Config.in.arm config BR2_cortex_a17 · line 175
Quoted 4 lines
arch/Config.in.arm +0
-1@@ -172,7 +172,6 @@ config BR2_cortex_a17 select BR2_ARCH_HAS_MMU_OPTIONAL config BR2_cortex_m3 bool "cortex-M3" - select BR2_ARM_CPU_HAS_THUMB
I do agree about the change itself, but I also think that HAS_THUMB2 should
select HAS_THUMB instead. Also, I think the BR2_ARM_INSTRUCTIONS_THUMB2 option should be removed, because in the end it's just compiling in thumb mode. In arm mode, we also don't have separate options for armv5, armv6, armv7.
Regards,
Arnout
arch/Config.in.arm config BR2_cortex_a17 · line 177
Quoted 4 lines
arch/Config.in.arm +0
-0select BR2_ARM_CPU_HAS_THUMB2 select BR2_ARM_CPU_ARMV7M config BR2_fa526
[1]
http://stackoverflow.com/questions/28669905/arm-thumb-and-thumb-2-instructions-confusion
Signature · 6 lines
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: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
PATCH 2/16 arch/arm: Cortex-M3 provides only Thumb-2
Hello,
Quoted 2 lines · Arnout Vandecappelle
If thumb2 is a superset of thumb, then
CPU_HAS_THUMB2should selectCPU_HAS_THUMB. And according to [1], it really is a superset.
Right, this is a superset.
Quoted 6 lines
Quoted 3 lines
and we could have a single option for both in Buildroot, since -mthumb on ARMv4/v5 means original Thumb, while -mthumb on ARMv7 means Thumb 2.
Well, I think the main reason to have the
CPU_HAS_THUMB2option is to allow
packages to depend on it, e.g. because there is some thumb2 assembly in it.
Indeed.
Quoted 6 lines
Quoted 6 lines
arch/Config.in.arm +0
-0@@ -172,7 +172,6 @@ config BR2_cortex_a17 select BR2_ARCH_HAS_MMU_OPTIONAL
Quoted 8 lines
arch/Config.in.arm config BR2_cortex_a17 · line 175
Quoted 3 lines
arch/Config.in.arm +0
-1config BR2_cortex_m3 bool "cortex-M3" - select BR2_ARM_CPU_HAS_THUMBI do agree about the change itself, but I also think that
HAS_THUMB2should
selectHAS_THUMBinstead. Also, I think theBR2_ARM_INSTRUCTIONS_THUMB2option should be removed, because in the end it's just compiling in thumb mode. In arm mode, we also don't have separate options for armv5, armv6, armv7.
I originally started to remove BR2_ARM_INSTRUCTIONS_THUMB2, and have a single BR2_ARM_INSTRUCTIONS_THUMB that simply says "use Thumb for that core", which would be Thumb1 for old ARM cores, and Thumb2 for ARMv7.
However, there are cases where packages really need to know whether Thumb1 or Thumb2 is used. For example, glibc or musl don't build in Thumb1, so we force ARM instructions. This is fine for Thumb1, because all cores that support Thumb1 also support the ARM instruction set.
However, glibc and musl build fine in Thumb2, so there's no reason to force using the ARM instruction set. And Thumb2 is different than Thumb1 in that respect: there are some cores that implement *only* Thumb2 and not ARM (basically, the ARMv7-M ones).
So, if we remove BR2_ARM_INSTRUCTIONS_THUMB, we will have to change:
ifeq ($(BR2_ARM_INSTRUCTIONS_THUMB),y)GLIBC_EXTRA_CFLAGS += -marm
endif
to something like:
ifeq ($(BR2_ARM_INSTRUCTIONS_THUMB):$(BR2_CPU_HAS_THUMB2),y:) GLIBC_EXTRA_CFLAGS += -marm
endif
And so on everywhere where we need to do things depending on whether Thumb1 or Thumb2 is used.
So, while using Thumb1 or Thumb2 is just a matter of passing -mthumb to gcc and would therefore lead us to think that a single options is sufficient, I found it clearer to keep two separate options.
But I'm open to suggestions. As I said, I initially started my patch series by doing what you suggested, but reverted back to the ARM/Thumb/Thumb2 choice that we have today.
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 2/16 arch/arm: Cortex-M3 provides only Thumb-2
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Thomas" == Thomas Petazzoni <[email protected]> writes:
Hi,
Quoted 25 lines
Quoted 4 lines
I do agree about the change itself, but I also think that
HAS_THUMB2should selectHAS_THUMBinstead. Also, I think theBR2_ARM_INSTRUCTIONS_THUMB2option should be removed, because in the end it's just compiling in thumb mode. In arm mode, we also don't have separate options for armv5, armv6, armv7.I originally started to remove
BR2_ARM_INSTRUCTIONS_THUMB2, and have a singleBR2_ARM_INSTRUCTIONS_THUMBthat simply says "use Thumb for that core", which would be Thumb1 for old ARM cores, and Thumb2 for ARMv7.However, there are cases where packages really need to know whether Thumb1 or Thumb2 is used. For example, glibc or musl don't build in Thumb1, so we force ARM instructions. This is fine for Thumb1, because all cores that support Thumb1 also support the ARM instruction set.
However, glibc and musl build fine in Thumb2, so there's no reason to force using the ARM instruction set. And Thumb2 is different than Thumb1 in that respect: there are some cores that implement *only* Thumb2 and not ARM (basically, the ARMv7-M ones).
So, if we remove
BR2_ARM_INSTRUCTIONS_THUMB, we will have to change:ifeq ($(BR2_ARM_INSTRUCTIONS_THUMB),y)
GLIBC_EXTRA_CFLAGS+= -marm
endif
Quoted 8 lines
to something like:
ifeq ($(BR2_ARM_INSTRUCTIONS_THUMB):$(BR2_CPU_HAS_THUMB2),y:)
GLIBC_EXTRA_CFLAGS+= -marm
endifAnd so on everywhere where we need to do things depending on whether Thumb1 or Thumb2 is used.
Yes. A quick grep shows that we only need to do this in a few places:
git grep 'ifeq.*BR2_ARM_INSTRUCTIONS_THUMB),y' package/dmalloc/dmalloc.mk:ifeq ($(BR2_ARM_INSTRUCTIONS_THUMB),y) package/glibc/glibc.mk:ifeq ($(BR2_ARM_INSTRUCTIONS_THUMB),y) package/libglib2/libglib2.mk:ifeq ($(BR2_ARM_INSTRUCTIONS_THUMB),y) package/qt/qt.mk:ifeq ($(BR2_ARM_INSTRUCTIONS_THUMB),y)
Notice that we don't seem to do it for musl?
Quoted 3 lines
So, while using Thumb1 or Thumb2 is just a matter of passing -mthumb to gcc and would therefore lead us to think that a single options is sufficient, I found it clearer to keep two separate options.
Is there any other situations where we want to know the difference between thumb1 and thumb2? It might make sense to default to thumb instructions for systems supporting thumb2, but not for systems using thumb1 and the tradeoff is less clear - But that is also simple to do in kconfig with:
default BR2_ARM_INSTRUCTIONS_THUMB if BR2_ARM_CPU_HAS_THUMB2
It is really a question about trading off complexity in one place vs adding it somewhere else, so I'm not sure. You could argue that having a single thumb kconfig option would be simpler for users though (on the other hand, having explicit thumb1/thumb2 is perhaps clearer).
Signature · 1 line
Bye, Peter Korsgaard
PATCH 2/16 arch/arm: Cortex-M3 provides only Thumb-2
Hello,
Quoted 7 lines · Peter Korsgaard
Quoted 6 lines
ifeq ($(BR2_ARM_INSTRUCTIONS_THUMB):$(BR2_CPU_HAS_THUMB2),y:)
GLIBC_EXTRA_CFLAGS+= -marm
endifAnd so on everywhere where we need to do things depending on whether Thumb1 or Thumb2 is used.
Quoted 7 lines
Yes. A quick grep shows that we only need to do this in a few places:
git grep 'ifeq.*BR2_ARM_INSTRUCTIONS_THUMB),y' package/dmalloc/dmalloc.mk:ifeq ($(BR2_ARM_INSTRUCTIONS_THUMB),y) package/glibc/glibc.mk:ifeq ($(BR2_ARM_INSTRUCTIONS_THUMB),y) package/libglib2/libglib2.mk:ifeq ($(BR2_ARM_INSTRUCTIONS_THUMB),y) package/qt/qt.mk:ifeq ($(BR2_ARM_INSTRUCTIONS_THUMB),y)
Correct.
Quoted 1 line
Notice that we don't seem to do it for musl?
See patch 07/16.
Quoted 10 lines
Quoted 3 lines
So, while using Thumb1 or Thumb2 is just a matter of passing -mthumb to gcc and would therefore lead us to think that a single options is sufficient, I found it clearer to keep two separate options.
Is there any other situations where we want to know the difference between thumb1 and thumb2? It might make sense to default to thumb instructions for systems supporting thumb2, but not for systems using thumb1 and the tradeoff is less clear - But that is also simple to do in kconfig with:
Quoted 6 lines
default
BR2_ARM_INSTRUCTIONS_THUMBifBR2_ARM_CPU_HAS_THUMB2It is really a question about trading off complexity in one place vs adding it somewhere else, so I'm not sure. You could argue that having a single thumb kconfig option would be simpler for users though (on the other hand, having explicit thumb1/thumb2 is perhaps clearer).
I also find it clearer to have separate thumb1/thumb2 options for the user. I tried something like:
config BR2_ARM_INSTRUCTIONS_THUMB
bool "thumb" if BR2_ARM_CPU_HAS_THUMB
bool "thumb2" if BR2_ARM_CPU_HAS_THUMB2
but it wasn't working. And if we make BR2_ARM_CPU_HAS_THUMB2 select BR2_ARM_CPU_HAS_THUMB as suggested by Arnout, it would have to be:
config BR2_ARM_INSTRUCTIONS_THUMB
bool "thumb" if BR2_ARM_CPU_HAS_THUMB && !BR2_ARM_CPU_THUMB2 bool "thumb2" if BR2_ARM_CPU_HAS_THUMB2
Hence my suggestion to keep both BR2_ARM_INSTRUCTIONS_THUMB and BR2_ARM_INSTRUCTIONS_THUMB2.
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 2/16 arch/arm: Cortex-M3 provides only Thumb-2
In reply to Arnout VandecappelleHello,
Quoted 6 lines · Arnout Vandecappelle
Quoted 2 lines · Thomas Petazzoni
The Cortex-M cores only support Thumb-2, not Thumb. In fact, Thumb-2 is a superset of Thumb,
If thumb2 is a superset of thumb, then
CPU_HAS_THUMB2should selectCPU_HAS_THUMB. And according to [1], it really is a superset.
Thinking more about this, I don't see the point.
Even if Thumb2 is strictly speaking a superset of Thumb1, there is no gcc flag or mechanism that will allow you to generate Thumb1 code on a Thumb2-capable core.
Therefore, it IMO doesn't bring any benefit to select CPU_HAS_THUMB from CPU_HAS_THUMB2.
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 2/16 arch/arm: Cortex-M3 provides only Thumb-2
Quoted 10 lines · Thomas Petazzoni
Hello,
Quoted 6 lines · Arnout Vandecappelle
Quoted 2 lines · Thomas Petazzoni
The Cortex-M cores only support Thumb-2, not Thumb. In fact, Thumb-2 is a superset of Thumb,
If thumb2 is a superset of thumb, then
CPU_HAS_THUMB2should selectCPU_HAS_THUMB. And according to [1], it really is a superset.
Quoted 8 lines
Thinking more about this, I don't see the point.
Even if Thumb2 is strictly speaking a superset of Thumb1, there is no gcc flag or mechanism that will allow you to generate Thumb1 code on a Thumb2-capable core.
Therefore, it IMO doesn't bring any benefit to select
CPU_HAS_THUMBfromCPU_HAS_THUMB2.
Well, my idea was that a package that needs a specific config option to use
some thumb assembly (in an otherwise arm build) could just have a .mk condition on CPU_HAS_THUMB instead of CPU_HAS_THUMB or CPU_HAS_THUMB2. But that's not a situation we have at the moment anyway.
Regards,
Arnout
Signature · 6 lines
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: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
PATCH 3/16 arch/arm: add Cortex-M4 entry
In reply to Thomas PetazzoniThis commit adds the option to select the Cortex-M4 ARM core, in the same family as Cortex-M3. This will be useful to enable the internal toolchain backend for this ARM core, and provide some defconfigs for Cortex-M4 platforms.
--- arch/Config.in.arm | 5 +++++ 1 file changed, 5 insertions(+)
arch/Config.in.arm +5 -0
@@ -174,6 +174,10 @@ config BR2_cortex_m3 bool "cortex-M3" select BR2_ARM_CPU_HAS_THUMB2 select BR2_ARM_CPU_ARMV7M +config BR2_cortex_m4 + bool "cortex-M4" + select BR2_ARM_CPU_HAS_THUMB2 + select BR2_ARM_CPU_ARMV7M config BR2_fa526 bool "fa526/626" select BR2_ARM_CPU_HAS_ARM
@@ -455,6 +459,7 @@ config BR2_GCC_TARGET_CPU default "cortex-a15" if BR2_cortex_a15 default "cortex-a17" if BR2_cortex_a17 default "cortex-m3" if BR2_cortex_m3 + default "cortex-m4" if BR2_cortex_m4 default "fa526" if BR2_fa526 default "marvell-pj4" if BR2_pj4 default "strongarm" if BR2_strongarm
Signature · 1 line
2.6.4
PATCH 3/16 arch/arm: add Cortex-M4 entry
Quoted 6 lines · Thomas Petazzoni
This commit adds the option to select the Cortex-M4 ARM core, in the same family as Cortex-M3. This will be useful to enable the internal toolchain backend for this ARM core, and provide some defconfigs for Cortex-M4 platforms.
Signed-off-by Thomas Petazzoni <[email protected]>
Regards,
Arnout
Quoted 28 lines
--- arch/Config.in.arm | 5 +++++ 1 file changed, 5 insertions(+)arch/Config.in.arm +5
-0@@ -174,6 +174,10 @@ config BR2_cortex_m3 bool "cortex-M3" select BR2_ARM_CPU_HAS_THUMB2 select BR2_ARM_CPU_ARMV7M +config BR2_cortex_m4 + bool "cortex-M4" + select BR2_ARM_CPU_HAS_THUMB2 + select BR2_ARM_CPU_ARMV7M config BR2_fa526 bool "fa526/626" select BR2_ARM_CPU_HAS_ARM@@ -455,6 +459,7 @@ config BR2_GCC_TARGET_CPU default "cortex-a15" if BR2_cortex_a15 default "cortex-a17" if BR2_cortex_a17 default "cortex-m3" if BR2_cortex_m3 + default "cortex-m4" if BR2_cortex_m4 default "fa526" if BR2_fa526 default "marvell-pj4" if BR2_pj4 default "strongarm" if BR2_strongarm
Signature · 6 lines
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: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
PATCH 4/16 uclibc: Enable compile in thumb mode when selected
In reply to Thomas PetazzoniFrom: Paul Enman <[email protected]>
Until now, when thumb was selected with threads, we were forcing ARM mode to be used, to workaround some problems building uClibc with threads in Thumb mode. Also, we were never enabling Thumb mode in uClibc when Thumb2 was selected in the configuration.
Therefore, this commit updates the uclibc.mk logic to:
- Force ARM mode only when gcc 4.7 or 4.8 is selected with Thumb1 and threads. We also explicitly disable COMPILE_IN_THUMB_MODE when we fall in this situation. With newer gcc versions, starting 4.9, this problem is fixed and we can build uClibc in Thumb1 mode.
- Enable COMPILE_IN_THUMB_MODE when Thumb1 or Thumb2 is selected. We need to disable context functions since they don't build in Thumb mode.
- Disable COMPILE_IN_THUMB_MODE explicitly otherwise.
This allows to build a Thumb2 toolchain on ARMv7-M for example.
--- package/uclibc/uclibc.mk | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-)
package/uclibc/uclibc.mk +17 -2
@@ -75,9 +75,23 @@ define UCLIBC_ARM_ABI_CONFIG $(call KCONFIG_ENABLE_OPT,CONFIG_ARM_EABI,$(@D)/.config) endef -# Thumb build is broken with threads, build in ARM mode -ifeq ($(BR2_ARM_INSTRUCTIONS_THUMB)$(BR2_TOOLCHAIN_HAS_THREADS),yy) +# Thumb1 build is broken with threads with old gcc versions (4.7 and +# 4.8). Since all cores supporting Thumb1 also support ARM, we use ARM +# code in this case. +ifeq ($(BR2_GCC_VERSION_4_7_X)$(BR2_GCC_VERSION_4_8_X):$(BR2_ARM_INSTRUCTIONS_THUMB)$(BR2_TOOLCHAIN_HAS_THREADS),y:yy) UCLIBC_EXTRA_CFLAGS += -marm +define UCLIBC_ARM_THUMB_CONFIG + $(call KCONFIG_DISABLE_OPT,COMPILE_IN_THUMB_MODE,$(@D)/.config) +endef +else ifeq ($(BR2_ARM_INSTRUCTIONS_THUMB)$(BR2_ARM_INSTRUCTIONS_THUMB2),y) +define UCLIBC_ARM_THUMB_CONFIG + $(call KCONFIG_ENABLE_OPT,COMPILE_IN_THUMB_MODE,$(@D)/.config) + $(call KCONFIG_DISABLE_OPT,UCLIBC_HAS_CONTEXT_FUNCS,$(@D)/.config) +endef +else +define UCLIBC_ARM_THUMB_CONFIG + $(call KCONFIG_DISABLE_OPT,COMPILE_IN_THUMB_MODE,$(@D)/.config) +endef endif ifeq ($(BR2_UCLIBC_ARM_BX),y)
@@ -362,6 +376,7 @@ define UCLIBC_KCONFIG_FIXUP_CMDS $(UCLIBC_ARC_TYPE_CONFIG) $(UCLIBC_ARC_PAGE_SIZE_CONFIG) $(UCLIBC_ARM_ABI_CONFIG) + $(UCLIBC_ARM_THUMB_CONFIG) $(UCLIBC_ARM_BX_CONFIG) $(UCLIBC_MIPS_ABI_CONFIG) $(UCLIBC_MIPS_ISA_CONFIG)
Signature · 1 line
2.6.4
PATCH 4/16 uclibc: Enable compile in thumb mode when selected
Quoted 14 lines · Thomas Petazzoni
From: Paul Enman <[email protected]>
Until now, when thumb was selected with threads, we were forcing ARM mode to be used, to workaround some problems building uClibc with threads in Thumb mode. Also, we were never enabling Thumb mode in uClibc when Thumb2 was selected in the configuration.
Therefore, this commit updates the uclibc.mk logic to:
- Force ARM mode only when gcc 4.7 or 4.8 is selected with Thumb1 and threads. We also explicitly disable
COMPILE_IN_THUMB_MODEwhen we fall in this situation. With newer gcc versions, starting 4.9, this problem is fixed and we can build uClibc in Thumb1 mode.
Quoted 7 lines
- Enable
COMPILE_IN_THUMB_MODEwhen Thumb1 or Thumb2 is selected. We need to disable context functions since they don't build in Thumb mode.- Disable
COMPILE_IN_THUMB_MODEexplicitly otherwise.This allows to build a Thumb2 toolchain on ARMv7-M for example.
Principle looks OK to me, but it will of course have to be reworked if you
follow my suggestion os removing BR2_ARM_INSTRUCTIONS_THUMB2.
Quoted 12 lines
Signed-off-by Paul Enman <[email protected]>Signed-off-by Thomas Petazzoni <[email protected]>--- package/uclibc/uclibc.mk | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-)package/uclibc/uclibc.mk +0
-0
package/uclibc/uclibc.mk define UCLIBC_ARM_ABI_CONFIG · line 81
Quoted 9 lines
package/uclibc/uclibc.mk +4
-2@@ -75,9 +75,23 @@ define UCLIBC_ARM_ABI_CONFIG $(call KCONFIG_ENABLE_OPT,CONFIG_ARM_EABI,$(@D)/.config) endef -# Thumb build is broken with threads, build in ARM mode -ifeq ($(BR2_ARM_INSTRUCTIONS_THUMB)$(BR2_TOOLCHAIN_HAS_THREADS),yy) +# Thumb1 build is broken with threads with old gcc versions (4.7 and +# 4.8). Since all cores supporting Thumb1 also support ARM, we use ARM +# code in this case. +ifeq ($(BR2_GCC_VERSION_4_7_X)$(BR2_GCC_VERSION_4_8_X):$(BR2_ARM_INSTRUCTIONS_THUMB)$(BR2_TOOLCHAIN_HAS_THREADS),y:yy)
This would need to become something like
ifeq ($(BR2_GCC_VERSION_4_7_X)$(BR2_GCC_VERSION_4_8_X):$(BR2_ARM_INSTRUCTIONS_THUMB):$(BR2_ARM_CPU_HAS_THUMB2):$(BR2_TOOLCHAIN_HAS_THREADS),y:y::y)
But that is horrible, so some auxiliary variables should be introduced.
Or actually, it could be
ifeq ($(BR2_ARM_INSTRUCTIONS_THUMB),y)
ifeq ($(BR2_GCC_VERSION_4_7_X)$(BR2_GCC_VERSION_4_8_X):$(BR2_ARM_CPU_HAS_THUMB2):$(BR2_TOOLCHAIN_HAS_THREADS),y::y) ...arm...
else
...thumb...
endif
else
...arm...
endif
Regards,
Arnout
Quoted 25 lines
package/uclibc/uclibc.mk +13
-0UCLIBC_EXTRA_CFLAGS += -marm +define UCLIBC_ARM_THUMB_CONFIG + $(call KCONFIG_DISABLE_OPT,COMPILE_IN_THUMB_MODE,$(@D)/.config) +endef +else ifeq ($(BR2_ARM_INSTRUCTIONS_THUMB)$(BR2_ARM_INSTRUCTIONS_THUMB2),y) +define UCLIBC_ARM_THUMB_CONFIG + $(call KCONFIG_ENABLE_OPT,COMPILE_IN_THUMB_MODE,$(@D)/.config) + $(call KCONFIG_DISABLE_OPT,UCLIBC_HAS_CONTEXT_FUNCS,$(@D)/.config) +endef +else +define UCLIBC_ARM_THUMB_CONFIG + $(call KCONFIG_DISABLE_OPT,COMPILE_IN_THUMB_MODE,$(@D)/.config) +endef endif ifeq ($(BR2_UCLIBC_ARM_BX),y)@@ -362,6 +376,7 @@ define UCLIBC_KCONFIG_FIXUP_CMDS $(UCLIBC_ARC_TYPE_CONFIG) $(UCLIBC_ARC_PAGE_SIZE_CONFIG) $(UCLIBC_ARM_ABI_CONFIG) + $(UCLIBC_ARM_THUMB_CONFIG) $(UCLIBC_ARM_BX_CONFIG) $(UCLIBC_MIPS_ABI_CONFIG) $(UCLIBC_MIPS_ISA_CONFIG)
Signature · 6 lines
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: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
PATCH 4/16 uclibc: Enable compile in thumb mode when selected
In reply to Thomas PetazzoniQuoted 10 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Thomas" == Thomas Petazzoni <[email protected]> writes:
From: Paul Enman <[email protected]>
Until now, when thumb was selected with threads, we were forcing ARM mode to be used, to workaround some problems building uClibc with threads in Thumb mode. Also, we were never enabling Thumb mode in uClibc when Thumb2 was selected in the configuration.Therefore, this commit updates the uclibc.mk logic to:
Quoted 8 lines
- Force ARM mode only when gcc 4.7 or 4.8 is selected with Thumb1 and threads. We also explicitly disable
COMPILE_IN_THUMB_MODEwhen we fall in this situation. With newer gcc versions, starting 4.9, this problem is fixed and we can build uClibc in Thumb1 mode.- Enable
COMPILE_IN_THUMB_MODEwhen Thumb1 or Thumb2 is selected. We need to disable context functions since they don't build in Thumb mode.
Why do we need to tell uClibc that we are building in thumb1/2 mode? From a quick grep this just adds -mthumb to CFLAGS, which shouldn't be needed as we've already configured the compiler to do so by default and enables USE_BX + USE_LDREXSTREX.
Now, I don't know enough of the finer details about this. I thought BX was for thumb1 interworking with classical ARM code and not needed for thumb2, so isn't it just adding overhead for thumb2? I also see that enabling this option will break thumb compilation on arm920t.
Luckily Yann is the author of this logic in uClibc, so lets ask him ;)
Quoted 3 lines
- Disable
COMPILE_IN_THUMB_MODEexplicitly otherwise.This allows to build a Thumb2 toolchain on ARMv7-M for example.
What wasn't working before?
Signature · 1 line
Bye, Peter Korsgaard
PATCH 4/16 uclibc: Enable compile in thumb mode when selected
Hello,
Quoted 14 lines · Peter Korsgaard
Quoted 8 lines
- Force ARM mode only when gcc 4.7 or 4.8 is selected with Thumb1 and threads. We also explicitly disable
COMPILE_IN_THUMB_MODEwhen we fall in this situation. With newer gcc versions, starting 4.9, this problem is fixed and we can build uClibc in Thumb1 mode.- Enable
COMPILE_IN_THUMB_MODEwhen Thumb1 or Thumb2 is selected. We need to disable context functions since they don't build in Thumb mode.Why do we need to tell uClibc that we are building in thumb1/2 mode? From a quick grep this just adds -mthumb to CFLAGS, which shouldn't be needed as we've already configured the compiler to do so by default and enables
USE_BX+USE_LDREXSTREX.
Quoted 4 lines
Now, I don't know enough of the finer details about this. I thought BX was for thumb1 interworking with classical ARM code and not needed for thumb2, so isn't it just adding overhead for thumb2? I also see that enabling this option will break thumb compilation on arm920t.
Interworking allows on pre-ARMv5 code to fix ARM and Thumb code. With ARMv5, it is not needed if I remember correctly, thanks to the bx/blx instructions.
Quoted 7 lines
Luckily Yann is the author of this logic in uClibc, so lets ask him ;)
Quoted 3 lines
- Disable
COMPILE_IN_THUMB_MODEexplicitly otherwise.This allows to build a Thumb2 toolchain on ARMv7-M for example.
What wasn't working before?
Not sure. In fact this patch was kind-of the starting point of my series, I wanted to get rid of it from patchwork :)
I'll have a closer look.
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 4/16 uclibc: Enable compile in thumb mode when selected
In reply to Peter KorsgaardHello,
Quoted 5 lines · Peter Korsgaard
Quoted 4 lines
- Force ARM mode only when gcc 4.7 or 4.8 is selected with Thumb1 and threads. We also explicitly disable
COMPILE_IN_THUMB_MODEwhen we fall in this situation. With newer gcc versions, starting 4.9, this problem is fixed and we can build uClibc in Thumb1 mode.
Quoted 8 lines
Quoted 3 lines
- Enable
COMPILE_IN_THUMB_MODEwhen Thumb1 or Thumb2 is selected. We need to disable context functions since they don't build in Thumb mode.Why do we need to tell uClibc that we are building in thumb1/2 mode? From a quick grep this just adds -mthumb to CFLAGS, which shouldn't be needed as we've already configured the compiler to do so by default and enables
USE_BX+USE_LDREXSTREX.
USE_LDREXSTREX is mandatory for uClibc to build on Thumb2 (see commit
https://lists.uclibc.org/pipermail/uclibc/2014-November/048704.html).
Otherwise, the build fails with:
/tmp/ccsjUC4D.s: Assembler messages:/tmp/ccsjUC4D.s:31: Error: selected processor does not support ARM opcodes /tmp/ccsjUC4D.s:32: Error: attempt to use an ARM instruction on a Thumb-only processor -- swp r2,r2,[r0]' /tmp/ccsjUC4D.s:33: Error: attempt to use an ARM instruction on a Thumb-only processor -- orr r3,pc,#1' /tmp/ccsjUC4D.s:34: Error: attempt to use an ARM instruction on a Thumb-only processor -- `bx r3' make[2]: *** [libpthread/linuxthreads.old/pt-machine.o] Error 1
Quoted 4 lines
Now, I don't know enough of the finer details about this. I thought BX was for thumb1 interworking with classical ARM code and not needed for thumb2, so isn't it just adding overhead for thumb2? I also see that enabling this option will break thumb compilation on arm920t.
What makes you think it will fail to build ?
I believe you think:
#if defined(__USE_BX__)
# if (__ARM_ARCH <= 4 && !defined __ARM_ARCH_4T__) # error Use of BX was requested, but is not available on the target processor. # endif /* ARCH level */ #endif /* __USE_BX__ */
will make it fail to build.
But ARM920T is an ARMv4T, not an ARMv4. Quoting from
http://www.atmel.com/Images/ARM_920T_TRM.pdf:
"""
The ARM920T processor incorporates the ARM9TDMI integer core, which implements the ARM architecture v4T.
"""
However, it could indeed break StrongARM and FA256, which implement the ARMv4 instruction set. *But* for those two cores, we don't select BR2_ARM_CPU_HAS_THUMB, so you can't switch them to Thumb mode.
But isn't this all moot since Thumb appeared with ARMv4T ?
Quoted 7 lines
Luckily Yann is the author of this logic in uClibc, so lets ask him ;)
Quoted 3 lines
- Disable
COMPILE_IN_THUMB_MODEexplicitly otherwise.This allows to build a Thumb2 toolchain on ARMv7-M for example.
What wasn't working before?
See above. If you don't enable COMPILE_IN_THUMB_MODE, you can't enable USE_LDREXSTREX.
So I think we should:
1/ Enable COMPILE_IN_THUMB_MODE whenever ARM_INSTRUCTIONS_THUMB(2) is
enabled.
2/ Enable USE_BX whenever ARM_INSTRUCTIONS_THUMB(2) is enabled. I
don't see why USE_BX for later cores can cause performance problems, it's just about using a simple bx instruction to switch between ARM and Thumb modes.
3/ Enable USE_LDREXSTREX whenver ARM_INSTRUCTIONS_THUMB(2) is enabled
*and* we're on ARMv7. Otherwise, disable it.
Thoughts ?
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 4/16 uclibc: Enable compile in thumb mode when selected
Quoted 14 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Thomas" == Thomas Petazzoni <[email protected]> writes:
Hello,
Quoted 9 lines · Peter Korsgaard
Quoted 8 lines
- Force ARM mode only when gcc 4.7 or 4.8 is selected with Thumb1 and threads. We also explicitly disable
COMPILE_IN_THUMB_MODEwhen we fall in this situation. With newer gcc versions, starting 4.9, this problem is fixed and we can build uClibc in Thumb1 mode.- Enable
COMPILE_IN_THUMB_MODEwhen Thumb1 or Thumb2 is selected. We need to disable context functions since they don't build in Thumb mode.
Quoted 8 lines
Quoted 4 lines
Why do we need to tell uClibc that we are building in thumb1/2 mode? From a quick grep this just adds -mthumb to CFLAGS, which shouldn't be needed as we've already configured the compiler to do so by default and enables
USE_BX+USE_LDREXSTREX.
USE_LDREXSTREXis mandatory for uClibc to build on Thumb2 (see commit
https://lists.uclibc.org/pipermail/uclibc/2014-November/048704.html).
Otherwise, the build fails with:
Ahh, ok - Good to know. So this is only really needed for thumb2-only CPUs (cortex-M).
Completely unrelated, but notice that my browser wouldn't let me visit https://lists.uclibc.org because of the HSTS header on uclibc.org and the lists.uclibc.org vhost using a certificate for *.osuosl.org.
It does work for lists.buildroot.org as we don't do HSTS for subdomains.
Quoted 10 lines
What makes you think it will fail to build ?
I believe you think:
#if
defined(__USE_BX__)# if (__ARM_ARCH <= 4 && !defined __ARM_ARCH_4T__) # error Use of BX was requested, but is not available on the target processor. # endif /* ARCH level */ #endif /* __USE_BX__ */
Quoted 4 lines
will make it fail to build.
But ARM920T is an ARMv4T, not an ARMv4. Quoting from
http://www.atmel.com/Images/ARM_920T_TRM.pdf:
Ahh yes, true.
Quoted 4 lines
So I think we should:
1/ Enable
COMPILE_IN_THUMB_MODEwheneverARM_INSTRUCTIONS_THUMB(2)is
enabled.
Ok.
Quoted 7 lines
2/ Enable
USE_BXwheneverARM_INSTRUCTIONS_THUMB(2)is enabled. I
don't see whyUSE_BXfor later cores can cause performance problems, it's just about using a simple bx instruction to switch between ARM and Thumb modes.3/ Enable
USE_LDREXSTREXwhenverARM_INSTRUCTIONS_THUMB(2)is enabled
*and* we're on ARMv7. Otherwise, disable it.
With ARMv7 I guess you mean thumb2-only CPUs (cortex-m)?
But COMPILE_IN_THUMB_MODE selects USE_BX / USE_LDREXTREX, so we cannot really do that.
I guess we should leave COMPILE_IN_THUMB_MODE alone (it just passes -mthumb in CFLAGS which we don't need), and just enable USE_BX/LDREXTREX when needed.
Signature · 2 lines
Venlig hilsen, Peter Korsgaard
PATCH 4/16 uclibc: Enable compile in thumb mode when selected
Hello,
Quoted 6 lines · Peter Korsgaard
Quoted 3 lines
USE_LDREXSTREXis mandatory for uClibc to build on Thumb2 (see commit
https://lists.uclibc.org/pipermail/uclibc/2014-November/048704.html).
Otherwise, the build fails with:Ahh, ok - Good to know. So this is only really needed for thumb2-only CPUs (cortex-M).
Mandatory for Thumb2-only CPUs, but perfectly usable for ARMv7-A as well.
Quoted 4 lines
Completely unrelated, but notice that my browser wouldn't let me visit https://lists.uclibc.org because of the HSTS header on uclibc.org and the lists.uclibc.org vhost using a certificate for *.osuosl.org.
Same here, I have to use Firefox to be able to bypass the "security checks". Chromium doesn't allow to bypass such security checks (at least by default).
Quoted 15 lines
Quoted 4 lines
So I think we should:
1/ Enable
COMPILE_IN_THUMB_MODEwheneverARM_INSTRUCTIONS_THUMB(2)is
enabled.Ok.
Quoted 7 lines
2/ Enable
USE_BXwheneverARM_INSTRUCTIONS_THUMB(2)is enabled. I
don't see whyUSE_BXfor later cores can cause performance problems, it's just about using a simple bx instruction to switch between ARM and Thumb modes.3/ Enable
USE_LDREXSTREXwhenverARM_INSTRUCTIONS_THUMB(2)is enabled
*and* we're on ARMv7. Otherwise, disable it.
Quoted 8 lines
With ARMv7 I guess you mean thumb2-only CPUs (cortex-m)?
But
COMPILE_IN_THUMB_MODEselectsUSE_BX/USE_LDREXTREX, so we cannot really do that.I guess we should leave
COMPILE_IN_THUMB_MODEalone (it just passes -mthumb in CFLAGS which we don't need), and just enable USE_BX/LDREXTREX when needed.
USE_LDREXSTREX depends on COMPILE_IN_THUMB_MODE, so you can't have USE_LDREXSTREX without having COMPILE_IN_THUMB_MODE.
So, instead what I've done is cook a set of patches for uClibc that simply remove USE_BX, USE_LDREXSTREX and COMPILE_IN_THUMB. None of those options are needed, everything can be guessed by looking at the selected ARM variant, and for COMPILE_IN_THUMB, by passing -mthumb.
See
https://github.com/tpetazzoni/uclibc-ng/commits/arm-simplifications.
Build testing in progress. I'm testing:
* Cortex-M4, so a Thumb2-only core
* Cortex-A in Thumb2 mode
* ARM920T in Thumb mode
* FA526, which is an ARMv4 (and therefore doesn't support Thumb)
Any other config you think is relevant?
Thanks,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 4/16 uclibc: Enable compile in thumb mode when selected
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Thomas" == Thomas Petazzoni <[email protected]> writes:
Hi,
Quoted 5 lines
Quoted 2 lines
Ahh, ok - Good to know. So this is only really needed for thumb2-only CPUs (cortex-M).
Mandatory for Thumb2-only CPUs, but perfectly usable for ARMv7-A as well.
True.
Quoted 8 lines
Quoted 4 lines
Completely unrelated, but notice that my browser wouldn't let me visit https://lists.uclibc.org because of the HSTS header on uclibc.org and the lists.uclibc.org vhost using a certificate for *.osuosl.org.
Same here, I have to use Firefox to be able to bypass the "security checks". Chromium doesn't allow to bypass such security checks (at least by default).
Yes, quite a mess :/
Quoted 11 lines
Quoted 8 lines
With ARMv7 I guess you mean thumb2-only CPUs (cortex-m)?
But
COMPILE_IN_THUMB_MODEselectsUSE_BX/USE_LDREXTREX, so we cannot really do that.I guess we should leave
COMPILE_IN_THUMB_MODEalone (it just passes -mthumb in CFLAGS which we don't need), and just enable USE_BX/LDREXTREX when needed.
USE_LDREXSTREXdepends onCOMPILE_IN_THUMB_MODE, so you can't haveUSE_LDREXSTREXwithout havingCOMPILE_IN_THUMB_MODE.
Ahh yes, but USE_BX is independent at least, so COMPILE_IN_THUMB_MODE (which implies USE_LDREXSTREX) for thumb2, and NOT for classic ARM/thumb1 mode.
Quoted 7 lines
So, instead what I've done is cook a set of patches for uClibc that simply remove
USE_BX,USE_LDREXSTREXandCOMPILE_IN_THUMB. None of those options are needed, everything can be guessed by looking at the selected ARM variant, and forCOMPILE_IN_THUMB, by passing -mthumb.See
https://github.com/tpetazzoni/uclibc-ng/commits/arm-simplifications.
Thanks, it imho looks sensible.
Quoted 8 lines
Build testing in progress. I'm testing:
* Cortex-M4, so a Thumb2-only core
* Cortex-A in Thumb2 mode
* ARM920T in Thumb mode
* FA526, which is an ARMv4 (and therefore doesn't support Thumb)Any other config you think is relevant?
No, I think this pretty much covers it. There's afaik an arm11 variant supporting thumb2, but I've never seen any SoCs using it and we don't support it Buildroot.
Signature · 2 lines
Venlig hilsen, Peter Korsgaard
PATCH 5/16 uclibc: disable DOPIC on ARM noMMU
In reply to Thomas PetazzoniAs explained by Waldemar, enabling DOPIC in uClibc will lead to the creation of a Position Independent library. In turn, this will cause elf2flt to generate a "Has-PIC-GOT" flat binary, which doesn't work on ARM. In fact, elf2flt on ARM really except to have non-PIC code as input, so we must disable DOPIC in the uClibc configuration.
--- package/uclibc/uclibc.mk | 9 +++++++++ 1 file changed, 9 insertions(+)
package/uclibc/uclibc.mk +9 -0
@@ -94,6 +94,14 @@ define UCLIBC_ARM_THUMB_CONFIG endef endif +ifeq ($(UCLIBC_TARGET_ARCH),arm) +ifeq ($(BR2_USE_MMU),) +define UCLIBC_ARM_NOMMU + $(call KCONFIG_DISABLE_OPT,DOPIC,$(@D)/.config) +endef +endif +endif + ifeq ($(BR2_UCLIBC_ARM_BX),y) define UCLIBC_ARM_BX_CONFIG $(call KCONFIG_ENABLE_OPT,USE_BX,$(@D)/.config)
@@ -378,6 +386,7 @@ define UCLIBC_KCONFIG_FIXUP_CMDS $(UCLIBC_ARM_ABI_CONFIG) $(UCLIBC_ARM_THUMB_CONFIG) $(UCLIBC_ARM_BX_CONFIG) + $(UCLIBC_ARM_NOMMU) $(UCLIBC_MIPS_ABI_CONFIG) $(UCLIBC_MIPS_ISA_CONFIG) $(UCLIBC_SH_TYPE_CONFIG)
Signature · 1 line
2.6.4
PATCH 5/16 uclibc: disable DOPIC on ARM noMMU
Quoted 4 lines · Thomas Petazzoni
As explained by Waldemar, enabling DOPIC in uClibc will lead to the creation of a Position Independent library. In turn, this will cause elf2flt to generate a "Has-PIC-GOT" flat binary, which doesn't work on ARM. In fact, elf2flt on ARM really except to have non-PIC code as
^^^^^^expects
Quoted 12 lines
input, so we must disable DOPIC in the uClibc configuration.
Signed-off-by Thomas Petazzoni <[email protected]>--- package/uclibc/uclibc.mk | 9 +++++++++ 1 file changed, 9 insertions(+)package/uclibc/uclibc.mk +0
-0
package/uclibc/uclibc.mk define UCLIBC_ARM_THUMB_CONFIG · line 98
Quoted 5 lines
package/uclibc/uclibc.mk +2
-0@@ -94,6 +94,14 @@ define UCLIBC_ARM_THUMB_CONFIG endef endif +ifeq ($(UCLIBC_TARGET_ARCH),arm) +ifeq ($(BR2_USE_MMU),)
If elf2flt is the issue, wouldn't it make more sense to check for BINFMT_FLAT?
Also, is it really only for arm that this issue exists? Custom xtensa is the
only other one for which we build an internal toolchain, but I don't know if anybody ever tests it...
Regards,
Arnout
Quoted 18 lines
package/uclibc/uclibc.mk +7
-0+define UCLIBC_ARM_NOMMU + $(call KCONFIG_DISABLE_OPT,DOPIC,$(@D)/.config) +endef +endif +endif + ifeq ($(BR2_UCLIBC_ARM_BX),y) define UCLIBC_ARM_BX_CONFIG $(call KCONFIG_ENABLE_OPT,USE_BX,$(@D)/.config)@@ -378,6 +386,7 @@ define UCLIBC_KCONFIG_FIXUP_CMDS $(UCLIBC_ARM_ABI_CONFIG) $(UCLIBC_ARM_THUMB_CONFIG) $(UCLIBC_ARM_BX_CONFIG) + $(UCLIBC_ARM_NOMMU) $(UCLIBC_MIPS_ABI_CONFIG) $(UCLIBC_MIPS_ISA_CONFIG) $(UCLIBC_SH_TYPE_CONFIG)
Signature · 6 lines
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: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
PATCH 5/16 uclibc: disable DOPIC on ARM noMMU
Hello,
Quoted 4 lines · Arnout Vandecappelle
package/uclibc/uclibc.mk define UCLIBC_ARM_THUMB_CONFIG · line 98
Quoted 2 lines
package/uclibc/uclibc.mk +2
-0+ifeq ($(UCLIBC_TARGET_ARCH),arm) +ifeq ($(BR2_USE_MMU),)If elf2flt is the issue, wouldn't it make more sense to check for
BINFMT_FLAT?
OK. At this point, on ARM BR2_USE_MMU disabled or BINFMT_FLAT=y is equivalent. But right, it's a elf2flt related issue, so testing BINFMT_FLAT makes more sense.
Quoted 3 lines
Also, is it really only for arm that this issue exists? Custom xtensa is the
only other one for which we build an internal toolchain, but I don't know if anybody ever tests it...
I have no idea if Xtensa noMMU has ever been tested, whether it uses FLAT or FDPIC, etc. Could we leave this up to people interested in Xtensa ? Or alternatively, remove noMMU Xtensa support altogether.
I'm Cc'ing Max to see if he knows what the status of noMMU Xtensa is.
Thanks!
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 5/16 uclibc: disable DOPIC on ARM noMMU
Quoted 17 lines · Thomas Petazzoni
Hello,
Quoted 4 lines · Arnout Vandecappelle
package/uclibc/uclibc.mk define UCLIBC_ARM_THUMB_CONFIG · line 98
Quoted 2 lines
package/uclibc/uclibc.mk +2
-0+ifeq ($(UCLIBC_TARGET_ARCH),arm) +ifeq ($(BR2_USE_MMU),)If elf2flt is the issue, wouldn't it make more sense to check for
BINFMT_FLAT?OK. At this point, on ARM
BR2_USE_MMUdisabled or BINFMT_FLAT=y is equivalent. But right, it's a elf2flt related issue, so testingBINFMT_FLATmakes more sense.Quoted 3 lines
Also, is it really only for arm that this issue exists? Custom xtensa is the
only other one for which we build an internal toolchain, but I don't know if anybody ever tests it...
Quoted 5 lines
I have no idea if Xtensa noMMU has ever been tested, whether it uses FLAT or FDPIC, etc. Could we leave this up to people interested in Xtensa ? Or alternatively, remove noMMU Xtensa support altogether.
I'm Cc'ing Max to see if he knows what the status of noMMU Xtensa is.
I tested noMMU xtensa lightly. It uses FLAT
( https://github.com/uclinux-dev/elf2flt/commit/052ec62c087a3e9dfb62d231ee4aad253bce2f7e
),
requires a patch for gcc
( https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=e3c15dbe1c4cd63d906eb67c1c607cc4fab6b329
),
and currently it defaults to generating PIC code.
It appears to work with both DOPIC enabled and disabled.
Signature · 2 lines
Thanks. -- Max
PATCH 5/16 uclibc: disable DOPIC on ARM noMMU
Hello,
Quoted 6 lines · Max Filippov
Quoted 5 lines
I have no idea if Xtensa noMMU has ever been tested, whether it uses FLAT or FDPIC, etc. Could we leave this up to people interested in Xtensa ? Or alternatively, remove noMMU Xtensa support altogether.
I'm Cc'ing Max to see if he knows what the status of noMMU Xtensa is.
Quoted 8 lines
I tested noMMU xtensa lightly. It uses FLAT
( https://github.com/uclinux-dev/elf2flt/commit/052ec62c087a3e9dfb62d231ee4aad253bce2f7e
),
requires a patch for gcc
( https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=e3c15dbe1c4cd63d906eb67c1c607cc4fab6b329
),
and currently it defaults to generating PIC code.
It appears to work with both DOPIC enabled and disabled.
Does it work within Buildroot? I think we should either have support for Xtensa noMMU and make it work, or we should remove it.
From what you say, if it doesn't work already, it seems like it should be a huge work to get it working, right?
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 5/16 uclibc: disable DOPIC on ARM noMMU
Quoted 19 lines · Thomas Petazzoni
Hello,
Quoted 6 lines · Max Filippov
Quoted 5 lines
I have no idea if Xtensa noMMU has ever been tested, whether it uses FLAT or FDPIC, etc. Could we leave this up to people interested in Xtensa ? Or alternatively, remove noMMU Xtensa support altogether.
I'm Cc'ing Max to see if he knows what the status of noMMU Xtensa is.
Quoted 8 lines
I tested noMMU xtensa lightly. It uses FLAT
( https://github.com/uclinux-dev/elf2flt/commit/052ec62c087a3e9dfb62d231ee4aad253bce2f7e
),
requires a patch for gcc
( https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=e3c15dbe1c4cd63d906eb67c1c607cc4fab6b329
),
and currently it defaults to generating PIC code.
It appears to work with both DOPIC enabled and disabled.
Quoted 5 lines
Does it work within Buildroot? I think we should either have support for Xtensa noMMU and make it work, or we should remove it.
From what you say, if it doesn't work already, it seems like it should be a huge work to get it working, right?
It should not, yes. Let me post the patches.
Signature · 2 lines
Thanks. -- Max
PATCH 6/16 uclibc: NPTL thread implementation only available on MMU platforms
In reply to Thomas PetazzoniAs indicated by the uClibc-ng source code, the NPTL thread implementation is only available on MMU platforms, so we replicate this dependency in Buildroot so that the appropriate thread implementation is chosen by default on ARM noMMU.
--- package/uclibc/Config.in | 2 ++ 1 file changed, 2 insertions(+)
package/uclibc/Config.in +2 -0
@@ -48,6 +48,7 @@ config BR2_TOOLCHAIN_BUILDROOT_LOCALE choice prompt "Thread library implementation" default BR2_PTHREADS_NATIVE + default BR2_PTHREADS_OLD if !BR2_USE_MMU help Use this option to select the thread library implementation that should be used in your toolchain.
@@ -69,6 +70,7 @@ choice bool "Native POSIX Threading (NPTL)" select BR2_TOOLCHAIN_HAS_THREADS select BR2_TOOLCHAIN_HAS_THREADS_NPTL + depends on BR2_USE_MMU depends on !BR2_m68k && !BR2_x86_i386 endchoice
Signature · 1 line
2.6.4
PATCH 6/16 uclibc: NPTL thread implementation only available on MMU platforms
Quoted 6 lines · Thomas Petazzoni
As indicated by the uClibc-ng source code, the NPTL thread implementation is only available on MMU platforms, so we replicate this dependency in Buildroot so that the appropriate thread implementation is chosen by default on ARM noMMU.
Signed-off-by Thomas Petazzoni <[email protected]>
Regards,
Arnout
Quoted 25 lines
--- package/uclibc/Config.in | 2 ++ 1 file changed, 2 insertions(+)package/uclibc/Config.in +2
-0@@ -48,6 +48,7 @@ config BR2_TOOLCHAIN_BUILDROOT_LOCALE choice prompt "Thread library implementation" default BR2_PTHREADS_NATIVE + default BR2_PTHREADS_OLD if !BR2_USE_MMU help Use this option to select the thread library implementation that should be used in your toolchain.@@ -69,6 +70,7 @@ choice bool "Native POSIX Threading (NPTL)" select BR2_TOOLCHAIN_HAS_THREADS select BR2_TOOLCHAIN_HAS_THREADS_NPTL + depends on BR2_USE_MMU depends on !BR2_m68k && !BR2_x86_i386 endchoice
Signature · 6 lines
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: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
PATCH 6/16 uclibc: NPTL thread implementation only available on MMU platforms
In reply to Thomas PetazzoniQuoted 25 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Thomas" == Thomas Petazzoni <[email protected]> writes:
As indicated by the uClibc-ng source code, the NPTL thread implementation is only available on MMU platforms, so we replicate this dependency in Buildroot so that the appropriate thread implementation is chosen by default on ARM noMMU.
Signed-off-by Thomas Petazzoni <[email protected]>--- package/uclibc/Config.in | 2 ++ 1 file changed, 2 insertions(+)package/uclibc/Config.in +1
-0@@ -48,6 +48,7 @@ config BR2_TOOLCHAIN_BUILDROOT_LOCALE choice prompt "Thread library implementation" default BR2_PTHREADS_NATIVE + default BR2_PTHREADS_OLD if !BR2_USE_MMU help Use this option to select the thread library implementation that should be used in your toolchain.
package/uclibc/Config.in choice · line 74
Quoted 5 lines
package/uclibc/Config.in +1
-0@@ -69,6 +70,7 @@ choice bool "Native POSIX Threading (NPTL)" select BR2_TOOLCHAIN_HAS_THREADS select BR2_TOOLCHAIN_HAS_THREADS_NPTL + depends on BR2_USE_MMU depends on !BR2_m68k && !BR2_x86_i386
Not related to this commit, but I think we should really remove m68k by now - I marked it broken back in 2009 and nobody has cared to fix it:
commit 8161c45b891aca4c3184c320de81a44767c7cece
Author: Peter Korsgaard <[email protected]> Date: Mon Jan 12 20:58:54 2009 +0000
buildroot: mark ia64, m68k, nios2, sparc and sparc64 as broken
No sense in showing the architecture options when they cannot even build the toolchain.
Signature · 1 line
Bye, Peter Korsgaard
PATCH 6/16 uclibc: NPTL thread implementation only available on MMU platforms
Hello,
Quoted 11 lines · Peter Korsgaard
Not related to this commit, but I think we should really remove m68k by now - I marked it broken back in 2009 and nobody has cared to fix it:
commit
8161c45b891aca4c3184c320de81a44767c7ceceAuthor: Peter Korsgaard <[email protected]> Date: Mon Jan 12 20:58:54 2009 +0000buildroot: mark ia64, m68k, nios2, sparc and sparc64 as broken
No sense in showing the architecture options when they cannot even build the toolchain.
Let's Cc: Waldemar on this, I believe he has done some work on m68k for uClibc-ng.
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 6/16 uclibc: NPTL thread implementation only available on MMU platforms
Hi,
Thomas Petazzoni wrote,
Quoted 11 lines
Hello,
Quoted 7 lines · Peter Korsgaard
Not related to this commit, but I think we should really remove m68k by now - I marked it broken back in 2009 and nobody has cared to fix it:
commit
8161c45b891aca4c3184c320de81a44767c7ceceAuthor: Peter Korsgaard <[email protected]> Date: Mon Jan 12 20:58:54 2009 +0000
Quoted 7 lines
Quoted 4 lines
buildroot: mark ia64, m68k, nios2, sparc and sparc64 as broken
No sense in showing the architecture options when they cannot even build the toolchain.
Let's Cc: Waldemar on this, I believe he has done some work on m68k for uClibc-ng.
I have once sent a patch to enable m68k support. It needs to be updated and incorporate Arnouts review comments.
Is there still interest in reviving m68k support, than I can work on it.
best regards
Waldemar
PATCH 6/16 uclibc: NPTL thread implementation only available on MMU platforms
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Waldemar" == Waldemar Brodkorb <[email protected]> writes:
Hi,
Quoted 4 lines
I have once sent a patch to enable m68k support. It needs to be updated and incorporate Arnouts review comments.
Is there still interest in reviving m68k support, than I can work on it.
If it works and somebody cares enough about it to look at build errors and verify that stuff still works at runtime - Then I have absolutely no problem keeping m68k support.
Signature · 2 lines
Venlig hilsen, Peter Korsgaard
PATCH 7/16 musl: build broken on Thumb, use ARM mode
In reply to Thomas PetazzoniBuilding the musl C library on Thumb (Thumb1, not Thumb2), fails with:
{standard input}:20: Error: only lo regs allowed with immediate -- mov fp,#0' {standard input}:21: Error: only lo regs allowed with immediate -- mov lr,#0' {standard input}:25: Error: unshifted register required -- `and ip,a1,#-16'
Since there are no cores that we support that are Thumb1 only, use the same solution as the one used by glibc: build the C library in ARM mode.
--- package/musl/musl.mk | 5 +++++ 1 file changed, 5 insertions(+)
package/musl/musl.mk +5 -0
@@ -23,6 +23,11 @@ MUSL_ADD_TOOLCHAIN_DEPENDENCY = NO MUSL_INSTALL_STAGING = YES +# Thumb build is broken, build in ARM mode +ifeq ($(BR2_ARM_INSTRUCTIONS_THUMB),y) +MUSL_EXTRA_CFLAGS += -marm +endif + define MUSL_CONFIGURE_CMDS (cd $(@D); \ $(TARGET_CONFIGURE_OPTS) \
Signature · 1 line
2.6.4
PATCH 7/16 musl: build broken on Thumb, use ARM mode
Quoted 20 lines · Thomas Petazzoni
Building the musl C library on Thumb (Thumb1, not Thumb2), fails with:
{standard input}:20: Error: only lo regs allowed with immediate --
mov fp,#0' {standard input}:21: Error: only lo regs allowed with immediate --mov lr,#0' {standard input}:25: Error: unshifted register required -- `and ip,a1,#-16'Since there are no cores that we support that are Thumb1 only, use the same solution as the one used by glibc: build the C library in ARM mode.
Signed-off-by Thomas Petazzoni <[email protected]>--- package/musl/musl.mk | 5 +++++ 1 file changed, 5 insertions(+)package/musl/musl.mk +0
-0
package/musl/musl.mk MUSL_ADD_TOOLCHAIN_DEPENDENCY = NO · line 26
Quoted 4 lines
package/musl/musl.mk +1
-0@@ -23,6 +23,11 @@ MUSL_ADD_TOOLCHAIN_DEPENDENCY = NO MUSL_INSTALL_STAGING = YES +# Thumb build is broken, build in ARM mode
The comment about all our thumb1 architectures supporting arm mode should be
repeated here IMHO.
package/musl/musl.mk MUSL_ADD_TOOLCHAIN_DEPENDENCY = NO · line 27
Quoted 1 line
package/musl/musl.mk +1
-0+ifeq ($(BR2_ARM_INSTRUCTIONS_THUMB),y)
So this one would also have to be changed if INSTRUCTIONS_THUMB2 is removed.
Hm, maybe not such a good idea after all... So instead, just add a depends on !THUMB2 to BR2_ARM_INSTRUCTIONS_THUMB.
Regards,
Arnout
Quoted 7 lines
package/musl/musl.mk +3
-0+MUSL_EXTRA_CFLAGS += -marm +endif + define MUSL_CONFIGURE_CMDS (cd $(@D); \ $(TARGET_CONFIGURE_OPTS) \
Signature · 6 lines
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: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
PATCH 7/16 musl: build broken on Thumb, use ARM mode
Hello,
Quoted 10 lines · Arnout Vandecappelle
Quoted 1 line
+# Thumb build is broken, build in ARM mode
The comment about all our thumb1 architectures supporting arm mode should be
repeated here IMHO.Quoted 1 line
+ifeq ($(BR2_ARM_INSTRUCTIONS_THUMB),y)
So this one would also have to be changed if
INSTRUCTIONS_THUMB2is removed.
Hm, maybe not such a good idea after all... So instead, just add a depends on !THUMB2 toBR2_ARM_INSTRUCTIONS_THUMB.
Aah, so you come to the same conclusion as me: keeping BR2_ARM_INSTRUCTIONS_THUMB *and* BR2_ARM_INSTRUCTIONS_THUMB2 is simpler :-)
The depends on !BR2_ARM_CPU_HAS_THUMB2 indeed needs to be added to BR2_ARM_INSTRUCTIONS_THUMB if we change BR2_ARM_CPU_HAS_THUMB2 to make it select BR2_ARM_CPU_HAS_THUMB. IMO, this is a rather useless change, since in practice, you don't care that Thumb2 is a superset of Thumb:
you will only allow Thumb2 for Thumb2-capable cores, and only allow Thumb for Thumb-capable cores.
But if you like it, I'm happy to do this useless change :-)
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 8/16 toolchain-buildroot: update glibc comment for noMMU
In reply to Thomas Petazzoniglibc is not available for noMMU platforms, so it doesn't make sense to show the comment about glibc requiring dynamic libraries on noMMU platforms.
--- toolchain/toolchain-buildroot/Config.in | 1 + 1 file changed, 1 insertion(+)
toolchain/toolchain-buildroot/Config.in +1 -0
@@ -83,6 +83,7 @@ config BR2_TOOLCHAIN_BUILDROOT_GLIBC http://www.gnu.org/software/libc/ comment "(e)glibc only available with shared lib support" + depends on BR2_USE_MMU depends on BR2_STATIC_LIBS config BR2_TOOLCHAIN_BUILDROOT_MUSL
Signature · 1 line
2.6.4
PATCH 8/16 toolchain-buildroot: update glibc comment for noMMU
Quoted 14 lines · Thomas Petazzoni
glibc is not available for noMMU platforms, so it doesn't make sense to show the comment about glibc requiring dynamic libraries on noMMU platforms.
Signed-off-by Thomas Petazzoni <[email protected]>--- toolchain/toolchain-buildroot/Config.in | 1 + 1 file changed, 1 insertion(+)toolchain/toolchain-buildroot/Config.in +0
-0
toolchain/toolchain-buildroot/Config.in config BR2_TOOLCHAIN_BUILDROOT_GLIBC · line 86
Quoted 4 lines
toolchain/toolchain-buildroot/Config.in +1
-0@@ -83,6 +83,7 @@ config BR2_TOOLCHAIN_BUILDROOT_GLIBC http://www.gnu.org/software/libc/ comment "(e)glibc only available with shared lib support" + depends on BR2_USE_MMU
Actually, the rest of the architecture dependencies should also be repeated
then. It's a huge blob, so maybe introduce GLIBC_ARCH_DEPENDS? Which could, by the way, also be used to protect comments for packages that depend on glibc.
Regards,
Arnout
Quoted 4 lines
toolchain/toolchain-buildroot/Config.in +0
-0depends on BR2_STATIC_LIBS config BR2_TOOLCHAIN_BUILDROOT_MUSL
Signature · 6 lines
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: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
PATCH 8/16 toolchain-buildroot: update glibc comment for noMMU
Hello,
Quoted 6 lines · Arnout Vandecappelle
toolchain/toolchain-buildroot/Config.in config BR2_TOOLCHAIN_BUILDROOT_GLIBC · line 86
Quoted 2 lines
comment "(e)glibc only available with shared lib support"
toolchain/toolchain-buildroot/Config.in +1
-0+ depends on BR2_USE_MMUActually, the rest of the architecture dependencies should also be repeated
then. It's a huge blob, so maybe introduceGLIBC_ARCH_DEPENDS? Which could, by the way, also be used to protect comments for packages that depend on glibc.
I'll be happy to do that, however if you agree, I'd prefer to handle it in a separate patch series. This one is already 18 patches long (in its new version), and the problem you're pointing is not introduced by my patch series.
Once this patch series is merged, I'll take care of introducing foo_ARCH_DEPENDS options for the different C libraries.
Is it OK for you?
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 8/16 toolchain-buildroot: update glibc comment for noMMU
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Thomas" == Thomas Petazzoni <[email protected]> writes:
Hi,
Quoted 4 lines
Once this patch series is merged, I'll take care of introducing
foo_ARCH_DEPENDSoptions for the different C libraries.Is it OK for you?
Yes, lets please handle that seperately from this.
Signature · 1 line
Bye, Peter Korsgaard
PATCH 8/16 toolchain-buildroot: update glibc comment for noMMU
In reply to Thomas PetazzoniQuoted 11 lines · Thomas Petazzoni
Hello,
Quoted 6 lines · Arnout Vandecappelle
toolchain/toolchain-buildroot/Config.in config BR2_TOOLCHAIN_BUILDROOT_GLIBC · line 86
Quoted 2 lines
comment "(e)glibc only available with shared lib support"
toolchain/toolchain-buildroot/Config.in +1
-0+ depends on BR2_USE_MMUActually, the rest of the architecture dependencies should also be repeated
then. It's a huge blob, so maybe introduceGLIBC_ARCH_DEPENDS? Which could, by the way, also be used to protect comments for packages that depend on glibc.
Quoted 4 lines
I'll be happy to do that, however if you agree, I'd prefer to handle it in a separate patch series. This one is already 18 patches long (in its new version), and the problem you're pointing is not introduced by my patch series.
Well, I don't think it makes sense to add the noMMU dependency without the
rest of the arch dependencies. So just drop this patch from the series I'd say.
Regards,
Arnout
Quoted 8 lines
Once this patch series is merged, I'll take care of introducing
foo_ARCH_DEPENDSoptions for the different C libraries.Is it OK for you?
Thomas
Signature · 6 lines
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: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
PATCH 9/16 toolchain-buildroot: don't show musl on noMMU platforms
In reply to Thomas PetazzoniWhile musl has recently gained noMMU support for the sh2 platform, we don't support this yet. So for the time being, let's not show musl as an available C library on noMMU platforms. This is for example important on ARM noMMU: ARM is supported by musl, but not its noMMU variants.
--- toolchain/toolchain-buildroot/Config.in | 3 +++ 1 file changed, 3 insertions(+)
toolchain/toolchain-buildroot/Config.in +3 -0
@@ -94,6 +94,9 @@ config BR2_TOOLCHAIN_BUILDROOT_MUSL depends on !BR2_powerpc_SPE # not supported, build breaks # Unsupported for MIPS R6 depends on !BR2_mips_32r6 && !BR2_mips_64r6 + # sh2 nommu is supported by musl, but we don't have support + # for it yet in Buildroot. + depends on BR2_USE_MMU select BR2_TOOLCHAIN_USES_MUSL help This option selects musl as the C library for the
Signature · 1 line
2.6.4
PATCH 9/16 toolchain-buildroot: don't show musl on noMMU platforms
Quoted 16 lines · Thomas Petazzoni
While musl has recently gained noMMU support for the sh2 platform, we don't support this yet. So for the time being, let's not show musl as an available C library on noMMU platforms. This is for example important on ARM noMMU: ARM is supported by musl, but not its noMMU variants.
Signed-off-by Thomas Petazzoni <[email protected]>--- toolchain/toolchain-buildroot/Config.in | 3 +++ 1 file changed, 3 insertions(+)toolchain/toolchain-buildroot/Config.in +0
-0
toolchain/toolchain-buildroot/Config.in config BR2_TOOLCHAIN_BUILDROOT_MUSL · line 98
Quoted 5 lines
toolchain/toolchain-buildroot/Config.in +2
-0@@ -94,6 +94,9 @@ config BR2_TOOLCHAIN_BUILDROOT_MUSL depends on !BR2_powerpc_SPE # not supported, build breaks # Unsupported for MIPS R6 depends on !BR2_mips_32r6 && !BR2_mips_64r6 + # sh2 nommu is supported by musl, but we don't have support + # for it yet in Buildroot.
We don't have support for sh2 at all, and also we used to have it, so I
wouldn't use 'yet'. Better: we don't have support for sh2 in Buildroot.
With that:
Regards,
Arnout
Quoted 5 lines
toolchain/toolchain-buildroot/Config.in +1
-0+ depends on BR2_USE_MMU select BR2_TOOLCHAIN_USES_MUSL help This option selects musl as the C library for the
Signature · 6 lines
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: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
PATCH 9/16 toolchain-buildroot: don't show musl on noMMU platforms
Dear Arnout Vandecappelle,
Quoted 12 lines · Arnout Vandecappelle
Quoted 11 lines · Thomas Petazzoni
While musl has recently gained noMMU support for the sh2 platform, we don't support this yet. So for the time being, let's not show musl as an available C library on noMMU platforms. This is for example important on ARM noMMU: ARM is supported by musl, but not its noMMU variants.
Signed-off-by Thomas Petazzoni <[email protected]>--- toolchain/toolchain-buildroot/Config.in | 3 +++ 1 file changed, 3 insertions(+)
Quoted 13 lines
toolchain/toolchain-buildroot/Config.in config BR2_TOOLCHAIN_BUILDROOT_MUSL · line 98
Quoted 10 lines
toolchain/toolchain-buildroot/Config.in +2
-0@@ -94,6 +94,9 @@ config BR2_TOOLCHAIN_BUILDROOT_MUSL depends on !BR2_powerpc_SPE # not supported, build breaks # Unsupported for MIPS R6 depends on !BR2_mips_32r6 && !BR2_mips_64r6 + # sh2 nommu is supported by musl, but we don't have support + # for it yet in Buildroot.We don't have support for sh2 at all, and also we used to have it, so I
wouldn't use 'yet'. Better: we don't have support for sh2 in Buildroot.
We do have sh2a in the choice of sub-architectures for SuperH:
config BR2_sh2a
bool "sh2a (SH2A big endian)"
Whether it works well or not is a different question, but saying that we don't have support for sh2 at all is not quite correct.
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 9/16 toolchain-buildroot: don't show musl on noMMU platforms
Quoted 29 lines · Thomas Petazzoni
Dear Arnout Vandecappelle,
Quoted 12 lines · Arnout Vandecappelle
Quoted 11 lines · Thomas Petazzoni
While musl has recently gained noMMU support for the sh2 platform, we don't support this yet. So for the time being, let's not show musl as an available C library on noMMU platforms. This is for example important on ARM noMMU: ARM is supported by musl, but not its noMMU variants.
Signed-off-by Thomas Petazzoni <[email protected]>--- toolchain/toolchain-buildroot/Config.in | 3 +++ 1 file changed, 3 insertions(+)Quoted 13 lines
toolchain/toolchain-buildroot/Config.in config BR2_TOOLCHAIN_BUILDROOT_MUSL · line 98
Quoted 10 lines
toolchain/toolchain-buildroot/Config.in +2
-0@@ -94,6 +94,9 @@ config BR2_TOOLCHAIN_BUILDROOT_MUSL depends on !BR2_powerpc_SPE # not supported, build breaks # Unsupported for MIPS R6 depends on !BR2_mips_32r6 && !BR2_mips_64r6 + # sh2 nommu is supported by musl, but we don't have support + # for it yet in Buildroot.We don't have support for sh2 at all, and also we used to have it, so I
wouldn't use 'yet'. Better: we don't have support for sh2 in Buildroot.
Quoted 7 lines
We do have sh2a in the choice of sub-architectures for SuperH:
config
BR2_sh2a
bool "sh2a (SH2A big endian)"Whether it works well or not is a different question, but saying that we don't have support for sh2 at all is not quite correct.
Sorry, I thought that sh2a was a distinct architecture from sh2. Never mind then.
My Rev-by is already there.
Regards,
Arnout
Quoted 3 lines
Thomas
Signature · 6 lines
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: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
PATCH 10/16 arch/arm: add support for hard-float on Cortex-M4
In reply to Thomas PetazzoniCortex-M4 cores can optionally have a FPv4-SP floating point unit (which is different than the VFPv4). This commit adds the necessary Config.in options to allow the user to enable the use of this FPU, and to build an EABIhf toolchain for Cortex-M4.
Note that for now the kernel does not have CONFIG_VFP support for ARMv7-M, so in practice, this VFP support cannot really be used for the moment.
--- arch/Config.in.arm | 23 +++++++++++++++++++++-- 1 file changed, 21 insertions(+), 2 deletions(-)
arch/Config.in.arm +21 -2
@@ -31,6 +31,12 @@ config BR2_ARM_CPU_HAS_VFPV4 bool select BR2_ARM_CPU_HAS_VFPV3 +config BR2_ARM_CPU_MAYBE_HAS_FPV4_SP + bool + +config BR2_ARM_CPU_HAS_FPV4_SP + bool + config BR2_ARM_CPU_HAS_ARM bool
@@ -177,6 +183,7 @@ config BR2_cortex_m3 config BR2_cortex_m4 bool "cortex-M4" select BR2_ARM_CPU_HAS_THUMB2 + select BR2_ARM_CPU_MAYBE_HAS_FPV4_SP select BR2_ARM_CPU_ARMV7M config BR2_fa526 bool "fa526/626"
@@ -218,10 +225,11 @@ config BR2_ARM_ENABLE_NEON config BR2_ARM_ENABLE_VFP bool "Enable VFP extension support" - depends on BR2_ARM_CPU_MAYBE_HAS_VFPV2 + depends on BR2_ARM_CPU_MAYBE_HAS_VFPV2 || BR2_ARM_CPU_MAYBE_HAS_FPV4_SP select BR2_ARM_CPU_HAS_VFPV4 if BR2_ARM_CPU_MAYBE_HAS_VFPV4 select BR2_ARM_CPU_HAS_VFPV3 if BR2_ARM_CPU_MAYBE_HAS_VFPV3 select BR2_ARM_CPU_HAS_VFPV2 if BR2_ARM_CPU_MAYBE_HAS_VFPV2 + select BR2_ARM_CPU_HAS_FPV4_SP if BR2_ARM_CPU_MAYBE_HAS_FPV4_SP help For some CPU cores, the VFP extension is optional. Select this option if you are certain your particular
@@ -264,7 +272,7 @@ config BR2_ARM_EABI config BR2_ARM_EABIHF bool "EABIhf" - depends on BR2_ARM_CPU_HAS_VFPV2 + depends on BR2_ARM_CPU_HAS_VFPV2 || BR2_ARM_CPU_HAS_FPV4_SP help The EABIhf is an extension of EABI which supports the 'hard' floating point model. This model uses the floating point
@@ -285,6 +293,7 @@ endchoice choice prompt "Floating point strategy" depends on BR2_ARM_EABI || BR2_ARM_EABIHF + default BR2_ARM_FPU_FPV4_SP if BR2_ARM_CPU_HAS_FPV4_SP default BR2_ARM_FPU_VFPV4D16 if BR2_ARM_CPU_HAS_VFPV4 default BR2_ARM_FPU_VFPV3D16 if BR2_ARM_CPU_HAS_VFPV3 default BR2_ARM_FPU_VFPV2 if BR2_ARM_CPU_HAS_VFPV2
@@ -374,6 +383,15 @@ config BR2_ARM_FPU_VFPV4D16 cores, including the earlier Cortex-A{8, 9}, you should instead select VFPv3-D16. +config BR2_ARM_FPU_FPV4_SP + bool "FPv4-SP-D16" + depends on BR2_ARM_CPU_HAS_FPV4_SP + help + This option allows to use the FPv4-SP floating point unit, + as available in some ARMv7-M processors (Cortex-M4). This + option requires a FPv4-SP unit that has 16 double-precision + registers. + config BR2_ARM_FPU_NEON bool "NEON" depends on BR2_ARM_CPU_HAS_NEON
@@ -475,6 +493,7 @@ config BR2_GCC_TARGET_FPU default "vfpv3-d16" if BR2_ARM_FPU_VFPV3D16 default "vfpv4" if BR2_ARM_FPU_VFPV4 default "vfpv4-d16" if BR2_ARM_FPU_VFPV4D16 + default "fpv4-sp-d16" if BR2_ARM_FPU_FPV4_SP default "neon" if BR2_ARM_FPU_NEON default "neon-vfpv4" if BR2_ARM_FPU_NEON_VFPV4
Signature · 1 line
2.6.4
PATCH 10/16 arch/arm: add support for hard-float on Cortex-M4
Quoted 8 lines · Thomas Petazzoni
Cortex-M4 cores can optionally have a FPv4-SP floating point unit (which is different than the VFPv4). This commit adds the necessary Config.in options to allow the user to enable the use of this FPU, and to build an EABIhf toolchain for Cortex-M4.
Note that for now the kernel does not have
CONFIG_VFPsupport for ARMv7-M, so in practice, this VFP support cannot really be used for the moment.
As in, when you select this option, then your target will fail dramatically
because it's hardfloat so even a simple printf will crash violently if a reschedule happens in the middle?
If so, I'm not so sure we really want this option...
Quoted 11 lines
Signed-off-by Thomas Petazzoni <[email protected]>--- arch/Config.in.arm | 23 +++++++++++++++++++++-- 1 file changed, 21 insertions(+), 2 deletions(-)arch/Config.in.arm +0
-0
arch/Config.in.arm config BR2_ARM_CPU_HAS_VFPV4 · line 34
Quoted 4 lines
arch/Config.in.arm +1
-0@@ -31,6 +31,12 @@ config BR2_ARM_CPU_HAS_VFPV4 bool select BR2_ARM_CPU_HAS_VFPV3 +config BR2_ARM_CPU_MAYBE_HAS_FPV4_SP
Since the gcc option has -d16, shouldn't we have that as well?
Quoted 17 lines
arch/Config.in.arm +6
-0+ bool + +config BR2_ARM_CPU_HAS_FPV4_SP + bool + config BR2_ARM_CPU_HAS_ARM bool@@ -177,6 +183,7 @@ config BR2_cortex_m3 config BR2_cortex_m4 bool "cortex-M4" select BR2_ARM_CPU_HAS_THUMB2 + select BR2_ARM_CPU_MAYBE_HAS_FPV4_SP select BR2_ARM_CPU_ARMV7M config BR2_fa526 bool "fa526/626"
arch/Config.in.arm config BR2_ARM_ENABLE_NEON · line 227
Quoted 3 lines
arch/Config.in.arm +0
-0@@ -218,10 +225,11 @@ config BR2_ARM_ENABLE_NEON config BR2_ARM_ENABLE_VFP bool "Enable VFP extension support"
As I understand it (but I could be wrong), FPv4 is not again different from
VFP, i.e. it's again a different ABI (like softfloat and VFP are different ABIs). At least, you get different flags in the ELF files. So I would tend to really make a separate option for FPv4, to avoid all confusion. That is, assuming that I'm right about it being a different ABI.
Note that in practice it doesn't make much of a difference becaus you never
have both VFP and FPv4 on the same processor. Well, at least for the time being
- who knows what kind of ugliness ARM will still invent :-)
Regards,
Arnout
Quoted 51 lines
arch/Config.in.arm +14
-2- depends on BR2_ARM_CPU_MAYBE_HAS_VFPV2 + depends on BR2_ARM_CPU_MAYBE_HAS_VFPV2 || BR2_ARM_CPU_MAYBE_HAS_FPV4_SP select BR2_ARM_CPU_HAS_VFPV4 if BR2_ARM_CPU_MAYBE_HAS_VFPV4 select BR2_ARM_CPU_HAS_VFPV3 if BR2_ARM_CPU_MAYBE_HAS_VFPV3 select BR2_ARM_CPU_HAS_VFPV2 if BR2_ARM_CPU_MAYBE_HAS_VFPV2 + select BR2_ARM_CPU_HAS_FPV4_SP if BR2_ARM_CPU_MAYBE_HAS_FPV4_SP help For some CPU cores, the VFP extension is optional. Select this option if you are certain your particular@@ -264,7 +272,7 @@ config BR2_ARM_EABI config BR2_ARM_EABIHF bool "EABIhf" - depends on BR2_ARM_CPU_HAS_VFPV2 + depends on BR2_ARM_CPU_HAS_VFPV2 || BR2_ARM_CPU_HAS_FPV4_SP help The EABIhf is an extension of EABI which supports the 'hard' floating point model. This model uses the floating point@@ -285,6 +293,7 @@ endchoice choice prompt "Floating point strategy" depends on BR2_ARM_EABI || BR2_ARM_EABIHF + default BR2_ARM_FPU_FPV4_SP if BR2_ARM_CPU_HAS_FPV4_SP default BR2_ARM_FPU_VFPV4D16 if BR2_ARM_CPU_HAS_VFPV4 default BR2_ARM_FPU_VFPV3D16 if BR2_ARM_CPU_HAS_VFPV3 default BR2_ARM_FPU_VFPV2 if BR2_ARM_CPU_HAS_VFPV2@@ -374,6 +383,15 @@ config BR2_ARM_FPU_VFPV4D16 cores, including the earlier Cortex-A{8, 9}, you should instead select VFPv3-D16. +config BR2_ARM_FPU_FPV4_SP + bool "FPv4-SP-D16" + depends on BR2_ARM_CPU_HAS_FPV4_SP + help + This option allows to use the FPv4-SP floating point unit, + as available in some ARMv7-M processors (Cortex-M4). This + option requires a FPv4-SP unit that has 16 double-precision + registers. + config BR2_ARM_FPU_NEON bool "NEON" depends on BR2_ARM_CPU_HAS_NEON@@ -475,6 +493,7 @@ config BR2_GCC_TARGET_FPU default "vfpv3-d16" if BR2_ARM_FPU_VFPV3D16 default "vfpv4" if BR2_ARM_FPU_VFPV4 default "vfpv4-d16" if BR2_ARM_FPU_VFPV4D16 + default "fpv4-sp-d16" if BR2_ARM_FPU_FPV4_SP default "neon" if BR2_ARM_FPU_NEON default "neon-vfpv4" if BR2_ARM_FPU_NEON_VFPV4
Signature · 6 lines
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: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
PATCH 10/16 arch/arm: add support for hard-float on Cortex-M4
Hello,
Quoted 6 lines · Arnout Vandecappelle
Quoted 5 lines · Thomas Petazzoni
Cortex-M4 cores can optionally have a FPv4-SP floating point unit (which is different than the VFPv4). This commit adds the necessary Config.in options to allow the user to enable the use of this FPU, and to build an EABIhf toolchain for Cortex-M4.
Quoted 7 lines
Quoted 3 lines
Note that for now the kernel does not have
CONFIG_VFPsupport for ARMv7-M, so in practice, this VFP support cannot really be used for the moment.As in, when you select this option, then your target will fail dramatically
because it's hardfloat so even a simple printf will crash violently if a reschedule happens in the middle?
My tests show that a VFP-using userspace indeed doesn't start. I've mailed the STM32 kernel maintainer to see what the plans are in terms of FPU support.
Quoted 1 line
If so, I'm not so sure we really want this option...
Agreed. I saw that the STM32F4 had a FPU, so I wanted to support that, and it's only when I started testing on HW that I realized that the kernel CONFIG_VFP option could not be enabled for this platform.
Depending on the answer from the STM32 kernel maintainer, I will either drop or keep (disabled in some form?) this floating point support.
Quoted 9 lines
Quoted 2 lines
config
BR2_ARM_ENABLE_VFP
bool "Enable VFP extension support"As I understand it (but I could be wrong), FPv4 is not again different from
VFP, i.e. it's again a different ABI (like softfloat and VFP are different ABIs). At least, you get different flags in the ELF files. So I would tend to really make a separate option for FPv4, to avoid all confusion. That is, assuming that I'm right about it being a different ABI.
Quoted 3 lines
Note that in practice it doesn't make much of a difference becaus you never
have both VFP and FPv4 on the same processor. Well, at least for the time being
- who knows what kind of ugliness ARM will still invent :-)
The BR2_ARM_ENABLE_VFP option is *not* about choosing the ABI. The BR2_ARM_ENABLE_VFP option is only here for cores that have an *optional* FPU so that the user can say whether his specific SoC has chosen to include the FPU or not.
If you for example have an hypothetical Cortex-M5 core that has a mandatory FPU, then this BR2_ARM_ENABLE_VFP option would not appear, as we know all Cortex-M5 based SoCs have FPU.
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 10/16 arch/arm: add support for hard-float on Cortex-M4
Quoted 21 lines · Thomas Petazzoni
Hello,
Quoted 6 lines · Arnout Vandecappelle
Quoted 5 lines · Thomas Petazzoni
Cortex-M4 cores can optionally have a FPv4-SP floating point unit (which is different than the VFPv4). This commit adds the necessary Config.in options to allow the user to enable the use of this FPU, and to build an EABIhf toolchain for Cortex-M4.
Quoted 7 lines
Quoted 3 lines
Note that for now the kernel does not have
CONFIG_VFPsupport for ARMv7-M, so in practice, this VFP support cannot really be used for the moment.As in, when you select this option, then your target will fail dramatically
because it's hardfloat so even a simple printf will crash violently if a reschedule happens in the middle?My tests show that a VFP-using userspace indeed doesn't start. I've mailed the STM32 kernel maintainer to see what the plans are in terms of FPU support.
Quoted 8 lines
Quoted 1 line
If so, I'm not so sure we really want this option...
Agreed. I saw that the STM32F4 had a FPU, so I wanted to support that, and it's only when I started testing on HW that I realized that the kernel
CONFIG_VFPoption could not be enabled for this platform.Depending on the answer from the STM32 kernel maintainer, I will either drop or keep (disabled in some form?) this floating point support.
It's also an option to just keep it lingering in patchwork for a while.
Quoted 10 lines
Quoted 10 lines
Quoted 3 lines
config
BR2_ARM_ENABLE_VFP
bool "Enable VFP extension support"As I understand it (but I could be wrong), FPv4 is not again different from
VFP, i.e. it's again a different ABI (like softfloat and VFP are different ABIs). At least, you get different flags in the ELF files. So I would tend to really make a separate option for FPv4, to avoid all confusion. That is, assuming that I'm right about it being a different ABI.
Quoted 8 lines
Quoted 3 lines
Note that in practice it doesn't make much of a difference becaus you never
have both VFP and FPv4 on the same processor. Well, at least for the time being
- who knows what kind of ugliness ARM will still invent :-)The
BR2_ARM_ENABLE_VFPoption is *not* about choosing the ABI. TheBR2_ARM_ENABLE_VFPoption is only here for cores that have an *optional* FPU so that the user can say whether his specific SoC has chosen to include the FPU or not.
Oops my bad, I was confusing it with the BR2_ARM_FPU_* options.
Regards,
Arnout
Quoted 7 lines
If you for example have an hypothetical Cortex-M5 core that has a mandatory FPU, then this
BR2_ARM_ENABLE_VFPoption would not appear, as we know all Cortex-M5 based SoCs have FPU.Thomas
Signature · 6 lines
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: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
PATCH 10/16 arch/arm: add support for hard-float on Cortex-M4
Hello,
Quoted 4 lines · Arnout Vandecappelle
Quoted 2 lines
Depending on the answer from the STM32 kernel maintainer, I will either drop or keep (disabled in some form?) this floating point support.
It's also an option to just keep it lingering in patchwork for a while.
I got some feedback from the STM32 kernel maintainer, and he doesn't intend to work on FPU support anytime soon. So I've dropped the patch for now.
I don't like to let things linger in patchwork. We already have enough stuff there. If one day we want to re-add EABIhf support for Cortex-M, my patch will be in the archives (and the patch is anyway simple enough that anyone can re-create without much effort).
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 11/16 package/Makefile.in: adjust LDFLAGS for elf2flt
In reply to Thomas PetazzoniSo far, our LDFLAGS for the BR2_BINFMT_FLAT case were only used on Blackfin. However, passing -elf2flt in LDFLAGS is wrong. Indeed, LDFLAGS are not linker flags, but flags passed to the compiler when linking.
If you pass -elf2flt to the compiler when linking, it is understood as "-e lf2flt", i.e "the entry point is named lf2flt", which isn't exactly the intention. We in fact need to pass -Wl,-elf2flt in LDFLAGS as well, so that the compiler passes -elf2flt down to the linker.
For some reason, this option does not cause an issue with the Blackfin toolchain, but it does with either a Buildroot toolchain for Cortex-M or an OSELAS toolchain for Cortex-M. We have verified that passing -Wl,-elf2flt continues to work with the Blackfin toolchain.
--- package/Makefile.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
package/Makefile.in +1 -1
@@ -145,7 +145,7 @@ TARGET_CFLAGS += $(if $($(PKG)_FLAT_STACKSIZE),-Wl$(comma)-elf2flt=-s$($(PKG)_FL -Wl$(comma)-elf2flt) TARGET_CXXFLAGS += $(if $($(PKG)_FLAT_STACKSIZE),-Wl$(comma)-elf2flt=-s$($(PKG)_FLAT_STACKSIZE),\ -Wl$(comma)-elf2flt) -TARGET_LDFLAGS += $(if $($(PKG)_FLAT_STACKSIZE),-elf2flt=-s$($(PKG)_FLAT_STACKSIZE),-elf2flt) +TARGET_LDFLAGS += $(if $($(PKG)_FLAT_STACKSIZE),-Wl$(comma)-elf2flt=-s$($(PKG)_FLAT_STACKSIZE),-Wl$(comma)-elf2flt) endif ifeq ($(BR2_BINFMT_FLAT_SHARED),y)
Signature · 1 line
2.6.4
PATCH 11/16 package/Makefile.in: adjust LDFLAGS for elf2flt
Quoted 5 lines · Thomas Petazzoni
So far, our LDFLAGS for the
BR2_BINFMT_FLATcase were only used on Blackfin. However, passing -elf2flt in LDFLAGS is wrong. Indeed, LDFLAGS are not linker flags, but flags passed to the compiler when linking.
Quoted 7 lines
If you pass -elf2flt to the compiler when linking, it is understood as "-e lf2flt", i.e "the entry point is named lf2flt", which isn't exactly the intention. We in fact need to pass -Wl,-elf2flt in LDFLAGS as well, so that the compiler passes -elf2flt down to the linker.
For some reason, this option does not cause an issue with the Blackfin toolchain,
Probably because it isn't tested so much :-)
Quoted 5 lines
but it does with either a Buildroot toolchain for Cortex-M or an OSELAS toolchain for Cortex-M. We have verified that passing -Wl,-elf2flt continues to work with the Blackfin toolchain.
Signed-off-by Thomas Petazzoni <[email protected]>
Regards,
Arnout
Quoted 18 lines
--- package/Makefile.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)package/Makefile.in +1
-1@@ -145,7 +145,7 @@ TARGET_CFLAGS += $(if $($(PKG)_FLAT_STACKSIZE),-Wl$(comma)-elf2flt=-s$($(PKG)_FL -Wl$(comma)-elf2flt) TARGET_CXXFLAGS += $(if $($(PKG)_FLAT_STACKSIZE),-Wl$(comma)-elf2flt=-s$($(PKG)_FLAT_STACKSIZE),\ -Wl$(comma)-elf2flt) -TARGET_LDFLAGS += $(if $($(PKG)_FLAT_STACKSIZE),-elf2flt=-s$($(PKG)_FLAT_STACKSIZE),-elf2flt) +TARGET_LDFLAGS += $(if $($(PKG)_FLAT_STACKSIZE),-Wl$(comma)-elf2flt=-s$($(PKG)_FLAT_STACKSIZE),-Wl$(comma)-elf2flt) endif ifeq ($(BR2_BINFMT_FLAT_SHARED),y)
Signature · 6 lines
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: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
PATCH 12/16 elf2flt: use new upstream site and add ARM patch
In reply to Thomas PetazzoniThe uClinux developers now have a Github with elf2flt code, with an upstream that is again active. Let's switch to this upstream, to which Waldemar is contributing as well.
We also add an ARM patch from Waldemar, which was on his elf2flt repository and he submitted upstream.
--- .../0001-allow-to-build-arm-flat-binaries.patch | 123 +++++++++++++++++++++ package/elf2flt/elf2flt.mk | 5 +- 2 files changed, 125 insertions(+), 3 deletions(-) create mode 100644 package/elf2flt/0001-allow-to-build-arm-flat-binaries.patch
package/elf2flt/0001-allow-to-build-arm-flat-binaries.patch new file +123 -0
@@ -0,0 +1,123 @@ +From 56b082412c6f49d21f5e54831a40d1e7c45b3ee4 Mon Sep 17 00:00:00 2001 +From: Waldemar Brodkorb <[email protected]> +Date: Sat, 12 Mar 2016 22:09:30 +0100 +Subject: [PATCH] allow to build arm flat binaries + +Add patchset from ptxdist which is required to produce working +ARM flat binaries. Tested with busybox on Kinetis K70. + +Signed-off-by: Waldemar Brodkorb <[email protected]> +Signed-off-by: Thomas Petazzoni <[email protected]> +--- + elf2flt.c | 19 ++++++++++++------- + elf2flt.ld.in | 17 ++++++++++++++--- + 2 files changed, 26 insertions(+), 10 deletions(-) + +diff --git a/elf2flt.c b/elf2flt.c +index fcd797c..c6978e1 100644 +--- a/elf2flt.c ++++ b/elf2flt.c +@@ -56,6 +56,8 @@ const char *elf2flt_progname; + + #if defined(TARGET_h8300) + #include <elf/h8.h> /* TARGET_* ELF support for the BFD library */ ++#elif defined(TARGET_arm) ++#include <elf/arm.h> + #elif defined(__CYGWIN__) || defined(__MINGW32__) || defined(TARGET_nios) || defined(TARGET_nios2) + #include "cygwin-elf.h" /* Cygwin uses a local copy */ + #elif defined(TARGET_xtensa) +@@ -646,16 +648,23 @@ dump_symbols(symbols, number_of_symbols); + default: + goto good_32bit_resolved_reloc; + #elif defined(TARGET_arm) ++ case R_ARM_TARGET1: ++ case R_ARM_TARGET2: + case R_ARM_ABS32: + relocation_needed = 1; + break; + case R_ARM_REL32: ++ case R_ARM_JUMP24: ++ case R_ARM_CALL: + case R_ARM_THM_PC11: + case R_ARM_THM_PC22: ++ case R_ARM_THM_JUMP24: + case R_ARM_PC24: + case R_ARM_PLT32: + case R_ARM_GOTPC: + case R_ARM_GOT32: ++ case R_ARM_PREL31: ++ case R_ARM_NONE: + relocation_needed = 0; + break; + default: +@@ -871,9 +880,7 @@ dump_symbols(symbols, number_of_symbols); + relocation_needed = 1; + if (verbose) + fprintf(stderr, +- "%s vma=0x%x, " +- "value=0x%"BFD_VMA_FMT"x, " +- "address=0x%"BFD_VMA_FMT"x " ++ "%s vma=0x%x, value=0x%x, address=0x%x " + "sym_addr=0x%x rs=0x%x, opcode=0x%x\n", + "ABS32", + sym_vma, (*(q->sym_ptr_ptr))->value, +@@ -890,9 +897,7 @@ dump_symbols(symbols, number_of_symbols); + case R_ARM_PLT32: + if (verbose) + fprintf(stderr, +- "%s vma=0x%x, " +- "value=0x%"BFD_VMA_FMT"x, " +- "address=0x%"BFD_VMA_FMT"x " ++ "%s vma=0x%x, value=0x%x, address=0x%x " + "sym_addr=0x%x rs=0x%x, opcode=0x%x\n", + "PLT32", + sym_vma, (*(q->sym_ptr_ptr))->value, +@@ -1446,7 +1451,7 @@ DIS29_RELOCATION: + } + } + +- sprintf(&addstr[0], "+0x%lx", sym_addr - (*(q->sym_ptr_ptr))->value - ++ sprintf(&addstr[0], "+0x%x", sym_addr - (*(q->sym_ptr_ptr))->value - + bfd_section_vma(abs_bfd, sym_section)); + + +diff --git a/elf2flt.ld.in b/elf2flt.ld.in +index bfda0ef..ec1fe6f 100644 +--- a/elf2flt.ld.in ++++ b/elf2flt.ld.in +@@ -35,6 +35,8 @@ W_RODAT *(.rodata1) + W_RODAT *(.rodata.*) + W_RODAT *(.gnu.linkonce.r*) + ++ /* .ARM.extab name sections containing exception unwinding information */ ++ *(.ARM.extab* .gnu.linkonce.armextab.*) + /* This is special code area at the end of the normal + text section. It contains a small lookup table at + the start followed by the code pointed to by entries +@@ -43,11 +45,20 @@ W_RODAT *(.gnu.linkonce.r*) + PROVIDE(@SYMBOL_PREFIX at __ctbp = .); + *(.call_table_data) + *(.call_table_text) +- +- . = ALIGN(0x20) ; +- @SYMBOL_PREFIX at _etext = . ; + } > flatmem :text + ++ /* .ARM.exidx name sections containing index entries for section unwinding */ ++ /* .ARM.exidx is sorted, so has to go in its own output section. */ ++ @SYMBOL_PREFIX at __exidx_start = .; ++ .ARM.exidx : ++ { ++ *(.ARM.exidx* .gnu.linkonce.armexidx.*) ++ } > flatmem ++ @SYMBOL_PREFIX at __exidx_end = .; ++ ++ . = ALIGN(0x20) ; ++ @SYMBOL_PREFIX at _etext = . ; ++ + .data : { + . = ALIGN(0x4) ; + @SYMBOL_PREFIX at _sdata = . ; +-- +2.6.4 +
package/elf2flt/elf2flt.mk +2 -3
@@ -4,9 +4,8 @@ # ################################################################################ -ELF2FLT_VERSION = f859213b18a67fcfc09961267e0a1122d35186f4 -ELF2FLT_SITE = http://cgit.openadk.org/cgi/cgit/elf2flt.git -ELF2FLT_SITE_METHOD = git +ELF2FLT_VERSION = 177ec2701aba30270ec1260746b8db5442c77ef4 +ELF2FLT_SITE = $(call github,uclinux-dev,elf2flt,$(ELF2FLT_VERSION)) ELF2FLT_LICENSE = GPLv2+ ELF2FLT_LICENSE_FILES = LICENSE.TXT
Signature · 1 line
2.6.4
PATCH 12/16 elf2flt: use new upstream site and add ARM patch
Quoted 3 lines · Thomas Petazzoni
The uClinux developers now have a Github with elf2flt code, with an upstream that is again active. Let's switch to this upstream, to which Waldemar is contributing as well.
While at it, you could have added a hash file.
Quoted 3 lines
We also add an ARM patch from Waldemar, which was on his elf2flt repository and he submitted upstream.
That probably should have been a separate patch.
Regards,
Arnout
Quoted 154 lines
Signed-off-by Thomas Petazzoni <[email protected]>--- .../0001-allow-to-build-arm-flat-binaries.patch | 123 +++++++++++++++++++++ package/elf2flt/elf2flt.mk | 5 +- 2 files changed, 125 insertions(+), 3 deletions(-)create mode 100644
package/elf2flt/0001-allow-to-build-arm-flat-binaries.patchpackage/elf2flt/0001-allow-to-build-arm-flat-binaries.patch new file +123
-0@@ -0,0 +1,123 @@ +From 56b082412c6f49d21f5e54831a40d1e7c45b3ee4 Mon Sep 17 00:00:00 2001 +From: Waldemar Brodkorb <[email protected]> +Date: Sat, 12 Mar 2016 22:09:30 +0100 +Subject: [PATCH] allow to build arm flat binaries + +Add patchset from ptxdist which is required to produce working +ARM flat binaries. Tested with busybox on Kinetis K70. + +Signed-off-by: Waldemar Brodkorb <[email protected]> +Signed-off-by: Thomas Petazzoni <[email protected]> +--- + elf2flt.c | 19 ++++++++++++------- + elf2flt.ld.in | 17 ++++++++++++++--- + 2 files changed, 26 insertions(+), 10 deletions(-) + +diff --git a/elf2flt.c b/elf2flt.c +index fcd797c..c6978e1 100644 +--- a/elf2flt.c ++++ b/elf2flt.c +@@ -56,6 +56,8 @@ const char *elf2flt_progname; + + #if defined(TARGET_h8300) + #include <elf/h8.h> /* TARGET_* ELF support for the BFD library */ ++#elif defined(TARGET_arm) ++#include <elf/arm.h> + #elif defined(__CYGWIN__) || defined(__MINGW32__) || defined(TARGET_nios) || defined(TARGET_nios2) + #include "cygwin-elf.h" /* Cygwin uses a local copy */ + #elif defined(TARGET_xtensa) +@@ -646,16 +648,23 @@ dump_symbols(symbols, number_of_symbols); + default: + goto good_32bit_resolved_reloc; + #elif defined(TARGET_arm) ++ case R_ARM_TARGET1: ++ case R_ARM_TARGET2: + case R_ARM_ABS32: + relocation_needed = 1; + break; + case R_ARM_REL32: ++ case R_ARM_JUMP24: ++ case R_ARM_CALL: + case R_ARM_THM_PC11: + case R_ARM_THM_PC22: ++ case R_ARM_THM_JUMP24: + case R_ARM_PC24: + case R_ARM_PLT32: + case R_ARM_GOTPC: + case R_ARM_GOT32: ++ case R_ARM_PREL31: ++ case R_ARM_NONE: + relocation_needed = 0; + break; + default: +@@ -871,9 +880,7 @@ dump_symbols(symbols, number_of_symbols); + relocation_needed = 1; + if (verbose) + fprintf(stderr, +- "%s vma=0x%x, " +- "value=0x%"BFD_VMA_FMT"x, " +- "address=0x%"BFD_VMA_FMT"x " ++ "%s vma=0x%x, value=0x%x, address=0x%x " + "sym_addr=0x%x rs=0x%x, opcode=0x%x\n", + "ABS32", + sym_vma, (*(q->sym_ptr_ptr))->value, +@@ -890,9 +897,7 @@ dump_symbols(symbols, number_of_symbols); + case R_ARM_PLT32: + if (verbose) + fprintf(stderr, +- "%s vma=0x%x, " +- "value=0x%"BFD_VMA_FMT"x, " +- "address=0x%"BFD_VMA_FMT"x " ++ "%s vma=0x%x, value=0x%x, address=0x%x " + "sym_addr=0x%x rs=0x%x, opcode=0x%x\n", + "PLT32", + sym_vma, (*(q->sym_ptr_ptr))->value, +@@ -1446,7 +1451,7 @@ DIS29_RELOCATION: + } + } + +- sprintf(&addstr[0], "+0x%lx", sym_addr - (*(q->sym_ptr_ptr))->value - ++ sprintf(&addstr[0], "+0x%x", sym_addr - (*(q->sym_ptr_ptr))->value - + bfd_section_vma(abs_bfd, sym_section)); + + +diff --git a/elf2flt.ld.in b/elf2flt.ld.in +index bfda0ef..ec1fe6f 100644 +--- a/elf2flt.ld.in ++++ b/elf2flt.ld.in +@@ -35,6 +35,8 @@ W_RODAT *(.rodata1) + W_RODAT *(.rodata.*) + W_RODAT *(.gnu.linkonce.r*) + ++ /* .ARM.extab name sections containing exception unwinding information */ ++ *(.ARM.extab* .gnu.linkonce.armextab.*) + /* This is special code area at the end of the normal + text section. It contains a small lookup table at + the start followed by the code pointed to by entries +@@ -43,11 +45,20 @@ W_RODAT *(.gnu.linkonce.r*) + PROVIDE(@SYMBOL_PREFIX at __ctbp = .); + *(.call_table_data) + *(.call_table_text) +- +- . = ALIGN(0x20) ; +- @SYMBOL_PREFIX at _etext = . ; + } > flatmem :text + ++ /* .ARM.exidx name sections containing index entries for section unwinding */ ++ /* .ARM.exidx is sorted, so has to go in its own output section. */ ++ @SYMBOL_PREFIX at __exidx_start = .; ++ .ARM.exidx : ++ { ++ *(.ARM.exidx* .gnu.linkonce.armexidx.*) ++ } > flatmem ++ @SYMBOL_PREFIX at __exidx_end = .; ++ ++ . = ALIGN(0x20) ; ++ @SYMBOL_PREFIX at _etext = . ; ++ + .data : { + . = ALIGN(0x4) ; + @SYMBOL_PREFIX at _sdata = . ; +-- +2.6.4 +package/elf2flt/elf2flt.mk +2
-3@@ -4,9 +4,8 @@ # ################################################################################ -ELF2FLT_VERSION = f859213b18a67fcfc09961267e0a1122d35186f4 -ELF2FLT_SITE = http://cgit.openadk.org/cgi/cgit/elf2flt.git -ELF2FLT_SITE_METHOD = git +ELF2FLT_VERSION = 177ec2701aba30270ec1260746b8db5442c77ef4 +ELF2FLT_SITE = $(call github,uclinux-dev,elf2flt,$(ELF2FLT_VERSION)) ELF2FLT_LICENSE = GPLv2+ ELF2FLT_LICENSE_FILES = LICENSE.TXT
Signature · 6 lines
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: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
PATCH 12/16 elf2flt: use new upstream site and add ARM patch
Dear Arnout Vandecappelle,
Quoted 6 lines · Arnout Vandecappelle
Quoted 3 lines · Thomas Petazzoni
The uClinux developers now have a Github with elf2flt code, with an upstream that is again active. Let's switch to this upstream, to which Waldemar is contributing as well.
While at it, you could have added a hash file.
Will do.
Quoted 4 lines
Quoted 2 lines
We also add an ARM patch from Waldemar, which was on his elf2flt repository and he submitted upstream.
That probably should have been a separate patch.
No: the Waldemar Git repository did contain the ARM noMMU support. So when switching to the more "official" upstream (which doesn't yet have ARM noMMU support), we need to include the patch adding ARM noMMU support to keep functionality the same.
I guess I should have made that explicit in the commit log, to avoid confusion.
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 12/16 elf2flt: use new upstream site and add ARM patch
Quoted 13 lines · Thomas Petazzoni
Quoted 6 lines · Arnout Vandecappelle
Quoted 3 lines · Thomas Petazzoni
The uClinux developers now have a Github with elf2flt code, with an upstream that is again active. Let's switch to this upstream, to which Waldemar is contributing as well.
While at it, you could have added a hash file.
Will do.
Quoted 3 lines
Quoted 2 lines
We also add an ARM patch from Waldemar, which was on his elf2flt repository and he submitted upstream.
Quoted 6 lines
Quoted 1 line
That probably should have been a separate patch.
No: the Waldemar Git repository did contain the ARM noMMU support. So when switching to the more "official" upstream (which doesn't yet have ARM noMMU support), we need to include the patch adding ARM noMMU support to keep functionality the same.
elf2flt has had nommu arm support pretty much from the beginning (at
least since 2002). i don't know what this patch is for, but it hasn't
been sent upstream afaik, so i can't really comment on it.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20160317/38a407de/attachment.asc>
PATCH 12/16 elf2flt: use new upstream site and add ARM patch
Hi Mike,
Mike Frysinger wrote,
Quoted 16 lines · Thomas Petazzoni
Quoted 15 lines · Arnout Vandecappelle
Quoted 6 lines · Thomas Petazzoni
Quoted 3 lines
The uClinux developers now have a Github with elf2flt code, with an upstream that is again active. Let's switch to this upstream, to which Waldemar is contributing as well.
While at it, you could have added a hash file.
Will do.
Quoted 4 lines
Quoted 2 lines
We also add an ARM patch from Waldemar, which was on his elf2flt repository and he submitted upstream.
That probably should have been a separate patch.
Quoted 8 lines
Quoted 4 lines
No: the Waldemar Git repository did contain the ARM noMMU support. So when switching to the more "official" upstream (which doesn't yet have ARM noMMU support), we need to include the patch adding ARM noMMU support to keep functionality the same.
elf2flt has had nommu arm support pretty much from the beginning (at least since 2002). i don't know what this patch is for, but it hasn't been sent upstream afaik, so i can't really comment on it.
Yes, elf2flt has ARM noMMU support I think it is just not complete enough to work with recent gcc and binutils. I can't compile a working busybox binary without this patch:
http://mailman.uclinux.org/pipermail/uclinux-dev/2016-March/052707.html
Isn't this the mailing list to sent patches for elf2flt?
best regards
Waldemar
PATCH 12/16 elf2flt: use new upstream site and add ARM patch
In reply to Mike FrysingerHello,
Quoted 8 lines · Mike Frysinger
Quoted 4 lines
No: the Waldemar Git repository did contain the ARM noMMU support. So when switching to the more "official" upstream (which doesn't yet have ARM noMMU support), we need to include the patch adding ARM noMMU support to keep functionality the same.
elf2flt has had nommu arm support pretty much from the beginning (at least since 2002). i don't know what this patch is for, but it hasn't been sent upstream afaik, so i can't really comment on it.
Well, it was sent to the uclinux-dev mailing list just a few days ago:
http://mailman.uclinux.org/pipermail/uclinux-dev/2016-March/052707.html
I don't know if you call the uclinux-dev mailing list "upstream", but it doesn't sound too bad for a project hosted at github.com/uclinux-dev :-)
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 12/16 elf2flt: use new upstream site and add ARM patch
Quoted 10 lines · Thomas Petazzoni
Quoted 8 lines · Mike Frysinger
Quoted 4 lines
No: the Waldemar Git repository did contain the ARM noMMU support. So when switching to the more "official" upstream (which doesn't yet have ARM noMMU support), we need to include the patch adding ARM noMMU support to keep functionality the same.
elf2flt has had nommu arm support pretty much from the beginning (at least since 2002). i don't know what this patch is for, but it hasn't been sent upstream afaik, so i can't really comment on it.
Quoted 7 lines
Well, it was sent to the uclinux-dev mailing list just a few days ago:
http://mailman.uclinux.org/pipermail/uclinux-dev/2016-March/052707.html
I don't know if you call the uclinux-dev mailing list "upstream", but it doesn't sound too bad for a project hosted at github.com/uclinux-dev :-)
that is the upstream list, i'm just not on it ;). i expect the other
uclinux devs to look at it. i just watch the github list now myself.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20160317/a41bf85a/attachment.asc>
PATCH 12/16 elf2flt: use new upstream site and add ARM patch
In reply to Thomas PetazzoniHi Thomas,
Thomas Petazzoni wrote,
Quoted 6 lines
The uClinux developers now have a Github with elf2flt code, with an upstream that is again active. Let's switch to this upstream, to which Waldemar is contributing as well.
We also add an ARM patch from Waldemar, which was on his elf2flt repository and he submitted upstream.
It is not exactly the stuff I added to my repo, but it produces working binaries ;)
Please use the updated patch from here:
http://mailman.uclinux.org/pipermail/uclinux-dev/2016-March/052707.html
This only left on build problem with -Werror.
Thanks
Waldemar
PATCH 13/16 elf2flt: disable Werror to avoid build issues
In reply to Thomas PetazzoniSome of the debugging printf use incorrect formats, which cause some warnings. Due to the use of -Werror by default, the build breaks unnecessarily. Therefore, disable -Werror when building elf2flt.
--- package/elf2flt/elf2flt.mk | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
package/elf2flt/elf2flt.mk +2 -1
@@ -18,7 +18,8 @@ HOST_ELF2FLT_CONF_OPTS = \ --with-binutils-include-dir=$(HOST_BINUTILS_DIR)/include/ \ --with-libbfd=$(HOST_BINUTILS_DIR)/bfd/libbfd.a \ --with-libiberty=$(HOST_BINUTILS_DIR)/libiberty/libiberty.a \ - --target=$(GNU_TARGET_NAME) + --target=$(GNU_TARGET_NAME) \ + --disable-werror HOST_ELF2FLT_LIBS = -lz
Signature · 1 line
2.6.4
PATCH 13/16 elf2flt: disable Werror to avoid build issues
Quoted 3 lines · Thomas Petazzoni
Some of the debugging printf use incorrect formats, which cause some warnings. Due to the use of -Werror by default, the build breaks unnecessarily. Therefore, disable -Werror when building elf2flt.
Wouldn't it be better to patch elf2flt to fix the errors?
Still:
Regards,
Arnout
Quoted 21 lines
Signed-off-by Thomas Petazzoni <[email protected]>--- package/elf2flt/elf2flt.mk | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)package/elf2flt/elf2flt.mk +2
-1@@ -18,7 +18,8 @@ HOST_ELF2FLT_CONF_OPTS = \ --with-binutils-include-dir=$(HOST_BINUTILS_DIR)/include/ \ --with-libbfd=$(HOST_BINUTILS_DIR)/bfd/libbfd.a \ --with-libiberty=$(HOST_BINUTILS_DIR)/libiberty/libiberty.a \ - --target=$(GNU_TARGET_NAME) + --target=$(GNU_TARGET_NAME) \ + --disable-werror HOST_ELF2FLT_LIBS = -lz
Signature · 6 lines
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: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
PATCH 13/16 elf2flt: disable Werror to avoid build issues
Dear Arnout Vandecappelle,
Quoted 6 lines · Arnout Vandecappelle
Quoted 3 lines · Thomas Petazzoni
Some of the debugging printf use incorrect formats, which cause some warnings. Due to the use of -Werror by default, the build breaks unnecessarily. Therefore, disable -Werror when building elf2flt.
Wouldn't it be better to patch elf2flt to fix the errors?
Yes, indeed it is better, but one step at a time :)
Also, we generally anyway build things with -Werror disabled.
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 13/16 elf2flt: disable Werror to avoid build issues
In reply to Thomas PetazzoniQuoted 3 lines · Thomas Petazzoni
Some of the debugging printf use incorrect formats, which cause some warnings. Due to the use of -Werror by default, the build breaks unnecessarily. Therefore, disable -Werror when building elf2flt.
you should send a patch and/or open an issue.
the build bot is clean for all the targets w/Werror:
https://travis-ci.org/uclinux-dev/elf2flt
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20160316/b5ef64a1/attachment.asc>
PATCH 13/16 elf2flt: disable Werror to avoid build issues
Mike,
Quoted 8 lines · Mike Frysinger
Quoted 3 lines · Thomas Petazzoni
Some of the debugging printf use incorrect formats, which cause some warnings. Due to the use of -Werror by default, the build breaks unnecessarily. Therefore, disable -Werror when building elf2flt.
you should send a patch and/or open an issue. the build bot is clean for all the targets w/Werror:
https://travis-ci.org/uclinux-dev/elf2flt
Sure, I'll reproduce and report. It's just some stupid printf specifier issue with some of the funky bfd types.
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 13/16 elf2flt: disable Werror to avoid build issues
Quoted 6 lines · Thomas Petazzoni
Quoted 5 lines · Mike Frysinger
Quoted 3 lines · Thomas Petazzoni
Some of the debugging printf use incorrect formats, which cause some warnings. Due to the use of -Werror by default, the build breaks unnecessarily. Therefore, disable -Werror when building elf2flt.
Quoted 6 lines
Quoted 3 lines
you should send a patch and/or open an issue. the build bot is clean for all the targets w/Werror:
https://travis-ci.org/uclinux-dev/elf2fltSure, I'll reproduce and report. It's just some stupid printf specifier issue with some of the funky bfd types.
depending on the ABI, printf mismatches can be pretty bad. consider that most 32bit arches require splitting 64bit values across two "slots" and that a 64bit printf length will consume 2 "slots". so a mismatch there (either passing too many or consuming too many) with a pointer following them can lead to crashes :).
the buildbots are only doing one type of build atm (64bit host), so it
might be missing coverage w/a 32bit userland. we might be able to add
that to the travis matrix.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20160317/14b011e6/attachment.asc>
PATCH 14/16 afboot-stm32: use the Buildroot toolchain
In reply to Thomas PetazzoniBy default, the afboot-stm32 Makefile uses "CROSS_COMPILE = arm-none-eabi-". Since I had such a toolchain installed on my system when testing afboot-stm32, I didn't realize it wasn't using the Buildroot toolchain.
However, using the Buildroot toolchain doesn't immediately works for FLAT toolchains, as gcc automatically wants to create a FLAT binary. So we need to adjust the afboot-stm32 Makefile to use directly 'ld' and not 'gcc' when linking.
--- .../0001-Use-ld-instead-of-gcc-for-linking.patch | 61 ++++++++++++++++++++++ boot/afboot-stm32/afboot-stm32.mk | 2 +- 2 files changed, 62 insertions(+), 1 deletion(-) create mode 100644 boot/afboot-stm32/0001-Use-ld-instead-of-gcc-for-linking.patch
boot/afboot-stm32/0001-Use-ld-instead-of-gcc-for-linking.patch new file +61 -0
@@ -0,0 +1,61 @@ +From 0d581abe6620ac69adec321b94390e009802f36a Mon Sep 17 00:00:00 2001 +From: Thomas Petazzoni <[email protected]> +Date: Sun, 13 Mar 2016 14:32:33 +0100 +Subject: [PATCH] Use ld instead of gcc for linking + +Signed-off-by: Thomas Petazzoni <[email protected]> +--- + Makefile | 11 ++++++----- + 1 file changed, 6 insertions(+), 5 deletions(-) + +diff --git a/Makefile b/Makefile +index ce40314..271bb4f 100644 +--- a/Makefile ++++ b/Makefile +@@ -1,6 +1,7 @@ + CROSS_COMPILE ?= arm-none-eabi- + + CC = $(CROSS_COMPILE)gcc ++LD = $(CROSS_COMPILE)ld + OBJCOPY = $(CROSS_COMPILE)objcopy + OBJDUMP = $(CROSS_COMPILE)objdump + SIZE = $(CROSS_COMPILE)size +@@ -10,7 +11,7 @@ OPENOCD = openocd + CFLAGS := -mthumb -mcpu=cortex-m4 + CFLAGS += -ffunction-sections -fdata-sections + CFLAGS += -Os -std=gnu99 -Wall +-LDFLAGS := -nostartfiles -Wl,--gc-sections ++LINKERFLAGS := -nostartfiles --gc-sections + + obj-y += gpio.o mpu.o + obj-f4 += $(obj-y) usart-f4.o +@@ -22,22 +23,22 @@ all: stm32f429i-disco stm32429i-eval stm32f469i-disco stm32746g-eval + $(CC) -c $(CFLAGS) $< -o $@ + + stm32f429i-disco: stm32f429i-disco.o $(obj-f4) +- $(CC) -T stm32f429.lds $(LDFLAGS) -o stm32f429i-disco.elf stm32f429i-disco.o $(obj-f4) ++ $(LD) -T stm32f429.lds $(LINKERFLAGS) -o stm32f429i-disco.elf stm32f429i-disco.o $(obj-f4) + $(OBJCOPY) -Obinary stm32f429i-disco.elf stm32f429i-disco.bin + $(SIZE) stm32f429i-disco.elf + + stm32429i-eval: stm32429i-eval.o $(obj-f4) +- $(CC) -T stm32f429.lds $(LDFLAGS) -o stm32429i-eval.elf stm32429i-eval.o $(obj-f4) ++ $(LD) -T stm32f429.lds $(LINKERFLAGS) -o stm32429i-eval.elf stm32429i-eval.o $(obj-f4) + $(OBJCOPY) -Obinary stm32429i-eval.elf stm32429i-eval.bin + $(SIZE) stm32429i-eval.elf + + stm32f469i-disco: stm32f469i-disco.o $(obj-f4) +- $(CC) -T stm32f429.lds $(LDFLAGS) -o stm32f469i-disco.elf stm32f469i-disco.o $(obj-f4) ++ $(LD) -T stm32f429.lds $(LINKERFLAGS) -o stm32f469i-disco.elf stm32f469i-disco.o $(obj-f4) + $(OBJCOPY) -Obinary stm32f469i-disco.elf stm32f469i-disco.bin + $(SIZE) stm32f469i-disco.elf + + stm32746g-eval: stm32746g-eval.o $(obj-f7) +- $(CC) -T stm32f429.lds $(LDFLAGS) -o stm32746g-eval.elf stm32746g-eval.o $(obj-f7) ++ $(LD) -T stm32f429.lds $(LINKERFLAGS) -o stm32746g-eval.elf stm32746g-eval.o $(obj-f7) + $(OBJCOPY) -Obinary stm32746g-eval.elf stm32746g-eval.bin + $(SIZE) stm32746g-eval.elf + +-- +2.6.4 +
boot/afboot-stm32/afboot-stm32.mk +1 -1
@@ -8,7 +8,7 @@ AFBOOT_STM32_VERSION = v0.1 AFBOOT_STM32_SITE = $(call github,mcoquelin-stm32,afboot-stm32,$(AFBOOT_STM32_VERSION)) define AFBOOT_STM32_BUILD_CMDS - $(TARGET_MAKE_ENV) $(MAKE) -C $(@D) all + $(TARGET_MAKE_ENV) $(MAKE) -C $(@D) CROSS_COMPILE=$(TARGET_CROSS) all endef define AFBOOT_STM32_INSTALL_TARGET_CMDS
Signature · 1 line
2.6.4
PATCH 15/16 configs/stm32f429_disco: new configuration for STM32F429 Discovery board
In reply to Thomas PetazzoniFrom: Lee Jones <[email protected]>
This commit adds a defconfig for the STM32F429 platform, which is based on a Cortex-M4 core from ST Microelectronics. It is therefore the first noMMU ARM platform supported in Buildroot.
This commit includes some files that will be common to several STM32 platforms (hence in board/stmicroelectronics) and some files that are specific to the STM32F429 (hence in board/stmicroelectronics/stm32f429-disco). More specifically, this commit adds:
- A minimal Busybox configuration, which is small enough to boot without causing OOM on such small noMMU platforms. The resulting Busybox, statically linked with uClibc-ng, weights around 220 KB. For now, this file is located in board/stmicroelectronics/, but we might consider moving it to package/busybox/ in the future if needed.
- A post-build script that removes the mounting of /dev/pts (not enabled in the kernel and not very useful for a system that has no network and no X), and removes the network related init script and configuration files (no network support).
- A flash.sh script, to perform the right OpenOCD invocations to reflash the board.
- One small kernel patch to adjust the kernel command line in the Device Tree, since it's the only way to do so.
- The usual readme.txt file.
[Thomas:
- squashed multiple patches from Lee Jones together
- added the minimal Busybox configuration
- added the post-build script
- improved the flashing script to not hardcode the location of the output directory
- add the small kernel patch
- improve the readme.txt file
- test on HW the resulting image, after using the internal toolchain.]
--- board/stmicroelectronics/busybox-minimal.config | 1057 ++++++++++++++++++++ board/stmicroelectronics/stm32-post-build.sh | 8 + board/stmicroelectronics/stm32f429-disco/flash.sh | 20 + ...49-disco-don-t-force-init-in-chosen-boota.patch | 32 + .../stmicroelectronics/stm32f429-disco/readme.txt | 30 + configs/stm32f429_disco_defconfig | 18 + 6 files changed, 1165 insertions(+) create mode 100644 board/stmicroelectronics/busybox-minimal.config create mode 100755 board/stmicroelectronics/stm32-post-build.sh create mode 100755 board/stmicroelectronics/stm32f429-disco/flash.sh create mode 100644 board/stmicroelectronics/stm32f429-disco/patches/linux/0001-ARM-stm32f249-disco-don-t-force-init-in-chosen-boota.patch create mode 100644 board/stmicroelectronics/stm32f429-disco/readme.txt create mode 100644 configs/stm32f429_disco_defconfig
board/stmicroelectronics/busybox-minimal.config new file +1057 -0
@@ -0,0 +1,1057 @@ +# +# Automatically generated make config: don't edit +# Busybox version: 1.24.1 +# Sat Mar 12 15:36:27 2016 +# +CONFIG_HAVE_DOT_CONFIG=y + +# +# Busybox Settings +# + +# +# General Configuration +# +# CONFIG_DESKTOP is not set +# CONFIG_EXTRA_COMPAT is not set +CONFIG_INCLUDE_SUSv2=y +# CONFIG_USE_PORTABLE_CODE is not set +CONFIG_PLATFORM_LINUX=y +CONFIG_FEATURE_BUFFERS_USE_MALLOC=y +# CONFIG_FEATURE_BUFFERS_GO_ON_STACK is not set +# CONFIG_FEATURE_BUFFERS_GO_IN_BSS is not set +# CONFIG_SHOW_USAGE is not set +# CONFIG_FEATURE_VERBOSE_USAGE is not set +# CONFIG_FEATURE_COMPRESS_USAGE is not set +CONFIG_FEATURE_INSTALLER=y +# CONFIG_INSTALL_NO_USR is not set +# CONFIG_LOCALE_SUPPORT is not set +# CONFIG_UNICODE_SUPPORT is not set +# CONFIG_UNICODE_USING_LOCALE is not set +# CONFIG_FEATURE_CHECK_UNICODE_IN_ENV is not set +CONFIG_SUBST_WCHAR=0 +CONFIG_LAST_SUPPORTED_WCHAR=0 +# CONFIG_UNICODE_COMBINING_WCHARS is not set +# CONFIG_UNICODE_WIDE_WCHARS is not set +# CONFIG_UNICODE_BIDI_SUPPORT is not set +# CONFIG_UNICODE_NEUTRAL_TABLE is not set +# CONFIG_UNICODE_PRESERVE_BROKEN is not set +# CONFIG_PAM is not set +CONFIG_FEATURE_USE_SENDFILE=y +CONFIG_LONG_OPTS=y +CONFIG_FEATURE_DEVPTS=y +CONFIG_FEATURE_CLEAN_UP=y +CONFIG_FEATURE_UTMP=y +CONFIG_FEATURE_WTMP=y +# CONFIG_FEATURE_PIDFILE is not set +CONFIG_PID_FILE_PATH="" +CONFIG_FEATURE_SUID=y +# CONFIG_FEATURE_SUID_CONFIG is not set +# CONFIG_FEATURE_SUID_CONFIG_QUIET is not set +# CONFIG_SELINUX is not set +# CONFIG_FEATURE_PREFER_APPLETS is not set +CONFIG_BUSYBOX_EXEC_PATH="/proc/self/exe" +CONFIG_FEATURE_SYSLOG=y +# CONFIG_FEATURE_HAVE_RPC is not set + +# +# Build Options +# +CONFIG_STATIC=y +# CONFIG_PIE is not set +CONFIG_NOMMU=y +# CONFIG_BUILD_LIBBUSYBOX is not set +# CONFIG_FEATURE_INDIVIDUAL is not set +# CONFIG_FEATURE_SHARED_BUSYBOX is not set +CONFIG_LFS=y +CONFIG_CROSS_COMPILER_PREFIX="" +CONFIG_SYSROOT="" +CONFIG_EXTRA_CFLAGS="" +CONFIG_EXTRA_LDFLAGS="" +CONFIG_EXTRA_LDLIBS="" + +# +# Debugging Options +# +# CONFIG_DEBUG is not set +# CONFIG_DEBUG_PESSIMIZE is not set +# CONFIG_UNIT_TEST is not set +# CONFIG_WERROR is not set +CONFIG_NO_DEBUG_LIB=y +# CONFIG_DMALLOC is not set +# CONFIG_EFENCE is not set + +# +# Installation Options ("make install" behavior) +# +CONFIG_INSTALL_APPLET_SYMLINKS=y +# CONFIG_INSTALL_APPLET_HARDLINKS is not set +# CONFIG_INSTALL_APPLET_SCRIPT_WRAPPERS is not set +# CONFIG_INSTALL_APPLET_DONT is not set +# CONFIG_INSTALL_SH_APPLET_SYMLINK is not set +# CONFIG_INSTALL_SH_APPLET_HARDLINK is not set +# CONFIG_INSTALL_SH_APPLET_SCRIPT_WRAPPER is not set +CONFIG_PREFIX="./_install" + +# +# Busybox Library Tuning +# +# CONFIG_FEATURE_SYSTEMD is not set +CONFIG_FEATURE_RTMINMAX=y +CONFIG_PASSWORD_MINLEN=6 +CONFIG_MD5_SMALL=1 +CONFIG_SHA3_SMALL=1 +# CONFIG_FEATURE_FAST_TOP is not set +# CONFIG_FEATURE_ETC_NETWORKS is not set +CONFIG_FEATURE_USE_TERMIOS=y +CONFIG_FEATURE_EDITING=y +CONFIG_FEATURE_EDITING_MAX_LEN=1024 +CONFIG_FEATURE_EDITING_VI=y +CONFIG_FEATURE_EDITING_HISTORY=999 +CONFIG_FEATURE_EDITING_SAVEHISTORY=y +# CONFIG_FEATURE_EDITING_SAVE_ON_EXIT is not set +CONFIG_FEATURE_REVERSE_SEARCH=y +CONFIG_FEATURE_TAB_COMPLETION=y +# CONFIG_FEATURE_USERNAME_COMPLETION is not set +CONFIG_FEATURE_EDITING_FANCY_PROMPT=y +# CONFIG_FEATURE_EDITING_ASK_TERMINAL is not set +CONFIG_FEATURE_NON_POSIX_CP=y +# CONFIG_FEATURE_VERBOSE_CP_MESSAGE is not set +CONFIG_FEATURE_COPYBUF_KB=4 +CONFIG_FEATURE_SKIP_ROOTFS=y +CONFIG_MONOTONIC_SYSCALL=y +CONFIG_IOCTL_HEX2STR_ERROR=y +CONFIG_FEATURE_HWIB=y + +# +# Applets +# + +# +# Archival Utilities +# +# CONFIG_FEATURE_SEAMLESS_XZ is not set +# CONFIG_FEATURE_SEAMLESS_LZMA is not set +# CONFIG_FEATURE_SEAMLESS_BZ2 is not set +# CONFIG_FEATURE_SEAMLESS_GZ is not set +# CONFIG_FEATURE_SEAMLESS_Z is not set +# CONFIG_AR is not set +# CONFIG_FEATURE_AR_LONG_FILENAMES is not set +# CONFIG_FEATURE_AR_CREATE is not set +# CONFIG_UNCOMPRESS is not set +# CONFIG_GUNZIP is not set +# CONFIG_BUNZIP2 is not set +# CONFIG_UNLZMA is not set +# CONFIG_FEATURE_LZMA_FAST is not set +# CONFIG_LZMA is not set +# CONFIG_UNXZ is not set +# CONFIG_XZ is not set +# CONFIG_BZIP2 is not set +# CONFIG_CPIO is not set +# CONFIG_FEATURE_CPIO_O is not set +# CONFIG_FEATURE_CPIO_P is not set +# CONFIG_DPKG is not set +# CONFIG_DPKG_DEB is not set +# CONFIG_FEATURE_DPKG_DEB_EXTRACT_ONLY is not set +# CONFIG_GZIP is not set +# CONFIG_FEATURE_GZIP_LONG_OPTIONS is not set +CONFIG_GZIP_FAST=0 +# CONFIG_FEATURE_GZIP_LEVELS is not set +# CONFIG_LZOP is not set +# CONFIG_LZOP_COMPR_HIGH is not set +# CONFIG_RPM is not set +# CONFIG_RPM2CPIO is not set +# CONFIG_TAR is not set +# CONFIG_FEATURE_TAR_CREATE is not set +# CONFIG_FEATURE_TAR_AUTODETECT is not set +# CONFIG_FEATURE_TAR_FROM is not set +# CONFIG_FEATURE_TAR_OLDGNU_COMPATIBILITY is not set +# CONFIG_FEATURE_TAR_OLDSUN_COMPATIBILITY is not set +# CONFIG_FEATURE_TAR_GNU_EXTENSIONS is not set +# CONFIG_FEATURE_TAR_LONG_OPTIONS is not set +# CONFIG_FEATURE_TAR_TO_COMMAND is not set +# CONFIG_FEATURE_TAR_UNAME_GNAME is not set +# CONFIG_FEATURE_TAR_NOPRESERVE_TIME is not set +# CONFIG_FEATURE_TAR_SELINUX is not set +# CONFIG_UNZIP is not set + +# +# Coreutils +# +CONFIG_BASENAME=y +CONFIG_CAT=y +CONFIG_DATE=y +CONFIG_FEATURE_DATE_ISOFMT=y +# CONFIG_FEATURE_DATE_NANO is not set +CONFIG_FEATURE_DATE_COMPAT=y +CONFIG_DD=y +CONFIG_FEATURE_DD_SIGNAL_HANDLING=y +# CONFIG_FEATURE_DD_THIRD_STATUS_LINE is not set +CONFIG_FEATURE_DD_IBS_OBS=y +CONFIG_FEATURE_DD_STATUS=y +CONFIG_HOSTID=y +CONFIG_ID=y +# CONFIG_GROUPS is not set +# CONFIG_SHUF is not set +CONFIG_SYNC=y +# CONFIG_FEATURE_SYNC_FANCY is not set +CONFIG_TEST=y +CONFIG_FEATURE_TEST_64=y +CONFIG_TOUCH=y +# CONFIG_FEATURE_TOUCH_NODEREF is not set +CONFIG_FEATURE_TOUCH_SUSV3=y +CONFIG_TR=y +CONFIG_FEATURE_TR_CLASSES=y +CONFIG_FEATURE_TR_EQUIV=y +CONFIG_TRUNCATE=y +CONFIG_UNLINK=y +# CONFIG_BASE64 is not set +CONFIG_WHO=y +# CONFIG_USERS is not set +# CONFIG_CAL is not set +CONFIG_CATV=y +CONFIG_CHGRP=y +CONFIG_CHMOD=y +CONFIG_CHOWN=y +# CONFIG_FEATURE_CHOWN_LONG_OPTIONS is not set +CONFIG_CHROOT=y +CONFIG_CKSUM=y +# CONFIG_COMM is not set +CONFIG_CP=y +# CONFIG_FEATURE_CP_LONG_OPTIONS is not set +CONFIG_CUT=y +CONFIG_DF=y +# CONFIG_FEATURE_DF_FANCY is not set +CONFIG_DIRNAME=y +CONFIG_DOS2UNIX=y +CONFIG_UNIX2DOS=y +CONFIG_DU=y +CONFIG_FEATURE_DU_DEFAULT_BLOCKSIZE_1K=y +CONFIG_ECHO=y +CONFIG_FEATURE_FANCY_ECHO=y +CONFIG_ENV=y +# CONFIG_FEATURE_ENV_LONG_OPTIONS is not set +# CONFIG_EXPAND is not set +# CONFIG_FEATURE_EXPAND_LONG_OPTIONS is not set +CONFIG_EXPR=y +CONFIG_EXPR_MATH_SUPPORT_64=y +CONFIG_FALSE=y +CONFIG_FOLD=y +# CONFIG_FSYNC is not set +CONFIG_HEAD=y +CONFIG_FEATURE_FANCY_HEAD=y +CONFIG_INSTALL=y +CONFIG_FEATURE_INSTALL_LONG_OPTIONS=y +CONFIG_LN=y +CONFIG_LOGNAME=y +CONFIG_LS=y +CONFIG_FEATURE_LS_FILETYPES=y +CONFIG_FEATURE_LS_FOLLOWLINKS=y +CONFIG_FEATURE_LS_RECURSIVE=y +CONFIG_FEATURE_LS_SORTFILES=y +CONFIG_FEATURE_LS_TIMESTAMPS=y +CONFIG_FEATURE_LS_USERNAME=y +CONFIG_FEATURE_LS_COLOR=y +CONFIG_FEATURE_LS_COLOR_IS_DEFAULT=y +CONFIG_MD5SUM=y +CONFIG_MKDIR=y +CONFIG_FEATURE_MKDIR_LONG_OPTIONS=y +CONFIG_MKFIFO=y +CONFIG_MKNOD=y +CONFIG_MV=y +CONFIG_FEATURE_MV_LONG_OPTIONS=y +CONFIG_NICE=y +CONFIG_NOHUP=y +CONFIG_OD=y +CONFIG_PRINTENV=y +CONFIG_PRINTF=y +CONFIG_PWD=y +CONFIG_READLINK=y +CONFIG_FEATURE_READLINK_FOLLOW=y +CONFIG_REALPATH=y +CONFIG_RM=y +CONFIG_RMDIR=y +# CONFIG_FEATURE_RMDIR_LONG_OPTIONS is not set +CONFIG_SEQ=y +CONFIG_SHA1SUM=y +CONFIG_SHA256SUM=y +CONFIG_SHA512SUM=y +CONFIG_SHA3SUM=y +CONFIG_SLEEP=y +CONFIG_FEATURE_FANCY_SLEEP=y +CONFIG_FEATURE_FLOAT_SLEEP=y +CONFIG_SORT=y +CONFIG_FEATURE_SORT_BIG=y +# CONFIG_SPLIT is not set +# CONFIG_FEATURE_SPLIT_FANCY is not set +# CONFIG_STAT is not set +# CONFIG_FEATURE_STAT_FORMAT is not set +CONFIG_STTY=y +# CONFIG_SUM is not set +# CONFIG_TAC is not set +CONFIG_TAIL=y +CONFIG_FEATURE_FANCY_TAIL=y +CONFIG_TEE=y +CONFIG_FEATURE_TEE_USE_BLOCK_IO=y +CONFIG_TRUE=y +CONFIG_TTY=y +CONFIG_UNAME=y +CONFIG_UNAME_OSNAME="GNU/Linux" +# CONFIG_UNEXPAND is not set +# CONFIG_FEATURE_UNEXPAND_LONG_OPTIONS is not set +CONFIG_UNIQ=y +CONFIG_USLEEP=y +CONFIG_UUDECODE=y +CONFIG_UUENCODE=y +CONFIG_WC=y +# CONFIG_FEATURE_WC_LARGE is not set +CONFIG_WHOAMI=y +CONFIG_YES=y + +# +# Common options +# +CONFIG_FEATURE_VERBOSE=y + +# +# Common options for cp and mv +# +CONFIG_FEATURE_PRESERVE_HARDLINKS=y + +# +# Common options for ls, more and telnet +# +CONFIG_FEATURE_AUTOWIDTH=y + +# +# Common options for df, du, ls +# +CONFIG_FEATURE_HUMAN_READABLE=y + +# +# Common options for md5sum, sha1sum, sha256sum, sha512sum, sha3sum +# +CONFIG_FEATURE_MD5_SHA1_SUM_CHECK=y + +# +# Console Utilities +# +# CONFIG_CHVT is not set +# CONFIG_FGCONSOLE is not set +# CONFIG_CLEAR is not set +# CONFIG_DEALLOCVT is not set +# CONFIG_DUMPKMAP is not set +# CONFIG_KBD_MODE is not set +# CONFIG_LOADFONT is not set +# CONFIG_LOADKMAP is not set +# CONFIG_OPENVT is not set +# CONFIG_RESET is not set +# CONFIG_RESIZE is not set +# CONFIG_FEATURE_RESIZE_PRINT is not set +# CONFIG_SETCONSOLE is not set +# CONFIG_FEATURE_SETCONSOLE_LONG_OPTIONS is not set +# CONFIG_SETFONT is not set +# CONFIG_FEATURE_SETFONT_TEXTUAL_MAP is not set +CONFIG_DEFAULT_SETFONT_DIR="" +# CONFIG_SETKEYCODES is not set +# CONFIG_SETLOGCONS is not set +# CONFIG_SHOWKEY is not set +# CONFIG_FEATURE_LOADFONT_PSF2 is not set +# CONFIG_FEATURE_LOADFONT_RAW is not set + +# +# Debian Utilities +# +# CONFIG_MKTEMP is not set +# CONFIG_PIPE_PROGRESS is not set +# CONFIG_RUN_PARTS is not set +# CONFIG_FEATURE_RUN_PARTS_LONG_OPTIONS is not set +# CONFIG_FEATURE_RUN_PARTS_FANCY is not set +CONFIG_START_STOP_DAEMON=y +CONFIG_FEATURE_START_STOP_DAEMON_FANCY=y +CONFIG_FEATURE_START_STOP_DAEMON_LONG_OPTIONS=y +CONFIG_WHICH=y + +# +# Editors +# +# CONFIG_AWK is not set +# CONFIG_FEATURE_AWK_LIBM is not set +# CONFIG_FEATURE_AWK_GNU_EXTENSIONS is not set +# CONFIG_CMP is not set +# CONFIG_DIFF is not set +# CONFIG_FEATURE_DIFF_LONG_OPTIONS is not set +# CONFIG_FEATURE_DIFF_DIR is not set +# CONFIG_ED is not set +# CONFIG_PATCH is not set +# CONFIG_SED is not set +# CONFIG_VI is not set +CONFIG_FEATURE_VI_MAX_LEN=0 +# CONFIG_FEATURE_VI_8BIT is not set +# CONFIG_FEATURE_VI_COLON is not set +# CONFIG_FEATURE_VI_YANKMARK is not set +# CONFIG_FEATURE_VI_SEARCH is not set +# CONFIG_FEATURE_VI_REGEX_SEARCH is not set +# CONFIG_FEATURE_VI_USE_SIGNALS is not set +# CONFIG_FEATURE_VI_DOT_CMD is not set +# CONFIG_FEATURE_VI_READONLY is not set +# CONFIG_FEATURE_VI_SETOPTS is not set +# CONFIG_FEATURE_VI_SET is not set +# CONFIG_FEATURE_VI_WIN_RESIZE is not set +# CONFIG_FEATURE_VI_ASK_TERMINAL is not set +# CONFIG_FEATURE_VI_UNDO is not set +# CONFIG_FEATURE_VI_UNDO_QUEUE is not set +CONFIG_FEATURE_VI_UNDO_QUEUE_MAX=0 +# CONFIG_FEATURE_ALLOW_EXEC is not set + +# +# Finding Utilities +# +# CONFIG_FIND is not set +# CONFIG_FEATURE_FIND_PRINT0 is not set +# CONFIG_FEATURE_FIND_MTIME is not set +# CONFIG_FEATURE_FIND_MMIN is not set +# CONFIG_FEATURE_FIND_PERM is not set +# CONFIG_FEATURE_FIND_TYPE is not set +# CONFIG_FEATURE_FIND_XDEV is not set +# CONFIG_FEATURE_FIND_MAXDEPTH is not set +# CONFIG_FEATURE_FIND_NEWER is not set +# CONFIG_FEATURE_FIND_INUM is not set +# CONFIG_FEATURE_FIND_EXEC is not set +# CONFIG_FEATURE_FIND_EXEC_PLUS is not set +# CONFIG_FEATURE_FIND_USER is not set +# CONFIG_FEATURE_FIND_GROUP is not set +# CONFIG_FEATURE_FIND_NOT is not set +# CONFIG_FEATURE_FIND_DEPTH is not set +# CONFIG_FEATURE_FIND_PAREN is not set +# CONFIG_FEATURE_FIND_SIZE is not set +# CONFIG_FEATURE_FIND_PRUNE is not set +# CONFIG_FEATURE_FIND_DELETE is not set +# CONFIG_FEATURE_FIND_PATH is not set +# CONFIG_FEATURE_FIND_REGEX is not set +# CONFIG_FEATURE_FIND_CONTEXT is not set +# CONFIG_FEATURE_FIND_LINKS is not set +CONFIG_GREP=y +CONFIG_FEATURE_GREP_EGREP_ALIAS=y +CONFIG_FEATURE_GREP_FGREP_ALIAS=y +CONFIG_FEATURE_GREP_CONTEXT=y +CONFIG_XARGS=y +# CONFIG_FEATURE_XARGS_SUPPORT_CONFIRMATION is not set +CONFIG_FEATURE_XARGS_SUPPORT_QUOTES=y +CONFIG_FEATURE_XARGS_SUPPORT_TERMOPT=y +CONFIG_FEATURE_XARGS_SUPPORT_ZERO_TERM=y +CONFIG_FEATURE_XARGS_SUPPORT_REPL_STR=y + +# +# Init Utilities +# +# CONFIG_BOOTCHARTD is not set +# CONFIG_FEATURE_BOOTCHARTD_BLOATED_HEADER is not set +# CONFIG_FEATURE_BOOTCHARTD_CONFIG_FILE is not set +CONFIG_HALT=y +# CONFIG_FEATURE_CALL_TELINIT is not set +CONFIG_TELINIT_PATH="" +CONFIG_INIT=y +CONFIG_FEATURE_USE_INITTAB=y +CONFIG_FEATURE_KILL_REMOVED=y +CONFIG_FEATURE_KILL_DELAY=0 +CONFIG_FEATURE_INIT_SCTTY=y +CONFIG_FEATURE_INIT_SYSLOG=y +CONFIG_FEATURE_EXTRA_QUIET=y +# CONFIG_FEATURE_INIT_COREDUMPS is not set +CONFIG_FEATURE_INITRD=y +CONFIG_INIT_TERMINAL_TYPE="linux" +CONFIG_MESG=y +CONFIG_FEATURE_MESG_ENABLE_ONLY_GROUP=y + +# +# Login/Password Management Utilities +# +# CONFIG_ADD_SHELL is not set +# CONFIG_REMOVE_SHELL is not set +CONFIG_FEATURE_SHADOWPASSWDS=y +# CONFIG_USE_BB_PWD_GRP is not set +# CONFIG_USE_BB_SHADOW is not set +CONFIG_USE_BB_CRYPT=y +# CONFIG_USE_BB_CRYPT_SHA is not set +CONFIG_ADDUSER=y +# CONFIG_FEATURE_ADDUSER_LONG_OPTIONS is not set +# CONFIG_FEATURE_CHECK_NAMES is not set +CONFIG_LAST_ID=60000 +CONFIG_FIRST_SYSTEM_ID=100 +CONFIG_LAST_SYSTEM_ID=999 +# CONFIG_ADDGROUP is not set +# CONFIG_FEATURE_ADDGROUP_LONG_OPTIONS is not set +# CONFIG_FEATURE_ADDUSER_TO_GROUP is not set +# CONFIG_DELUSER is not set +# CONFIG_DELGROUP is not set +# CONFIG_FEATURE_DEL_USER_FROM_GROUP is not set +CONFIG_GETTY=y +CONFIG_LOGIN=y +# CONFIG_LOGIN_SESSION_AS_CHILD is not set +# CONFIG_LOGIN_SCRIPTS is not set +CONFIG_FEATURE_NOLOGIN=y +CONFIG_FEATURE_SECURETTY=y +CONFIG_PASSWD=y +CONFIG_FEATURE_PASSWD_WEAK_CHECK=y +# CONFIG_CRYPTPW is not set +# CONFIG_CHPASSWD is not set +CONFIG_FEATURE_DEFAULT_PASSWD_ALGO="des" +# CONFIG_SU is not set +# CONFIG_FEATURE_SU_SYSLOG is not set +# CONFIG_FEATURE_SU_CHECKS_SHELLS is not set +# CONFIG_SULOGIN is not set +# CONFIG_VLOCK is not set + +# +# Linux Ext2 FS Progs +# +# CONFIG_CHATTR is not set +# CONFIG_FSCK is not set +# CONFIG_LSATTR is not set +# CONFIG_TUNE2FS is not set + +# +# Linux Module Utilities +# +# CONFIG_MODINFO is not set +# CONFIG_MODPROBE_SMALL is not set +# CONFIG_FEATURE_MODPROBE_SMALL_OPTIONS_ON_CMDLINE is not set +# CONFIG_FEATURE_MODPROBE_SMALL_CHECK_ALREADY_LOADED is not set +# CONFIG_INSMOD is not set +# CONFIG_RMMOD is not set +# CONFIG_LSMOD is not set +# CONFIG_FEATURE_LSMOD_PRETTY_2_6_OUTPUT is not set +# CONFIG_MODPROBE is not set +# CONFIG_FEATURE_MODPROBE_BLACKLIST is not set +# CONFIG_DEPMOD is not set + +# +# Options common to multiple modutils +# +# CONFIG_FEATURE_2_4_MODULES is not set +# CONFIG_FEATURE_INSMOD_TRY_MMAP is not set +# CONFIG_FEATURE_INSMOD_VERSION_CHECKING is not set +# CONFIG_FEATURE_INSMOD_KSYMOOPS_SYMBOLS is not set +# CONFIG_FEATURE_INSMOD_LOADINKMEM is not set +# CONFIG_FEATURE_INSMOD_LOAD_MAP is not set +# CONFIG_FEATURE_INSMOD_LOAD_MAP_FULL is not set +# CONFIG_FEATURE_CHECK_TAINTED_MODULE is not set +# CONFIG_FEATURE_MODUTILS_ALIAS is not set +# CONFIG_FEATURE_MODUTILS_SYMBOLS is not set +CONFIG_DEFAULT_MODULES_DIR="" +CONFIG_DEFAULT_DEPMOD_FILE="" + +# +# Linux System Utilities +# +# CONFIG_BLOCKDEV is not set +# CONFIG_FATATTR is not set +# CONFIG_FSTRIM is not set +# CONFIG_MDEV is not set +# CONFIG_FEATURE_MDEV_CONF is not set +# CONFIG_FEATURE_MDEV_RENAME is not set +# CONFIG_FEATURE_MDEV_RENAME_REGEXP is not set +# CONFIG_FEATURE_MDEV_EXEC is not set +# CONFIG_FEATURE_MDEV_LOAD_FIRMWARE is not set +CONFIG_MOUNT=y +# CONFIG_FEATURE_MOUNT_FAKE is not set +# CONFIG_FEATURE_MOUNT_VERBOSE is not set +# CONFIG_FEATURE_MOUNT_HELPERS is not set +# CONFIG_FEATURE_MOUNT_LABEL is not set +# CONFIG_FEATURE_MOUNT_NFS is not set +CONFIG_FEATURE_MOUNT_CIFS=y +CONFIG_FEATURE_MOUNT_FLAGS=y +CONFIG_FEATURE_MOUNT_FSTAB=y +CONFIG_FEATURE_MOUNT_OTHERTAB=y +# CONFIG_REV is not set +# CONFIG_UEVENT is not set +# CONFIG_ACPID is not set +# CONFIG_FEATURE_ACPID_COMPAT is not set +# CONFIG_BLKID is not set +# CONFIG_FEATURE_BLKID_TYPE is not set +CONFIG_DMESG=y +CONFIG_FEATURE_DMESG_PRETTY=y +# CONFIG_FBSET is not set +# CONFIG_FEATURE_FBSET_FANCY is not set +# CONFIG_FEATURE_FBSET_READMODE is not set +# CONFIG_FDFLUSH is not set +# CONFIG_FDFORMAT is not set +# CONFIG_FDISK is not set +# CONFIG_FDISK_SUPPORT_LARGE_DISKS is not set +# CONFIG_FEATURE_FDISK_WRITABLE is not set +# CONFIG_FEATURE_AIX_LABEL is not set +# CONFIG_FEATURE_SGI_LABEL is not set +# CONFIG_FEATURE_SUN_LABEL is not set +# CONFIG_FEATURE_OSF_LABEL is not set +# CONFIG_FEATURE_GPT_LABEL is not set +# CONFIG_FEATURE_FDISK_ADVANCED is not set +# CONFIG_FINDFS is not set +# CONFIG_FLOCK is not set +CONFIG_FREERAMDISK=y +# CONFIG_FSCK_MINIX is not set +# CONFIG_MKFS_EXT2 is not set +# CONFIG_MKFS_MINIX is not set +# CONFIG_FEATURE_MINIX2 is not set +# CONFIG_MKFS_REISER is not set +# CONFIG_MKFS_VFAT is not set +CONFIG_GETOPT=y +CONFIG_FEATURE_GETOPT_LONG=y +# CONFIG_HEXDUMP is not set +# CONFIG_FEATURE_HEXDUMP_REVERSE is not set +# CONFIG_HD is not set +# CONFIG_HWCLOCK is not set +# CONFIG_FEATURE_HWCLOCK_LONG_OPTIONS is not set +# CONFIG_FEATURE_HWCLOCK_ADJTIME_FHS is not set +# CONFIG_IPCRM is not set +# CONFIG_IPCS is not set +# CONFIG_LOSETUP is not set +# CONFIG_LSPCI is not set +# CONFIG_LSUSB is not set +# CONFIG_MKSWAP is not set +# CONFIG_FEATURE_MKSWAP_UUID is not set +CONFIG_MORE=y +# CONFIG_PIVOT_ROOT is not set +# CONFIG_RDATE is not set +# CONFIG_RDEV is not set +# CONFIG_READPROFILE is not set +# CONFIG_RTCWAKE is not set +# CONFIG_SCRIPT is not set +# CONFIG_SCRIPTREPLAY is not set +# CONFIG_SETARCH is not set +# CONFIG_SWAPONOFF is not set +# CONFIG_FEATURE_SWAPON_DISCARD is not set +# CONFIG_FEATURE_SWAPON_PRI is not set +# CONFIG_SWITCH_ROOT is not set +CONFIG_UMOUNT=y +CONFIG_FEATURE_UMOUNT_ALL=y + +# +# Common options for mount/umount +# +CONFIG_FEATURE_MOUNT_LOOP=y +CONFIG_FEATURE_MOUNT_LOOP_CREATE=y +# CONFIG_FEATURE_MTAB_SUPPORT is not set +# CONFIG_VOLUMEID is not set +# CONFIG_FEATURE_VOLUMEID_BTRFS is not set +# CONFIG_FEATURE_VOLUMEID_CRAMFS is not set +# CONFIG_FEATURE_VOLUMEID_EXFAT is not set +# CONFIG_FEATURE_VOLUMEID_EXT is not set +# CONFIG_FEATURE_VOLUMEID_F2FS is not set +# CONFIG_FEATURE_VOLUMEID_FAT is not set +# CONFIG_FEATURE_VOLUMEID_HFS is not set +# CONFIG_FEATURE_VOLUMEID_ISO9660 is not set +# CONFIG_FEATURE_VOLUMEID_JFS is not set +# CONFIG_FEATURE_VOLUMEID_LINUXRAID is not set +# CONFIG_FEATURE_VOLUMEID_LINUXSWAP is not set +# CONFIG_FEATURE_VOLUMEID_LUKS is not set +# CONFIG_FEATURE_VOLUMEID_NILFS is not set +# CONFIG_FEATURE_VOLUMEID_NTFS is not set +# CONFIG_FEATURE_VOLUMEID_OCFS2 is not set +# CONFIG_FEATURE_VOLUMEID_REISERFS is not set +# CONFIG_FEATURE_VOLUMEID_ROMFS is not set +# CONFIG_FEATURE_VOLUMEID_SQUASHFS is not set +# CONFIG_FEATURE_VOLUMEID_SYSV is not set +# CONFIG_FEATURE_VOLUMEID_UDF is not set +# CONFIG_FEATURE_VOLUMEID_XFS is not set + +# +# Miscellaneous Utilities +# +# CONFIG_CONSPY is not set +# CONFIG_CROND is not set +# CONFIG_FEATURE_CROND_D is not set +# CONFIG_FEATURE_CROND_CALL_SENDMAIL is not set +CONFIG_FEATURE_CROND_DIR="" +# CONFIG_I2CGET is not set +# CONFIG_I2CSET is not set +# CONFIG_I2CDUMP is not set +# CONFIG_I2CDETECT is not set +# CONFIG_LESS is not set +CONFIG_FEATURE_LESS_MAXLINES=0 +# CONFIG_FEATURE_LESS_BRACKETS is not set +# CONFIG_FEATURE_LESS_FLAGS is not set +# CONFIG_FEATURE_LESS_TRUNCATE is not set +# CONFIG_FEATURE_LESS_MARKS is not set +# CONFIG_FEATURE_LESS_REGEXP is not set +# CONFIG_FEATURE_LESS_WINCH is not set +# CONFIG_FEATURE_LESS_ASK_TERMINAL is not set +# CONFIG_FEATURE_LESS_DASHCMD is not set +# CONFIG_FEATURE_LESS_LINENUMS is not set +# CONFIG_NANDWRITE is not set +# CONFIG_NANDDUMP is not set +# CONFIG_RFKILL is not set +CONFIG_SETSERIAL=y +# CONFIG_TASKSET is not set +# CONFIG_FEATURE_TASKSET_FANCY is not set +# CONFIG_UBIATTACH is not set +# CONFIG_UBIDETACH is not set +# CONFIG_UBIMKVOL is not set +# CONFIG_UBIRMVOL is not set +# CONFIG_UBIRSVOL is not set +# CONFIG_UBIUPDATEVOL is not set +# CONFIG_WALL is not set +# CONFIG_ADJTIMEX is not set +# CONFIG_BBCONFIG is not set +# CONFIG_FEATURE_COMPRESS_BBCONFIG is not set +# CONFIG_BEEP is not set +CONFIG_FEATURE_BEEP_FREQ=0 +CONFIG_FEATURE_BEEP_LENGTH_MS=0 +# CONFIG_CHAT is not set +# CONFIG_FEATURE_CHAT_NOFAIL is not set +# CONFIG_FEATURE_CHAT_TTY_HIFI is not set +# CONFIG_FEATURE_CHAT_IMPLICIT_CR is not set +# CONFIG_FEATURE_CHAT_SWALLOW_OPTS is not set +# CONFIG_FEATURE_CHAT_SEND_ESCAPES is not set +# CONFIG_FEATURE_CHAT_VAR_ABORT_LEN is not set +# CONFIG_FEATURE_CHAT_CLR_ABORT is not set +# CONFIG_CHRT is not set +# CONFIG_CRONTAB is not set +# CONFIG_DC is not set +# CONFIG_FEATURE_DC_LIBM is not set +# CONFIG_DEVFSD is not set +# CONFIG_DEVFSD_MODLOAD is not set +# CONFIG_DEVFSD_FG_NP is not set +# CONFIG_DEVFSD_VERBOSE is not set +# CONFIG_FEATURE_DEVFS is not set +# CONFIG_DEVMEM is not set +# CONFIG_EJECT is not set +# CONFIG_FEATURE_EJECT_SCSI is not set +# CONFIG_FBSPLASH is not set +# CONFIG_FLASHCP is not set +# CONFIG_FLASH_LOCK is not set +# CONFIG_FLASH_UNLOCK is not set +# CONFIG_FLASH_ERASEALL is not set +# CONFIG_IONICE is not set +# CONFIG_INOTIFYD is not set +# CONFIG_LAST is not set +# CONFIG_FEATURE_LAST_SMALL is not set +# CONFIG_FEATURE_LAST_FANCY is not set +# CONFIG_HDPARM is not set +# CONFIG_FEATURE_HDPARM_GET_IDENTITY is not set +# CONFIG_FEATURE_HDPARM_HDIO_SCAN_HWIF is not set +# CONFIG_FEATURE_HDPARM_HDIO_UNREGISTER_HWIF is not set +# CONFIG_FEATURE_HDPARM_HDIO_DRIVE_RESET is not set +# CONFIG_FEATURE_HDPARM_HDIO_TRISTATE_HWIF is not set +# CONFIG_FEATURE_HDPARM_HDIO_GETSET_DMA is not set +# CONFIG_MAKEDEVS is not set +# CONFIG_FEATURE_MAKEDEVS_LEAF is not set +# CONFIG_FEATURE_MAKEDEVS_TABLE is not set +# CONFIG_MAN is not set +# CONFIG_MICROCOM is not set +# CONFIG_MOUNTPOINT is not set +# CONFIG_MT is not set +# CONFIG_RAIDAUTORUN is not set +# CONFIG_READAHEAD is not set +# CONFIG_RUNLEVEL is not set +# CONFIG_RX is not set +# CONFIG_SETSID is not set +# CONFIG_STRINGS is not set +# CONFIG_TIME is not set +# CONFIG_TIMEOUT is not set +# CONFIG_TTYSIZE is not set +# CONFIG_VOLNAME is not set +# CONFIG_WATCHDOG is not set + +# +# Networking Utilities +# +# CONFIG_NAMEIF is not set +# CONFIG_FEATURE_NAMEIF_EXTENDED is not set +# CONFIG_NBDCLIENT is not set +# CONFIG_NC is not set +# CONFIG_NC_SERVER is not set +# CONFIG_NC_EXTRA is not set +# CONFIG_NC_110_COMPAT is not set +# CONFIG_PING is not set +# CONFIG_PING6 is not set +# CONFIG_FEATURE_FANCY_PING is not set +# CONFIG_WGET is not set +# CONFIG_FEATURE_WGET_STATUSBAR is not set +# CONFIG_FEATURE_WGET_AUTHENTICATION is not set +# CONFIG_FEATURE_WGET_LONG_OPTIONS is not set +# CONFIG_FEATURE_WGET_TIMEOUT is not set +# CONFIG_FEATURE_WGET_OPENSSL is not set +# CONFIG_FEATURE_WGET_SSL_HELPER is not set +# CONFIG_WHOIS is not set +# CONFIG_FEATURE_IPV6 is not set +# CONFIG_FEATURE_UNIX_LOCAL is not set +# CONFIG_FEATURE_PREFER_IPV4_ADDRESS is not set +# CONFIG_VERBOSE_RESOLUTION_ERRORS is not set +# CONFIG_ARP is not set +# CONFIG_ARPING is not set +# CONFIG_BRCTL is not set +# CONFIG_FEATURE_BRCTL_FANCY is not set +# CONFIG_FEATURE_BRCTL_SHOW is not set +# CONFIG_DNSD is not set +# CONFIG_ETHER_WAKE is not set +# CONFIG_FAKEIDENTD is not set +# CONFIG_FTPD is not set +# CONFIG_FEATURE_FTP_WRITE is not set +# CONFIG_FEATURE_FTPD_ACCEPT_BROKEN_LIST is not set +# CONFIG_FEATURE_FTP_AUTHENTICATION is not set +# CONFIG_FTPGET is not set +# CONFIG_FTPPUT is not set +# CONFIG_FEATURE_FTPGETPUT_LONG_OPTIONS is not set +CONFIG_HOSTNAME=y +# CONFIG_HTTPD is not set +# CONFIG_FEATURE_HTTPD_RANGES is not set +# CONFIG_FEATURE_HTTPD_SETUID is not set +# CONFIG_FEATURE_HTTPD_BASIC_AUTH is not set +# CONFIG_FEATURE_HTTPD_AUTH_MD5 is not set +# CONFIG_FEATURE_HTTPD_CGI is not set +# CONFIG_FEATURE_HTTPD_CONFIG_WITH_SCRIPT_INTERPR is not set +# CONFIG_FEATURE_HTTPD_SET_REMOTE_PORT_TO_ENV is not set +# CONFIG_FEATURE_HTTPD_ENCODE_URL_STR is not set +# CONFIG_FEATURE_HTTPD_ERROR_PAGES is not set +# CONFIG_FEATURE_HTTPD_PROXY is not set +# CONFIG_FEATURE_HTTPD_GZIP is not set +# CONFIG_IFCONFIG is not set +# CONFIG_FEATURE_IFCONFIG_STATUS is not set +# CONFIG_FEATURE_IFCONFIG_SLIP is not set +# CONFIG_FEATURE_IFCONFIG_MEMSTART_IOADDR_IRQ is not set +# CONFIG_FEATURE_IFCONFIG_HW is not set +# CONFIG_FEATURE_IFCONFIG_BROADCAST_PLUS is not set +# CONFIG_IFENSLAVE is not set +# CONFIG_IFPLUGD is not set +# CONFIG_IFUPDOWN is not set +CONFIG_IFUPDOWN_IFSTATE_PATH="" +# CONFIG_FEATURE_IFUPDOWN_IP is not set +# CONFIG_FEATURE_IFUPDOWN_IP_BUILTIN is not set +# CONFIG_FEATURE_IFUPDOWN_IFCONFIG_BUILTIN is not set +# CONFIG_FEATURE_IFUPDOWN_IPV4 is not set +# CONFIG_FEATURE_IFUPDOWN_IPV6 is not set +# CONFIG_FEATURE_IFUPDOWN_MAPPING is not set +# CONFIG_FEATURE_IFUPDOWN_EXTERNAL_DHCP is not set +# CONFIG_INETD is not set +# CONFIG_FEATURE_INETD_SUPPORT_BUILTIN_ECHO is not set +# CONFIG_FEATURE_INETD_SUPPORT_BUILTIN_DISCARD is not set +# CONFIG_FEATURE_INETD_SUPPORT_BUILTIN_TIME is not set +# CONFIG_FEATURE_INETD_SUPPORT_BUILTIN_DAYTIME is not set +# CONFIG_FEATURE_INETD_SUPPORT_BUILTIN_CHARGEN is not set +# CONFIG_FEATURE_INETD_RPC is not set +# CONFIG_IP is not set +# CONFIG_FEATURE_IP_ADDRESS is not set +# CONFIG_FEATURE_IP_LINK is not set +# CONFIG_FEATURE_IP_ROUTE is not set +CONFIG_FEATURE_IP_ROUTE_DIR="" +# CONFIG_FEATURE_IP_TUNNEL is not set +# CONFIG_FEATURE_IP_RULE is not set +# CONFIG_FEATURE_IP_SHORT_FORMS is not set +# CONFIG_FEATURE_IP_RARE_PROTOCOLS is not set +# CONFIG_IPADDR is not set +# CONFIG_IPLINK is not set +# CONFIG_IPROUTE is not set +# CONFIG_IPTUNNEL is not set +# CONFIG_IPRULE is not set +# CONFIG_IPCALC is not set +# CONFIG_FEATURE_IPCALC_FANCY is not set +# CONFIG_FEATURE_IPCALC_LONG_OPTIONS is not set +# CONFIG_NETSTAT is not set +# CONFIG_FEATURE_NETSTAT_WIDE is not set +# CONFIG_FEATURE_NETSTAT_PRG is not set +# CONFIG_NSLOOKUP is not set +# CONFIG_NTPD is not set +# CONFIG_FEATURE_NTPD_SERVER is not set +# CONFIG_FEATURE_NTPD_CONF is not set +# CONFIG_PSCAN is not set +# CONFIG_ROUTE is not set +# CONFIG_SLATTACH is not set +# CONFIG_TCPSVD is not set +# CONFIG_TELNET is not set +# CONFIG_FEATURE_TELNET_TTYPE is not set +# CONFIG_FEATURE_TELNET_AUTOLOGIN is not set +# CONFIG_TELNETD is not set +# CONFIG_FEATURE_TELNETD_STANDALONE is not set +# CONFIG_FEATURE_TELNETD_INETD_WAIT is not set +# CONFIG_TFTP is not set +# CONFIG_TFTPD is not set +# CONFIG_FEATURE_TFTP_GET is not set +# CONFIG_FEATURE_TFTP_PUT is not set +# CONFIG_FEATURE_TFTP_BLOCKSIZE is not set +# CONFIG_FEATURE_TFTP_PROGRESS_BAR is not set +# CONFIG_TFTP_DEBUG is not set +# CONFIG_TRACEROUTE is not set +# CONFIG_TRACEROUTE6 is not set +# CONFIG_FEATURE_TRACEROUTE_VERBOSE is not set +# CONFIG_FEATURE_TRACEROUTE_SOURCE_ROUTE is not set +# CONFIG_FEATURE_TRACEROUTE_USE_ICMP is not set +# CONFIG_TUNCTL is not set +# CONFIG_FEATURE_TUNCTL_UG is not set +# CONFIG_UDHCPC6 is not set +# CONFIG_UDHCPD is not set +# CONFIG_DHCPRELAY is not set +# CONFIG_DUMPLEASES is not set +# CONFIG_FEATURE_UDHCPD_WRITE_LEASES_EARLY is not set +# CONFIG_FEATURE_UDHCPD_BASE_IP_ON_MAC is not set +CONFIG_DHCPD_LEASES_FILE="" +# CONFIG_UDHCPC is not set +# CONFIG_FEATURE_UDHCPC_ARPING is not set +# CONFIG_FEATURE_UDHCPC_SANITIZEOPT is not set +# CONFIG_FEATURE_UDHCP_PORT is not set +CONFIG_UDHCP_DEBUG=0 +# CONFIG_FEATURE_UDHCP_RFC3397 is not set +# CONFIG_FEATURE_UDHCP_8021Q is not set +CONFIG_UDHCPC_DEFAULT_SCRIPT="" +CONFIG_UDHCPC_SLACK_FOR_BUGGY_SERVERS=0 +CONFIG_IFUPDOWN_UDHCPC_CMD_OPTIONS="" +# CONFIG_UDPSVD is not set +# CONFIG_VCONFIG is not set +# CONFIG_ZCIP is not set + +# +# Print Utilities +# +# CONFIG_LPD is not set +# CONFIG_LPR is not set +# CONFIG_LPQ is not set + +# +# Mail Utilities +# +# CONFIG_MAKEMIME is not set +CONFIG_FEATURE_MIME_CHARSET="" +# CONFIG_POPMAILDIR is not set +# CONFIG_FEATURE_POPMAILDIR_DELIVERY is not set +# CONFIG_REFORMIME is not set +# CONFIG_FEATURE_REFORMIME_COMPAT is not set +# CONFIG_SENDMAIL is not set + +# +# Process Utilities +# +# CONFIG_IOSTAT is not set +# CONFIG_LSOF is not set +# CONFIG_MPSTAT is not set +# CONFIG_NMETER is not set +# CONFIG_PMAP is not set +# CONFIG_POWERTOP is not set +# CONFIG_PSTREE is not set +# CONFIG_PWDX is not set +# CONFIG_SMEMCAP is not set +# CONFIG_TOP is not set +# CONFIG_FEATURE_TOP_CPU_USAGE_PERCENTAGE is not set +# CONFIG_FEATURE_TOP_CPU_GLOBAL_PERCENTS is not set +# CONFIG_FEATURE_TOP_SMP_CPU is not set +# CONFIG_FEATURE_TOP_DECIMALS is not set +# CONFIG_FEATURE_TOP_SMP_PROCESS is not set +# CONFIG_FEATURE_TOPMEM is not set +# CONFIG_UPTIME is not set +# CONFIG_FEATURE_UPTIME_UTMP_SUPPORT is not set +# CONFIG_FREE is not set +# CONFIG_FUSER is not set +CONFIG_KILL=y +CONFIG_KILLALL=y +CONFIG_KILLALL5=y +# CONFIG_PGREP is not set +# CONFIG_PIDOF is not set +# CONFIG_FEATURE_PIDOF_SINGLE is not set +# CONFIG_FEATURE_PIDOF_OMIT is not set +# CONFIG_PKILL is not set +CONFIG_PS=y +CONFIG_FEATURE_PS_WIDE=y +CONFIG_FEATURE_PS_LONG=y +# CONFIG_FEATURE_PS_TIME is not set +# CONFIG_FEATURE_PS_ADDITIONAL_COLUMNS is not set +# CONFIG_FEATURE_PS_UNUSUAL_SYSTEMS is not set +# CONFIG_RENICE is not set +# CONFIG_BB_SYSCTL is not set +# CONFIG_FEATURE_SHOW_THREADS is not set +# CONFIG_WATCH is not set + +# +# Runit Utilities +# +# CONFIG_RUNSV is not set +# CONFIG_RUNSVDIR is not set +# CONFIG_FEATURE_RUNSVDIR_LOG is not set +# CONFIG_SV is not set +CONFIG_SV_DEFAULT_SERVICE_DIR="" +# CONFIG_SVLOGD is not set +# CONFIG_CHPST is not set +# CONFIG_SETUIDGID is not set +# CONFIG_ENVUIDGID is not set +# CONFIG_ENVDIR is not set +# CONFIG_SOFTLIMIT is not set +# CONFIG_CHCON is not set +# CONFIG_FEATURE_CHCON_LONG_OPTIONS is not set +# CONFIG_GETENFORCE is not set +# CONFIG_GETSEBOOL is not set +# CONFIG_LOAD_POLICY is not set +# CONFIG_MATCHPATHCON is not set +# CONFIG_RESTORECON is not set +# CONFIG_RUNCON is not set +# CONFIG_FEATURE_RUNCON_LONG_OPTIONS is not set +# CONFIG_SELINUXENABLED is not set +# CONFIG_SETENFORCE is not set +# CONFIG_SETFILES is not set +# CONFIG_FEATURE_SETFILES_CHECK_OPTION is not set +# CONFIG_SETSEBOOL is not set +# CONFIG_SESTATUS is not set + +# +# Shells +# +# CONFIG_ASH is not set +# CONFIG_ASH_BASH_COMPAT is not set +# CONFIG_ASH_IDLE_TIMEOUT is not set +# CONFIG_ASH_JOB_CONTROL is not set +# CONFIG_ASH_ALIAS is not set +# CONFIG_ASH_GETOPTS is not set +# CONFIG_ASH_BUILTIN_ECHO is not set +# CONFIG_ASH_BUILTIN_PRINTF is not set +# CONFIG_ASH_BUILTIN_TEST is not set +# CONFIG_ASH_HELP is not set +# CONFIG_ASH_CMDCMD is not set +# CONFIG_ASH_MAIL is not set +# CONFIG_ASH_OPTIMIZE_FOR_SIZE is not set +# CONFIG_ASH_RANDOM_SUPPORT is not set +# CONFIG_ASH_EXPAND_PRMT is not set +# CONFIG_CTTYHACK is not set +CONFIG_HUSH=y +CONFIG_HUSH_BASH_COMPAT=y +CONFIG_HUSH_BRACE_EXPANSION=y +CONFIG_HUSH_HELP=y +CONFIG_HUSH_INTERACTIVE=y +CONFIG_HUSH_SAVEHISTORY=y +CONFIG_HUSH_JOB=y +CONFIG_HUSH_TICK=y +CONFIG_HUSH_IF=y +CONFIG_HUSH_LOOPS=y +CONFIG_HUSH_CASE=y +CONFIG_HUSH_FUNCTIONS=y +CONFIG_HUSH_LOCAL=y +CONFIG_HUSH_RANDOM_SUPPORT=y +CONFIG_HUSH_EXPORT_N=y +CONFIG_HUSH_MODE_X=y +# CONFIG_MSH is not set +# CONFIG_FEATURE_SH_IS_ASH is not set +CONFIG_FEATURE_SH_IS_HUSH=y +# CONFIG_FEATURE_SH_IS_NONE is not set +# CONFIG_FEATURE_BASH_IS_ASH is not set +# CONFIG_FEATURE_BASH_IS_HUSH is not set +CONFIG_FEATURE_BASH_IS_NONE=y +CONFIG_SH_MATH_SUPPORT=y +# CONFIG_SH_MATH_SUPPORT_64 is not set +CONFIG_FEATURE_SH_EXTRA_QUIET=y +# CONFIG_FEATURE_SH_STANDALONE is not set +# CONFIG_FEATURE_SH_NOFORK is not set +# CONFIG_FEATURE_SH_HISTFILESIZE is not set + +# +# System Logging Utilities +# +# CONFIG_SYSLOGD is not set +# CONFIG_FEATURE_ROTATE_LOGFILE is not set +# CONFIG_FEATURE_REMOTE_LOG is not set +# CONFIG_FEATURE_SYSLOGD_DUP is not set +# CONFIG_FEATURE_SYSLOGD_CFG is not set +CONFIG_FEATURE_SYSLOGD_READ_BUFFER_SIZE=0 +# CONFIG_FEATURE_IPC_SYSLOG is not set +CONFIG_FEATURE_IPC_SYSLOG_BUFFER_SIZE=0 +# CONFIG_LOGREAD is not set +# CONFIG_FEATURE_LOGREAD_REDUCED_LOCKING is not set +# CONFIG_FEATURE_KMSG_SYSLOG is not set +# CONFIG_KLOGD is not set +# CONFIG_FEATURE_KLOGD_KLOGCTL is not set +# CONFIG_LOGGER is not set
board/stmicroelectronics/stm32-post-build.sh new file +8 -0
@@ -0,0 +1,8 @@ +#!/bin/sh + +# Kernel is built without devpts support +sed -i '/^devpts/d' ${TARGET_DIR}/etc/fstab + +# Kernel is built without network support +rm -f ${TARGET_DIR}/etc/init.d/S40network +rm -rf ${TARGET_DIR}/etc/network/
board/stmicroelectronics/stm32f429-disco/flash.sh new file +20 -0
@@ -0,0 +1,20 @@ +#!/bin/bash + +OUTPUT_DIR=$1 + +if ! test -d "${OUTPUT_DIR}" ; then + echo "ERROR: no output directory specified." + echo "Usage: $0 OUTPUT_DIR" + exit 1 +fi + +${OUTPUT_DIR}/host/usr/bin/openocd -f board/stm32f429discovery.cfg \ + -c "init" \ + -c "reset init" \ + -c "flash probe 0" \ + -c "flash info 0" \ + -c "flash write_image erase ${OUTPUT_DIR}/images/stm32f429i-disco.bin 0x08000000" \ + -c "flash write_image erase ${OUTPUT_DIR}/images/stm32f429-disco.dtb 0x08004000" \ + -c "flash write_image erase ${OUTPUT_DIR}/images/xipImage 0x08008000" \ + -c "reset run" \ + -c "shutdown"
board/stmicroelectronics/stm32f429-disco/patches/linux/0001-ARM-stm32f249-disco-don-t-force-init-in-chosen-boota.patch new file +32 -0
@@ -0,0 +1,32 @@ +From ded9afa688184b3240a92c2b8f114c545a09bc3f Mon Sep 17 00:00:00 2001 +From: Thomas Petazzoni <[email protected]> +Date: Sat, 12 Mar 2016 23:14:41 +0100 +Subject: [PATCH] ARM: stm32f249-disco: don't force init= in /chosen/bootargs + +There is no reason to override the kernel's default init= value, as +this breaks userspace that assumes the kernel default of /init is +used. Since stm32 is often used with a minimal bootloader +(afboot-stm32) that doesn't provide any mechanism to override the DTB, +we need to adjust the kernel command line in the Device Tree source. + +Signed-off-by: Thomas Petazzoni <[email protected]> +--- + arch/arm/boot/dts/stm32f429-disco.dts | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/arch/arm/boot/dts/stm32f429-disco.dts b/arch/arm/boot/dts/stm32f429-disco.dts +index f0b731d..2bae81c 100644 +--- a/arch/arm/boot/dts/stm32f429-disco.dts ++++ b/arch/arm/boot/dts/stm32f429-disco.dts +@@ -53,7 +53,7 @@ + compatible = "st,stm32f429i-disco", "st,stm32f429"; + + chosen { +- bootargs = "root=/dev/ram rdinit=/linuxrc"; ++ bootargs = "root=/dev/ram"; + stdout-path = "serial0:115200n8"; + }; + +-- +2.6.4 +
board/stmicroelectronics/stm32f429-disco/readme.txt new file +30 -0
@@ -0,0 +1,30 @@ +STM32F429 Discovery +=================== + +This tutorial describes how to use the predefined Buildroot +configuration for the STM32F429 Discovery evaluation platform. + +Building +-------- + + make stm32f429_disco_defconfig + make + +Wire the UART +------------- + +Use a USB to TTL adapter, and connect: + + - RX to PA9 + - TX to PA10 + - GND to one of the GND available on the board + +The UART is configured at 115200. + +Flashing +-------- + + ./board/stmicroelectronics/stm32/stm32f429-disco/flash.sh output/ + +It will flash the minimal bootloader, the Device Tree Blob, and the +kernel image which includes the root filesystem as initramfs.
configs/stm32f429_disco_defconfig new file +18 -0
@@ -0,0 +1,18 @@ +BR2_arm=y +BR2_cortex_m4=y +BR2_GLOBAL_PATCH_DIR="board/stmicroelectronics/stm32f429-disco/patches/" +BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_4=y +BR2_ROOTFS_POST_BUILD_SCRIPT="board/stmicroelectronics/stm32-post-build.sh" +BR2_LINUX_KERNEL=y +BR2_LINUX_KERNEL_CUSTOM_VERSION=y +BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.4.5" +BR2_LINUX_KERNEL_DEFCONFIG="stm32" +BR2_LINUX_KERNEL_IMAGE_TARGET_CUSTOM=y +BR2_LINUX_KERNEL_IMAGE_TARGET_NAME="xipImage" +BR2_LINUX_KERNEL_DTS_SUPPORT=y +BR2_LINUX_KERNEL_INTREE_DTS_NAME="stm32f429-disco" +BR2_PACKAGE_BUSYBOX_CONFIG="board/stmicroelectronics/busybox-minimal.config" +BR2_TARGET_ROOTFS_INITRAMFS=y +# BR2_TARGET_ROOTFS_TAR is not set +BR2_TARGET_AFBOOT_STM32=y +BR2_PACKAGE_HOST_OPENOCD=y
Signature · 1 line
2.6.4
PATCH 16/16 configs/stm32f469_disco: new configuration for STM32F469 Discovery board
In reply to Thomas PetazzoniFrom: Lee Jones <[email protected]>
Similar to stm32f429_disco, this commit adds a configuration for the Cortex-M4 based STM32F469 platform.
It requires a few kernel patches, which have already been submitted upstream, as well as a small OpenOCD patch. Besides that, it re-uses most of what has been added for the STM32F429 platform.
[Thomas:
- squash multiple patches from Lee Jones into one
- improve the readme.txt file
- sync the defconfig with the adaptations made to the stm32f429 configuration.]
--- board/stmicroelectronics/stm32f469-disco/flash.sh | 20 ++++ .../linux/0001-kernel-add-top-compatible.patch | 25 +++++ .../patches/linux/0002-kernel-new-dts-file.patch | 114 +++++++++++++++++++++ .../linux/0003-kernel-config-frag-ram.patch | 28 +++++ .../patches/openocd/0001-add-config.patch | 37 +++++++ .../patches/openocd/0002-flash-nor.patch | 37 +++++++ .../stmicroelectronics/stm32f469-disco/readme.txt | 19 ++++ configs/stm32f469_disco_defconfig | 19 ++++ 8 files changed, 299 insertions(+) create mode 100755 board/stmicroelectronics/stm32f469-disco/flash.sh create mode 100644 board/stmicroelectronics/stm32f469-disco/patches/linux/0001-kernel-add-top-compatible.patch create mode 100644 board/stmicroelectronics/stm32f469-disco/patches/linux/0002-kernel-new-dts-file.patch create mode 100644 board/stmicroelectronics/stm32f469-disco/patches/linux/0003-kernel-config-frag-ram.patch create mode 100644 board/stmicroelectronics/stm32f469-disco/patches/openocd/0001-add-config.patch create mode 100644 board/stmicroelectronics/stm32f469-disco/patches/openocd/0002-flash-nor.patch create mode 100644 board/stmicroelectronics/stm32f469-disco/readme.txt create mode 100644 configs/stm32f469_disco_defconfig
board/stmicroelectronics/stm32f469-disco/flash.sh new file +20 -0
@@ -0,0 +1,20 @@ +#!/bin/bash + +OUTPUT_DIR=$1 + +if ! test -d "${OUTPUT_DIR}" ; then + echo "ERROR: no output directory specified." + echo "Usage: $0 OUTPUT_DIR" + exit 1 +fi + +${OUTPUT_DIR}/host/usr/bin/openocd -f board/stm32f469discovery.cfg \ + -c "init" \ + -c "reset init" \ + -c "flash probe 0" \ + -c "flash info 0" \ + -c "flash write_image erase ${OUTPUT_DIR}/images/stm32f469i-disco.bin 0x08000000" \ + -c "flash write_image erase ${OUTPUT_DIR}/images/stm32f469-disco.dtb 0x08004000" \ + -c "flash write_image erase ${OUTPUT_DIR}/images/xipImage 0x08008000" \ + -c "reset run" \ + -c "shutdown"
board/stmicroelectronics/stm32f469-disco/patches/linux/0001-kernel-add-top-compatible.patch new file +25 -0
@@ -0,0 +1,25 @@ +From 6bd8bae3dd0631f8d23e63617dca289f162e6840 Mon Sep 17 00:00:00 2001 +From: Lee Jones <[email protected]> +Date: Tue, 16 Feb 2016 14:04:17 +0000 +Subject: [PATCH] ARM: stm32: Identify a new board - STM32F469 + +Signed-off-by: Lee Jones <[email protected]> +--- + arch/arm/mach-stm32/board-dt.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/arch/arm/mach-stm32/board-dt.c b/arch/arm/mach-stm32/board-dt.c +index f2ad772..ceee477 100644 +--- a/arch/arm/mach-stm32/board-dt.c ++++ b/arch/arm/mach-stm32/board-dt.c +@@ -10,6 +10,7 @@ + + static const char *const stm32_compat[] __initconst = { + "st,stm32f429", ++ "st,stm32f469", + NULL + }; + +-- +1.9.1 +
board/stmicroelectronics/stm32f469-disco/patches/linux/0002-kernel-new-dts-file.patch new file +114 -0
114 lines not on this page · raw message
board/stmicroelectronics/stm32f469-disco/patches/linux/0003-kernel-config-frag-ram.patch new file +28 -0
@@ -0,0 +1,28 @@ +From 4cb65563325bee1886329b97ce3e2b0b90106bdd Mon Sep 17 00:00:00 2001 +From: Lee Jones <[email protected]> +Date: Tue, 16 Feb 2016 13:56:13 +0000 +Subject: [PATCH] ARM: configs: Add new config fragment to change RAM start + point + +Rather than duplicate a defconfig for each difference +between platforms, we can choose to pick a basic defconfig and +manipulate it at run-time using config fragments. Here we're +adding a new fragment to over-ride the RAM start point to 0x0. + +Cc: Arnd Bergmann <[email protected]> +Signed-off-by: Lee Jones <[email protected]> +--- + arch/arm/configs/dram_0x00000000.config | 1 + + 1 file changed, 1 insertion(+) + create mode 100644 arch/arm/configs/dram_0x00000000.config + +diff --git a/arch/arm/configs/dram_0x00000000.config b/arch/arm/configs/dram_0x00000000.config +new file mode 100644 +index 0000000..db96dcb +--- /dev/null ++++ b/arch/arm/configs/dram_0x00000000.config +@@ -0,0 +1 @@ ++CONFIG_DRAM_BASE=0x00000000 +-- +1.9.1 +
board/stmicroelectronics/stm32f469-disco/patches/openocd/0001-add-config.patch new file +37 -0
@@ -0,0 +1,37 @@ +From 26045588f462476cee356d15a24944d6c26befb4 Mon Sep 17 00:00:00 2001 +From: Maxime Coquelin <[email protected]> +Date: Sat, 24 Oct 2015 00:13:38 +0200 +Subject: [PATCH] tcl: add STM32F469 discovery board config + +Change-Id: Iad7ee06330b3259ea0ce0d174dfdade6785913eb +Signed-off-by: Maxime Coquelin <[email protected]> +Reviewed-on: http://openocd.zylin.com/3043 +Tested-by: jenkins +Reviewed-by: Antonio Borneo <[email protected]> +Reviewed-by: Freddie Chopin <[email protected]> +--- + tcl/board/stm32f469discovery.cfg | 12 ++++++++++++ + 1 file changed, 12 insertions(+) + create mode 100644 tcl/board/stm32f469discovery.cfg + +diff --git a/tcl/board/stm32f469discovery.cfg b/tcl/board/stm32f469discovery.cfg +new file mode 100644 +index 0000000..eecfe33 +--- /dev/null ++++ b/tcl/board/stm32f469discovery.cfg +@@ -0,0 +1,12 @@ ++# ++# This is an STM32F469 discovery board with a single STM32F469NI chip. ++# http://www.st.com/web/catalog/tools/FM116/CL1620/SC959/SS1532/LN1848/PF262395 ++# ++ ++source [find interface/stlink-v2-1.cfg] ++ ++transport select hla_swd ++ ++source [find target/stm32f4x.cfg] ++ ++reset_config srst_only +-- +1.9.1 +
board/stmicroelectronics/stm32f469-disco/patches/openocd/0002-flash-nor.patch new file +37 -0
@@ -0,0 +1,37 @@ +From 3e219648c80a27f0519003f3b088cbb846e255d8 Mon Sep 17 00:00:00 2001 +From: Maxime Coquelin <[email protected]> +Date: Sat, 24 Oct 2015 00:03:54 +0200 +Subject: [PATCH] flash/nor/stm32f2x: Add STM32F469 part + +Change-Id: I4e13ceb0ba954dc2fea059ddeef10109be938c9c +Signed-off-by: Maxime Coquelin <[email protected]> +Reviewed-on: http://openocd.zylin.com/3042 +Tested-by: jenkins +Reviewed-by: Freddie Chopin <[email protected]> +--- + src/flash/nor/stm32f2x.c | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/src/flash/nor/stm32f2x.c b/src/flash/nor/stm32f2x.c +index 2130444..89fc75d 100644 +--- a/src/flash/nor/stm32f2x.c ++++ b/src/flash/nor/stm32f2x.c +@@ -790,6 +790,7 @@ static int stm32x_probe(struct flash_bank *bank) + max_flash_size_in_kb = 1024; + break; + case 0x419: ++ case 0x434: + max_flash_size_in_kb = 2048; + break; + case 0x423: +@@ -952,6 +953,7 @@ static int get_stm32x_info(struct flash_bank *bank, char *buf, int buf_size) + + case 0x413: + case 0x419: ++ case 0x434: + device_str = "STM32F4xx"; + + switch (rev_id) { +-- +1.9.1 +
board/stmicroelectronics/stm32f469-disco/readme.txt new file +19 -0
@@ -0,0 +1,19 @@ +STM32F469 Discovery +=================== + +This tutorial describes how to use the predefined Buildroot +configuration for the STM32F469 Discovery evaluation platform. + +Building +-------- + + make stm32f469_disco_defconfig + make + +Flashing +-------- + + ./board/stmicroelectronics/stm32/stm32f469-disco/flash.sh output/ + +It will flash the minimal bootloader, the Device Tree Blob, and the +kernel image which includes the root filesystem as initramfs.
configs/stm32f469_disco_defconfig new file +19 -0
@@ -0,0 +1,19 @@ +BR2_arm=y +BR2_cortex_m4=y +BR2_GLOBAL_PATCH_DIR="board/stmicroelectronics/stm32f469-disco/patches/" +BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_4=y +BR2_ROOTFS_POST_BUILD_SCRIPT="board/stmicroelectronics/stm32-post-build.sh" +BR2_LINUX_KERNEL=y +BR2_LINUX_KERNEL_CUSTOM_VERSION=y +BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.4.5" +BR2_LINUX_KERNEL_DEFCONFIG="stm32" +BR2_LINUX_KERNEL_CONFIG_FRAGMENT_FILES="$(LINUX_DIR)/arch/arm/configs/dram_0x00000000.config" +BR2_LINUX_KERNEL_IMAGE_TARGET_CUSTOM=y +BR2_LINUX_KERNEL_IMAGE_TARGET_NAME="xipImage" +BR2_LINUX_KERNEL_DTS_SUPPORT=y +BR2_LINUX_KERNEL_INTREE_DTS_NAME="stm32f469-disco" +BR2_PACKAGE_BUSYBOX_CONFIG="board/stmicroelectronics/busybox-minimal.config" +BR2_TARGET_ROOTFS_INITRAMFS=y +# BR2_TARGET_ROOTFS_TAR is not set +BR2_TARGET_AFBOOT_STM32=y +BR2_PACKAGE_HOST_OPENOCD=y
Signature · 1 line
2.6.4