This bug was fixed in the package linux-fsl-imx51 - 2.6.31-111.27
---
linux-fsl-imx51 (2.6.31-111.27) karmic-proposed; urgency=low
[ Bryan Wu ]
* [Config] built in SMSC_PHY driver for fsl-imx51
- LP: #546649
* SAUCE: fsl-imx51: sync karmic fec.c driver with lucid fec.c
Hi there,
Try the attached modification. It looks like I forgot to force the
correct data alignment in the test program.
Something must have changed in libc in the meantime, altering the link
map slightly and pushing the data off by a word. In this case, an
alignment fault is the correct thing
Thanks Dave, that worked! The kernel in question here has neon turned
on, and passes the updated regression test attached to this bug.
** Tags added: verification-done
** Tags removed: verification-failed
--
CONFIG_NEON=y causes platform lockups with certain application/platform
combinations
neon certainly seems to be turned on now, however the testcase attached to this
bug fails (and fails in lucid as well). I get illegal instruction when running
either one of them, and get the following in dmesg:
Alignment trap: not handling instruction f920079f at [83f0]
Unhandled fault:
CONFIG_NEON does not seem to be enabled in the proposed kernel
--
CONFIG_NEON=y causes platform lockups with certain application/platform
combinations
https://bugs.launchpad.net/bugs/507416
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct subscriber.
** Tags added: verification-failed
** Tags removed: verification-needed
--
CONFIG_NEON=y causes platform lockups with certain application/platform
combinations
https://bugs.launchpad.net/bugs/507416
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct
Emmet asked me to drop this kernel from karmic-proposed, since it was
incomplete and needs more fixes.
** Changed in: linux-fsl-imx51 (Ubuntu Karmic)
Status: Fix Committed = Triaged
--
CONFIG_NEON=y causes platform lockups with certain application/platform
combinations
Re-accepted into karmic-proposed; the removal was a misunderstanding,
sorry. Please test and give feedback here.
Thanks!
** Changed in: linux-fsl-imx51 (Ubuntu Karmic)
Status: Triaged = Fix Committed
--
CONFIG_NEON=y causes platform lockups with certain application/platform
After discussing with Dave, I found ASEDIS is no available in Cortex A8
based SoC. It is available in Cortex A9. So our plan to disable NEON
hardware entirely by setting ASEDIS on TO2 silicon is impossible now.
Generally, for this silicon issue there is no more workaround so far.
And the patches
Close it for Lucid, if find another workaround method, please reopen it.
** Changed in: linux-fsl-imx51 (Ubuntu Lucid)
Status: Confirmed = Fix Released
--
CONFIG_NEON=y causes platform lockups with certain application/platform
combinations
https://bugs.launchpad.net/bugs/507416
You
** Description changed:
Observed for example running ffplay to decode H.264 video on Babbage 2.0
This needs to be worked around by a separate kernel image for the
affected platforms, or the ability to enable or disable CONFIG_NEON at
boot.
Note that the principal problem here is
For Karmic -proposed, I think we still need to provide another patch to
set ASEDIS for =TO2. I am working on this and will provide patch soon.
-Bryan
--
CONFIG_NEON=y causes platform lockups with certain application/platform
combinations
https://bugs.launchpad.net/bugs/507416
You received this
** Branch linked: lp:ubuntu/karmic-proposed/linux-fsl-imx51
--
CONFIG_NEON=y causes platform lockups with certain application/platform
combinations
https://bugs.launchpad.net/bugs/507416
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct subscriber.
Accepted linux-fsl-imx51 into karmic-proposed, the package will build
now and be available in a few hours. Please test and give feedback here.
See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you in advance!
** Changed in: linux-fsl-imx51
closing the uboot task, for karmic uboot-imx doesnt exist, in lucid a
patch is added that spits out the right revision numbers
** Changed in: uboot-imx (Ubuntu Karmic)
Status: New = Invalid
** Changed in: uboot-imx (Ubuntu Lucid)
Status: Triaged = Fix Released
--
CONFIG_NEON=y
** Also affects: linux-fsl-imx51 (Ubuntu Karmic)
Importance: Undecided
Status: New
** Also affects: uboot-imx (Ubuntu Karmic)
Importance: Undecided
Status: New
** Also affects: linux-fsl-imx51 (Ubuntu Lucid)
Importance: High
Assignee: Bryan Wu (cooloney)
Bryan, Martin - After chatting with Freescale I'm proposing to SRU the
NEON detection patch to Karmic. Are you both still of the opinion that
the ASEDIS fix for rev 3 is still unnecessary ?
Oliver - will the uboot-imx supply the correct version since I assume
the patch mentioned in
we dont use uboot-imx in ubuntu yet (the latest code drop shuold have a
patch for setting the revision numbers right though), redboot (which we
use across all releases) definately sets the proper revision numbers.
--
CONFIG_NEON=y causes platform lockups with certain application/platform
** Tags added: patch
--
CONFIG_NEON=y causes platform lockups with certain application/platform
combinations
https://bugs.launchpad.net/bugs/507416
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct subscriber.
--
ubuntu-bugs mailing list
Karmic SRU
Justification: Enable NEON support for Freescale imx51 rev 3 boards
Impact: Applications that _could_ use NEON instructions to speedup
encode/decode operations (youtube, etc) are forced to operate in full emulation
mode.
Patch description: Detect NEON capability at kernel boot time
It looks like it's possible to implement the additional unaligned access
emulation for Thumb-2, but it may involve a non-trivial amount of work.
In particular, loads and stores behave differently for ThumbEE compared
with normal Thumb-2. ThumbEE is not much used at present, so it would
probably
Re-opening the bug to discuss some new issues.
Both of these problems are effectively present in the previous Ubuntu
releases on imx51, as well as lucid.
1) CONFIG_NEON=n doesn't actually disable the use of NEON instructions
(I misinderstood things here). It should be straightforward to improve
@Dave,
Appreciate for this useful information.
If I understand correctly, I think our goal is to make one kernel for
all the imx51 silicon. On the good silicon, we enable all the NEON and
VFP. On the bad silicon, we disable the NEON and add some hack in
unaligned access code.
So we are going to
** Changed in: linux-fsl-imx51 (Ubuntu)
Status: Triaged = Fix Committed
--
CONFIG_NEON=y causes platform lockups with certain application/platform
combinations
https://bugs.launchpad.net/bugs/507416
You received this bug notification because you are a member of Ubuntu
Bugs, which is a
This bug was fixed in the package linux-fsl-imx51 - 2.6.31-603.5
---
linux-fsl-imx51 (2.6.31-603.5) lucid; urgency=low
[ Bryan Wu ]
* [Config] Enable devtmpfs for fsl-imx51 kernel
- LP: #512321
* SAUCE: IMX51: only export NEON flag to userspace on Freescale iMX51
** Branch linked: lp:ubuntu/linux-fsl-imx51
--
CONFIG_NEON=y causes platform lockups with certain application/platform
combinations
https://bugs.launchpad.net/bugs/507416
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct subscriber.
--
ubuntu-bugs
** Visibility changed to: Public
--
CONFIG_NEON=y causes platform lockups with certain application/platform
combinations
https://bugs.launchpad.net/bugs/507416
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct subscriber.
--
ubuntu-bugs mailing list
Regarding wrong board version for EVK3.0, it was fixed before. The
attachment is the patch.
** Attachment added:
0069-ENGR00118739-Correct-the-board-version-of-MX51-EVK.patch
http://launchpadlibrarian.net/38213403/0069-ENGR00118739-Correct-the-board-version-of-MX51-EVK.patch
--
Regarding wrong board version for EVK3.0, it was fixed before. The
attachment is the patch.
** Attachment added:
0069-ENGR00118739-Correct-the-board-version-of-MX51-EVK.patch
http://launchpadlibrarian.net/38213404/0069-ENGR00118739-Correct-the-board-version-of-MX51-EVK.patch
--
** Changed in: uboot-imx (Ubuntu)
Status: New = Triaged
** Changed in: uboot-imx (Ubuntu)
Importance: Undecided = High
** Changed in: linux-fsl-imx51 (Ubuntu)
Status: New = Triaged
** Changed in: linux-fsl-imx51 (Ubuntu)
Importance: Undecided = High
--
CONFIG_NEON=y causes
Thanks a lot, Jamie. That is the right thing.
After some email with Rob from Freescale, for TO2 rev is 51120 and TO3
rev should be 51130. Oliver's revision might be a bug in U-Boot or
something.
So I think using 'cpu_is_mx51_rev(CHIP_REV_3_0)' to do dynamic testing
is a safe way to workaround
the uboot-imx package now carries the patch below:
--- uboot-imx-2009.01/include/asm-arm/arch-mx51/mx51.h 2010-01-20
15:41:00.918768862 +
+++ uboot-imx-2009.01.new/include/asm-arm/arch-mx51/mx51.h 2010-01-20
15:42:58.338756978 +
@@ -393,8 +393,8 @@
#define CHIP_REV_1_0
** Also affects: uboot-imx (Ubuntu)
Importance: Undecided
Status: New
--
CONFIG_NEON=y causes platform lockups with certain application/platform
combinations
https://bugs.launchpad.net/bugs/507416
You received this bug notification because you are a member of Ubuntu
Bugs, which is a
this is my 2.5 board (with the current archive kernel though, installed
from alpha2) showing 51025 as the revision number ...
o...@babbage2:~$ cat /proc/cpuinfo
Processor : ARMv7 Processor rev 1 (v7l)
BogoMIPS: 159.90
Features: swp half thumb fastmult vfp edsp neon vfpv3
@Bryan: in the case of chromium which you describe, the application
ought to be fixed to NOT use NEON by default -- or it wont work on e.g.
Marvell v7 (ARMADA) -- instead of using it if the kernel has it. In
general, packages built for Ubuntu should not look at the currently
running kernel to
Apologies, it seems in my recent office move I mixed up the boards and
plugged a 2.5 board in instead of the 3.0. Below is the real output from
a 3.0 board.
Processor : ARMv7 Processor rev 5 (v7l)
BogoMIPS: 799.53
Features: swp half thumb fastmult vfp edsp neon vfpv3
CPU
Testing Bryan's kernel on a Babbage 3.0 with a recent lucid daily:
proc/cpuinfo
Processor : ARMv7 Processor rev 1 (v7l)
BogoMIPS: 799.53
Features: swp half thumb fastmult vfp edsp vfpv3
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x2
CPU part:
@Jamie,
Are you sure this is running on your BB3.0 board. The cpuinfo is the
same as my BB 2.5 board. BB3 is supposed to be 51130 instead of 51120.
Thanks,
-Bryan
--
CONFIG_NEON=y causes platform lockups with certain application/platform
combinations
https://bugs.launchpad.net/bugs/507416
You
@Dave,
After some discussion with Alex and Oliver, I think we still need to
disable the whole CONFIG_NEON for our lucid kernel. Although my dynamic
chip rev checking patch can make some testing pass, we still have some
potential issues from user space NEON applications.
There are 2 types NEON
I added a simple dynamic checking patch in the kernel and build the kernel
again, please help me to test on your side.
So in this kernel, CONFIG_NEON is enabled but it won't export NEON bit in HWCAP
on TO1 and TO2.
Kernel:
http://people.canonical.com/~roc/kernel/neon/
Git branch:
The patch looks sensible, and appears to work for me on Babbage 2.0.
Can someone else please test on Babbage 3.0?
Execution of NEON instructions and NEON context switching still appear to work
OK on Babbage 2.0: See the attachment:
$ gcc -g -o neon-check neon-check.s
$ gcc -g -o neon-probe
** Changed in: linux-fsl-imx51 (Ubuntu)
Assignee: (unassigned) = Bryan Wu (cooloney)
--
CONFIG_NEON=y causes platform lockups with certain application/platform
combinations
https://bugs.launchpad.net/bugs/507416
You received this bug notification because you are a member of Ubuntu
Bugs,
@Dave,
I just simply disabled the NEON in fsl-imx51 kernel now. The git tree is here:
http://kernel.ubuntu.com/git?p=roc/ubuntu-lucid.git;a=shortlog;h=refs/heads/lp507416
And please download the kernel package here to do some test on your hardware:
On Babbage 2.0, installing and booting Bryan's kernel from here
http://people.canonical.com/~roc/kernel/lp507416/
I get the following results:
/proc/cpuinfo no longer lists neon among the CPU features;
AT_HWCAP in /proc/self/auxv no longer reports HWCAP_NEON;
ffplay now sources the ffmpeg
44 matches
Mail list logo
