cross-distro

cross-distro@lists.linaro.org

147 discussions

Re: FOSDEM 2013

by Philippe De Swert

Hi, On 19/11/2012, Andrew Wafaa <andrew.wafaa(a)arm.com> wrote: > It's only a few months until the land of waffles, chocolate and beer (to > name a few of their fine products) hosts one of Europe's great Open Source > events - FOSDEM [0]. I have submitted two talk proposals for the > Distribution track, one around the status of ARMv7, and one around ARMv8; I > believe there will also be a talk from Debian's one and only Wookey around > bootstrapping ARMv8. Related to that there is also the embedded and mobile room which is interested in similar things. So if you're not building complete distros that is the place to be ;) =================================================================== Every year there is a special dedicated track for embedded and mobile projects at Fosdem (see: www.fosdem.org ). If you are interested to highlight or give a talk about your project check out the cfp. FOSDEM will be held the 2nd and 3th of February 2013 in Brussels, Belgium. As usual and for the 10th time there will be an embedded and mobile room. For this years program we are looking for people who would like to do a presentation about their or their community's projects in this area. These projects must be Free Software or Open Source. For example involvement and experiences with projects like Arduino, Tizen, Jolla, Mer, Beagleboard, Openembedded, Android, OpenWrt, Yocto, Linaro... Kernel hacks for maximising memory usage, using filesystems on flash, power management, ... We are also interested in short tutorials, project overviews, achievements, ports to new hardware and hardware hacking, real life deployments, ... all are welcome and all submissions will be reviewed by our panel. Submissions require a small abstract and short speaker presentation and should be submitted to fosdem.embedded at gmail.com before the 25th of December 2012 The panel consists of: Philippe De Swert Peter De Schrijver Geert Uytterhoeven Thomas Pettazoni

13 years

FOSDEM 2013

by Andrew Wafaa

Aloha all, It's only a few months until the land of waffles, chocolate and beer (to name a few of their fine products) hosts one of Europe's great Open Source events - FOSDEM [0]. I have submitted two talk proposals for the Distribution track, one around the status of ARMv7, and one around ARMv8; I believe there will also be a talk from Debian's one and only Wookey around bootstrapping ARMv8. As the talks are being proposed in the Distribution track, it would be great if we could get as many people from different distros interested in ARM to join in the discussions and work to a common goal. If the talks are not accepted for whatever reason, I would still like to have as many people as possible in a face to face discussions about the trials and tribulations of getting Linux on ARM to work - please note this will be focussed on the ARM architecture and not the architecture of distro components, so leave any GNOME/KDE/systemd/upstart/udev/*kit/etc angst at home please :) Hope to see you in Brussels in February, Andy 0 - http://fosdem.org/2013/

13 years

Minutes from the ARMv8 Distributions session at Connect (2012-10-30)

by Steve McIntyre

[ Based heavily on notes from http://summit.linaro.org/lce12/meeting/21345/armv8-mini-summit-4/ but etherpad data has a lovely habit of going away over time... ] This was an AArch64-specific distribution planning and discussion session on Tuesday morning as part of the v8 mini-summit; there was also a general cross-distro session on Monday for discussion about ARM issues. I've already posted those minutes. Familiar faces from Debian, Red Hat, SuSe and Ubuntu lead a discussion about the where these distributions have got with thinking about AArch64, the challenges that they face and how the community can get involved Recap of cross-distro session on Monday: * Project is set up for sharing bugs and patches for ARMv8. * Suggested way of working is to file a bug in distro-specific bug tracker, and also one in the common bug trackers. * There is already a Linaro cross-distro mailing list - currently very low traffic. AArch64 support in packages =========================== Biggest issue seen to date (Fedora) is the number of packages that have not reconfigured to pick up the aarch64 target. Jon suggested using an LWN article perhaps to publicise the need for upstream code to update their config. * There has been some discussion as happened on autoconf mailing list to try and get around the non-update of many packages config * Using autoreconf automatically for all packages is a big risk, but might kinda work for the time being? (This is what happens by default in OE, with a blacklist to disable autoreconf where it's known to break.) * There remains the issue of getting the upstream packages fixed * Identifying which packages need to be fixed is not a simple task * Suggestion: start with a list of those packages which absolutely require fixing (on Linaro wiki), handle many cases using a change to autoconf to use a config variable Cross-distro compatibility ========================== How do we make sure that software built on one distro can install and run on others? * Key aspects are decided already: the GNU triplet and the runtime linker path (phew!) * Jon suggests using LSB to provide that compatibility baseline. It might be a large piece of work. Some ARMv8 market segments are likely to require LSB, so this work will have to be done. * Need regular (monthly) testing of sets of binaries across other distros - don't wait for LSB. Contents of the test set TBD later, but start from something simple. Perhaps hello-world, binutils, gcc, perl, python, ruby. Maybe run a regular bake-off/plug-fest? * How do we get distro images while the distros are under construction? Should Linaro do this or should each distro run the tests from other distros on their own images? Consensus seems to be that Linaro can help with the testing, writing scripts etc. to do some of the work, but it's up to the distros to share their images and software periodically then do the N-way testing. Fedora has a git repo of the file system, and plans to provide tarballs of this in the future. Issues/problems? ================ Is anything blocking progress for the building? * What's the timeline for QEMU? + It requires enough details about the instruction set (ARMv8 Architecture Architecture Manual) + Who would do this work? + Linaro could/should provide some coordination of the effort. * There's (obviously) no hardware available yet. Using models to build software is not very attractive! + How much do you need before you can use a highly parallel build system (lots of models)? Generally, the number seems to be 300 packages (except Fedora with systemd's 1500 dependencies - some tinkering may be needed!). + Parallel building is still some time away... * A decent bootloader. When will we have UEFI working? + People are working on it, coming Real Soon Now! + It would be nice to avoid the proliferation of boot loaders common on 32-bit ARM now Involvement =========== How can other developers get involved? * The availability of the Foundation model and the initial images makes this possible * In reality most packages do not need significant work to make them build, a small number will have to be ported to AArch64, and a larger numer will benefit from AArch64 specific code. * With the public model and code, it makes sense to start publishing the distro code for wider use ASAP. Next steps ========== * At the next Connect, there should be distro code that runs on ARMv8. * Linaro should coordinate and help with the cross-distro testing. * Planning will be done via the cross-distro mailing list. Cheers, -- Steve McIntyre steve.mcintyre(a)linaro.org <http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs

13 years, 1 month

Minutes from the Cross-Distro session at Connect (2012-10-29)

by Steve McIntyre

[ Based on notes from http://summit.linaro.org/lce12/meeting/20963/cross-distro-standardisation-d… but etherpad data has a lovely habit of going away over time... ] This was a general cross-distro session for discussion about ARM issues. There was also a more AArch64-specific session on Tuesday morning as part of the v8 mini-summit; I'll post notes from that next! Distros/groups represented ========================== * Debian * Ubuntu * Fedora * Baserock * openSUSE * OpenEmbedded Existing ports ============== v7 hard-float is basically done by everybody. Steve McIntyre mopping up last bits (glibc/binutils/ABI doc, mostly multiarch/multilib cleanup). TODO: it would be nice to get the binutils hf/sf ABI patches into the binutils 2.23 branch. It looks like the runtime linker stuff is just about finished! Question about Cortex-A15 kernel support, especially LPAE. Looks like distros will need to ship 2 kernels for ARMv7 in this case: LPAE/non-LPAE. There is no current way to merge these, and no plans. ARMv8/AArch64/arm64 =================== Many distributions are starting work on porting to AArch64. Linaro have released an initial OpenEmbedded-based filesystem which will work in ARM's v8 models. Toolchains are available too: http://www.linaro.org/engineering/armv8 Hopefully this will help the distros bootstrap. There are "aarch64" tags that should be used when filing bugs in various Linaro projects (gcc-linaro, linux-linaro, linaro-oe, etc.) There's also a shared bug tracker at https://launchpad.net/linaro-aarch64 for distros to use, so we don't waste time working in parallel on the same bugs for AArch64 support. When using this, please file bug reports in-distro first and link to these. Once fixes are accepted upstream, mark the linaro-aarch64 bugs fixed. Distro AArch64 status ===================== * Ubuntu: * http://wiki.debian.org/Arm64Port * https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/arm64bootstrap * Raring has all components required for armv8 cross toolchain * Debian * http://wiki.debian.org/Arm64Port * Fedora * Jon Masters has scanned the package set for assembler code, identifying probable pain-points Tools ===== Steve working on strace support - 64-bit is done, working on using 64-bit strace with 32-bit binaries next. Ptrace patches for gdb are submitted, but until things stabilise people will need to match up kernel and tools to get things working here. Standard install instructions for distros? ========================================== Some discussion about how different various of the ARM boards are in terms of setup; could/should we talk to them and give recommendations on making them easier to work with? Ideas: * Default boot process in server world is UEFI+GRUB. Stick with that. * Partition layout recommondation (FAT partition for UEFI?) * Would distros and board makers follow such doc if it existed or will everyone prefer to "add value" in this area? * Linaro should write doc with default recommendations, which in long term should reduce variation and feed into SOC manufacturer boot code Network booting =============== Lots of people are interested in this, especially for installing clusters of machines like Calxeda/Dell offerings. How should people do this? 'Use PXE' doesn't really help. There is PXE support in uboot, developed by Calxeda. Is anybody working on PXE support in UEFI? Linaro Enterprise Group should... We could do with some recommendations for how this area should work - prod the LEG people! Cheers, -- Steve McIntyre steve.mcintyre(a)linaro.org <http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs

13 years, 1 month

U-Boot env. var. fdt_addr vs. fdt_addr_r

by Stephen Warren

Rob, in git commit 49a3fb455890dd9d53a18573d0998edb8332fc4a (from git://git.linaro.org/boot/u-boot-linaro-stable.git), there is: +fdt_addr=0x1000 +pxefile_addr_r=0x700000 +kernel_addr_r=0x800000 +ramdisk_addr_r=0x01000000 Why is that first line fdt_addr not fdt_addr_r; the latter appears more often in mainline U-Boot and is what's mentioned in README too. (as background, I'm working on a change to switch Tegra to using the standard env. var. names in mainline U-Boot and was snooping on what you'd done for Highbank!)

13 years, 2 months

supporting DTB files

by Dennis Gilmore

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey all, So as distros we are soon going to be forced to support DTB files. Fedora likely sooner than the rest as we closely follow the mainline kernel throughout the life of a fedora release. Ideally the device manufacturers will provide dtb files. but then devices like the pandaboard, beagleboardXM etc with no storage to speak of we have to ship u-boot so likely will need to ship dtb files also. so far the best vendor i know of for dtb support is calxeda. and thats where we should encourage vendors to emulate, but until we get to there we need to take baby steps. I was wondering what the distros were planning to do, or has it even been considered? Fedora 18 will likely ship 3.6.x but will be updated to 3.7.1 likely and also 3.8.x if not 3.9.x We get the joy of things breaking every kernel release because no one else seems to be testing or using the upstream kernel. I would like to see us as distros and linaro go to the vendors and get them to ship dtb files and updated u-boot with dtb support. Ideally with some consistent macro use to make distro support of u-boot saner. appended dtb is pretty ugly and I do not want to support it. I feel like we have an opportunity here to correct some of the wrongs of the past as u-boot updates will be forced on the world to deal with the forced move to DeviceTree. do we have vendors on this list? if not can we get the list of contacts and reach out to them to get things straightened up? Dennis -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAlBSCpsACgkQkSxm47BaWfcHeACeOkvZUdoGQOKBI9u2K/g5Fjct BTEAn2ArwfQbGTVcmFK3y/FzJDsftGQq =wMfb -----END PGP SIGNATURE-----

13 years, 2 months

U-Boot and architecture detection

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, 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

13 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

13 years, 3 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.

13 years, 3 months

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

cross-distro