* [Buildroot] [PATCH 01/16] arch/arm: introduce and use BR2_ARM_CPU_ARMV7M
2016-03-16 21:43 [Buildroot] [PATCH 00/16] ARM Cortex-M support Thomas Petazzoni
@ 2016-03-16 21:43 ` Thomas Petazzoni
2016-03-16 22:29 ` Arnout Vandecappelle
2016-03-16 21:43 ` [Buildroot] [PATCH 02/16] arch/arm: Cortex-M3 provides only Thumb-2 Thomas Petazzoni
` (14 subsequent siblings)
15 siblings, 1 reply; 68+ messages in thread
From: Thomas Petazzoni @ 2016-03-16 21:43 UTC (permalink / raw)
To: buildroot
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.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
arch/Config.in.arm | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/Config.in.arm b/arch/Config.in.arm
index 04f0369..33f763a 100644
--- a/arch/Config.in.arm
+++ b/arch/Config.in.arm
@@ -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
--
2.6.4
^ permalink raw reply related [flat|nested] 68+ messages in thread* [Buildroot] [PATCH 01/16] arch/arm: introduce and use BR2_ARM_CPU_ARMV7M
2016-03-16 21:43 ` [Buildroot] [PATCH 01/16] arch/arm: introduce and use BR2_ARM_CPU_ARMV7M Thomas Petazzoni
@ 2016-03-16 22:29 ` Arnout Vandecappelle
0 siblings, 0 replies; 68+ messages in thread
From: Arnout Vandecappelle @ 2016-03-16 22:29 UTC (permalink / raw)
To: buildroot
On 03/16/16 22:43, Thomas Petazzoni wrote:
> 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.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Regards,
Arnout
> ---
> arch/Config.in.arm | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/Config.in.arm b/arch/Config.in.arm
> index 04f0369..33f763a 100644
> --- a/arch/Config.in.arm
> +++ b/arch/Config.in.arm
> @@ -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
>
--
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
^ permalink raw reply [flat|nested] 68+ messages in thread
* [Buildroot] [PATCH 02/16] arch/arm: Cortex-M3 provides only Thumb-2
2016-03-16 21:43 [Buildroot] [PATCH 00/16] ARM Cortex-M support Thomas Petazzoni
2016-03-16 21:43 ` [Buildroot] [PATCH 01/16] arch/arm: introduce and use BR2_ARM_CPU_ARMV7M Thomas Petazzoni
@ 2016-03-16 21:43 ` Thomas Petazzoni
2016-03-16 22:43 ` Arnout Vandecappelle
2016-03-16 21:43 ` [Buildroot] [PATCH 03/16] arch/arm: add Cortex-M4 entry Thomas Petazzoni
` (13 subsequent siblings)
15 siblings, 1 reply; 68+ messages in thread
From: Thomas Petazzoni @ 2016-03-16 21:43 UTC (permalink / raw)
To: buildroot
The 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.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
arch/Config.in.arm | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/Config.in.arm b/arch/Config.in.arm
index 33f763a..cd1ec33 100644
--- a/arch/Config.in.arm
+++ b/arch/Config.in.arm
@@ -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
--
2.6.4
^ permalink raw reply related [flat|nested] 68+ messages in thread* [Buildroot] [PATCH 02/16] arch/arm: Cortex-M3 provides only Thumb-2
2016-03-16 21:43 ` [Buildroot] [PATCH 02/16] arch/arm: Cortex-M3 provides only Thumb-2 Thomas Petazzoni
@ 2016-03-16 22:43 ` Arnout Vandecappelle
2016-03-17 8:03 ` Thomas Petazzoni
2016-03-17 20:36 ` Thomas Petazzoni
0 siblings, 2 replies; 68+ messages in thread
From: Arnout Vandecappelle @ 2016-03-16 22:43 UTC (permalink / raw)
To: buildroot
On 03/16/16 22:43, Thomas Petazzoni wrote:
> 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 select
CPU_HAS_THUMB. And according to [1], it really is a superset.
> 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.
> 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 <thomas.petazzoni@free-electrons.com>
> ---
> arch/Config.in.arm | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/Config.in.arm b/arch/Config.in.arm
> index 33f763a..cd1ec33 100644
> --- a/arch/Config.in.arm
> +++ b/arch/Config.in.arm
> @@ -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
> select 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
--
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
^ permalink raw reply [flat|nested] 68+ messages in thread
* [Buildroot] [PATCH 02/16] arch/arm: Cortex-M3 provides only Thumb-2
2016-03-16 22:43 ` Arnout Vandecappelle
@ 2016-03-17 8:03 ` Thomas Petazzoni
2016-03-17 11:08 ` Peter Korsgaard
2016-03-17 20:36 ` Thomas Petazzoni
1 sibling, 1 reply; 68+ messages in thread
From: Thomas Petazzoni @ 2016-03-17 8:03 UTC (permalink / raw)
To: buildroot
Hello,
On Wed, 16 Mar 2016 23:43:03 +0100, Arnout Vandecappelle wrote:
> If thumb2 is a superset of thumb, then CPU_HAS_THUMB2 should select
> CPU_HAS_THUMB. And according to [1], it really is a superset.
Right, this is a superset.
> > 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.
Indeed.
> > diff --git a/arch/Config.in.arm b/arch/Config.in.arm
> > index 33f763a..cd1ec33 100644
> > --- a/arch/Config.in.arm
> > +++ b/arch/Config.in.arm
> > @@ -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.
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
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 68+ messages in thread
* [Buildroot] [PATCH 02/16] arch/arm: Cortex-M3 provides only Thumb-2
2016-03-17 8:03 ` Thomas Petazzoni
@ 2016-03-17 11:08 ` Peter Korsgaard
2016-03-17 13:06 ` Thomas Petazzoni
0 siblings, 1 reply; 68+ messages in thread
From: Peter Korsgaard @ 2016-03-17 11:08 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Hi,
>> 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.
> 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.
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?
> 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).
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 68+ messages in thread
* [Buildroot] [PATCH 02/16] arch/arm: Cortex-M3 provides only Thumb-2
2016-03-17 11:08 ` Peter Korsgaard
@ 2016-03-17 13:06 ` Thomas Petazzoni
0 siblings, 0 replies; 68+ messages in thread
From: Thomas Petazzoni @ 2016-03-17 13:06 UTC (permalink / raw)
To: buildroot
Hello,
On Thu, 17 Mar 2016 12:08:36 +0100, Peter Korsgaard wrote:
> > 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.
>
> 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.
> Notice that we don't seem to do it for musl?
See patch 07/16.
> > 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).
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
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 68+ messages in thread
* [Buildroot] [PATCH 02/16] arch/arm: Cortex-M3 provides only Thumb-2
2016-03-16 22:43 ` Arnout Vandecappelle
2016-03-17 8:03 ` Thomas Petazzoni
@ 2016-03-17 20:36 ` Thomas Petazzoni
2016-03-17 22:34 ` Arnout Vandecappelle
1 sibling, 1 reply; 68+ messages in thread
From: Thomas Petazzoni @ 2016-03-17 20:36 UTC (permalink / raw)
To: buildroot
Hello,
On Wed, 16 Mar 2016 23:43:03 +0100, Arnout Vandecappelle wrote:
> On 03/16/16 22:43, Thomas Petazzoni wrote:
> > 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 select
> CPU_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
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 68+ messages in thread
* [Buildroot] [PATCH 02/16] arch/arm: Cortex-M3 provides only Thumb-2
2016-03-17 20:36 ` Thomas Petazzoni
@ 2016-03-17 22:34 ` Arnout Vandecappelle
0 siblings, 0 replies; 68+ messages in thread
From: Arnout Vandecappelle @ 2016-03-17 22:34 UTC (permalink / raw)
To: buildroot
On 03/17/16 21:36, Thomas Petazzoni wrote:
> Hello,
>
> On Wed, 16 Mar 2016 23:43:03 +0100, Arnout Vandecappelle wrote:
>> On 03/16/16 22:43, Thomas Petazzoni wrote:
>>> 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 select
>> CPU_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.
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
--
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
^ permalink raw reply [flat|nested] 68+ messages in thread
* [Buildroot] [PATCH 03/16] arch/arm: add Cortex-M4 entry
2016-03-16 21:43 [Buildroot] [PATCH 00/16] ARM Cortex-M support Thomas Petazzoni
2016-03-16 21:43 ` [Buildroot] [PATCH 01/16] arch/arm: introduce and use BR2_ARM_CPU_ARMV7M Thomas Petazzoni
2016-03-16 21:43 ` [Buildroot] [PATCH 02/16] arch/arm: Cortex-M3 provides only Thumb-2 Thomas Petazzoni
@ 2016-03-16 21:43 ` Thomas Petazzoni
2016-03-16 22:50 ` Arnout Vandecappelle
2016-03-16 21:43 ` [Buildroot] [PATCH 04/16] uclibc: Enable compile in thumb mode when selected Thomas Petazzoni
` (12 subsequent siblings)
15 siblings, 1 reply; 68+ messages in thread
From: Thomas Petazzoni @ 2016-03-16 21:43 UTC (permalink / raw)
To: buildroot
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 <thomas.petazzoni@free-electrons.com>
---
arch/Config.in.arm | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/Config.in.arm b/arch/Config.in.arm
index cd1ec33..ee612f5 100644
--- a/arch/Config.in.arm
+++ b/arch/Config.in.arm
@@ -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
--
2.6.4
^ permalink raw reply related [flat|nested] 68+ messages in thread* [Buildroot] [PATCH 03/16] arch/arm: add Cortex-M4 entry
2016-03-16 21:43 ` [Buildroot] [PATCH 03/16] arch/arm: add Cortex-M4 entry Thomas Petazzoni
@ 2016-03-16 22:50 ` Arnout Vandecappelle
0 siblings, 0 replies; 68+ messages in thread
From: Arnout Vandecappelle @ 2016-03-16 22:50 UTC (permalink / raw)
To: buildroot
On 03/16/16 22:43, Thomas Petazzoni wrote:
> 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 <thomas.petazzoni@free-electrons.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Regards,
Arnout
> ---
> arch/Config.in.arm | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/Config.in.arm b/arch/Config.in.arm
> index cd1ec33..ee612f5 100644
> --- a/arch/Config.in.arm
> +++ b/arch/Config.in.arm
> @@ -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
>
--
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
^ permalink raw reply [flat|nested] 68+ messages in thread
* [Buildroot] [PATCH 04/16] uclibc: Enable compile in thumb mode when selected
2016-03-16 21:43 [Buildroot] [PATCH 00/16] ARM Cortex-M support Thomas Petazzoni
` (2 preceding siblings ...)
2016-03-16 21:43 ` [Buildroot] [PATCH 03/16] arch/arm: add Cortex-M4 entry Thomas Petazzoni
@ 2016-03-16 21:43 ` Thomas Petazzoni
2016-03-16 23:01 ` Arnout Vandecappelle
2016-03-17 11:21 ` Peter Korsgaard
2016-03-16 21:43 ` [Buildroot] [PATCH 05/16] uclibc: disable DOPIC on ARM noMMU Thomas Petazzoni
` (11 subsequent siblings)
15 siblings, 2 replies; 68+ messages in thread
From: Thomas Petazzoni @ 2016-03-16 21:43 UTC (permalink / raw)
To: buildroot
From: Paul Enman <paul.enman@gmail.com>
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.
Signed-off-by: Paul Enman <paul.enman@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
package/uclibc/uclibc.mk | 19 +++++++++++++++++--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/package/uclibc/uclibc.mk b/package/uclibc/uclibc.mk
index 88a4a8c..ce706e0 100644
--- a/package/uclibc/uclibc.mk
+++ b/package/uclibc/uclibc.mk
@@ -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)
--
2.6.4
^ permalink raw reply related [flat|nested] 68+ messages in thread* [Buildroot] [PATCH 04/16] uclibc: Enable compile in thumb mode when selected
2016-03-16 21:43 ` [Buildroot] [PATCH 04/16] uclibc: Enable compile in thumb mode when selected Thomas Petazzoni
@ 2016-03-16 23:01 ` Arnout Vandecappelle
2016-03-17 11:21 ` Peter Korsgaard
1 sibling, 0 replies; 68+ messages in thread
From: Arnout Vandecappelle @ 2016-03-16 23:01 UTC (permalink / raw)
To: buildroot
On 03/16/16 22:43, Thomas Petazzoni wrote:
> From: Paul Enman <paul.enman@gmail.com>
>
> 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.
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.
>
> Signed-off-by: Paul Enman <paul.enman@gmail.com>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
> package/uclibc/uclibc.mk | 19 +++++++++++++++++--
> 1 file changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/package/uclibc/uclibc.mk b/package/uclibc/uclibc.mk
> index 88a4a8c..ce706e0 100644
> --- a/package/uclibc/uclibc.mk
> +++ b/package/uclibc/uclibc.mk
> @@ -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
> 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)
>
--
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
^ permalink raw reply [flat|nested] 68+ messages in thread
* [Buildroot] [PATCH 04/16] uclibc: Enable compile in thumb mode when selected
2016-03-16 21:43 ` [Buildroot] [PATCH 04/16] uclibc: Enable compile in thumb mode when selected Thomas Petazzoni
2016-03-16 23:01 ` Arnout Vandecappelle
@ 2016-03-17 11:21 ` Peter Korsgaard
2016-03-17 13:10 ` Thomas Petazzoni
2016-03-17 21:25 ` Thomas Petazzoni
1 sibling, 2 replies; 68+ messages in thread
From: Peter Korsgaard @ 2016-03-17 11:21 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
> From: Paul Enman <paul.enman@gmail.com>
> 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.
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 ;)
> - Disable COMPILE_IN_THUMB_MODE explicitly otherwise.
> This allows to build a Thumb2 toolchain on ARMv7-M for example.
What wasn't working before?
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 68+ messages in thread
* [Buildroot] [PATCH 04/16] uclibc: Enable compile in thumb mode when selected
2016-03-17 11:21 ` Peter Korsgaard
@ 2016-03-17 13:10 ` Thomas Petazzoni
2016-03-17 21:25 ` Thomas Petazzoni
1 sibling, 0 replies; 68+ messages in thread
From: Thomas Petazzoni @ 2016-03-17 13:10 UTC (permalink / raw)
To: buildroot
Hello,
On Thu, 17 Mar 2016 12:21:55 +0100, Peter Korsgaard wrote:
> > - 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.
>
> 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.
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.
> Luckily Yann is the author of this logic in uClibc, so lets ask him ;)
>
> > - Disable COMPILE_IN_THUMB_MODE explicitly 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
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 68+ messages in thread
* [Buildroot] [PATCH 04/16] uclibc: Enable compile in thumb mode when selected
2016-03-17 11:21 ` Peter Korsgaard
2016-03-17 13:10 ` Thomas Petazzoni
@ 2016-03-17 21:25 ` Thomas Petazzoni
2016-03-17 21:44 ` Peter Korsgaard
1 sibling, 1 reply; 68+ messages in thread
From: Thomas Petazzoni @ 2016-03-17 21:25 UTC (permalink / raw)
To: buildroot
Hello,
On Thu, 17 Mar 2016 12:21:55 +0100, Peter Korsgaard wrote:
> > - 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.
>
> 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
> 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 ?
> Luckily Yann is the author of this logic in uClibc, so lets ask him ;)
>
> > - Disable COMPILE_IN_THUMB_MODE explicitly 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
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 68+ messages in thread* [Buildroot] [PATCH 04/16] uclibc: Enable compile in thumb mode when selected
2016-03-17 21:25 ` Thomas Petazzoni
@ 2016-03-17 21:44 ` Peter Korsgaard
2016-03-17 22:03 ` Thomas Petazzoni
0 siblings, 1 reply; 68+ messages in thread
From: Peter Korsgaard @ 2016-03-17 21:44 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
> Hello,
> On Thu, 17 Mar 2016 12:21:55 +0100, Peter Korsgaard wrote:
>> > - 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.
>>
>> 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:
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.
> 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:
Ahh yes, true.
> So I think we should:
> 1/ Enable COMPILE_IN_THUMB_MODE whenever ARM_INSTRUCTIONS_THUMB(2) is
> enabled.
Ok.
> 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.
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.
--
Venlig hilsen,
Peter Korsgaard
^ permalink raw reply [flat|nested] 68+ messages in thread
* [Buildroot] [PATCH 04/16] uclibc: Enable compile in thumb mode when selected
2016-03-17 21:44 ` Peter Korsgaard
@ 2016-03-17 22:03 ` Thomas Petazzoni
2016-03-17 22:18 ` Peter Korsgaard
0 siblings, 1 reply; 68+ messages in thread
From: Thomas Petazzoni @ 2016-03-17 22:03 UTC (permalink / raw)
To: buildroot
Hello,
On Thu, 17 Mar 2016 22:44:16 +0100, Peter Korsgaard wrote:
> > 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:
>
> 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.
> 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).
> > So I think we should:
>
> > 1/ Enable COMPILE_IN_THUMB_MODE whenever ARM_INSTRUCTIONS_THUMB(2) is
> > enabled.
>
> Ok.
>
> > 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.
>
> 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.
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
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 68+ messages in thread
* [Buildroot] [PATCH 04/16] uclibc: Enable compile in thumb mode when selected
2016-03-17 22:03 ` Thomas Petazzoni
@ 2016-03-17 22:18 ` Peter Korsgaard
0 siblings, 0 replies; 68+ messages in thread
From: Peter Korsgaard @ 2016-03-17 22:18 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Hi,
>> 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.
>> 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 :/
>> 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.
> USE_LDREXSTREX depends on COMPILE_IN_THUMB_MODE, so you can't have
> USE_LDREXSTREX without having COMPILE_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.
> 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.
Thanks, it imho looks sensible.
> 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.
--
Venlig hilsen,
Peter Korsgaard
^ permalink raw reply [flat|nested] 68+ messages in thread
* [Buildroot] [PATCH 05/16] uclibc: disable DOPIC on ARM noMMU
2016-03-16 21:43 [Buildroot] [PATCH 00/16] ARM Cortex-M support Thomas Petazzoni
` (3 preceding siblings ...)
2016-03-16 21:43 ` [Buildroot] [PATCH 04/16] uclibc: Enable compile in thumb mode when selected Thomas Petazzoni
@ 2016-03-16 21:43 ` Thomas Petazzoni
2016-03-16 23:09 ` Arnout Vandecappelle
2016-03-16 21:43 ` [Buildroot] [PATCH 06/16] uclibc: NPTL thread implementation only available on MMU platforms Thomas Petazzoni
` (10 subsequent siblings)
15 siblings, 1 reply; 68+ messages in thread
From: Thomas Petazzoni @ 2016-03-16 21:43 UTC (permalink / raw)
To: buildroot
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
input, so we must disable DOPIC in the uClibc configuration.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
package/uclibc/uclibc.mk | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/package/uclibc/uclibc.mk b/package/uclibc/uclibc.mk
index ce706e0..d11c103 100644
--- a/package/uclibc/uclibc.mk
+++ b/package/uclibc/uclibc.mk
@@ -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)
--
2.6.4
^ permalink raw reply related [flat|nested] 68+ messages in thread* [Buildroot] [PATCH 05/16] uclibc: disable DOPIC on ARM noMMU
2016-03-16 21:43 ` [Buildroot] [PATCH 05/16] uclibc: disable DOPIC on ARM noMMU Thomas Petazzoni
@ 2016-03-16 23:09 ` Arnout Vandecappelle
2016-03-17 8:06 ` Thomas Petazzoni
0 siblings, 1 reply; 68+ messages in thread
From: Arnout Vandecappelle @ 2016-03-16 23:09 UTC (permalink / raw)
To: buildroot
On 03/16/16 22:43, Thomas Petazzoni wrote:
> 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
> input, so we must disable DOPIC in the uClibc configuration.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
> package/uclibc/uclibc.mk | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/package/uclibc/uclibc.mk b/package/uclibc/uclibc.mk
> index ce706e0..d11c103 100644
> --- a/package/uclibc/uclibc.mk
> +++ b/package/uclibc/uclibc.mk
> @@ -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
> +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)
>
--
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
^ permalink raw reply [flat|nested] 68+ messages in thread* [Buildroot] [PATCH 05/16] uclibc: disable DOPIC on ARM noMMU
2016-03-16 23:09 ` Arnout Vandecappelle
@ 2016-03-17 8:06 ` Thomas Petazzoni
2016-03-17 10:32 ` Max Filippov
0 siblings, 1 reply; 68+ messages in thread
From: Thomas Petazzoni @ 2016-03-17 8:06 UTC (permalink / raw)
To: buildroot
Hello,
On Thu, 17 Mar 2016 00:09:05 +0100, Arnout Vandecappelle wrote:
> > +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.
> 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
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 68+ messages in thread
* [Buildroot] [PATCH 05/16] uclibc: disable DOPIC on ARM noMMU
2016-03-17 8:06 ` Thomas Petazzoni
@ 2016-03-17 10:32 ` Max Filippov
2016-03-17 11:00 ` Thomas Petazzoni
0 siblings, 1 reply; 68+ messages in thread
From: Max Filippov @ 2016-03-17 10:32 UTC (permalink / raw)
To: buildroot
On Thu, Mar 17, 2016 at 11:06 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Thu, 17 Mar 2016 00:09:05 +0100, Arnout Vandecappelle wrote:
>
>> > +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.
>
>> 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.
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.
--
Thanks.
-- Max
^ permalink raw reply [flat|nested] 68+ messages in thread
* [Buildroot] [PATCH 05/16] uclibc: disable DOPIC on ARM noMMU
2016-03-17 10:32 ` Max Filippov
@ 2016-03-17 11:00 ` Thomas Petazzoni
2016-03-17 11:39 ` Max Filippov
0 siblings, 1 reply; 68+ messages in thread
From: Thomas Petazzoni @ 2016-03-17 11:00 UTC (permalink / raw)
To: buildroot
Hello,
On Thu, 17 Mar 2016 13:32:46 +0300, Max Filippov wrote:
> > 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.
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
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 68+ messages in thread
* [Buildroot] [PATCH 05/16] uclibc: disable DOPIC on ARM noMMU
2016-03-17 11:00 ` Thomas Petazzoni
@ 2016-03-17 11:39 ` Max Filippov
0 siblings, 0 replies; 68+ messages in thread
From: Max Filippov @ 2016-03-17 11:39 UTC (permalink / raw)
To: buildroot
On Thu, Mar 17, 2016 at 2:00 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Thu, 17 Mar 2016 13:32:46 +0300, Max Filippov wrote:
>
>> > 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.
>
> 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.
--
Thanks.
-- Max
^ permalink raw reply [flat|nested] 68+ messages in thread
* [Buildroot] [PATCH 06/16] uclibc: NPTL thread implementation only available on MMU platforms
2016-03-16 21:43 [Buildroot] [PATCH 00/16] ARM Cortex-M support Thomas Petazzoni
` (4 preceding siblings ...)
2016-03-16 21:43 ` [Buildroot] [PATCH 05/16] uclibc: disable DOPIC on ARM noMMU Thomas Petazzoni
@ 2016-03-16 21:43 ` Thomas Petazzoni
2016-03-16 23:11 ` Arnout Vandecappelle
2016-03-17 12:14 ` Peter Korsgaard
2016-03-16 21:43 ` [Buildroot] [PATCH 07/16] musl: build broken on Thumb, use ARM mode Thomas Petazzoni
` (9 subsequent siblings)
15 siblings, 2 replies; 68+ messages in thread
From: Thomas Petazzoni @ 2016-03-16 21:43 UTC (permalink / raw)
To: buildroot
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 <thomas.petazzoni@free-electrons.com>
---
package/uclibc/Config.in | 2 ++
1 file changed, 2 insertions(+)
diff --git a/package/uclibc/Config.in b/package/uclibc/Config.in
index 16bf89c..8be99f8 100644
--- a/package/uclibc/Config.in
+++ b/package/uclibc/Config.in
@@ -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
--
2.6.4
^ permalink raw reply related [flat|nested] 68+ messages in thread* [Buildroot] [PATCH 06/16] uclibc: NPTL thread implementation only available on MMU platforms
2016-03-16 21:43 ` [Buildroot] [PATCH 06/16] uclibc: NPTL thread implementation only available on MMU platforms Thomas Petazzoni
@ 2016-03-16 23:11 ` Arnout Vandecappelle
2016-03-17 12:14 ` Peter Korsgaard
1 sibling, 0 replies; 68+ messages in thread
From: Arnout Vandecappelle @ 2016-03-16 23:11 UTC (permalink / raw)
To: buildroot
On 03/16/16 22:43, Thomas Petazzoni wrote:
> 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 <thomas.petazzoni@free-electrons.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Regards,
Arnout
> ---
> package/uclibc/Config.in | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/package/uclibc/Config.in b/package/uclibc/Config.in
> index 16bf89c..8be99f8 100644
> --- a/package/uclibc/Config.in
> +++ b/package/uclibc/Config.in
> @@ -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
>
>
--
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
^ permalink raw reply [flat|nested] 68+ messages in thread
* [Buildroot] [PATCH 06/16] uclibc: NPTL thread implementation only available on MMU platforms
2016-03-16 21:43 ` [Buildroot] [PATCH 06/16] uclibc: NPTL thread implementation only available on MMU platforms Thomas Petazzoni
2016-03-16 23:11 ` Arnout Vandecappelle
@ 2016-03-17 12:14 ` Peter Korsgaard
2016-03-17 13:11 ` Thomas Petazzoni
1 sibling, 1 reply; 68+ messages in thread
From: Peter Korsgaard @ 2016-03-17 12:14 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> 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 <thomas.petazzoni@free-electrons.com>
> ---
> package/uclibc/Config.in | 2 ++
> 1 file changed, 2 insertions(+)
> diff --git a/package/uclibc/Config.in b/package/uclibc/Config.in
> index 16bf89c..8be99f8 100644
> --- a/package/uclibc/Config.in
> +++ b/package/uclibc/Config.in
> @@ -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
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 <jacmet@sunsite.dk>
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.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 68+ messages in thread* [Buildroot] [PATCH 06/16] uclibc: NPTL thread implementation only available on MMU platforms
2016-03-17 12:14 ` Peter Korsgaard
@ 2016-03-17 13:11 ` Thomas Petazzoni
2016-03-17 19:45 ` Waldemar Brodkorb
0 siblings, 1 reply; 68+ messages in thread
From: Thomas Petazzoni @ 2016-03-17 13:11 UTC (permalink / raw)
To: buildroot
Hello,
On Thu, 17 Mar 2016 13:14:27 +0100, Peter Korsgaard wrote:
> 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 <jacmet@sunsite.dk>
> 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.
Let's Cc: Waldemar on this, I believe he has done some work on m68k for
uClibc-ng.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 68+ messages in thread
* [Buildroot] [PATCH 06/16] uclibc: NPTL thread implementation only available on MMU platforms
2016-03-17 13:11 ` Thomas Petazzoni
@ 2016-03-17 19:45 ` Waldemar Brodkorb
2016-03-17 20:08 ` Peter Korsgaard
0 siblings, 1 reply; 68+ messages in thread
From: Waldemar Brodkorb @ 2016-03-17 19:45 UTC (permalink / raw)
To: buildroot
Hi,
Thomas Petazzoni wrote,
> Hello,
>
> On Thu, 17 Mar 2016 13:14:27 +0100, Peter Korsgaard wrote:
>
> > 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 <jacmet@sunsite.dk>
> > 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.
>
> 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
^ permalink raw reply [flat|nested] 68+ messages in thread
* [Buildroot] [PATCH 06/16] uclibc: NPTL thread implementation only available on MMU platforms
2016-03-17 19:45 ` Waldemar Brodkorb
@ 2016-03-17 20:08 ` Peter Korsgaard
0 siblings, 0 replies; 68+ messages in thread
From: Peter Korsgaard @ 2016-03-17 20:08 UTC (permalink / raw)
To: buildroot
>>>>> "Waldemar" == Waldemar Brodkorb <wbx@openadk.org> writes:
Hi,
> 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.
--
Venlig hilsen,
Peter Korsgaard
^ permalink raw reply [flat|nested] 68+ messages in thread
* [Buildroot] [PATCH 07/16] musl: build broken on Thumb, use ARM mode
2016-03-16 21:43 [Buildroot] [PATCH 00/16] ARM Cortex-M support Thomas Petazzoni
` (5 preceding siblings ...)
2016-03-16 21:43 ` [Buildroot] [PATCH 06/16] uclibc: NPTL thread implementation only available on MMU platforms Thomas Petazzoni
@ 2016-03-16 21:43 ` Thomas Petazzoni
2016-03-16 23:14 ` Arnout Vandecappelle
2016-03-16 21:43 ` [Buildroot] [PATCH 08/16] toolchain-buildroot: update glibc comment for noMMU Thomas Petazzoni
` (8 subsequent siblings)
15 siblings, 1 reply; 68+ messages in thread
From: Thomas Petazzoni @ 2016-03-16 21:43 UTC (permalink / raw)
To: buildroot
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 <thomas.petazzoni@free-electrons.com>
---
package/musl/musl.mk | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/package/musl/musl.mk b/package/musl/musl.mk
index 081a700..0e881f9 100644
--- a/package/musl/musl.mk
+++ b/package/musl/musl.mk
@@ -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) \
--
2.6.4
^ permalink raw reply related [flat|nested] 68+ messages in thread* [Buildroot] [PATCH 07/16] musl: build broken on Thumb, use ARM mode
2016-03-16 21:43 ` [Buildroot] [PATCH 07/16] musl: build broken on Thumb, use ARM mode Thomas Petazzoni
@ 2016-03-16 23:14 ` Arnout Vandecappelle
2016-03-17 8:10 ` Thomas Petazzoni
0 siblings, 1 reply; 68+ messages in thread
From: Arnout Vandecappelle @ 2016-03-16 23:14 UTC (permalink / raw)
To: buildroot
On 03/16/16 22:43, Thomas Petazzoni wrote:
> 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 <thomas.petazzoni@free-electrons.com>
> ---
> package/musl/musl.mk | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/package/musl/musl.mk b/package/musl/musl.mk
> index 081a700..0e881f9 100644
> --- a/package/musl/musl.mk
> +++ b/package/musl/musl.mk
> @@ -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.
> +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
> +MUSL_EXTRA_CFLAGS += -marm
> +endif
> +
> define MUSL_CONFIGURE_CMDS
> (cd $(@D); \
> $(TARGET_CONFIGURE_OPTS) \
>
--
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
^ permalink raw reply [flat|nested] 68+ messages in thread* [Buildroot] [PATCH 07/16] musl: build broken on Thumb, use ARM mode
2016-03-16 23:14 ` Arnout Vandecappelle
@ 2016-03-17 8:10 ` Thomas Petazzoni
0 siblings, 0 replies; 68+ messages in thread
From: Thomas Petazzoni @ 2016-03-17 8:10 UTC (permalink / raw)
To: buildroot
Hello,
On Thu, 17 Mar 2016 00:14:01 +0100, Arnout Vandecappelle wrote:
> > +# Thumb build is broken, build in ARM mode
>
> The comment about all our thumb1 architectures supporting arm mode should be
> repeated here IMHO.
>
> > +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.
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
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 68+ messages in thread
* [Buildroot] [PATCH 08/16] toolchain-buildroot: update glibc comment for noMMU
2016-03-16 21:43 [Buildroot] [PATCH 00/16] ARM Cortex-M support Thomas Petazzoni
` (6 preceding siblings ...)
2016-03-16 21:43 ` [Buildroot] [PATCH 07/16] musl: build broken on Thumb, use ARM mode Thomas Petazzoni
@ 2016-03-16 21:43 ` Thomas Petazzoni
2016-03-16 23:18 ` Arnout Vandecappelle
2016-03-16 21:43 ` [Buildroot] [PATCH 09/16] toolchain-buildroot: don't show musl on noMMU platforms Thomas Petazzoni
` (7 subsequent siblings)
15 siblings, 1 reply; 68+ messages in thread
From: Thomas Petazzoni @ 2016-03-16 21:43 UTC (permalink / raw)
To: buildroot
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 <thomas.petazzoni@free-electrons.com>
---
toolchain/toolchain-buildroot/Config.in | 1 +
1 file changed, 1 insertion(+)
diff --git a/toolchain/toolchain-buildroot/Config.in b/toolchain/toolchain-buildroot/Config.in
index cb4fc18..ea290eb 100644
--- a/toolchain/toolchain-buildroot/Config.in
+++ b/toolchain/toolchain-buildroot/Config.in
@@ -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
--
2.6.4
^ permalink raw reply related [flat|nested] 68+ messages in thread* [Buildroot] [PATCH 08/16] toolchain-buildroot: update glibc comment for noMMU
2016-03-16 21:43 ` [Buildroot] [PATCH 08/16] toolchain-buildroot: update glibc comment for noMMU Thomas Petazzoni
@ 2016-03-16 23:18 ` Arnout Vandecappelle
2016-03-18 20:49 ` Thomas Petazzoni
0 siblings, 1 reply; 68+ messages in thread
From: Arnout Vandecappelle @ 2016-03-16 23:18 UTC (permalink / raw)
To: buildroot
On 03/16/16 22:43, Thomas Petazzoni wrote:
> 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 <thomas.petazzoni@free-electrons.com>
> ---
> toolchain/toolchain-buildroot/Config.in | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/toolchain/toolchain-buildroot/Config.in b/toolchain/toolchain-buildroot/Config.in
> index cb4fc18..ea290eb 100644
> --- a/toolchain/toolchain-buildroot/Config.in
> +++ b/toolchain/toolchain-buildroot/Config.in
> @@ -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
> depends on BR2_STATIC_LIBS
>
> config BR2_TOOLCHAIN_BUILDROOT_MUSL
>
--
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
^ permalink raw reply [flat|nested] 68+ messages in thread
* [Buildroot] [PATCH 08/16] toolchain-buildroot: update glibc comment for noMMU
2016-03-16 23:18 ` Arnout Vandecappelle
@ 2016-03-18 20:49 ` Thomas Petazzoni
2016-03-18 20:59 ` Peter Korsgaard
2016-03-18 21:33 ` Arnout Vandecappelle
0 siblings, 2 replies; 68+ messages in thread
From: Thomas Petazzoni @ 2016-03-18 20:49 UTC (permalink / raw)
To: buildroot
Hello,
On Thu, 17 Mar 2016 00:18:21 +0100, Arnout Vandecappelle wrote:
> > 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.
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
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 68+ messages in thread
* [Buildroot] [PATCH 08/16] toolchain-buildroot: update glibc comment for noMMU
2016-03-18 20:49 ` Thomas Petazzoni
@ 2016-03-18 20:59 ` Peter Korsgaard
2016-03-18 21:33 ` Arnout Vandecappelle
1 sibling, 0 replies; 68+ messages in thread
From: Peter Korsgaard @ 2016-03-18 20:59 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Hi,
> 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?
Yes, lets please handle that seperately from this.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 68+ messages in thread
* [Buildroot] [PATCH 08/16] toolchain-buildroot: update glibc comment for noMMU
2016-03-18 20:49 ` Thomas Petazzoni
2016-03-18 20:59 ` Peter Korsgaard
@ 2016-03-18 21:33 ` Arnout Vandecappelle
1 sibling, 0 replies; 68+ messages in thread
From: Arnout Vandecappelle @ 2016-03-18 21:33 UTC (permalink / raw)
To: buildroot
On 03/18/16 21:49, Thomas Petazzoni wrote:
> Hello,
>
> On Thu, 17 Mar 2016 00:18:21 +0100, Arnout Vandecappelle wrote:
>
>>> 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.
>
> 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
>
> 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
>
--
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
^ permalink raw reply [flat|nested] 68+ messages in thread
* [Buildroot] [PATCH 09/16] toolchain-buildroot: don't show musl on noMMU platforms
2016-03-16 21:43 [Buildroot] [PATCH 00/16] ARM Cortex-M support Thomas Petazzoni
` (7 preceding siblings ...)
2016-03-16 21:43 ` [Buildroot] [PATCH 08/16] toolchain-buildroot: update glibc comment for noMMU Thomas Petazzoni
@ 2016-03-16 21:43 ` Thomas Petazzoni
2016-03-16 23:26 ` Arnout Vandecappelle
2016-03-16 21:43 ` [Buildroot] [PATCH 10/16] arch/arm: add support for hard-float on Cortex-M4 Thomas Petazzoni
` (6 subsequent siblings)
15 siblings, 1 reply; 68+ messages in thread
From: Thomas Petazzoni @ 2016-03-16 21:43 UTC (permalink / raw)
To: buildroot
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 <thomas.petazzoni@free-electrons.com>
---
toolchain/toolchain-buildroot/Config.in | 3 +++
1 file changed, 3 insertions(+)
diff --git a/toolchain/toolchain-buildroot/Config.in b/toolchain/toolchain-buildroot/Config.in
index ea290eb..1fba06b 100644
--- a/toolchain/toolchain-buildroot/Config.in
+++ b/toolchain/toolchain-buildroot/Config.in
@@ -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
--
2.6.4
^ permalink raw reply related [flat|nested] 68+ messages in thread* [Buildroot] [PATCH 09/16] toolchain-buildroot: don't show musl on noMMU platforms
2016-03-16 21:43 ` [Buildroot] [PATCH 09/16] toolchain-buildroot: don't show musl on noMMU platforms Thomas Petazzoni
@ 2016-03-16 23:26 ` Arnout Vandecappelle
2016-03-18 20:51 ` Thomas Petazzoni
0 siblings, 1 reply; 68+ messages in thread
From: Arnout Vandecappelle @ 2016-03-16 23:26 UTC (permalink / raw)
To: buildroot
On 03/16/16 22:43, Thomas Petazzoni wrote:
> 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 <thomas.petazzoni@free-electrons.com>
> ---
> toolchain/toolchain-buildroot/Config.in | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/toolchain/toolchain-buildroot/Config.in b/toolchain/toolchain-buildroot/Config.in
> index ea290eb..1fba06b 100644
> --- a/toolchain/toolchain-buildroot/Config.in
> +++ b/toolchain/toolchain-buildroot/Config.in
> @@ -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:
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Regards,
Arnout
> + depends on BR2_USE_MMU
> select BR2_TOOLCHAIN_USES_MUSL
> help
> This option selects musl as the C library for the
>
--
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
^ permalink raw reply [flat|nested] 68+ messages in thread
* [Buildroot] [PATCH 09/16] toolchain-buildroot: don't show musl on noMMU platforms
2016-03-16 23:26 ` Arnout Vandecappelle
@ 2016-03-18 20:51 ` Thomas Petazzoni
2016-03-18 21:42 ` Arnout Vandecappelle
0 siblings, 1 reply; 68+ messages in thread
From: Thomas Petazzoni @ 2016-03-18 20:51 UTC (permalink / raw)
To: buildroot
Dear Arnout Vandecappelle,
On Thu, 17 Mar 2016 00:26:38 +0100, Arnout Vandecappelle wrote:
> On 03/16/16 22:43, Thomas Petazzoni wrote:
> > 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 <thomas.petazzoni@free-electrons.com>
> > ---
> > toolchain/toolchain-buildroot/Config.in | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/toolchain/toolchain-buildroot/Config.in b/toolchain/toolchain-buildroot/Config.in
> > index ea290eb..1fba06b 100644
> > --- a/toolchain/toolchain-buildroot/Config.in
> > +++ b/toolchain/toolchain-buildroot/Config.in
> > @@ -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
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 68+ messages in thread
* [Buildroot] [PATCH 09/16] toolchain-buildroot: don't show musl on noMMU platforms
2016-03-18 20:51 ` Thomas Petazzoni
@ 2016-03-18 21:42 ` Arnout Vandecappelle
0 siblings, 0 replies; 68+ messages in thread
From: Arnout Vandecappelle @ 2016-03-18 21:42 UTC (permalink / raw)
To: buildroot
On 03/18/16 21:51, Thomas Petazzoni wrote:
> Dear Arnout Vandecappelle,
>
> On Thu, 17 Mar 2016 00:26:38 +0100, Arnout Vandecappelle wrote:
>> On 03/16/16 22:43, Thomas Petazzoni wrote:
>>> 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 <thomas.petazzoni@free-electrons.com>
>>> ---
>>> toolchain/toolchain-buildroot/Config.in | 3 +++
>>> 1 file changed, 3 insertions(+)
>>>
>>> diff --git a/toolchain/toolchain-buildroot/Config.in b/toolchain/toolchain-buildroot/Config.in
>>> index ea290eb..1fba06b 100644
>>> --- a/toolchain/toolchain-buildroot/Config.in
>>> +++ b/toolchain/toolchain-buildroot/Config.in
>>> @@ -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.
Sorry, I thought that sh2a was a distinct architecture from sh2. Never mind then.
My Rev-by is already there.
Regards,
Arnout
>
> Thomas
>
--
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
^ permalink raw reply [flat|nested] 68+ messages in thread
* [Buildroot] [PATCH 10/16] arch/arm: add support for hard-float on Cortex-M4
2016-03-16 21:43 [Buildroot] [PATCH 00/16] ARM Cortex-M support Thomas Petazzoni
` (8 preceding siblings ...)
2016-03-16 21:43 ` [Buildroot] [PATCH 09/16] toolchain-buildroot: don't show musl on noMMU platforms Thomas Petazzoni
@ 2016-03-16 21:43 ` Thomas Petazzoni
2016-03-16 23:45 ` Arnout Vandecappelle
2016-03-16 21:43 ` [Buildroot] [PATCH 11/16] package/Makefile.in: adjust LDFLAGS for elf2flt Thomas Petazzoni
` (5 subsequent siblings)
15 siblings, 1 reply; 68+ messages in thread
From: Thomas Petazzoni @ 2016-03-16 21:43 UTC (permalink / raw)
To: buildroot
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_VFP support for
ARMv7-M, so in practice, this VFP support cannot really be used for
the moment.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
arch/Config.in.arm | 23 +++++++++++++++++++++--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/arch/Config.in.arm b/arch/Config.in.arm
index ee612f5..ad3c725 100644
--- a/arch/Config.in.arm
+++ b/arch/Config.in.arm
@@ -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
--
2.6.4
^ permalink raw reply related [flat|nested] 68+ messages in thread* [Buildroot] [PATCH 10/16] arch/arm: add support for hard-float on Cortex-M4
2016-03-16 21:43 ` [Buildroot] [PATCH 10/16] arch/arm: add support for hard-float on Cortex-M4 Thomas Petazzoni
@ 2016-03-16 23:45 ` Arnout Vandecappelle
2016-03-17 8:16 ` Thomas Petazzoni
0 siblings, 1 reply; 68+ messages in thread
From: Arnout Vandecappelle @ 2016-03-16 23:45 UTC (permalink / raw)
To: buildroot
On 03/16/16 22:43, Thomas Petazzoni wrote:
> 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_VFP support 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...
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
> arch/Config.in.arm | 23 +++++++++++++++++++++--
> 1 file changed, 21 insertions(+), 2 deletions(-)
>
> diff --git a/arch/Config.in.arm b/arch/Config.in.arm
> index ee612f5..ad3c725 100644
> --- a/arch/Config.in.arm
> +++ b/arch/Config.in.arm
> @@ -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?
> + 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"
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
> - 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
>
>
--
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
^ permalink raw reply [flat|nested] 68+ messages in thread* [Buildroot] [PATCH 10/16] arch/arm: add support for hard-float on Cortex-M4
2016-03-16 23:45 ` Arnout Vandecappelle
@ 2016-03-17 8:16 ` Thomas Petazzoni
2016-03-18 21:47 ` Arnout Vandecappelle
0 siblings, 1 reply; 68+ messages in thread
From: Thomas Petazzoni @ 2016-03-17 8:16 UTC (permalink / raw)
To: buildroot
Hello,
On Thu, 17 Mar 2016 00:45:19 +0100, Arnout Vandecappelle wrote:
> On 03/16/16 22:43, Thomas Petazzoni wrote:
> > 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_VFP support 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.
> 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.
> > 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 :-)
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
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 68+ messages in thread
* [Buildroot] [PATCH 10/16] arch/arm: add support for hard-float on Cortex-M4
2016-03-17 8:16 ` Thomas Petazzoni
@ 2016-03-18 21:47 ` Arnout Vandecappelle
2016-03-18 22:29 ` Thomas Petazzoni
0 siblings, 1 reply; 68+ messages in thread
From: Arnout Vandecappelle @ 2016-03-18 21:47 UTC (permalink / raw)
To: buildroot
On 03/17/16 09:16, Thomas Petazzoni wrote:
> Hello,
>
> On Thu, 17 Mar 2016 00:45:19 +0100, Arnout Vandecappelle wrote:
>> On 03/16/16 22:43, Thomas Petazzoni wrote:
>>> 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_VFP support 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.
>
>> 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.
It's also an option to just keep it lingering in patchwork for a while.
>
>>> 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 :-)
>
> 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.
Oops my bad, I was confusing it with the BR2_ARM_FPU_* options.
Regards,
Arnout
>
> 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
>
--
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
^ permalink raw reply [flat|nested] 68+ messages in thread
* [Buildroot] [PATCH 10/16] arch/arm: add support for hard-float on Cortex-M4
2016-03-18 21:47 ` Arnout Vandecappelle
@ 2016-03-18 22:29 ` Thomas Petazzoni
0 siblings, 0 replies; 68+ messages in thread
From: Thomas Petazzoni @ 2016-03-18 22:29 UTC (permalink / raw)
To: buildroot
Hello,
On Fri, 18 Mar 2016 22:47:28 +0100, Arnout Vandecappelle wrote:
> > 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
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 68+ messages in thread
* [Buildroot] [PATCH 11/16] package/Makefile.in: adjust LDFLAGS for elf2flt
2016-03-16 21:43 [Buildroot] [PATCH 00/16] ARM Cortex-M support Thomas Petazzoni
` (9 preceding siblings ...)
2016-03-16 21:43 ` [Buildroot] [PATCH 10/16] arch/arm: add support for hard-float on Cortex-M4 Thomas Petazzoni
@ 2016-03-16 21:43 ` Thomas Petazzoni
2016-03-16 23:48 ` Arnout Vandecappelle
2016-03-16 21:43 ` [Buildroot] [PATCH 12/16] elf2flt: use new upstream site and add ARM patch Thomas Petazzoni
` (4 subsequent siblings)
15 siblings, 1 reply; 68+ messages in thread
From: Thomas Petazzoni @ 2016-03-16 21:43 UTC (permalink / raw)
To: buildroot
So 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.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
package/Makefile.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/package/Makefile.in b/package/Makefile.in
index dd595e2..616bdd0 100644
--- a/package/Makefile.in
+++ b/package/Makefile.in
@@ -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)
--
2.6.4
^ permalink raw reply related [flat|nested] 68+ messages in thread* [Buildroot] [PATCH 11/16] package/Makefile.in: adjust LDFLAGS for elf2flt
2016-03-16 21:43 ` [Buildroot] [PATCH 11/16] package/Makefile.in: adjust LDFLAGS for elf2flt Thomas Petazzoni
@ 2016-03-16 23:48 ` Arnout Vandecappelle
0 siblings, 0 replies; 68+ messages in thread
From: Arnout Vandecappelle @ 2016-03-16 23:48 UTC (permalink / raw)
To: buildroot
On 03/16/16 22:43, Thomas Petazzoni wrote:
> So 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,
Probably because it isn't tested so much :-)
> 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 <thomas.petazzoni@free-electrons.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Regards,
Arnout
> ---
> package/Makefile.in | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/package/Makefile.in b/package/Makefile.in
> index dd595e2..616bdd0 100644
> --- a/package/Makefile.in
> +++ b/package/Makefile.in
> @@ -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)
>
--
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
^ permalink raw reply [flat|nested] 68+ messages in thread
* [Buildroot] [PATCH 12/16] elf2flt: use new upstream site and add ARM patch
2016-03-16 21:43 [Buildroot] [PATCH 00/16] ARM Cortex-M support Thomas Petazzoni
` (10 preceding siblings ...)
2016-03-16 21:43 ` [Buildroot] [PATCH 11/16] package/Makefile.in: adjust LDFLAGS for elf2flt Thomas Petazzoni
@ 2016-03-16 21:43 ` Thomas Petazzoni
2016-03-16 23:50 ` Arnout Vandecappelle
2016-03-17 19:39 ` Waldemar Brodkorb
2016-03-16 21:43 ` [Buildroot] [PATCH 13/16] elf2flt: disable Werror to avoid build issues Thomas Petazzoni
` (3 subsequent siblings)
15 siblings, 2 replies; 68+ messages in thread
From: Thomas Petazzoni @ 2016-03-16 21:43 UTC (permalink / raw)
To: buildroot
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.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
.../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
diff --git a/package/elf2flt/0001-allow-to-build-arm-flat-binaries.patch b/package/elf2flt/0001-allow-to-build-arm-flat-binaries.patch
new file mode 100644
index 0000000..a6c63c5
--- /dev/null
+++ b/package/elf2flt/0001-allow-to-build-arm-flat-binaries.patch
@@ -0,0 +1,123 @@
+From 56b082412c6f49d21f5e54831a40d1e7c45b3ee4 Mon Sep 17 00:00:00 2001
+From: Waldemar Brodkorb <wbx@openadk.org>
+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 <wbx@openadk.org>
+Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+---
+ 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
+
diff --git a/package/elf2flt/elf2flt.mk b/package/elf2flt/elf2flt.mk
index bec270b..796313b 100644
--- a/package/elf2flt/elf2flt.mk
+++ b/package/elf2flt/elf2flt.mk
@@ -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
--
2.6.4
^ permalink raw reply related [flat|nested] 68+ messages in thread* [Buildroot] [PATCH 12/16] elf2flt: use new upstream site and add ARM patch
2016-03-16 21:43 ` [Buildroot] [PATCH 12/16] elf2flt: use new upstream site and add ARM patch Thomas Petazzoni
@ 2016-03-16 23:50 ` Arnout Vandecappelle
2016-03-17 8:18 ` Thomas Petazzoni
2016-03-17 19:39 ` Waldemar Brodkorb
1 sibling, 1 reply; 68+ messages in thread
From: Arnout Vandecappelle @ 2016-03-16 23:50 UTC (permalink / raw)
To: buildroot
On 03/16/16 22:43, Thomas Petazzoni wrote:
> 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.
>
> 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
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
> .../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
>
> diff --git a/package/elf2flt/0001-allow-to-build-arm-flat-binaries.patch b/package/elf2flt/0001-allow-to-build-arm-flat-binaries.patch
> new file mode 100644
> index 0000000..a6c63c5
> --- /dev/null
> +++ b/package/elf2flt/0001-allow-to-build-arm-flat-binaries.patch
> @@ -0,0 +1,123 @@
> +From 56b082412c6f49d21f5e54831a40d1e7c45b3ee4 Mon Sep 17 00:00:00 2001
> +From: Waldemar Brodkorb <wbx@openadk.org>
> +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 <wbx@openadk.org>
> +Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> +---
> + 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
> +
> diff --git a/package/elf2flt/elf2flt.mk b/package/elf2flt/elf2flt.mk
> index bec270b..796313b 100644
> --- a/package/elf2flt/elf2flt.mk
> +++ b/package/elf2flt/elf2flt.mk
> @@ -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
>
>
--
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
^ permalink raw reply [flat|nested] 68+ messages in thread* [Buildroot] [PATCH 12/16] elf2flt: use new upstream site and add ARM patch
2016-03-16 23:50 ` Arnout Vandecappelle
@ 2016-03-17 8:18 ` Thomas Petazzoni
2016-03-17 18:53 ` Mike Frysinger
0 siblings, 1 reply; 68+ messages in thread
From: Thomas Petazzoni @ 2016-03-17 8:18 UTC (permalink / raw)
To: buildroot
Dear Arnout Vandecappelle,
On Thu, 17 Mar 2016 00:50:59 +0100, Arnout Vandecappelle wrote:
> On 03/16/16 22:43, Thomas Petazzoni wrote:
> > 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.
> > 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
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 68+ messages in thread
* [Buildroot] [PATCH 12/16] elf2flt: use new upstream site and add ARM patch
2016-03-17 8:18 ` Thomas Petazzoni
@ 2016-03-17 18:53 ` Mike Frysinger
2016-03-17 19:41 ` Waldemar Brodkorb
2016-03-17 20:34 ` Thomas Petazzoni
0 siblings, 2 replies; 68+ messages in thread
From: Mike Frysinger @ 2016-03-17 18:53 UTC (permalink / raw)
To: buildroot
On 17 Mar 2016 09:18, Thomas Petazzoni wrote:
> On Thu, 17 Mar 2016 00:50:59 +0100, Arnout Vandecappelle wrote:
> > On 03/16/16 22:43, Thomas Petazzoni wrote:
> > > 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.
>
> > > 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.
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>
^ permalink raw reply [flat|nested] 68+ messages in thread
* [Buildroot] [PATCH 12/16] elf2flt: use new upstream site and add ARM patch
2016-03-17 18:53 ` Mike Frysinger
@ 2016-03-17 19:41 ` Waldemar Brodkorb
2016-03-17 20:34 ` Thomas Petazzoni
1 sibling, 0 replies; 68+ messages in thread
From: Waldemar Brodkorb @ 2016-03-17 19:41 UTC (permalink / raw)
To: buildroot
Hi Mike,
Mike Frysinger wrote,
> On 17 Mar 2016 09:18, Thomas Petazzoni wrote:
> > On Thu, 17 Mar 2016 00:50:59 +0100, Arnout Vandecappelle wrote:
> > > On 03/16/16 22:43, Thomas Petazzoni wrote:
> > > > 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.
> >
> > > > 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.
>
> 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
^ permalink raw reply [flat|nested] 68+ messages in thread
* [Buildroot] [PATCH 12/16] elf2flt: use new upstream site and add ARM patch
2016-03-17 18:53 ` Mike Frysinger
2016-03-17 19:41 ` Waldemar Brodkorb
@ 2016-03-17 20:34 ` Thomas Petazzoni
2016-03-17 20:45 ` Mike Frysinger
1 sibling, 1 reply; 68+ messages in thread
From: Thomas Petazzoni @ 2016-03-17 20:34 UTC (permalink / raw)
To: buildroot
Hello,
On Thu, 17 Mar 2016 14:53:42 -0400, Mike Frysinger wrote:
> > 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
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 68+ messages in thread
* [Buildroot] [PATCH 12/16] elf2flt: use new upstream site and add ARM patch
2016-03-17 20:34 ` Thomas Petazzoni
@ 2016-03-17 20:45 ` Mike Frysinger
0 siblings, 0 replies; 68+ messages in thread
From: Mike Frysinger @ 2016-03-17 20:45 UTC (permalink / raw)
To: buildroot
On 17 Mar 2016 21:34, Thomas Petazzoni wrote:
> On Thu, 17 Mar 2016 14:53:42 -0400, Mike Frysinger wrote:
> > > 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 :-)
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>
^ permalink raw reply [flat|nested] 68+ messages in thread
* [Buildroot] [PATCH 12/16] elf2flt: use new upstream site and add ARM patch
2016-03-16 21:43 ` [Buildroot] [PATCH 12/16] elf2flt: use new upstream site and add ARM patch Thomas Petazzoni
2016-03-16 23:50 ` Arnout Vandecappelle
@ 2016-03-17 19:39 ` Waldemar Brodkorb
1 sibling, 0 replies; 68+ messages in thread
From: Waldemar Brodkorb @ 2016-03-17 19:39 UTC (permalink / raw)
To: buildroot
Hi Thomas,
Thomas Petazzoni wrote,
> 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
^ permalink raw reply [flat|nested] 68+ messages in thread
* [Buildroot] [PATCH 13/16] elf2flt: disable Werror to avoid build issues
2016-03-16 21:43 [Buildroot] [PATCH 00/16] ARM Cortex-M support Thomas Petazzoni
` (11 preceding siblings ...)
2016-03-16 21:43 ` [Buildroot] [PATCH 12/16] elf2flt: use new upstream site and add ARM patch Thomas Petazzoni
@ 2016-03-16 21:43 ` Thomas Petazzoni
2016-03-16 23:53 ` Arnout Vandecappelle
2016-03-17 1:40 ` Mike Frysinger
2016-03-16 21:43 ` [Buildroot] [PATCH 14/16] afboot-stm32: use the Buildroot toolchain Thomas Petazzoni
` (2 subsequent siblings)
15 siblings, 2 replies; 68+ messages in thread
From: Thomas Petazzoni @ 2016-03-16 21:43 UTC (permalink / raw)
To: buildroot
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.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
package/elf2flt/elf2flt.mk | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/package/elf2flt/elf2flt.mk b/package/elf2flt/elf2flt.mk
index 796313b..eb0baad 100644
--- a/package/elf2flt/elf2flt.mk
+++ b/package/elf2flt/elf2flt.mk
@@ -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
--
2.6.4
^ permalink raw reply related [flat|nested] 68+ messages in thread* [Buildroot] [PATCH 13/16] elf2flt: disable Werror to avoid build issues
2016-03-16 21:43 ` [Buildroot] [PATCH 13/16] elf2flt: disable Werror to avoid build issues Thomas Petazzoni
@ 2016-03-16 23:53 ` Arnout Vandecappelle
2016-03-17 8:18 ` Thomas Petazzoni
2016-03-17 1:40 ` Mike Frysinger
1 sibling, 1 reply; 68+ messages in thread
From: Arnout Vandecappelle @ 2016-03-16 23:53 UTC (permalink / raw)
To: buildroot
On 03/16/16 22:43, Thomas Petazzoni wrote:
> 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:
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Regards,
Arnout
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
> package/elf2flt/elf2flt.mk | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/package/elf2flt/elf2flt.mk b/package/elf2flt/elf2flt.mk
> index 796313b..eb0baad 100644
> --- a/package/elf2flt/elf2flt.mk
> +++ b/package/elf2flt/elf2flt.mk
> @@ -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
>
>
--
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
^ permalink raw reply [flat|nested] 68+ messages in thread
* [Buildroot] [PATCH 13/16] elf2flt: disable Werror to avoid build issues
2016-03-16 23:53 ` Arnout Vandecappelle
@ 2016-03-17 8:18 ` Thomas Petazzoni
0 siblings, 0 replies; 68+ messages in thread
From: Thomas Petazzoni @ 2016-03-17 8:18 UTC (permalink / raw)
To: buildroot
Dear Arnout Vandecappelle,
On Thu, 17 Mar 2016 00:53:41 +0100, Arnout Vandecappelle wrote:
> On 03/16/16 22:43, Thomas Petazzoni wrote:
> > 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
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 68+ messages in thread
* [Buildroot] [PATCH 13/16] elf2flt: disable Werror to avoid build issues
2016-03-16 21:43 ` [Buildroot] [PATCH 13/16] elf2flt: disable Werror to avoid build issues Thomas Petazzoni
2016-03-16 23:53 ` Arnout Vandecappelle
@ 2016-03-17 1:40 ` Mike Frysinger
2016-03-17 8:19 ` Thomas Petazzoni
1 sibling, 1 reply; 68+ messages in thread
From: Mike Frysinger @ 2016-03-17 1:40 UTC (permalink / raw)
To: buildroot
On 16 Mar 2016 22:43, Thomas Petazzoni wrote:
> 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>
^ permalink raw reply [flat|nested] 68+ messages in thread
* [Buildroot] [PATCH 13/16] elf2flt: disable Werror to avoid build issues
2016-03-17 1:40 ` Mike Frysinger
@ 2016-03-17 8:19 ` Thomas Petazzoni
2016-03-17 18:57 ` Mike Frysinger
0 siblings, 1 reply; 68+ messages in thread
From: Thomas Petazzoni @ 2016-03-17 8:19 UTC (permalink / raw)
To: buildroot
Mike,
On Wed, 16 Mar 2016 21:40:51 -0400, Mike Frysinger wrote:
> On 16 Mar 2016 22:43, Thomas Petazzoni wrote:
> > 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
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 68+ messages in thread
* [Buildroot] [PATCH 13/16] elf2flt: disable Werror to avoid build issues
2016-03-17 8:19 ` Thomas Petazzoni
@ 2016-03-17 18:57 ` Mike Frysinger
0 siblings, 0 replies; 68+ messages in thread
From: Mike Frysinger @ 2016-03-17 18:57 UTC (permalink / raw)
To: buildroot
On 17 Mar 2016 09:19, Thomas Petazzoni wrote:
> On Wed, 16 Mar 2016 21:40:51 -0400, Mike Frysinger wrote:
> > On 16 Mar 2016 22:43, Thomas Petazzoni wrote:
> > > 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.
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>
^ permalink raw reply [flat|nested] 68+ messages in thread
* [Buildroot] [PATCH 14/16] afboot-stm32: use the Buildroot toolchain
2016-03-16 21:43 [Buildroot] [PATCH 00/16] ARM Cortex-M support Thomas Petazzoni
` (12 preceding siblings ...)
2016-03-16 21:43 ` [Buildroot] [PATCH 13/16] elf2flt: disable Werror to avoid build issues Thomas Petazzoni
@ 2016-03-16 21:43 ` Thomas Petazzoni
2016-03-16 21:43 ` [Buildroot] [PATCH 15/16] configs/stm32f429_disco: new configuration for STM32F429 Discovery board Thomas Petazzoni
2016-03-16 21:43 ` [Buildroot] [PATCH 16/16] configs/stm32f469_disco: new configuration for STM32F469 " Thomas Petazzoni
15 siblings, 0 replies; 68+ messages in thread
From: Thomas Petazzoni @ 2016-03-16 21:43 UTC (permalink / raw)
To: buildroot
By 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.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
.../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
diff --git a/boot/afboot-stm32/0001-Use-ld-instead-of-gcc-for-linking.patch b/boot/afboot-stm32/0001-Use-ld-instead-of-gcc-for-linking.patch
new file mode 100644
index 0000000..3f359dc
--- /dev/null
+++ b/boot/afboot-stm32/0001-Use-ld-instead-of-gcc-for-linking.patch
@@ -0,0 +1,61 @@
+From 0d581abe6620ac69adec321b94390e009802f36a Mon Sep 17 00:00:00 2001
+From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+Date: Sun, 13 Mar 2016 14:32:33 +0100
+Subject: [PATCH] Use ld instead of gcc for linking
+
+Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+---
+ 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
+
diff --git a/boot/afboot-stm32/afboot-stm32.mk b/boot/afboot-stm32/afboot-stm32.mk
index ac85d58..042b21f 100644
--- a/boot/afboot-stm32/afboot-stm32.mk
+++ b/boot/afboot-stm32/afboot-stm32.mk
@@ -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
--
2.6.4
^ permalink raw reply related [flat|nested] 68+ messages in thread* [Buildroot] [PATCH 15/16] configs/stm32f429_disco: new configuration for STM32F429 Discovery board
2016-03-16 21:43 [Buildroot] [PATCH 00/16] ARM Cortex-M support Thomas Petazzoni
` (13 preceding siblings ...)
2016-03-16 21:43 ` [Buildroot] [PATCH 14/16] afboot-stm32: use the Buildroot toolchain Thomas Petazzoni
@ 2016-03-16 21:43 ` Thomas Petazzoni
2016-03-16 21:43 ` [Buildroot] [PATCH 16/16] configs/stm32f469_disco: new configuration for STM32F469 " Thomas Petazzoni
15 siblings, 0 replies; 68+ messages in thread
From: Thomas Petazzoni @ 2016-03-16 21:43 UTC (permalink / raw)
To: buildroot
From: Lee Jones <lee.jones@linaro.org>
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.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
[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.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
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
diff --git a/board/stmicroelectronics/busybox-minimal.config b/board/stmicroelectronics/busybox-minimal.config
new file mode 100644
index 0000000..3261e5a
--- /dev/null
+++ b/board/stmicroelectronics/busybox-minimal.config
@@ -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
diff --git a/board/stmicroelectronics/stm32-post-build.sh b/board/stmicroelectronics/stm32-post-build.sh
new file mode 100755
index 0000000..e324afe
--- /dev/null
+++ b/board/stmicroelectronics/stm32-post-build.sh
@@ -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/
diff --git a/board/stmicroelectronics/stm32f429-disco/flash.sh b/board/stmicroelectronics/stm32f429-disco/flash.sh
new file mode 100755
index 0000000..ffb8fcf
--- /dev/null
+++ b/board/stmicroelectronics/stm32f429-disco/flash.sh
@@ -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"
diff --git a/board/stmicroelectronics/stm32f429-disco/patches/linux/0001-ARM-stm32f249-disco-don-t-force-init-in-chosen-boota.patch b/board/stmicroelectronics/stm32f429-disco/patches/linux/0001-ARM-stm32f249-disco-don-t-force-init-in-chosen-boota.patch
new file mode 100644
index 0000000..d6d5c61
--- /dev/null
+++ b/board/stmicroelectronics/stm32f429-disco/patches/linux/0001-ARM-stm32f249-disco-don-t-force-init-in-chosen-boota.patch
@@ -0,0 +1,32 @@
+From ded9afa688184b3240a92c2b8f114c545a09bc3f Mon Sep 17 00:00:00 2001
+From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+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 <thomas.petazzoni@free-electrons.com>
+---
+ 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
+
diff --git a/board/stmicroelectronics/stm32f429-disco/readme.txt b/board/stmicroelectronics/stm32f429-disco/readme.txt
new file mode 100644
index 0000000..afe0f11
--- /dev/null
+++ b/board/stmicroelectronics/stm32f429-disco/readme.txt
@@ -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.
diff --git a/configs/stm32f429_disco_defconfig b/configs/stm32f429_disco_defconfig
new file mode 100644
index 0000000..28f253e
--- /dev/null
+++ b/configs/stm32f429_disco_defconfig
@@ -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
--
2.6.4
^ permalink raw reply related [flat|nested] 68+ messages in thread* [Buildroot] [PATCH 16/16] configs/stm32f469_disco: new configuration for STM32F469 Discovery board
2016-03-16 21:43 [Buildroot] [PATCH 00/16] ARM Cortex-M support Thomas Petazzoni
` (14 preceding siblings ...)
2016-03-16 21:43 ` [Buildroot] [PATCH 15/16] configs/stm32f429_disco: new configuration for STM32F429 Discovery board Thomas Petazzoni
@ 2016-03-16 21:43 ` Thomas Petazzoni
15 siblings, 0 replies; 68+ messages in thread
From: Thomas Petazzoni @ 2016-03-16 21:43 UTC (permalink / raw)
To: buildroot
From: Lee Jones <lee.jones@linaro.org>
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.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
[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.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
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
diff --git a/board/stmicroelectronics/stm32f469-disco/flash.sh b/board/stmicroelectronics/stm32f469-disco/flash.sh
new file mode 100755
index 0000000..a68bea0
--- /dev/null
+++ b/board/stmicroelectronics/stm32f469-disco/flash.sh
@@ -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"
diff --git a/board/stmicroelectronics/stm32f469-disco/patches/linux/0001-kernel-add-top-compatible.patch b/board/stmicroelectronics/stm32f469-disco/patches/linux/0001-kernel-add-top-compatible.patch
new file mode 100644
index 0000000..f1c61dd
--- /dev/null
+++ b/board/stmicroelectronics/stm32f469-disco/patches/linux/0001-kernel-add-top-compatible.patch
@@ -0,0 +1,25 @@
+From 6bd8bae3dd0631f8d23e63617dca289f162e6840 Mon Sep 17 00:00:00 2001
+From: Lee Jones <lee.jones@linaro.org>
+Date: Tue, 16 Feb 2016 14:04:17 +0000
+Subject: [PATCH] ARM: stm32: Identify a new board - STM32F469
+
+Signed-off-by: Lee Jones <lee.jones@linaro.org>
+---
+ 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
+
diff --git a/board/stmicroelectronics/stm32f469-disco/patches/linux/0002-kernel-new-dts-file.patch b/board/stmicroelectronics/stm32f469-disco/patches/linux/0002-kernel-new-dts-file.patch
new file mode 100644
index 0000000..954679e
--- /dev/null
+++ b/board/stmicroelectronics/stm32f469-disco/patches/linux/0002-kernel-new-dts-file.patch
@@ -0,0 +1,114 @@
+From a898629f21b86f2560041109f64d01d20087deae Mon Sep 17 00:00:00 2001
+From: Lee Jones <lee.jones@linaro.org>
+Date: Tue, 16 Feb 2016 13:53:47 +0000
+Subject: [PATCH] ARM: stm32: Supply a DTS file for the STM32F469 Discovery
+ board
+
+It's pretty similar to the STM32F429, but there are some
+subtle changes required to boot successfully.
+
+Signed-off-by: Lee Jones <lee.jones@linaro.org>
+[Thomas: remove rdinit= from /chosen/bootargs.]
+Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+---
+ arch/arm/boot/dts/Makefile | 1 +
+ arch/arm/boot/dts/stm32f469-disco.dts | 75 +++++++++++++++++++++++++++++++++++
+ 2 files changed, 76 insertions(+)
+ create mode 100644 arch/arm/boot/dts/stm32f469-disco.dts
+
+diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
+index 30bbc37..c9d8023 100644
+--- a/arch/arm/boot/dts/Makefile
++++ b/arch/arm/boot/dts/Makefile
+@@ -583,6 +583,7 @@ dtb-$(CONFIG_ARCH_STI) += \
+ stih418-b2199.dtb
+ dtb-$(CONFIG_ARCH_STM32)+= \
+ stm32f429-disco.dtb \
++ stm32f469-disco.dtb \
+ stm32429i-eval.dtb
+ dtb-$(CONFIG_MACH_SUN4I) += \
+ sun4i-a10-a1000.dtb \
+diff --git a/arch/arm/boot/dts/stm32f469-disco.dts b/arch/arm/boot/dts/stm32f469-disco.dts
+new file mode 100644
+index 0000000..e911af8
+--- /dev/null
++++ b/arch/arm/boot/dts/stm32f469-disco.dts
+@@ -0,1 +1,75 @@
++/*
++ * Copyright 2016 - Lee Jones <lee.jones@linaro.org>
++ *
++ * This file is dual-licensed: you can use it either under the terms
++ * of the GPL or the X11 license, at your option. Note that this dual
++ * licensing only applies to this file, and not this project as a
++ * whole.
++ *
++ * a) This file is free software; you can redistribute it and/or
++ * modify it under the terms of the GNU General Public License as
++ * published by the Free Software Foundation; either version 2 of the
++ * License, or (at your option) any later version.
++ *
++ * This file is distributed in the hope that it will be useful,
++ * but WITHOUT ANY WARRANTY; without even the implied warranty of
++ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
++ * GNU General Public License for more details.
++ *
++ * You should have received a copy of the GNU General Public
++ * License along with this file; if not, write to the Free
++ * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
++ * MA 02110-1301 USA
++ *
++ * Or, alternatively,
++ *
++ * b) Permission is hereby granted, free of charge, to any person
++ * obtaining a copy of this software and associated documentation
++ * files (the "Software"), to deal in the Software without
++ * restriction, including without limitation the rights to use,
++ * copy, modify, merge, publish, distribute, sublicense, and/or
++ * sell copies of the Software, and to permit persons to whom the
++ * Software is furnished to do so, subject to the following
++ * conditions:
++ *
++ * The above copyright notice and this permission notice shall be
++ * included in all copies or substantial portions of the Software.
++ *
++ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
++ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
++ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
++ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
++ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
++ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
++ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
++ * OTHER DEALINGS IN THE SOFTWARE.
++ */
++
++/dts-v1/;
++#include "stm32f429.dtsi"
++
++/ {
++ model = "STMicroelectronics STM32F469i-DISCO board";
++ compatible = "st,stm32f469i-disco", "st,stm32f469";
++
++ chosen {
++ bootargs = "root=/dev/ram";
++ stdout-path = "serial0:115200n8";
++ };
++
++ memory {
++ reg = <0x00000000 0x800000>;
++ };
++
++ aliases {
++ serial0 = &usart3;
++ };
++};
++
++&clk_hse {
++ clock-frequency = <8000000>;
++};
++
++&usart3 {
++ status = "okay";
++};
+--
+1.9.1
+
diff --git a/board/stmicroelectronics/stm32f469-disco/patches/linux/0003-kernel-config-frag-ram.patch b/board/stmicroelectronics/stm32f469-disco/patches/linux/0003-kernel-config-frag-ram.patch
new file mode 100644
index 0000000..e431e8b
--- /dev/null
+++ b/board/stmicroelectronics/stm32f469-disco/patches/linux/0003-kernel-config-frag-ram.patch
@@ -0,0 +1,28 @@
+From 4cb65563325bee1886329b97ce3e2b0b90106bdd Mon Sep 17 00:00:00 2001
+From: Lee Jones <lee.jones@linaro.org>
+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 <arnd@arndb.de>
+Signed-off-by: Lee Jones <lee.jones@linaro.org>
+---
+ 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
+
diff --git a/board/stmicroelectronics/stm32f469-disco/patches/openocd/0001-add-config.patch b/board/stmicroelectronics/stm32f469-disco/patches/openocd/0001-add-config.patch
new file mode 100644
index 0000000..036c4f6
--- /dev/null
+++ b/board/stmicroelectronics/stm32f469-disco/patches/openocd/0001-add-config.patch
@@ -0,0 +1,37 @@
+From 26045588f462476cee356d15a24944d6c26befb4 Mon Sep 17 00:00:00 2001
+From: Maxime Coquelin <mcoquelin.stm32@gmail.com>
+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 <mcoquelin.stm32@gmail.com>
+Reviewed-on: http://openocd.zylin.com/3043
+Tested-by: jenkins
+Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
+Reviewed-by: Freddie Chopin <freddie.chopin@gmail.com>
+---
+ 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
+
diff --git a/board/stmicroelectronics/stm32f469-disco/patches/openocd/0002-flash-nor.patch b/board/stmicroelectronics/stm32f469-disco/patches/openocd/0002-flash-nor.patch
new file mode 100644
index 0000000..bfec983
--- /dev/null
+++ b/board/stmicroelectronics/stm32f469-disco/patches/openocd/0002-flash-nor.patch
@@ -0,0 +1,37 @@
+From 3e219648c80a27f0519003f3b088cbb846e255d8 Mon Sep 17 00:00:00 2001
+From: Maxime Coquelin <maxime.coquelin@st.com>
+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 <mcoquelin.stm32@gmail.com>
+Reviewed-on: http://openocd.zylin.com/3042
+Tested-by: jenkins
+Reviewed-by: Freddie Chopin <freddie.chopin@gmail.com>
+---
+ 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
+
diff --git a/board/stmicroelectronics/stm32f469-disco/readme.txt b/board/stmicroelectronics/stm32f469-disco/readme.txt
new file mode 100644
index 0000000..3b88496
--- /dev/null
+++ b/board/stmicroelectronics/stm32f469-disco/readme.txt
@@ -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.
diff --git a/configs/stm32f469_disco_defconfig b/configs/stm32f469_disco_defconfig
new file mode 100644
index 0000000..4d42f96
--- /dev/null
+++ b/configs/stm32f469_disco_defconfig
@@ -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
--
2.6.4
^ permalink raw reply related [flat|nested] 68+ messages in thread