Amit, Bryan:
Do you know what the correct setting for CONFIG_NEON is for MX51? In a discussion on IRC there was mention that there is a patch that makes it safe to turn on. Do you know if that patch has made it upstream?
Thanks, John
Bryan, I think you had worked on a patch to only turn on NEON on TO3+ but not on TO1/TO2 boards?
On Tue, Aug 31, 2010, John Rigby wrote:
Amit, Bryan:
Do you know what the correct setting for CONFIG_NEON is for MX51? In a discussion on IRC there was mention that there is a patch that makes it safe to turn on. Do you know if that patch has made it upstream?
Thanks, John
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On Wed, Sep 1, 2010 at 4:05 AM, Loïc Minier loic.minier@linaro.org wrote:
Bryan, I think you had worked on a patch to only turn on NEON on TO3+ but not on TO1/TO2 boards?
Exactly, That's a silicon issue of TO1 and TO2, but Freescale fixed it in TO3+. Here is the NEON patch: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git%3Ba=commitdiff%3Bh=60...
You guys can find the whole story in the BugLink. And I'm afraid this patch is just a workaround and Freescale won't support TO1/TO2 anymore. So it might be for upstream.
Thanks,
On Tue, Aug 31, 2010, John Rigby wrote:
Amit, Bryan:
Do you know what the correct setting for CONFIG_NEON is for MX51? In a discussion on IRC there was mention that there is a patch that makes it safe to turn on. Do you know if that patch has made it upstream?
Thanks, John
Thanks Bryan; Amit, what's your take on upstream TO1/TO2 support and on upstreaming this?
On Wed, Sep 01, 2010, Bryan Wu wrote:
Exactly, That's a silicon issue of TO1 and TO2, but Freescale fixed it in TO3+. Here is the NEON patch: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git%3Ba=commitdiff%3Bh=60...
You guys can find the whole story in the BugLink. And I'm afraid this patch is just a workaround and Freescale won't support TO1/TO2 anymore. So it might be for upstream.
Thanks,
On Tue, Aug 31, 2010, John Rigby wrote:
Amit, Bryan:
Do you know what the correct setting for CONFIG_NEON is for MX51? In a discussion on IRC there was mention that there is a patch that makes it safe to turn on. Do you know if that patch has made it upstream?
Thanks, John
That patch likely won't go upstream.
OTOH, how important is support below TO3?
TO1 won't even boot on Freescale's BSP, IIRC. AFAICT, Freescale isn't testing their BSP on TO2 if you take into account bugs like LP # 615722 [1] that caused bricking of Babbage 2.5 boards. And new HW is all TO3 and so is all known production HW. We only have a few TO2 boards now those will get rapidly get discarded when we get newer ones.
So, IMHO, enable NEON support and add to release-notes that TO1/2 is not supported.
[1]. https://bugs.edge.launchpad.net/ubuntu/+source/linux-fsl-imx51/+bug/615722
On 10 Sep 01, Loïc Minier wrote:
Thanks Bryan; Amit, what's your take on upstream TO1/TO2 support and on upstreaming this?
On Wed, Sep 01, 2010, Bryan Wu wrote:
Exactly, That's a silicon issue of TO1 and TO2, but Freescale fixed it in TO3+. Here is the NEON patch: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git%3Ba=commitdiff%3Bh=60...
You guys can find the whole story in the BugLink. And I'm afraid this patch is just a workaround and Freescale won't support TO1/TO2 anymore. So it might be for upstream.
Thanks,
Hi,
On Wed, Sep 1, 2010 at 12:23 PM, Amit Kucheria amit.kucheria@linaro.org wrote:
That patch likely won't go upstream.
OTOH, how important is support below TO3?
TO1 won't even boot on Freescale's BSP, IIRC. AFAICT, Freescale isn't testing their BSP on TO2 if you take into account bugs like LP # 615722 [1] that caused bricking of Babbage 2.5 boards. And new HW is all TO3 and so is all known production HW. We only have a few TO2 boards now those will get rapidly get discarded when we get newer ones.
So, IMHO, enable NEON support and add to release-notes that TO1/2 is not supported.
We could carry the patch for a bit, but I agree it's probably not worth getting it upstream.
I believe the number of real devices with TO2 is small and no new devices with TO2 are anticipated.
Last I remember, Ubuntu uses a lot of armel buildds based on TO2 hardware though--- we should bear that in mind, though the situation may have changed in the meantime.
Cheers ---Dave
On Wed, Sep 01, 2010, Amit Kucheria wrote:
That patch likely won't go upstream.
Why not?
OTOH, how important is support below TO3?
For Linaro, not too important I guess, some people have TO2 hardware, some Babbage 2.0 or 2.5, albeit 2.0 is not really supported anymore. EfikaMX also comes in both TO2 and TO3. Finally, some mass-market / public hardware like Sharp Netwalker are TO2 based.
TO1 won't even boot on Freescale's BSP, IIRC. AFAICT, Freescale isn't testing their BSP on TO2 if you take into account bugs like LP # 615722 [1] that caused bricking of Babbage 2.5 boards. And new HW is all TO3 and so is all known production HW. We only have a few TO2 boards now those will get rapidly get discarded when we get newer ones.
Some months back, in the beginning of this year, I heard of commercial projects targetting TO2 to save some money on the chip. There's also some mass-market / public TO2 hardware in the form of the netwalker.
So, IMHO, enable NEON support and add to release-notes that TO1/2 is not supported.
We can do that in Linaro, I'm just a bit uncomfortable that there is a non-trivial amount of TO2 devices out there, and it's a DoS issue to have this NEON flaw.
I would be ok if we would only support TO3 and the kernel wouldn't boot on TO2 hardware, but AIUI the kernel will boot just fine and turn on NEON on TO2 such as Babbage 2.x, so I'm a bit scared by just release noting it.
On 10 Sep 01, Loïc Minier wrote:
On Wed, Sep 01, 2010, Amit Kucheria wrote:
That patch likely won't go upstream.
Why not?
Because it adds a sub-arch, revision-specific override into generic architecture code (vfpmodule.c)
To do this elegantly with a hope to get it to mainline, we'd need a way to disable the hwcap through some board-specific fixup code that can check the revision of the board at runtime.
Unfortunately, it seems after talking to Nicolas that mdesc->fixup() is called too early.
Nicolas suggested linking the i.MX5 code _after_ the VFP module :)
OTOH, how important is support below TO3?
For Linaro, not too important I guess, some people have TO2 hardware, some Babbage 2.0 or 2.5, albeit 2.0 is not really supported anymore. EfikaMX also comes in both TO2 and TO3. Finally, some mass-market / public hardware like Sharp Netwalker are TO2 based.
TO1 won't even boot on Freescale's BSP, IIRC. AFAICT, Freescale isn't testing their BSP on TO2 if you take into account bugs like LP # 615722 [1] that caused bricking of Babbage 2.5 boards. And new HW is all TO3 and so is all known production HW. We only have a few TO2 boards now those will get rapidly get discarded when we get newer ones.
Some months back, in the beginning of this year, I heard of commercial projects targetting TO2 to save some money on the chip. There's also some mass-market / public TO2 hardware in the form of the netwalker.
I hope they didn't get bitten by the bricking problems.
So, IMHO, enable NEON support and add to release-notes that TO1/2 is not supported.
We can do that in Linaro, I'm just a bit uncomfortable that there is a non-trivial amount of TO2 devices out there, and it's a DoS issue to have this NEON flaw.
I would be ok if we would only support TO3 and the kernel wouldn't boot on TO2 hardware, but AIUI the kernel will boot just fine and turn on NEON on TO2 such as Babbage 2.x, so I'm a bit scared by just release noting it.
Another solution is that we could perhaps add code in the board init function to check the cpu revision and if NEON was enabled, then stop booting.
/Amit
On Wed, Sep 01, 2010 at 03:56:15PM +0300, Amit Kucheria wrote:
Because it adds a sub-arch, revision-specific override into generic architecture code (vfpmodule.c)
To do this elegantly with a hope to get it to mainline, we'd need a way to disable the hwcap through some board-specific fixup code that can check the revision of the board at runtime.
Unfortunately, it seems after talking to Nicolas that mdesc->fixup() is called too early.
Nicolas suggested linking the i.MX5 code _after_ the VFP module :)
Hmm; I would rather we tried a bit harder to find a solution which was workable upstream. I'm surprised there's no generic facility to do fixups of this sort given how fast we've run into the problem -- a hint towards something the KCWG could improve?
We can do that in Linaro, I'm just a bit uncomfortable that there is a non-trivial amount of TO2 devices out there, and it's a DoS issue to have this NEON flaw.
I would be ok if we would only support TO3 and the kernel wouldn't boot on TO2 hardware, but AIUI the kernel will boot just fine and turn on NEON on TO2 such as Babbage 2.x, so I'm a bit scared by just release noting it.
Another solution is that we could perhaps add code in the board init function to check the cpu revision and if NEON was enabled, then stop booting.
That's a backup plan I'd be mildly okay with; I don't like the idea of the Linaro kernel booting on even less hardware ;-)
On Wed, Sep 1, 2010 at 3:56 PM, Amit Kucheria amit.kucheria@linaro.org wrote:
I would be ok if we would only support TO3 and the kernel wouldn't boot on TO2 hardware, but AIUI the kernel will boot just fine and turn on NEON on TO2 such as Babbage 2.x, so I'm a bit scared by just release noting it.
Another solution is that we could perhaps add code in the board init function to check the cpu revision and if NEON was enabled, then stop booting.
This is what the patch would look like (not-even compile tested)
On Wed, Sep 01, 2010, Amit Kucheria wrote:
Because it adds a sub-arch, revision-specific override into generic architecture code (vfpmodule.c)
To do this elegantly with a hope to get it to mainline, we'd need a way to disable the hwcap through some board-specific fixup code that can check the revision of the board at runtime.
Unfortunately, it seems after talking to Nicolas that mdesc->fixup() is called too early.
Nicolas suggested linking the i.MX5 code _after_ the VFP module :)
Sounds like a plan!
Another solution is that we could perhaps add code in the board init function to check the cpu revision and if NEON was enabled, then stop booting.
Would be a good workaround if the elegant version takes too long
On Wed, 1 Sep 2010, Amit Kucheria wrote:
On 10 Sep 01, Loïc Minier wrote:
On Wed, Sep 01, 2010, Amit Kucheria wrote:
That patch likely won't go upstream.
Why not?
Because it adds a sub-arch, revision-specific override into generic architecture code (vfpmodule.c)
To do this elegantly with a hope to get it to mainline, we'd need a way to disable the hwcap through some board-specific fixup code that can check the revision of the board at runtime.
Right. I eventually dismissed that idea on the basis that the silicon revision in question was pre production stuff. But if there are actual devices out there using it then we need something for it that is mainline acceptable.
Unfortunately, it seems after talking to Nicolas that mdesc->fixup() is called too early.
Nicolas suggested linking the i.MX5 code _after_ the VFP module :)
Something like this patch:
----- >8 From: Nicolas Pitre nicolas.pitre@linaro.org Date: Wed, 1 Sep 2010 09:37:05 -0400 Subject: [PATCH] ARM: link board specific files after core files
This allows for board specific issues to override decisions made in generic code that might not be suitable due to some errata or the like.
Signed-off-by: Nicolas Pitre nicolas.pitre@linaro.org
diff --git a/arch/arm/Makefile b/arch/arm/Makefile index df4ab3c..3e8e3d7 100644 --- a/arch/arm/Makefile +++ b/arch/arm/Makefile @@ -243,13 +243,14 @@ ifeq ($(FASTFPE),$(wildcard $(FASTFPE))) FASTFPE_OBJ :=$(FASTFPE)/ endif
-# If we have a machine-specific directory, then include it in the build. -core-y += arch/arm/kernel/ arch/arm/mm/ arch/arm/common/ -core-y += $(machdirs) $(platdirs) core-$(CONFIG_FPE_NWFPE) += arch/arm/nwfpe/ core-$(CONFIG_FPE_FASTFPE) += $(FASTFPE_OBJ) core-$(CONFIG_VFP) += arch/arm/vfp/
+# If we have a machine-specific directory, then include it in the build. +core-y += arch/arm/kernel/ arch/arm/mm/ arch/arm/common/ +core-y += $(machdirs) $(platdirs) + drivers-$(CONFIG_OPROFILE) += arch/arm/oprofile/
libs-y := arch/arm/lib/ $(libs-y) 8< -----
Then, just add your fixup in a separate patch. Beware: the above patch is untested.
Another solution is that we could perhaps add code in the board init function to check the cpu revision and if NEON was enabled, then stop booting.
That is a bit blunt for the user though, and that forces a different kernel config depending on the silicon revision which is also bad.
Nicolas
On 10 Sep 01, Nicolas Pitre wrote:
On Wed, 1 Sep 2010, Amit Kucheria wrote:
[snip]
Unfortunately, it seems after talking to Nicolas that mdesc->fixup() is called too early.
Nicolas suggested linking the i.MX5 code _after_ the VFP module :)
Something like this patch:
----- >8 From: Nicolas Pitre nicolas.pitre@linaro.org Date: Wed, 1 Sep 2010 09:37:05 -0400 Subject: [PATCH] ARM: link board specific files after core files
This allows for board specific issues to override decisions made in generic code that might not be suitable due to some errata or the like.
Signed-off-by: Nicolas Pitre nicolas.pitre@linaro.org
diff --git a/arch/arm/Makefile b/arch/arm/Makefile index df4ab3c..3e8e3d7 100644 --- a/arch/arm/Makefile +++ b/arch/arm/Makefile @@ -243,13 +243,14 @@ ifeq ($(FASTFPE),$(wildcard $(FASTFPE))) FASTFPE_OBJ :=$(FASTFPE)/ endif -# If we have a machine-specific directory, then include it in the build. -core-y += arch/arm/kernel/ arch/arm/mm/ arch/arm/common/ -core-y += $(machdirs) $(platdirs) core-$(CONFIG_FPE_NWFPE) += arch/arm/nwfpe/ core-$(CONFIG_FPE_FASTFPE) += $(FASTFPE_OBJ) core-$(CONFIG_VFP) += arch/arm/vfp/ +# If we have a machine-specific directory, then include it in the build. +core-y += arch/arm/kernel/ arch/arm/mm/ arch/arm/common/ +core-y += $(machdirs) $(platdirs)
drivers-$(CONFIG_OPROFILE) += arch/arm/oprofile/ libs-y := arch/arm/lib/ $(libs-y) 8< -----
Then, just add your fixup in a separate patch. Beware: the above patch is untested.
My fixup patch is attached. Compile-tested along with Nico's patch. But I have no TO1/TO2 boards to test. Loic do know anybody that can test with Nico's patch and this fixup?
From caad712990cccb705b44414830d41142277538b8 Mon Sep 17 00:00:00 2001
Message-Id: caad712990cccb705b44414830d41142277538b8.1283370628.git.amit.kucheria@linaro.org From: Amit Kucheria amit.kucheria@linaro.org Date: Wed, 1 Sep 2010 22:49:13 +0300 Subject: [PATCH] mxc: turn off HWCAP_NEON for older versions of imx51 silicon
Versions of silicon older than TO3 have broken NEON implementation. Turn off NEON in such cases.
Signed-off-by: Amit Kucheria amit.kucheria@linaro.org --- arch/arm/mach-mx5/board-mx51_babbage.c | 9 +++++++++ arch/arm/mach-mx5/cpu.c | 15 +++++++++++++++ 2 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-mx5/board-mx51_babbage.c b/arch/arm/mach-mx5/board-mx51_babbage.c index 6e384d9..65d1d2c 100644 --- a/arch/arm/mach-mx5/board-mx51_babbage.c +++ b/arch/arm/mach-mx5/board-mx51_babbage.c @@ -45,6 +45,8 @@ #define MX51_USB_PLL_DIV_19_2_MHZ 0x01 #define MX51_USB_PLL_DIV_24_MHZ 0x02
+extern void mx51_neon_fixup(void); + static struct platform_device *devices[] __initdata = { &mxc_fec_device, }; @@ -240,6 +242,12 @@ static int __init babbage_otg_mode(char *options) } __setup("otg_mode=", babbage_otg_mode);
+static void __init fixup_mx51_babbage(struct machine_desc *desc, + struct tag *tags, char **cmdline, struct meminfo *mi) +{ + mx51_neon_fixup(); +} + /* * Board specific initialization. */ @@ -284,6 +292,7 @@ MACHINE_START(MX51_BABBAGE, "Freescale MX51 Babbage Board") .phys_io = MX51_AIPS1_BASE_ADDR, .io_pg_offst = ((MX51_AIPS1_BASE_ADDR_VIRT) >> 18) & 0xfffc, .boot_params = PHYS_OFFSET + 0x100, + .fixup = fixup_mx51_babbage, .map_io = mx51_map_io, .init_irq = mx51_init_irq, .init_machine = mxc_board_init, diff --git a/arch/arm/mach-mx5/cpu.c b/arch/arm/mach-mx5/cpu.c index 2d37785..8d081c6 100644 --- a/arch/arm/mach-mx5/cpu.c +++ b/arch/arm/mach-mx5/cpu.c @@ -70,6 +70,21 @@ int mx51_revision(void) } EXPORT_SYMBOL(mx51_revision);
+#ifdef CONFIG_NEON +/* All versions of the silicon before Rev. 3 have broken NEON implementations */ +void mx51_neon_fixup(void) +{ + if (mx51_revision() < MX51_CHIP_REV_3_0) { + if (elf_hwcap & HWCAP_NEON) { + elf_hwcap &= ~HWCAP_NEON; + pr_info("Turning off NEON support, detected broken NEON implemention\n"); + } + } +} +#else +void mx51_neon_fixup(void) {} +#endif + static int __init post_cpu_init(void) { unsigned int reg;
On Wed, 1 Sep 2010, Amit Kucheria wrote:
On 10 Sep 01, Nicolas Pitre wrote:
On Wed, 1 Sep 2010, Amit Kucheria wrote:
[snip]
Unfortunately, it seems after talking to Nicolas that mdesc->fixup() is called too early.
Nicolas suggested linking the i.MX5 code _after_ the VFP module :)
Something like this patch:
----- >8 From: Nicolas Pitre nicolas.pitre@linaro.org Date: Wed, 1 Sep 2010 09:37:05 -0400 Subject: [PATCH] ARM: link board specific files after core files
This allows for board specific issues to override decisions made in generic code that might not be suitable due to some errata or the like.
Signed-off-by: Nicolas Pitre nicolas.pitre@linaro.org
diff --git a/arch/arm/Makefile b/arch/arm/Makefile index df4ab3c..3e8e3d7 100644 --- a/arch/arm/Makefile +++ b/arch/arm/Makefile @@ -243,13 +243,14 @@ ifeq ($(FASTFPE),$(wildcard $(FASTFPE))) FASTFPE_OBJ :=$(FASTFPE)/ endif -# If we have a machine-specific directory, then include it in the build. -core-y += arch/arm/kernel/ arch/arm/mm/ arch/arm/common/ -core-y += $(machdirs) $(platdirs) core-$(CONFIG_FPE_NWFPE) += arch/arm/nwfpe/ core-$(CONFIG_FPE_FASTFPE) += $(FASTFPE_OBJ) core-$(CONFIG_VFP) += arch/arm/vfp/ +# If we have a machine-specific directory, then include it in the build. +core-y += arch/arm/kernel/ arch/arm/mm/ arch/arm/common/ +core-y += $(machdirs) $(platdirs)
drivers-$(CONFIG_OPROFILE) += arch/arm/oprofile/ libs-y := arch/arm/lib/ $(libs-y) 8< -----
Then, just add your fixup in a separate patch. Beware: the above patch is untested.
My fixup patch is attached. Compile-tested along with Nico's patch. But I have no TO1/TO2 boards to test. Loic do know anybody that can test with Nico's patch and this fixup?
[...]
@@ -284,6 +292,7 @@ MACHINE_START(MX51_BABBAGE, "Freescale MX51 Babbage Board") .phys_io = MX51_AIPS1_BASE_ADDR, .io_pg_offst = ((MX51_AIPS1_BASE_ADDR_VIRT) >> 18) & 0xfffc, .boot_params = PHYS_OFFSET + 0x100,
- .fixup = fixup_mx51_babbage, .map_io = mx51_map_io, .init_irq = mx51_init_irq, .init_machine = mxc_board_init,
This won't work as this is called way too early.
I'd suggest calling mx51_neon_fixup() through a late_initcall instead. And making it __init too.
Nicolas
Nico and Amit,
Thanks for this quickly solution. I believe it is much better than my dirty hack in our Ubuntu Lucid kernel and it's good for upstream to me.
My TO2 BB2.5 board is bricked, so maybe we need other folks with the hardware for testing.
Thanks, -Bryan
On Thu, Sep 2, 2010 at 4:12 AM, Nicolas Pitre nicolas.pitre@linaro.org wrote:
On Wed, 1 Sep 2010, Amit Kucheria wrote:
On 10 Sep 01, Nicolas Pitre wrote:
On Wed, 1 Sep 2010, Amit Kucheria wrote:
[snip]
Unfortunately, it seems after talking to Nicolas that mdesc->fixup() is called too early.
Nicolas suggested linking the i.MX5 code _after_ the VFP module :)
Something like this patch:
----- >8 From: Nicolas Pitre nicolas.pitre@linaro.org Date: Wed, 1 Sep 2010 09:37:05 -0400 Subject: [PATCH] ARM: link board specific files after core files
This allows for board specific issues to override decisions made in generic code that might not be suitable due to some errata or the like.
Signed-off-by: Nicolas Pitre nicolas.pitre@linaro.org
diff --git a/arch/arm/Makefile b/arch/arm/Makefile index df4ab3c..3e8e3d7 100644 --- a/arch/arm/Makefile +++ b/arch/arm/Makefile @@ -243,13 +243,14 @@ ifeq ($(FASTFPE),$(wildcard $(FASTFPE))) FASTFPE_OBJ :=$(FASTFPE)/ endif
-# If we have a machine-specific directory, then include it in the build. -core-y += arch/arm/kernel/ arch/arm/mm/ arch/arm/common/ -core-y += $(machdirs) $(platdirs) core-$(CONFIG_FPE_NWFPE) += arch/arm/nwfpe/ core-$(CONFIG_FPE_FASTFPE) += $(FASTFPE_OBJ) core-$(CONFIG_VFP) += arch/arm/vfp/
+# If we have a machine-specific directory, then include it in the build. +core-y += arch/arm/kernel/ arch/arm/mm/ arch/arm/common/ +core-y += $(machdirs) $(platdirs)
drivers-$(CONFIG_OPROFILE) += arch/arm/oprofile/
libs-y := arch/arm/lib/ $(libs-y) 8< -----
Then, just add your fixup in a separate patch. Beware: the above patch is untested.
My fixup patch is attached. Compile-tested along with Nico's patch. But I have no TO1/TO2 boards to test. Loic do know anybody that can test with Nico's patch and this fixup?
[...]
@@ -284,6 +292,7 @@ MACHINE_START(MX51_BABBAGE, "Freescale MX51 Babbage Board") .phys_io = MX51_AIPS1_BASE_ADDR, .io_pg_offst = ((MX51_AIPS1_BASE_ADDR_VIRT) >> 18) & 0xfffc, .boot_params = PHYS_OFFSET + 0x100,
- .fixup = fixup_mx51_babbage,
.map_io = mx51_map_io, .init_irq = mx51_init_irq, .init_machine = mxc_board_init,
This won't work as this is called way too early.
I'd suggest calling mx51_neon_fixup() through a late_initcall instead. And making it __init too.
Nicolas
On Thu, Sep 2, 2010 at 4:19 AM, Bryan Wu bryan.wu@canonical.com wrote:
Nico and Amit,
Thanks for this quickly solution. I believe it is much better than my dirty hack in our Ubuntu Lucid kernel and it's good for upstream to me.
My TO2 BB2.5 board is bricked, so maybe we need other folks with the hardware for testing.
I also have a bricked 2.5 board...
Otherwise, I have only Babbage 2.0 (TO2) and 3.0 (TO3), and Pegatron nettops (TO2).
I can try and test, but I believe the upstream kernel and linaro tree may not work on babbage 2.0 or the nettops... does anyone know better?
Cheers ---Dave
On Thu, Sep 2, 2010 at 11:44 AM, Dave Martin dave.martin@linaro.org wrote:
On Thu, Sep 2, 2010 at 4:19 AM, Bryan Wu bryan.wu@canonical.com wrote:
Nico and Amit,
Thanks for this quickly solution. I believe it is much better than my dirty hack in our Ubuntu Lucid kernel and it's good for upstream to me.
My TO2 BB2.5 board is bricked, so maybe we need other folks with the hardware for testing.
I also have a bricked 2.5 board...
Same here. :-/
Otherwise, I have only Babbage 2.0 (TO2) and 3.0 (TO3), and Pegatron nettops (TO2).
I can try and test, but I believe the upstream kernel and linaro tree may not work on babbage 2.0 or the nettops... does anyone know better?
The Babbage 2.0 _might_ work. Nobody has tried it yet.
I guess I should get the board file for the efikamx done quickly. I'm told it is similar (identical?) to the pegatron nettops.
/Amit
Hi,
The Babbage 2.0 _might_ work. Nobody has tried it yet.
I guess I should get the board file for the efikamx done quickly. I'm told it is similar (identical?) to the pegatron nettops.
That was my understanding too, though I haven't got my hands on one to compare.
It would be good to have efikamx supported in the linaro kernel, at least at a basic level.
Cheers ---Dave
On 10 Sep 01, Nicolas Pitre wrote:
On Wed, 1 Sep 2010, Amit Kucheria wrote:
On 10 Sep 01, Nicolas Pitre wrote:
[...]
@@ -284,6 +292,7 @@ MACHINE_START(MX51_BABBAGE, "Freescale MX51 Babbage Board") .phys_io = MX51_AIPS1_BASE_ADDR, .io_pg_offst = ((MX51_AIPS1_BASE_ADDR_VIRT) >> 18) & 0xfffc, .boot_params = PHYS_OFFSET + 0x100,
- .fixup = fixup_mx51_babbage, .map_io = mx51_map_io, .init_irq = mx51_init_irq, .init_machine = mxc_board_init,
This won't work as this is called way too early.
I'd suggest calling mx51_neon_fixup() through a late_initcall instead. And making it __init too.
Argh! You're right.
It becomes a lot simpler with just late_init. Fixed patch attached.
From 141ab741491a314bb05a4f17f9cba0870d76c74e Mon Sep 17 00:00:00 2001
Message-Id: 141ab741491a314bb05a4f17f9cba0870d76c74e.1283410133.git.amit.kucheria@linaro.org From: Amit Kucheria amit.kucheria@linaro.org Date: Wed, 1 Sep 2010 22:49:13 +0300 Subject: [PATCH] mxc: turn off HWCAP_NEON for older versions of imx51 silicon
Versions of silicon older than TO3 have broken NEON implementation. Turn off NEON in such cases.
Signed-off-by: Amit Kucheria amit.kucheria@linaro.org --- arch/arm/mach-mx5/cpu.c | 23 +++++++++++++++++++++++ 1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-mx5/cpu.c b/arch/arm/mach-mx5/cpu.c index 2d37785..ba5f6be 100644 --- a/arch/arm/mach-mx5/cpu.c +++ b/arch/arm/mach-mx5/cpu.c @@ -70,6 +70,28 @@ int mx51_revision(void) } EXPORT_SYMBOL(mx51_revision);
+#ifdef CONFIG_NEON + +/* All versions of the silicon before Rev. 3 have broken NEON implementations. + * Dependent on link order - so the assumption is that vfp_init is called before us + */ +static int __init mx51_neon_fixup(void) +{ + if (mx51_revision() < MX51_CHIP_REV_3_0) { + if (elf_hwcap & HWCAP_NEON) { + elf_hwcap &= ~HWCAP_NEON; + pr_info("Turning off NEON support, detected broken NEON implemention\n"); + } + } + return 0; +} +#else +void mx51_neon_fixup(void) +{ + return 0; +} +#endif + static int __init post_cpu_init(void) { unsigned int reg; @@ -98,3 +120,4 @@ static int __init post_cpu_init(void) }
postcore_initcall(post_cpu_init); +late_initcall(mx51_neon_fixup);
On Thu, 2 Sep 2010, Amit Kucheria wrote:
On 10 Sep 01, Nicolas Pitre wrote:
On Wed, 1 Sep 2010, Amit Kucheria wrote:
On 10 Sep 01, Nicolas Pitre wrote:
[...]
@@ -284,6 +292,7 @@ MACHINE_START(MX51_BABBAGE, "Freescale MX51 Babbage Board") .phys_io = MX51_AIPS1_BASE_ADDR, .io_pg_offst = ((MX51_AIPS1_BASE_ADDR_VIRT) >> 18) & 0xfffc, .boot_params = PHYS_OFFSET + 0x100,
- .fixup = fixup_mx51_babbage, .map_io = mx51_map_io, .init_irq = mx51_init_irq, .init_machine = mxc_board_init,
This won't work as this is called way too early.
I'd suggest calling mx51_neon_fixup() through a late_initcall instead. And making it __init too.
Argh! You're right.
It becomes a lot simpler with just late_init. Fixed patch attached.
You could make this even simpler still.
diff --git a/arch/arm/mach-mx5/cpu.c b/arch/arm/mach-mx5/cpu.c index 2d37785..ba5f6be 100644 --- a/arch/arm/mach-mx5/cpu.c +++ b/arch/arm/mach-mx5/cpu.c @@ -70,6 +70,28 @@ int mx51_revision(void) } EXPORT_SYMBOL(mx51_revision); +#ifdef CONFIG_NEON
+/* All versions of the silicon before Rev. 3 have broken NEON implementations.
- Dependent on link order - so the assumption is that vfp_init is called before us
- */
+static int __init mx51_neon_fixup(void) +{
- if (mx51_revision() < MX51_CHIP_REV_3_0) {
if (elf_hwcap & HWCAP_NEON) {elf_hwcap &= ~HWCAP_NEON;pr_info("Turning off NEON support, detected broken NEON implemention\n");}- }
- return 0;
+} +#else +void mx51_neon_fixup(void) +{
- return 0;
+} +#endif
Instead of having this empty mx51_neon_fixup() in the #else part...
@@ -98,3 +120,4 @@ static int __init post_cpu_init(void) } postcore_initcall(post_cpu_init); +late_initcall(mx51_neon_fixup);
... why don't you move this late_initcall() _inside_ the #ifdef CONFIG_NEON ?
Nicolas
On 10 Sep 02, Nicolas Pitre wrote:
On Thu, 2 Sep 2010, Amit Kucheria wrote:
Instead of having this empty mx51_neon_fixup() in the #else part...
@@ -98,3 +120,4 @@ static int __init post_cpu_init(void) } postcore_initcall(post_cpu_init); +late_initcall(mx51_neon_fixup);
... why don't you move this late_initcall() _inside_ the #ifdef CONFIG_NEON ?
Elegant. Please find patch attached. If someone with a TO2 board can test this, there is a uImage with this patch and Nico's at http://people.canonical.com/~amitk/imx5/uImage
Regards, Amit
From ee41c96eb92a1561cbbde6bafffa87ba11c7544d Mon Sep 17 00:00:00 2001
Message-Id: ee41c96eb92a1561cbbde6bafffa87ba11c7544d.1283442320.git.amit.kucheria@linaro.org From: Amit Kucheria amit.kucheria@verdurent.com Date: Wed, 1 Sep 2010 22:49:13 +0300 Subject: [PATCH] mxc: turn off HWCAP_NEON for older versions of imx51 silicon
Versions of silicon older than TO3 have broken NEON implementation. Turn off NEON in such cases.
Signed-off-by: Amit Kucheria amit.kucheria@linaro.org --- arch/arm/mach-mx5/cpu.c | 19 +++++++++++++++++++ 1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-mx5/cpu.c b/arch/arm/mach-mx5/cpu.c index 2d37785..06e1717 100644 --- a/arch/arm/mach-mx5/cpu.c +++ b/arch/arm/mach-mx5/cpu.c @@ -70,6 +70,25 @@ int mx51_revision(void) } EXPORT_SYMBOL(mx51_revision);
+#ifdef CONFIG_NEON + +/* All versions of the silicon before Rev. 3 have broken NEON implementations. + * Dependent on link order - so the assumption is that vfp_init is called before us + */ +static int __init mx51_neon_fixup(void) +{ + if (mx51_revision() < MX51_CHIP_REV_3_0) { + if (elf_hwcap & HWCAP_NEON) { + elf_hwcap &= ~HWCAP_NEON; + pr_info("Turning off NEON support, detected broken NEON implemention\n"); + } + } + return 0; +} + +late_initcall(mx51_neon_fixup); +#endif + static int __init post_cpu_init(void) { unsigned int reg;
-
Amit Kucheria -
Bryan Wu -
Christian Robottom Reis -
Dave Martin -
John Rigby -
Loïc Minier -
Nicolas Pitre