[Buildroot] [RFC PATCH 0/2] Add Freescale e5500 & e6500 support

[Buildroot] [RFC PATCH 0/2] Add Freescale e5500 & e6500 support

[Gustavo Zacarias]

This patchset enables internal toolchain builds for Freescale e5500
and e6500 cores.
It's only built-tested to generate a 32 and 64-bit toolchains
with a basic busybox binary and libraries.

Feedback welcome, free kits to test as well :)

Gustavo Zacarias (2):
  arch/powerpc: add fsl e5500 and e6500 support
  package/gcc: set e5500 and e6500 version mask

 arch/Config.in.powerpc     | 7 +++++++
 package/gcc/Config.in.host | 6 ++++--
 2 files changed, 11 insertions(+), 2 deletions(-)

-- 
2.0.4

[Buildroot] [PATCH 1/2] arch/powerpc: add fsl e5500 and e6500 support

[Gustavo Zacarias]

Add Freescale E5500 and E6500 core support.
These can go in 32 or 64-bit mode.
I'm not aware of these being able to boot in LE mode so filter that out
until we get some feedback on it.

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
 arch/Config.in.powerpc | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/Config.in.powerpc b/arch/Config.in.powerpc
index f7f3ab1..c1142f2 100644
--- a/arch/Config.in.powerpc
+++ b/arch/Config.in.powerpc
@@ -109,6 +109,13 @@ config BR2_powerpc_e300c3
 config BR2_powerpc_e500mc
 	bool "e500mc"
 	depends on !BR2_ARCH_IS_64
+config BR2_powerpc_e5500
+	bool "e5500"
+	depends on !BR2_powerpc64le
+config BR2_powerpc_e6500
+	bool "e6500"
+	depends on !BR2_powerpc64le
+	select BR2_POWERPC_CPU_HAS_ALTIVEC
 config BR2_powerpc_power4
 	bool "power4"
 config BR2_powerpc_power5
-- 
2.0.4

[Buildroot] [PATCH 2/2] package/gcc: set e5500 and e6500 version mask

[Gustavo Zacarias]

Freescale e5500 and e6500 cores are supported for versions >= 4.8
So filter out all of the older versions to avoid build failures.

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
 package/gcc/Config.in.host | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/package/gcc/Config.in.host b/package/gcc/Config.in.host
index 3bccf36..a62e762 100644
--- a/package/gcc/Config.in.host
+++ b/package/gcc/Config.in.host
@@ -30,7 +30,8 @@ choice
 		depends on !BR2_cortex_a7 && !BR2_cortex_a12 && \
 			!BR2_cortex_a15 && !BR2_fa526 && !BR2_pj4
 		# Broken or unsupported PPC cores
-		depends on !BR2_powerpc_power8
+		depends on !BR2_powerpc_e5500 && !BR2_powerpc_e6500 && \
+			!BR2_powerpc_power8
 		# SPARC -mcpu=leon3 appeared in gcc 4.8.3
 		depends on !BR2_sparc_leon3
 		# Broken or unsupported X86 cores
@@ -49,7 +50,8 @@ choice
 		# Broken or unsupported ARM cores
 		depends on !BR2_cortex_a12 && !BR2_pj4
 		# Broken or unsupported PPC cores
-		depends on !BR2_powerpc_power8
+		depends on !BR2_powerpc_e5500 && !BR2_powerpc_e6500 && \
+			!BR2_powerpc_power8
 		# SPARC -mcpu=leon3 appeared in gcc 4.8.3
 		depends on !BR2_sparc_leon3
 		# Broken or unsupported x86 cores
-- 
2.0.4

[Buildroot] [PATCH 1/2] arch/powerpc: add fsl e5500 and e6500 support

[Matthew Weber]

Gustavo,

On Mon, Nov 17, 2014 at 5:14 PM, Gustavo Zacarias
<gustavo@zacarias.com.ar> wrote:
> Add Freescale E5500 and E6500 core support.
> These can go in 32 or 64-bit mode.
> I'm not aware of these being able to boot in LE mode so filter that out
> until we get some feedback on it.
>
> Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
> ---
>  arch/Config.in.powerpc | 7 +++++++
>  1 file changed, 7 insertions(+)
>
> diff --git a/arch/Config.in.powerpc b/arch/Config.in.powerpc
> index f7f3ab1..c1142f2 100644
> --- a/arch/Config.in.powerpc
> +++ b/arch/Config.in.powerpc
> @@ -109,6 +109,13 @@ config BR2_powerpc_e300c3
>  config BR2_powerpc_e500mc
>         bool "e500mc"
>         depends on !BR2_ARCH_IS_64
> +config BR2_powerpc_e5500
> +       bool "e5500"
> +       depends on !BR2_powerpc64le
> +config BR2_powerpc_e6500
> +       bool "e6500"
> +       depends on !BR2_powerpc64le
> +       select BR2_POWERPC_CPU_HAS_ALTIVEC

Reviewed-by: "Matt Weber" <matthew.weber@rockwellcollins.com>

I'll try to give this a test when I get a chance, we currently have a
e5500 target that we're building binaries for but with a e500mc
toolchain (using arch compatibility mode on the processor).  Will the
buildroot toolchain do multilib so that it's possible to build uboot
32/36bit and a kernel 64bit?  So far that's why we stuck with the
e500mc (just 32/36bit) keeping us using a single toolchain.

>  config BR2_powerpc_power4
>         bool "power4"
>  config BR2_powerpc_power5
> --
> 2.0.4
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot



-- 
Matthew L Weber / Pr Software Engineer
Airborne Information Systems / Security Systems and Software
MS 131-100, C Ave NE, Cedar Rapids, IA, 52498, USA
www.rockwellcollins.com

Note: Any Export License Required Information and License Restricted
Third Party Intellectual Property (TPIP) content must be encrypted and
sent to matthew.weber at corp.rockwellcollins.com.

[Buildroot] [PATCH 1/2] arch/powerpc: add fsl e5500 and e6500 support

[Gustavo Zacarias]

On 11/18/2014 10:56 AM, Matthew Weber wrote:

> I'll try to give this a test when I get a chance, we currently have a
> e5500 target that we're building binaries for but with a e500mc
> toolchain (using arch compatibility mode on the processor).  Will the
> buildroot toolchain do multilib so that it's possible to build uboot
> 32/36bit and a kernel 64bit?  So far that's why we stuck with the
> e500mc (just 32/36bit) keeping us using a single toolchain.

We don't do proper multilib yet, so unfortunately you'll have to go with
separate BR projects for say kernel/bootloader (64 bit) and userland (32
bit).
Regards.

[Buildroot] [PATCH 1/2] arch/powerpc: add fsl e5500 and e6500 support

[Thomas Petazzoni]

Dear Gustavo Zacarias,

On Tue, 18 Nov 2014 11:28:09 -0300, Gustavo Zacarias wrote:

> > I'll try to give this a test when I get a chance, we currently have a
> > e5500 target that we're building binaries for but with a e500mc
> > toolchain (using arch compatibility mode on the processor).  Will the
> > buildroot toolchain do multilib so that it's possible to build uboot
> > 32/36bit and a kernel 64bit?  So far that's why we stuck with the
> > e500mc (just 32/36bit) keeping us using a single toolchain.
> 
> We don't do proper multilib yet, so unfortunately you'll have to go with
> separate BR projects for say kernel/bootloader (64 bit) and userland (32
> bit).

That's kind of annoying, and we have a similar problem on x86-64 when
we need to build a 32 bits bootloader (though this might become less of
an issue with UEFI being capable of using 64 bits bootloaders).

Should we do something about this, and support multilib? Note that SH4
is also broken since quite a while in the internal toolchain backend
because it needs multilib support. The issue is how do we decide which
multilib variants to build? Do we simply "force" a certain set of
multilib variants for a given architecture?

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 1/2] arch/powerpc: add fsl e5500 and e6500 support

[Gustavo Zacarias]

On 11/18/2014 12:20 PM, Thomas Petazzoni wrote:

> That's kind of annoying, and we have a similar problem on x86-64 when
> we need to build a 32 bits bootloader (though this might become less of
> an issue with UEFI being capable of using 64 bits bootloaders).
> 
> Should we do something about this, and support multilib? Note that SH4
> is also broken since quite a while in the internal toolchain backend
> because it needs multilib support. The issue is how do we decide which
> multilib variants to build? Do we simply "force" a certain set of
> multilib variants for a given architecture?

Yes it is, i think we should deal with it.
In most scenarios there aren't more than 2 possible combinations.
Quick examples would be:

* x86_64 -> i386, x32 (ugh), x86_64
Most of the time you want the 64-bit kernel with one of i386 or x32.
Bootloader might be subject to being built as 32-bit because of legacy.

* sparc64 -> 64-v9 or 32-v9.
Useful for a 64-bit kernel with 32ul mostly, or everything 64 (no
multilib) (i know we don't support sparc64, but it's a good testbed with
qemu for this so we could enable it).

* ppc64 -> 64 or 32, same deal as sparc64.

* sh4 -> i'm not familiar but i think there are more than 2 variants
that could be used at the same time?

* mips64 -> IIRC similar to sparc64 mixed ABI/bitness is possible.

For example back on gentoo times we had two separate toolchains for
kernel and userland for sparc64 (32ul/64k) which was the
reasonable/upstream default, these days it's multilib for that.
Question is, do we want to do the full multilib dance? (userland
components to match some blob prereq is the primary use for that).
Regards.

[Buildroot] [PATCH 1/2] arch/powerpc: add fsl e5500 and e6500 support

[Thomas Petazzoni]

Hello,

On Tue, 18 Nov 2014 13:28:05 -0300, Gustavo Zacarias wrote:

> Yes it is, i think we should deal with it.
> In most scenarios there aren't more than 2 possible combinations.

Yes, maybe we can restrict ourselves to certain fixed scenarios.

> * x86_64 -> i386, x32 (ugh), x86_64
> Most of the time you want the 64-bit kernel with one of i386 or x32.
> Bootloader might be subject to being built as 32-bit because of legacy.

Right.

> * sparc64 -> 64-v9 or 32-v9.
> Useful for a 64-bit kernel with 32ul mostly, or everything 64 (no
> multilib) (i know we don't support sparc64, but it's a good testbed with
> qemu for this so we could enable it).
> 
> * ppc64 -> 64 or 32, same deal as sparc64.
> 
> * sh4 -> i'm not familiar but i think there are more than 2 variants
> that could be used at the same time?

The main issue with sh4 is that you need the nofpu variant to be able
to build the kernel.

> * mips64 -> IIRC similar to sparc64 mixed ABI/bitness is possible.
> 
> For example back on gentoo times we had two separate toolchains for
> kernel and userland for sparc64 (32ul/64k) which was the
> reasonable/upstream default, these days it's multilib for that.
> Question is, do we want to do the full multilib dance? (userland
> components to match some blob prereq is the primary use for that).

What do you call the full multilib dance?

I guess if we go multilib, we should build the C library for both
"variants", but then build the rest of the userspace with only one of
the two variants, and keep the other variant just to build the special
stuff (kernel, bootloader, etc.).

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 1/2] arch/powerpc: add fsl e5500 and e6500 support

[Gustavo Zacarias]

On 11/18/2014 01:56 PM, Thomas Petazzoni wrote:
> What do you call the full multilib dance?
> 
> I guess if we go multilib, we should build the C library for both
> "variants", but then build the rest of the userspace with only one of
> the two variants, and keep the other variant just to build the special
> stuff (kernel, bootloader, etc.).

Building all (necessary) libraries as well to accomodate for ugly BLOBs
like the flash plugin or other cr^H^Hstuff like that, say i386 zlib and
more.
I don't think we want that.
Regards.

[Buildroot] [PATCH 1/2] arch/powerpc: add fsl e5500 and e6500 support

[Thomas Petazzoni]

Dear Gustavo Zacarias,

On Tue, 18 Nov 2014 14:00:19 -0300, Gustavo Zacarias wrote:
> On 11/18/2014 01:56 PM, Thomas Petazzoni wrote:
> > What do you call the full multilib dance?
> > 
> > I guess if we go multilib, we should build the C library for both
> > "variants", but then build the rest of the userspace with only one of
> > the two variants, and keep the other variant just to build the special
> > stuff (kernel, bootloader, etc.).
> 
> Building all (necessary) libraries as well to accomodate for ugly BLOBs
> like the flash plugin or other cr^H^Hstuff like that, say i386 zlib and
> more.
> I don't think we want that.

Unfortunately, it's typically the kind of thing that's very hard to do
with kconfig, as it would require the ability to specify for each
package for which multilib variant it should be built. Same issue as
having a per-package "build this statically" or "build this with
debugging symbol" option.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 1/2] arch/powerpc: add fsl e5500 and e6500 support

[Baruch Siach]

Hi Thomas,

On Tue, Nov 18, 2014 at 05:56:37PM +0100, Thomas Petazzoni wrote:
> I guess if we go multilib, we should build the C library for both
> "variants", but then build the rest of the userspace with only one of
> the two variants, and keep the other variant just to build the special
> stuff (kernel, bootloader, etc.).

Please forgive my ignorance, but why do we need a C library to build bare 
metal software like the kernel and bootloaders?

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

[Buildroot] [PATCH 1/2] arch/powerpc: add fsl e5500 and e6500 support

[Thomas Petazzoni]

Dear Baruch Siach,

On Tue, 18 Nov 2014 20:31:39 +0200, Baruch Siach wrote:

> On Tue, Nov 18, 2014 at 05:56:37PM +0100, Thomas Petazzoni wrote:
> > I guess if we go multilib, we should build the C library for both
> > "variants", but then build the rest of the userspace with only one of
> > the two variants, and keep the other variant just to build the special
> > stuff (kernel, bootloader, etc.).
> 
> Please forgive my ignorance, but why do we need a C library to build bare 
> metal software like the kernel and bootloaders?

We indeed normally don't in theory. It would be interesting to see if we
can actually build things like grub with a bare metal x86 32 bits
toolchain. I fear that in practice things might be a bit more
complicated, but it would be worth testing.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [RFC PATCH 0/2] Add Freescale e5500 & e6500 support

[Thomas Petazzoni]

Dear Gustavo Zacarias,

On Mon, 17 Nov 2014 20:14:50 -0300, Gustavo Zacarias wrote:

> Gustavo Zacarias (2):
>   arch/powerpc: add fsl e5500 and e6500 support
>   package/gcc: set e5500 and e6500 version mask

Patches applied. I must say I'm a bit confused by why we exclude PP64le
for those new platforms. Is there theoretically something that would
prevent those from being used in LE mode?

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [RFC PATCH 0/2] Add Freescale e5500 & e6500 support

[Gustavo Zacarias]

On 12/07/2014 07:48 PM, Thomas Petazzoni wrote:

> Patches applied. I must say I'm a bit confused by why we exclude PP64le
> for those new platforms. Is there theoretically something that would
> prevent those from being used in LE mode?

As far i was able to find out without hardware the fsl ppc64 SOCs aren't
able to boot in LE mode.
It's like ARM, if the peripherals aren't ready for it even though the
CPU itself can do so it won't work right.
For example for pseries there's the pseries_le_defconfig, for the fsl 64
bit chips there's corenet64_smp_defconfig but no LE counterpart.
Even though CONFIG_CPU_LITTLE_ENDIAN can be toggled for said config i
wasn't able to find anything related to actually booting that (and it's
a pretty generic option).
So i "erred" on the safe side.
Regards.

[Buildroot] [RFC PATCH 0/2] Add Freescale e5500 & e6500 support

[Thomas Petazzoni]

Dear Gustavo Zacarias,

On Sun, 07 Dec 2014 20:17:46 -0300, Gustavo Zacarias wrote:

> > Patches applied. I must say I'm a bit confused by why we exclude PP64le
> > for those new platforms. Is there theoretically something that would
> > prevent those from being used in LE mode?
> 
> As far i was able to find out without hardware the fsl ppc64 SOCs aren't
> able to boot in LE mode.
> It's like ARM, if the peripherals aren't ready for it even though the
> CPU itself can do so it won't work right.

Hum, right. I worked on an ARM platform that does support both LE and
BE. For most things, there is no need for any sort of BE/LE handling at
the peripheral level, except maybe for DMA descriptors shared by the
CPU and device (even though the CPU could do the effort of doing things
LE even if the system is running BE).

> For example for pseries there's the pseries_le_defconfig, for the fsl 64
> bit chips there's corenet64_smp_defconfig but no LE counterpart.
> Even though CONFIG_CPU_LITTLE_ENDIAN can be toggled for said config i
> wasn't able to find anything related to actually booting that (and it's
> a pretty generic option).
> So i "erred" on the safe side.

Ok, works for me.

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com