cross-distro

cross-distro@lists.linaro.org

148 discussions

root=PARTUUID for MBR/NT disk signatures?

by Stephen Warren

I was considering extending the kernel command-line option root=PARTUUID= to also support MBR (NT disk signatures). I was thinking of a syntax along the lines of: root=PARTUUID=UUUUUUUU-PP[/PARTNROFF=%d] ... where UUUUUUUU is the hex representation of the NT disk signature, and PP is the hex representation of the partition number. Like GPT, /PARTNROFF could be used too if desired. Related, I was thinking of changing struct partition_meta_info's uuid field to be a string, so that it could simply be strcmp'd against the UUID value on the kernel command-line. That way, the type of the UUID is irrelevant. Does anyone have any objection to that? The reason I aim for that syntax rather than say: root=MBRSIG=UUUUUUUU-PP[/PARTNROFF=%d] ... is to allow boot-loaders (e.g. U-Boot on ARM) to store just the partition ID in a variable, and prepend all the Linux-specific stuff on the front, e.g. # For GPT: setenv kernel_part_uuid b2f82cda-2535-4779-b467-094a210fbae7 # For MBR: setenv kernel_part_uuid UUUUUUUU-PP In fact, those hard-coded statements would probably be replaced with a run-time command: part uuid mmc 0:1 kernel_part_uuid # Then in a common script: setenv bootargs root=PARTUUID=${kernel_part_uuid} Otherwise, the value of the uuid variable (or result of the "part uuid" command) would need to prepend the PARTUUID= or MBRSIG= to the "uuid" variable's value, and that's probably Linux-specific rather than part of a generic UUID for the partition.

14 years

Minutes from the Cross-Distro session at Connect (2012-05-31)

by Steve McIntyre

[ Basically as found at http://summit.linaro.org/lcq2-12/meeting/20696/linaro-general-q112-cross-di… but etherpad data has a lovely habit of going away over time... ] Current Status ============== Overall, everything works!! ;-) \o/ Fedora ====== Fedora 17 has been released for primary platforms, but not for ARM yet. Still some remaining work. * OMAP4 "doesn't work" (crashes), likely due to reliance on pure upstream OMAP support rather than TI branches. Other distros have used TI patches. * Might be more similar issues around other SoCs that lack support in upstream kernel. * omapdrm support will wait until F18 (likely). * Still need to apply the arm hard-float linker path patches, including the hacky patch for supporting old and new SONAME * Still scrubbing code base for use of GCC locking intrinsics (or, rather where packages have rolled their own). Sharing patches considered good here. * "We suck" - Jon Masters * Normal installer not working for ARM, still using dd mechanism to flash images to cards. * Fedora are doing two ARM distros: v7 hardfloat (armv7hl) and v5 softfloat (armv5tel). v5 will be supported for another couple of years, mainly for RaspberryPi users. Debian ====== * Architecture qualification underway for next release (Wheezy/version 7). * armhf (v7 hardfloat) is fully expected to be accepted as an architecture for the next release, but not *officially* labelled as such yet. * armel is still targetting ARMv4t; will continue to stay supported until absolute confirmation of no more devices in developer hands. * need banchmarks to check how much speed is lost with staying to armv4 and/or reasons from toolchain people why v4t is no longer supported/doesn't work. Time to open discussion about this again after the Wheezy release. * There's an *unofficial* port being made for for RaspberryPi (raspbian.org) ARMv6 hardfloat enabled for this (forward compatible with armhf). To support this better in future, would need additional support in HWCAPS to indicate which instructions are used in this binary/can be used on this hardware. Could use ELF headers for similar info for binaries. And corresponding info in package control file so dpkg can do something sensible (i.e. stop you installing v7 binaries on v6/v5 hardware. * Starting early ground work for ARMv8 port. * No omapdrm support in Debian due to "insane" use of 3.2 kernel for Wheezy Ubuntu ====== * Ubuntu 12.04 LTS released (3.2 kernel). Main ARM support is armhf (v7 hardfloat). * armel port used to be v7 soft-float, but is now slowly being downgraded from v7 to v5t. May be deprecated altogether in the future. * Quantal (12.10) will likely use Linux 3.5 kernel * LLVM built code not correct for armhf; under investigation. * janimo officially volunteered (by infinity) to resolve issues around Mono. * Starting early ground work for ARMv8 port. General / actions ================= As all the distros are going to be working on bootstrapping ARMv8, plan to keep using the cross-distro list for discussion of issues. Linaro will host a bug tracker to help people share work better. [ACTION] SteveMcIntyre to get BTS going Steve's major Ruby issue on ARM (reported widely, see http://bugs.debian.org/652674 for details) is resolved. Now we can rely on getcontext/setcontext support in glibc, rather than on Ruby's (broken) internal implementation from Ruby v1.9+. Re-enable the test suites now! [ACTION] Enumerate disabled testsuites across all distros and get them re-enabled More regular cross-distro meetings (monthly conf call) considered useful. [ACTION] SteveMcIntyre to chase down DaveRusling about reviving cross-distro meetings. Cheers, -- Steve McIntyre steve.mcintyre(a)linaro.org <http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs

14 years, 3 months

Minutes from the ARMHF status discussion at Connect (2012-05-29)

by Steve McIntyre

[ Basically as found at http://summit.linaro.org/lcq2-12/meeting/20695/linaro-general-q112-armhf-st… but etherpad data has a lovely habit of going away over time... ] Current status ============== Just about done in the distros! * Released in Ubuntu 12.04 * About to be accepted as a release architecture in Debian * Fedora 17 * openSUSE (12.2?) * ChromeOS switched to hard-float (recently) We finally got agreement on the runtime linker path for arm hard-float. All the distros have incorporated the changes for that now *except* Fedora; they're planning to do it Real Soon Now. Benchmarks ========== The early comparisons not clear (differing hw, distro, compilers), difficult to get directly comparable numbers out. The latest set from Konstantinos are almost complete - see https://wiki.linaro.org/OfficeofCTO/HardFloat/Benchmarks201205 for a comparison of Ubuntu 12.04 armhf/armel on a Panda board. Somebody needs to finish off the GUI test results. Overall, numbers as expected. Some graphics-heavy and FP-heavy code wins (povray! some media encoding), most integer code comparisons are neutral. Remaining work ============== Work is proceeding on ELF markers/segment definition for ABI. Time to actually implement the PT_ARM_ARCHEXT segment in binutils and (e)glibc. SteveMcIntyre working on this. We need to clearly document what the hard-float ABI is. Plan to incorporate into or copy the existing soft-float ABI doc at Mentor nee Code Sourcery. Java is still a mess: * http://www.oracle.com/technetwork/java/embedded/downloads/javase/index.html ARMv7 Linux - Headless - Server Compiler * EABI, VFP, SoftFP ABI, Little Endian* * possibly would work with ubuntu/debian multiarch Mono is currently not hardfp and needs work to fix it up. Jani (janimo) might be a good candidate to fix mono, if we can get some of his time libffi gained variadic support last year; wasn't used much so far ctypes would need patching to use new variadic support in libffi but ctypes isn't maintained upstream anymore; probably not worth it. Other places where libffi users may be broken. Gnat: * Current port works but not great * Needs resources to do the real port Ruby is still exhibiting some crashes in testsuite on Debian, Ubuntu and Fedora, considered likely to be a glibc locking bug. [ACTION] UlrichWeigand and SteveMcIntyre to setup a hacking session this week to try to look into this. RESULT: problem solved - see http://bugs.debian.org/652674 for more details. Raspberry Pi ============ Brief discussion. It's known that the Pi can support hard-float if recompiled for ARMv6 in ARM mode (e.g. unofficial Debian rebuild at http://www.raspbian.org/). General consensus from the distros: not interested in doing such ports officially, but we love the community doing so. Cheers, -- Steve McIntyre steve.mcintyre(a)linaro.org <http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs

14 years, 3 months

[PATCH v2] ARM: Use different linker path for hardfloat ABI

by Michael Hope

Change the dynamic linker path for ARM hard float executables. Matches the path discussed and agreed on last week[1]. Carlos will follow up with the matching patch to GLIBC[2]. I'm happy to if he's busy. OK for trunk? -- Michael [1] http://sourceware.org/ml/libc-ports/2012-04/msg00060.html [2] http://sourceware.org/ml/libc-ports/2012-04/msg00064.html 2012-04-23 Michael Hope <michael.hope(a)linaro.org> * config/arm/linux-eabi.h (GLIBC_DYNAMIC_LINKER_HARD_FLOAT): Define. (GLIBC_DYNAMIC_LINKER_SOFT_FLOAT): Define. (GLIBC_DYNAMIC_LINKER): Redefine to use the hard float path. diff --git a/gcc/config/arm/linux-eabi.h b/gcc/config/arm/linux-eabi.h index 80bd825..3ddf812 100644 --- a/gcc/config/arm/linux-eabi.h +++ b/gcc/config/arm/linux-eabi.h @@ -62,7 +62,11 @@ /* Use ld-linux.so.3 so that it will be possible to run "classic" GNU/Linux binaries on an EABI system. */ #undef GLIBC_DYNAMIC_LINKER -#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.3" +#define GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "/lib/ld-linux.so.3" +#define GLIBC_DYNAMIC_LINKER_HARD_FLOAT "/lib/ld-linux-armhf.so.3" +#define GLIBC_DYNAMIC_LINKER \ + "%{mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \ + %{!mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "}" /* At this point, bpabi.h will have clobbered LINK_SPEC. We want to use the GNU/Linux version, not the generic BPABI version. */

14 years, 3 months

Fwd: Fedora 17 ARM Beta Release

by Jon Masters

FYI -------- Original Message -------- Subject: Fedora 17 ARM Beta Release Date: Thu, 24 May 2012 01:49:46 +0000 From: Paul Whalen <Paul.Whalen(a)senecacollege.ca> Reply-To: users(a)lists.fedoraproject.org To: announce(a)lists.fedoraproject.org <announce(a)lists.fedoraproject.org> The Fedora ARM team is pleased to announce that the Fedora 17 Beta for ARM is now available for download from: http://dl.fedoraproject.org/pub/fedora-secondary/releases/test/17-Beta/Imag… Please visit the announcement page for additional information and links to specific hardware images as well as QEMU for those who lack ARM hardware. http://fedoraproject.org/wiki/Architectures/ARM/Fedora_17_Beta We invite you to take part in making Fedora 17 for ARM a solid release by downloading, testing, and providing your valuable feedback. Please join us on the IRC in #fedora-arm on Freenode or send feedback and comments to the ARM mailing list. On behalf of the Fedora ARM team, Paul

14 years, 3 months

Linaro Connect Q2, 28th May - 1st June, sessions of interest for distro people

by Riku Voipio

Hi, Linaro connect Q2, approaching the schedule is getting ready. Here is a selection of sessions most close to cross-distro people, but check the schedule[1] for other sessions as well. I will link to remote participation instructions once they are online. Monday 28th May: 10:00 - 10:45 HKT (02:00-02:45 GMT) ARMHF status discussion Meetup for folks interested in the hard-float ABI work, discussing status to date and what's still remaining. Tuesday 29th May: 08:30 - 09:00 HKT (00:30 - 01:00 GMT) ARM update Plenary An overview of ARM’s current developments with emphasis on ecosystem activity relative to Linaro and the open source community, both for ARMv7 and plans for the emerging ARMv8 standard Thursday 31st May: 09:00 - 09:55 HKT (01:00 - 01:55 GMT): Enterprise Bootloaders: UEFI, ACPI, Device Tree Oh My! Discuss bootloader requirements for enterprise grade Linux on ARM CPUs. 10:00 - 10:45 HKT (02:00 - 02:45 GMT) Cross-distro standardisation / discussion session ARM progress in various distros (including the new HF ABI) and build/port issues - sharing ideas and problems that people may have related to ARM porting Riku [1] http://connect.linaro.org/events/event/linaro-connect-q2-12/#schedule

14 years, 3 months

Armhf dynamic linker path

by Steve McIntyre

Hi folks, We really need to push on with getting the loader path for armhf standardised. The path that was agreed months ago is /lib/arm-linux-gnueabihf/ld-linux.so.3 but clearly not everybody is using that yet. Dann has just posted an updated patch for gcc, and we want to get this reviewed / fixed up / accepted ASAP. Then we may need to backport it to older gcc releases. This is *important* so that we can help vendors release binaries that work on any hard-float distribution. For people who have made binaries that still use the old, broken location /lib/ld-linux.so.3, we can put symlinks in place *for now* but in the longer term as many distros switch to multi-arch the symlink is not an acceptable solution. I'm working on a more complete spec document for armhf to help us with this kind of thing, but it's not going as smoothly as I'd hoped and I don't want to wait for that as a blocker on the linker path. Cheers, -- Steve McIntyre steve.mcintyre(a)linaro.org <http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs

14 years, 4 months

arm softfp ABI vs hardfp in rpm world

by Adrian Schröter

Hi, I would like to propose a change in the rpm provides/requires handling of libs and binaries. Right now, we use on arm the architecture to distinguish between hard and soft fp abi. This results to the fact that armv7l is complete incompatible to armv7hl due to the rpm architecture compatibility list (is this true everywhere?) This is IMHO technical wrong. For example an rpm with a static build soft-fp binary should be installable on a hard-fp system. The kernel and the hardware does support it and it would just run. But furthermore this will make it also impossible later to have mixed systems. What I like to do on openSUSE-ARM is to go the same way as i686 vs. x86_64 world did go. Declare i686 backward compatible from x86_64, but to extent the provides and requires with an extension. So a hf binary will still require a hf lib. A patch for rpm which should do this is attached, but I have not tested it, I have to admit. The reason is that want to discuss it here first, because this has a big impact: It would suddenly make the old armv7hl rpms not compatible anymore with the new ones. So, I would like to here if you share my POV here in general. And secondly, if you see a chance at all to do this switch. I promise to take care to push such a patch to rpm upstream, if you want it. thanks adrian PS: I have not evaluated how the NEON VFP world fits in here. -- Adrian Schroeter SUSE Linux Products GmbH email: adrian(a)suse.de

14 years, 4 months

ARM hard-float linker path - consensus

by Steve McIntyre

Hi folks, As promised, here's minutes from the call we had this afternoon. Spoiler: the result we've agreed is /lib/ld-linux-armhf.so.3 And here's a transcription of the minutes from https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012 ======================================== Meeting: 13th April 2012, 15:00 UTC Agenda ------ * Debian/Ubuntu have so far built using /lib/arm-linux-gnueabihf/ld-linux.so.3 * Some other distros (Fedora, OpenSUSE) are still using /lib/ld-linux.so.3 option which matches the older soft-float ABI * Some people are proposing /libhf/ld-linux.so.3 or /libhfp/ld-linux.so.3 (multilib) * Some people proposed /lib/ld-arm-linux-gnueabihf.so.3 (similar to x86_64, libs still in /lib, from Michael Hope) * What should we do as a community? Present ------- Name Affiliations Steve McIntyre ARM, Debian, Linaro Wookey ARM, Debian, Linaro Richard Earnshaw ARM, gcc Jeff Law Fedora, Red Hat, gcc, glibc Jon Masters Fedora, Red Hat Andrew Haley Fedora, Red Hat, gcc Andreas Jaeger SUSE, openSUSE, glibc Carlos O'Donnell Mentor, gcc Steve Langasek Canonical, Ubuntu, Debian Dann Frazier Canonical, Ubuntu, Debian Adam Conrad Canonical, Ubuntu, Debian Matthias Klose Canonical, Ubuntu, Debian Mike Frysinger Gentoo Dennis Gilmore Fedora, Red Hat Discussion ---------- We started with a couple of questions up front to establish the grounds for discussion: * We believed that decision makers were present for all the important parties, i.e. all the arm hard-float distros, plus toolchain developers. This meant that a decision taken at the meeting could be implemented without needing further arguments/negotiations. * All the people present understood the importance of cross-distro binary compatibility, and they all wanted it. This led to agreement that we needed to agree on a standard path for the runtime linker for ARM hard-float Linux binaries. Debian and Ubuntu had so far been using the "multi-arch" path of /lib/arm-linux-gnueabihf/ld-linux.so.3. Fedora and OpenSUSE were thus far using /lib/ld-linux.so.3, the same as the soft-float ABI. Others had proposed alternative paths such as /libhf/ld-linux.so.3 or /libhfp/ld-linux.so.3 (multilib) or /lib/ld-arm-linux-gnueabihf.so.3. Discussion showed that none of these were found to be universally acceptable. Two parties were likely to be soon affected by an agreement here: 1. Ubuntu 12.04 (releasing with armhf in ~2 weeks) Adam/Steve L agreed that all efforts would be put in to switch the compilers in Ubuntu to a new path before release. Default things like gcc would be correct, but less common tools might still be targetting the old path /lib/arm-linux-gnueabihf/ld-linux.so. at release. They could be fixed in the longer term and would not stop progress here. 2. Mentor (Codebench due for release in ~1 week) Carlos mentioned this - Codebench has been using /lib/ld-linux.so.3 for hard-float binaries for some time and it was too late to change that for this upcoming release. Next release due in October. Suggested and accepted that this should be mentioned in release notes: if people want to use Codebench on some systems (Debian/Ubuntu and derivatives), they'll need to tweak their system setup. He may be able to do the linker change and rebuild in a point release in a few weeks. It was briefly suggested that the soft-float linker should be renamed away from /lib/ld-linux.so.3 as well at this time, but that idea was quickly shot down. Proposal #1: /lib/ld-armhf.so.3 (not generally liked) Proposal #2: /lib/ld-linux-armhf.so.3 (not favourite, but considered an acceptable compromise by all) No need to go any further. Conclusion ---------- All the people in the meeting agreed: the new runtime linker path for ARM hard-float Linux binaries was to be /lib/ld-linux-armhf.so.3 ACTION: People at the meeting to present this decision to their companies / communities and get the appropriate changes made. Further discussion ------------------ General unhappiness with the mess that led to this meeting. Future planning needs to be better between the various groups for the next time we have a new CPU/ABI/whatever. ACTION: Jon Masters to talk to the Linux Foundation about setting up a forum for such discussions. In the meantime, strong consensus to use the cross-distro(a)lists.linaro.org mailing list for any more conversations now we have people in contact. ACTION: Steve McIntyre to write up the minutes and circulate. Include an updated linker path patch for gcc to match the decision made here. More discussion about triplets and naming, but nothing came of it in the end. Distro folks have already decided what they're using and have patched various software to build appropriately. Richard wants to move gcc's config.guess to use arm-linux-gnueabihf; no strong objections to that. Linker path patch for gcc ------------------------- Adapted from earlier work by Dann Frazier <dann.frazier(a)canonical.com> and Michael Hope <michael.hope(a)linaro.org> 2012-04-13 Steve McIntyre <steve.mcintyre(a)linaro.org> * config/arm/linux-eabi.h (GLIBC_DYNAMIC_LINKER_HARD_FLOAT): Define. (GLIBC_DYNAMIC_LINKER): Redefine to use the hard float path. diff --git a/gcc/config/arm/linux-eabi.h b/gcc/config/arm/linux-eabi.h index 80bd825..8c9d2e7 100644 --- a/gcc/config/arm/linux-eabi.h +++ b/gcc/config/arm/linux-eabi.h @@ -62,7 +62,11 @@ /* Use ld-linux.so.3 so that it will be possible to run "classic" GNU/Linux binaries on an EABI system. */ #undef GLIBC_DYNAMIC_LINKER -#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.3" +#define GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "/lib/ld-linux.so.3" +#define GLIBC_DYNAMIC_LINKER_HARD_FLOAT "/lib/ld-linux-armhf.so.3" +#define GLIBC_DYNAMIC_LINKER \ + "%{mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \ + %{!mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "}" /* At this point, bpabi.h will have clobbered LINK_SPEC. We want to use the GNU/Linux version, not the generic BPABI version. */ Post-meeting on IRC ------------------- Suggested that Richard should push the change into gcc trunk ASAP. Steve McIntyre agreed to work on that with Richard. Also suggested that we want to get a patch into glibc too to change the installation path for ARM hard-float. Andrew agreed to push glibc upstream for that. Cheers, -- Steve McIntyre steve.mcintyre(a)linaro.org <http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs

14 years, 5 months

Linaro Connect Q2, Hong Kong, 28th May - 1st June

by Steve McIntyre

Hey folks, The next Connect event is in Hong Kong at the end of May. I'm going to propose another cross-distro discussion there as normally happens. There's still time for people to register and turn up in person if you'd like to come along and can get travel organised, otherwise I'll post the details here so that people can connect remotely too. Cheers, -- Steve McIntyre steve.mcintyre(a)linaro.org <http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs

14 years, 5 months

← Newer
1
...
7
8
9
10
11
12
13
14
15
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

cross-distro