Add Freescale e5500 & e6500 support
cover Add Freescale e5500 & e6500 support
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(-)
Signature · 1 line
2.0.4
PATCH 1/2 arch/powerpc: add fsl e5500 and e6500 support
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.
--- arch/Config.in.powerpc | 7 +++++++ 1 file changed, 7 insertions(+)
arch/Config.in.powerpc +7 -0
@@ -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
Signature · 1 line
2.0.4
PATCH 1/2 arch/powerpc: add fsl e5500 and e6500 support
Gustavo,
Quoted 15 lines · 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 <[email protected]>--- arch/Config.in.powerpc | 7 +++++++ 1 file changed, 7 insertions(+)arch/Config.in.powerpc +0
-0
arch/Config.in.powerpc config BR2_powerpc_e300c3 · line 118
Quoted 10 lines
arch/Config.in.powerpc +7
-0@@ -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
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.
Quoted 10 lines
arch/Config.in.powerpc +0
-1config 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
Signature · 8 lines
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.
PATCH 1/2 arch/powerpc: add fsl e5500 and e6500 support
Quoted 6 lines · Matthew Weber
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.
PATCH 1/2 arch/powerpc: add fsl e5500 and e6500 support
Dear Gustavo Zacarias,
Quoted 10 lines · Gustavo Zacarias
Quoted 6 lines
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
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/2 arch/powerpc: add fsl e5500 and e6500 support
Quoted 9 lines · Thomas Petazzoni
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.
PATCH 1/2 arch/powerpc: add fsl e5500 and e6500 support
Hello,
Quoted 2 lines · Gustavo Zacarias
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.
Quoted 3 lines
*
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.
Quoted 9 lines
* 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.
Quoted 7 lines
* 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
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/2 arch/powerpc: add fsl e5500 and e6500 support
Quoted 6 lines · Thomas Petazzoni
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.
PATCH 1/2 arch/powerpc: add fsl e5500 and e6500 support
Dear Gustavo Zacarias,
Quoted 8 lines · Gustavo Zacarias
Quoted 6 lines · Thomas Petazzoni
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.).
Quoted 4 lines
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
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/2 arch/powerpc: add fsl e5500 and e6500 support
In reply to Thomas PetazzoniHi Thomas,
Quoted 4 lines · Thomas Petazzoni
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
Signature · 3 lines
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 -PATCH 1/2 arch/powerpc: add fsl e5500 and e6500 support
Dear Baruch Siach,
Quoted 8 lines · Baruch Siach
Quoted 4 lines · Thomas Petazzoni
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
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 2/2 package/gcc: set e5500 and e6500 version mask
In reply to Gustavo ZacariasFreescale e5500 and e6500 cores are supported for versions >= 4.8 So filter out all of the older versions to avoid build failures.
--- package/gcc/Config.in.host | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
package/gcc/Config.in.host +4 -2
@@ -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
Signature · 1 line
2.0.4
cover Add Freescale e5500 & e6500 support
In reply to Gustavo ZacariasDear Gustavo Zacarias,
Quoted 3 lines · Gustavo Zacarias
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
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
cover Add Freescale e5500 & e6500 support
Quoted 3 lines · Thomas Petazzoni
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.
cover Add Freescale e5500 & e6500 support
Dear Gustavo Zacarias,
Quoted 8 lines · Gustavo Zacarias
Quoted 3 lines
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).
Quoted 6 lines
For example for pseries there's the
pseries_le_defconfig, for the fsl 64 bit chips there'scorenet64_smp_defconfigbut no LE counterpart. Even thoughCONFIG_CPU_LITTLE_ENDIANcan 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
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com