Re: Trouble with newer kernels on Gumstix Overo boards
Daniel Mack wrote: Well, it doesn't really affect me as I just use this as a development platform for now. But please consider that there is hardware out there which gets software updates through automated download and install procedures. In such cases, you want as little dependencies between the bootloader and the kernel, so you can boot both older and newer If you want *minimal* dependency, then a compiled-in command line is the way to go and the bootloader only providing a few board identifying tags kernels (and full software distribution images) with no pain. Or maybe quickly switch from one version to the other for testing. Depending on the complexity of the system, the bootloader might also add extra parameters to the cmdline dynamically. AFAIK there is way to have the bootloader provided cmdline appended to the compiled-in one The serial console change breaks this approach, at it forces the kernel to ship its own CMDLINE and override the one the bootloader provides. I'm sure this is a problem that affects people out there. FWIW, for our firmware update deployment it's not a problem at all, since we do *not* want to rely on a kernel commandline provided by the bootloader for the exact same reason. Kernels change and thus the kernel command line belongs to the kernel. What does not change is e.g. the board id or revision or mem size, that (and only that) is provided by the bootloader to the kernel. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Trouble with newer kernels on Gumstix Overo boards
* Daniel Mack zon...@gmail.com [110617 18:06]: On Fri, Jun 17, 2011 at 4:03 PM, Gadiyar, Anand gadi...@ti.com wrote: console=ttyS2,115200 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait Here is your problem. We now use the OMAP-serial driver for the UARTs. Which breaks backward-compatibility with bootloaders set up for older kernels. Now I have to deploy kernels with CONFIG_CMDLINE_FORCE=y. Was that really necessary? In most cases you can just setenv cmdline then saveenv in u-boot. Who knows, maybe at some point we can make 8250.c behave with runtime PM and Linux generic DMA API, but that might take a while before we get there :) Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Trouble with newer kernels on Gumstix Overo boards
On Tue, Jun 21, 2011 at 9:22 AM, Tony Lindgren t...@atomide.com wrote: * Daniel Mack zon...@gmail.com [110617 18:06]: On Fri, Jun 17, 2011 at 4:03 PM, Gadiyar, Anand gadi...@ti.com wrote: console=ttyS2,115200 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait Here is your problem. We now use the OMAP-serial driver for the UARTs. Which breaks backward-compatibility with bootloaders set up for older kernels. Now I have to deploy kernels with CONFIG_CMDLINE_FORCE=y. Was that really necessary? In most cases you can just setenv cmdline then saveenv in u-boot. Well, it doesn't really affect me as I just use this as a development platform for now. But please consider that there is hardware out there which gets software updates through automated download and install procedures. In such cases, you want as little dependencies between the bootloader and the kernel, so you can boot both older and newer kernels (and full software distribution images) with no pain. Or maybe quickly switch from one version to the other for testing. Depending on the complexity of the system, the bootloader might also add extra parameters to the cmdline dynamically. The serial console change breaks this approach, at it forces the kernel to ship its own CMDLINE and override the one the bootloader provides. I'm sure this is a problem that affects people out there. Daniel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Trouble with newer kernels on Gumstix Overo boards
On Mon, Jun 20, 2011 at 3:31 PM, Yegor Yefremov yegor_s...@visionsystems.de wrote: Am 17.06.2011 17:11, schrieb Daniel Mack: On Fri, Jun 17, 2011 at 4:03 PM, Gadiyar, Anand gadi...@ti.com wrote: console=ttyS2,115200 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait Here is your problem. We now use the OMAP-serial driver for the UARTs. Which breaks backward-compatibility with bootloaders set up for older kernels. Now I have to deploy kernels with CONFIG_CMDLINE_FORCE=y. Was that really necessary? Change the ttyS2 to ttyO2 and you should be fine. You're right, that did the trick. Thanks a lot! Are you using some extra patches? I have a custom board based on am3517 SoC and I have much more errors during booting as I can see from your boot log. I have no problems booting 2.6.32/37 though. Any idea? I don't use any extra patches. Just a plain 3.0.0-rc3 from Linus' master branch plus the patch I've sent some days ago to this list. With that setup, and console=ttyO2, my systems runs just fine. Daniel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Trouble with newer kernels on Gumstix Overo boards
Am 17.06.2011 17:11, schrieb Daniel Mack: On Fri, Jun 17, 2011 at 4:03 PM, Gadiyar, Anand gadi...@ti.com wrote: console=ttyS2,115200 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait Here is your problem. We now use the OMAP-serial driver for the UARTs. Which breaks backward-compatibility with bootloaders set up for older kernels. Now I have to deploy kernels with CONFIG_CMDLINE_FORCE=y. Was that really necessary? Change the ttyS2 to ttyO2 and you should be fine. You're right, that did the trick. Thanks a lot! Are you using some extra patches? I have a custom board based on am3517 SoC and I have much more errors during booting as I can see from your boot log. I have no problems booting 2.6.32/37 though. Any idea? Linux version 3.0.0-rc3-11085-g0a28368 () (gcc version 4.5.2 (Buildroot 2011.05-git-00157-gf4c06f4-dirty) ) #25 Mon Jun 20 15:24:30 CEST 2011 CPU: ARMv7 Processor [411fc087] revision 7 (ARMv7), cr=10c53c7f CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: OMAP3517/AM3517 EVM Memory policy: ECC disabled, Data cache writeback AM3517 ES1.1 (l2cache iva sgx neon isp ) SRAM: Mapped pa 0x4020 to va 0xfe40 size: 0x1 Clocking rate (Crystal/Core/MPU): 26.0/332/500 MHz Reprogramming SDRC clock to 33200 Hz dpll3_m2_clk rate change failed: -22 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024 Kernel command line: root=/dev/nfs nfsroot=192.168.1.127:/home/sp860dev/Projects/adlink/nfs/ ip=192.168.1.235:192.168.1.127:192.168.1.1:255.255.255.0::eth0:off rw console=ttyO2,115200n8 PID hash table entries: 1024 (order: 0, 4096 bytes) Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 256MB = 256MB total Memory: 249556k/249556k available, 12588k reserved, 0K highmem Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xfff0 - 0xfffe ( 896 kB) DMA : 0xffc0 - 0xffe0 ( 2 MB) vmalloc : 0xd080 - 0xf800 ( 632 MB) lowmem : 0xc000 - 0xd000 ( 256 MB) modules : 0xbf00 - 0xc000 ( 16 MB) .init : 0xc0008000 - 0xc0033000 ( 172 kB) .text : 0xc0033000 - 0xc049c900 (4519 kB) .data : 0xc049e000 - 0xc04e3e00 ( 280 kB) NR_IRQS:410 IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 interrupts Total of 96 interrupts on 1 active controller OMAP clockevent source: GPTIMER1 at 32768 Hz sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms Console: colour dummy device 80x30 Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar ... MAX_LOCKDEP_SUBCLASSES: 8 ... MAX_LOCK_DEPTH: 48 ... MAX_LOCKDEP_KEYS:8191 ... CLASSHASH_SIZE: 4096 ... MAX_LOCKDEP_ENTRIES: 16384 ... MAX_LOCKDEP_CHAINS: 32768 ... CHAINHASH_SIZE: 16384 memory used by lock dependency info: 3695 kB per task-struct memory footprint: 1152 bytes Calibrating delay loop... 331.40 BogoMIPS (lpj=1296384) pid_max: default: 32768 minimum: 301 Security Framework initialized Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for l4_core omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for l4_per omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for l4_wkup omap_hwmod: gpt12_fck: missing clockdomain for gpt12_fck. omap_hwmod: sr1_hwmod: cannot clk_get main_clk sr1_fck omap_hwmod: sr1_hwmod: cannot clk_get interface_clk sr_l4_ick [ cut here ] WARNING: at arch/arm/mach-omap2/omap_hwmod.c:1764 omap_hwmod_setup_all+0x60/0x98() omap_hwmod: omap_hwmod_setup_all: _init_clocks failed [c0042764] (unwind_backtrace+0x0/0xe4) from [c0062c30] (warn_slowpath_common+0x48/0x60) [c0062c30] (warn_slowpath_common+0x48/0x60) from [c0062c8c] (warn_slowpath_fmt+0x2c/0x3c) [c0062c8c] (warn_slowpath_fmt+0x2c/0x3c) from [c00100e0] (omap_hwmod_setup_all+0x60/0x98) [c00100e0] (omap_hwmod_setup_all+0x60/0x98) from [c000894c] (do_one_initcall+0x9c/0x170) [c000894c] (do_one_initcall+0x9c/0x170) from [c0008ab0] (kernel_init+0x90/0x13c) [c0008ab0] (kernel_init+0x90/0x13c) from [c003e1b8] (kernel_thread_exit+0x0/0x8) ---[ end trace 1b75b31a2719ed1c ]--- omap_hwmod: i2c1: softreset failed (waited 1 usec) omap_hwmod: i2c2: softreset failed (waited 1 usec) omap_hwmod: i2c3: softreset failed (waited 1 usec) print_constraints: dummy: NET: Registered protocol family 16 GPMC revision 5.0 [ cut here ] WARNING: at arch/arm/mach-omap2/omap_hwmod.c:1231 _enable+0x38/0x148() omap_hwmod: gpio1: enabled state can only be entered from initialized, idle, or disabled state [c0042764] (unwind_backtrace+0x0/0xe4) from [c0062c30] (warn_slowpath_common+0x48/0x60) [c0062c30] (warn_slowpath_common+0x48/0x60) from [c0062c8c] (warn_slowpath_fmt+0x2c/0x3c) [c0062c8c] (warn_slowpath_fmt+0x2c/0x3c) from
RE: Trouble with newer kernels on Gumstix Overo boards
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Yegor Yefremov Sent: Monday, June 20, 2011 7:02 PM To: Daniel Mack Cc: Gadiyar, Anand; Tony Lindgren; linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: Trouble with newer kernels on Gumstix Overo boards [snip]...[snip] Are you using some extra patches? I have a custom board based on am3517 SoC and I have much more errors during booting as I can see from your boot log. I have no problems booting 2.6.32/37 though. Any idea? [sp] You may want to follow this thread: http://marc.info/?t=12986417803r=1w=2 It was few months ago, and I am not sure if I tested updated patch(es) working. But, something to verify... ~sanjeev [snip]...[snip] -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Trouble with newer kernels on Gumstix Overo boards
Are you using some extra patches? I have a custom board based on am3517 SoC and I have much more errors during booting as I can see from your boot log. I have no problems booting 2.6.32/37 though. Any idea? [sp] You may want to follow this thread: http://marc.info/?t=12986417803r=1w=2 It was few months ago, and I am not sure if I tested updated patch(es) working. But, something to verify... I've checked those patches from Benoit, but they seem to be already applied. Best regards, Yegor -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Trouble with newer kernels on Gumstix Overo boards
Daniel Mack wrote: Hi Tony et al, I'm having problems booting newer kernels on a Gumstix Overo board. I enabled CONFIG_EARLY_PRINTK to see any messages at all, and see a number of warnings first and then lots of garbled binary junk once the UART is set up. This is Linus' current master branch plus your latest fixes from git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git fixes Uncompressing Linux... done, booting the kernel. [0.00] Linux version 3.0.0-rc3-00209-g64db347-dirty (daniel@jup) (gcc version 4.4.5 (Buildroot 2010.11-git) ) #24 SMP Fri Jun 17 15:42:59 CEST 2011 [0.00] CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c53c7f [0.00] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache [0.00] Machine: Gumstix Overo [0.00] Ignoring tag cmdline (using the default kernel command line) [0.00] bootconsole [earlycon0] enabled [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] OMAP3503 ES3.1 (l2cache neon isp ) [0.00] SRAM: Mapped pa 0x4020 to va 0xfe40 size: 0x1 [0.00] On node 0 totalpages: 65536 [0.00] free_area_init_node: node 0, pgdat c065e9e0, node_mem_map c0bb5000 [0.00] Normal zone: 512 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 65024 pages, LIFO batch:15 [0.00] Clocking rate (Crystal/Core/MPU): 26.0/331/500 MHz [0.00] Reprogramming SDRC clock to 331882352 Hz [0.00] PERCPU: Embedded 7 pages/cpu @c0dba000 s5952 r8192 d14528 u32768 [0.00] pcpu-alloc: s5952 r8192 d14528 u32768 alloc=8*4096 [0.00] pcpu-alloc: [0] 0 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024 [0.00] Kernel command line: debug earlyprintk console=ttyS2,115200 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait Here is your problem. We now use the OMAP-serial driver for the UARTs. Change the ttyS2 to ttyO2 and you should be fine. - Anand -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Trouble with newer kernels on Gumstix Overo boards
On Fri, Jun 17, 2011 at 4:03 PM, Gadiyar, Anand gadi...@ti.com wrote: console=ttyS2,115200 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait Here is your problem. We now use the OMAP-serial driver for the UARTs. Which breaks backward-compatibility with bootloaders set up for older kernels. Now I have to deploy kernels with CONFIG_CMDLINE_FORCE=y. Was that really necessary? Change the ttyS2 to ttyO2 and you should be fine. You're right, that did the trick. Thanks a lot! Daniel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
