Patchwork [2/2] arch/Config.in: Allow ARM to select BR2_BINFMT_FLAT

login
register
mail settings
Submitter Axel Lin
Date Sept. 4, 2013, 2:44 a.m.
Message ID <1378262667.32360.6.camel@phoenix>
Download mbox | patch
Permalink /patch/272450/
State Rejected
Delegated to: Thomas Petazzoni
Headers show

Comments

Axel Lin - Sept. 4, 2013, 2:44 a.m.
Some noMMU ARM platforms need to select BR2_BINFMT_FLAT.
Most ARM platforms have MMU, thus set default to BR2_BINFMT_ELF for ARM.

Signed-off-by: Axel Lin <axel.lin@ingics.com>
---
 arch/Config.in | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)
Thomas Petazzoni - Sept. 5, 2013, 9:48 p.m.
Dear Axel Lin,

On Wed, 04 Sep 2013 10:44:27 +0800, Axel Lin wrote:

> diff --git a/arch/Config.in b/arch/Config.in
> index 14899ca..31c23ec 100644
> --- a/arch/Config.in
> +++ b/arch/Config.in
> @@ -223,8 +223,9 @@ config BR2_GCC_TARGET_MODE
>  # Set up target binary format
>  choice
>  	prompt "Target Binary Format"
> -	depends on BR2_bfin || BR2_m68k
> -	default BR2_BINFMT_FDPIC
> +	depends on BR2_arm || BR2_bfin || BR2_m68k
> +	default BR2_BINFMT_ELF if BR2_arm
> +	default BR2_BINFMT_FDPIC if (BR2_bfin || BR2_m68k)

I know it was broken before, but FDPIC isn't supported on BR2_m68k, so
I guess we should have something like:

	prompt "Target Binary Format"
	depends on BR2_arm || BR2_m68k || BR2_bfin
	default BR2_BINFMT_ELF if BR2_arm
	default BR2_BINFMT_FDPIC if BR2_bfin
	default BR2_BINFMT_FLAT if BR2_m68k

But I'm wondering if we shouldn't go further than that, and make
BR2_BINFMT_FLAT available only for non-MMU ARMs. Something like:

	prompt "Target Binary Format"
	depends on BR2_arm7tmdi || BR2_arm_cortex_m3 ||	BR2_arm_cortex_m4 || BR2_m68k || BR2_bfin
	default BR2_BINFMT_FLAT if BR2_arm7tmdi || BR2_arm_cortex_m3 ||	BR2_arm_cortex_m4 || BR2_m68k
	default BR2_BINFMT_FDPIC if BR2_bfin

or something like this. This way, users of MMU-capable ARM variants
wouldn't be confused by the availability of FLAT and ELF as binary
formats. Of course, BR2_BINFMT_ELF should gain some !BR2_arm7tmdi
&& !BR2_arm_cortex_m3 && !BR2_arm_cortex_m4 dependencies, or maybe even
a !BR2_USE_MMU dependency. I think there's quite some room for
improvement around the definition of which CPU has an MMU or not, and
which architectures support which binary formats.

Best regards,

Thomas
Thomas De Schampheleire - Sept. 6, 2013, 1:08 a.m.
Op 5-sep.-2013 23:48 schreef "Thomas Petazzoni" <
thomas.petazzoni@free-electrons.com> het volgende:

> But I'm wondering if we shouldn't go further than that, and make
> BR2_BINFMT_FLAT available only for non-MMU ARMs. Something like:
>
>         prompt "Target Binary Format"
>         depends on BR2_arm7tmdi || BR2_arm_cortex_m3 || BR2_arm_cortex_m4
|| BR2_m68k || BR2_bfin
>         default BR2_BINFMT_FLAT if BR2_arm7tmdi || BR2_arm_cortex_m3 ||
BR2_arm_cortex_m4 || BR2_m68k
>         default BR2_BINFMT_FDPIC if BR2_bfin
>
> or something like this. This way, users of MMU-capable ARM variants
> wouldn't be confused by the availability of FLAT and ELF as binary
> formats. Of course, BR2_BINFMT_ELF should gain some !BR2_arm7tmdi
> && !BR2_arm_cortex_m3 && !BR2_arm_cortex_m4 dependencies, or maybe even
> a !BR2_USE_MMU dependency. I think there's quite some room for
> improvement around the definition of which CPU has an MMU or not, and
> which architectures support which binary formats.

Don't we/shouldn't we have something like ARCH_HAS_MMU and/or
ARCH_SUPPORTS_FLAT_BINARY?

Best regards,
Thomas
Thomas Petazzoni - Sept. 6, 2013, 6:25 a.m.
Dear Thomas De Schampheleire,

On Fri, 6 Sep 2013 03:08:10 +0200, Thomas De Schampheleire wrote:

> > or something like this. This way, users of MMU-capable ARM variants
> > wouldn't be confused by the availability of FLAT and ELF as binary
> > formats. Of course, BR2_BINFMT_ELF should gain some !BR2_arm7tmdi
> > && !BR2_arm_cortex_m3 && !BR2_arm_cortex_m4 dependencies, or maybe even
> > a !BR2_USE_MMU dependency. I think there's quite some room for
> > improvement around the definition of which CPU has an MMU or not, and
> > which architectures support which binary formats.
> 
> Don't we/shouldn't we have something like ARCH_HAS_MMU and/or
> ARCH_SUPPORTS_FLAT_BINARY?

Yes, we should probably have something like this (and ditto for other
binary formats: ELF, FDPIC and so on).

Thomas
Gustavo Zacarias - Sept. 6, 2013, 10:08 a.m.
On 09/06/2013 03:25 AM, Thomas Petazzoni wrote:

> On Fri, 6 Sep 2013 03:08:10 +0200, Thomas De Schampheleire wrote:
> 
>> Don't we/shouldn't we have something like ARCH_HAS_MMU and/or
>> ARCH_SUPPORTS_FLAT_BINARY?
> 
> Yes, we should probably have something like this (and ditto for other
> binary formats: ELF, FDPIC and so on).

On a side note, remember that HAS_MMU doesn't mean it's using it - from
what i've read you can use MMU-bearing processors to test uclinux
MMU-less scenarios (dunno if it can be done with every SOC out there,
probably depends on the linux support for each one, at least a couple of
Atmel ones were used this way for testing and/or masochism).
Regards.
Thomas Petazzoni - Sept. 6, 2013, 10:12 a.m.
Dear Gustavo Zacarias,

On Fri, 06 Sep 2013 07:08:16 -0300, Gustavo Zacarias wrote:
> On 09/06/2013 03:25 AM, Thomas Petazzoni wrote:
> 
> > On Fri, 6 Sep 2013 03:08:10 +0200, Thomas De Schampheleire wrote:
> > 
> >> Don't we/shouldn't we have something like ARCH_HAS_MMU and/or
> >> ARCH_SUPPORTS_FLAT_BINARY?
> > 
> > Yes, we should probably have something like this (and ditto for other
> > binary formats: ELF, FDPIC and so on).
> 
> On a side note, remember that HAS_MMU doesn't mean it's using it - from
> what i've read you can use MMU-bearing processors to test uclinux
> MMU-less scenarios (dunno if it can be done with every SOC out there,
> probably depends on the linux support for each one, at least a couple of
> Atmel ones were used this way for testing and/or masochism).

Right. We could distinguish what the hardware is capable of (i.e
BR2_HAS_MMU vs. !BR2_HAS_MMU) and what the user wants to do
(BR2_USE_MMU vs. !BR2_USE_MMU). Of course, BR2_USE_MMU depends on
BR2_HAS_MMU. That said, until now, we've been hiding BR2_USE_MMU on
many architectures for which !MMU doesn't exist/isn't supported. On
ARM, I believe it doesn't make much sense to expose !MMU for
MMU-capable variants.

Best regards,

Thomas

Patch

diff --git a/arch/Config.in b/arch/Config.in
index 14899ca..31c23ec 100644
--- a/arch/Config.in
+++ b/arch/Config.in
@@ -223,8 +223,9 @@  config BR2_GCC_TARGET_MODE
 # Set up target binary format
 choice
 	prompt "Target Binary Format"
-	depends on BR2_bfin || BR2_m68k
-	default BR2_BINFMT_FDPIC
+	depends on BR2_arm || BR2_bfin || BR2_m68k
+	default BR2_BINFMT_ELF if BR2_arm
+	default BR2_BINFMT_FDPIC if (BR2_bfin || BR2_m68k)
 
 config BR2_BINFMT_ELF
 	bool "ELF"
@@ -245,7 +246,7 @@  config BR2_BINFMT_FDPIC
 
 config BR2_BINFMT_FLAT
 	bool "FLAT"
-	depends on BR2_bfin || BR2_m68k
+	depends on BR2_arm || BR2_bfin || BR2_m68k
 	select BR2_PREFER_STATIC_LIB
 	help
 	  FLAT binary is a relatively simple and lightweight executable format