cross-distro

cross-distro@lists.linaro.org

1 participants
221 discussions

by Robie Basak

Hi, We (MAAS upstream) are having some issues figuring out how to effectively detect the architecture of a system booting using U-Boot pxelinux emulation in order to send back an appropriate kernel and initrd. In short, we'd like a mechanism that is separate from the DHCP vendor option which I believe is the only way to differentiate at the moment. I proposed an alternative mechanism in https://launchpad.net/bugs/1041092 (description copied below) and it was suggested to me that I could get feedback from this list. If this mechanism is appropriate and we can get vendor consensus on it, then I can continue and implement the other end of it in MAAS. If it is not suitable then I'd love to hear about alternatives. Either way, I'd really like to move within a couple of weeks so that I can make our 12.10 release in October. Without a non-DHCP mechanism for architecture detection, MAAS will be stuck having to be configured for homogeneous architecture clusters only, which would be unfortunte. What do you think? The full text of the bug is below. Thanks, Robie An outcome of a recent MAAS-related sprint is the conclusion that MAAS needs to be able to operate in an environment where it cannot control the DHCP server. This means that we cannot rely on the ability to differentiate architectures based on ISC dhcpd.conf conditional statements on vendor-class-identifier setting alternate next-server filenames as we are doing at the moment (see bug 927781 for details of this mechanism). Instead we need some other way for MAAS to detect the architecture of the booting system in order to send it the correct architecture kernel/initrd. If this doesn't happen, then MAAS will have to resort to guessing based on MAC addresses supplied by vendors, or the user entering in the information on a per-MAC basis manually, or the user nominating an entire MAAS cluster as homogeneous on a particular architecture. None of these options are ideal. Instead, I propose the following minor change to U-Boot to enable architecture detection outside of DHCP. The original (Intel) pxelinux.0 falls back through MAC addresses, IP address and subnets and then to "default". Prior to U-Boot pxelinux emulation, a TFTP server could assume that sending an i386 kernel would always work. pxelinux emulation on other architectures breaks this assumption. So I propose that all alternative architecture pxelinux emulators (eg. U-Boot) fall back to "default.<arch>-<subarch>" and then "default.<arch>" before further falling back to "default" as usual. <arch> and <subarch> must be defined in a new pxelinux emulator namespace, and MAAS will consequently need to map this namespace to Ubuntu's architecture and kernel flavour names. But to start with, they'll probably match 1-1. So: default.arm-highbank default.arm-armadaxp default.arm-omap4 For this proposed change to work, we need all vendors to take this up. I think the change would be trivial, but I would appreciate feedback from U-Boot maintainers and vendors before we commit to this direction.

13 years, 11 months

standard U-Boot environment variables/macros across platforms

by David Marlin

I'm not sure if this has been discussed before, but in working with various ARM systems (Panda, Trim Slice, Highbank, etc.) I have noticed that there is little consistency in the load addresses for kernel, initrd, and device tree, or the commands and devices used. While it may not be practical to always use the same physical addresses, it seems it might be possible to set some 'standard' U-Boot environment variables or macros to provide a more consistent user experience when working on various boards from different vendors. Some vendors already provide U-Boot environment variables for the load addresses, and some for the load commands themselves, but I have not found much consistency between them. One example is the Genesi Efika MX (mx51), which provides: ${loadcmd} ${kerneladdr} ${ramdiskaddr} By providing the kernel and initrd U-Boot images in a boot.scr, you can load and boot the desired kernel with no other board specific knowledge (specific addresses or devices). Highbank provides some similar load address definitions, but with different names, i.e., ${ramdisk_addr_r} ${kernel_addr_r} ${fdt_addr_r} Other boards provide similar features, including some (e.g., Trim-Slice) that 'scan' through a list of devices until a boot.scr is found, load it, and then boot using that script, but the load addresses are literals. Does anyone else think it would be useful to include a 'standard' set of such definitions in U-Boot (default) that could be used to abstract the board/vendor specific details and provide a more consistent user experience? If so, could this list be used to help define such a set, and encourage its use across ARM systems and distros? If this has already been discussed, perhaps someone could provide a link to the thread. Thank you for your consideration, d.marlin

13 years, 11 months

[PATCH 1/3] block: store partition_meta_info.uuid as a string

by Stephen Warren

From: Stephen Warren <swarren(a)nvidia.com> This will allow other types of UUID to be stored here, aside from true UUIDs. This also simplifies code that uses this field, since it's usually constructed from a, used as a, or compared to other, strings. Note: A simplistic approach here would be to set uuid_str[36]=0 whenever a /PARTNROFF option was found to be present. However, this modifies the input string, and causes subsequent calls to devt_from_partuuid() not to see the /PARTNROFF option, which causes different results. In order to avoid misleading future maintainers, this parameter is marked const. Signed-off-by: Stephen Warren <swarren(a)nvidia.com> --- block/genhd.c | 8 +------- block/partitions/efi.c | 7 +------ include/linux/genhd.h | 8 ++++++-- init/do_mounts.c | 28 +++++++++++++++++----------- 4 files changed, 25 insertions(+), 26 deletions(-) diff --git a/block/genhd.c b/block/genhd.c index 6cace66..b281f3a 100644 --- a/block/genhd.c +++ b/block/genhd.c @@ -743,7 +743,6 @@ void __init printk_all_partitions(void) struct hd_struct *part; char name_buf[BDEVNAME_SIZE]; char devt_buf[BDEVT_SIZE]; - char uuid_buf[PARTITION_META_INFO_UUIDLTH * 2 + 5]; /* * Don't show empty devices or things that have been @@ -762,16 +761,11 @@ void __init printk_all_partitions(void) while ((part = disk_part_iter_next(&piter))) { bool is_part0 = part == &disk->part0; - uuid_buf[0] = '\0'; - if (part->info) - snprintf(uuid_buf, sizeof(uuid_buf), "%pU", - part->info->uuid); - printk("%s%s %10llu %s %s", is_part0 ? "" : " ", bdevt_str(part_devt(part), devt_buf), (unsigned long long)part_nr_sects_read(part) >> 1 , disk_name(disk, part->partno, name_buf), - uuid_buf); + part->info ? part->info->uuid : ""); if (is_part0) { if (disk->driverfs_dev != NULL && disk->driverfs_dev->driver != NULL) diff --git a/block/partitions/efi.c b/block/partitions/efi.c index 6296b40..b62fb88 100644 --- a/block/partitions/efi.c +++ b/block/partitions/efi.c @@ -620,7 +620,6 @@ int efi_partition(struct parsed_partitions *state) gpt_entry *ptes = NULL; u32 i; unsigned ssz = bdev_logical_block_size(state->bdev) / 512; - u8 unparsed_guid[37]; if (!find_valid_gpt(state, &gpt, &ptes) || !gpt || !ptes) { kfree(gpt); @@ -649,11 +648,7 @@ int efi_partition(struct parsed_partitions *state) state->parts[i + 1].flags = ADDPART_FLAG_RAID; info = &state->parts[i + 1].info; - /* Instead of doing a manual swap to big endian, reuse the - * common ASCII hex format as the interim. - */ - efi_guid_unparse(&ptes[i].unique_partition_guid, unparsed_guid); - part_pack_uuid(unparsed_guid, info->uuid); + efi_guid_unparse(&ptes[i].unique_partition_guid, info->uuid); /* Naively convert UTF16-LE to 7 bits. */ label_max = min(sizeof(info->volname) - 1, diff --git a/include/linux/genhd.h b/include/linux/genhd.h index 4f440b3..79b8bba 100644 --- a/include/linux/genhd.h +++ b/include/linux/genhd.h @@ -88,10 +88,14 @@ struct disk_stats { }; #define PARTITION_META_INFO_VOLNAMELTH 64 -#define PARTITION_META_INFO_UUIDLTH 16 +/* + * Enough for the string representation of any kind of UUID plus NULL. + * EFI UUID is 36 characters. MSDOS UUID is 11 characters. + */ +#define PARTITION_META_INFO_UUIDLTH 37 struct partition_meta_info { - u8 uuid[PARTITION_META_INFO_UUIDLTH]; /* always big endian */ + char uuid[PARTITION_META_INFO_UUIDLTH]; u8 volname[PARTITION_META_INFO_VOLNAMELTH]; }; diff --git a/init/do_mounts.c b/init/do_mounts.c index d3f0aee..4dba733 100644 --- a/init/do_mounts.c +++ b/init/do_mounts.c @@ -69,23 +69,28 @@ __setup("ro", readonly); __setup("rw", readwrite); #ifdef CONFIG_BLOCK +struct uuidcmp { + const char *uuid; + int len; +}; + /** * match_dev_by_uuid - callback for finding a partition using its uuid * @dev: device passed in by the caller - * @data: opaque pointer to a 36 byte char array with a UUID + * @data: opaque pointer to the desired struct uuidcmp to match * * Returns 1 if the device matches, and 0 otherwise. */ static int match_dev_by_uuid(struct device *dev, void *data) { - u8 *uuid = data; + struct uuidcmp *cmp = data; struct hd_struct *part = dev_to_part(dev); if (!part->info) goto no_match; - if (memcmp(uuid, part->info->uuid, sizeof(part->info->uuid))) - goto no_match; + if (strncasecmp(cmp->uuid, part->info->uuid, cmp->len)) + goto no_match; return 1; no_match: @@ -95,7 +100,7 @@ no_match: /** * devt_from_partuuid - looks up the dev_t of a partition by its UUID - * @uuid: min 36 byte char array containing a hex ascii UUID + * @uuid: char array containing ascii UUID * * The function will return the first partition which contains a matching * UUID value in its partition_meta_info struct. This does not search @@ -106,11 +111,11 @@ no_match: * * Returns the matching dev_t on success or 0 on failure. */ -static dev_t devt_from_partuuid(char *uuid_str) +static dev_t devt_from_partuuid(const char *uuid_str) { dev_t res = 0; + struct uuidcmp cmp; struct device *dev = NULL; - u8 uuid[16]; struct gendisk *disk; struct hd_struct *part; int offset = 0; @@ -118,6 +123,9 @@ static dev_t devt_from_partuuid(char *uuid_str) if (strlen(uuid_str) < 36) goto done; + cmp.uuid = uuid_str; + cmp.len = 36; + /* Check for optional partition number offset attributes. */ if (uuid_str[36]) { char c = 0; @@ -134,10 +142,8 @@ static dev_t devt_from_partuuid(char *uuid_str) } } - /* Pack the requested UUID in the expected format. */ - part_pack_uuid(uuid_str, uuid); - - dev = class_find_device(&block_class, NULL, uuid, &match_dev_by_uuid); + dev = class_find_device(&block_class, NULL, &cmp, + &match_dev_by_uuid); if (!dev) goto done; -- 1.7.0.4

14 years

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, 2 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, 2 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, 3 months

← Newer
1
...
14
15
16
17
18
19
20
...
23
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

cross-distro