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%3Ba=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
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%3Ba=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
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
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.000000] 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.000000] CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c53c7f [ 0.000000] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache [ 0.000000] Machine: Gumstix Overo [ 0.000000] Reserving 12582912 bytes SDRAM for VRAM [ 0.000000] Memory policy: ECC disabled, Data cache writeback [ 0.000000] OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp ) [ 0.000000] SRAM: Mapped pa 0x40200000 to va 0xfe400000 size: 0x10000 [ 0.000000] Clocking rate (Crystal/Core/MPU): 26.0/332/500 MHz [ 0.000000] Reprogramming SDRC clock to 332000000 Hz [ 0.000000] PERCPU: Embedded 7 pages/cpu @c0f85000 s8160 r8192 d12320 u32768 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 126976 [ 0.000000] 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) from [<c000b27c>] (customize_machine+0x1c/0x28) [ 0.232604] [<c000b27c>] (customize_machine+0x1c/0x28) from [<c0050664>] (do_one_initcall+0x90/0x164) [ 0.232635] [<c0050664>] (do_one_initcall+0x90/0x164) from [<c000898c>] (kernel_init+0xa4/0x154) [ 0.232696] [<c000898c>] (kernel_init+0xa4/0x154) from [<c005b094>] (kernel_thread_exit+0x0/0x8) [ 0.233123] ---[ end trace 1b75b31a2719ed1c ]--- [ 0.233184] kobject_add_internal failed for reg-fixed-voltage.1 with -EEXIST, don't try to register things with the same name in the same directory. [ 0.233215] [<c0060d44>] (unwind_backtrace+0x0/0xe0) from [<c024c8ec>] (kobject_add_internal+0x1bc/0x1e8) [ 0.233276] [<c024c8ec>] (kobject_add_internal+0x1bc/0x1e8) from [<c024cbec>] (kobject_add+0x68/0x8c) [ 0.233306] [<c024cbec>] (kobject_add+0x68/0x8c) from [<c029fe78>] (device_add+0xa0/0x50c) [ 0.233337] [<c029fe78>] (device_add+0xa0/0x50c) from [<c02a382c>] (platform_device_add+0x108/0x164) [ 0.233398] [<c02a382c>] (platform_device_add+0x108/0x164) from [<c0015910>] (overo_init+0x80/0x228) [ 0.233428] [<c0015910>] (overo_init+0x80/0x228) from [<c000b27c>] (customize_machine+0x1c/0x28) [ 0.233459] [<c000b27c>] (customize_machine+0x1c/0x28) from [<c0050664>] (do_one_initcall+0x90/0x164) [ 0.233489] [<c0050664>] (do_one_initcall+0x90/0x164) from [<c000898c>] (kernel_init+0xa4/0x154) [ 0.233551] [<c000898c>] (kernel_init+0xa4/0x154) from [<c005b094>] (kernel_thread_exit+0x0/0x8) [ 0.249023] hw-breakpoint: debug architecture 0x4 unsupported. [ 0.351715] Switched to new clocking rate (Crystal/Core/MPU): 26.0/332/720 MHz
<snip>
[ 2.715759] ------------[ cut here ]------------ [ 2.720764] WARNING: at /home/doanac/linaro/code/linux-linaro-2.6.39/kernel/irq/handle.c:130 handle_irq_event_percpu+0xf8/0x1fc() [ 2.733123] irq 379 handler twl_rtc_interrupt+0x0/0x98 enabled interrupts [ 2.740356] Modules linked in: [ 2.743652] [<c0060d44>] (unwind_backtrace+0x0/0xe0) from [<c00915a0>] (warn_slowpath_common+0x4c/0x64) [ 2.753631] [<c00915a0>] (warn_slowpath_common+0x4c/0x64) from [<c0091638>] (warn_slowpath_fmt+0x2c/0x3c) [ 2.763763] [<c0091638>] (warn_slowpath_fmt+0x2c/0x3c) from [<c00d4b30>] (handle_irq_event_percpu+0xf8/0x1fc) [ 2.774291] [<c00d4b30>] (handle_irq_event_percpu+0xf8/0x1fc) from [<c00d4c70>] (handle_irq_event+0x3c/0x5c) [ 2.784698] [<c00d4c70>] (handle_irq_event+0x3c/0x5c) from [<c00d6f4c>] (handle_edge_irq+0x124/0x160) [ 2.794494] [<c00d6f4c>] (handle_edge_irq+0x124/0x160) from [<c02af40c>] (handle_twl4030_sih+0xac/0xd4) [ 2.804443] [<c02af40c>] (handle_twl4030_sih+0xac/0xd4) from [<c02af2f0>] (twl4030_irq_thread+0xb4/0x108) [ 2.814605] [<c02af2f0>] (twl4030_irq_thread+0xb4/0x108) from [<c00ad888>] (kthread+0x7c/0x84) [ 2.823760] [<c00ad888>] (kthread+0x7c/0x84) from [<c005b094>] (kernel_thread_exit+0x0/0x8) [ 2.832611] ---[ end trace 1b75b31a2719ed1e ]---
-andy
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.doan@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.000000] 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.000000] CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c53c7f [ 0.000000] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache [ 0.000000] Machine: Gumstix Overo [ 0.000000] Reserving 12582912 bytes SDRAM for VRAM [ 0.000000] Memory policy: ECC disabled, Data cache writeback [ 0.000000] OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp ) [ 0.000000] SRAM: Mapped pa 0x40200000 to va 0xfe400000 size: 0x10000 [ 0.000000] Clocking rate (Crystal/Core/MPU): 26.0/332/500 MHz [ 0.000000] Reprogramming SDRC clock to 332000000 Hz [ 0.000000] PERCPU: Embedded 7 pages/cpu @c0f85000 s8160 r8192 d12320 u32768 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 126976 [ 0.000000] 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) from [<c000b27c>] (customize_machine+0x1c/0x28) [ 0.232604] [<c000b27c>] (customize_machine+0x1c/0x28) from [<c0050664>] (do_one_initcall+0x90/0x164) [ 0.232635] [<c0050664>] (do_one_initcall+0x90/0x164) from [<c000898c>] (kernel_init+0xa4/0x154) [ 0.232696] [<c000898c>] (kernel_init+0xa4/0x154) from [<c005b094>] (kernel_thread_exit+0x0/0x8) [ 0.233123] ---[ end trace 1b75b31a2719ed1c ]--- [ 0.233184] kobject_add_internal failed for reg-fixed-voltage.1 with -EEXIST, don't try to register things with the same name in the same directory. [ 0.233215] [<c0060d44>] (unwind_backtrace+0x0/0xe0) from [<c024c8ec>] (kobject_add_internal+0x1bc/0x1e8) [ 0.233276] [<c024c8ec>] (kobject_add_internal+0x1bc/0x1e8) from [<c024cbec>] (kobject_add+0x68/0x8c) [ 0.233306] [<c024cbec>] (kobject_add+0x68/0x8c) from [<c029fe78>] (device_add+0xa0/0x50c) [ 0.233337] [<c029fe78>] (device_add+0xa0/0x50c) from [<c02a382c>] (platform_device_add+0x108/0x164) [ 0.233398] [<c02a382c>] (platform_device_add+0x108/0x164) from [<c0015910>] (overo_init+0x80/0x228) [ 0.233428] [<c0015910>] (overo_init+0x80/0x228) from [<c000b27c>] (customize_machine+0x1c/0x28) [ 0.233459] [<c000b27c>] (customize_machine+0x1c/0x28) from [<c0050664>] (do_one_initcall+0x90/0x164) [ 0.233489] [<c0050664>] (do_one_initcall+0x90/0x164) from [<c000898c>] (kernel_init+0xa4/0x154) [ 0.233551] [<c000898c>] (kernel_init+0xa4/0x154) from [<c005b094>] (kernel_thread_exit+0x0/0x8) [ 0.249023] hw-breakpoint: debug architecture 0x4 unsupported. [ 0.351715] Switched to new clocking rate (Crystal/Core/MPU): 26.0/332/720 MHz
<snip>
[ 2.715759] ------------[ cut here ]------------ [ 2.720764] WARNING: at /home/doanac/linaro/code/linux-linaro-2.6.39/kernel/irq/handle.c:130 handle_irq_event_percpu+0xf8/0x1fc() [ 2.733123] irq 379 handler twl_rtc_interrupt+0x0/0x98 enabled interrupts [ 2.740356] Modules linked in: [ 2.743652] [<c0060d44>] (unwind_backtrace+0x0/0xe0) from [<c00915a0>] (warn_slowpath_common+0x4c/0x64) [ 2.753631] [<c00915a0>] (warn_slowpath_common+0x4c/0x64) from [<c0091638>] (warn_slowpath_fmt+0x2c/0x3c) [ 2.763763] [<c0091638>] (warn_slowpath_fmt+0x2c/0x3c) from [<c00d4b30>] (handle_irq_event_percpu+0xf8/0x1fc) [ 2.774291] [<c00d4b30>] (handle_irq_event_percpu+0xf8/0x1fc) from [<c00d4c70>] (handle_irq_event+0x3c/0x5c) [ 2.784698] [<c00d4c70>] (handle_irq_event+0x3c/0x5c) from [<c00d6f4c>] (handle_edge_irq+0x124/0x160) [ 2.794494] [<c00d6f4c>] (handle_edge_irq+0x124/0x160) from [<c02af40c>] (handle_twl4030_sih+0xac/0xd4) [ 2.804443] [<c02af40c>] (handle_twl4030_sih+0xac/0xd4) from [<c02af2f0>] (twl4030_irq_thread+0xb4/0x108) [ 2.814605] [<c02af2f0>] (twl4030_irq_thread+0xb4/0x108) from [<c00ad888>] (kthread+0x7c/0x84) [ 2.823760] [<c00ad888>] (kthread+0x7c/0x84) from [<c005b094>] (kernel_thread_exit+0x0/0x8) [ 2.832611] ---[ end trace 1b75b31a2719ed1e ]---
-andy
linaro-kernel mailing list linaro-kernel@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-kernel
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
On 2 June 2011 18:55, Nicolas Pitre nicolas.pitre@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-kernel@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-kernel
On 2 June 2011 19:01, Zach Pfeffer zach.pfeffer@linaro.org wrote:
On 2 June 2011 18:55, Nicolas Pitre nicolas.pitre@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
On Thu, Jun 02, 2011 at 09:01:01PM -0500, Zach Pfeffer wrote:
On 2 June 2011 18:55, Nicolas Pitre nicolas.pitre@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>)
On 2 June 2011 21:39, Christian Robottom Reis kiko@linaro.org wrote:
On Thu, Jun 02, 2011 at 09:01:01PM -0500, Zach Pfeffer wrote:
On 2 June 2011 18:55, Nicolas Pitre nicolas.pitre@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>)
Yeah. I see that now. I'm sorry for not getting clarification.
On Thu, 2 Jun 2011, Zach Pfeffer wrote:
On 2 June 2011 18:55, Nicolas Pitre nicolas.pitre@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
On 2 June 2011 22:12, Nicolas Pitre nicolas.pitre@linaro.org wrote:
On Thu, 2 Jun 2011, Zach Pfeffer wrote:
On 2 June 2011 18:55, Nicolas Pitre nicolas.pitre@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.
On Thu, Jun 2, 2011 at 8:55 PM, Nicolas Pitre nicolas.pitre@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,
On 06/03/2011 07:04 AM, Somebody in the thread at some point said:
On Thu, Jun 2, 2011 at 8:55 PM, Nicolas Pitrenicolas.pitre@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.
I wish we could coordinate this a bit better somehow.
I was wandering around rebasing the DSS stuff I have and trying to get something other than 640 x 480 coming on mainline 2.6.39 the last couple of days; I also saw these new DSS build failures in npitre .39 build.
I can see Ricardo is better plugged into the source of these DSS patches than I am and has more experience working on them. But we have some related endeavours ongoing via Jassi's work uplevelling video decode stuff and trying to get workable SGX / PVR integrated.
Does it not make sense to put these patches into LT tree first where it can play alongside whatever other patches are flying around?
Anyway linus HEAD on Panda is otherwise quite nice now, the bluetooth stuff is in there already, WLAN is working well and so on. DSS stuff is still a WIP though.
-Andy
On Fri, Jun 3, 2011 at 4:29 AM, Andy Green andy@warmcat.com wrote:
On 06/03/2011 07:04 AM, Somebody in the thread at some point said:
On Thu, Jun 2, 2011 at 8:55 PM, Nicolas Pitrenicolas.pitre@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.
I wish we could coordinate this a bit better somehow.
I was wandering around rebasing the DSS stuff I have and trying to get something other than 640 x 480 coming on mainline 2.6.39 the last couple of days; I also saw these new DSS build failures in npitre .39 build.
I can see Ricardo is better plugged into the source of these DSS patches than I am and has more experience working on them. But we have some related endeavours ongoing via Jassi's work uplevelling video decode stuff and trying to get workable SGX / PVR integrated.
Is he working in another specific branch/tree?
Does it not make sense to put these patches into LT tree first where it can play alongside whatever other patches are flying around?
Sure, it'll probably be even easier to work with for this moment. Hopefully I'll have some time to work on this in the new few days.
Anyway linus HEAD on Panda is otherwise quite nice now, the bluetooth stuff is in there already, WLAN is working well and so on. DSS stuff is still a WIP though.
Awesome, good to see these improvements there. Hopefully we'll get a more stable wlan and bt this time.
Cheers,
On 06/03/2011 09:28 AM, Somebody in the thread at some point said:
Hi -
I wish we could coordinate this a bit better somehow.
I was wandering around rebasing the DSS stuff I have and trying to get something other than 640 x 480 coming on mainline 2.6.39 the last couple of days; I also saw these new DSS build failures in npitre .39 build.
I can see Ricardo is better plugged into the source of these DSS patches than I am and has more experience working on them. But we have some related endeavours ongoing via Jassi's work uplevelling video decode stuff and trying to get workable SGX / PVR integrated.
Is he working in another specific branch/tree?
At the moment the patchset is bleeding a bit too much over some other things and it's not really ready for normal use. But to get an idea, the "v4l2" branch on the TILT tree has a very early cut of the patches which Jassi was able to get a decode on with Maverick basis (Natty PPA is still showing a broken Requires for libsoundtouch1c2 making it uninstallable).
Does it not make sense to put these patches into LT tree first where it can play alongside whatever other patches are flying around?
Sure, it'll probably be even easier to work with for this moment. Hopefully I'll have some time to work on this in the new few days.
That'd be very cool, I realize you are busy with your own stuff but if you have time to look at SGX / PVR in my tree at the same time that'd be super cool.
Anyway linus HEAD on Panda is otherwise quite nice now, the bluetooth stuff is in there already, WLAN is working well and so on. DSS stuff is still a WIP though.
Awesome, good to see these improvements there. Hopefully we'll get a more stable wlan and bt this time.
I plan to try a backport of the BT stuff that actually got in mainline FWIW on 2.6.38.
-Andy
On 3 June 2011 14:38, Andy Green andy@warmcat.com wrote:
On 06/03/2011 09:28 AM, Somebody in the thread at some point said:
I wish we could coordinate this a bit better somehow.
I was wandering around rebasing the DSS stuff I have and trying to get something other than 640 x 480 coming on mainline 2.6.39 the last couple of days; I also saw these new DSS build failures in npitre .39 build.
I can see Ricardo is better plugged into the source of these DSS patches than I am and has more experience working on them. But we have some related endeavours ongoing via Jassi's work uplevelling video decode stuff and trying to get workable SGX / PVR integrated.
Is he working in another specific branch/tree?
At the moment the patchset is bleeding a bit too much over some other things and it's not really ready for normal use. But to get an idea, the "v4l2" branch on the TILT tree has a very early cut of the patches which Jassi was able to get a decode on with Maverick basis (Natty PPA is still showing a broken Requires for libsoundtouch1c2 making it uninstallable).
I pull Andy's TILT before both starting work as well as emailing him patches. So anytime one sees my patch, it should be safe to assume that was prepared against TILT.
After having Ducati decoded 1080p fwdported from .35, I am trying to fix HDMI audio that was broken in the process. I expect something by during this weekend. After that I'll be cleaning and compacting the patches.
Thanks, -j
On Fri, 3 Jun 2011, Andy Green wrote:
Anyway linus HEAD on Panda is otherwise quite nice now, the bluetooth stuff is in there already, WLAN is working well and so on. DSS stuff is still a WIP though.
If you could suggest a list of commits from Linus HEAD that I could cherry-pick in order to have BT and WLAN working as well in linaro-2.6.39 that would be cool.
Nicolas
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%3Ba=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
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%3Ba=summary
or cloned from either of those:
git://git.linaro.org/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
On 06/04/2011 02:17 PM, 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.
Panda chokes the same way with previously OK omap4_defconfig.
Uncompressing Linux... done, booting the kernel. [ 0.000000] Linux version 2.6.39-panda_reb39+ (agreen@otae.warmcat.com) (gcc version 4.5.1 20101112 (Red Hat 4.5.1-5) (GCC) ) #6 SMP PREEMPT Mon Jun 6 09:04:39 BST 2011 [ 0.000000] CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c5387f [ 0.000000] CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache [ 0.000000] Machine: OMAP4 Panda board [ 0.000000] Reserving 33554432 bytes SDRAM for VRAM [ 0.000000] Memory policy: ECC disabled, Data cache writealloc [ 0.000000] OMAP4430 ES2.1 [ 0.000000] SRAM: Mapped pa 0x40300000 to va 0xfe400000 size: 0xe000 [ 0.000000] powerdomain: waited too long for powerdomain dss_pwrdm to complete transition [ 0.000000] PERCPU: Embedded 8 pages/cpu @c10ea000 s9728 r8192 d14848 u32768 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 109410 [ 0.000000] Kernel command line: console=tty0 console=ttyO2,115200n8 earlycon=ttyO2,115200n8 earlyprintk=1 root=UUID=3f5789f6-fdb2-43cb-abe8-5e064f387200 rootwait ro fixrtc nocompcache vram=32M omapfb.vram=0:24M mem=463M ip=none omapfb.debug=1 [ 0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes) [ 0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [ 0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [ 0.000000] Memory: 430MB 1MB = 431MB total [ 0.000000] Memory: 419652k/419652k available, 54460k reserved, 0K highmem [ 0.000000] Virtual kernel memory layout: [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) [ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB) [ 0.000000] DMA : 0xffc00000 - 0xffe00000 ( 2 MB) [ 0.000000] vmalloc : 0xdd000000 - 0xf8000000 ( 432 MB) [ 0.000000] lowmem : 0xc0000000 - 0xdcf00000 ( 463 MB) [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) [ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB) [ 0.000000] .init : 0xc0008000 - 0xc0050000 ( 288 kB) [ 0.000000] .text : 0xc0050000 - 0xc0757cd4 (7200 kB) [ 0.000000] .data : 0xc0758000 - 0xc07dff68 ( 544 kB) [ 0.000000] Preemptable hierarchical RCU implementation. [ 0.000000] RCU-based detection of stalled CPUs is disabled. [ 0.000000] Verbose stalled-CPUs detection is disabled. [ 0.000000] NR_IRQS:410 [ 0.000000] omap_hwmod: dpll_mpu_m2_ck: missing clockdomain for dpll_mpu_m2_ck. [ 0.000000] OMAP clockevent source: GPTIMER1 at 32768 Hz [ 0.000000] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms [ 0.000000] Console: colour dummy device 80x30 [ 0.000000] console [tty0] enabled [ 0.000000] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [ 0.000000] ... MAX_LOCKDEP_SUBCLASSES: 8 [ 0.000000] ... MAX_LOCK_DEPTH: 48 [ 0.000000] ... MAX_LOCKDEP_KEYS: 8191 [ 0.000000] ... CLASSHASH_SIZE: 4096 [ 0.000000] ... MAX_LOCKDEP_ENTRIES: 16384 [ 0.000000] ... MAX_LOCKDEP_CHAINS: 32768 [ 0.000000] ... CHAINHASH_SIZE: 16384 [ 0.000000] memory used by lock dependency info: 3695 kB [ 0.000000] per task-struct memory footprint: 1152 bytes [ 0.002380] Calibrating delay loop... 2007.19 BogoMIPS (lpj=7839744) [ 0.062591] pid_max: default: 32768 minimum: 301 [ 0.063201] Security Framework initialized [ 0.063568] Mount-cache hash table entries: 512 [ 0.067138] CPU: Testing write buffer coherency: ok [ 0.067962] Calibrating local timer... 491.91MHz. [ 0.109649] L310 cache controller enabled [ 0.109710] l2x0: 16 ways, CACHE_ID 0x410000c4, AUX_CTRL 0x7e470000, Cache size: 1048576 B [ 0.186370] CPU1: Booted secondary processor [ 0.186401] CPU1: Unknown IPI message 0x1 [ 0.216491] Brought up 2 CPUs [ 0.216522] SMP: Total of 2 processors activated (3963.96 BogoMIPS). [ 0.217681] devtmpfs: initialized [ 0.224029] omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for emif_fw [ 0.224060] omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for l3_instr [ 0.224090] omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for l3_main_1 [ 0.224121] omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for l3_main_2 [ 0.224151] omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for l4_abe [ 0.224182] omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for l4_cfg [ 0.224212] omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for l4_per [ 0.224212] omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for l4_wkup [ 0.224243] omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for mpu_private [ 0.224273] omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for dsp [ 0.224304] omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for ipu [ 0.224609] omap_hwmod: l3_div_ck: missing clockdomain for l3_div_ck. [ 0.229980] print_constraints: dummy: [ 0.230773] NET: Registered protocol family 16 [ 0.231292] GPMC revision 6.0 [ 0.235137] omap_device: omap_gpio.0: new worst case activate latency 0: 61035 [ 0.236297] OMAP GPIO hardware version 0.1 [ 0.236907] OMAP GPIO hardware version 0.1 [ 0.237487] OMAP GPIO hardware version 0.1 [ 0.238067] OMAP GPIO hardware version 0.1 [ 0.238616] OMAP GPIO hardware version 0.1 [ 0.239227] OMAP GPIO hardware version 0.1 [ 0.242431] omap_mux_init: Add partition: #1: core, flags: 2 [ 0.243774] omap_mux_init: Add partition: #2: wkup, flags: 2 [ 0.246368] omap_device: omap_uart.0: new worst case deactivate latency 0: 30517 [ 0.246917] omap_device: omap_uart.1: new worst case activate latency 0: 30517 [ 0.257751] pm_dbg_init: only OMAP3 supported [ 0.258270] OMAP DMA hardware revision 0.0 [ 0.293395] bio: create slab <bio-0> at 0 [ 0.295135] print_constraints: vwl1271: 1800 mV [ 0.297515] SCSI subsystem initialized [ 0.301544] usbcore: registered new interface driver usbfs [ 0.302062] usbcore: registered new interface driver hub [ 0.302368] usbcore: registered new device driver usb [ 0.315582] omap_i2c omap_i2c.1: bus 1 rev4.0 at 400 kHz [ 0.318695] Skipping twl internal clock init and using bootloader value (unknown osc rate) [ 0.319641] twl6030: PIH (irq 39) chaining IRQs 368..387 [ 0.321044] print_constraints: VUSB: 3300 mV normal standby [ 0.519531] twl6030_usb twl6030_usb: Initialized TWL6030 USB module [ 0.520935] print_constraints: VMMC: 1200 <--> 3000 mV at 3000 mV normal standby [ 0.522033] print_constraints: VPP: 1800 <--> 2500 mV at 1900 mV normal standby [ 0.523010] print_constraints: VANA: 2100 mV normal standby [ 0.523895] print_constraints: VCXIO: 1800 mV normal standby [ 0.524841] print_constraints: VDAC: 1800 mV normal standby [ 0.525970] print_constraints: VAUX2_6030: 1200 <--> 2800 mV at 1800 mV normal standby [ 0.527099] print_constraints: VAUX3_6030: 1000 <--> 3000 mV at 1200 mV normal standby [ 0.528015] print_constraints: CLK32KG: [ 0.528442] omap_device: omap_i2c.2: new worst case activate latency 0: 30517 [ 0.536407] omap_i2c omap_i2c.2: bus 2 rev4.0 at 400 kHz [ 0.551635] omap_i2c omap_i2c.3: bus 3 rev4.0 at 100 kHz [ 0.566894] omap_i2c omap_i2c.4: bus 4 rev4.0 at 400 kHz [ 0.568695] Advanced Linux Sound Architecture Driver Version 1.0.24. [ 0.570678] Bluetooth: Core ver 2.16 [ 0.570922] NET: Registered protocol family 31 [ 0.570953] Bluetooth: HCI device and connection manager initialized [ 0.571044] Bluetooth: HCI socket layer initialized [ 0.571075] Bluetooth: L2CAP socket layer initialized [ 0.571258] Bluetooth: SCO socket layer initialized [ 0.572326] cfg80211: Calling CRDA to update world regulatory domain [ 0.574737] Switching to clocksource 32k_counter [ 0.575164] Switched to NOHz mode on CPU #1 [ 0.582092] Switched to NOHz mode on CPU #0 [ 0.626464] musb-hdrc: version 6.0, musb-dma, otg (peripheral+host), debug=0 [ 0.626708] omap_device: musb-omap2430.-1: new worst case activate latency 0: 30517 [ 0.627197] musb-hdrc musb-hdrc: USB OTG mode controller at fc0ab000 using DMA, IRQ 124 [ 0.627929] NET: Registered protocol family 2 [ 0.628295] IP route cache hash table entries: 4096 (order: 2, 16384 bytes) [ 0.629302] TCP established hash table entries: 16384 (order: 5, 131072 bytes) [ 0.629913] TCP bind hash table entries: 16384 (order: 7, 655360 bytes) [ 0.633453] TCP: Hash tables configured (established 16384 bind 16384) [ 0.633605] TCP reno registered [ 0.633636] UDP hash table entries: 256 (order: 2, 24576 bytes) [ 0.633789] UDP-Lite hash table entries: 256 (order: 2, 24576 bytes) [ 0.634399] NET: Registered protocol family 1 [ 0.635284] RPC: Registered udp transport module. [ 0.635314] RPC: Registered tcp transport module. [ 0.635314] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 0.635833] Trying to unpack rootfs image as initramfs... [ 0.869995] Freeing initrd memory: 3904K [ 0.870056] NetWinder Floating Point Emulator V0.97 (double precision) [ 1.009246] VFS: Disk quotas dquot_6.5.2 [ 1.009460] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) [ 1.011108] Installing knfsd (copyright (C) 1996 okir@monad.swb.de). [ 1.011718] JFFS2 version 2.2. (NAND) (SUMMARY) © 2001-2006 Red Hat, Inc. [ 1.012176] ROMFS MTD (C) 2007 Red Hat, Inc. [ 1.012268] msgmni has been set to 827 [ 1.014190] io scheduler noop registered [ 1.014221] io scheduler deadline registered [ 1.014312] io scheduler cfq registered (default) [ 1.075042] OMAP DSS rev 4.0 [ 1.079101] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled [ 1.192687] omap_uart.0: ttyO0 at MMIO 0x4806a000 (irq = 104) is a OMAP UART0 [ 1.254699] omap_uart.1: ttyO1 at MMIO 0x4806c000 (irq = 105) is a OMAP UART1 [ 1.317199] omap_uart.2: ttyO2 at MMIO 0x48020000 (irq = 106) is a OMAP UART2 [ 2.245056] console [ttyO2] enabled [ 2.301574] omap_uart.3: ttyO3 at MMIO 0x4806e000 (irq = 102) is a OMAP UART3 [ 2.364654] [drm] Initialized drm 1.1.0 20060810 [ 2.383941] brd: module loaded [ 2.394348] loop: module loaded [ 2.397918] (stk) :sysfs entries created [ 2.402130] (stk) : debugfs entries created [ 2.409484] mtdoops: mtd device (mtddev=name/number) must be supplied [ 2.416595] omap2-nand driver initializing [ 2.421234] OneNAND driver initializing [ 2.428649] usbcore: registered new interface driver asix [ 2.434631] usbcore: registered new interface driver cdc_ether [ 2.441040] usbcore: registered new interface driver smsc95xx [ 2.447387] usbcore: registered new interface driver net1080 [ 2.453582] usbcore: registered new interface driver cdc_subset [ 2.460571] usbcore: registered new interface driver zaurus [ 2.466491] cdc_ncm: 23-Apr-2011 [ 2.470092] usbcore: registered new interface driver cdc_ncm [ 2.476928] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 2.484008] _regulator_get: ehci-omap.0 supply hsusb0 not found, using dummy regulator [ 2.492919] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller [ 2.501312] ehci-omap ehci-omap.0: new USB bus registered, assigned bus number 1 [ 2.509521] ehci-omap ehci-omap.0: irq 109, io mem 0x4a064c00 [ 2.528106] ehci-omap ehci-omap.0: USB 2.0 started, EHCI 1.00 [ 2.534637] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [ 2.541839] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 2.549468] usb usb1: Product: OMAP-EHCI Host Controller [ 2.555175] usb usb1: Manufacturer: Linux 2.6.39-panda_reb39+ ehci_hcd [ 2.562103] usb usb1: SerialNumber: ehci-omap.0 [ 2.569610] hub 1-0:1.0: USB hub found [ 2.573669] hub 1-0:1.0: 3 ports detected [ 2.606414] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 2.613098] ohci-omap3 ohci-omap3.0: OMAP3 OHCI Host Controller [ 2.619964] ohci-omap3 ohci-omap3.0: new USB bus registered, assigned bus number 2 [ 2.628082] ohci-omap3 ohci-omap3.0: irq 108, io mem 0x4a064800 [ 2.711822] usb usb2: New USB device found, idVendor=1d6b, idProduct=0001 [ 2.718994] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 2.726654] usb usb2: Product: OMAP3 OHCI Host Controller [ 2.732360] usb usb2: Manufacturer: Linux 2.6.39-panda_reb39+ ohci_hcd [ 2.739440] usb usb2: SerialNumber: ohci-omap3.0 [ 2.745483] hub 2-0:1.0: USB hub found [ 2.749511] hub 2-0:1.0: 3 ports detected [ 2.755096] usbcore: registered new interface driver cdc_wdm [ 2.761077] Initializing USB Mass Storage driver... [ 2.766571] usbcore: registered new interface driver usb-storage [ 2.772979] USB Mass Storage support registered. [ 2.778869] usbcore: registered new interface driver libusual [ 2.903137] usb 1-1: new high speed USB device number 2 using ehci-omap [ 3.254913] usb 1-1: New USB device found, idVendor=0424, idProduct=9514 [ 3.261993] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 3.271087] hub 1-1:1.0: USB hub found [ 3.275268] hub 1-1:1.0: 5 ports detected [ 3.341613] usbcore: registered new interface driver usbtest [ 3.348602] mousedev: PS/2 mouse device common for all mice [ 3.358886] twl_rtc twl_rtc: rtc core: registered twl_rtc as rtc0 [ 3.366851] i2c /dev entries driver [ 3.373260] lirc_dev: IR Remote Control driver registered, major 251 [ 3.380157] IR NEC protocol handler initialized [ 3.384948] IR RC5(x) protocol handler initialized [ 3.390014] IR RC6 protocol handler initialized [ 3.394775] IR JVC protocol handler initialized [ 3.399566] IR Sony protocol handler initialized [ 3.404479] IR RC5 (streamzap) protocol handler initialized [ 3.410339] IR LIRC bridge handler initialized [ 3.415039] Linux video capture interface: v2.00 [ 3.420349] Driver for 1-wire Dallas network protocol. [ 3.427581] OMAP Watchdog Timer Rev 0x00: initial timeout 60 sec [ 3.434478] Bluetooth: HCI UART driver ver 2.2 [ 3.439178] Bluetooth: HCI H4 protocol initialized [ 3.444335] Bluetooth: HCI BCSP protocol initialized [ 3.449707] Bluetooth: HCILL protocol initialized [ 3.454803] Bluetooth: Bluetooth Driver for TI WiLink - Version 1.0 [ 3.462097] cpuidle: using governor ladder [ 3.466461] cpuidle: using governor menu [ 3.473419] _regulator_get: omap_hsmmc.0 supply vmmc_aux not found, using dummy regulator [ 3.484283] _regulator_get: omap_hsmmc.4 supply vmmc_aux not found, using dummy regulator [ 3.494659] usbcore: registered new interface driver usbhid [ 3.500549] usbhid: USB HID core driver [ 3.508850] ALSA device list: [ 3.511962] No soundcards found. [ 3.515899] oprofile: hardware counters not available [ 3.521270] oprofile: using timer interrupt. [ 3.526062] TCP cubic registered [ 3.529479] Initializing XFRM netlink socket [ 3.534088] NET: Registered protocol family 17 [ 3.539031] NET: Registered protocol family 15 [ 3.544128] Bluetooth: RFCOMM TTY layer initialized [ 3.550323] Bluetooth: RFCOMM socket layer initialized [ 3.557739] Bluetooth: RFCOMM ver 1.11 [ 3.561920] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 3.567718] Bluetooth: BNEP filters: protocol multicast [ 3.573333] Bluetooth: HIDP (Human Interface Emulation) ver 1.2 [ 3.580139] lib80211: common routines for IEEE802.11 drivers [ 3.586273] Registering the dns_resolver key type [ 3.594818] VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 1 [ 3.602996] ThumbEE CPU extension supported. [ 3.607604] Registering SWP/SWPB emulation handler [ 3.620208] Power Management for TI OMAP4. [ 3.624755] sr_init: No PMIC hook to init smartreflex [ 3.630340] smartreflex smartreflex.0: omap_sr_probe: SmartReflex driver initialized [ 3.638824] smartreflex smartreflex.1: omap_sr_probe: SmartReflex driver initialized [ 3.647338] smartreflex smartreflex.2: omap_sr_probe: SmartReflex driver initialized [ 3.655914] usb 1-1.1: new high speed USB device number 3 using ehci-omap [ 3.663635] SmartReflex Class3 initialized [ 3.673217] mmc0: host does not support reading read-only switch. assuming write-enable. [ 3.707855] mmc0: new high speed SDHC card at address d555 [ 3.715362] mmcblk0: mmc0:d555 SU08G 7.60 GiB [ 3.721740] mmcblk0: detected capacity change from 0 to 8168931328 [ 3.729980] mmcblk0: p1 p2 [ 3.825042] usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00 [ 3.832305] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 3.843627] smsc95xx v1.0.4 [ 3.862121] mmc1: card claims to support voltages below the defined range. These will be ignored. [ 3.904846] mmc1: queuing unknown CIS tuple 0x91 (3 bytes) [ 3.912445] mmc1: new SDIO card at address 0001 [ 3.957794] Console: switching to colour frame buffer device 80x30 [ 3.971893] omapdss DPI: Could not find exact pixel clock. Requested 23500 kHz, got 23630 kHz [ 3.989196] regulator_init_complete: CLK32KG: incomplete constraints, leaving on [ 4.002502] regulator_init_complete: VAUX3_6030: incomplete constraints, leaving on [ 4.016174] regulator_init_complete: VAUX2_6030: incomplete constraints, leaving on [ 4.029815] regulator_init_complete: VDAC: incomplete constraints, leaving on [ 4.040313] regulator_init_complete: VCXIO: incomplete constraints, leaving on [ 4.053436] regulator_init_complete: VANA: incomplete constraints, leaving on [ 4.063934] regulator_init_complete: VPP: incomplete constraints, leaving on [ 4.074920] regulator_init_complete: VUSB: incomplete constraints, leaving on [ 4.086059] twl_rtc twl_rtc: setting system clock to 2000-01-01 00:39:34 UTC (946687174) [ 4.100006] omap_vout omap_vout: probed for an unknown device [ 4.111694] Freeing init memory: 288K [ 4.126617] smsc95xx 1-1.1:1.0: eth0: Features changed: 0x00004808 -> 0x00004008 [ 4.140594] smsc95xx 1-1.1:1.0: eth0: register 'smsc95xx' at usb-ehci-omap.0-1.1, smsc95xx USB 2.0 Ethernet, 2e:40:70:f0:12:06 Loading, please wait... [ 4.282409] udev[685]: starting version 167 Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Running /scripts/local-premount ... done. FATAL: Could not load /lib/modules/2.6.39-panda_reb39+/modules.dep: No such file or directory [ 4.967346] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null) Begin: Running /scripts/local-bottom ... done. done. Begin: Running /scripts/init-bottom ... done. init: ureadahead main process (801) terminated with status 5
The .config I'm using is that described on the wiki at https://wiki.linaro.org/Resources/HowTo/KernelDeploy#From_Linaro_sources
with omap2plus_defconfig, after adding EXT4, the userland blows SIGILL -- and just SIGILL, not segfaults -- in an unpredictable but apparently deterministic way. For example ls at bash prompt is OK but ls -l is SIGILL.
The rootfs is linaro Ubuntu autobuilt stuff from a few weeks ago that has been reliable until this kernel.
I googled around and saw some other guy met this in April with no obvious result. It's possibly toolchain related since I am using gcc 4.5.1 Fedora ARM cross toolchain, but that's a bit subtle since omap4_defconfig is OK and expecting that to work is legit. Linus HEAD works fine with it too.
http://xbmc-installer.pastebin.ca/2045257 http://pandaboard.org/pbirclogs/index.php?date=2011-04-11#T23:14:08
I attempted to adapt a few things in omap2plus_defconfig like CONFIG_EMBEDDED to omap4_defconfig style but it didn't help; in any event omap4_defconfig is broken differently.
I have some dss patches on top but I rewound them for now and just pushed three small patches on top to my master (moving the old master to "tilt-linux-linaro-2.6.38").
-Andy
On Mon, 6 Jun 2011, Andy Green wrote:
On 06/04/2011 02:17 PM, 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.
Panda chokes the same way with previously OK omap4_defconfig.
[...]
The .config I'm using is that described on the wiki at https://wiki.linaro.org/Resources/HowTo/KernelDeploy#From_Linaro_sources
with omap2plus_defconfig, after adding EXT4, the userland blows SIGILL -- and just SIGILL, not segfaults -- in an unpredictable but apparently deterministic way. For example ls at bash prompt is OK but ls -l is SIGILL.
The rootfs is linaro Ubuntu autobuilt stuff from a few weeks ago that has been reliable until this kernel.
I googled around and saw some other guy met this in April with no obvious result. It's possibly toolchain related since I am using gcc 4.5.1 Fedora ARM cross toolchain, but that's a bit subtle since omap4_defconfig is OK and expecting that to work is legit. Linus HEAD works fine with it too.
http://xbmc-installer.pastebin.ca/2045257 http://pandaboard.org/pbirclogs/index.php?date=2011-04-11#T23:14:08
I attempted to adapt a few things in omap2plus_defconfig like CONFIG_EMBEDDED to omap4_defconfig style but it didn't help; in any event omap4_defconfig is broken differently.
I have some dss patches on top but I rewound them for now and just pushed three small patches on top to my master (moving the old master to "tilt-linux-linaro-2.6.38").
Can you test with plain v2.6.39 to see if those problems are present, and if no then it would be interesting to see the result of a git bisect run.
Nicolas
On Mon, Jun 6, 2011 at 2:19 PM, Nicolas Pitre nicolas.pitre@linaro.org wrote:
On Mon, 6 Jun 2011, Andy Green wrote:
On 06/04/2011 02:17 PM, 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.
Panda chokes the same way with previously OK omap4_defconfig.
I haven't found a precise cause yet, but this definitely looks like it could be a Thumb-2 related issue.
An ARM kernel for Panda boots (without device tree, anyway), but a Thumb kernel hangs as you describe. This is similar to the behaviour I observed on mx51evk.
[...]
The .config I'm using is that described on the wiki at https://wiki.linaro.org/Resources/HowTo/KernelDeploy#From_Linaro_sources
with omap2plus_defconfig, after adding EXT4, the userland blows SIGILL -- and just SIGILL, not segfaults -- in an unpredictable but apparently deterministic way. For example ls at bash prompt is OK but ls -l is SIGILL.
The rootfs is linaro Ubuntu autobuilt stuff from a few weeks ago that has been reliable until this kernel.
I googled around and saw some other guy met this in April with no obvious result. It's possibly toolchain related since I am using gcc 4.5.1 Fedora ARM cross toolchain, but that's a bit subtle since omap4_defconfig is OK and expecting that to work is legit. Linus HEAD works fine with it too.
http://xbmc-installer.pastebin.ca/2045257 http://pandaboard.org/pbirclogs/index.php?date=2011-04-11#T23:14:08
I attempted to adapt a few things in omap2plus_defconfig like CONFIG_EMBEDDED to omap4_defconfig style but it didn't help; in any event omap4_defconfig is broken differently.
I have some dss patches on top but I rewound them for now and just pushed three small patches on top to my master (moving the old master to "tilt-linux-linaro-2.6.38").
Can you test with plain v2.6.39 to see if those problems are present, and if no then it would be interesting to see the result of a git bisect run.
v2.6.39 does work for me in Thumb-2 on OMAP, so I will have a go at bisecting tomorrow...
Cheers ---Dave
On Sat, Jun 4, 2011 at 2:17 PM, Tixy tixy@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%3Ba=summary
or cloned from either of those:
git://git.linaro.org/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
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
On Mon, 2011-06-06 at 17:44 +0100, Dave Martin wrote:
On Sat, Jun 4, 2011 at 2:17 PM, Tixy tixy@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%3Ba=summary
or cloned from either of those:
git://git.linaro.org/kernel/linux-linaro-2.6.39.git
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.
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?
$ make ARCH=arm O=panda omap2plus_defconfig $ grep THUMB panda/.config CONFIG_ARM_THUMB=y CONFIG_ARM_THUMBEE=y
-Andy
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
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? 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
I just confirmed that's the case with current linux-linaro-2.6.39. Am I going nuts :?)
-Andy
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.
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
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
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_ 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
On Tue, Jun 7, 2011 at 5:33 AM, Dave Martin dave.martin@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-kernel@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-kernel
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
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.doan@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
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.
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
On Wed, Jun 8, 2011 at 4:31 AM, Nicolas Pitre nicolas.pitre@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
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
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
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
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
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%3Ba=patch%3B...
... 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
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)
... [ 1.816986] VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 1 [ 1.825347] ThumbEE CPU extension supported. ... [ 2.262329] Freeing init memory: 292K init: hwclock main process (519) killed by ILL signal init: ureadahead main process (520) terminated with status 5 init: plymouth main process (521) killed by ILL signal udevd[552]: failed to create queue file: No such file or directory
udevd[552]: error creating queue file
init: udev main process (552) terminated with status 1 init: udev main process ended, respawning init: udevmonitor main process (558) terminated with status 2 udevadm[822]: error sending message: Connection refused
init: udev-fallback-graphics main process (823) terminated with status 1 init: plymouth-splash main process (825) killed by ILL signal
-Andy
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
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
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
On Tue, Jun 07, 2011 at 10:01:48AM +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? 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.
Yes, starting from omap2plus_defconfig, you have to turn off the omap2 support in order for it to be possible to enable CONFIG_THUMB2_KERNEL.
We should probably document this-- I'll take a look at the wiki page.
Cheers ---Dave
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
I just confirmed that's the case with current linux-linaro-2.6.39. Am I going nuts :?)
-Andy
-
Andy Doan -
Andy Green -
Andy Green -
Christian Robottom Reis -
Dave Martin -
Deepak Saxena -
Jaswinder Singh -
John Rigby -
john stultz -
Nicolas Pitre -
Ricardo Salveti -
Tixy -
Zach Pfeffer