* Discussion to generalize the maintenance process of kernel branches
> for the periodic Linaro releases. This still needs documenting in the
> wiki.
>
> * Merged a set of patches put together by Anand Gadiyar to add display
> support to the PandaBoard.
>
> * Merged the following additional patches:
>
> * d983450 cpufreq: Add documentation for sampling_down_factor
> * 054fcd5 ARM: S5P: Fix end address in memory resource information for UART devices
> * bf47520 ARM: make SWP emulation explicit on !CPU_USE_DOMAINS
> * 459967a ARM: fixup SMP alternatives in modules
> * 7144fbc ARM: 6654/1: perf/oprofile: fix off-by-one in stack check
> * 067dfdf ARM: 6659/1: Thumb-2: Make CONFIG_OABI_COMPAT depend on !CONFIG_THUMB2_KERNEL
> * cc0f308 ARM: 6656/1: hw_breakpoint: avoid UNPREDICTABLE behaviour when reading DBGDSCR
> * 40ef21c ARM: 6657/1: hw_breakpoint: fix ptrace breakpoint advertising on unsupported arch
> * 9e97118 ARM: ptrace: remove single-step emulation code
>
== Upstream oriented activities ==
* Review of Arnd Bergmann's flash card article for LWN.
* Incorporation of feedback to the patch adding Thumb2 support to the
P2V branch.
* Another look at the Thumb-2 compatibility fixes for OMAP from Dave
Martin.
* Review of a patch series adding support for SDHCI v3.00.
* Posted patches:
* Rework of the kernel decompressor code to improve efficiency
* Removal of the 4x expansion presumption while decompressing the kernel
* kprobes insn decoding fix
* Ignore mdesc->boot_params if out of range
* Fold lookup_machine_type() into setup_machine()
== Linaro kernel activities ==
* Looked at some bugs:
* Bug 660811
* Bug 720055
* Merged 2.6.37.1 into linaro-2.6.37
* Merged Dave Martin's Thumb2 compatibility patches for OMAP.
* Merged core ARM ffixes from RMK.
* Merged OMAP fixes from Tony Lindgren.
* Opened up the linaro-2.6.38 branch.
Nicolas
Hello,
OpenID plugin usage has been disabled in ci.linaro.org due to some
vulnerability detected with the plugin.
Hence the Single Sig On option using your launchpad id wont work for now
till it gets fixed.
If you need to use ci.linaro.org services and need a way to login please
create a new user on ci.linaro.org
and mail me the details and I will give you appropriate access to the
service.
---------- Forwarded message ----------
From: Paul Sokolovsky <paul.sokolovsky(a)linaro.org>
Date: Fri, Oct 28, 2011 at 4:09 PM
Subject: FYI: OpenID auth disabled on android-build.linaro.org
To: linaro-android <linaro-android(a)linaro.org>, Alexander Sack <
asac(a)linaro.org>, Danilo Šegan <danilo.segan(a)linaro.org>, Infrastructure <
infrastructure(a)linaro.org>
Hello,
Due to suspected security issue, OpenID auth was disabed on
android-build.linaro.org. OpenID was never recommended as auth means
there, and instead username/passwd auth was recommended, so this change
should not affect users. Please let me know if you have any issues.
ETA for being enabled back is so far not known, Danilo Shegan tracks
this issue.
--
Best Regards,
Paul
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
--
Thanks and Regards,
Deepti
Infrastructure Team Member, 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
Hi all,
I have created a blueprint [1] for connect to discuss the
topic of platform level testing and want us to have some
sense of what we want before going into a face to face
discussion. I would like all the landing team leads
to attend this session, so I've marked you as essential.
The overall problem we are trying to solve is how
do we ensure that hardware enablement (USB,
MMC, etc) does not break across kernel versions.
We've had several cases where a patch got merged
into kernel.org that broke a device driver and
we didn't catch it until just before our release.
This causes us to scramble and reduces the
quality of the work we're delivering to our members.
With the CI loop in place, we now have the opportunity
to catch these type of issues early on, before they
even make it into the -rc kernels. My hope is that
by the end of the summit session, we have a enough
information to go back and develop a high level
roadmap of test cases to deliver. The questions I'd
like us to think about before the connect session include:
1) What are the different devices on each board that
we want to test and how do we test them?
We need to go through board by board and determine
which I/O devices can be tested and come up with
common methods to test them across all our existing
platforms. One of the questions that comes up for me
is what level of testing do we want? We can do simple
discovery tests such as look for sysfs device nodes and
poke at values in there or we can right small applications
that test specific functionality (mounting block devices
and running benchmark tests and also testing ioctls for
example).
2) Who develops these tests?
I think the answer to this is to have Landing Team
engineers developing the board-specific tests with a
KWG engineer assigned to coordinate overall direction
of the work.
3) Do we integrate those tests into an existing
framework (LTP for example) or develop a
separate framework for these tests? Related
to this question is whether some of the vendors
will provide us test cases we can just pull into
Lava?
~Deepak
[1] https://blueprints.launchpad.net/linux-linaro/+spec/linaro-kernel-platform-…
On Mon, Oct 3, 2011 at 6:32 PM, Christian Robottom Reis <kiko(a)linaro.org> wrote:
> On Mon, Oct 03, 2011 at 12:20:38PM -0700, Deepak Saxena wrote:
>> Is there usually a key-signing at UDS? If not, should we organize a
>> Linaro one?
>
> Copying Jorge.
>
> Yes, there's usually always a massive key-signing at UDS; Jorge, can you
> get us details as to whether and when the Orlando one is?
As far as I can tell there hasn't been an officially scheduled
keysigning in a while, usually people organize one on their own after
hours, however in light of recent events it might be prudent to
organize one with Linaro on a certain day after sessions.
CCing ubuntu-devel to see if anyone has plans/interest in getting this together.
=== Highlights ===
* Resubmitted kconfig merge_config script to lkml
* Submitted a number of clocksource cleanups to lkml
* Had a number of alarmtimer cleanup patches merged into 3.2 merge
window
* Worked on further prototyping madvise ashmem interface
* Heard from Paul that at Kernel Summit wakelocks were brought up and it
sounds like they may be merged as is! Discussions on the list continue.
* Submitted a documentation patch for the timekeeping core.
* Made final 11.10 Linaro+Android kernel release
* Spent a little time reviewing Neil Brown's userpsace pm deamon, but
not as much as I was hoping for.
* Worked on some virtualized testing environments to help with
development and testing.
* Setup linaro.org google+ account
=== Plans ===
* Linaro connect!
* Continue working on ashmem alternative
=== Issues ===
* None
Just wanted to announce that the final Linaro+Android-3.1 kernel is
available.
I've tagged it as: linux-linaro-3.1-2011.10-2-android-0
>From the branch:
git://android.git.linaro.org/kernel/linaro-android.git linaro-android-3.1-agreen-rebase
No changes other then updating to the latest linaro-3.1 updates.
thanks
-john
Hi -
Linus released 3.1 a couple of days ago, I have archived the tracking
androidization patchset with a pure vanilla 3.1 release basis here
http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git;a=shortl…
The tracking androidization tree has already moved on into Linus' new
pre-3.2 basis territory
http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git;a=shortl…
There were big file layout refactors in the mainline networking stack that
caused a lot of impact network / wireless related patches, some smaller
adaptations needed in gadget related patches and a little bluetooth dust.
Interestingly during the uplevel I noticed three patches (of ~470) had
evidently managed to get upstream so far for 3.2
0419-ipv6-updates-to-privacy-addresses-per-RFC-4941.patch
0431-hid-debug-Show-application-usage-for-each-collection.patch
0432-hid-multitouch-Filter-collections-by-application-usa.patch
I am updating the affected patches in linaro-androidization-tracking
directly. I have already been automatically tagging each push, with, eg,
"linaro-androidization-tracking-2011-10-25-18-24-CST", so there is a history
of these rebase trees being kept.
My plan after this is to perform a more aggressive squash on the refactored
patchset (I would like to considerably reduce the number of "internal
history" type patches, keeping the contributor patch logs in the squash
patch's log) and moving to using just that, instead of continuing to run the
patchset we started with and the refactored one simultaneously.
I am testing this against OMAP4 Panda board, soon there will be more test
coverage coming for the other LEBs supported by Linaro. We know already
that some of the non-core Androidization features were broken in common-3.0
and remained broken in the starting point for this tree. Any patches to fix
things like Broadcomm WLAN or whatever that we don't use at Linaro will be
very welcome. However, we believe the all core Android features are working
fine on this tree, since they result in a working Linaro Android rootfs for
Panda (complete with PVR accelerated video).
-Andy
PS If anyone interested in this stuff is at Linaro Connect, feel free to
ping me for a chat / beer
=== Device Tree ===
* imx5 board level DT series is ready for v3.2 merge window.
* Reviewed Rajendra's regulator DT series, and tested it with mc13892.
Some issue with different level 'struct dev' was found and is being
discussed.
=== Consolidation ===
* Reviewed Linus.W's pinctrl series about pin configuration part gave
input there as far as imx iomuxc controller concerned.
* Working on migrate imx6 clock to common clock v2 series from Mike
Turquette
=== Misc ===
* The imx6q series has been pulled into arm-soc tree by Arnd for v3.2
merge window.
* As suggested by Pengutronix, they want to get Sascha relieved from
the burden of maintaining MXS (imx23 and imx28) sub-architecture.
Since I brought the most of MXS core code to mainline, I stepped up
for maintaining MXS. This will start when v3.2 merge window closes.
I expect some amount of time will be spent on that at daily basis.
* The book of Orlando travel was cancelled.
--
Regards,
Shawn
FYI
---------- Forwarded message ----------
From: Deepti Kalakeri <deepti.kalakeri(a)linaro.org>
Date: Tue, Oct 25, 2011 at 4:37 PM
Subject: [ANN] Linaro CI Kernel Effort 2011.10
To: linaro-dev <linaro-dev(a)lists.linaro.org>
Hello All,
The Linaro Infrastructure team is pleased to announce the Continuous
Integration (CI) efforts 2011.10.
The Infrastructure Team is tasked to develop and maintain a jenkins based,
versatile service run in the cloud that will drive the build part of the
continuous integration loop for engineering components.
Here are the highlights of this release:
1. A first iteration to support kernel maintainers to submit one time jobs
for testing pull
requests or their personal branches has been finished. Infrastructure
team opens this service
to a limited amount of pilot users to gather initial feedback.
Please get in touch with me if you have similar needs.
2. Thanks to the validation team and special thanks to Michael Hudson,
we now have One stop place for kernel CI tracking on LAVA dashboard is
available
where engineers can continuously monitor their kernel for build and
runtime failures.
The same is available @
http://validation.linaro.org/lava-server/kernel-ci-views/index.
3. ci.linaro.org service has been upgraded to now use jenkins 1.419 and EC2
plugin version 1.13.
ci.linaro.org now aligns with jenkins version and EC2 plugin version
with the one used
for other infrastructure services (e.g. android-build). The future
updates on the same
will now on be coordinate across all such similar linaro infrastructure
services.
4. Extended the kernel CI effort by supporting the daily build for
Packaged Linux-linaro 3.0 and Linux-linaro 3.1 kernels for
imx51, panda, vexpress. Packaged Linux-linaro 3.0 is tested on
panda, beagle boards, while Linux-linaro 3.1 kernels is tested on panda
board in the LAVA lab.
5. The release fixes Bug 860556 "CI kernel fails to reboot successfully".
Known issues:
CI kernels causing many "Illegal Instruction"s.
Initial investigations done for this bug hints that this error might be
occurring
when we have a non-thumb2 kernel interacting with a thumb2 user space.
Here is the link for further details on the bug and the steps to reproduce
the same.
https://bugs.launchpad.net/linaro-ci/+bug/859473
Any help to fix this would be appreciated.
If you are interested in trying out this service or if you have a kernel
tree/defconfig that you would like to be continuously built on Linaro CI and
tested in Linaro's LAVA lab, please get in touch with me and the
infrastructure team, to discuss your steps to get started.
Detailed information on ci.linaro.org is available at
+ https://wiki.linaro.org/Platform/Infrastructure/LinaroCI
Details and background on the CI build service and how to request a new job
at
+ https://wiki.linaro.org/Platform/Infrastructure/LinaroCI
--
Thanks and Regards,
Deepti
Infrastructure Team Member, 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
_______________________________________________
linaro-dev mailing list
linaro-dev(a)lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
--
Alexander Sack
Technical Director, Linaro Platform Teams
http://www.linaro.org | Open source software for ARM SoCs
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
Hello All,
I have a need to enable thumb2 kernel option for kernel built using
omap2plus_defconfig.
Hence I am trying to find a mechanism to automatically enable the thumb2
kernel config option.
I have tried adding the CONFIG_THUMB2_KERNEL=y option to the .config file by
1) Appending it to the end of the .config using the echo
CONFIG_THUMB2_KERNEL=y >> output_dir/.config
2) By replacing the CONFIG_ARM_THUMB=y with CONFIG_THUMB2_KERNEL=y option
using the sed -ie 's/CONFIG_ARM_THUMB=y/CONFIG_THUMB2_KERNEL=y/g'
output_dir/.config
I follow this with the make oldconfig for ex:
yes "" | make ARCH=arm O=output_dir
KERNELVERSION=3.0.5-758-g051c523-omap2plus-linaro-omap
KERNELRELEASE=3.0.5-758-g051c523-omap2plus-linaro-omap
CROSS_COMPILE=arm-linux-gnueabi- oldconfig
Both the above mechanisms work, but once I run oldconfig the .config is
getting overwritten and it gets back to the old state.
I am sure there is something which I am missing. Can you let me know the
exact steps to overwrite the .config file.
1) I want to be able to overwrite the THUMB option with THUMB2 or add the
THUMB2 option ( if existence of both THUMB and THUMB2 in the .config is
permissible)
2) What would happen if both the CONFIG_ARM_THUMB=y and
CONFIG_THUMB2_KERNEL=y options are present in the .config.
Would the kernel be built with CONFIG_ARM_THUMB=y or
CONFIG_THUMB2_KERNEL=y ?
Do you have any suggestions to enable the THUMB2 option in a non-interactive
way ?
--
Thanks and Regards,
Deepti
Infrastructure Team Member, 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
