Greetings,
Enclosed you'll find a link to the agenda, notes and actions from the
Linaro User Platforms Weekly Status meeting dated 8/25 held in
#linaro-meeting at 13:00 UTC.
https://wiki.linaro.org/Platform/UserPlatforms/WeeklyStatus/2010-08-25
Regards,
Tom (tgall_foo)
User Platforms Team
Hello,
I have another question related to cross compilation...
I am still trying to setup a functional cross compilation environment
for our packages. I want to be able to build without xdeb, using debuild
command (this is mainly because we use other tools such as
git-buildpackage).
When I build a package which has dependency on another .so file, my
./configure script fails, pkg-config complains that it cannot find my
package config file (which is available in
/usr/arm-linux-gnueabi/lib/pkgconfig.
If I set PKG_CONFIG_LIBDIR to /usr/arm-linux-gnueabi/lib/pkgconfig, then
my build is fine, e.g. debuild
-ePKG_CONFIG_LIBDIR=/usr/arm-linux-gnueabi/lib/pkgconfig -b -aarmel -us -uc.
Is that expected? I was looking around in xdeb, and I don't find where
this is being done, and I am sure it would be needed too since it ends
up calling debuild... In this process I noticed that xdeb is also
passing /etc/dpkg-cross/cross-config.armel to debuild. Should I do this to?
I would appreciate any feedback on this.
thanks,
nicolas
note: I am using a maverick chroot, and Marcin's cross compiler.
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
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
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.
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…