Hi All,
In ppa: tom-gall/packages I've published an updated version live-build
(version a40-1linaro10) for maverick, natty, oneiric, and precise.
This version of live-build includes the ability to cross build root
file systems with multistrap. As it turns out to cross build our
precise linaro images for nano and developer, one only needs to change
one parameter to enable cross builds.
The "beta" instructions are as follows:
1) add-apt-repository ppa:tom-gall/packages
2) apt-get update
3) apt-get install live-build
This will work for maverick, natty, oneiric and precise. It will
install version: ~a40-1linaro10
4) mkdir dirforbld ; cd dirforbld
5) bzr branch lp:~linaro-maintainers/linaro/live-helper.config.precise.nano
config
or bzr branch lp:~linaro-maintainers/linaro/live-helper.config.precise.developer
config
6) cp config/conf_create.sh .
7) edit conf_create.sh : change parameter to --bootstrap from
debootstrap to multistrap
8) add / remove packages listed in
config/package-lists/nano.chroot.list which is a text file. One
package per line.
9) sh ./conf_create.sh
10) lb build
11) When rebuilding use the command : lb clean --all ; lb clean
--cache; rm -rf .stage/* ; lb build
--
Regards,
Tom
"Where's the kaboom!? There was supposed to be an earth-shattering
kaboom!" Marvin Martian
Multimedia Tech Lead | Linaro.org │ Open source software for ARM SoCs
w) tom.gall att linaro.org
w) tom_gall att vnet.ibm.com
h) tom_gall att mac.com
Hi -
Alexander was asking how linaro-androidization-tracking is maintained
(hope you are feeling better Alexander).
I made a 90-slide presentation about it at the last Connect, you can
find the slides here
http://people.linaro.org/~andygreen/lttools-introduction.pdf
and the tools here
http://git.linaro.org/gitweb?p=people/andygreen/lt-tools.git;a=summary
In a nutshell common-3.0 from Google is a history tree, so detecting new
patches on there is clear enough. John Stultz saw it had come back
recently and dropped me a note it had been updated. I asked Jassi to
isolate the new patches and send them to me.
I use lt-tools to distribute any new patches between the topics, then
reapply it to my android-ready branch and confirm it builds and works
before pushing.
lt-tools also takes care of the tracking action, it's important
everything is on the same Linus HEAD basis so I routinely rebase
linaro-androidization-tracking along with my other tracking branches, as
of last week it's on 3.2-rc4.
Actually, l-a-t is low maintainence since it's far from every day new
patches are coming on common-3.0, and so far on 3.2 cycle there was no
serious uplevel conflict between the androidization patch load and Linus
HEAD changes.
If we have someone else now who wants to maintain it, I think that's
fine with the provisos we should maintain the topic structure and look
at further refactor there, and we need a new approach to deal with
rebase points that more than one tree can rendezvous at --->
Right now when my tracking branches are in as reasonable a shape on one
Linus HEAD basis as they will get, I randomly pull a new basis from what
happens to be on Linus' tree that moment, and rebase everything on my
side against that (including up until now l-a-t at the same time). That
won't really scale to other LTs and WGs all randomly sampling Linus HEAD
at different random points as their basis.
Scott mentioned that there's a desire to see more KWG content at least
on tracking, I think that's a great idea. One way to solve both those
problems would be to no longer have LTs base off Linus HEAD but from a
new tree which is Linus HEAD + "linux-linaro-tracking", as it were, with
these other topics already merged in. So long as this rebases against
Linus HEAD really often, like daily at least in the early -rcs, carrying
its topic content with it, and matching linaro-androidization-tracking
is available, that would be a good way for all the LT trees to both get
any Linaro-specific content and increase their chances of having a
common "rendezvous" basis where multiple LT trees can be bound together.
-Andy
--
Andy Green | TI Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106 -
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog
A request has been received to discontinue Linaro's support for the
Beagleboard and Beagleboard-xM hardware.
The following conditions will be applied for the 2012.01 release cycle:
* There will be no more LEB or Linaro Developer builds.
* No more testing will be applied by Linaro to the boards at all,
and no quality assurance will be performed.
* No more bugs will be filed against these boards assigned to
Linaro resources.
* All currently filed bugs will be re-targeted to the appropriate
community resource.
* Landing team support is no longer needed or expected.
* Linaro Release notes will no longer refer to Beagleboard.
--
David Zinman
Linaro Release Manager | Project Manager
Linaro.org | Open source software for ARM SoCs
Since there is code duplication in different mach-board.c file it is better
to set default clock rate of xusbxti clock in plat-s5p/clock.c file.
The patches are based on following commit on Kukjin's for-next branch.
Pankaj (1):
ARM: S5P: Set default rate of xusbxti clock
Pankaj Dubey (2):
ARM: EXYNOS: Removed code for setting clock rate of xusbxti
ARM: S5PV210: Removed code for setting clock rate of xusbxti
arch/arm/mach-exynos/mach-nuri.c | 1 -
arch/arm/mach-exynos/mach-origen.c | 1 -
arch/arm/mach-exynos/mach-smdk4x12.c | 2 --
arch/arm/mach-exynos/mach-smdkv310.c | 1 -
arch/arm/mach-s5pv210/mach-goni.c | 1 -
arch/arm/plat-s5p/clock.c | 1 +
6 files changed, 1 insertions(+), 6 deletions(-)
--
1.7.4.1
Hi all,
a few weeks ago I (and a few others) started hacking on a
proof-of-concept hypervisor port to Cortex-A15 which uses and requires
ARMv7 virtualization extensions. The intention of this work was to find
out how to best support ARM v7+ on Xen. See
http://old-list-archives.xen.org/archives/html/xen-arm/2011-09/msg00013.html
for more details.
I am pleased to announce that significant progress has been made, and
that we now have a nascent Xen port for Cortex-A15. The port is based on
xen-unstable (HG CS 8d6edc3d26d2) and written from scratch exploiting
the latest virtualization, LPAE, GIC and generic timer support in
hardware.
We started the work less than three months ago, but the port is already
capable of booting a Linux 3.0 based virtual machine (dom0) up to a
shell prompt on an ARM Architecture Envelope Model, configured to emulate
an A15-based Versatile Express. In this context, we wanted to thank ARM
for making the model available to us.
Now we are looking forward to porting the tools and running multiple
guests.
The code requires virtualization, LPAE and GIC support and therefore it
won't be able to run on anything older than a Cortex-A15.
On the other hand, thanks to this, it is very small and easy to read,
write and understand.
The implementation does not distinguish between PV and HVM guests: there
is just one type of guests that would be comparable to Linux PV on HVM
in the Xen X86 world, but with no need for Qemu emulation.
The code only requires minimal changes to the Linux kernel: just enough
to support PV drivers.
Even though we are currently targeting Versatile Express and Cortex-A15
we do intend to support other machines and other ARMv7 with
virtualization extensions CPUs.
We are also looking forward to ARMv8 and 64 bits support.
Given that porting Xen to Cortex-A15 could be done with so little code,
we believe that the best course of action is to merge it into
xen-unstable as quickly as possible. There are still few rough edges to
sort out but we should be able to produce a clean and digestible patch
series for submission to xen-devel within the next couple of months. I
hope to see the first patches going to the list as soon as possible.
We would very welcome any contributions, in the form of testing, code
reviews and, of course, patches!
A git tree is available here:
git://xenbits.xen.org/people/sstabellini/xen-unstable.git arm
the gitweb url is the following:
http://xenbits.xen.org/gitweb/?p=people/sstabellini/xen-unstable.git/.git;a…
And here is the full diff:
http://xenbits.xen.org/people/sstabellini/diff
We want to point out that this effort is in addition to Samsung's
ongoing efforts to upstream Xen ARM to xen-unstable. Samsung's XenARM
port allows virtualization of Xen on ARM CPUs prior to virtualization
extensions and supports traditional PV guests.
I would like to thank Tim Deegan and Ian Campbell: if you spend some
time reading the history, you'll see that this project wouldn't have
been possible in such a short time without great contributions from
them.
Cheers,
Stefano
Amit/Mounir,
What's your guys plan with cpu_idle for each board? Are you going to
try and upstream a solution that will work across all boards? Would
you or Mounir be open to filing a BP per board so we can track when
cpu_idle will hit each board? Does it make sense to prototype
something across each board that we could land in Ubuntu and Android?
Adding other people, leads, etc...
--
Zach Pfeffer
Android Platform Team Lead, Linaro Platform Teams
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linarohttp://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog