Re: The linaro-2.6.39 kernel repository is now alive
On 06/14/2011 04:26 AM, Somebody in the thread at some point said: On Thu, 9 Jun 2011, Andy Green wrote: On 06/09/2011 10:01 AM, Somebody in the thread at some point said: ... and with omap4_defconfig anyway cpufreq seems at least to start up on both CPUs on Panda now, cool. Going to have a go at omap2plus_defconfig. omap2plus_defconfig is still blowing SIGILLs where omap4_defconfig is happy (these defconfigs are vs my master branch) Did you rebase your tree with all its features? I'm asking because some people would like to see HDMI support back in the Linaro kernel tree for Panda. I went through the earlier part of the patch stack and many of them are either upstream or in your tree already. Now you also took my MAC patches it's stuff like HDMI, tiler and syslink pending which are needed for accelerated video decode, and the SGX stuff. I rebased the HDMI patches locally on top of the public master but they're functionally broken at the moment, I guess due to the delta between upstreamed DSS stuff and what was in linux-linaro-2.6.38 for DSS. At the moment the pressure is on trying to get workable SGX on Android build, I'll return to .39 HDMI shortly. -Andy ___ 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 Thu, 9 Jun 2011, Andy Green wrote: On 06/09/2011 10:01 AM, Somebody in the thread at some point said: ... and with omap4_defconfig anyway cpufreq seems at least to start up on both CPUs on Panda now, cool. Going to have a go at omap2plus_defconfig. omap2plus_defconfig is still blowing SIGILLs where omap4_defconfig is happy (these defconfigs are vs my master branch) Did you rebase your tree with all its features? I'm asking because some people would like to see HDMI support back in the Linaro kernel tree for Panda. Nicolas ___ 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 Wed, Jun 08, 2011 at 11:18:10AM -0400, Nicolas Pitre wrote: On Wed, 8 Jun 2011, Dave Martin wrote: Bisecting when CONFIG_THUMB2_KERNEL=y reproducibly identified af3e4fd37a18f2e5a00175bc96061541d1364a3b as the first bad commit between v2.6.39 and linux-linaro-2.6.39/master, but it's obviously totally irrelevant and causes no code changes at all (which I confirmed by disassembling) :P Only the config.gz data and kernel signature in the kernel changes... It could be a decompressor problem or similar, but actually booting from an Image doesn't work for me either after or before the above commit. How is this commit identified as the first bad one then? Just to give the background to this: The identified commit was the first bad one when booting the zImage in particular. (And now we understand why this is.) Another thing to keep in mind is the fact that the OMAP code is doing pretty nasty things wrt the serial console where the detection and initialization of the serial port address is done in the zImage code, and the kernel proper simply hope for the best by simply relying on some leftovers in memory from zImage to keep on using the serial console. You can bypass this by hardcoding the appropriate addresses in arch/arm/mach-omap2/include/mach/debug-macro.S, otherwise running zImage is pretty much mandatory. OK - this may be why my attempts to bypass the zImage decompressor by booting the Image directly didn't work. Cheers ---Dave ___ 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 06/09/2011 05:38 AM, Somebody in the thread at some point said: http://article.gmane.org/gmane.linux.ports.arm.kernel/119896 I'm not entirely satisfied with the W() usage in there though, even less so by the THUMB(nop) that are inserted here and there to provide proper padding. As the patch above shows, this is just too easy to overlook and break. I wish we could get rid of them and make that code a bit more streamlined, but I have no bright idea for that at the moment. Wow scary, great job picking up on it. It could be a decompressor problem or similar, but actually booting from an Image doesn't work for me either after or before the above commit. The early serial port usage issue I mentioned before notwitstanding, there was actually a real bug there too, especially if you had CONFIG_OF=y but not using any DTB. The fix is here: http://article.gmane.org/gmane.linux.ports.arm.kernel/119893 All those fixes plus a bunch of other fixes from mainline are now merged in linaro-2.6.39. I wasn't seeing it die early but that also looks like a good find. -Andy ___ 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 06/09/2011 09:22 AM, Somebody in the thread at some point said: All those fixes plus a bunch of other fixes from mainline are now merged in linaro-2.6.39. I wasn't seeing it die early but that also looks like a good find. Just a FYI a bogus line in core cpufreq driver has crept into linux-linaro-2.6.39 that breaks compilation for anything with CPU_FREQ enabled. This solves it -- http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git;a=patch;h=8e8dc5f5e0e287acbe76fdd77ad1dfc568eb2f89 ... and with omap4_defconfig anyway cpufreq seems at least to start up on both CPUs on Panda now, cool. Going to have a go at omap2plus_defconfig. -Andy ___ 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 06/09/2011 10:26 AM, Somebody in the thread at some point said: [ 2.262329] Freeing init memory: 292K init: hwclock main process (519) killed by ILL signal SIGILL issue requires CONFIG_ARCH_OMAP2 enabled to see it. Disabling CONFIG_ARCH_OMAP2 (and fixing stuff like EXT4 and DEVTMPFS being disabled) gets a boot without display but no SIGILL. -Andy ___ 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 Wed, Jun 8, 2011 at 4:31 AM, Nicolas Pitre nicolas.pi...@linaro.org wrote: On Tue, 7 Jun 2011, Dave Martin wrote: On Tue, Jun 07, 2011 at 10:49:51AM +0100, Tixy wrote: No, were using two different methods to produce configs. The one I use produces a Thumb2 kernel, the one you use doesn't. Well, it seems we have a few different problems here: Certainly, it looks like there is some kernel bug related to Thumb-2. Andy's SIGILL symptom is probably something else though. I'm seeing those SIGILL crashes too, even with plain v2.6.39 from kernel.org. So this one might not be linaro-2.6.39 specific. Finally, we're not all using the same configuration, which is causing confusion. There are at least two sources for the config: * The debian.linaro/config/...config.* files from the packaged linaro kernel tree (at least me, Tixy and the packaged kernel use this) * omap2plus_defconfig (omap upstream and some other people use this) That's the one I'm also using due to its convenience. I'm not sure if there's a correct answer to that one ... but we should be careful to explain more carefully what config we're using when discussing kernel problems (I'm guilty of being a bit vague on this...) Yes, it is pretty necessary, especially if there is a config that works and another that doesn't. Does anyone have a strong view on which config we should be using? The more configs we use the better. More coverage is always good. In the end, if only one config amongst many provides eratic behaviors this is a bug worth looking at. Bisecting when CONFIG_THUMB2_KERNEL=y reproducibly identified af3e4fd37a18f2e5a00175bc96061541d1364a3b as the first bad commit between v2.6.39 and linux-linaro-2.6.39/master, but it's obviously totally irrelevant and causes no code changes at all (which I confirmed by disassembling) :P Only the config.gz data and kernel signature in the kernel changes... It could be a decompressor problem or similar, but actually booting from an Image doesn't work for me either after or before the above commit. So we could be looking at some other nasty side-effect, or we're missing some omap-specific patch required to make cache maintenance work properly etc. If anyone has any other ideas about how to debug this further, I'd be interested. For now, I will try to add some printascii to see where boot hangs (assuming that this isn't a heisenbug, of course). Cheers ---Dave ___ 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 Wed, 8 Jun 2011, Dave Martin wrote: Bisecting when CONFIG_THUMB2_KERNEL=y reproducibly identified af3e4fd37a18f2e5a00175bc96061541d1364a3b as the first bad commit between v2.6.39 and linux-linaro-2.6.39/master, but it's obviously totally irrelevant and causes no code changes at all (which I confirmed by disassembling) :P Only the config.gz data and kernel signature in the kernel changes... It could be a decompressor problem or similar, but actually booting from an Image doesn't work for me either after or before the above commit. How is this commit identified as the first bad one then? Another thing to keep in mind is the fact that the OMAP code is doing pretty nasty things wrt the serial console where the detection and initialization of the serial port address is done in the zImage code, and the kernel proper simply hope for the best by simply relying on some leftovers in memory from zImage to keep on using the serial console. You can bypass this by hardcoding the appropriate addresses in arch/arm/mach-omap2/include/mach/debug-macro.S, otherwise running zImage is pretty much mandatory. Nicolas ___ 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 Wed, 8 Jun 2011, Dave Martin wrote: Bisecting when CONFIG_THUMB2_KERNEL=y reproducibly identified af3e4fd37a18f2e5a00175bc96061541d1364a3b as the first bad commit between v2.6.39 and linux-linaro-2.6.39/master, but it's obviously totally irrelevant and causes no code changes at all (which I confirmed by disassembling) :P Only the config.gz data and kernel signature in the kernel changes... No, the code did change. I dismissed this commit at first, but I finally found the problem. Have a look at the fix: http://article.gmane.org/gmane.linux.ports.arm.kernel/119896 I'm not entirely satisfied with the W() usage in there though, even less so by the THUMB(nop) that are inserted here and there to provide proper padding. As the patch above shows, this is just too easy to overlook and break. I wish we could get rid of them and make that code a bit more streamlined, but I have no bright idea for that at the moment. It could be a decompressor problem or similar, but actually booting from an Image doesn't work for me either after or before the above commit. The early serial port usage issue I mentioned before notwitstanding, there was actually a real bug there too, especially if you had CONFIG_OF=y but not using any DTB. The fix is here: http://article.gmane.org/gmane.linux.ports.arm.kernel/119893 All those fixes plus a bunch of other fixes from mainline are now merged in linaro-2.6.39. BTW, I'm using git://github.com/swetland/omap4boot.git which allows to push a kernel over USB and boot it directly, entirely bypassing U-Boot and the MMC card or the network, which is *WAY* more convenient for kernel development and git bisect runs (thanks to Kevin Hilman for the link). A simple './usbboot zImage' on your build machine and a press on the reset button on the Panda and it is booted. This requires CONFIG_CMDLINE_FORCE=y though. Nicolas ___ 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 Tue, 2011-06-07 at 09:22 +0100, Andy Green wrote: On 06/07/2011 09:09 AM, Somebody in the thread at some point said: Hi - When booted on a Beagleboard-xM, the resulting kernel appears to hang after Starting kernel I haven't investigated any further. Try disabling CONFIG_THUMB2_KERNEL and rebuilding. If this does fix the problem, this suggests that this problem is indeed Thumb-2 related. I will have a go at digging into this tomorrow. Disabling Thumb2 fixes the problem. What did you actually disable? Presumably not CONFIG_THUMB2_KERNEL so the thumb support at all? I deselected CONFIG_THUMB2_KERNEL using menuconfig, which changed the .config file like... -CONFIG_THUMB2_KERNEL=y +# CONFIG_THUMB2_KERNEL is not set -CONFIG_THUMB2_AVOID_R_ARM_THM_JUMP11=y -CONFIG_ARM_ASM_UNIFIED=y +CONFIG_OABI_COMPAT=y +# CONFIG_KPROBES is not set +CONFIG_HAVE_KPROBES=y +CONFIG_HAVE_KRETPROBES=y +CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y -- Tixy ___ 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 Tue, Jun 07, 2011 at 10:49:51AM +0100, Tixy wrote: On Tue, 2011-06-07 at 10:01 +0100, Andy Green wrote: On 06/07/2011 09:35 AM, Somebody in the thread at some point said: Disabling Thumb2 fixes the problem. What did you actually disable? Presumably not CONFIG_THUMB2_KERNEL so the thumb support at all? I deselected CONFIG_THUMB2_KERNEL using menuconfig, which changed the .config file like... -CONFIG_THUMB2_KERNEL=y Yeah but where did this config come from? It was the output produced by running the commands listed at https://wiki.linaro.org/Resources/HowTo/KernelDeploy#From_Linaro_sources This config has CONFIG_THUMB2_KERNEL=y and doesn't have an entry for CONFIG_CPU_V6 Regenerating omap2plus_defconfig as I showed doesn't allow CONFIG_THUMB2_KERNEL to be configured because CONFIG_CPU_V6 is set (along with V7) since omap2plus_defconfig has a bunch of different cores supported. You mentioned -- The .config I'm using is that described on the wiki at https://wiki.linaro.org/Resources/HowTo/KernelDeploy#From_Linaro_sources; it also recommends make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- omap2plus_defconfig When I run that command I end up with a .config which has CONFIG_CPU_V6=y and no entry for CONFIG_THUMB2_KERNEL. I just confirmed that's the case with current linux-linaro-2.6.39. Am I going nuts :?) No, were using two different methods to produce configs. The one I use produces a Thumb2 kernel, the one you use doesn't. Well, it seems we have a few different problems here: Certainly, it looks like there is some kernel bug related to Thumb-2. Andy's SIGILL symptom is probably something else though. Finally, we're not all using the same configuration, which is causing confusion. There are at least two sources for the config: * The debian.linaro/config/...config.* files from the packaged linaro kernel tree (at least me, Tixy and the packaged kernel use this) * omap2plus_defconfig (omap upstream and some other people use this) I'm not sure if there's a correct answer to that one ... but we should be careful to explain more carefully what config we're using when discussing kernel problems (I'm guilty of being a bit vague on this...) Does anyone have a strong view on which config we should be using? Cheers ---Dave ___ 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 06/07/2011 10:58 AM, Somebody in the thread at some point said: Hi - It was the output produced by running the commands listed at https://wiki.linaro.org/Resources/HowTo/KernelDeploy#From_Linaro_sources This config has CONFIG_THUMB2_KERNEL=y and doesn't have an entry for CONFIG_CPU_V6 Well it's because that config is coming from outside the tree itself, it can have no relation to what's in the actual HEAD of what you're building. * The debian.linaro/config/...config.* files from the packaged linaro kernel tree (at least me, Tixy and the packaged kernel use this) * omap2plus_defconfig (omap upstream and some other people use this) I'm not sure if there's a correct answer to that one ... but we should be careful to explain more carefully what config we're using when discussing kernel problems (I'm guilty of being a bit vague on this...) Does anyone have a strong view on which config we should be using? I think folks who are working directly with kernel trees need to use defconfigs coming out of that exact tree and HEAD state. The reason is that along with patching code, we often patch our reference config that belongs to the tree, ie, at the patchlevel where a new feature is added to the tree, commonly the reference config is patched as well to enable it. In my case that's omap4_defconfig but we need to be paying some attention to everything working with upstream's omap2plus_defconfig as well. Folks who are packaging the kernel or wanting to get the same result as a packaged kernel with a different tree can try their previous packaged kernel's config; that's a bit less deterministic in terms of what they will get but it's certainly a legitimate thing to do since in the end most people will consume the kernel in packaged form. However not everyone taking this kernel tree will know about or want to use this external linaro config flavour that lives somewhere completely different. So the tree ought primarily to work with its own local in-tree reference configs above all else. -Andy ___ 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 Tue, Jun 7, 2011 at 5:33 AM, Dave Martin dave.mar...@linaro.org wrote: On Tue, Jun 07, 2011 at 11:31:51AM +0100, Andy Green wrote: On 06/07/2011 10:58 AM, Somebody in the thread at some point said: Hi - It was the output produced by running the commands listed at https://wiki.linaro.org/Resources/HowTo/KernelDeploy#From_Linaro_sources This config has CONFIG_THUMB2_KERNEL=y and doesn't have an entry for CONFIG_CPU_V6 Well it's because that config is coming from outside the tree itself, it can have no relation to what's in the actual HEAD of what you're building. * The debian.linaro/config/...config.* files from the packaged linaro kernel tree (at least me, Tixy and the packaged kernel use this) * omap2plus_defconfig (omap upstream and some other people use this) I'm not sure if there's a correct answer to that one ... but we should be careful to explain more carefully what config we're using when discussing kernel problems (I'm guilty of being a bit vague on this...) Does anyone have a strong view on which config we should be using? I think folks who are working directly with kernel trees need to use defconfigs coming out of that exact tree and HEAD state. The reason is that along with patching code, we often patch our reference config that belongs to the tree, ie, at the patchlevel where a new feature is added to the tree, commonly the reference config is patched as well to enable it. In my case that's omap4_defconfig but we need to be paying some attention to everything working with upstream's omap2plus_defconfig as well. Folks who are packaging the kernel or wanting to get the same result as a packaged kernel with a different tree can try their previous packaged kernel's config; that's a bit less deterministic in terms of what they will get but it's certainly a legitimate thing to do since in the end most people will consume the kernel in packaged form. Effectively that's what I've been doing. The reason for this was that I'd assumed that all defconfigs had potentially become stale cruft after all the controversy about them, since Linus no longer wanted to see a load of patches to those files. But now that things have settled down, I guess should be safe to assume that consolidated defconfigs which have survived the cull are valid and maintained. omap2plus_defconfig at least is actively used and maintained by the upstream omap guys, and should be a fairly good reference. However not everyone taking this kernel tree will know about or want to use this external linaro config flavour that lives somewhere completely different. So the tree ought primarily to work with its own local in-tree reference configs above all else. That seems fair--- and we don't want to get into a situation where the linaro kernel tree is actually broken with the upstream defconfig. This suggests that for most kernel work done by the kernel WG we should test both with the upstream defconfig and the linaro config, but treat the upstream defconfig as the primary reference. It's worth noting that the linaro configs typically enable a _lot_ I intend to make this better this cycle. The various flavours will be more consistent with one another and the configs will be much leaner. Also I have found that one can successfully boot test a kernel with only make uImage so you don't have to take the time to build all the module to do a quick boot test. more options and modules than the defconfigs, whichi are usually rather minimal. So the linaro configs may provide a better smoketest for build problems. Cheers ---Dave ___ 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
Re: The linaro-2.6.39 kernel repository is now alive
On 06/07/2011 10:44 AM, John Rigby wrote: I intend to make this better this cycle. The various flavours will be more consistent with one another and the configs will be much leaner. Also I have found that one can successfully boot test a kernel with only make uImage so you don't have to take the time to build all the module to do a quick boot test. Slightly off topic - but there's one annoying thing when you just build our uImage. The linaro default .config has these options as modules: CONFIG_NLS_CODEPAGE_437=m CONFIG_NLS_ISO8859_1=m This means you can't update the kernel on your target device because you can't mount /dev/mmcblk0p1. When testing kernel changes, I like to run a script on the device that will grab a new uImage, copy it to /dev/mmcblk0p1, and reboot. -andy ___ 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
Can you enter a bug for this so I don't forget to make these =y if that is all it takes to fix this. On Tue, Jun 7, 2011 at 9:59 AM, Andy Doan andy.d...@linaro.org wrote: On 06/07/2011 10:44 AM, John Rigby wrote: I intend to make this better this cycle. The various flavours will be more consistent with one another and the configs will be much leaner. Also I have found that one can successfully boot test a kernel with only make uImage so you don't have to take the time to build all the module to do a quick boot test. Slightly off topic - but there's one annoying thing when you just build our uImage. The linaro default .config has these options as modules: CONFIG_NLS_CODEPAGE_437=m CONFIG_NLS_ISO8859_1=m This means you can't update the kernel on your target device because you can't mount /dev/mmcblk0p1. When testing kernel changes, I like to run a script on the device that will grab a new uImage, copy it to /dev/mmcblk0p1, and reboot. -andy ___ 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 06/07/2011 11:04 AM, John Rigby wrote: Can you enter a bug for this so I don't forget to make these =y if that is all it takes to fix this. https://bugs.launchpad.net/linux-linaro/+bug/794134 ___ 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 Tue, 7 Jun 2011, Dave Martin wrote: On Tue, Jun 07, 2011 at 10:49:51AM +0100, Tixy wrote: No, were using two different methods to produce configs. The one I use produces a Thumb2 kernel, the one you use doesn't. Well, it seems we have a few different problems here: Certainly, it looks like there is some kernel bug related to Thumb-2. Andy's SIGILL symptom is probably something else though. I'm seeing those SIGILL crashes too, even with plain v2.6.39 from kernel.org. So this one might not be linaro-2.6.39 specific. Finally, we're not all using the same configuration, which is causing confusion. There are at least two sources for the config: * The debian.linaro/config/...config.* files from the packaged linaro kernel tree (at least me, Tixy and the packaged kernel use this) * omap2plus_defconfig (omap upstream and some other people use this) That's the one I'm also using due to its convenience. I'm not sure if there's a correct answer to that one ... but we should be careful to explain more carefully what config we're using when discussing kernel problems (I'm guilty of being a bit vague on this...) Yes, it is pretty necessary, especially if there is a config that works and another that doesn't. Does anyone have a strong view on which config we should be using? The more configs we use the better. More coverage is always good. In the end, if only one config amongst many provides eratic behaviors this is a bug worth looking at. Nicolas ___ 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 Sat, Jun 4, 2011 at 2:17 PM, Tixy t...@yxit.co.uk wrote: On Thu, 2011-06-02 at 01:12 -0400, Nicolas Pitre wrote: Time to leave 2.6.38 behind and move on! We now have a 2.6.39 based Linaro kernel which can be viewed here: http://git.linaro.org/gitweb?p=kernel/linux-linaro-2.6.39.git;a=summary or cloned from either of those: git://git.linaro.org/kernel/linux-linaro-2.6.39.git http://git.linaro.org/git/kernel/linux-linaro-2.6.39.git When building for OMAP there's a build error in smc91x.c which is fixed by http://permalink.gmane.org/gmane.linux.network/197474 There are also build errors to do with DSS (mentioned elsewhere in this thread). A kernel can be successfully built after disabling the following config option: Device Drivers -- Graphics support -- OMAP2+ Display Subsystem support -- DPI support When booted on a Beagleboard-xM, the resulting kernel appears to hang after Starting kernel I haven't investigated any further. The .config I'm using is that described on the wiki at https://wiki.linaro.org/Resources/HowTo/KernelDeploy#From_Linaro_sources Try disabling CONFIG_THUMB2_KERNEL and rebuilding. If this does fix the problem, this suggests that this problem is indeed Thumb-2 related. I will have a go at digging into this tomorrow. Cheers ---Dave ___ 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 06/06/2011 05:44 PM, Somebody in the thread at some point said: The .config I'm using is that described on the wiki at https://wiki.linaro.org/Resources/HowTo/KernelDeploy#From_Linaro_sources Try disabling CONFIG_THUMB2_KERNEL and rebuilding. If this does fix the problem, this suggests that this problem is indeed Thumb-2 related. I will have a go at digging into this tomorrow. FWIW in my tree's reference omap4_defconfig, CONFIG_THUMB2_KERNEL is disabled (this kernel just stops at the end of initrd scripts, although twice thisafternoon during dozens of boots I saw it continue as if nothing was wrong and complete a normal boot, whatever that means). On omap2plus_defconfig, CONFIG_THUMB2_KERNEL doesn't appear in the config because CPU_V6 is set. And that's the guy who blows SIGILL. -Andy ___ 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 Thu, Jun 2, 2011 at 8:55 PM, 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. In practice this means that AndyDoan/Ricardo will have to do their work again on top of this tree, and then I might merge it. Yup, that's the plan. I believe Rob Clark is targeting the DRM changes for OMAP for 3.1, so I'll check with him and rebase the patches to be in a better shape for upstream. Once done will send the pull request to Nicolas. Cheers, -- Ricardo Salveti de Araujo ___ 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 Thu, Jun 02, 2011 at 01:12:29AM -0400, Nicolas Pitre wrote: Time to leave 2.6.38 behind and move on! We now have a 2.6.39 based Linaro kernel which can be viewed here: http://git.linaro.org/gitweb?p=kernel/linux-linaro-2.6.39.git;a=summary or cloned from either of those: git://git.linaro.org/kernel/linux-linaro-2.6.39.git http://git.linaro.org/git/kernel/linux-linaro-2.6.39.git This will continue to evolve as this is just the beginning for that tree, so more stuff will be merged. Only smoke tested on a Dove board, and compile tested for OMAP so far. Great ... I've just been playing with the new tree. The following comments assume that linux-linaro-2.6.39/master = 570728d7678e788e4a0e2c19ad5f932e3c29a73c vexpress linux-linaro-2.6.39/master doesn't seem to work on vexpress using the linux-linaro-natty configuration (I get starting the kernel, then nothing). Upstream v2.6.39 does appear to work fully on vexpress in both ARM and Thumb-2. The bad commit is: 6e7c40e473c1f0553175efff64cf30288c1bc9f4 (clockevents: ARM sp804: obtain sp804 timer rate via clks) Rob Herring proposed a patch to fix this issue (below). Note that the last hunk of the patch affecting libata is not relevant (Rob subsequently retracted it.) http://article.gmane.org/gmane.linux.ports.arm.kernel/118249 That additional patch seems to fix the problem for me. imx51 - I get a booting kernel from linux-linaro-2.6.39/master in mx51evk, so long as I boot without an fdt blob. If I build a Thumb-2 kernel, it does not boot, but a Thumb-2 kernel built from linux-linaro-natty/master does boot; i.e. I get no messages at all after Starting kernel ... I haven't investigated what the problem is yet. Cheers ---Dave ___ 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 Thu, 2 Jun 2011, Dave Martin wrote: vexpress linux-linaro-2.6.39/master doesn't seem to work on vexpress using the linux-linaro-natty configuration (I get starting the kernel, then nothing). Upstream v2.6.39 does appear to work fully on vexpress in both ARM and Thumb-2. The bad commit is: 6e7c40e473c1f0553175efff64cf30288c1bc9f4 (clockevents: ARM sp804: obtain sp804 timer rate via clks) Rob Herring proposed a patch to fix this issue (below). Note that the last hunk of the patch affecting libata is not relevant (Rob subsequently retracted it.) http://article.gmane.org/gmane.linux.ports.arm.kernel/118249 That additional patch seems to fix the problem for me. Applied. imx51 - I get a booting kernel from linux-linaro-2.6.39/master in mx51evk, so long as I boot without an fdt blob. If I build a Thumb-2 kernel, it does not boot, but a Thumb-2 kernel built from linux-linaro-natty/master does boot; i.e. I get no messages at all after Starting kernel ... I haven't investigated what the problem is yet. I might not have carried over all the Thumb2 patches yet, if any of them are still relevant which is something I still need to figure out. However those would only affect build issues if I remember right. Nicolas ___ 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
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. On the config issue, I am going to strip down the omap config to be closer to the others. I want to make the different flavours more consistant with one another and the default kernel configs. I intend to only turn on stuff required to be Ubuntu. Once I have something we will test and see if anyone notices stuff missing (like a parallel port driver:). John On Thu, Jun 2, 2011 at 2:40 PM, Andy Doan andy.d...@linaro.org wrote: On 06/02/2011 12:12 AM, Nicolas Pitre wrote: This will continue to evolve as this is just the beginning for that tree, so more stuff will be merged. Only smoke tested on a Dove board, and compile tested for OMAP so far. I just tried some testing of my Overo with the omap2plus_defconfig and my hack for what John Rigby uses for Linaro builds. The Linaro config produces a compiler error. I'm assuming the config will be changing, so I haven't really looked into patching the issue. John - let me know if this is something you need my help with. The omap2plus_defconfig comes up but I'm not getting DVI video and I'm also seeing these problems from the kernel: Uncompressing Linux... done, booting the kernel. [ 0.00] Linux version 2.6.39-00910-g3818181-dirty (doanac@storage) (gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu3) ) #4 SMP Thu Jun 2 14:43:32 CDT 2011 [ 0.00] CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c53c7f [ 0.00] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache [ 0.00] Machine: Gumstix Overo [ 0.00] Reserving 12582912 bytes SDRAM for VRAM [ 0.00] Memory policy: ECC disabled, Data cache writeback [ 0.00] OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp ) [ 0.00] SRAM: Mapped pa 0x4020 to va 0xfe40 size: 0x1 [ 0.00] Clocking rate (Crystal/Core/MPU): 26.0/332/500 MHz [ 0.00] Reprogramming SDRC clock to 33200 Hz [ 0.00] PERCPU: Embedded 7 pages/cpu @c0f85000 s8160 r8192 d12320 u32768 [ 0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 126976 [ 0.00] Kernel command line: console=ttyO2,115200n8 mpurate=720 vram=12M omapfb.mode=dvi:1024x768MR-16@60 omapfb.debug=y omapdss.def_disp=dvi root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait snip [ 0.228179] Registering NAND on CS0 [ 0.231536] Could not obtain gpio for TS PenDown: -16 [ 0.231567] kobject (c05eae78): tried to init an initialized object, something is seriously wrong. [ 0.231628] [c0060d44] (unwind_backtrace+0x0/0xe0) from [c024c560] (kobject_init+0x34/0x90) [ 0.231689] [c024c560] (kobject_init+0x34/0x90) from [c029fa14] (device_initialize+0x20/0x90) [ 0.231719] [c029fa14] (device_initialize+0x20/0x90) from [c02a3898] (platform_device_register+0x10/0x1c) [ 0.231781] [c02a3898] (platform_device_register+0x10/0x1c) from [c0015910] (overo_init+0x80/0x228) [ 0.231811] [c0015910] (overo_init+0x80/0x228) from [c000b27c] (customize_machine+0x1c/0x28) [ 0.231872] [c000b27c] (customize_machine+0x1c/0x28) from [c0050664] (do_one_initcall+0x90/0x164) [ 0.231903] [c0050664] (do_one_initcall+0x90/0x164) from [c000898c] (kernel_init+0xa4/0x154) [ 0.231933] [c000898c] (kernel_init+0xa4/0x154) from [c005b094] (kernel_thread_exit+0x0/0x8) [ 0.232055] [ cut here ] [ 0.232086] WARNING: at /home/doanac/linaro/code/linux-linaro-2.6.39/fs/sysfs/dir.c:455 sysfs_add_one+0x6c/0x94() [ 0.232116] sysfs: cannot create duplicate filename '/devices/platform/reg-fixed-voltage.1' [ 0.232116] Modules linked in: [ 0.232177] [c0060d44] (unwind_backtrace+0x0/0xe0) from [c00915a0] (warn_slowpath_common+0x4c/0x64) [ 0.232208] [c00915a0] (warn_slowpath_common+0x4c/0x64) from [c0091638] (warn_slowpath_fmt+0x2c/0x3c) [ 0.232269] [c0091638] (warn_slowpath_fmt+0x2c/0x3c) from [c017b6e8] (sysfs_add_one+0x6c/0x94) [ 0.232299] [c017b6e8] (sysfs_add_one+0x6c/0x94) from [c017b76c] (create_dir+0x5c/0xb4) [ 0.232330] [c017b76c] (create_dir+0x5c/0xb4) from [c017b884] (sysfs_create_dir+0xa4/0xbc) [ 0.232360] [c017b884] (sysfs_create_dir+0xa4/0xbc) from [c024c800] (kobject_add_internal+0xd0/0x1e8) [ 0.232421] [c024c800] (kobject_add_internal+0xd0/0x1e8) from [c024cbec] (kobject_add+0x68/0x8c) [ 0.232452] [c024cbec] (kobject_add+0x68/0x8c) from [c029fe78] (device_add+0xa0/0x50c) [ 0.232482] [c029fe78] (device_add+0xa0/0x50c) from [c02a382c] (platform_device_add+0x108/0x164) [ 0.232543] [c02a382c] (platform_device_add+0x108/0x164) from [c0015910] (overo_init+0x80/0x228) [ 0.232574] [c0015910] (overo_init+0x80/0x228)
Re: The linaro-2.6.39 kernel repository is now alive
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. In practice this means that AndyDoan/Ricardo will have to do their work again on top of this tree, and then I might merge it. Nicolas ___ 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 Thu, 2011-06-02 at 01:12 -0400, Nicolas Pitre wrote: Time to leave 2.6.38 behind and move on! We now have a 2.6.39 based Linaro kernel which can be viewed here: http://git.linaro.org/gitweb?p=kernel/linux-linaro-2.6.39.git;a=summary or cloned from either of those: git://git.linaro.org/kernel/linux-linaro-2.6.39.git http://git.linaro.org/git/kernel/linux-linaro-2.6.39.git This will continue to evolve as this is just the beginning for that tree, so more stuff will be merged. Only smoke tested on a Dove board, and compile tested for OMAP so far. Hit a compile issue with your tree: drivers/video/omap2/dss/dpi.c: In function 'dpi_set_dsi_clk': drivers/video/omap2/dss/dpi.c:61: error: implicit declaration of function 'dsi_pll_calc_clock_div_pck' drivers/video/omap2/dss/dpi.c:66: error: implicit declaration of function 'dsi_pll_set_clock_div' drivers/video/omap2/dss/dpi.c: In function 'omapdss_dpi_display_enable': drivers/video/omap2/dss/dpi.c:192: error: implicit declaration of function 'dsi_pll_init' drivers/video/omap2/dss/dpi.c:209: error: implicit declaration of function 'dsi_pll_uninit' Looks like enabling CONFIG_OMAP2_DSS_DPI tries to access bits only available with CONFIG_OMAP2_DSS_DSI enabled. Vanilla 2.6.39 doesn't seem to have this issue. thanks -john ___ 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 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. In practice this means that AndyDoan/Ricardo will have to do their work again on top of this tree, and then I might merge it. I'd like to further suggest that in the interest of cooperation that we take a more constructive tone. We're all going to need to work closely to accomplish our goals of upstreaming support for these boards and unifying implementations. Nicolas ___ 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
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: The linaro-2.6.39 kernel repository is now alive
On Thu, Jun 02, 2011 at 09:01:01PM -0500, Zach Pfeffer 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. Zach, in this case, Nicolas is completely right. The task within the Kernel WG is to maintain a consolidation tree with a pretty clear criteria of carrying only upstreamable patches. When the tree is rebased, the patches that aren't upstream (and not trivially portable, AIUI) get dropped, and the authors need to refresh them. The job of maintaining a working consolidation tree is already hard enough. Let's not make it any harder. (And I don't find tone inappropriate at all, but maybe that's because I can see his well-meaning grin when I read it wink) -- Christian Robottom Reis | [+55] 16 9112 6430 | http://launchpad.net/~kiko Linaro Engineering VP | [ +1] 612 216 4935 | http://async.com.br/~kiko ___ 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 Thu, 2 Jun 2011, Zach Pfeffer 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. Am I really harsh? I'd like to suggest this kind of feedback isn't appropriate. The issues concerning what can't be upstreamed are well known. I'm not talking about what can't be upstreamed. I'm talking about what _can_ be upstreamed and still isn't. In practice this means that AndyDoan/Ricardo will have to do their work again on top of this tree, and then I might merge it. I'd like to further suggest that in the interest of cooperation that we take a more constructive tone. We're all going to need to work closely to accomplish our goals of upstreaming support for these boards and unifying implementations. Isn't that what we're all doing? Anyway I don't understand why you need to talk about constructive tone here, unless you read something different in my words than I actually meant. But mind you, that wouldn't be the first time this happened to me. Confused. Nicolas___ 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 22:12, Nicolas Pitre nicolas.pi...@linaro.org wrote: On Thu, 2 Jun 2011, Zach Pfeffer 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. Am I really harsh? Perhaps not. The 'you lose' comment kind of struck a cord with me. Its hard to tell tone in a email though. I'd like to suggest this kind of feedback isn't appropriate. The issues concerning what can't be upstreamed are well known. I'm not talking about what can't be upstreamed. I'm talking about what _can_ be upstreamed and still isn't. Sure. I was reacting to the 'you lose' comment. I thought, well I don't lose, maybe I need to try again, but I'd like some constructive feedback. In practice this means that AndyDoan/Ricardo will have to do their work again on top of this tree, and then I might merge it. I'd like to further suggest that in the interest of cooperation that we take a more constructive tone. We're all going to need to work closely to accomplish our goals of upstreaming support for these boards and unifying implementations. Isn't that what we're all doing? Anyway I don't understand why you need to talk about constructive tone here, unless you read something different in my words than I actually meant. But mind you, that wouldn't be the first time this happened to me. Yeah. I think I just read the above you lose comment wrong. I'm sorry for jumping to conclusions and not asking you privately about it. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
The linaro-2.6.39 kernel repository is now alive
Time to leave 2.6.38 behind and move on! We now have a 2.6.39 based Linaro kernel which can be viewed here: http://git.linaro.org/gitweb?p=kernel/linux-linaro-2.6.39.git;a=summary or cloned from either of those: git://git.linaro.org/kernel/linux-linaro-2.6.39.git http://git.linaro.org/git/kernel/linux-linaro-2.6.39.git This will continue to evolve as this is just the beginning for that tree, so more stuff will be merged. Only smoke tested on a Dove board, and compile tested for OMAP so far. Most of the ARM related patches which made their way into v3.0-rc1 in mainline are included. However there might still be patches that were included in linaro-2.6.38 which are missing from linaro-2.6.39 at the moment. I might forward port some of them according to their importance, their look, or even my mood. So if you need extra patches on top of what's currently there please tell me and don't just assume I will pick them up from linaro-2.6.38 automatically (this is reverse garbage collection i.e. I'll simply leave unwanted patches behind). This is also a good opportunity for landing teams to test their git-rebase skills and move ahead to linaro-2.6.39. Enjoy! Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
