cross-distro

cross-distro@lists.linaro.org

1 participants
221 discussions

arm64 Debian/Ubuntu port image available

by Wookey

State of the Debian/Ubuntu arm64 port ===================================== *** Arm64 lives! *** Executive summary ----------------- * There is now a bootable (raring) image to download and run * Everything has been rebuilt against glibc 2.17 so it works * A bit more work is needed to make the rootfs useable as a native buildd * Multiarch crossbuilding and the build-profile mechanism is mature enough to cross-build a port from scratch (this is a big deal IMHO) * All packages, sources and tools are in a public repo and this work should be reproducible. * This image is fully multiarched so co-installing armhf for a 64/32 mix should work nicely, as should multiarch crossbuilding to legacy x86 architectures. :-) (but I haven't tried that yet...) * Linaro wants 'the distros' to take this work forward from here so people interested in Debian and Ubuntu on 64-bit arm hardware need to step up and help out. Bootable images --------------- A milestone was reached this week: Enough packages were built for arm64 to debootstrap an image which booted to a prompt! After a bit of fettling (and switching to multistrap) I got an image with all the packages configured which boots with upstart to a login prompt (I admit, I did get quite excited about this, as it represents the coming together of nearly 3 years work on multiarch, crossbuilding, bootstrapping, cyclic dependencies and arm64 :-) The images are available for download: http://wiki.debian.org/Arm64Port#Pre-built_Rootfs And there are destructions there for making your own. All these packages were cross-built on raring, untangling cyclic dependencies with build profiles (see wiki.debian.org/DebianBootstrap for how that works), making this the first (non x86) self-bootstrapped debian port ever (so far as I know). All (?) previous ports have been done using something else like OpenEmbedded (armel, armhf), RedHat/HardHat (arm, alpha, mips), something IBMy (s390) to get an initial linux rootfs on which debian packages are built. The new bootstrap process is (almost) just a list of sbuild commands. In practice there are still a few rough edges around cross- build-dependencies so of the 140 packages needed for the bootstrap, 9 had to be built manually with 'dpkg-buildpackage -aarm64 -d' (to skip build-dep checks) instead of 'sbuild --host arm64 <package>'. The current bootstrap packageset status is here: http://people.linaro.org/~wookey/buildd/raring-arm64/status-bootstrap.html There is no armv8 (arm64/aarch64) hardware available yet, so this image can currently only be run in a model. ARM provide a free-beer prorietary 'Foundation model' so we do have someting to test with. It's sluggish but perfectly useable. Booting the images takes a couple of minutes on my fairly average machine. The images are using the Linaro OE release kernels which seem to work fine for this purpose. Thanks to Marcin for modified bootloader lines in .axf files. Image status ------------ I was impressed that things basically 'just worked' on first boot. There is of course plenty of breakage, I'm sure, and I haven't looked very hard yet, but it's a lot better than I expected after months of just building stuff and testing nothing. (Things that are poorly: nano can't parse it's own syntax-coluring files for example, and multiarch perl has the wrong @INC path compiled in; I'm sure there is more). Consider this alpha-grade until it's been used a bit more. Things that are not yet built which would make the images a lot more useful are apt and a dhcp client. apt needs gnupg needs curl needs nss. The nss cross-build needs fixing to unbung that. A debian chroot without apt turns out to be disappointing quite quickly :-) Expect an updated image with more packages very soon. Multiarch crossbuilding ----------------------- It's really nice to have building and crossbuilding using exactly the same mechanisms and tools, with all files having one canonical location, and dependency mechanisms that are reliable. The more I've used this, the more I've been impressed by it. There is still work to do to expand the set of cross-buildable stuff, but it's a solid base to work from. Getting this port working has been 'interesting' because it's attempting 4 new things all at once: multiarch (file layouts and dependencies), crossbuilding (tools and packaging support in a distro that historically was always natively built), arm64 (aarch64) support in packages that need it, and build-profiles to linearise the build-order. The arm64 part of this is a relatively small part as the heavy lifting has been done upstream (gcc, (e)glibc, binutils, kernel, libffi, autotools and a lot of minor fixes in various packages). Thanks are due to doko (Matthias Klose) for sterling work getting all that integrated into the debian and ubuntu toolchain packages, and infinity (Adam Conrad) for merging various eglibc branches. There were also hordes of very boring patches of the form 'update config.sub and guess before building'. Most of the work has been in making things cross-build (exactly the same fixes needed for armel/hf too so I've had plenty of help there from canonical types who want cross-building for arm to work nicely), and particular thinks to Neil Williams for taking on the perl cross-build challenge and creating the debian-perl-cross package to manage the cross-configury, whilst also working with upstream to make the whole thing a bit less 1996. Multiarchifying has been going on nicely in libraries and -dev packages, but things like perl and python needed significant work, along with a lot of boring bugs saying 'mark this package MA: foreign' and 'build-dep on python:any or perl-base:any'. Thanks are due to doko for the python multiarching and Niko Tyni for the perl multiarchification. Getting all 3 'aspects' of multiarch perl, cross-built perl and arm64 perl config to work at the same time was quite hard work, and there are still bugs there. Wider usage of multiarched perl would no doubt sort this out reasonably quickly. I started a wiki page to track the status of multiarched cross-buildable perl: http://wiki.debian.org/Multiarch/Perl . Help would be welcome. The build-profile work is described on the http://wiki.debian.org/DebianBootstrap page. Progress has been greatly helped by GSOC projects last year, with good work on the tools (crossbuild-essential packages, build-profile support) from P.J McDermott and an impressive contribution from Johannes Schauer on dependency analysis tools around libdose, and apt build-profile support. All of this apart from multiarch perl, crossbuildable perl and build-profile stuff (and a few pending patches) is already in raring. Building stuff yourself ----------------------- Setting up an arm64 build environment is very simple. Use sbuild-createchroot or mk-sbuild and point at the bootstrap repo, with a bit of config and some updated tools packages from the repo (amd64 only supplied). Details are given on https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/arm64bootstrap Once you've created a tarball chroot builds are simply done with sbuild -c quantal-amd64-sbuild -d quantal --host=arm64 <package.dsc> or sbuild -c quantal-amd64-sbuild -d quantal --host=arm64 <package>_<version> (I'd love it if sbuild got smart enough to work out the version itself when given a distro - Roger says he's working on it) To deal with the chore of 'find version, run sbuild, sign result, upload to repo, import to repo, deal with reprepro bitching if you re-upload the same version of something' for every package build, I wrote 'dimstrap' which is a simple-minded tool to wrap that up and either do one-off builds or run through a list. It is part of the xbuilder package here: https://launchpad.net/~linaro-foundations/+archive/cross-build-tools/ It also includes the logfile-parsing script ('generate html') which generates the nice status pages: http://people.linaro.org/~wookey/buildd/raring-arm64/status-bootstrap.html Image building -------------- The config and instructions provided (in http://wiki.debian.org/Arm64Port#Building_your_own_rootfs_image ) is for multistrap. Debootstrap sort-of produces working images too but takes a lot longer to unpack/configure, and misses out various vital packages (like libperl5.14). I'm sure it could be kicked into submission. In theory multistrap (apt really) should have got all the arch all packages from the main repo, but in practice it refused to do that so I had to rebuild them or copy them over anyway (grumble). Any package that installs replaced conffiles seems to generate invalid dpkg status entries (ifupdown did this to me). I've not got to the bottom of that yet. Deleting the offending line gets you an image that works. Issues ------ General: The build-profile patches for dpkg and apt need to be pushed into the distro to make that feature permanent. A thread on debian-devel is working on that (http://debian.2.n7.nabble.com/Bootstrappable-Debian-proposal-of-needed-chan…). The main issue is what syntax to use '<>' or '[]' and how to deal with multiple overlapping profiles. The patches to debian control cannot go in until at least the syntax is agreed and the tools will parse them without barfing. Johannes ands I will send an updated spec soonish. The missing piece of bootstrapping with regard to build-deps is packages that build-dep on gcc-4.6 or binutils. When cross-building this should be satisfied by <triplet>-gcc-4.6 or <triplet>-binutils. Nothing makes that happen currently. A scheme has been mooted but nothing is implemented yet. There is debate about whether cross-toolchains should build against multiarch libraries (libgcc, libstdc++) like everything else, or have their own internal copies. Doko and I disagree on this matter. That will need to be worked out at some point. We won't get that much further with fixing cross- object-introspection, which is a non-trivial job. Image-related: The images do essentially work but very little has been tested so far. Multiarch perl still needs work. nss needs cross-building in order to get apt cross-built I've not got networking working yet. Info is here: https://fedoraproject.org/wiki/Architectures/ARM/AArch64/FoundationModel_Ne… lack of a dhcp client in the image hasn't helped there. More info --------- The canonical arm64 port info page is: http://wiki.debian.org/Arm64Port Full arm64 cross-build status (i.e everything that has been tried) is here: http://people.linaro.org/~wookey/buildd/raring-arm64/status.html All the patches generated so far are here: http://people.debian.org/~wookey/bootstrap/patches/ (most that can, have been filed as bugs - there is a backlog of stuff filed in Launchpad but not yet forwarded to the Debian BTS - yes I am a bad boy - blame the fact that you can't use reportbug or bts from inside ARM due to their idiotic email policies). Future work ----------- Firstly we should say thank you to Linaro for sponsoring this work in various ways over the last 3 years. We wouldn't be at this point now if it wasn't for that. However Linaro has a lot of things to do and is trying hard not to do distro's work for them, concentrating on upstream things. This makes sense for commercially-backed distros like Red Hat and Ubuntu, but rather less for Debian where we _are_ the distro just as much as anyone else is, and ultimately someone has to spend the time to get stuff working. Anyway, I was supposed to stop work on this some time back, but have largely failed to do so (cross-building is so moreish - there is always one more build to try before bedtime!) and appreciate being given enough slack to get this to a point of actual utility. However I expect to have much less time to spend on this from now on, except insofar as it still co-oncides with things Linaro wants doing. I'd love to hear from people who actually want to use this, to get more packages built, the Debian cross-toolchains sorted, build-profiles finalised, and a whole pile of stuff fixed once Wheezy is released. I'm pretty sure there are quite a lot of people who want multiarch Debian or Ubuntu on their arm64 machines (or models). I hear rumours that actual hardware may appear sometime around the middle of the year with some bagsied for Debian. Setting up the ports infrastructure for that would be good. I don't know if anyone is interested in building slowly on models in the meantime, or if we should just carry on crossing and see how far we get. This table shows that 471 packages in raring can be expected to cross-build already: http://people.canonical.com/~cjwatson/cross/armhf/raring/ Todo: Fix up multiarch/cross perl Fix nss Build missing packages for apt Build missing packages for build-essential Build Debian cross-toolchain Get all this working in unstable as well as raring Setup buildds Build all the other packages Set up automated bootstraping runs (eventually) Current setup ------------- Builds have all been run locally using the sbuild/chroot setup described above and on the Arm64Port page, which should be easy for anyone to reproduce. The main irritation is keeping up with raring: out of sync libraries are not MA-installable. Logs are uploaded to people.linaro.org (rsync). The reprepro repo is on people.debian.org (dupload). This stuff should probably move to ports.debian.org and ports.ubuntu.com, but neither of those are set up for cross-building so I'm not quite sure how this will work. I could go on at great length about the machinery of profiled bootstrap builds, and interactions between tools, but it's not very exciting, so will resist. Suffice it to say that whilst it's all pretty slick I'd still like better buildd tools. Build-profile changes --------------------- The build-profile patches are not yet upstreamable so are collecting in the repo. The patch set so far is here: http://people.debian.org/~wookey/bootstrap/patches/profiles/packages/ Other thanks: Other people who have helped make this happen in various ways but not got a mention above: Colin Watson, Dmitry Ledkovs, Steve Langasek, Harry Leibel, Thibaut Girka, Roger Leigh, Marcus Shawcroft, James Morrisey, Jonathan Austin, Steve McIntyre, Peter Pearse, Aurelien Jarno, and whoever does sysadmin at people.{linaro,debian}.org I hope I didn't forget anyone, or any important information. Feedback from anyone attempting to get this working outside my computer is very welcome. I have almost certainly forgotten to write down some things, and upload correct versions of some other things. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/

13 years, 5 months

[Announcement] openSUSE 12.3 preview available for AArch64

by Dirk Müller

Hi cross-distro readers, the openSUSE on ARM team was quite busy the last few weeks with getting openSUSE 12.3 for AArch64 ready. At the time of this post, we have finished around 4000-4100 packages (out of ~ 6000) of the current state of the openSUSE 12.3 project for AArch64. With those successfully built packages, we’re also able to build a regular openSUSE image for you to try and run in the ARMv8 System emulator (ARMv8 Foundation Model). This is a huge achievement and milestone for us, thanks to lots of helpful hands in openSUSE. Just to put this into context: This is not a minimal system with a couple of toolchain packages. It is also not an embedded variant of a Linux environment. No, this is the full featured, standard openSUSE distribution as you’re used to, ported to AArch64, up and running. We have built it based on (slightly newer versions of) standard openSUSE 12.3 packages, and the changes are mostly already merged back into openSUSE Factory. For all we know it’s also more successful package builds than any other Linux distribution has on AArch64! If you’d like to see the status yourself, please check out the OBS repository we created for this [1]. As an open distribution, it is important to make contributions easy and we worked hard to enable others to participate in our effort. We extended OBS (the Open Build Service) to automatically spawn a Foundation Model virtual machine when you want to build for aarch64. This works remotely on the OBS server as well as locally using osc build. Building for AArch64 is therefore as easy as building for any other architecture, and it feels native to all who are familiar with the OBS. More information on this is available on the respective wiki page [2]. So, dive right into it: Get the image and start with openSUSE on AArch64 by following our wiki page: https://en.opensuse.org/Portal:ARM/AArch64. Please contact the openSUSE Team at opensuse-arm(a)opensuse.org Greetings, Dirk (openSUSE ARM Team) [1] https://build.opensuse.org/project/show?project=devel:ARM:AArch64:12.3 [2] https://en.opensuse.org/Portal:ARM/AArch64

13 years, 5 months

AArch64 triplet

by Jon Masters

Hi Folks, I propose the following triplet for Fedora on AArch64: aarch64-redhat-linux-gnu Skipping the vendor part, that means generally: aarch64-linux-gnu There should be no reason to deviate from this. I'm putting it out there now because I don't want another ARMv7 experience later :) Jon.

13 years, 8 months

Fwd: AArch64 triplet

by Jon Masters

Meant to reply to the list. Begin forwarded message: > From: Jon Masters <jonathan(a)jonmasters.org> > Subject: Re: AArch64 triplet > Date: November 22, 2012 3:32:45 AM EST > To: Mike Frysinger <vapier(a)gentoo.org> > > > On Nov 20, 2012, at 1:27 PM, Mike Frysinger <vapier(a)gentoo.org> wrote: > >> On Tuesday 20 November 2012 03:25:56 Jon Masters wrote: >>> The only reason for making a change at this time appears to be cosmetic, >>> for removing /lib for example. I can understand that, and if we were >>> discussing this a year ago (or even months ago when I first raised it on >>> this list), then it might be a reasonable change, but at this time I >>> cannot find an overwhelming technical justification. >> >> i don't think removal of /lib/ is really feasible. that's the path that gets >> used for firmware (/lib/firmware/) and kernel modules (/lib/modules/<kver>/) >> regardless of the default ABI on the system. >> >> similarly, userspace packages are using that path for supplemental files like >> the bootloader (grub) or ABI-independent settings (udev rules). > > Sorry for the confusion. By "getting rid" what I mean is not having libraries in there. As is obvious, there will always be plenty of stuff in there, and it's mandated by standards anyway. So, really, if it's down to whether we (Fedora) have one thing in /lib that could be in /lib64 vs. not then I would rather just keep the dynamic linker where it is in /lib and move on with life. > > By the way, we announced our initial Fedora bootstrap work tonight. The wiki has a lot of information about what is currently being done, along with initial images that will grow: > > https://fedoraproject.org/wiki/Architectures/ARM/AArch64 > > Jon. >

13 years, 9 months

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

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

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

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

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

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

cross-distro