Re: Running Linaro toolchain on ubuntu 13.10 x86_64
On 12 November 2013 02:01, Ola Dahl dahl@gmail.com wrote: Hi, in my experience (Ubuntu 13.04, 64-bit), it worked fine (building with the Linaro toolchain) after doing two installs: sudo apt-get install ia32-libs and sudo apt-get install ia32-libs-multiarch Those have been dropped in 13.10. Best regards, Ola On Tue, Nov 12, 2013 at 7:25 AM, Deepak Saxena dsax...@linaro.org wrote: I'm working on getting my new build system up and running and with 13.10. Running any of our toolchain commands leads to No such file or directory. I'm guessing this has to with my system being x86_64 and 13.10 no longer including ia32_libs package, but could be incorrect. If this is indeed the issue, my understanding is that I need to manually install 32 bit versions of every library that's needed. Can toolchain folks comment on this? Any possibility of getting 64 bit native binaries or just having a repository that we can install from and thus auto-pull the dependent 32 bit libraries? Thanks, ~Deepak -- Deepak Saxena - Kernel Working Group Lead Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev -- Deepak Saxena - Kernel Working Group Lead Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Running Linaro toolchain on ubuntu 13.10 x86_64
On 12 November 2013 05:49, Nicolas Dechesne nicolas.deche...@linaro.org wrote: On Tue, Nov 12, 2013 at 2:39 PM, Ryan Harkin ryan.har...@linaro.org wrote: On 12 November 2013 06:25, Deepak Saxena dsax...@linaro.org wrote: I'm working on getting my new build system up and running and with 13.10. Running any of our toolchain commands leads to No such file or directory. I had exactly the same problem. I'm guessing this has to with my system being x86_64 and 13.10 no longer including ia32_libs package, but could be incorrect. If this is indeed the issue, my understanding is that I need to manually install 32 bit versions of every library that's needed. Can toolchain folks comment on this? Yes, I assumed so too. I didn't know *which* libraries though, so I gave up in the end and reverted my machine to 12.10. Any possibility of getting 64 bit native binaries or just having a repository that we can install from and thus auto-pull the dependent 32 bit libraries? I was told no at Connect. The reasoning being very understandable: they *must* provide a 32 bit version. And having 2 versions is a support and validation headache. I asked for a snapshot, unverified build. I'm ever hopeful :-) given that [1] ubuntu no longer support ia32-libs in 13.10+ and [2] ubuntu has decided to switch to 64-bit by default, i believe we should provide an explicit note about how to run the 32-bit Linaro GCC on 64-bit machines, as it is wrong to either use a 32-bit OS install, or stay on an older OS version to workaround the problem ;-) The current README still refers to ia32-libs package. +1 For now, I'm going down the road of building my own binutils and gcc. ~Deepak ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Running Linaro toolchain on ubuntu 13.10 x86_64
I'm working on getting my new build system up and running and with 13.10. Running any of our toolchain commands leads to No such file or directory. I'm guessing this has to with my system being x86_64 and 13.10 no longer including ia32_libs package, but could be incorrect. If this is indeed the issue, my understanding is that I need to manually install 32 bit versions of every library that's needed. Can toolchain folks comment on this? Any possibility of getting 64 bit native binaries or just having a repository that we can install from and thus auto-pull the dependent 32 bit libraries? Thanks, ~Deepak -- Deepak Saxena - Kernel Working Group Lead Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 2 0/2] RFC: introduce arch_early_time for early boot timestamps
Idea is good though one note on this is that the DT binding is very Linux-specific and there is a move away from OS-specific bindings. You'll have to repost to a wider audience including the new DT binding maintainers to get their input. You also need to add the binding to Documentation/devicetree/bindings regardless of what the final binding is. ~Deepak On 9 August 2013 07:34, Andy Green andy.gr...@linaro.org wrote: The following patches extend accurate time much further back into the boot process by adding an optional arch_early_time source that starts counting about 1.75ms after the MMU is enabled. This exposes currently hidden kernel boot times exceeding 340ms for a 2GByte dual A9. Currently only Arm globaltimer is supported as the early time source. Where the globaltimer is and how to map it is configured by Device Tree as explained in the second patch. To get monotonic time in the kernel starting from before the normal time source can be initialized, the early time source offset is allowed to be added to scheduler clock time in the first patch. --- Andy Green (2): scheduler: time: allow arch-specific time offset function arm: time: add globaltimer-based arch_early_time arch/arm/Kconfig | 16 ++ arch/arm/Kconfig.debug | 10 arch/arm/boot/dts/mb8ac0300eb.dts | 10 +++- arch/arm/configs/fujitsu_defconfig |2 + arch/arm/include/asm/memory.h |8 +++ arch/arm/kernel/devtree.c |1 arch/arm/kernel/setup.c| 50 ++ arch/arm/kernel/time.c | 101 arch/arm/mach-mb8ac0300/Kconfig|3 + arch/arm/mm/mmu.c | 49 + include/linux/time.h |7 ++ kernel/sched/clock.c | 12 ++-- mm/Kconfig |2 - 13 files changed, 263 insertions(+), 8 deletions(-) -- ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev -- Deepak Saxena - Kernel Working Group Lead Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 0/7] uprobes: Add uprobes support to ARM
On 19 June 2013 20:32, Viresh Kumar viresh.ku...@linaro.org wrote: On 20 June 2013 00:41, David Long dave.l...@linaro.org wrote: This patch series adds basic uprobes support to ARM. It is based on patches developed earlier by Rabin Vincent. That approach of adding special cases into the kprobes instruction parsing code was not well received. This approach separates the ARM instruction parsing code in kprobes out into a separate set of functions which can be used by both kprobes and uprobes. Both kprobes and uprobes then provide their own semantic action tables to process the results of the parsing. Some regression bug fixing is still in progress on this, and some more definitions may be moved from kprobes*.h files into more generic include files. However, at this point feedback on the basic approach would be appreciated. These patches are based on v3.10-rc3 David A. Long (2): ARM: Separate kprobes instruction parsing into routines sharable with uprobes ARM: add uprobes support Please use linaro-kernel list for sending patches. Hi Viresh, I think linaro-kernel should be part of the cc, but I don't think that there is any policy in regards to not sending patches to linaro-dev. I see lots of patches being posted on here and think it is a good place for discussion. Thanks, ~Deepak -- Deepak Saxena - Kernel Working Group Lead Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Suggestion
On 16 April 2013 07:06, Jonathan Aquilina eagles051...@gmail.com wrote: Wouldnt all of them benefit in a way from it? My take on this is that one of the goals of Linaro's assignee process is to teach folks how to work in the open source community and than take that knowledge back to internal teams. This means we should use communication methods and tools that are native to the upstream communities we interact with and in the case of the kernel, this means that code review should be done via email lists. ~Deepak On Tue, Apr 16, 2013 at 4:04 PM, Nicolas Dechesne nicolas.deche...@linaro.org wrote: On Tue, Apr 16, 2013 at 3:59 PM, Jonathan Aquilina eagles051...@gmail.com wrote: Have you guys considered gerrit code review for patches? as well as setting up build bots to test build the patches? which projects at Linaro you have in mind for this request? it's already being used for Android 'stuff', see http://review.android.git.linaro.org/ -- Jonathan Aquilina ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev -- Deepak Saxena - Kernel Working Group Lead Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] [RFC]: mfd: Implement DT Support for AB8500 Btemp and fg
On 29 June 2012 12:44, Rajanikanth HV rajanikanth...@linaro.org wrote: thanks for your review comments, i will post it on public branch, Posting on a public branch once you have your git issues sorted is good, but we want the patches themselves posted on the relevant email lists. Please make the cleanups suggested and repost directly for upstream review and Lee and Arnd can directly comment on those lists. Rease Documentation/SubmittingPatches if you have not done so yet. Thanks, ~Deepak ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Making ARM multiplatform kernels DT-only?
On 3 May 2012 06:50, Arnd Bergmann a...@arndb.de wrote: Hi everyone, I've been discussing multiplatform kernels with a few people recently, and we will have a lot of discussion sessions about this at Linaro Connect in Hong Kong. One question that came up repeatedly is whether we should support all possible board files for each platform in a multiplatform kernel, or just the ones that are already using DT probing. I would like to get a quick poll of opinions on that and I've tried to put those people on Cc that would be most impacted by this, i.e. the maintainers for platforms that have both DT and non-DT board files at the moment. My feeling is that we should just mandate DT booting for multiplatform kernels, because it significantly reduces the combinatorial space at compile time, avoids a lot of legacy board files that we cannot test anyway, reduces the total kernel size and gives an incentive for people to move forward to DT with their existing boards. +1 I'm of the opinion that we support DT only platforms for multi-platform but this is based on the approach of only caring for multi-platform for newer systems and not worrying too much for legacy HW. I look at this from the perspective of how much return do we get on investing effort into making it possible for every platform to be built as part of consolidated zImage. I don't expect distros (the main users of a single zImage IMHO) to spend many cycles on older platforms and those of us who still have some of them sitting around to use are generally developers who are going to be doing a lot of builds anyways... ~Deepak ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: No group tracks at Connect
On 24 April 2012 03:22, David Rusling david.rusl...@linaro.org wrote: All, I've created and shared the Connection Sessions spreadsheet, you can find it here - https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AnK-Uyci_D20dFlUX1ZOVm5LWDVudkxJM1B0aS1FWWc#gid=0. Arwen is happy that that spreadsheet will be used for the session planning. I've added some topics and champions, please contact me to arrange more / discuss how best to organise things moving forward. If you want a hint, see what Amit's done... What are the responsibilities of the champion vs those of the session lead? ~Deepak ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: No group tracks at Connect
On 19 April 2012 12:58, Zach Pfeffer zach.pfef...@linaro.org wrote: On 19 April 2012 14:47, Deepak Saxena dsax...@linaro.org wrote: On 19 April 2012 12:15, Zach Pfeffer zach.pfef...@linaro.org wrote: On 19 April 2012 13:21, Deepak Saxena dsax...@linaro.org wrote: On 19 April 2012 08:53, Christian Robottom Reis k...@linaro.org wrote: On Wed, Apr 18, 2012 at 10:43:56AM -0500, Zach Pfeffer wrote: While we're planning for connect, I'd like to suggest that we do away with team tracks all together and just have topic tracks. This would align with our topic based approach to things now, and would be a way to breakdown our silo's. The topic track would be lead by a topic champion. What do people think? I ask myself whether in practice it makes a difference. In practice, at Connect, you want somebody to own a certain set of sessions. Splitting this by team or by topic seems to have equal drawbacks on either side. I'm not really sure if it makes a difference at the end of the day. Also, are we really talking about topic tracks or sessions here? W/o a CFP asking for externally developed presentations, I'm not sure we can end up with many talks about the same topics. We're planning on some training sessions for Linaro noobs and also for what I hope will be a large contingent of member engineers from China, India, and Korea offices. Should Training be a separate track? Also to clarify, regardless of whether we go down this path or not, we will still have time for hacking sessions? I think its actually makes the hacking sessions better. Why have team hacking rooms? We should have topic hacking rooms where each tiger team meets each other and starts to solve the problems they've talked about in the topic planning session. I dunno. I think a lot of the work we are doing in the groups does not directly overlap, and when it does (i.e, platform integration level) it's as easy as grabbing the right person. From my experience at prior connects, a lot of the decisions around common infrastructure happened in the hacking rooms where folks could gather around there computers and boards in a shared space. Spreading us across rooms by topic areas would loose that cohesiveness that I think is really key to the work that happens at Connect. I think some of that is just a reflection of our team track organization. Consider a common goal like: Unify all Kernels That's a big topic, but if Andrea Mathieu Lee Andy Green Tixy Vishal LAVA PoC Ubuntu PoC etc... Were all on the Unify all Kernels tiger team, they could use connect to hammer this out. The hacking rooms could then change mid week for other topic hacking sessions. OK, that makes sense. Another one would be Android + DT...get your team and the DT folks from KWG together for half a day to hash out anything that's needed. In essence these become extended summit sessions. We need to keep 1-2 rooms open for general hacking in this case for folks who may want to just go deep dive into an area they are working on. ~Deepak ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: No group tracks at Connect
On 19 April 2012 08:53, Christian Robottom Reis k...@linaro.org wrote: On Wed, Apr 18, 2012 at 10:43:56AM -0500, Zach Pfeffer wrote: While we're planning for connect, I'd like to suggest that we do away with team tracks all together and just have topic tracks. This would align with our topic based approach to things now, and would be a way to breakdown our silo's. The topic track would be lead by a topic champion. What do people think? I ask myself whether in practice it makes a difference. In practice, at Connect, you want somebody to own a certain set of sessions. Splitting this by team or by topic seems to have equal drawbacks on either side. I'm not really sure if it makes a difference at the end of the day. Also, are we really talking about topic tracks or sessions here? W/o a CFP asking for externally developed presentations, I'm not sure we can end up with many talks about the same topics. We're planning on some training sessions for Linaro noobs and also for what I hope will be a large contingent of member engineers from China, India, and Korea offices. Should Training be a separate track? Also to clarify, regardless of whether we go down this path or not, we will still have time for hacking sessions? ~Deepak ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: No group tracks at Connect
On 19 April 2012 12:15, Zach Pfeffer zach.pfef...@linaro.org wrote: On 19 April 2012 13:21, Deepak Saxena dsax...@linaro.org wrote: On 19 April 2012 08:53, Christian Robottom Reis k...@linaro.org wrote: On Wed, Apr 18, 2012 at 10:43:56AM -0500, Zach Pfeffer wrote: While we're planning for connect, I'd like to suggest that we do away with team tracks all together and just have topic tracks. This would align with our topic based approach to things now, and would be a way to breakdown our silo's. The topic track would be lead by a topic champion. What do people think? I ask myself whether in practice it makes a difference. In practice, at Connect, you want somebody to own a certain set of sessions. Splitting this by team or by topic seems to have equal drawbacks on either side. I'm not really sure if it makes a difference at the end of the day. Also, are we really talking about topic tracks or sessions here? W/o a CFP asking for externally developed presentations, I'm not sure we can end up with many talks about the same topics. We're planning on some training sessions for Linaro noobs and also for what I hope will be a large contingent of member engineers from China, India, and Korea offices. Should Training be a separate track? Also to clarify, regardless of whether we go down this path or not, we will still have time for hacking sessions? I think its actually makes the hacking sessions better. Why have team hacking rooms? We should have topic hacking rooms where each tiger team meets each other and starts to solve the problems they've talked about in the topic planning session. I dunno. I think a lot of the work we are doing in the groups does not directly overlap, and when it does (i.e, platform integration level) it's as easy as grabbing the right person. From my experience at prior connects, a lot of the decisions around common infrastructure happened in the hacking rooms where folks could gather around there computers and boards in a shared space. Spreading us across rooms by topic areas would loose that cohesiveness that I think is really key to the work that happens at Connect. ~Deepak ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[ACTIVITY] (Deepak Saxena) April 8 - 14
== Deepak Saxena dsaxena == === Highlights === * Completed reviews! * Worked with Kiko on Android Upstreaming patch tracking. Still have mixed feelings about whether every single patch needs to be tracked to help stay on top of deliverables but will give it a try, might get some ideas on different ways to do it. (http://goo.gl/QtPwS) * Started work on new roadmap cards, closing out existing cards * Worked on Upstreaming 101 slides (http://goo.gl/QtPwS) === Plans === * Hopefully close out on training deliverables from KWG for Hong Kong Connect * Work more on Upstreaming 101 slides * Continue to dig into patch tracking * Continue work on new roadmap cards * Dig out my timex.h patches if I have time === Issues === === Travel/Time Off === * Possibly out Monday, April 30th. * Off May 4th and following week, back to work on Monday the 13th. Will have no interwebs and limited phone access. * Connect Q2, possibly with follow up travel to Linux Con Japan the week before and trip to Austin to sync up with Mounir before. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Activity] (Omar Ramirez) Apr 2 - Apr 8
On 10 April 2012 17:01, Andy Green andy.gr...@linaro.org wrote:
On 04/11/2012 07:41 AM, Somebody in the thread at some point said:
On Tue, Apr 10, 2012 at 5:17 PM, Christian Robottom Reis
k...@linaro.org wrote:
On Mon, Apr 09, 2012 at 08:24:51PM -0500, Omar Ramirez Luna wrote:
== Omar Ramirez omarrmz ==
=== Highlights ===
* Working on device tree for mailbox:
Find a kernel that works with DT for pandaboard (OMAP4):
- k3.4-rc1 doesn't recognize DT blob, k3.3 DT panics at boot.
- DT has to be appended to zImage.
Find a DT uboot:
- secretlab.ca uboot doesn't have usb support for panda, having
problems with fatload and mmc.
- linaro uboot has problems recognizing dt blob in memory (bootm
${kern} - ${dtb}; doesn't work properly).
This is a bit unexpected -- is there really nobody currently booting
Panda using a DT?
The routine tests we do on each monthly release test for device tree
and this test has passed for panda for months now. That is the LT
kernel that may include some DT patches so maybe that explains this?
Right, LT kernels work fine with DT boot, we have done DT boot on OMAP4
since last Autumn. We still need to add at least this for a long time
http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git;a=commitdiff;h=e7f11e8c3a67ca73da27b33814307077ea73f6b5
This is from Dec and still not in mainline. Grant, Arnd, Rajendra, do
you know the reason why?
I don't know if that's all that's required.
Last week we tried v3.3 mainline and it dies in some problem about UART.
Have you tried 3.4-rc kernels?
Omar, you should look here
http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git;a=summary
use tilt-tracking and omap_5430evm_defconfig
That's workable on 4430, 4460 (and Omap5) with DT boot. We have a race
bug about mmc probe outstanding but we can't reproduce it at the moment.
Otherwise for 4460 it should be running on all cylinders.
Can someone on the LT, working with Omar, take some time to dig into what all
is needed to boot mainline with DT support? I'm a little surprised
too that it doesn't
just work out of the box. :/
~Deepak
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Which kernel should outside developers use?
On 4 April 2012 09:54, Chris Simmonds chris.simmo...@2net.co.uk wrote: On 04/04/12 11:53, Amit Kucheria wrote: On Wed, Apr 4, 2012 at 1:31 PM, Chris Simmonds chris.simmo...@2net.co.uk wrote: Hello, I am working on behalf of an SoC vendor and I am trying to work out which (if any) of the many git trees at http://git.linaro.org/gitweb we should Is this a new SoC (no mainline support) or an existing SoC? It's a new SoC which will have its own arch/arm/mach-xxx directory Ideally I would like a long term support Linaro kernel. Since that doesn't exist, one approach is use the linux-linaro-tracking tree but only use the linux-linaro-3.0* tagged versions so that we can easily merge in changes from v3.0 from kernel.org linux-stable. LTSI is something that is work in progress by the Linux Foundation. But that is directed towards products shipping with already enabled SoCs. I don't think it is a good tree to follow for new SoC enablement. LTSI is interesting and something that I would like to track. But it does not help me with core arm support. So my questions are 1. Is this a rational approach? IMHO, you should be developing against mainline, say the last released kernel 3.3, if tracking 3.4-rc is too much. And then ask for it to be merged via the arm-soc tree if you have no other sub-arch maintainer above you. It is not feasible to track the tip mainline release both because it eats up man power in the kernel team but even more so in the QA team. Probably looking at one kernel release per year, ideally based on the long term kernel, currently 3.0. When it comes to mainlining, is arm-soc the best way? There is no route via Linaro? 2. Is this how you imagine other projects interfacing with Linaro? Or should we really be waiting for Linaro code to be mainlined and pulling from kernel.org? If you need specific features from the Linaro tree, you should use git branches to track the tree and cherry-pick the bits that you do need. Can you give examples of things that you do need from the Linaro tree? Basically, everything in arch/arm/kernel, arch/arm/mm, etc. Right now the diff is mostly to do with device tree, which is interesting but not crucial. But the principle is that linux-linaro will have arm architecture support before mainline, no? We used to track the stable release of the kernel but are moving to tracking Linus' -rc tree and staying in sync with tip while merging in features that may not quite be ready fo upstream. Due to this, the deltas will be continuously changing For example, many of the Device Tree changes will get merged upstream but we will bring in other changes such as the Android upstream cleanups that may still be queued for the next merge window. Since we are now tracking -rc, I think it is OK to work against our tree for new SOCs, specially if you want to enable features that are not yet in mainline. At the same time, keep a topic branch around that has only changes against mainline to make it easier to get those upstream. Thanks, ~Deepak ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
February 2012 Kernel Release
The Linaro Kernel Working Group (KWG) and the Linaro Platform Group are excited to announce the availability our February 2012 development snapshot: linux-linaro-3.3-rc3-2012.02-1 As the word snapshot implies, these are meant as development kernels and have not been fully validated. You should expect issues and to help us deliver a better kernel in the future, please file bugs in Launchpad at https://bugs.launchpad.net/linux-linaro. We are excited about our first -rc based kernel as we move to a new process that will provide early access to more bleeding edge features on member-supported LEBs. The source tarball is available at: http://launchpad.net/linux-linaro/3.3/3.3-rc3-2012.02/+download/linux-linaro-3.3-rc3-2012.02-1.tar.bz2 The kernel sources can also be accessed using git at: git://git.linaro.org/people/ynk/linux-linaro-tracking.git tag: linux-linaro-3.3-rc3-2012.02-1 This kernel includes the following changes from the 2011.11 kernel: - Update to 3.3-rc3 - Various patches from Linaro * samsung_cpuidle_l2_retention patch set from the power management WG * thermal_cpu_cooling patch set from the power management WG * irq_domain patch set from Grant L. (cherry-picked from linux-next) * Fix for https://bugs.launchpad.net/bugs/918412 * Basic device tree board support for supported ARM boards (comes from linux-linaro-3.1) * sched: Ensure cpu_power periodic update (Vincent G.) * ARM: kprobes: work around build errors (Arnd B.) * usb: ehci: make HC see up-to-date qh/qtd descriptors ASAP (Ming L.) * Perf: Fallback to /bin/more if less is not found for perf pager (Avik S.) A full change log against the 3.3-rc3 release is available at: http://launchpad.net/linux-linaro/3.3/3.3-rc3-2012.02/+download/CHANGELOG-linux-linaro-3.3-rc3-2012.02-1 High Priority Known Issues: - None at this time Mailing list: http://lists.linaro.org/mailman/listinfo/linaro-dev Questions? https://ask.linaro.org/ ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
January 2012 Kernel Release
The Linaro Kernel Working Group (KWG) is excited to announce the availability our January 2012 development snapshot: linux-linaro-3.2-2021.01-0 As the word snapshot implies, these are meant as development kernels and have not been fully validated. You should expect issues and to help us deliver a better kernel in the future, please file bugs in Launchpad at https://bugs.launchpad.net/linux-linaro. This is our first kernel release run by Andrey Konovalov and I want to thank him for getting up and running in short time period and getting this release out the door. Andrey will be creating a 3.3 tracking branch soon and we can then start merging code from the other WGs and LTs to provide a common baseline for the 2012.02 release. The source tarball is available at: http://launchpad.net/linux-linaro/3.2/3.2-2012.01/+download/linux-linaro-3.2-2012.01-0.tar.bz2 The kernel sources can also be accessed using git at: git://git.linaro.org/people/ynk/linux-linaro-tracking.git tag: linux-linaro-3.2-2012.01-0 This kernel includes the following changes from the 2011.11 kernel: - Update to 3.2.1 stable kernel - Various patches from 3.3-rc1 and other trees: - Restart code cleanup (Russell King) - Config fragment support (John Stultz) - Pinctrl updates (Dong Aishang, Rajendra Nayak, Linus Walleij) - Thermal cpu cooling branch from PMWG (Amit Kacchap, Jaecheol Lee) - LPAE support (Catalin Marinas) - MULTI_IRQ_HANDLER support (Marc Zyngier) - ioremap() consolidation (Nicolas Pitre) A full change log against the 3.2.1 release is available at: http://launchpad.net/linux-linaro/3.2/3.2-2012.01/+download/CHANGELOG-linux-linaro-3.2-2012.01-0 High Priority Known Issues: - None at this time Mailing list: http://lists.linaro.org/mailman/listinfo/linaro-dev Questions? https://ask.linaro.org/ ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: perf fixes not present in Linaro kernel
On 15 December 2011 06:27, Nicolas Pitre nicolas.pi...@linaro.org wrote: On Thu, 15 Dec 2011, Nicolas Pitre wrote: On Thu, 15 Dec 2011, Will Deacon wrote: Rather than me point each landing team at the patches, would you be able to cherry-pick the fixes from mainline please? They are: bce34d14 (ARM: perf: initialise used_mask for fake PMU during validation) e5a21327 (ARM: perf: check that we have a platform device when reserving PMU) 6bd05409 (ARM: 7185/1: perf: don't assign platform_device on unsupported CPUs) Cherry-picked and pushed out. And tagged as linux-linaro-3.1-2011.12-1. thanks, I'll grab this and push out the release! ~Deepak ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Linaro Kernel December 2011 Release
The Linaro Kernel Working Group (KWG) is excited to announce the availability our December 2011 development snapshot: linux-linaro-3.1-2011.12-1 As the word snapshot implies, these are meant as development kernels and have not been fully validated. You should expect issues and to help us deliver a better kernel in the future, please file bugs in Launchpad at https://bugs.launchpad.net/linux-linaro. The source tarball is available at: http://launchpad.net/linux-linaro/3.1/3.1-2011.12/+download/linux-linaro-3.1-2011.12-1.tar.bz2 The kernel sources can also be accessed using git at: git://git.linaro.org/kernel/linux-linaro-3.1.git tag: linux-linaro-3.1-2011.12-1 This kernel includes the following changes from the 2011.11 kernel: - Update to 3.1.5 stable kernel - Inital thermal framework support (Amit Kacchap) - Updates to ARM perf support (Will Deacon) - Improvements to ARM OOM killer support (Kautuk Consul) A full change log against the 2011.11 release is available at: http://launchpad.net/linux-linaro/3.1/3.1-2011.12/+download/CHANGELOG-linux-linaro-3.1-2011.12-1 High Priority Known Issues: - None at this time Mailing list: http://lists.linaro.org/mailman/listinfo/linaro-dev Questions? https://ask.linaro.org/ ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Some more comments on CI loop interface
Hi Michael, I went to take a look at the kernel ci-loop page to see the build status of upstream builds and have a few new comments on the UIL 1) When there is a build failure, is it possible to have the build link go directly to the build results? It currently takes 3 clicks to get to the results from the main page and it may not be obvious to someone that the consoleText attachment is the correct link to use. 2) From the main ci-loop page, how do I get to a link for the RSS feed? Are the RSS feeds per-tree or per (tree + defconfig) combination? The later is preferred from the perspective of having upstream sub-arch maintainers who want to watch specific platforms. Thanks, ~Deepak ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: FYI: OpenID auth disabled on android-build.linaro.org
Thanks for this info Deepti. I'm assuming this is the same reason I had issues logging into the summit scheduler. ~Deepak On 31 October 2011 03:42, Deepti Kalakeri deepti.kalak...@linaro.org wrote: 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.sokolov...@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-andr...@linaro.org, Alexander Sack a...@linaro.org, Danilo Šegan danilo.se...@linaro.org, Infrastructure infrastruct...@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/Linaro http://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/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-kernel mailing list linaro-ker...@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-kernel ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Linaro Kernel September 2011 Release
The Linaro Kernel Working Group (KWG) is excited to announce the availability of our September 2011 development snapshot: linux-linaro-3.0-2011.09-0 As the word snapshot implies, these are meant as development kernels and have not been fully validated. You should expect issues and to help us deliver a better kernel in the future, please file bugs in Launchpad at https://bugs.launchpad.net/linux-linaro. The source tarball is available at: http://launchpad.net/linux-linaro/3.0/3.0-2011.09/+download/linux-linaro-3.0-2011.09-0.tar.bz2 The kernel sources can also be accessed using git at: git://git.linaro.org/kernel/linux-linaro-3.0.git tag: linux-linaro-3.0-2011.09-0 The changes since our 11.08 release include: - Update to 3.0.4 stable tree - Fix for https://bugs.launchpad.net/bugs/709245, a USB performance issue on Cortex A9 dual core systems. This release is light on changes as we don't feel that the 3.1-rc tree is ready to move to and we are moving towards a policy of no backporting except for critical bugs. A full changelog against linux-linaro-3.0-2011.09 is available at: http://launchpad.net/linux-linaro/3.0/3.0-2011.09/+download/CHANGELOG-linux-linaro-3.0-2011.09-0 High Priority Known Issues: - None at this time! Mailing list: http://lists.linaro.org/mailman/listinfo/linaro-dev Questions? https://ask.linaro.org/ ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Sept 14th struct_clk discussion meetings notes
A group of us met at Linux Plumber's Conf two weeks ago to discuss struct clk and how we move forward with it. Several of us had a follow up phone call last week, on Wed the 14th, and what follows are meeting notes from this follow up discussion (I've seem to have lost the notepad on which I took notes during the LPC discussion). Attendees: Arnd Bergman Stephen Boyd Mark Brown Thomas Gleixner Shawn Guo Saravana Kannan Nicolas Pitre Mike Turquette Linus Walleij Paul Walmsley - Mike T. - Remove set_parent and upstream clock arbitration - Functionality is limited, but would work for OMAP as is - We can add new features as needed - Shawn - Does not want to block new SoC support due to common clock support not being ready. This is gating mx6 support being merged upstream. - Arnd - Pre-req: Device Tree representation of struct clk before we let these patches in. - Mike T: Can we split the problems. - Arnd: Yes? - Thomas: Is not entirely separate. Current patches are not enough to do actual representation of building blocks. Need more than just the ops pointer structure. Will look into what it would take the current patches and then slowly add changes to building block. - Stephen - Want 1 tree lock instead of a framework lock: + Have 2 trees, 1 fast (1ms), 1 really slow (5ms) - Thomas: Should be trivial to implement - Once the traverse code is fixed, will be hard to change the locking code, so need to get this right. - Thomas: Need a clock tree base with its own lock and put a struct clk tree into that tree base. - Paul W.: How rate propagation would work across bases? - Thomas: Should be doable with proper locking order, and should not be too hard to solve. Non fast path. - Can implement separate root clocks for right now - tglx: separate struct clk from building block devices such as frequency management. - Paul W. - Have multiple root clocks, but only one lock right now - Figure out the scope of the patches to be. Goal: get basic support for common struct clk upstream. Get imx6 upstream w/o common struct clk Has some bugs and races on existing code. set_rate: Can parents be switched at same time? operate under set_rate and set_parent as distinct operations. clk_rate sample implementation: will only work in some limited cases. Need to guarantee that clock is stable. There are lot of hw specific that may not be possible to abstract. Not true: All parents are equal and should be treated the same during set_rate. From tglx: Looked at existing stuff and noted that a lot of implementations share concepts... walking a freq table or a divisor table. Paul: Agree, can go into some sort of library code down the road. in-tree vs out-of-tree: what's shipping on most device is quite a bit more hacky and complex than what is currently in mainline. Will need clock notifiers before being able to use on real shipping devices. Much code that calls clk_set_rate() assumes that code will not be changed in the future. Patch 1: good Patch 2: needs a bit more thought Patch 3: no comments yet What do people think about having initial patches to convert to using common clk struct but having sub-arch specific set_rate and get_rate? General consensus: seems like a good idea. - Linus W.: No major comments - Nicolas: Just listening in to understand the issues involved. ACTION ITEMS: - Thomas: will post updated patches by end of the week - Others: Will post initial patches porting their platforms to new patches as follow up. - Deepak: Organize follow up call in two weeks and post to wider audience to attend. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Sept 14th struct_clk discussion meetings notes
[Resend with update of l-a-k address in my alias to the correct one on infradead]. A group of us met at Linux Plumber's Conf two weeks ago to discuss struct clk and how we move forward with it. Several of us had a follow up phone call last week, on Wed the 14th, and what follows are meeting notes from this follow up discussion (I've seem to have lost the notepad on which I took notes during the LPC discussion). Attendees: Arnd Bergman Stephen Boyd Mark Brown Thomas Gleixner Shawn Guo Saravana Kannan Nicolas Pitre Mike Turquette Linus Walleij Paul Walmsley - Mike T. - Remove set_parent and upstream clock arbitration - Functionality is limited, but would work for OMAP as is - We can add new features as needed - Shawn - Does not want to block new SoC support due to common clock support not being ready. This is gating mx6 support being merged upstream. - Arnd - Pre-req: Device Tree representation of struct clk before we let these patches in. - Mike T: Can we split the problems. - Arnd: Yes? - Thomas: Is not entirely separate. Current patches are not enough to do actual representation of building blocks. Need more than just the ops pointer structure. Will look into what it would take the current patches and then slowly add changes to building block. - Stephen - Want 1 tree lock instead of a framework lock: + Have 2 trees, 1 fast (1ms), 1 really slow (5ms) - Thomas: Should be trivial to implement - Once the traverse code is fixed, will be hard to change the locking code, so need to get this right. - Thomas: Need a clock tree base with its own lock and put a struct clk tree into that tree base. - Paul W.: How rate propagation would work across bases? - Thomas: Should be doable with proper locking order, and should not be too hard to solve. Non fast path. - Can implement separate root clocks for right now - tglx: separate struct clk from building block devices such as frequency management. - Paul W. - Have multiple root clocks, but only one lock right now - Figure out the scope of the patches to be. Goal: get basic support for common struct clk upstream. Get imx6 upstream w/o common struct clk Has some bugs and races on existing code. set_rate: Can parents be switched at same time? operate under set_rate and set_parent as distinct operations. clk_rate sample implementation: will only work in some limited cases. Need to guarantee that clock is stable. There are lot of hw specific that may not be possible to abstract. Not true: All parents are equal and should be treated the same during set_rate. From tglx: Looked at existing stuff and noted that a lot of implementations share concepts... walking a freq table or a divisor table. Paul: Agree, can go into some sort of library code down the road. in-tree vs out-of-tree: what's shipping on most device is quite a bit more hacky and complex than what is currently in mainline. Will need clock notifiers before being able to use on real shipping devices. Much code that calls clk_set_rate() assumes that code will not be changed in the future. Patch 1: good Patch 2: needs a bit more thought Patch 3: no comments yet What do people think about having initial patches to convert to using common clk struct but having sub-arch specific set_rate and get_rate? General consensus: seems like a good idea. - Linus W.: No major comments - Nicolas: Just listening in to understand the issues involved. ACTION ITEMS: - Thomas: will post updated patches by end of the week - Others: Will post initial patches porting their platforms to new patches as follow up. - Deepak: Organize follow up call in two weeks and post to wider audience to attend. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] ARM: EXYNOS4: Add HDMI support for Origen
Will this patch and the patch Tushar just posted apply
cleanly with each other? You are both touching mach-origen.c,
changing origen_devices, and adding support for video output
so it might be good in a future situations such as this to
post as one patch series with both of your sign-offs.
Thanks,
~Deepak
On 7 September 2011 03:54, Sachin Kamat sachin.ka...@linaro.org wrote:
This patch adds HDMI (TVout) support for Origen board.
This patch is based on for-next branch of Kukjin Kim's tree:
http://git.kernel.org/?p=linux/kernel/git/kgene/linux-samsung.git;a=summary
This patch is tested using Hatim's patch:
http://www.spinics.net/lists/linux-samsung-soc/msg06367.html
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
arch/arm/mach-exynos4/Kconfig | 2 ++
arch/arm/mach-exynos4/mach-origen.c | 4
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
index 181fb04..4f908f7 100644
--- a/arch/arm/mach-exynos4/Kconfig
+++ b/arch/arm/mach-exynos4/Kconfig
@@ -225,6 +225,8 @@ config MACH_ORIGEN
select S3C_DEV_WDT
select S3C_DEV_HSMMC2
select EXYNOS4_SETUP_SDHCI
+ select S5P_DEV_I2C_HDMIPHY
+ select S5P_DEV_TV
help
Machine support for ORIGEN based on Samsung EXYNOS4210
diff --git a/arch/arm/mach-exynos4/mach-origen.c
b/arch/arm/mach-exynos4/mach-origen.c
index ed59f86..6ec68ee 100644
--- a/arch/arm/mach-exynos4/mach-origen.c
+++ b/arch/arm/mach-exynos4/mach-origen.c
@@ -81,8 +81,11 @@ static struct s3c_sdhci_platdata origen_hsmmc2_pdata
__initdata = {
static struct platform_device *origen_devices[] __initdata = {
s3c_device_hsmmc2,
+ s5p_device_i2c_hdmiphy,
s3c_device_rtc,
s3c_device_wdt,
+ s5p_device_hdmi,
+ s5p_device_mixer,
};
static void __init origen_map_io(void)
@@ -95,6 +98,7 @@ static void __init origen_map_io(void)
static void __init origen_machine_init(void)
{
s3c_sdhci2_set_platdata(origen_hsmmc2_pdata);
+ s5p_i2c_hdmiphy_set_platdata(NULL);
platform_add_devices(origen_devices, ARRAY_SIZE(origen_devices));
}
--
1.7.4.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Linaro Kernel August 2011 Release
The Linaro Kernel Working Group (KWG) is excited to announce the availability of our August 2011 development snapshot: linux-linaro-3.0-2011.08-0 As the word snapshot implies, these are meant as development kernels and have not been fully validated. You should expect issues and to help us deliver a better kernel in the future, please file bugs in Launchpad at https://bugs.launchpad.net/linux-linaro. The source tarball is available at: http://launchpad.net/linux-linaro/3.0/3.0-2011.08/+download/linux-linaro-3.0-2011.08-0.tar.bz2 The kernel sources can also be accessed using git at: git://git.linaro.org/kernel/linux-linaro-3.0.git tag: linux-linaro-3.0-2011.08-0 The changes since our 11.07 release include: - Update to 3.0.3 stable tree - Initial support for Samsung ORIGEN platform - Updates from Russell King's 3.1 fixes branch A full changelog against linux-linaro-3.0-2011.07 is available at: http://launchpad.net/linux-linaro/3.0/3.0-2011.08/+download/CHANGELOG-linux-linaro-3.0-2011.08-0 High Priority Known Issues: - None at this time! Mailing list: http://lists.linaro.org/mailman/listinfo/linaro-dev Questions? https://ask.linaro.org/ ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Linaro Connect - Kernel Working Group Summary
Hi all, I wanted to provide an update of what the kernel team accomplished at Linaro Connect last week for those who were unable to attend. The team was split into two main groups, the first being led by Grant Likely and focusing on continuing the work on enabling Device Tree support on ARM platforms. In addition to Linaro members, David Brown and Nicolas Ferre also worked on DT support for their platforms and all together the team got much accomplished in 5 days there with a number of patches ready for the 3.2 merge windows: * Several device drivers for the Freescale iMX were converted to use DT-base discovery. * Code was written to bridge between the Device Tree model and TI OMAP's HWMOD. * Initial support for DT was added to the Samsung Exynos, Qualcomm MSM86, and Atmel AT91 by Nicolas Ferre * DT skeleton code was written for the ARM Versatile and ST-E platforms. The rest of the team primarilly focused on code cleanup and development to work towards a multi-SOC zImage. Nicolas posted and original email with info at http://bit.ly/oVQRQm and folks took individual bits to work on. Russel King was also in attendance and there was good discussion around some of these topics. What we discovered is that many of these issues are multi-layered and as we start cleaning up one bit of code, we need to fix other areas to make them work consistently. The areas we looked into were: * Replacing low level IO accessor macros with runtime selected functions based on platform type. * Replacing the global NR_IRQS constant with per-board information * Removing duplicated low-level serial output functions. Currently the code to print Uncompressing kernel... and the code for low-level in-kernel serial output are completely different but could be made to be the same. At the end of the day, the method we're looking at using is providing a special node in the DT that contains the physical mapping of the debug serial registers in place. * Removing CLOCK_TICK_RATE from the kernel * Replace CONSISTENT_DMA_SIZE with a runtime variable * Removing arch_idle() and moving to using the run time selected pm_idle hooks. Similar work to be done with arch_reset() * Getting rid of VMALLOC_END. Russel and Nicolas agreed that we'll just use a static VMALLOC_END for everyone and insert static I/O mappings in there. In addition the the above work, KWG members also were involved in discussions about continuous integration and testing of the upstream kernels on ARM platforms, kernel development process at Linaro and how to better stay in sync with upstream, -stable patches for ARM platforms, Android development, and flash storage roadmap to name a few. Overall, the team had an extremely productive week of hacking on existing projects and on coming up with more detailed plans on what other items on which we need to focus. I want to thank everone on the team for their hard work last week and also the non-Linaro developers David Brown, Will Deacon, Nicolas Ferre, and Marc Zyngier for taking time to join us in hacking and planning. All together connect was a great technically focused event and I highly encourage folks to join us in Orlando in November. You can register now at http://connect.linaro.org/events/event/linaro-connect-q411/. Thanks, ~Deepak ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Single zImage at Linaro Connect
On 5 August 2011 14:40, Rob Herring robherri...@gmail.com wrote: Deepak, Nicolas, On 07/27/2011 09:58 PM, Nicolas Pitre wrote: To everyone, and especially to those who are expected to work on this topic next week, please find below a list of tasks that needs to be investigated and/or accomplished. I'll coordinate the work and collect patches for the team. If you have comments on this, or if you know about some omissions, please feel free to provide them as a reply to this message. I'd like to know if people are particularly interested in one (or more :-)) items they would like to work on. If so please say so as well. Are you going to publish a summary of the week? For example, are there any refinements to this list in terms of additional items or approach on how to fix. Who is working each item and which ones need help? Hi Rob, I have a bunch of meeting notes that I'm translating into a high-level blog post for the Linaro site and I'll do a more technical summary and send it in email, including a breakdown of who's doing what.. Nicolas is out on vacation this week but once he's back we'll go through and re-factor the existing list. ~Deepak ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: The Linaro-3.0 kernel branch is now open
On 21 July 2011 15:08, john stultz johns...@us.ibm.com wrote: On Mon, 2011-07-18 at 22:57 -0400, Nicolas Pitre wrote: Please let me know if you want to see something merged into the linaro-3.0 tree before Thursday. So I'm working on merging this into the Android tree and something in your tree is causing Pandaboard to hang very early at boot: Starting kernel ... Uncompressing Linux... done, booting the kernel. ... And that's all. I rolled back to just your tree and got the same thing (the vanilla Android 3.0 branch still works fine). Attached is the config I was testing with. I'll be trying to debug and bisect this down further, but has anyone else been testing the Linaro kernel on Panda? Didn't we see the same lack of console at boot up last month? :/ Does stock defconfig bootup? ~Deepak ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: The Linaro-3.0 kernel branch is now open
On 21 July 2011 16:47, john stultz johns...@us.ibm.com wrote: On Thu, 2011-07-21 at 16:34 -0700, john stultz wrote: On Thu, 2011-07-21 at 15:18 -0700, Deepak Saxena wrote: On 21 July 2011 15:08, john stultz johns...@us.ibm.com wrote: On Mon, 2011-07-18 at 22:57 -0400, Nicolas Pitre wrote: Please let me know if you want to see something merged into the linaro-3.0 tree before Thursday. So I'm working on merging this into the Android tree and something in your tree is causing Pandaboard to hang very early at boot: Starting kernel ... Uncompressing Linux... done, booting the kernel. ... And that's all. I rolled back to just your tree and got the same thing (the vanilla Android 3.0 branch still works fine). [snip] Bisecting narrowed it down to: af496a67c101b2161a12c1bc70626f6a479501bb Arnd: Maybe something went badly with the merge collision resolution there? And frustratingly, since its a merge commit, I can't just revert that one commit. Is anyone else testing Nico's tree (or even the ARM-SOC tree) with PandaBoard? According to the following from today, the merge should not have happened in the first place. Nico, do you need to rebase/merge with latest arm-soc/for-next tree? http://lists.infradead.org/pipermail/linux-arm-kernel/2011-July/058255.html ~Deepak ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Consistent names for Linaro kernel trees and releases
On 8 July 2011 12:50, john stultz johns...@us.ibm.com wrote: On Fri, 2011-07-08 at 12:35 -0700, Deepak Saxena wrote: On 1 July 2011 12:14, Deepak Saxena dsax...@linaro.org wrote: Each of the trees have various tags and branches based on how each team and developer works and I don't want to ask folks to change what they are doing for their day to work. What I'd like to see is a a separate set of official trees that only get updated with bits that we are ready for non-Linaro developers to use, do not get rebased, and get tagged at the end of each monthly cycle. My proposal: kernel/linux-linaro-$version with tags for each monthly release: v$version-$milestone-$buildcount So tag wise, since its a source release, by build count you mean more like drop number or something? Yes, so if we release a tarball and two days later we update it due to a critical bug, we'd increase the buildcount. So a concrete example would be: v2.6.39-11.06.4 kernel/linux-linaro-android-$version with tags for each monthly release: android-v$version-$milestone-$buildcount android-v2.6.39-11.06.4 ? The catch here is there may be multiple android drops for one linaro drop. So it would seem: v2.6.39-11.06.4-android-2 Or v$version-$milestone-$buildcount-android-$androidbuildcount Yep, that makes sense. ~Deepak ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Consistent names for Linaro kernel trees and releases
On 1 July 2011 12:21, Andy Green andy.gr...@linaro.org wrote: On 07/01/2011 08:14 PM, Somebody in the thread at some point said: What I'd like to see is a a separate set of official trees that only get updated with bits that we are ready for non-Linaro developers to use, do not get rebased, and get tagged at the end of each monthly cycle. My proposal: kernel/linux-linaro-$version with tags for each monthly release: v$version-$milestone-$buildcount kernel/linux-linaro-android-$version with tags for each monthly release: android-v$version-$milestone-$buildcount kernel/$soc/linux-linaro-$version with tags for each monthly release: $bsp-v$version-$milestone-$buildcount kernel/$soc/linux-linaro-android-$version with tags for each monthly release: $bsp-android-v$version-$milestone-$buildcount Comments? It would be less ridiculous than issuing monthly tarballs for the kernel case. We'd still release tarballs with this naming scheme, it would just be that the git tree locations would be consistent across all LTs. ~Deepak ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Consistent names for Linaro kernel trees and releases
Hi all,
I was looking at git.linaro.org and I'd like to propose some consistency
in naming our git trees and in how we branch them. The main reason
for this from my perspective is to make it easy to point someone
from a partner team or from a partner''s customer to the git server and
have them quickly figure out what they need to pull. Right now we have:
Generic Linaro Kernels:
kernel/linux-linaro-${version}
Freescale:
bsp/freescale/linux-2.6-imx.git
bsp/freescale/linux-linaro-natty.git
bsp/freescale/linux-meta-linaro-natty.git
bsp/freescale/mx5-gpu.git
bsp/freescale/mx5-vpu.git
bsp/freescale/u-boot-linaro-natty.git
Samsung:
bsp/samsung/linux-linaro-2.6.39.git
bsp/samsung/u-boot-insignal-dev.git
bsp/samsung/u-boot.git
ST-E:
bsp/st-ericsson/firmware-ux500.git
bsp/st-ericsson/linux-2.6.34-ux500.git
bsp/st-ericsson/linux-2.6.35-ux500.git
bsp/st-ericsson/linux-2.6.38-snowball.git
bsp/st-ericsson/linux-2.6.38-ux500.git
bsp/st-ericsson/u-boot-ux500.git
TI:
people/andygreen/kernel-tilt.git
Each of the trees have various tags and branches based on how each
team and developer
works and I don't want to ask folks to change what they are doing for
their day to work.
What I'd like to see is a a separate set of official trees that only
get updated with bits that
we are ready for non-Linaro developers to use, do not get rebased, and
get tagged at the
end of each monthly cycle. My proposal:
kernel/linux-linaro-$version with tags for each monthly release:
v$version-$milestone-$buildcount
kernel/linux-linaro-android-$version with tags for each monthly
release: android-v$version-$milestone-$buildcount
kernel/$soc/linux-linaro-$version with tags for each monthly release:
$bsp-v$version-$milestone-$buildcount
kernel/$soc/linux-linaro-android-$version with tags for each monthly
release: $bsp-android-v$version-$milestone-$buildcount
Comments?
~Deepak
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Linaro Kernel 11.06 Snapshot
The Linaro Kernel Working Group (KWG) is excited to announce the availability our June 2011 development snapshot: linux-linaro-2.6.39-2011.06-0 As the word snapshot implies, these are meant as development kernels and have not been fully validated. You should expect issues and to help us deliver a better kernel in the future, please file bugs in Launchpad at https://bugs.launchpad.net/linux-linaro. The source tarball is available at: http://launchpad.net/linux-linaro/2.6.39/2.6.39-2011.06/+download/linux-linaro-2.6.39-2011.06-0.tar.bz2 The kernel sources can also be accessed using git at: git://git.linaro.org/kernel/linux-linaro-2.6.39.git tag: linux-linaro-2.6.39-2011.06-0 This snapshot is based on the 2.6.39.1 stable kernel with a number of changes developed by Linaro and integrated from the 3.0-rc. The changes since our 11.05 release, other than what is already in 2.6.39 include: * Fixed LP #754254: imx51 randomly truncates serial input at 31 characters * Ability to append Device Tree to zImage at build time * Support for parallel async MMC requests * Common MMIO clocksource infrastructure * Moving of various drivers out of arch/arm into drivers/ A full changelog against 2.6.39.1 is available at: http://launchpad.net/linux-linaro/2.6.39/2.6.39-2011.06/+download/linux-linaro-2.6.39-2011.06-0.tar.bz2 High Priority Known Issues: * Only half of RAM useable when using Device Tree on Panda board (LP #707047) Mailing list: http://lists.linaro.org/mailman/listinfo/linaro-dev Questions? https://ask.linaro.org/ ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: TI LT 3.0 Tracking branches
On 23 June 2011 08:51, Andy Green andy.gr...@linaro.org wrote: Hi - I mentioned this already to npitre but for various reasons we are planning to target 3.0 kernel rather than linux-linaro-2.6.39 at the moment. 2.6.39 has some known issues like no onboard audio or HDMI audio, but since 3.0 has a new and better ALSA implementation for Panda I'm not sure it's worth spending time on when the old implementation won't really go into linux-linaro even if we did forward-port it again. What does this mean for the 11.06 OMAP Android release? Will it use your 3.0 kernel or will it use 2.6.35 again? I introduced two new branches yesterday: http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git;a=shortlog;h=refs/heads/tilt-tracking - omap4_defconfig http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git;a=shortlog;h=refs/heads/tilt-tracking-android - android_omap4_defconfig that are linus' HEAD and common-3.0 (androidized nearly linus HEAD) based and have the API v4403 SGX stuff on them. How hard is it to just grab the OMAP-specific patches from 3.0-rclatestand move them to 2.6.39? The status is currently on linus HEAD, Panda EHCI is broken which is a bit of a downer; Jassi is taking a look at it. Also video is coming up nicely with 1080p raster, but it is stuck at 640 x 480 framebuffer viewport inside that right now. Is this something that upstream is also aware of and tracking? ~Deepak ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: TI LT 3.0 Tracking branches
On 23 June 2011 11:39, Nicolas Pitre nicolas.pi...@linaro.org wrote: On Thu, 23 Jun 2011, Andy Green wrote: When linux-linaro-3.0 is coming in the next weeks, we will use that as a base instead as before. The base will be just as good as the contributions made by people to it. And besides a few notable exceptions such as yours, I didn't get much from people in terms of patches and/or pull requests. I'm seriously starting to question the usefulness of the Linaro kernel tree in fact. For one year that I've been putting such a tree together, the feedback and response have been less than overwhelming. The idea was to _consolidate_ the work that the various groups within Linaro was producing into a single and coherent whole without screwing up the other groups' work, but so far this hasn't been a great success for various reasons. - Is solving the ARM fragmentation problem still a Linaro priority? From my POV, this is definitely a yes. - Is the Linaro kernel effective for this? This I am not 100% sure about. I've seen quite a bit of activity on linux-arm-kernel after LDS with folks moving drivers out of arch/arm and I am beginning to see DT work being posted upstream. How much of that work is being send directly to you vs you having to stay on top of various changes in the community and pull those in proactively or as in the case of the ALSA issues, reactively? In other words, how much of your time is spent on keeping up with all the changes you need to pull into the Linaro kernel? This kernel is useful as place to test patches that are headed upstream in a single tree but unless all the LTs are using it as their base and are sending you patches on a regular basis, I do wonder if you're spending cycles on this tree that could be used on more core consolidation work. Half a year ago when I did ask for comments about the usefulness of the linaro-next tree, I got almost no responses as I suspected, and I therefore dropped that tree to concentrate my efforts on the Linaro stable branches. If even the stable branch doesn't steer more interest than it does now then this effort is just wasted. Either our process is to blame, our priorities are wrong, or some efforts are diverted where they shouldn't. One reason for the Linaro tree was to help LTs moving ahead rather than sticking to ancient kernels. Now it seems that everyone wants to get ahead of the actual latest release from kernel.org which is a radical shift. Does this mean that vendors and co now are getting used to the upstream pace and they're going to move to a rebasing workflow for real, or they're just fooled by the marketing prospects of a meaningless major kernel version bump? If the former that would be wonderful and maybe the Linaro kernel outlived its usefulness. If the later... well... what can I say here? I don't know that we're hearing that all vendor trees want to be on the latest kernel. What I'm reading from Andy's perspective is that it is easier to just work directly against upstream changes that to try and figure out what all changes need to be picked into 2.6.39.. From ST-E's landing team perspective, by the time they start on their work, it will be time for a 3.x tree. In any case that doesn't make a strong case for the Linaro kernel. We could as well just patch the latest Ubuntu kernel, the latest Android kernel, or whatever existing distro or vendor kernel, in order to showcase the Linaro initiated work and results. In practice that's what I see people doing right now anyway. Pushing that work into mainline is what matters the most in the end, and _that_ should always be Linaro's top priority. +1 I don't think it makes sense to have a Linaro-only tree for the sake of having a place to showcase Linaro's work. We don't want to be different from a kernel POV in my opinion. Our goal is to fix the kernel upstream, improve performance, consolidate architectures, help vendors cleanup their code. If we want to show case work, there are other ways to do it including just collating commit messages and providing high level summaries of work being done. I don't feel compelled to fight for the survival of the Linaro kernel either if it is not widely used and significantly useful. I'm more effective fighting with mainline kernel people: it is much more interesting and useful with lasting results. My opinion is that if there are no patches coming in from within Linaro and all of the work you are doing is to simply integrate patches that are already upstream-bound, then we should just kill the Linaro tree and focus 100% on an upstream. Instead of having a Linaro-branded kernel, could we just have a branch in the arm-soc tree that is a consolidation branch and is widely used beyond just Linaro builds and that acts as a more public and upstream arm-next tree? ~Deepak ___ linaro-dev mailing list linaro-dev@lists.linaro.org
Re: The Linaro monthly release cycle
On 14 June 2011 15:16, Mounir Bsaibes mounir.bsai...@linaro.org wrote: Nico, Is there any dependency on the Toolchain WG? Does the latest kernel have to be built using the latest Toolchain release? Good question. As we get the CI loop going, I imagine that we'll want the kernel building with multiple tool chains that the WG releases but for now I think the right answer is probably for Nicolas and others to use the latest Linaro toolchain for their manual testing. Does the kernel have to boot under the latest QEMU release? I would say ideally yes if we have a proper defconfig for the platform under emulation. Again, I think this is something that is more important as we start automating testing. ~Deepak ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: The linaro-2.6.39 kernel repository is now alive
On 2 June 2011 19:01, Zach Pfeffer zach.pfef...@linaro.org wrote: On 2 June 2011 18:55, Nicolas Pitre nicolas.pi...@linaro.org wrote: On Thu, 2 Jun 2011, John Rigby wrote: I noticed all the fine AndyDoan/Ricardo fixes that make panda wonderful are missing. My question now is should that stuff go back in or should we plan on a LT/BSP kernel for full functionality. I presume if those patches were headed upstream they would be headed upstream:). If not they they should not be in linux-linaro. This is the strategy of this game. If it isn't going upstream you lose. First, please don't take offense to this feedback. I know kernel banter can have a harsh undertone. I'd like to suggest this kind of feedback isn't appropriate. The issues concerning what can't be upstreamed are well known I think the issues are well known but if developers are not working on cleaning up the code to make it upstreamable, we have to continue to push back and provide them whatever guidance is needed on how to make it acceptable until they get it upstream. Until it is upstream, the developers of out-of-tree code need to be 100% responsible for rebasing and moving their code forward to newer kernels or there's no motivation for developers to change their ways. By they I don't mean to single out Andy/Ricardo in anyway, this applies to anyone developing code that is meant to go into the linaro-linux base kernel. ~Deepak ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: What do we want our hwpack sources
On 1 June 2011 11:41, Christian Robottom Reis k...@linaro.org wrote: I seem to be hung up on having a way of saying this hardware pack's kernel was built from this git tree with this config, so I wanted to explore the use cases a bit more: - My #1 use case is, once I've installed a hardware pack, running into a problem and then being able to verify whether it contains a certain patch or was built with a certain config option. I'd like to know that because it's the first thing the KWG and LT people ask me when I go to report the bug. This problem could be easily solved with git:: All official Linaro builds are generated from a single git tree that has branches for different kernel versions that we build from being automatically updated during the build process. The git rev is embedded in the kernel package name (linaro-linux-githash-...) and also in the kernel uname so that it is immediately obvious what tree and set of patches it come from and the KWG or LT can go fix the issue in their private trees that then get pulled into the main git tree. We can also tag the git tree during a build and embed that into the kernel uname. Zach suggested SPDX (as in spdx.org) as a solution to this problem; I'm not sure I understand enough about it (Loïc's provided a sample file at http://spdx.org/wiki/sample-partial-spdx-file-geronimo) but here's my strawman proposal of what data we should give people quick access to: Quick look at it and to me it seems a bit heavy for just having a way to find out what's in the kernel. If we want to carry other information than that than it would be good to have all the meta-data in one place such as the SPDX file. - What kernel tree it was built from (A URL to the git tree) - What revision (A revision ID) - What patches were applied on top of it (A URL to the patchset, maybe?) By patchset do you mean broken out patches as in a quilt stack or a changelog of the patches? If someone has the git url and git revision, they inherently know what patches are in the kernel. - What kernel config was used to build it (A separate file in the hwpack directory?) Do we have a repo where we store these? We probably want something similar to the kernel with an official repo used for build purposes that can be tagged at with the same tag as the kernel builds. Thanks, ~Deepak ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: What do we want our hwpack sources
On 1 June 2011 12:58, Christian Robottom Reis k...@linaro.org wrote: On Wed, Jun 01, 2011 at 12:51:12PM -0700, Deepak Saxena wrote: All official Linaro builds are generated from a single git tree that has branches for different kernel versions that we build from being automatically updated during the build process. The git rev is embedded in the kernel package name (linaro-linux-githash-...) and also in the kernel uname so that it is immediately obvious what tree and set of patches it come from and the KWG or LT can go fix the issue in their private trees that then get pulled into the main git tree. We can also tag the git tree during a build and embed that into the kernel uname. So your suggestion is that we have a tree to which we commit the result of the kernel source package build process? It's an interesting one; I'd like to know if this (or an approximation of it) is feasible. No, not a tree of packaged kernels. I meant a single git tree that consolidates all the kernel source trees that we possibly build from to provide a single location where developers can grab any kernel we've used for builds. This would also facilitate easy diffing between kernel versions. And thinking about it, John should already have this tree somewhere, right? - What kernel tree it was built from (A URL to the git tree) - What revision (A revision ID) - What patches were applied on top of it (A URL to the patchset, maybe?) By patchset do you mean broken out patches as in a quilt stack or a changelog of the patches? If someone has the git url and git revision, they inherently know what patches are in the kernel. I was referring to the fact that for a source package (such as what we build the hwpacks out of) we have a base plus a set of patches which may not live in any tree. But answering the question above will probably answer this one too. What's an example of such a set of patches? ~Deepak ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC] Kernel WG Slides for Public Plan Review, Draft 1
On 30 May 2011 08:48, Zach Pfeffer zach.pfef...@linaro.org wrote: On 27 May 2011 11:45, Deepak Saxena dsax...@linaro.org wrote: On 26 May 2011 20:17, Zach Pfeffer zach.pfef...@linaro.org wrote: My only comment is on: What We're Not Doing Integrating graphics drivers ● Handled by vendor Landing Team I think aspects of this will need to be handled by the kernel team. Especially with the work Jesse and the MM summit are proposing. Hi Zach, Clarification on the above point is that we will not be handling integrating binary blobs for the different SOCs. Any work that Jesse's team and upstream developers do on consolidating towards a single buffer management solution will certainly be integrated into the linaro-linux tree as it starts stabilizing. We're going to need to chat about that. I'll need support for binary blob integration from all teams. Overall I'm asking for each team (Landing Teams included) to: I agree that we need to talk about it. :) What I'd like to see is clearly identified ownership of who does different integration tasks and I still think that the integration of the binary graphics drivers needs to be handled by the landing teams who then feed into the Android builds. What you're proposing is a parallel model where every group is testing independently and then we throw everything together. What I'm proposing is a linear model where one group feeds their output to another group to add their patches on top and to test against Android at each merge step. KWG provides a linaro-linux + Android kernel to the landing teams who then merge their non-upstream patches and then feed that to the platform team. It is unclear to me who manages merging all the bits together in the the parallel model of each team testing separately against Android and then throwing the bits together. I'm reading your email as that being the KWGs responsibility but I'm don't think that we have the cycles to handle integration and testing of closed source drivers into our tree w/o having to drop some of our technology enablement tasks for 11.11. ~Deepak ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[Announce] Linaro Kernel 2011.05-2.6.38 Snapshot Released
The Linaro Kernel Working Group (KWG) is excited to announce the availability our May 2011 development snapshot: linux-linaro-11.05-2.6.38 This is the first of a new monthly series of development snapshots from the KWG that will provide a way for developers to work with the Linaro kernels without needing to follow the git tree on a daily basis. As the word snapshot implies, these are meant as development kernels and have not been fully validated. You should expect issues and to help us deliver a better kernel in the future, you should file bugs in Launchpad at https://bugs.launchpad.net/linux-linaro. The source tarball is available at: https://launchpad.net/linux-linaro/11.05/11.05-final/+download/linux-linaro-11.05-2.6.38.tar.bz2 The kernel sources can also be accessed using git at: git://git.linaro.org/kernel/linux-linaro-2.6.38.git tag: linaro-11.05-2.6.38 A pre-packaged kernel for OMAP boards is available at: https://launchpad.net/~linaro-maintainers/+archive/kernel/+files/linux-image-2.6.38-1003-linaro-omap_2.6.38-1003.4~ppa5_armel.deb This snapshot is based on the 2.6.38.7 stable kernel with a number of changes developed by Linaro and integrated from upstream trees including the 2.6.39, OMAP, and Power Management trees to name a few. The changes from 2.6.38.7 include: * Initial Device Tree support for MX51, MX53, Overo, SMDKV310, Beagle, IGEPv2/v3, Panda, Tegra, and Versatile boards. This support allows memory size and board type to be passed via the Device Tree. * The ARM kprobes code has been updated to correctly handle a number of instructions that did not previously work and to work on kernels w/o frame pointers. * The coredump code has been updated so you can now analyze VFP register state using GDB. Using this feature requires the upstream GDB trunk tree or the Linaro snapshot available from https://launchpad.net/gdb-linaro/+download * CPUIDLE support for Samsung Orion has been added, allowing for longer battery life on platforms based on this chipset. * Experimental support for LTTng on ARM, allowing developers to perform deep analysis of system state transitions. See http://lttng.org/ for more information on using LTTng. A full changelog against 2.6.38.7 is available at: https://launchpad.net/linux-linaro/11.05/11.05-final/+download/CHANGELOG-linux-linaro-11.05-2.6.38 High Priority Known Issues: * The combination of a device-tree enabled kernel and and Linaro's 2011-03 u-boot will make WiFi and HDMI unuseable on the IGEP board. (LP #768680) * imx51 randomly truncates serial input at 31 characters (LP #754254) * OMAP Beagle C4: kernel does not reliably find SD card on boot (LP #712175) * wl12** driver causes networking to hang on ubuntu-desktop image (LP #785739) * Only half of RAM useable when using Device Tree on Panda board (LP #707047) Mailing list: http://lists.linaro.org/mailman/listinfo/linaro-dev Questions? https://ask.linaro.org/ ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Boot sanity testing of release candidate kernel
On 25 May 2011 04:18, Dave Martin dave.mar...@linaro.org wrote: On Tue, May 24, 2011 at 07:42:43PM -0700, Deepak Saxena wrote: Hi all, The Kernel Working Group is getting ready to release the first of our new monthly development snapshot in a few days and we would like folks to do some quick sanity boot testing on their boards. Please grab or update the kernel from git://git.linaro.org/kernel/linux-linaro-2.6.38.git, and checkout the linaro-11.05-2.6.38 tag (which happens to be same as master at this moment) and give it a quick spin. Note that this is just the stock Linaro kernel and does not include any binary graphics drivers or other bits provided by Linaro's landing team kernels, so we just need the basic build and boot tested along with some simple testing of devices that can be used w/o extra drivers. Are we going to track who tested snapshots on what platform? Otherwise, we may collect little evidence that the snapshot was tested at all, especially if people don't encounter serious problems... I am tracking it right now and will make sure any issues that come up get documented or linked back to a bug. This is our first time doing this so it is a bit adhoc, in the future we'll have a more formal methodology for tagging, testing, and releasing. Thanks, ~Deepak ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Boot sanity testing of release candidate kernel
On 25 May 2011 03:29, Tixy t...@yxit.co.uk wrote: On Tue, 2011-05-24 at 19:42 -0700, Deepak Saxena wrote: The Kernel Working Group is getting ready to release the first of our new monthly development snapshot in a few days and we would like folks to do some quick sanity boot testing on their boards. Please grab or update the kernel from git://git.linaro.org/kernel/linux-linaro-2.6.38.git, and checkout the linaro-11.05-2.6.38 tag (which happens to be same as master at this moment) and give it a quick spin. Note that this is just the stock Linaro kernel and does not include any binary graphics drivers or other bits provided by Linaro's landing team kernels, so we just need the basic build and boot tested along with some simple testing of devices that can be used w/o extra drivers. Is there anywhere to report results of testing? I think it would be useful for us to know what has and what hasn't been tested. For this release, email is what we'll use and I'll collate all the info into a wiki page and maybe the release notes. - Blocked kworker thread issue manifests [2] This needs a bug opened and assigned to one of the TI engineers in the KWG. Thanks, ~Deepak ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Boot sanity testing of release candidate kernel
Hi all, The Kernel Working Group is getting ready to release the first of our new monthly development snapshot in a few days and we would like folks to do some quick sanity boot testing on their boards. Please grab or update the kernel from git://git.linaro.org/kernel/linux-linaro-2.6.38.git, and checkout the linaro-11.05-2.6.38 tag (which happens to be same as master at this moment) and give it a quick spin. Note that this is just the stock Linaro kernel and does not include any binary graphics drivers or other bits provided by Linaro's landing team kernels, so we just need the basic build and boot tested along with some simple testing of devices that can be used w/o extra drivers. Thanks! ~Deepak ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
