cross-distro August 2012

cross-distro@lists.linaro.org

13 participants
4 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.

12 years, 3 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

12 years, 3 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

12 years, 4 months

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.

12 years, 4 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

cross-distro August 2012