Re: [fedora-arm] On ARM atomics
On 14 November 2012 06:21, Jon Masters j...@redhat.com wrote:
On 11/13/2012 01:24 AM, Nicolas Pitre wrote:
There are several serious mistakes in your assembly example.
Thanks for the feedback! Appreciated. Comments below...
|START_FUNC(opal_atomic_add_32)
| push{r4-r7}
Why r4 to r7? You're using only r4 below.
Ah. Because in the rest of the OpenMPI code they're doing similar on
function entry (saving all 4 of the variable registers). You're right
that I only use one of those registers so I could have not bothered to
save all 4 of them.
Random note: you need to save an even number of registers to keep the
stack aligned to eight bytes. Nico's code below is good.
-- Michael
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Debugging our kernels under qemu + gdb
On 14 May 2012 16:57, Jon Masters j...@redhat.com wrote: On 05/13/2012 04:34 PM, Michael Hope wrote: On 12 May 2012 22:12, Richard W.M. Jones rjo...@redhat.com wrote: On Fri, May 11, 2012 at 01:41:43PM -0700, Brendan Conoboy wrote: On 05/11/2012 01:04 PM, Richard W.M. Jones wrote: Has anyone tried to debug our Fedora/arm kernels under qemu-system-arm? (In this case, the host is also arm, but I don't think that matters.) Richard, FYI, we as of a few hours ago have nearly-official F17-beta images for versatile express on the following page: http://scotland.proximity.on.ca/arm-nightlies/ There's a link for vexpress and vexpress+x rootfs images. A second link provides a kernel, initramfs, and script for starting qemu. Note that vexpress is much faster than versatile and allows more ram (1GB). Recommend you try this out! So one issue appears to be lack of PCI support (according to Linaro's notes: https://wiki.linaro.org/PeterMaydell/QemuVersatileExpress). Unfortunately all of the virtio hardware is PCI-based, so it doesn't seem like this is going to work for the virt tools :-( Hi Richard. The plan is to use virtio-mmio and use Device Tree to set where the virtio devices are. virtio-mmio is in the mainline kernel and in the queue for QEMU. Note, we're not using dtb (device tree) yet in the qemu kernel. To do that properly, we'll need to get a qemu that works with U-Boot, etc. I know Linaro have put such a combination together, right? Should any of that be working with upstream bits yet? Brendan mentioned he'd tried poking briefly at the U-Boot that Linaro put together but it apparently didn't boot on our qemu (I know upstream was missing e.g. the model instantiation for the hardware memory controller, etc. in vexpress). I guess I could/should ping Peter Maydell? Is he the best contact? Peter or Ricardo, yip. Ricardo has a good handle on the integration work that's been done and the upstream versions. We've standardised on the vexpress-a9 model as it's neutral, has a good amount of RAM, and has good support in upstream QEMU and mainline Linux. The vexpress-a15 isn't as tested but goes up to 2 GB and will probably be the base model for KVM. -- Michael ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Debugging our kernels under qemu + gdb
On 12 May 2012 22:12, Richard W.M. Jones rjo...@redhat.com wrote: On Fri, May 11, 2012 at 01:41:43PM -0700, Brendan Conoboy wrote: On 05/11/2012 01:04 PM, Richard W.M. Jones wrote: Has anyone tried to debug our Fedora/arm kernels under qemu-system-arm? (In this case, the host is also arm, but I don't think that matters.) Richard, FYI, we as of a few hours ago have nearly-official F17-beta images for versatile express on the following page: http://scotland.proximity.on.ca/arm-nightlies/ There's a link for vexpress and vexpress+x rootfs images. A second link provides a kernel, initramfs, and script for starting qemu. Note that vexpress is much faster than versatile and allows more ram (1GB). Recommend you try this out! So one issue appears to be lack of PCI support (according to Linaro's notes: https://wiki.linaro.org/PeterMaydell/QemuVersatileExpress). Unfortunately all of the virtio hardware is PCI-based, so it doesn't seem like this is going to work for the virt tools :-( Hi Richard. The plan is to use virtio-mmio and use Device Tree to set where the virtio devices are. virtio-mmio is in the mainline kernel and in the queue for QEMU. -- Michael ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] getcontext returns ENOSYS
On 29 April 2012 01:39, Richard W.M. Jones rjo...@redhat.com wrote: For the record, attached is the patch to Fedora glibc. It works, and gets us past the missing ucontext problem. However, qemu-system-arm fails very quickly afterwards somewhere in TCG code. I suspect that qemu cannot emulate the same hardware as required by my kernel (vmlinuz-3.3.2-8.fc17.armv7hl.tegra), although there is not much to go on. Anyone have a primer on all the different ARM architectures? Hi Richard. I recommend the Versatile Express A9 model. It's one of our supported platforms, has good kernel support in Linus's tree, and has a decent amount of memory. It's the seed system model for the KVM work we're looking at. There's more information at: https://wiki.linaro.org/PeterMaydell/QemuVersatileExpress and my quick start at: https://wiki.linaro.org/MichaelHope/Sandbox/QEMUCrossTest You'd probably want a Fedora kernel and libvirt instance instead of our tools. -- Michael ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] GCC status update
2011/11/22 Michael Hope michael.h...@linaro.org: 2011/11/21 Michael Hope michael.h...@linaro.org: 2011/11/21 Henrik Nordström hen...@henriknordstrom.net: mån 2011-11-21 klockan 11:23 +1300 skrev Michael Hope: Let me know if Linaro can help. I see that Joey Ye from ARM is working in this area as well. Current GCC topics are a) More in depth analysis of the first patch in GCC PR #50521 which aims to fix code generation issues in volatile bitfields accesses. There is some test cases in the PR illustrating the problem (another cpu arch, but also applies to arm). It is unknown to me if linaro have other fixes in this area not yet found in gcc trunk. We work upstream so, sorry, we don't have a fix for that one. b) Identifying other ARM critical GCC bugfixes in the linary tree which have not yet made it into gcc-4.6 and try to push those to 4.6 where possible. I'll bring this up at our next meeting. So far we have hit another volatile bitfields issue in expr.c fixed by gcc trunk change 171347 (from linaro origin, no PR # identified) This is LP: #675347: https://bugs.launchpad.net/gcc-linaro/+bug/675347 which is also: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=625825 I've pinged the original author to see if he can backport it. If not then we'll take over. and PR #48190, also of linaro origin. This is also LP: #714921. The second half of the fix may be too big for the 4.6 release branch but we'll talk about it in the meeting. Richard Sandiford is going to look into this. He originally asked for approval for 4.6 as well but the response was ambiguous. Hi Henrik. The fix has been backported to the 4.5 and 4.6 branches. No response from the original author for LP: #675347 yet but we'll ping him again and failing that organise a backport. -- Michael ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] GCC status update
2011/11/21 Michael Hope michael.h...@linaro.org: 2011/11/21 Henrik Nordström hen...@henriknordstrom.net: mån 2011-11-21 klockan 11:23 +1300 skrev Michael Hope: Let me know if Linaro can help. I see that Joey Ye from ARM is working in this area as well. Current GCC topics are a) More in depth analysis of the first patch in GCC PR #50521 which aims to fix code generation issues in volatile bitfields accesses. There is some test cases in the PR illustrating the problem (another cpu arch, but also applies to arm). It is unknown to me if linaro have other fixes in this area not yet found in gcc trunk. We work upstream so, sorry, we don't have a fix for that one. b) Identifying other ARM critical GCC bugfixes in the linary tree which have not yet made it into gcc-4.6 and try to push those to 4.6 where possible. I'll bring this up at our next meeting. So far we have hit another volatile bitfields issue in expr.c fixed by gcc trunk change 171347 (from linaro origin, no PR # identified) This is LP: #675347: https://bugs.launchpad.net/gcc-linaro/+bug/675347 which is also: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=625825 I've pinged the original author to see if he can backport it. If not then we'll take over. and PR #48190, also of linaro origin. This is also LP: #714921. The second half of the fix may be too big for the 4.6 release branch but we'll talk about it in the meeting. Richard Sandiford is going to look into this. He originally asked for approval for 4.6 as well but the response was ambiguous. -- Michael ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] GCC status update
2011/11/19 Henrik Nordström hen...@henriknordstrom.net: tor 2011-11-17 klockan 02:55 -0500 skrev Jon Masters: * gcc - making sure the bitfields patches are in place for v5 Actually it's not quite in place for v7 even. The gcc in v7 still generates bad code on volatile bitfield accesses. And v5 probably needs even more changes in that area if I understood alignment requirements for v5 correctly. See separate discussion on 9 Nov last week regardign GCC PR #50521. It would be great if we could get help from some gcc developers in analysing the needed changes. The suggested patch which seems to fix known code generation is not yet in gcc trunk and is why we have not included it in the armv7hl gcc package even if it's been discussed a number of times. Let me know if Linaro can help. I see that Joey Ye from ARM is working in this area as well. -- Michael ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fedora-ARM Shirts
On Tue, Jun 14, 2011 at 2:45 PM, David A. Marlin dmar...@redhat.com wrote: Chris Tyler wrote: I want a Fedora-ARM t-shirt! Anyone else interested in getting some made up? Any ideas on design? (One idea that crossed my mind was a medium blue shirt with Fedora ARM on the sleeve, but maybe that's too subtle :-) I assume we can use the Fedora logo/name without any special permission (as long as we follow the usage guidelines), but would we need to request permission to use the ARM logo/name on a shirt? Hi Dave. There's contact details on ARM's trademark page: http://www.arm.com/about/trademark-usage-guidelines.php -- Michael ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] [Fwd: Activity Day June 10th - ARMv7 F15 hardfp bringup]
On Mon, Jun 6, 2011 at 2:35 PM, Jon Masters j...@redhat.com wrote: On Sun, 2011-06-05 at 09:54 +0100, Peter Robinson wrote: Right. v7 based Tegra parts will be supported by virtue of the vfpv3-d16 ABI (some newer VFPv3 parts have 16 additional optional registers not required by the minimal implementation we are basing upon in Fedora, intentionally, for ABI linkage, so that there's no break again). Note that the VFPv3-D16, VFPv3-D32, and NEON are all ABI compatible. You can call -D32 code from -D16 and vice-versa. -- Michael ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] armv7hl requirements
On Fri, May 6, 2011 at 6:57 PM, Gordan Bobic gor...@bobich.net wrote: Jon Masters wrote: If you read how VFPv3 actually implements its registers, you'll see that the extra 16 (for D32) really are totally separate anyway as far as the ABI is concerned, so I remain unconvinced we lose a lot by being D16. Can you clarify that? Does that mean that a we can have a D16 distro with D32 kernel/glibc? VFPv3-D16 and VFPv3-D32 code are compatible. You can call D16 code from D32 code and vice-versa. -- Michael ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] armv7hl requirements
On Thu, May 5, 2011 at 3:50 PM, Jon Masters jonat...@jonmasters.org wrote: On Thu, 2011-05-05 at 08:23 +1200, Michael Hope wrote: *). ARM VFP3 hardware floating point (h) *). ARM NEON Architecture *). Thumb2 interworking I don't think you have to anything explicit here. Thumb-2 and ARM code interoperate just fine. *). Your suggestion here? *) Hard float. Never worse than soft float, sometimes much better. Note that hard float is implied by VFPv3, and by the subject being armv7hl. The intention is to use the aapcs-vfp binding but the only real debate is whether to use the D16/32 option. That comes down to whether we want to focus on really great A15 plus or be more inclusive of various minimal ARMv7 systems that are already out there today. Ah, thanks. Perhaps we need a matrix of known capabilities in v7 hardware. I guess that's another wiki page I should create, starting with my Beagle, Panda and Efika systems, but a pointer to AC100 specs would be cool (I found various reviews on it, and wow it's pricey compared to e.g. Efika) :) Have a look at: http://wiki.debian.org/ArmHardFloatPort/VfpComparison#FPU -- Michael ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] llvm/clang support
On Sat, Apr 2, 2011 at 12:04 PM, Xerxes Ranby xer...@zafena.se wrote: On 2011-04-02 00:20, Michael Hope wrote: On Sat, Apr 2, 2011 at 1:50 AM,omall...@msu.edu wrote: Did anyone ever get llvm/clang working? It -says- it is fast, good optimization, faster binaries, aimed at generating better errors, and has good tools for debugging. :) the darwin-arm (and x86 ports are production quality. There isn't support for EABI or armv6 in the ARM-backend yet. I'm having a bit of a look at this for Linaro at the moment. LLVM is quite respectable, and generates code that is slower than GCC but generally in the same ballpark. Of the three benchmarks I've tried, two took 8 % longer to run on an A9 and pybench took more like 40 % longer to run. pybench is sensitive to having a good inner loop though. -- Michael ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm Hi Michael! For what I know, LLVM defaults to ARMv4t code generation unless it gets told that it are allowed to use newer code generation. This llvm bug tracked how llvm and clang implemented X86 cpu feature autodetection code to make clang generate the best code available for any given host when using -march=native. http://www.llvm.org/bugs/show_bug.cgi?id=5389 I have added an initial cpu features auto-detection code for ARM to that bug-report for the LLVM part. Do you get better performance on your A9 tests when running clang with clang -mcpu=generic -mattr=+neon,-thumb2,+v6,+vfp2 I've only done a first pass, but I'm fairly sure I used clang -mcpu=cortex-a9 -mfpu=neon. I don't think clang supports ARMv4T at all. I'm working on automating the benchmarks at the moment and I'll add llvm into that. Better than some throw-away, unreproducable results :) -- Michael ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
