Re: Bug Fix for ARMv8 bootup in Foundation_v8pkg
On Thu, Nov 29, 2012, Sagar Kadam wrote: Thanks for hosting a bug on my behalf. Just a small query: To provide a patch for OE build, shall I extract the core-image-minimal-genericarmv8-20121019001847.rootfs.tar.gz add entry for /dev/ttyAMA into the /etc/device_table and provide its patch. Best to discuss this directly in the bug; it seems we might be expecting devtmpfs to be mounted via the kernel cmdline request to do so. I don't think it's a good idea to mount devtmpfs from fstab, there are usually special purpose init pieces which do the mounting BICBW. -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Bug Fix for ARMv8 bootup in Foundation_v8pkg
Hi, On Tue, Nov 27, 2012, Sagar Kadam wrote: The following is the error message Starting Boolog daemon: bootlogd: cannot find console device 204:64 under /dev Indeed, /dev/ttyAMA0 is missing from the rootfs; thanks for pointing this out. I've logged this problem on your behalf in: https://bugs.launchpad.net/linaro-oe/+bug/1084037 +CONFIG_DEVTMPFS_MOUNT=y This change might be too intrusive; we probably want to just patch our OE build to include the missing device node along the other ones. Thanks! -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Installable ARMv8 cross-toolchain
On Sat, Nov 03, 2012, Marek Vasut wrote: I need to catch up with you in there ;-) What do you use for a bootloader on these armv8 devices? No bootloader at the moment, but a boot wrapper! ;-) At the moment, ARMv8 work is mostly on virtual platforms (I guess there might be some people with expensive FGPAs too); the two virtual platforms Linaro is using are: * the free (as in beer) ARMv8 Foundation model (Foundation) * the pre-built ARMv8 Versatile Express model (VE RTSM) ARM recently published some information on the various models at: http://www.arm.com/fvp The two virtual platforms are relatively similar; the main differences are: * VE model has a MMC while the Foundation model has an AMBA virtio block device * VE has a RTC while Foundation model hasn't * VE has an AMBA LCD (clcd) while Foundation model hasn't At least the first difference prevents us from sharing a single Device Tree with all devices between the two platforms (kernel oops when starting the Foundation model with the MMC listed or vice-versa). To boot the platform, a small boot wrapper is combined with the kernel, device tree, and kernel cmdline into an ELF .axf file for the model to run. This page explains how to rebuild kernel + device tree + boot wrapper: https://wiki.linaro.org/HowTo/BuildArm64Kernel (the boot wrapper is maintained by Catalin Marinas on git.kernel.org) The plan is to switch to a full bootloader -- likely Tianocore (UEFI) -- when available as it's painful to have to rebuild the .axf whenever the kernel or kernel cmdline change, and real hardware wouldn't use a boot wrapper anyway. I guess you're asking because you consider an U-Boot port? :-) Cheers, -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Support for Raspberry Pi
Hi Geert, On Fri, Nov 02, 2012, Geert Schuring wrote: Could you tell me if you have any plans to enable Ubuntu on the Raspberry Pi (ARMv6) ? Short answer: an Ubuntu ARMv6 port for the Raspberry Pi isn't a Linaro target, but we're taking patches and we're interested in some bugs! :-) There are two main reasons for that: - Linaro doesn't have the capacity to do large scale distro ports, this is usually mainly the job of distros, and we're sometimes giving a hand - Linaro is all about the future of ARM, so the focus is mainly on ARMv7 and ARMv8 at this point That said, there is hope! First, a bunch of Linaro folks have a Raspberry Pi and play with it; second, I believe Ubuntu's armel port is being re-targeted to ARMv5, so Ubuntu armel binaries should eventually run on the Pi. Linaro does directly care about toolchain regressions you might encounter on ARMv5/ARMv6 (or even on x86), so please do report us any toolchain regressions caused by Linaro patches. Cheers, -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro Website Contact
Hey (Cc:ing linaro-dev@ where we usually discuss technical stuff) On Wed, Oct 31, 2012, sundar.subramani...@gmail.com wrote: This is great. Just tried the pre-compiled image and works like a charm. It took a little longer than two minutes though on my i3/4Gig machine. Haven't yet tried compiling anything yet but how do i get started with porting some libraries to armv8? Just compile with the toolchain and run? Great! This page gives some ideas on how to rebuild the filesystem and how to fix some common issues: https://wiki.linaro.org/HowTo/ARMv8/OpenEmbedded Perhaps you want to try to build this or that software you care about, or just try bitbake world to build as many things as possible and see what breaks :-) Cheers, -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: git.l.o: please add post-update hooks to run git-update-server-info
Hi My instructions were actually not correct; two points I failed to highlight: * some old template hooks had git-update-server-info but that doesn't exist anymore; instead one is supposed to run git update-server-info; please check that your hooks/post-update scripts use the new command * you need to run this once to update refs, otherwise git update-server-info will only run on the next git push; please run git update-server-info in each of the affected .git repos! Thanks, -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
git.l.o: please add post-update hooks to run git-update-server-info
/lt-ti.git people/asac/android/kernel/pandroid.git people/asac/android/u-boot/pandroid.git people/rusty/qemu-linaro.git people/sachin/linux-linaro.git people/sachin/linux-kernel-samsung.git people/sachin/linux-linaro-2.6.36.git people/sachin/linux-linaro-3.0.git people/sachin/linux-linaro-2.6.38.git people/sachin/linux-linaro-3.1.git people/jserv/omap4-frameworks-base.git people/amitdanielk/thermal-test.git people/amitdanielk/linux.git people/amitdanielk/pm-qa-thermal.git people/amitdanielk/library/libnl.git people/amitdanielk/powertop.git people/patrikryd/b2r2lib.git people/patrikryd/panda.git people/patrikryd/pandaboard.git people/patrikryd/build.git people/riczhao/linux-2.6.git people/chunsangjeong/gralloc-dev.git people/sudip-jain/smartt-old.git people/mandeep-ti/libjpeg_8b_neon.git people/ronynandy/speex.git people/ronynandy/u-boot-arndale.git people/ronynandy/edk2-origen.git people/ronynandy/speex_ubuntu.git people/ronynandy/linux_stable.git people/bhoj/boot-wrapper.git people/bhoj/test-manifest.git people/ycmiao/pxa-linux.git people/vireshk/module.git people/vireshk/linux-linaro-big-LITTLE-MP.git people/dooferlad/patchwork.git people/jessebarker/linaro-mm-sig/linux.git people/jessebarker/linaro-mm-sig/linux-2.6.git people/sachin-gupta/gstreamer.git people/stevejahnke/kernel-thermal-framework.git people/stevejahnke/thermal_manager.git people/pfefferz/manifest.git people/pfefferz/linux-2.6.git people/doanac/LinaroConnect.git people/doanac/monitis_python.git people/doanac/linaro-toolchain-benchmarking.git tools/arm-probe.git arm/big.LITTLE/mp.git ubuntu/linux-linaro-oneiric.git ubuntu/future-linux-linaro-precise-3.2.git ubuntu/linux-linaro-quantal.git ubuntu/linux-linaro-precise.git ubuntu/linux-meta-linaro-natty.git landing-teams/working/samsung/edk2-origen.git Thanks! -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Lava images improvement idea
On Wed, May 23, 2012, Alexander Sack wrote: Assuming we want to do this, would we really make a -lava variant? Why not include the tests in the LEB directly? Android already ships the tests in the image, so it wouldn't be something entirely new. +1; the test helpers should just be installed by default; I don't think having separate -lava images is a good idea, it's a lot of maintenance and direct costs when we can do it directly in our main images for little overhead. -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: android-build's are failing, we're on it...
* IRC is nice for this kind of announcements; you can even put it in the #linaro topic * perhaps we can just add a banner to android-build.linaro.org? * perhaps a Linaro services dashboard is what we miss? e.g. Android build system: working (green), or broken (see LP #1234); Joey is running a basic HTTP status monitor as part of Linaro IS * notifications about build system going down could go to the same places where build failures / successful builds are reported; perhaps we need a dedicated build-notifications list or something like that -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: jenkins really broken right now
On Wed, Mar 28, 2012, Alexander Sack wrote: The builds went through _after_ i disabled the git proxy setting. Before that kernel_cloud builds failed after we shut down the old instance. Right; and the proxy setting was also bogusly pointing at the internal EC2 IP which is why it kept pointing at the old instance; when we set it up again we should use ci.linaro.org as hostname for the proxy, this will resolve to the internal EC2 IP when queried from within EC2. -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: How to install OpenCV in Linaro Android on Pandaboard
On Fri, Mar 23, 2012, Christian Robottom Reis wrote: Is there OpenCV code actually available for the Panda yet? Last time I checked it was yet to be released. The opencv libraries themselves are built on armel/armhf in Ubuntu, but I don't know whether there is an easy way to use them on Android, nor whether there is specific hardware accelerator that could be leveraged on pandaboard. -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Plan for changing the binary toolchain to 4.7 and hardfloat
On Fri, Mar 16, 2012, Michael Hope wrote: https://wiki.linaro.org/MichaelHope/Sandbox/BinariesMigration Is there a separate plan for gcc-4.5 deprecation in source releases? The triplet situation is sad; is there any hope that we fix this upstream? -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Linaro-big-little] Sample big.LITTLE model boot images
On Tue, Feb 28, 2012, Dave Martin wrote: I've added some detailed info on the wiki about how to go about building bootable images for the big.LITTLE components, here: https://wiki.linaro.org/Internal/Projects/Big.Little.Switcher/ARMFastModelsHowto Could you share the model binaries within Linaro so that Linaro folks with a FastModels license or access to a licensing server just have to combine: - model binary - license - your boot wrapper - your sample kernel and rootfs to get things working? Perhaps in your home dir on people.linaro.org. (Unless you can share it publicly, in which case do put it in your ~public_html or on the wiki page! :-) -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: LiveBuild failure creating nano image
On Wed, Feb 08, 2012, Fathi Boudra wrote: find log attached http://people.linaro.org/~lool/linaro-dev/binary.log.gz -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Sources for 11.11 kernel release
On Fri, Jan 27, 2012, Alexander Sack wrote: * hide people/ trees and show them on people.git.linaro.org instead of main git.linaro.org. At best git:// urls would be valid still aftterwards * hide the android/ trees and don't show them anywhere else; keep git:// urls and/or http:// clone urls wprking too This would definitely air to breath and we can continue to improve things from there. The arago-project layout seems nicer, effectively just hiding subtrees rather than using separate DNSes; also, they are linked from the main repos to the other ones, whereas if we create a people.git.linaro.org, how will people discover it? It's best to avoid having 3 places/hostnames for people to host stuff. As one example, ubuntu packages having a vcs-bzr field and a reasonable tagging/versioning scheme could probably work, but we have to look case by case. Problem is that a Vcs-* field is not consistently applied :-/ Sometimes it's not set, or doesn't point at the right repo, or points at a repo with a special tree where people have to do magic to get things done. -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Sources for 11.11 kernel release
(dropping linaro-kernel@) On Thu, Jan 26, 2012, Dave Martin wrote: deb http://ports.ubuntu.com/ubuntu-ports precise main deb http://ppa.launchpad.net/linaro-maintainers/overlay linaro-12.02 main And http://ppa.launchpad.net/linaro-maintainers/overlay/ubuntu/dists/linaro-12.02/Release and the things it points to would then be authoritative definition of what was in that release for evermore (or at least, the GPL-requisite 3 years). [...] Do you know if this is sensible/doable, or is launchpad very tied the ubuntu release names? It's not possible with the current web UI of PPAs, but the Launchpad code is flexible in this area and it would likely be possible to do things like that, albeit it would be a bit weird to combine distros together (precise from Ubuntu with linaro-12.02 from Linaro). Launchpad gained over the last year improved support for derivatives but that means forking Ubuntu for Linaro and then constantly merging from it, having our own archive etc.; the only entry would be: deb http://archive.linaro.org linaro-12.02 main This is something we envisioned doing in the early stages of Linaro, but Launchpad wasn't ready and it was costly to maintain, now it would be costly to switch; perhaps the incentive is strong enough though. Another way to solve this could be to defer to some automated service for publishing our bits rather than uploading them ourselves; for instance we would point a robot at the git repo where the TI LT kernel for release is kept, and it would be assembling a source package from it and publishing that to some Vcs and to the release PPA. That way we would ensure we always now where we took the source from, how it was built etc. and can enforce any rule we like. This would be comparable to the automated merges of some bzr branches in Launchpad where a robot tries running the testsuite and then merges the branch in tip if that passes, but humans never push to tip. Availibility of the original (git or not) source is a long standing problem which is partly due to the PPA rules (which are dropping some sources after being superseded for a while) and partly to relying on humans to document things like Vcs-Git properly. -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: boot armv7 on qemu-linaro
Hey On Wed, Jan 11, 2012, Andrei Gherzan wrote: I'm struggling to find a way of booting an armv7 fs compiled with poky / yocto. I found some resources on the internet but none proved to be successful for me. Would you be so kind and provide me some infos upon this topic? There are a couple of HowTos on the wiki linked from https://wiki.linaro.org/Resources/HowTo/Qemu but the instructions might not be fully up-to-date; perhaps they provide enough guidance for you to overcome your issues? Would you fix or point out the issues in the HowTos if they fail you? Thanks! -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: RFC: Ideas for Linaro
On Wed, Jan 04, 2012, Joey STANFORD wrote: http://brainstorm.ubuntu.com/ I love the concept and implementation of brainstorm -- +1 -- but will we commit to implementing x things per cycle from brainstorm.linaro.org if we start advertizing it? The worst thing would be to give people a place to suggest work and then ... ignore it. -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: launchpad: ddeb packages in ppa problem
Reported at https://bugs.launchpad.net/launchpad/+bug/888204 Thanks -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: ELC-E Linaro Android Presentation For Comment
On Mon, Oct 24, 2011, Zach Pfeffer wrote: Here's what I've got so far, More to come on Benchmarking, Andy's kernel process, LAVA and toolchain. I stripped attachments in moderation and put them at: http://people.linaro.org/~lool/zach-elce/Linaro_Android_Presentation.odp http://people.linaro.org/~lool/zach-elce/Linaro_Android_Presentation.pdf -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro CI hwpack name improvements
On Mon, Oct 10, 2011, Deepti Kalakeri wrote: 1) The board on which the hwpack can be booted 2) The hwpack creation timestamp includes the date in mmdd format along with the time in hhmm format. The hwpack name does not include any defconfig related information, which was used to build the kernel. Do we need to use the defconfig name as well to be part of the hwpack name ? Is there any other information you would like to include in the hwpack name ? Or do we need to continue with the current hwpack names ? We rarely use a defconfig alone; however in the case of kernel .debs, you should find the corresponding config under boot/config-`uname -r` in the .deb (dpkg-deb -x the kernel .deb to find the config). -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: debuild no secret keys
On Sat, Oct 01, 2011, Tom Gall wrote: gpg: skipped Tom Gall tom.g...@linaro.org: secret key not available gpg: /tmp/debsign.Or3BKbui/live-build_3.0~a21-1linaro9~natty1.dsc: clearsign failed: secret key not available debsign: gpg error occurred! Aborting Yet if I gpg -k on both a good machine and this new box I see the exact same set of keys listed. gpg -k lists public keys. see what gpg -K lists? Yet again the same output for gpg -K on both machines. Does your key have exactly Tom Gall tom.g...@linaro.org as one uid? If not, you might have to set explicitly which key id to use (-k1234ABCD); perhaps this is a config that you didn't copy over. -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro Boot up times.
On Mon, Sep 12, 2011, Sudhangathan B S wrote: Is there a way to boot up Linaro in under 40 sec. ?? This could include increasing CPU speeds or more OS tweaks There are plenty of ways to improve boot, the most effective way being to remove things you don't need (e.g. not starting services you wont use, not building features in your kernel that you don't need etc.). So it's extremely specific to one's own view of what can be removed and what should be kept. -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: First 11.09 Linaro Android Candidate Builds are done for (Linux 3.0.3, GCC 4.6, libjpegturbo) Panda, Beagle, Beagle xM, iMX53, Origen, Snowball
On Mon, Sep 12, 2011, Zach Pfeffer wrote: I think stage is okay. Its short for staging which is used in the kernel as a place for things which aren't mainline. If I hear of any other issues with the name I'll think we can reevaluate it, but overall I think the term stage is okay. Sorry for the bikeshedding. staging or staged would in my eyes be much clearer than stage. -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Non-FOSS license acceptance by robots
On Wed, Sep 07, 2011, Tony Mansson wrote: The Snowball s/w design team decided to use the debian mechanism for license acceptance of h/w-pack binaries, so there are pop-ups when you run Linaro-Media-Create. Is this a debconf note or prompt? When Validation creates new images all the time, the conscious action click through must be replaced by the conscious action I am the maintainer of this Validation farm, I hereby accept the license once and for all and from now on l-m-c will not pop up the licenses in any of *these* packages that are automatically installed in my lab. if it's debconf based, you want to preseed the debconf database with debconf-set-selections to set the relevant flag before installing the packages. Image creation tools could be patched to allow running a custom script before installing hwpacks; you would pass a script which would run debconf-set-selections. See also debconf-get-selections to dump your debconf question db. -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Request] Can Linaro-dev not send duplicate mail to recipients?
On Thu, Sep 01, 2011, Christian Robottom Reis wrote: On Wed, Aug 31, 2011 at 09:05:55PM -0700, John Stultz wrote: It seems the linaro-dev list isn't configed to avoid mailing folks who are already recipients of the email. So if you're on linaro-dev and you're also To/CC'ed in the email, you get it twice (three times if your other work email was CC'ed as well, but that cannot be helped). Someone else already told you about your personal mailing-list settings to avoid multiple copies of messages; I wanted to add that the default config on linaro-dev@ has always been for copies to be discarded by default. You might be getting copies from other lists though (e.g. I get bug updates from launchpad and from launchpad team mailing-lists), which you can confirm by looking at the List-Id header or at the Received headers. The big hammer is filtering copies out yourself as others have suggested (procmail's formail -D is one example). I know this is controversial, but I really like that pattern. It ensures that I filter messages that are directly to me specially, while the rest just goes into a lower priority archive folder. (same here; mailing-list traffic is kept in folders and mail directed to me in a different one) -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Tracking Android kernel tips and Android builds
On Fri, Sep 02, 2011, Zach Pfeffer wrote: repo bootstraps itself by syncing the repo guts from google, google signs the repo guts so that people know that they're using a trusted source. As our repo in not a trusted source, people may be reluctant to use it and will instead use Google's version which won't work 100% of the time for the reasons already discussed. I think there's an env var to disable the auto-update of repo; we could set it in our instructions or in build wrappers, and/or we could patch repo to update itself from linaro.org instead. -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Generic Linux cross toolchain for tests
On Mon, Aug 22, 2011, Marcin Juszkiewicz wrote: Some time ago we agreed that not everyone here uses Ubuntu distribution and decided to provide so called 'generic linux' cross toolchain. Recently I managed to get it done and now need brave testers to tell is it working or not. Get it here: http://people.linaro.org/~hrw/generic-linux/ (64bit only) This is awesome news; thanks a lot for working on this! -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [ACTIVITY] OCTO status report - wk 33.2011 (20110815-20110819)
On Mon, Aug 22, 2011, Christian Robottom Reis wrote: AIUI this is blocked on IS deployment of a new architecture tag. Has this been resolved? not yet; this is tracked in RT #46652 and was blocked on hardware availability and deployment for a while -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [frederik.lot...@arm.com: [UBUNTU] linaro-media-create failing]
Thanks for moving this thread to linaro-dev; I've sent the attached response to Frederik -- Loïc Minier ---BeginMessage--- Hi On Tue, Aug 16, 2011, Frederik Lotter wrote: We have several people here in the support office trying to build an sdcard using the latest hwpack and root filesystem files as found here: http://releases.linaro.org/platform/linaro-n/ubuntu/leb-panda/latest/ We are running into a segfualt in /usr/bin/dpkg during what seems to be the hwpack installation. Please find the log attached. Any suggestions would be greatly appreciated. What's your QEMU version (qemu-arm-static)? Old versions of QEMU have bugs and limitations in their emulation of ARM instructions which might cause weird failures such as segfaults when installing the hwpack. We recommend using the latest version of Linaro QEMU, which should be available for Ubuntu at: https://launchpad.net/~linaro-maintainers/+archive/tools Using a very recent upstream QEMU version would also help emulation. If that doesn't help, please report a bug or ask for input on a technical forum, such as linaro-dev@lists.linaro.org or IRC etc. Ideally, we would detect broken QEMU versions when running linaro-media-create, but it's non-trivial and a low priority feature, so it didn't get implemented so far. Thanks! -- Loïc Minier ---End Message--- ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [frederik.lot...@arm.com: [UBUNTU] linaro-media-create failing]
On Tue, Aug 16, 2011, James Westby wrote: It was in the posted log: qemu-user-static: Installed: 0.14.50-2011.06-0-0ubuntu1~ppa11.04.1 Ah thanks; that's fairly recent, so I guess this is a bug that deserves filing -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Error installing ROS on Linaro
On Tue, Jun 07, 2011, Bradley Powers wrote: This indicates that ROS can't determine the OS. I suspect that this is because Linaro calls itself Linaro, not Ubuntu (which is what the image is). Any ideas on how to get Linaro to call itself Ubuntu, or to get ROS to understand that Linaro means Ubuntu? Linaro images include a modified base-files package which sets up lsb-release configs with Linaro instead of Ubuntu. You're likely seeing the effect of lsb_release output being Linaro according to /etc/lsb-release instead of Ubuntu. One way this could be handled by ROS (or any ISV really) is to use the new dpkg-vendor tool to check whether the current distro has a known distro as a parent. For instance dpkg-vendor --derives-from Debian succeeds under Ubuntu, and dpkg-vendor --derives-from Ubuntu or dpkg-vendor --derives-from Debian should succeed under a Linaro image. Unfortunately, dpkg-vendor is in dpkg-dev, so maybe one nee to parse /etc/dpkg/origins/* manually instead. In the mean time, you can downgrade base-files or edit its conffiles locally. Cheers, -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: proposal for reorganization of releases.linaro.org hierarchy
Hey On Thu, May 26, 2011, Fathi Boudra wrote: releases.linaro.org layout proposal 1 Jamie, Alexander and myself once had a long and relatively painful discussion about the ideal layout; my main argument in the discussion was that the names and contents of our releases will keep changing, we will rebrand the names we use for our outputs (e.g. LEB or platform images), we will add and remove outputs, so my proposal was for the toplevel to be the date of the release, much like the http://releases.ubuntu.com/ toplevel. For a similar discussion on snapshots.linaro.org, http://cdimage.ubuntu.com/ might be a good example where there's only a toplevel by project, then subdirs by date or arch, or whatever. The main advantage of having a /$year-$month/ toplevel is that you magically historize the old product names; people will want the latest release anyway. Back when Alexander, Jamie and I had this discussion, there was an area of confusion for the end-user because we had 6-monthly outputs and monthly outputs, and monthly outputs were not on releases.linaro.org. But interestingly your argument is about user experience, not about the best layout. I don't think browsing a file hierarchy over http is a particularly friendly user experience, nor reading multiple web pages, downloading multiple bits. A better user experience is if we can provide pre-built consumable images as we discussed at Budapest, or if we can provide a tool to download the right hwpack + rootfs for your board and then run linaro-media-create automatically; James Tunnicliffe is working on such a TestDrive tool. It's fair to say that we could make the web user experience better, but instead of changing the layout, could we simply provide entry points to browse related things together? For instance we could offer a search page to find all OMAP related downloads. Or we could generate a page per board with all the latest files related to this board. As part of TestDrive, James Tunnicliffe wrote a tool to scan images on releases.linaro.org and generate a sqlite3 db. We could use this tool or this db, or a similar approach, as the source of information for everything related to beagleboard or latest images for all platforms. Integration with Launchpad could we done via launchpadlib; no need to copy the tarballs around, or change existing practices or hosting locations. Cheers, -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: proposal for reorganization of releases.linaro.org hierarchy
On Thu, May 26, 2011, Alexander Sack wrote: Lets move step by step and focus in this thread on the layout of releases.linaro.org. We can discuss the big download future picture outside of this thread ;). Linaro strives to be transparent and open, but design by committee or by vote suck, and discussing the layout of files on a server with the whole world doesn't make sense if we already agree we want to provide an UI to abstract it this layout away. I agree the current layout isn't the best; what I believe is a more sustainable layout where we wont have to maintain URL redirections over time would be: /$year-$month/$project/ with project being an ouput of a team; either a platform output, or a working output; project could be android, or powerdebug. -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Linaro@UDS: MM summit starts at *2pm* today
Hey This is a quick heads up that MM summit starts at *2pm* today (in 15mn) and not at 3pm. The schedule is incorrect because we can't overlap the plenaries, but discussion will start at 2pm. See you there! -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Would you like remotely accessible boards?
Hey This is not a specific use case, but more of a proposed design feature: Linaro might sometimes offer the possibility to run/build something on boards to untrusted third parties. For instance building a package, running a testsuite, or doing a test build of a proposed GCC branch or an Android image. It might be worth considering some security sandboxing for some of the boards for some of the use cases. Cheers, -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro-Media-Create
On Tue, May 03, 2011, Tony MANSSON wrote: We'd like to use the --mmc option to distinguish between these two cases: 3 partitions vs. 2 partitions. (This would be counter-intuitive as other pointed out) For now, until Hwpackv2 are implemented, you could propose a new flag indicating the image type, or abuse --dev to offer snowball-mmc and snowball-emmc --dev/BoardConfig implementations. -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: plymouth SEGV on Overo with 2.6.39
On Mon, May 02, 2011, AJ ONeal wrote:
I don't think that plymouth is a particularly necessary service (especially
since I don't have a display), so my temporary solution is to disable it
like so:
cd /etc/init
ls plymouth*.conf | while read CONF
do
mv ${CONF} ${CONF}.off
done
Can anyone offer me any suggestions?
Plymouth is used a message and user-interaction multiplexer so that new
devices and filesystems can appear during boot and be fscked, and the
user can be prompted -- asynchronously. It's not just the framebuffer
output used to display a splash.
I don't have suggestions for your SEGV; there are debug flags for
plymouth which you might be able to use; you could also spawn a
terminal at various stages of the boot and try running plymouth
yourself or under gdb
--
Loïc Minier
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: plymouth SEGV on Overo with 2.6.39
On Mon, May 02, 2011, AJ ONeal wrote: Warning... fsck.ext3 for device /dev/mmcblk0p2 exited with signal 11. fsck.ext3 segfaulting is pretty bad - Plymouth's availability reported/y affects `/` being mounted That might be normal (see other message) - yet there are no errors on the filesystem and it still mounts (though in read-only mode)fsck -y /dev/mmcblk0p2 Well even without errors, something causes fsck to segv when run from mountall apparently; maybe different flags? -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: STM at UDS-Budapest
Hi The attachment which was too big for the mailing-list is at: http://people.linaro.org/~lool/STMLinuxDriverWhitePaper_Rev0%202S.pdf Cheers -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Help on general file sharing
On Fri, Apr 29, 2011, Shawn Guo wrote: I have one 35MB tarball to share with Linaro folks. It's too big to distribute through email. Is there any infrastructural solution for such general file sharing purpose? (The launchpad PPA is for package than general file sharing, and I do not want to bother.) Thanks. You can request access to people.linaro.org which will expose your ~/public_html/ over http; file a RT ticket with your Launchpad account details (similar to git.linaro.org access). If it's for other Linaro folks to access, you could put it in your home on git.linaro.org and tell them to get it from there (using scp or whatever). -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Help on general file sharing
On Fri, Apr 29, 2011, Scott Bambrough wrote: Is there a particular reason that http://people.linaro.org doesn't show a list of accounts exposed via http? Might not be easily doable with Apache; people.linaro.org is defined in the config as a virtualhost with its own document root and could serve documents under this directory (http://people.linaro.org/foo); the only difference is that it has UserDir enabled so that ~lool resolves to my ~/public_html/. Maybe there's a way to have Apache list all http://people.linaro.org/~user urls though. -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Device Tree hwpacks
Hey If you try latest daily hwpacks + latest linaro-image-tools (0.4.4 or bzr) you should be getting Device Tree aware images for boards which support it (mostly i.MX51 and OMAP ATM). Feedback and bug reports welcome! Cheers, -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: IMPORTANT UPDATE: Details for Linaro Developer Summit in Budapest, 9-13 May
On Fri, Apr 01, 2011, Stephen Doel wrote: Contact matt.wadd...@linaro.org for more details matt.wad...@linaro.org -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: USB issues on OMAP3 (beagle/overo) with latest linaro-2.6.38 tree
Is there a bug tracking this? if not, would you mind opening one? I fear this affects OMAP4 with the -omap flavor as well. -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Add packaging of .dtb files
On Thu, Mar 31, 2011, Grant Likely wrote: As the .dtb files will be naturally generated in the same kernel folder as kernel image sits, why do not we ship .dtb in the same folder as kernel image /boot? Version numbers. If two kernel packages are installed, that means two sets of .dtb files. At the very least they would need to be in a subdirectory that encodes the 'uname -r' value. Version numbers aren't a problem in /boot though; we already deal with one vmlinuz-`uname -r` file per kernel in /boot (and abi-*, config-*, initrd.img-*, System.map-*, vmcoreinfo-*). -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] arm/dt: Add basic device tree support for genesi mx board
On Wed, Mar 30, 2011, Steev Klimaszewski wrote: We actually call the small desktop a Smarttop not nettop :) I thought the same, but this name is already used in mainline linux/arch/arm/mach-mx5/board-mx51_efikamx.c: MACHINE_START(MX51_EFIKAMX, Genesi EfikaMX nettop -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Status of the linaro-2.6.38 kernel
On Mon, Mar 28, 2011, Arnd Bergmann wrote: If you worry about the users of the Android tree more than the git history of it, there may be another option: Take the diff between the old and the new linaro-2.6.38 and apply that on the Android tree. After you have fixed up all conflicts you get from that, do a pull from the new tree and solve ignore all conflicts by reverting them in the merge. That way, you have a tree that your downstream can pull. It feels kind of hackish to do this in the downstream Android tree rather than in linux-linaro; the latter would also avoid the issue in other trees outside of Linaro if any. -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Starting a cookbook
On Mon, Mar 28, 2011, Michael Hope wrote: Hi there. I'd like to start an official Linaro cookbook that has recipes on how to build and use the various Linaro outputs. This cookbook would answer questions such as 'how do I build Linaro GCC from source?' and could be expanded into others. Is that a Linaro Toolchain cookbook? Othewise, it sounds much like the HowTo tab on wiki.linaro.org: https://wiki.linaro.org/Resources/HowTo https://wiki.linaro.org/CategoryHowTo In any I feel your efforts could definitely be part of the HowTos :-) -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Overo Clock Rate
Thanks for the excellent writeup! For u-boot, I find this a bit surprizing as I thought Overo was well supported in upstream u-boot; in any case, please do file a bug against u-boot-linaro on this. It's quite likely patches not yet upstream to u-boot which we might find in Steve Sakoman's tree(s). For linux, it could either be a missing patch or a config option or a kernel cmdline option, but I guess you tried the latter already; I don't know where to start searching for this, but it's certainly also worth a bug against linux-linaro. Cheers, -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: problem with linaro-media-create
On Thu, Mar 10, 2011, Shawn Guo wrote: === wait_device testing === * On reader #1, consistently fails with 30 seconds timeout * On reader #2, very likely succeeds after 2 seconds (5 out of 6 iterations), (fails with 30 seconds timeout on the 6th iteration) * On reader #3, consistently succeeds after 0 seconds This is really valuable information, thanks a lot for your testing Can you think of a way we could distinguish between these readers? I don't want us to start tracking USB reader vendor information, but maybe they expose some SDHC bit, or have SDHC in their description instead of MMC or...? Maybe the good readers perform at higher speeds and we could do a speed test and refuse to work with slow readers? So I would say the result not only depends on the cards but also readers. Absolutely -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Making linaro-nano smaller or Give Up Disk Space for Lent
On Wed, Mar 09, 2011, Tom Gall wrote: Specifically from the installed image after the hwpack deps are installed get rid of the following: rm -f ./var/lib/apt/lists/*Packages rm -f ./var/lib/apt/lists/*Sources rm -f ./var/lib/apt/lists/*Release rm -f ./var/lib/apt/lists/*Release.gpg rm -f ./var/cache/apt/pkgcache.bin rm -f ./var/cache/apt/srcpkgcache.bin I think there is a way for APT to keep compressed versions of these files; it's the Acquire::GzipIndexes option -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH V3 1/5] arm/dt: add basic mx51 device tree support
On Wed, Mar 09, 2011, Jason Hui wrote: + * Copyright 2011 Freescale Semiconductor, Inc. All Rights Reserved. Copyright 2011 Linaro Ltd. -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH V3 1/5] arm/dt: add basic mx51 device tree support
On Wed, Mar 09, 2011, Jason Hui wrote: I will resend the whole patchset and use Linaro copyright and sign off. Thanks for it. Awesome, thanks! (And sorry that I can't provide any technical feedback on the patches, but it is certainly nice to see imx51 + DT booting with enough devices in DT to bring up a NFS root!) -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: problem with linaro-media-create
On Wed, Mar 09, 2011, Shawn Guo wrote: I just tried another SanDisk 4GB SD card (#8) borrowed from colleague. With 20 iterations testing, it reports: Could list partitions after 0 seconds! -- 13 times Could list partitions after 2 seconds! -- 5 times Could list partitions after 4 seconds! -- once Could list partitions after 8 seconds! -- once Gah that's still pretty bad, but I guess we could wait up to 30 seconds and output some messages on the console. Guilherme, what do you think? -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: problem with linaro-media-create
On Tue, Mar 08, 2011, Shawn Guo wrote: mkimage: Write error on /tmp/tmpXkyS2N/boot-disc/uImage: Success Could it be that your MMC is flaky? -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Running linaro-media-create on machine behind firewall
On Tue, Mar 08, 2011, Shawn Guo wrote: Yes, it is. Do we have a quick fix right now? I need it ... As a workaround, try disabling your (host's) network entirely before running linaro-media-create; I could run it completely networkless, but I think your proxy is confusing APT. -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Running linaro-media-create on machine behind firewall
On Tue, Mar 08, 2011, Shawn Guo wrote: That's not an option for me. Myself is on ssh terminal. I do not have a nice monitor for that machine :) Ok; I could propose various network tricks such as changing the routing table to mark your APT repo unreachable, but I guess we really have to fix support for proxies and/or offline. -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: problem with linaro-media-create
On Tue, Mar 08, 2011, Shawn Guo wrote: I'm scanning all 7 cards I have with the script wait_device, each card with 10 iterations of the test. 1) Transend 4GB SD 2) SanDisk 2GB SD 3) KingMax MMC Mobile 2GB All above 3 cards passed the test with giving Could list partitions after 0 seconds! 4) SanDisk 4GB SD 5) SanDisk 4GB SD 6) SanDisk 4GB SD 7) SanDisk 4GB SD All above 4 cards failed with giving Giving up after 30 seconds failing to list partitions. The interesting thing is it does not always fail from the beginning. Some cards can even pass the test for 4~5 iterations, and then start failing. If it starts failing, it always fails until I remove the card and replug it. This is really valuable data; SanDisk 4 GB SDs seem to be a trend above! It would be interesting if you could borrow another USB reader for some hours to run the tests on the same SD cards, but a different adapter. -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: problem with linaro-media-create
On Wed, Mar 09, 2011, Shawn Guo wrote:
I just added this one, and it does not help. The l-m-c still fails at
the last step.
mkimage: Write error on /tmp/tmpUiR_m1/boot-disc/uImage: Success
This error sounded a bit weird; I checked the u-boot sources, and this
string is used in a bunch of places, but essentially it's either on
write() or on close() that this fails. I bet it's on write() as I
don't see close() failing without an useful errno, but I could imagine
the write tests failing:
if (write(ifd, tparams-hdr, tparams-header_size)
!= tparams-header_size) {
fprintf (stderr, %s: Write error on %s: %s\n,
params.cmdname, params.imagefile, strerror(errno));
notably if this is a partial write.
We could change mkimage's write()s to actually account for the number
of bytes written rather than just failing when not all bytes were
written.
Could you log a bug on the u-boot package on that one? Or rather,
could you check before hand where your mkimage comes from?
dpkg -S `which mkimage`
apt-cache policy name-of-the-package-returned-above
Thanks!
--
Loïc Minier
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: problem with linaro-media-create
On Wed, Mar 09, 2011, Shawn Guo wrote: $ apt-cache policy uboot-mkimage uboot-mkimage: Installed: 0.4build1 Candidate: 0.4build1 Version table: *** 0.4build1 0 500 http://us.archive.ubuntu.com/ubuntu/ maverick/main amd64 Packages 100 /var/lib/dpkg/status Ok; natty has a more recent version built from u-boot upstream in the u-boot-tools package (superseding uboot-mkimage which was a fork); mind trying that out? -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: problem with linaro-media-create
On Mon, Mar 07, 2011, Shawn Guo wrote: proc umounted /dev/sdb: No medium found sfdisk: cannot open /dev/sdb read-write Hmm that's really bad; the only thing that I can think of is that your device goes away for some time after the empty partition table is created, and so the sfdisk call comes too soon; could you try this on your MMC: parted -s /dev/sdN mklabel msdos sfdisk -L /dev/sdN if sfdisk fails when called immediately after parted, it probably means we have to poll for readyness of /dev/sdN before calling sfdisk. Thanks! -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: problem with linaro-media-create
On Mon, Mar 07, 2011, Zygmunt Krynicki wrote: This will most lokalu not help. Well, I'm trying to figure out one issue at a time; I would like to avoid sleep() at all costs. -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Thumb-2 kernel on imx51/efikamx
On Thu, Feb 24, 2011, Dave Martin wrote: Just tested the imx51 Thumb-2 kernel on efikamx here -- it boots fine, but we only went as far as the initramfs. Uh no, we booted all the way to a serial console on the real btrfs rootfs together! :) -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Emdebian sprint - flash-kernel discussion
On Wed, Feb 23, 2011, Andy Green wrote: Over the longer term I think it could be possible to arrange things that - hwpacks as they are - initrds, and - Qemu requirement for image composition, maybe whole l-m-c could in most or all cases be dispensed with. In that situation l-m-c itself would ideally disappear into composition-host-runnable scripts down /etc/board-specific.d or /usr/share/whatever.d for hosts that have a concept of external bootloader and / or kernel composition (ie, not shoving it in local NAND but SD card). So, at what used to be l-m-c time you run on the composition host the same scripts that the native device uses for bootloader and kernel install from the composed rootfs itself, with suitable abstraction of device names and so on. Any scripting config left from kernel package install could be batched and deferred until first boot where it runs natively. Hmm this is a bit too far-looking for me Another kinda-related simplification that would pay dividends is to enable taking advantage of multi-board kernels within the same arch that are possible, by having the same deal in terms of multi-board bootloaders within the same arch. Currently X-loader and U-Boot take a compile-time config approach that forces them to emit ultra-specific bootloader binaries. If that was fixed then it'd be possible to have, eg, a single Omap4 kernel package and a single Omap4 bootloader package that worked on all supported Omap4 boards and so on. So John Rigby had proposed a similar approach, but Steve Sakoman had suggested that it's really hard to identify the board you're running on safely. And you need the information of the exact board relatively early because you need to setup DDR, access the MMC and serial console etc. -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Emdebian sprint - flash-kernel discussion
On Wed, Feb 23, 2011, James Westby wrote: How would this interact with the proposal for storing some of this information in hwpacks? This came up; basically linaro-image-tools + hwpacks are one of the many copies of this information which we have around. It will take some time to share this stuff across debian-cd, debian-installer, flash-kernel, linaro-image-tools + hwpacks etc. Basically, we want all these tools to separate code and data, and we'd like data to be shared. Right now, linaro-image-tools has both code and data, and moving the board-specific data to hwpacks would be a win. Eventually we could generate the hardware pack from this common data, or we might change linaro-image-tools to read the common data from where it lives, but it seems further away. So there's a long-term/short-term tradeoff: hwpack v2 seems possible in a couple of weeks, common data package with the right semantics to expose ot the world -- might take longer. Does it imply that hwpacks aren't quite the right place for this? Should they instead just contain an indication of which boards are supported and information about the contents (such as the u-boot path), and the rest of the information lives outside of the hwpack? I'm not sure; for instance consider the case of data which changes with the distro over time; let's say linaro-image-tools depends on that data and combines the data + 1 hwpack + 1 rootfs to create an image. Then the data changes, and you want to support an older hwpack + rootfs, but the new data is not compatible with them (ttyS2/ttyO2 example). If the data is contained in the hwpack in some way, then it's not an issue anymore. I'm pretty sure there are examples the other way around though, and I don't like having caches of the data which might be stale. Also, some data should perhaps be shipped by packages like the kernel or by u-boot; for instance a device tree, or the information about the kernel features (for instance maybe ttyO2 is a kernel feature we can infer from the config). Hwpacks seem like a convenient vehicle for grouping these things together in a daily build which you can download and verify easily. -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Emdebian sprint - flash-kernel discussion
On Wed, Feb 23, 2011, James Westby wrote: So longer term we should be thinking of having the hwpack generation read some information from the common files corresponding to the versions it is building for (e.g. grab the package containing the common files and look for the one with a specific name and take some info from there). That would allow us to share the data, while not worrying about having different versions of that data at hwpack-install time. Yup I still think we should consider cases where the information refers to the rootfs when we come to do this, and not include that in the hwpack, instead reading it from the rootfs we are installing the hwpack in to. That's sensible; there is much less stuff relevant in the rootfs, but maybe pieces of kernel cmdline (cmdline would be built from rootfs part + hwpack part + linaro-image-tools computer part + user specified part). Did you have something specific in mind? -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Emdebian sprint - flash-kernel discussion
Hi there flash-kernel is this place where we add support for a lot of weird boards of various architectures. flash-kernel because it used to just write a kernel to Flash memory, but that's not always true anymore. Because it's integrated in d-i and with initramfs-tools / linux packages, it is the easiest way to add support for one new board. But flash-kernel isn't in the happiest state right now, as new boards were added by copy-pasting the installation logic of other boards over and over. Also, Ubuntu added more and more boards and features to its flash-kernel package, and the delta is really big now (I will take part of the blame for allowing this to happen). In the light of this situation, and because I think Debian and derivatives will support more and more boards via flash-kernel in the future (for instance modern ARM boards in the armel/armhf ports), I'm interested in improving flash-kernel's code, architecture and scalability (in fact, I started working on it [1]). I'm at the Emdebian sprint in Cambridge this week and I wanted to pursue work on flash-kernel this week, but a lot of people here would like to have a discussion on this work, and other people seem to be interested in solving the same problems in flash-kernel. So in the interest of avoiding work duplication and in the hope to come up with a good roadmap and target architecture for flash-kernel, I'll be hosting a discussion on flash-kernel development tomorrow morning at 11am UK time. (Sorry for the late notice!) If you're interested in flash-kernel, if you have ideas, patches, etc. consider dialing in! Of course, email works too. I'll work on a wiki page summarizing tomorrow's discussion and the plans around flash-kernel. Dial-in details: Access code:52386 86884# UK Local+44 207 630 2405 UK Freephone0800 026 0166 US Local+1 781 761 9450 US Toll Free1 866 352 2709 Brazil 0800 881 0038 Canada 1 866 352 2710 Finland 800 523 103 France 0 805 980 044 Germany 800 589 0993 New Zealand 800 452 290 Taiwan 0800 265 855 China (North) 10 800 152 1873 China (South) 10 800 852 1873 India 000 800 100 7944 Poland 800 331 1398 Anybody is welcome to dial-in. I'd welcome if you would notify me of your presence so that we can expect you on the call. We'll be using #emdebian as back-channel. Cheers, [1] branch at http://git.debian.org/?p=users/lool/d-i/flash-kernel.git * adds a testsuite * consolidates code into functions * moves board support data into a database (currently inline for convenience of testing, but will be split out in its own file) -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: cc'ing patc...@linaro.org
On Tue, Feb 22, 2011, Dave Martin wrote: Do we need a policy on whether or not to use Bcc here? One argument for using Bcc is that it avoids replies from subscribers to the destination mailing lists from also being CC'd to patc...@linaro.org. Can your analysis cope with patc...@linaro.org receiving a whole thread, or do we need to be careful about this? The tool will likely have to cope no matter what, but I would think it's best to use Bcc: just to keep most issues away. -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: cc'ing patc...@linaro.org
On Tue, Feb 22, 2011, john stultz wrote: Yea. Since I still send out patches from both my employer and linaro address, I can't utilize fixed git config values. I already put the effort in to make sure my linaro work has my linaro.org address as the author on a patch by patch basis. And similarly I can add a CC: line to the patch commit log to make sure patc...@linaro.org gets the mail. But BCC isn't easy to do on a patch-by-patch basis. That's fair enough; could you explain how you're doing this patch by patch? I personally set author via the EMAIL env var and I have aliases like: linaro='EMAIL=loic.min...@linaro.org' debian='EMAIL=l...@debian.org' etc. and then I run: linaro git commit -av I wonder how you set Cc: though -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Emdebian sprint - flash-kernel discussion
On Wed, Feb 23, 2011, Michael Hudson-Doyle wrote: I ask mostly from a position of ignorance, but is the information in this database related to the information linaro-media-create keeps about each board? If so, could it be shared somehow? It's completely related and I envisioned we could share it some time ago: http://www.mail-archive.com/linaro-dev@lists.linaro.org/msg00254.html even before linaro-image-tools existed ;-) But thanks for bringing this up, it's a good thing to put on the goals for the rework: that the data be usage-agnostic and self-contained as to allow reuse in other places. -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: cc'ing patc...@linaro.org
On Tue, Feb 22, 2011, john stultz wrote: Add to the commit log: CC: Loïc Minier loic.min...@linaro.org CC: patc...@linaro.org And git-send-email will add those entries to the outgoing mail. Ah, so it's in the commit forever; I thought you were adding that at send-email time; ok, thanks! -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Availability of kernel .config, Module.symvers and vmlinux in a package ?
On Tue, Feb 08, 2011, Steve Langasek wrote: ddeb debug packages for the current natty kernel are meant to be made available here: http://ddebs.ubuntu.com/pool/universe/l/linux-linaro-omap/ Currently this directory is empty, but I'm not sure why. Loïc, do you have any details on what's going wrong currently with dbgsyms packages for the Linaro kernels? It should just work; last time this happened, lamont fixed it by starting apache on the armel buildds; pitti also added some error file: http://ddebs.ubuntu.com/failed-buildds.txt it shows a bunch of buildds, so I think that's likely the issue again. I'll open a ticket to ask for these buildds to get a httpd again -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Availability of kernel .config, Module.symvers and vmlinux in a package ?
On Wed, Feb 09, 2011, Peter Maydell wrote: Last time I needed them, on 1st Feb, the ddebs were in http://ddebs.ubuntu.com/pool/main/l/linux-linaro-omap/ (no, I don't know why 'main' when the .deb is in universe) but there's nothing in there any more either. That was the ddeb for linux-linaro-omap_2.6.37-1002.5, which is still in the archive. So the ddeb definitely got created and uploaded to ddebs, but something else has subsequently removed it :-( Yeah; I was wondering the same, I think the source package got demoted from main to universe which might explain why the ddebs got removed -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Efikamx bootloader help
hey
adding my bits where I can
On Tue, Feb 08, 2011, Eric Miao wrote:
2. The three possible boot up methods: a) Internal SPI NOR flash, b) the
MicroSD card behind the battery and c) the normal SD card at the left
side, not really sure about the situation on Efika MX (smart top) as
I don't have one in my hands
efikamx only has SD and internal flash; there might be other boot
methods like serial or USB, but I don't think we need to care too much
about these
4. The boot sequence of the Internal SPI NOR flash, as it looks to me that
it's trying to find boot.scr from either the MicroSD or SD card on the
first partition? Also it would be helpful to document the envionment
variables of this specific u-boot.
on my efikamx, this is the bootcmd it had when I received it and
corresponding variables:
bootcmd=run pata_boot
pata_boot=run bootargs_base bootargs_pata
bootargs_base=setenv bootargs noinitrd console=ttymxc0,115200 console=tty1
bootargs_pata=setenv bootargs ${bootargs} root=/dev/sda2 ${bootinfo};run
boot_pata
bootinfo=rw
boot_pata=run base_cmds;ide reset;fatload ide 0:1 ${loadaddr} ${kernel}; bootm
${loadaddr}
base_cmds=run base_cmd1;run base_cmd2;run base_cmd3;run base_cmd4;run
base_cmd5;run base_cmd99
loadaddr=0x90007FC0
kernel=uImage
base_cmd1=pmic 15 0x00400022;mw.l 0x73fa84b8 0xe7 1;mw.l 0x73fd4014 0x59239100 1
base_cmd2=mw.l 0x83fd9010 0xcaaaf6d0 1;mw.l 0x73f88000 0x01025200 1;mw.l
0x73f84000 0x20 1
base_cmd3=mw.l 0x83fd9004 0x333574aa 1;mw.l 0x83fd900c 0x333574aa 1;
base_cmd4=mw.l 0x83fd9020 0x00f48b00 1;mw.l 0x83fd9024 0x00f49700 1;mw.l
0x83fd9028 0x00f48700 1
base_cmd5=mw.l 0x83fd902c 0x00f48400 1;mw.l 0x83fd9030 0x00f44e00 1;
5. If Linaro is going to support u-boot for Efika MX/SB, it's better to
follow what is in upstream. However, there could be some differences
between the u-boot in the recovery/installing image downloadable from
powerdeveloper.org and the one in upstream. We might need to figure
out those differences and see how to handle them.
That was indeed the case; Marex, who developed the upstream u-boot
bits, told me the same u-boot would work on SD and on flash; the one
I've built from mainline uses the default imximage.cfg settings which
is BOOT_FROM spi, yet works fine from a SD card. So it seems the
same u-boot can be used for both SD and flash -- just with different
bootcmd.
Cheers,
--
Loïc Minier
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: v4l2 vs omx for camera
On Tue, Feb 08, 2011, Arnd Bergmann wrote: while gst-openmax is currently not even packaged for ubuntu. I think this is because gst-openmax needs to be built against BSP-specific omx headers, and this means we need some of these headers in Ubuntu and we need to build gst-openmax one time per concrete implementation. -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 1/3] xloader-panda-add-0map4-gpio-base.patch
On Tue, Feb 08, 2011, Andy Green wrote: Actually FWIW I was talking to my friend Matt Hsu at 0xlabs yesterday, he did an Omap 3 port of Qi bootloader and told he is working on a Pandaboard / OMAP 4 port this week. cool! To the extent that the bootloader is just there to load and boot Linux the current system of xloader and U-Boot is wasteful in several domains at once but most especially boot time when combined with a big initrd like it is at the moment. This is certainly an interesting perspective for production images; for Linaro, I think we're exclusively using u-boot for now, which allows for some simplifications and gives developers a rather featureful bootloader which is suitable for the development stage (and granted, might not always be small or fast enough for production). Consider for instance DeviceTree support: it's available in u-boot, and I'd be surprized if it was also available in Qi. Maybe a lightweight BSD-licensed bootloader will be on our agenda in future cycles, but it's not a priority right now That said, if it's available and working, we could offer if as an alternative for interested people (I would guess on a best effort basis, non-official etc.) Do you have pointers to the source and usage instructions? :-) maybe a Linaro wiki page might make sense -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 1/3] xloader-panda-add-0map4-gpio-base.patch
On Tue, Feb 08, 2011, Andy Green wrote: http://git.warmcat.com/cgi-bin/cgit/qi/ Currently the lpc branch is most up to date but Matt also proposed merging all the support back into our master when he has done Panda, so I will wait to move it on until that is done. omap3430/3530 seem to be the only supported ARMv7 CPUs in an omap3530 branch, and it seems the only supported board is beagle. It didn't build for me since my cross toolchain has FORTIFY_SOURCE and defaults to Thumb and because I'm using a French locale, I've sent a patch series to Matt Hsu since he seems to be the one committing to this branch. Overall, many things seem hardcoded like the cmdline args which include the rootfstype. In past discussions around detecting the board with John Rigby and Steve Sakoman, it wasn't entirely clear how one would actually detect the board one is running on, so I'm not sure how Qi would deal with this. In terms of licensing, many files lack a header, and there is no top-level COPYING, but it seems to be mostly GPL v2. The result (image/qi-omap3530-beagle-fixes_14ef8c447f592dcd.bin) wasn't recognized by QEMU whem I copied it as MLO on an otherwise working image; I guess I'm missing some required step, but I didn't find any new tool or target while reviewing the diff from the master branch to the omap3530 one. -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: problem with linaro-media-create
On Tue, Feb 08, 2011, Michael Hope wrote: (I don't like that - am I prompted first? A script shouldn't be allowed to install packages on my machine) I don't like it either; that's already reported: https://bugs.launchpad.net/linaro-image-tools/+bug/704029 -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: problem with linaro-media-create
On Mon, Feb 07, 2011, Peter Maydell wrote: You need a newer qemu (specifically a /usr/bin/qemu-system-arm (/usr/bin/qemu-arm-static) -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: problem with linaro-media-create
On Mon, Feb 07, 2011, Alexander Sack wrote: Since we only really support developer platform hosts with the tools ppa enabled, could we improve l-m-c to print a warning if that ppa isn't enabled? This sounds awfully Ubuntu specific; we released a standalone tarball as to allow people to grab the tools on other distros as well The other idea I had was to include the working qemu-arm-static in the tarball releases ... in that way things might even work on non-ubuntu platform. bundled binaries are so wrong; then we need to provide source, allow people to override them, this is really a path I don't want us to go to, and something I would complain about if an upstream was doing that... Linaro is distributing a qemu version which is fixed; we should just point people at it. Concerning testing the version, this is something we could easily do, but I don't really like it: for instance if we fix this issue in a qemu patch to an older version, the version check will decide that qemu is broken when it is not. The only correct thing to do would be to try to run a piece of code for which we know emulation is broken, and then report the result of this test to the end-user (e.g. we could point at a wiki page with a FAQ entry on the qemu fix). Implementing a version check is much easier though. I don't really want us to be in the business of meta-distributing fixes , or defensively testing for everything in the environment -- we have better things to work on. How about we call this a common issue and we add it on the wiki page where the installation instructions live, and we bundle a FAQ with linaro-image-tools? -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Build assembler errors on Beagleboard ALIP
On Mon, Feb 07, 2011, Kurt Taylor wrote:
I am seeing the following when trying to build pulseaudio on a Beagleboard
running a current ALIP daily:
...
CC libpulsecore_1.0_la-svolume_
arm.lo
{standard input}: Assembler messages:
{standard input}:82: Error: thumb conditional instruction should be in IT
block -- `addcs r0,r8'
{standard input}:83: Error: thumb conditional instruction should be in IT
block -- `movcs r6,r0'
{standard input}:98: Error: thumb conditional instruction should be in IT
block -- `addcs r0,r8'
{standard input}:99: Error: thumb conditional instruction should be in IT
block -- `movcs r6,r0'
{standard input}:119: Error: thumb conditional instruction should be in IT
block -- `addcs r0,r8'
{standard input}:120: Error: thumb conditional instruction should be in IT
block -- `movcs r6,r0'
...
I am using the normal pulseaudio build (bootstrap.sh, configure, make). The
build worked fine on a Pandaboard with Ubuntu 10.10. It looks like something
is not being detected correctly via bootstrap/configure on ALIP.
I have searched and seen commits in archive for adding -Wa,
-mimplicit-it=thumb. I have added this to CFLAGS without success.
The package does a regular configure and then:
make -C src libpulsecore_0.9.22_la-svolume_arm.lo
CFLAGS+=-Wa,-mimplicit-it=thumb
on ARM.
This is really ugly though; I guess the asm snippets in
src/pulsecore/svolume_arm.c should be ported, this is explained in:
https://wiki.ubuntu.com/ARM/Thumb2PortingHowto#Types of Assembly Language
Bye
--
Loïc Minier
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Panda Board power supplies
On Wed, Feb 02, 2011, Joey Stanford wrote: This is the part: http://search.digikey.com/scripts/DkSearch/dksus.dll?Pname?Name=T1075-P5P-ND Was http://search.digikey.com/scripts/DkSearch/dksus.dll?Pname?Name=T377-P5P-ND the original part? if yes, note that the new one doesn't seem to come with international plugs, only US. Would be nice to find an international one; it seems to be a standard cable though -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Efikamx bootloader help
On Wed, Feb 02, 2011, Per Förlin wrote: I made a new attempt bringing up my imx today, this time I reconnected the keyboard and then I could recover u-boot without any trouble. I disconnected the keyboard when changing the DIP switches. Per, upstream u-boot got support in git for efikamx some hours ago; I managed to boot it this very morning! make efikamx_config and make, then write u-boot.imx to SD at offset 0x400; boot with 4 DIP switches to off. I think we will have this in .debs soon; mainline kernel lack some important stuff still though Cheers -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: tcl8.5 breaks dpkg-cross assumptions and multiarch
On Tue, Feb 01, 2011, Wookey wrote: But if something is looking for arch-independent stuff in /lib then in general that's wrong, and I'm not aware of any examples of correctly-packaged packages that need this. Any arch-independent files will be supplied by an arch all package that the build should depend on if needed. I might be getting your point wrong, but I certainly see a lot of files in /lib itself which are arch-independent data used for early boot (before /usr is available); PNG files and text files which would be identical on all architectures. -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Booting linux-linaro-2.6.37 on Beagle Board
On Mon, Jan 31, 2011, Alexander Sack wrote: 3. make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- omap2plus_defconfig this one feels odd as beagle is omap3 That's actually correct; omap2plus is meant to support OMAP2, OMAP3 and OMAP4 in the same binary kernel (OMAP2+) -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: tcl8.5 breaks dpkg-cross assumptions and multiarch
For this specific tcl issue, there was some discussion in Debian #599206; I didn't comment back on the bug, but I liked Goswin's proposal -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro Image Tools 0.4.2 released
On Sat, Jan 29, 2011, Loïc Minier wrote: Backports to Ubuntu 10.04 and Ubuntu 10.10 will be provided shortly. A backport to Ubuntu 10.04 willl take longer to prepare, but a backport to Ubuntu 10.10 is now available in ppa:linaro-maintainers/tools. -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: New dial-in number for conference calls
On Tue, Jan 25, 2011, Lee Jones wrote: Any sign of a Swedish number? Nope; Alexander's document has the full list I've opened a ticket with IS to ask for a number for Sweden -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Talk: Embedded GPUs at LCA
On Tue, Jan 25, 2011, Christian Robottom Reis wrote: I did a talk at LCA yesterday evening that covered Embedded GPUs and Open Source (or the lack thereof) Any interesting question or feedback? -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: New dial-in number for conference calls
On Mon, Jan 24, 2011, Loïc Minier wrote: (Sorry for the late notice, we were caught by surprize by the speed of this move) The conference system for phone calls moved to new dial-in numbers this week Correction: the old system apparently still works, but please consider moving your calls to the new system ASAP! Thanks! -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: New dial-in number for conference calls
On Mon, Jan 24, 2011, Marcin Juszkiewicz wrote: I hope that list will be expanded this week - there is no number for Poland and each operators which I use will rather charge me for international calls. Poland: 800 331 1398 -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro PPAs and backports / release cycles
On Thu, Jan 20, 2011, Steve Langasek wrote: - the overlay ppa is the only one that should be enabled for Linaro release images [...] I like the clear limits you're setting to the overlay PPA (rejecting any other concurrent overlays) As for the 'tools' ppa, I had envisioned this as the single ppa that developers should enable on their desktop systems to get tools they need to work with, and develop for, current Linaro development images, particularly when those desktops are running older versions of Ubuntu That's relatively close to the reason we created it for during the 10.05 cycle: we basically had to allow people to create/use Linaro images from a lucid install, and not everything was in lucid. So I'm also happy with this, keeping in mind that it's on a best effort basis, in particular: I don't intend us to guarantee that the packages won't cause regressions vs. those versions shipped in that Ubuntu release - indeed, we know for certain that the new linaro-image-tools won't work with images released with 10.11 - but they will be the best tools we can give you for working with Linaro images while minimizing regressions where possible. and that's in part what triggered this thread, because I wanted to eventually provide lucid/maverick folks with updated l-i-t, but I was suddenly challenged to QA these extensively. There should only be a decently lightweight QA for the tools PPA. The 'kernel' ppa is something of a mixed bag. There are a variety of test kernels, bsp kernels and pre-release kernels available there, including those we used for our bsp hwpacks in 10.11. It lacks a clear policy, and I'm pretty sure we don't want Landing Teams to be bottlenecked on this single PPA for their ability to build kernel packages (and hwpacks). But I wouldn't do away with this altogether; it's clear to me that John has been getting good use out of it. To me it sounds like this should be a ~linaro-kernel-wg/release PPA, with eventually some /beta or /daily PPA; or perhaps his own ~jcrigby PPA Provided that the PPA uploads use proper version numbers (i.e., don't shadow any version number that would be used in the Ubuntu or Debian archives), I think this is reasonable. We can't generally guarantee any particular time frame for inclusion in natty after the WG component is released, so I think it's simpler to have a policy of always PPA upload. Ok; this is how I felt as well, simply because of freezes Thanks! -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: btrfs-tools for arm
On Fri, Jan 21, 2011, Per Förlin wrote: I am using the linaro-m-headless-rootfs and tools for btrfs are missing. I want to put btrfs on the onboard MMC and therefore I would like to run btrfs-tools on target. Does any one have arm version of the btrfs-tools? apt-get install btrfs-tools? It seems they built for armel: https://launchpad.net/ubuntu/+source/btrfs-tools/0.19+20100601-3ubuntu1/+buildjob/2171776 -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro PPAs and backports / release cycles
On Fri, Jan 21, 2011, Ramana Radhakrishnan wrote: I'm curious to hear what packaging methods would be used for things like the toolchain which have consumers beyond ubuntu. Are we saying this will only be Ubuntu packages or is there consensus around providing static tarballs ? For outputs of WGs like gcc-linaro, gdb-linaro, qemu-linaro, linux-linaro, u-boot-linaro, ... we expect the official release to be a source tarball which can be consumed/integrated anywhere, not limited to Ubuntu. But as our primary developer platform is Ubuntu, we also package these outputs in the current Ubuntu release and we should also provide PPA versions for: * people running older / stable versions of Ubuntu * times when the Ubuntu development repo is frozen (e.g. before an Ubuntu release) I ask this because I've seen a number of requests about getting hold of a binary Linaro toolchain release and not everyone uses Ubuntu as their host distribution. You mean a CS-style .tar.gz with a standalone toolchain? This came up frequenly; it's a question of whether we want to spend the extra effort of supporting this output, and whether we'll be able to manage / we'll be interested in the support of the users of such a release. I'm sure Michael Hope can expand on this, but I think the main argument is that we are interested in supporting packagers integrating our toolchain in their distros, but less interested in direct support of hundreds of people consuming the toolchain directly -- we'd rather crowdsource this to distros. -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: linaro-image-tools 0.4(.1)
On Thu, Jan 20, 2011, Alexander Sack wrote: What's the plan for staging/QA before pushing this backport into the tools ppa? Good question; do we have a process for this? I realize we don't have a -proposed/-updates etc. setup for stuff which we only provide in PPAs. -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Linaro PPAs and backports / release cycles
Hey As a followup to IRC conversations around backports, releases and QA today, I'd like to hear what others think of our Linaro PPAs. I'll start with some history and proposals: We created a fairly ad hoc PPA layout for the 10.11 cycle, with ppa:linaro-maintainers/tools ppa:linaro-maintainers/override ppa:linaro-maintainers/kernel and nowadays we also have this PPA for toolchain backports: ppa:linaro-maintainers/toolchain and misc other PPAs which I don't really know much about: ppa:linaro-maintainers/user-platforms ppa:linaro-toolchain-dev/ppa ppa:linaro-infrastructure/launch-control ppa:linaro-infrastructure/launch-control-snapshots (and probably many more) There are multiple problems with our current approach: * ~linaro-maintainers membership is poorly defined * it's not clear which software should go in which PPA * it's not clear when we can update which PPAs, e.g. can we update them after 6-monthly releases? how do we QA/validate updates? In general, it's good to avoid PPA proliferation, both for sanity and for the confort of our end users, but I think a consistent set of PPAs is more important than trying to optimize the number of PPAs to the smallest subset possible. Some ideas on addressing this: * have software ownership split by team; ~toolchain owns gcc-linaro and qemu-linaro, ~infrastructure owns * have each team decide between either: - a single PPA for all their outputs (e.g. ~infrastructure/ppa for linaro-image-tools and gcc-log-analyzer) - or multiple PPAs, one per software (e.g. ~toolchain/gcc-linaro PPA for gcc-linaro, ~toolchain/qemu-linaro PPA for qemu-linaro) * optionally, additional PPAs for dailies * optionally, additional PPAs for RC releases [ this is inspired from the set of PPAs for bzr: http://wiki.bazaar.canonical.com/DistroDownloads#Ubuntu%20and%20derivatives ] In addition, we'd have a single overlay PPA which would be used for rootfs builds. We could keep the existing one below ~linaro-maintainers. Open questions: - list of ~linaro-teams - do we upload latest release of e.g. gcc-linaro to the natty toolchain PPA if it already gets uploaded to natty proper? Thanks, -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Hardware Packs v2
On Wed, Jan 19, 2011, Amit Kucheria wrote: Am I correct in my understanding then, that this will address some of the issues I raised in https://wiki.linaro.org/Platform/Infrastructure/Specs/TestDrive ? Basically l-m-c won't have to be touched everytime we add new board support? Yes, I think one can say this. Unless the new board needs something completely different than the older ones, e.g. a specific partition layout or a new media type etc. At the risk of sounding like a broken record, I still believe that another tool on top of l-m-c that takes care of the selection and download of correct image hwpack and the combines writes the image to SD is what we should strive for to increase the attractiveness of linaro images. I agree, and I would also hope we gain a GUI someday, but I don't think it relates to changing the hwpack format? -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
gdb-multiarch
Hey Based on an idea by Ulrich Weigand, I've uploaded a new gdb to natty today which adds a gdb-multiarch binary package. It's about 19 MB and once you install it, you will get a new /usr/bin/gdb-multiarch which can debug any target that gdb knows about, including ARM! So you could debug an ARM /bin/ls from a local chroot with qemu-arm-static by running gdb-multiarch and then running: (gdb) file /arm-chroot/bin/ls /arm-chroot/bin/ls: not in executable format: File format is ambiguous. Matching formats: elf32-littlearm elf32-littlearm-symbian elf32-littlearm-vxworks. Use set gnutarget format-name to specify the format. (gdb) set gnutarget elf32-littlearm (gdb) file /arm-chroot/bin/ls In the chroot, run: qemu-arm-static -g 1234 /bin/ls and in gdb-multiarch: target remote localhost:1234 and you can now use gdb as usual, setting breakpoints, single-stepping etc. (It obviously also works with remote debugging of a real, network-connected ARM board; use gdbserver instead of qemu) Would people be interested in backports? Cheers, PS: the package is in NEW and will show up soon in natty; in the mean time, you can get it from my natty PPA: https://launchpad.net/~lool/+archive/ppa/+sourcepub/1446500/+listing-archive-extra -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Hardware Packs v2
On Wed, Jan 19, 2011, Guilherme Salgado wrote: This looks good to me. The only thing I can think of right now is to also add the board name to the hwpack meta-data and consider dropping the --dev option (making it optional, in fact, so that it keeps working with hwpacks in the current format) which should no longer be needed once all the board-specific options are in the hwpack. What would we do with the board name? -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
