linaro-dev

linaro-dev@lists.linaro.org

4332 discussions

Notes & Actions: Linaro graphics/multimedia - Aug 23, 2010

by Alexander Sack

Hi, notes and actions from our Monday graphics and multimedia cross-vendor call are available on the wiki: + https://wiki.linaro.org/Platform/UserPlatforms/2010-08-23 Details about when and where of this meeting can be found here: + https://wiki.linaro.org/WorkingGroups/Middleware/Graphics#Weekly%20Public%2… Thanks, -- - Alexander

14 years, 10 months

Efika kernel

by Tom Gall

Hi All, Is there a Linaro kernel available for the Efika MX? Thanks! Tom "We want great men who, when fortune frowns will not be discouraged." - Colonel Henry Knox w) tom.gall att linaro.org w) tom_gall att vnet.ibm.com h) tom_gall att mac.com

14 years, 10 months

Common data for uImage generation

by Loïc Minier

Hey There are a bunch of places where we generate uImages and which duplicate information. a kernel build most commonly outputs a zImage; this is then converted to an uImage for u-boot consumption with some rune like: mkimage -A arm -O linux -T kernel -C none \ -a 0x80008000 -e 0x80008000 -n Linux \ -d vmlinuz-2.6.35-1001-omap \ uImage-linaro Linaro's platform wants to output media for various boards, probably as a single rootfs + separate boot bits for each SoC, but probably as multiple [ rootfs + boot bits ] for now. I'd also like to setup daily kernel builds where people can directly grab uImages for testing. Linaro's platform provides .debs with zImage which get converted to an updated uImage at upgrade time (and get flashed when that makes sense). So there are already three places where this data is relevant: a) daily kernel builds b) live-helper image builds c) flash-kernel helper for kernel upgrade Finally, there are two other places in the .deb ecosystem where this data is also copied: in debian-installer (both in Debian and Ubuntu), and in debian-cd (mostly in Ubuntu, but applies to Debian). d) debian-installer is a package in charge of collecting the bootloader and kernel pieces and generating installation media such as netboot files which contain the installer e) debian-cd is standalone software to create installation media such as ISOs or SD card images These two pieces are not used by Linaro right now, but it makes sense to try to come up with a solution which is usable by these pieces too. So there is way too much duplication of this data; there are some duplications we could possibly avoid, for instance we could try calling flash-kernel's logic from live-helper, but it's not really a good approach for the debian-installer build, debian-cd, or the daily kernel builds. flash-kernel currently relies on being run on the target because it pokes /proc/cpuinfo, /proc/mtd and /dev/mtdblock*, or in Ubuntu the boot SD card; it's a "host install", not an installation towards a target. We want a solution which is usable from a x86 build host to create an ARM image (daily kernel builds, debian-cd). I see two ways to approach this problem: - data driven: we have data files for each board which document the addresses to pass to mkimage; all interested software parses the data and uses it to generate images - scripts: we have scripts for each board to do any board specific stuff; all interested software calls into the scripts to generate images I think what would likely work is a combination of the two. We should have generic "task" scripts ("I want to generate a bootloader kernel image from a zImage"), and board-specific scripts for board-specific logic -- I think we don't really need board-specific scripts for Linaro because we try to unify all platforms to the same boot interface, but in practice it will be needed for other architectures and we can only get wide acceptance of such a replacement if we support more than just u-boot. This should all be backed by plain simple data files as much as possible so that extending support to one more board can often be done by dropping a data file in a directory. So what kind of operations do we want to be able to do? * generate an u-boot kernel image from a zImage - input: zImage, kernel load address - output: uImage * generate an u-boot initrd image from an initrd.gz - input: initrd.gz, initrd load address - output: uInitrd * generate a mostly boilerplate u-boot boot script with specific cmdline opts - input: cmdline opts, script load address - output: boot.cmd I wonder whether we want to wrap other operations such as: * writing the kernel/initrd/script to flash or to a specific partition according to config * creation of boot media (partition table, vfat etc.) * other bootloaders Comments welcome! Other use cases, existing software, whatever! :-) Cheers -- Loïc Minier

14 years, 10 months

linux-linaro pull request

by John Rigby

Tim, The following changes since commit 951315de2583af8b51bf73ea284fdb8999f4f51c: Tim Gardner (1): UBUNTU: Linaro-2.6.35-1002.6 are available in the git repository at: git://git.linaro.org/ubuntu/linux-linaro.git linaro John Rigby (5): LINARO: [Config] Fix vexpress config LINARO: [Config] Add mx51 flavour LINARO: Start new release LINARO: [config] Update vexpress config LINARO: Linaro-2.6.35-1003.7 debian.linaro/abi/2.6.35-1001.5/armel/ignore | 1 - .../abi/2.6.35-1001.5/armel/ignore.modules | 1 - debian.linaro/abi/2.6.35-1001.5/armel/vexpress | 7196 -------------------- .../abi/2.6.35-1001.5/armel/vexpress.modules | 1167 ---- .../abi/{2.6.35-1001.5 => 2.6.35-1002.6}/abiname | 0 debian.linaro/abi/2.6.35-1002.6/armel/linaro-mx51 | 4844 +++++++++++++ .../abi/2.6.35-1002.6/armel/linaro-mx51.modules | 255 + .../armel/omap => 2.6.35-1002.6/armel/linaro-omap} | 0 .../armel/linaro-omap.modules} | 260 +- .../abi/2.6.35-1002.6/armel/linaro-vexpress | 5156 ++++++++++++++ .../2.6.35-1002.6/armel/linaro-vexpress.modules | 213 + debian.linaro/changelog | 12 + .../config/armel/config.flavour.linaro-mx51 | 540 ++ .../config/armel/config.flavour.linaro-omap | 498 ++- .../config/armel/config.flavour.linaro-vexpress | 495 ++- debian.linaro/config/config.common.ubuntu | 542 +-- debian.linaro/control.d/vars.linaro-mx51 | 8 + debian.linaro/d-i/kernel-versions.in | 1 + debian.linaro/etc/getabis | 2 +- debian.linaro/rules.d/armel.mk | 2 +- 20 files changed, 12176 insertions(+), 9017 deletions(-) delete mode 100644 debian.linaro/abi/2.6.35-1001.5/armel/ignore delete mode 100644 debian.linaro/abi/2.6.35-1001.5/armel/ignore.modules delete mode 100644 debian.linaro/abi/2.6.35-1001.5/armel/vexpress delete mode 100644 debian.linaro/abi/2.6.35-1001.5/armel/vexpress.modules rename debian.linaro/abi/{2.6.35-1001.5 => 2.6.35-1002.6}/abiname (100%) create mode 100644 debian.linaro/abi/2.6.35-1002.6/armel/linaro-mx51 create mode 100644 debian.linaro/abi/2.6.35-1002.6/armel/linaro-mx51.modules rename debian.linaro/abi/{2.6.35-1001.5/armel/omap => 2.6.35-1002.6/armel/linaro-omap} (100%) rename debian.linaro/abi/{2.6.35-1001.5/armel/omap.modules => 2.6.35-1002.6/armel/linaro-omap.modules} (100%) create mode 100644 debian.linaro/abi/2.6.35-1002.6/armel/linaro-vexpress create mode 100644 debian.linaro/abi/2.6.35-1002.6/armel/linaro-vexpress.modules create mode 100644 debian.linaro/config/armel/config.flavour.linaro-mx51 create mode 100644 debian.linaro/control.d/vars.linaro-mx51

14 years, 10 months

[PM] 18/08/10 - Minutes for the Power Management WG weekly call

by Amit Kucheria

The minutes of the weekly call can be found at: https://wiki.linaro.org/WorkingGroups/PowerManagement/Meetings/2010-08-18 Attendees: Linaro: Amit Kucheria, Amit Arora, Yong Shen ARM: Robin Randhawa == Agenda == * Review action items from last meeting * Blueprint status * HW governers * Powerdebug - Amit A and Yong to co-operate on the list of info we've noted in the Master Task List against powerdebug * hwmon not much used * camera goes to v4l * battery goes to supply class * omap4 - temperature sensor exported to hwmon * power supply class support to be added == Action Items from this Meeting == * ACTION: Amit A to test on pm enabled OMAP3 board * ACTION: Amit A to document details on power supply class (battery info) to PowerTOP internal wiki page * ACTION: Yong to look into getting powertop kernel patches applied to Linaro kernel tree * ACTION: Robin to send links to patches sent to linux-pm * ACTION: Amit K to spend some time on usecase to reproduce ondemand governor problems * ACTION: Yong to look at common clock FW, find out if debug info being exported (usage count, clk rate, dependencies) == Action Items from Previous Meeting == * ACTIVE (Immediate): * ACTION: Robin and Srinivas to target the ftrace patches for upstream.: * Srinivas to clarify what tree/branch is being used for this work: DONE * ARM to sit on patches, perhaps get TI to carry them. * ACTION: Amit A to get review and then post powertop patches to powertop list upstream: DONE * New ACTION: Amit A to test on pm enabled OMAP3 board * ACTION: Amit A to look at power supply framework * New ACTION: Amit A to document details on power supply class (battery info) to PowerTOP internal wiki page * ACTION: Amit K to look at getting powertop kernel patches applied to Linaro kernel tree: Carry forward * New ACTION: Yong to look into this * ACTION: Vishwa to send instrumentation patches to linaro-dev: DONE * ACTION: Vishwa to send usecase to reproduce ondemand governor problems: Tranferred to Amit K * New ACTION: Robin to send link to some interesting patches from linux-pm * ACTION: Amit K to spend some time on usecase to reproduce ondemand governor problems: Carry forward * ACTIVE (Long Term) : * ACTION: Srinivas to provide details of where he believes userspace - kernel interaction is required. (low prio) * ACTION: Bobby to check on multi-core boards availability (request open) * ACTION: ARM to discuss giving out internal Eclipse based tool (similar to powertop) (no ETA as of now) * ACTION: Amit Kucheria and Vishwa to get inputs from community on the issues related to CPUIDLE governor: POSTPONED until instrumentation work * DORMANT : * ACTION: ARM to share internal instrumentation flow (BAB: we might also align with Linaro on workload discussions) * Might take couple of months * ACTION: Amit K to talk to jeremy about power domain framework: DONE * Jeremy needs help, will revisit in a few weeks == Minutes == * Vishwa and Srinivas on holidays * Powerdebug: * Start a wiki page to note findings (amit a) * ACTION: Yong to look at common clock FW, find out if debug info being exported (usage count, clk rate, dependencies) * Add code to powerdebug to read this debug information * Power management differentiation * Discussion with Robin from ARM about common frameworks * Robin not convinced about all the consolidation effort, since some of it is seen as competetive differentiator * Amit K believes Mechanism should be common amongst vendors so that can use common tools and design patterns. * Policies can be different to allow differentiation * e.g. have a cpufreq and cpuidle driver allows all vendors to use powertop tool. If current frameworks don't suit the needs, we can work with upstream to extend them.

14 years, 10 months

Fwd: [Build #1931878] armel build of linux-linaro 2.6.35-1003.7 in ubuntu maverick RELEASE

by Tim Gardner

Looks like buildd borkage. -------- Original Message -------- Subject: [Build #1931878] armel build of linux-linaro 2.6.35-1003.7 in ubuntu maverick RELEASE Date: Tue, 24 Aug 2010 03:40:11 -0000 From: Launchpad Buildd System <noreply(a)launchpad.net> Reply-To: Launchpad Buildd System <noreply(a)launchpad.net> To: tim.gardner(a)canonical.com * Source Package: linux-linaro * Version: 2.6.35-1003.7 * Architecture: armel * Archive: ubuntu primary archive * Component: main * State: Failed to build * Duration: four minutes * Build Log: https://launchpad.net/ubuntu/+source/linux-linaro/2.6.35-1003.7/+build/1931… * Builder: https://launchpad.net/builders/hubbard * Source: https://launchpad.net/ubuntu/+source/linux-linaro/2.6.35-1003.7 If you want further information about this situation, feel free to contact a member of the Launchpad Buildd Administrators team. -- armel build of linux-linaro 2.6.35-1003.7 in ubuntu maverick RELEASE https://launchpad.net/ubuntu/+source/linux-linaro/2.6.35-1003.7/+build/1931…

14 years, 10 months

Beta Freeze this Thursday

by Jamie Bennett

Hi, The Linaro Beta Freeze comes into effect Thursday 26th August 2010, i.e. this Thusday! [1]. After the deadline _all_ uploads to the main archive will have to be approved manually by the release team. For a further explanation of what the Beta Freeze entails and how to get your changes into the archive, please see the Linaro wiki [2][3]. Regards, Jamie. -- Linaro Release Manager [1] http://wiki.linaro.org/Releases/1011#Linaro10.11Schedule [2] http://wiki.linaro.org/Releases/BetaFreeze [3] http://wiki.linaro.org/Releases/ReleaseStages

14 years, 10 months

Announcing the Linaro 2.6.35 "stable" kernel

by Nicolas Pitre

There is now a "stable" 2.6.35-based Linaro kernel repository now available from: git://git.linaro.org/kernel/linux-linaro-2.6.35.git http://git.linaro.org/gitweb?p=kernel/linux-linaro-2.6.35.git;a=summary Unlike the linaro-next tree which will continue to evolve and be rebuilt with the merge of latest developments, the stable 2.6.35 repository won't be rebased and will only include bug fixes and material really considered stable and non intrusive from now on. This linaro-2.6.35 tree is currently made of: - The official 2.6.35 kernel from Linus of course; - The latest Linaro merge tagged linaro_merge_100811 previously announced here; - The upstream stable branch up to 2.6.35.3; - A fix for symbol offset breakage with separated debug in perf by Dave Martin; - The small change required to enable ASLR on PIE executable text segments. Please report any problem with this tree as always. Nicolas

14 years, 10 months

Git repository shuffling on git.linaro.org

by Nicolas Pitre

As discussed between Loïc, John and I, some kernel repositoryes have been moved around on git.linaro.org to better reflect their usage, and to give them more "official" sounding names. Unless people really complain, I don't think this is worth adding backward compatibility symlinks at this point, as this would only clutter the namespace for little gain. It should be easy for people to simply edit their .git/config file within the clones of those repositories and adjust the affected URLs. For example: git.linaro.org/linux/arm_next.git is now git.linaro.org/kernel/linux-linaro-next.git John Rigby's Ubuntu packaging of the above are now found at: git://git.linaro.org/ubuntu/linux-linaro.git git://git.linaro.org/ubuntu/linux-meta-linaro.git I also created a people/ directory under which all personal trees can be accessed. Hence I'd ask those of you (amitarora, amitk, arnd, jcrigby, lool) to remove those symlinks from Git's root repo directory at your earliest convenience. Those personal repositories may now be accessed by adding "people/" in front of the path component of the Git URL. Nicolas

14 years, 10 months

FYI, first-draft RCU priority boosting detailed design

by Paul E. McKenney

Hello! Attached is the current draft of the RCU-boosting detailed design document. There are still a few TBD sections, which I will fill out this week. The associated Linaro spec is at: https://wiki.linaro.org/WorkingGroups/KernelConsolidation/Specs/RcuPriority… Thanx, Paul

14 years, 10 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev