With Nicolas releasing the linux-linaro-3.1 branch, I wanted to also
announce that the linaro+android-3.1 branch has also opened.
I've tag it as: linux-linaro-3.1-2011.10-0-android-0
>From the branch:
git://android.git.linaro.org/kernel/linaro-android.git linaro-android-3.1-ozoom-rebase
Since android.git.kernel.org is still down, and there is no official
kernel/common-3.1 branch, I've merged in the forward ported
kernel/common-3.0 work done by TI in the omapzoom p-common tree. Thanks
to the TI folks for that work!
Let me know if there's any trouble. Similarly, I'll be following Nico's
linux-linaro-3.0 work in case the 3.1 jump is too aggressive for 11.10.
thanks
-john
Hi -
Recently at Linaro we've started a new tree
linaro-androidization-tracking, which is pretty much "common-3.1"[1] at
the moment on 3.1-rc8 basis.
http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git;a=summary
We have already been running a kernel tree tracking Linus HEAD since
2.6.39, which has OMAP4 / Panda enablement stuff on top of Linus HEAD,
so we have some experience with the rough and tumble.
What we missed having was an "all year round" Androidization tree that
we could combine it with to casually create Android versions of the work
we were doing on Vanilla Linus HEAD basis. We used common-3.0 for that
for a while late in the kernel release cycle when it was tracking Linus
HEAD itself and that was great. But common-3.0 like the name suggests
is really a release tree, and it stops tracking at release, and a new
one starts up only late in the next kernel release cycle.
Actually, it would be a big advantage for many folks to not be doing
their Android kernel development on lagging releases, but by tracking
Linus HEAD. They would have access to latest stuff already and they
don't have to think about backport or later forwardport stuff to a new
release, it's constantly tracking HEAD and being adapted.
One side-effect of using this tracking methodology is if they want
release trees, they can just clone their tracking branch at the time
Linus HEAD is at a release point and bam, a hopefully fully working
release tree is there. Another very nice side-effect is they can do the
bulk of the work once on a Vanilla Linus HEAD basis, and get and Android
version of that work routinely by merging or rebasing in the
Androidization tree - instead of doing and validating work twice on
separate Vanilla and Android trees.
So linaro-androidization-tracking is our attempt at that Linus HEAD
Androidization tree, moving it on regularly and fixing breakage as it
happens throughout the cycle. It's generic same as common-, it should
be usable for any arch or board to Androidize a vanilla kernel that is
on the same Linus HEAD basis just by merge or rebase action.
It seemed this effort might be interesting for the guys that make the
common- trees, since if there was a tracking Androidization tree, in
fact common- releases for release trees like common-3.1 would just
naturally fall out of it when Linus HEAD was at 3.1. So I'd be very
happy to hear any opinions about that.
Another side-issue is we are also looking at refactoring the
Androidization patchset into topic branches, at the moment they're kind
of reflecting the history that they were applied on plus or minus some
munging around. So, all the net core patches for example would be
together in one series, then all the wireless ones in a series on top of
that, etc. It seems they would be easier to maintain then, opinions on
that approach are also welcome.
-Andy
[1] TI have a tree on omapzoom where we got the patches from
http://git.omapzoom.org/?p=kernel/omap.git;a=shortlog;h=refs/heads/p-androi…
--
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
== Thomas Abraham <thomas-ab> Â ==
=== Highlights ===
* Submitted second version of UART and IRQ device tree support patches.
* Prepared a single device tree enabled board file for smdkv310 and Origen
boards and tested device tree support on both the boards for the following
modules: UART, SDHCI, Keypad, GPIO keys, DMA, RTC, I2C, WDT,
GPIO, IRQ
=== Plans ===
* Submit updated/rebased device tree support patches for SDHCI, Keypad,
DMA, RTC, GPIO, IRQ and dt-board file. (hoping that all of these will be
merged in 3.2)
=== Issues ===
* (Not critical) Testing for backward compatibility with the changes in the
drivers for all previous Samsung boards consumes lot of time.
== Linus Walleij linusw ==
=== Highlights ===
* Maturing pinctrl core and pinmux in linux-next, answering
late review comments and merging smaller patches.
* Arnd pulled the last ux500 stuff (timers) for the merge
window.
* Found the problem with attached device trees on my
platforms. Root cause: mismatched "compatible" node
hangs kernel 3.1+ at an early stage, with an error message
on the earlyprintk console. If you don't have a working
earlyprintk the stuff locks up, and this non-visibility of
early errors had us stuck for a while.
* Reviewed various stuff. (pinctrl, MMC, new platform called
SPMP8000).
=== Plans ===
* Let pin control core and pinmux mature in -next and
I expect to issue a pull request to Torvalds in the coming
merge window
* Start working on generic pin control:
- Biasing
- Driving
- Input modes
- Load capacitance
First step - survey of existing configuration options for
currens SoC:s.
* Test the PL08x patches on the Ericsson Research
PB11MPCore and submit platform data for using
pl08x DMA on that platform.
* Drive generalization of U300 and Nomadik GPIO
by using the pinctrl framework
* Watch the DBx500 PRCMU drivers update, fixed
patches for Sam, but don't know if he's pleased with
them yet.
* Mainline some ux500 U-Boot stuff so it can atleast boot
the system.
=== Issues ===
* The formation of the clk subsystem seems pretty much
tangled up in details right now, don't know what to do
about it though :-(
Thanks,
Linus Walleij
Hi -
TI Landing Team has added a couple of new trees to our git repo over the
weekend
http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git;a=summary
Both of them track Linus HEAD, currently at 3.1-rc8.
First is "linaro-androidization-tracking", this is Linus HEAD plus a set
of Androidization patches formed from common-3.0 and common-3.1.
"common-3.1 you say?", yes, TI needed a tracking Androidization tree and
have made their own public one using pieces from common-3.1.
You can find TI's tree that was an ingredient in this here if you're
interested, it's public
http://git.omapzoom.org/?p=kernel/omap.git;a=shortlog;h=refs/heads/p-androi…
Due to android.git.kernel.org down, AFAIK there's no public access to
common-3.1 direct otherwise at the moment.
So what's this tree good for? If you have a kernel for any arch or
board that is based on Linus HEAD, 3.1-rc8 at the moment, you can merge
or rebase a copy of it with linaro-androidization-tracking to create an
Android version of the same kernel.
That's very handy if you did your work to get stuff looking good on
Vanilla Linus HEAD and don't want to repeat the effort to get the same
features coming in an Android kernel.
Until now there was no way to casually Androidize a Linus HEAD basis
tree unless it happened common-3.x was tracking it, which it only does
for a short period at the end. It meant that you had to use old release
to start integrating and adding drivers for Android and backport from
HEAD anything nice that was coming. Now with this tree, you can do your
work on Linus HEAD and fork off working release trees when Linus HEAD
goes through a release.
This Androidization tree is generic and should be usable for any arch or
board, there's nothing TI specific in there. Why then is TI Landing
team announcing it / TI go to the effort of creating their original one
we based off? Nobody else in Linaro wanted to do the work to create and
maintain it, so we own it at the moment. We'll have to see how tough it
is to keep tracking Linus HEAD through the post-release patchstorm but
reviewing the Androidization patchset I'm cautiously optimistic.
I don't have any connection to Google guys who are basically doing the
same work on common-3.x, but it would be very cool to be able to
cooperate with them on bringing this Androidization patchset forward for
everyone's benefit.
The second branch is "tilt-android-tracking". This is our main tracking
branch tilt-tracking for Panda enablement we have been running for some
months combined with "linaro-androidization-tracking" above.
This gets you an effective Panda enabled "3.1 preview" kernel that we
have had for a while on Vanilla also on Android in an ongoing way.
Current status of it is
+ 1080p SGX acceleration
- Suspend borked
- WLAN borked
But we only generated it Sunday, we are working on those issues now.
Lastly TILT is also providing tracking versions of the Android autobuilt
Panda-LEB tarballs that are ready to use. These are the Autobuilt
tarballs with the kernel replaced with a tracking one by us. You can
find them linked from our git repo in tilt-android-tracking column of
the status table there.
-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
=== Highlights ===
* Worked on prototyping sched-flag based timer freezing. Initial rough
hack allowed a system to drop from 20-60 wakeups per second down to 0.7.
The hack is not really viable, so I'm continuing to research and refine
the idea to see how it could best be implemented.
* Pinged AmitK for ideas on how to measure power improvements.
* Resubmit merge_config.sh script to lkml. So far have had no feedback.
* Reviewed a rough initial patch by Dave Hansen that could be the start
of some ashmem-like functionality. Talked with him about some of the API
issues over lunch.
* Split up some blueprints for Mounir
* Met with PaulMck for lunch to sync up on current issues around my
wakelocks idea.
* Linaro Connect expenses went through! Yay!
=== Issues ===
* N/A
== Dave Martin <dmart> ==
=== Activity Summary ===
* More discussions around testing/quality/documentation
* Reworked AMBA module autoloading series to Do Things Properly using
the existing modpost framework. Posted patches; about 50% Acked.
* Thumb-2 kernel migration advice posted on wiki and linaro-dev.
* No significant progress on Versatile Express this week, due to
discussions and other work.
=== Plans ===
Prompt for further feedback on minor Thumb-2 randconfig issues:
* v6/v7 single kernel Thumb-2 undef fixup patches: currently waiting
for Russell/Arnd to comment
* Fixing some Thumb-2 related randconfig errors reported by Arnd:
* pxa/pj4/iwmmxt uses non-Thumb-2-compatible code: waiting for
feedback (probably needs a Marvell expert to comment)
* tegra2 uses non-Thumb-2-compatible code: waiting for feedback from
Colin Cross.
=== Work Items ===
Refined the workitems list for vexpress:
kernel-versatile-boad-description-and-implementation:
* [dave-martin-arm] Dynamic loading of AMBA device drivers (including
via DT) - implement and test: DONE
* [dave-martin-arm] Dynamic loading of AMBA device drivers (including
via DT) - repost: DONE
* [dave-martin-arm] Dynamic loading of AMBA device drivers (including
via DT) - Propose for merging: TODO
linaro-kernel-o-finish-thump2-support:
* [dave-martin-arm] to document what he needed to do get Thumb-2
kernel working for a new SoC: DONE
=== Absences ===
Mon 2011-10-17 - Fri 2011-10-21
Hi all,
For kernel guys and landing teams, I've posted some kernel-specific
info on mirating to Thumb-2 here:
https://wiki.linaro.org/WorkingGroups/Kernel/Thumb2Guide
If your kernel tree isn't building in Thumb-2 yet, please do take a look.
Let me know if you want more information on anything, or if you find
something that's incorrect or confusing.
Cheers
---Dave
Hi -
Recently at Linaro we've started a new tree linaro-androidization-tracking,
which is pretty much "common-3.1"[1] at the moment on 3.1-rc8 basis.
http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git;a=summary
We have already been running a kernel tree tracking Linus HEAD since 2.6.39,
which has OMAP4 / Panda enablement stuff on top of Linus HEAD, so we have
some experience with the rough and tumble.
What we missed having was an "all year round" Androidization tree that we
could combine it with to casually create Android versions of the work we
were doing on Vanilla Linus HEAD basis. We used common-3.0 for that for a
while late in the kernel release cycle when it was tracking Linus HEAD
itself and that was great. But common-3.0 like the name suggests is really
a release tree, and it stops tracking at release, and a new one starts up
only late in the next kernel release cycle.
Actually, it would be a big advantage for many folks to not be doing their
Android kernel development on lagging releases, but by tracking Linus HEAD.
They would have access to latest stuff already and they don't have to think
about backport or later forwardport stuff to a new release, it's constantly
tracking HEAD and being adapted.
One side-effect of using this tracking methodology is if they want release
trees, they can just clone their tracking branch at the time Linus HEAD is
at a release point and bam, a hopefully fully working release tree is
there. Another very nice side-effect is they can do the bulk of the work
once on a Vanilla Linus HEAD basis, and get and Android version of that work
routinely by merging or rebasing in the Androidization tree - instead of
doing and validating work twice on separate Vanilla and Android trees.
So linaro-androidization-tracking is our attempt at that Linus HEAD
Androidization tree, moving it on regularly and fixing breakage as it
happens throughout the cycle. It's generic same as common-, it should be
usable for any arch or board to Androidize a vanilla kernel that is on the
same Linus HEAD basis just by merge or rebase action.
It seemed this effort might be interesting for the guys that make the
common- trees, since if there was a tracking Androidization tree, in fact
common- releases for release trees like common-3.1 would just naturally fall
out of it when Linus HEAD was at 3.1. So I'd be very happy to hear any
opinions about that.
Another side-issue is we are also looking at refactoring the Androidization
patchset into topic branches, at the moment they're kind of reflecting the
history that they were applied on plus or minus some munging around. So,
all the net core patches for example would be together in one series, then
all the wireless ones in a series on top of that, etc. It seems they would
be easier to maintain then, opinions on that approach are also welcome.
-Andy
[1] TI have a tree on omapzoom where we got the patches from
http://git.omapzoom.org/?p=kernel/omap.git;a=shortlog;h=refs/heads/p-androi…
(Apologies for any duplication, googlegroups needs mail sent from Google
mail)
--
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
Hi all,
I want to give everyone a heads up about the kernel.org outage. As
most of you know, kernel.org was compromised by an outside hacker and
has been taken down for rebuild. You can find the coverage on
lwn.net[1][2][3].
[1] http://lwn.net/Articles/457142/ - Initial notice
[2] http://lwn.net/Articles/458809/ - Further details
[3] http://lwn.net/Articles/460376/ - An update from H. Peter Alvin
Because kernel.org is central to the kernel development process,
particularly since the majority of git trees pulled by Linus live
there, the security of kernel.org is of paramount importance. It is
critically important that when the kernel.org infrastructure comes
back up that it not be vulnerable to another attack, so as part of
rebuilding the infrastructure, all of the policies around how
developers access kernel.org as well as how Linus pulls maintainer
trees is under review.
The reason for this email is to give you a heads up about what you
should expect when kernel.org becomes live again. There is a strong
likelyhood that maintainers will need to start GPG signing branches
that they will ask Linus to pull. Nothing has been decided firmly
(indeed, we won't know until Linus himself makes a decision about what
he will accept), and it will definitely be a topic for the upcoming
Kernel Summit at the end of October. However, it is worth taking the
opportunity now to get familiar with GPG and to create a key for
yourself. The Debian developers among you will already be familiar
with this process, /even if you don't have a kernel.org account/. The
Debian keysigning page[4] is a good place to start reading.
[4] http://wiki.debian.org/Keysigning
I'll post more details as I learn them. In the mean time, you can
email me if you have any questions and I'll do my best to answer them.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
