* OMAP baseline test results for v3.8-rc4 @ 2013-01-20 21:38 ` Paul Walmsley 0 siblings, 0 replies; 64+ messages in thread From: Paul Walmsley @ 2013-01-20 21:38 UTC (permalink / raw) To: linux-omap; +Cc: linux-arm-kernel Here are some basic OMAP test results for Linux v3.8-rc4. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.8-rc4/20130120122039/ Test summary ------------ Boot to userspace: Pass ( 9/11): 2420n800, 2430sdp, 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm, 4430es2panda, 5912osk, 4460pandaes FAIL ( 2/11): am335xbone, cmt3517 PM ret/off, suspend + dynamic idle: Pass (3/3): 3530es3beagle, 3730beaglexm, 37xxevm PM ret, suspend + dynamic idle: Pass (1/2): 4460pandaes FAIL (1/2): 4430es2panda PM ret, dynamic idle: FAIL (1/1): 2430sdp Failing tests: fixed by posted patches -------------------------------------- Other: * 2420N800: powers down 30 seconds after boot - Presumably due to missing CBUS patches for watchdog control - http://lkml.org/lkml/2012/9/3/265 - http://marc.info/?l=linux-omap&m=135274739624125&w=2 - http://marc.info/?l=linux-omap&m=135664195831104&w=2 Failing tests: needing investigation ------------------------------------ Boot tests: * am335xbone: hangs after "Starting kernel" - Cause unknown - http://www.mail-archive.com/linux-omap@vger.kernel.org/msg82297.html * 3517EVM & CM-T3517: boot hangs with NFS root - Likely some Kconfig, board file, and PM issues with EMAC - Longstanding bug * CM-T3517: boot hangs with MMC root - Due to missing MMC setup in board file - http://www.spinics.net/lists/arm-kernel/msg211471.html Boot warnings: * 3530es3beagle, 3730beaglexm, 37xxevm: nand_scan_ident() warning - "at drivers/mtd/nand/nand_base.c:2861 nand_scan_ident+0xdb4/0xf90()" - http://marc.info/?l=linux-omap&m=135630897110185&w=2 * CM-T3517: L3 in-band error with IPSS during boot - Cause unknown but see http://marc.info/?l=linux-omap&m=134833869730129&w=2 - Longstanding issue; does not occur on the 3517EVM PM tests: * 2430sdp: pwrdm state mismatch(dsp_pwrdm) 0 != 3 - need to doublecheck wakeup dependencies * 2430sdp: power domains not entering retention - Cause unknown * 4430es2panda, 4460pandaes: pwrdm state mismatch on CAM, DSS, ABE * 4460pandaes: pwrdm state mismatch on IVAHD, TESLA * 4430es2panda: CORE, TESLA, IVAHD, L3INIT didn't enter target state - Probably due to lack of reset code for M3, DSP, SL2IF, FSUSB per discussion with Tero Kristo - Likely dependent on the bootloader version - fails with 2012.07-00136-g755de79 * 3730 Beagle XM: does not serial wake from off-idle suspend when console UART doesn't clock gate ("debug ignore_loglevel") - Cause unknown - Not yet part of the automated test suite - Re-tested at v3.7; still failing: http://www.pwsan.com/omap/transcripts/20121211-3730beaglexm-3.7-pm-offmode-fail-debug.txt Other: * 4430es2panda: omap_hwmod: l3_instr: _wait_target_disable failed - Unknown cause; could be due to the lack of hierarchical enable/disable in hwmod code - Jon Hunter reports this does not appear with the same X-loader/bootloader on his 4430ES2.3 Panda, so could be ES-level dependent Failing tests: needing local investigation (may be due to testbed issues) ------------------------------------------------------------------------- Boot tests: * AM335x Beaglebone: omap2plus_defconfig kernels don't boot - May be fixed now, pending retest: - http://marc.info/?l=linux-omap&m=135082257727502&w=2 - Not yet part of the automated test suite - Nishanth Menon & Vaibhav Hiremath report that it works for them * May be due to an old U-boot with FDT support problems used here? Pending local investigation and re-test Problems reported by others --------------------------- * I2C intermittent failures on N900; can break boot - "omap_i2c omap_i2c.1: timeout waiting for bus ready" - Reported by Aaro Koskinen - http://www.spinics.net/lists/arm-kernel/msg216859.html * 2420H4: reports "Could not set MPU rate to 4294MHz" on reboot - Reported and fixed by Jon Hunter - http://www.spinics.net/lists/arm-kernel/msg216121.html -------------------------------------------------------------- Branch: test_v3.8-rc4 Test-Serial: 20130120122039 Commit-ID: 7d1f9aeff1ee4a20b1aeb377dd0f579fe9647619 Test-Target-Board-Count: 11 ^ permalink raw reply [flat|nested] 64+ messages in thread
* OMAP baseline test results for v3.8-rc4 @ 2013-01-20 21:38 ` Paul Walmsley 0 siblings, 0 replies; 64+ messages in thread From: Paul Walmsley @ 2013-01-20 21:38 UTC (permalink / raw) To: linux-arm-kernel Here are some basic OMAP test results for Linux v3.8-rc4. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.8-rc4/20130120122039/ Test summary ------------ Boot to userspace: Pass ( 9/11): 2420n800, 2430sdp, 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm, 4430es2panda, 5912osk, 4460pandaes FAIL ( 2/11): am335xbone, cmt3517 PM ret/off, suspend + dynamic idle: Pass (3/3): 3530es3beagle, 3730beaglexm, 37xxevm PM ret, suspend + dynamic idle: Pass (1/2): 4460pandaes FAIL (1/2): 4430es2panda PM ret, dynamic idle: FAIL (1/1): 2430sdp Failing tests: fixed by posted patches -------------------------------------- Other: * 2420N800: powers down 30 seconds after boot - Presumably due to missing CBUS patches for watchdog control - http://lkml.org/lkml/2012/9/3/265 - http://marc.info/?l=linux-omap&m=135274739624125&w=2 - http://marc.info/?l=linux-omap&m=135664195831104&w=2 Failing tests: needing investigation ------------------------------------ Boot tests: * am335xbone: hangs after "Starting kernel" - Cause unknown - http://www.mail-archive.com/linux-omap at vger.kernel.org/msg82297.html * 3517EVM & CM-T3517: boot hangs with NFS root - Likely some Kconfig, board file, and PM issues with EMAC - Longstanding bug * CM-T3517: boot hangs with MMC root - Due to missing MMC setup in board file - http://www.spinics.net/lists/arm-kernel/msg211471.html Boot warnings: * 3530es3beagle, 3730beaglexm, 37xxevm: nand_scan_ident() warning - "at drivers/mtd/nand/nand_base.c:2861 nand_scan_ident+0xdb4/0xf90()" - http://marc.info/?l=linux-omap&m=135630897110185&w=2 * CM-T3517: L3 in-band error with IPSS during boot - Cause unknown but see http://marc.info/?l=linux-omap&m=134833869730129&w=2 - Longstanding issue; does not occur on the 3517EVM PM tests: * 2430sdp: pwrdm state mismatch(dsp_pwrdm) 0 != 3 - need to doublecheck wakeup dependencies * 2430sdp: power domains not entering retention - Cause unknown * 4430es2panda, 4460pandaes: pwrdm state mismatch on CAM, DSS, ABE * 4460pandaes: pwrdm state mismatch on IVAHD, TESLA * 4430es2panda: CORE, TESLA, IVAHD, L3INIT didn't enter target state - Probably due to lack of reset code for M3, DSP, SL2IF, FSUSB per discussion with Tero Kristo - Likely dependent on the bootloader version - fails with 2012.07-00136-g755de79 * 3730 Beagle XM: does not serial wake from off-idle suspend when console UART doesn't clock gate ("debug ignore_loglevel") - Cause unknown - Not yet part of the automated test suite - Re-tested at v3.7; still failing: http://www.pwsan.com/omap/transcripts/20121211-3730beaglexm-3.7-pm-offmode-fail-debug.txt Other: * 4430es2panda: omap_hwmod: l3_instr: _wait_target_disable failed - Unknown cause; could be due to the lack of hierarchical enable/disable in hwmod code - Jon Hunter reports this does not appear with the same X-loader/bootloader on his 4430ES2.3 Panda, so could be ES-level dependent Failing tests: needing local investigation (may be due to testbed issues) ------------------------------------------------------------------------- Boot tests: * AM335x Beaglebone: omap2plus_defconfig kernels don't boot - May be fixed now, pending retest: - http://marc.info/?l=linux-omap&m=135082257727502&w=2 - Not yet part of the automated test suite - Nishanth Menon & Vaibhav Hiremath report that it works for them * May be due to an old U-boot with FDT support problems used here? Pending local investigation and re-test Problems reported by others --------------------------- * I2C intermittent failures on N900; can break boot - "omap_i2c omap_i2c.1: timeout waiting for bus ready" - Reported by Aaro Koskinen - http://www.spinics.net/lists/arm-kernel/msg216859.html * 2420H4: reports "Could not set MPU rate to 4294MHz" on reboot - Reported and fixed by Jon Hunter - http://www.spinics.net/lists/arm-kernel/msg216121.html -------------------------------------------------------------- Branch: test_v3.8-rc4 Test-Serial: 20130120122039 Commit-ID: 7d1f9aeff1ee4a20b1aeb377dd0f579fe9647619 Test-Target-Board-Count: 11 ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: OMAP baseline test results for v3.8-rc4 2013-01-20 21:38 ` Paul Walmsley @ 2013-01-21 16:32 ` Mark Jackson -1 siblings, 0 replies; 64+ messages in thread From: Mark Jackson @ 2013-01-21 16:32 UTC (permalink / raw) To: Hiremath, Vaibhav, mporter; +Cc: Paul Walmsley, linux-omap, linux-arm-kernel Vaibhav / Matt On 20/01/13 21:38, Paul Walmsley wrote: > > Here are some basic OMAP test results for Linux v3.8-rc4. > Logs and other details at: > > http://www.pwsan.com/omap/testlogs/test_v3.8-rc4/20130120122039/ <snip> > Failing tests: needing investigation > ------------------------------------ > > Boot tests: > > * am335xbone: hangs after "Starting kernel" > - Cause unknown > - http://www.mail-archive.com/linux-omap@vger.kernel.org/msg82297.html <snip> > Failing tests: needing local investigation (may be due to testbed issues) > ------------------------------------------------------------------------- > > Boot tests: > > * AM335x Beaglebone: omap2plus_defconfig kernels don't boot > - May be fixed now, pending retest: > - http://marc.info/?l=linux-omap&m=135082257727502&w=2 > - Not yet part of the automated test suite > - Nishanth Menon & Vaibhav Hiremath report that it works for them > * May be due to an old U-boot with FDT support problems used here? > Pending local investigation and re-test Does anyone know when the BeagleBone support is going to be fixed in mainline ? I've just tried the latest linux-next git, and no joy. However, Matt's edma-dmaengine-am33xx-v5 branch on github seems to be working:- Uncompressing Linux... done, booting the kernel. [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 3.8.0-rc3-61978-g108da76-dirty (mpfj@mpfj-nanobone) (gcc version 4.5.4 (Buildroot 2012.11-git-00497-ge48bf89) ) #7 SMP Mon Jan 21 15:52:14 GMT 2013 [ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [ 0.000000] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone Are we just waiting for Matt's DMA stuff to be accepted ? Cheers Mark J. ^ permalink raw reply [flat|nested] 64+ messages in thread
* OMAP baseline test results for v3.8-rc4 @ 2013-01-21 16:32 ` Mark Jackson 0 siblings, 0 replies; 64+ messages in thread From: Mark Jackson @ 2013-01-21 16:32 UTC (permalink / raw) To: linux-arm-kernel Vaibhav / Matt On 20/01/13 21:38, Paul Walmsley wrote: > > Here are some basic OMAP test results for Linux v3.8-rc4. > Logs and other details at: > > http://www.pwsan.com/omap/testlogs/test_v3.8-rc4/20130120122039/ <snip> > Failing tests: needing investigation > ------------------------------------ > > Boot tests: > > * am335xbone: hangs after "Starting kernel" > - Cause unknown > - http://www.mail-archive.com/linux-omap at vger.kernel.org/msg82297.html <snip> > Failing tests: needing local investigation (may be due to testbed issues) > ------------------------------------------------------------------------- > > Boot tests: > > * AM335x Beaglebone: omap2plus_defconfig kernels don't boot > - May be fixed now, pending retest: > - http://marc.info/?l=linux-omap&m=135082257727502&w=2 > - Not yet part of the automated test suite > - Nishanth Menon & Vaibhav Hiremath report that it works for them > * May be due to an old U-boot with FDT support problems used here? > Pending local investigation and re-test Does anyone know when the BeagleBone support is going to be fixed in mainline ? I've just tried the latest linux-next git, and no joy. However, Matt's edma-dmaengine-am33xx-v5 branch on github seems to be working:- Uncompressing Linux... done, booting the kernel. [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 3.8.0-rc3-61978-g108da76-dirty (mpfj at mpfj-nanobone) (gcc version 4.5.4 (Buildroot 2012.11-git-00497-ge48bf89) ) #7 SMP Mon Jan 21 15:52:14 GMT 2013 [ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [ 0.000000] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone Are we just waiting for Matt's DMA stuff to be accepted ? Cheers Mark J. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: OMAP baseline test results for v3.8-rc4 2013-01-21 16:32 ` Mark Jackson @ 2013-01-21 16:45 ` Nishanth Menon -1 siblings, 0 replies; 64+ messages in thread From: Nishanth Menon @ 2013-01-21 16:45 UTC (permalink / raw) To: Mark Jackson Cc: Hiremath, Vaibhav, mporter, Paul Walmsley, linux-omap, linux-arm-kernel On 16:32-20130121, Mark Jackson wrote: > Vaibhav / Matt > > On 20/01/13 21:38, Paul Walmsley wrote: [...] > > > Failing tests: needing local investigation (may be due to testbed issues) > > ------------------------------------------------------------------------- > > > > Boot tests: > > > > * AM335x Beaglebone: omap2plus_defconfig kernels don't boot > > - May be fixed now, pending retest: > > - http://marc.info/?l=linux-omap&m=135082257727502&w=2 > > - Not yet part of the automated test suite > > - Nishanth Menon & Vaibhav Hiremath report that it works for them > > * May be due to an old U-boot with FDT support problems used here? > > Pending local investigation and re-test > > Does anyone know when the BeagleBone support is going to be fixed in mainline ? > > I've just tried the latest linux-next git, and no joy. > > However, Matt's edma-dmaengine-am33xx-v5 branch on github seems to be working:- > > Uncompressing Linux... done, booting the kernel. > [ 0.000000] Booting Linux on physical CPU 0x0 > [ 0.000000] Linux version 3.8.0-rc3-61978-g108da76-dirty (mpfj@mpfj-nanobone) (gcc version 4.5.4 > (Buildroot 2012.11-git-00497-ge48bf89) ) #7 SMP Mon Jan 21 15:52:14 GMT 2013 > [ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d > [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache > [ 0.000000] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone > > Are we just waiting for Matt's DMA stuff to be accepted ? > for MMC filesystem - we need the edma series. for a ramdisk, I am able to boot up to shell with 3.8-rc4 tag see: http://pastebin.com/bGNxJnZJ build configuration: compiler: $ arm-linux-gnueabi-gcc --version arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. U-boot: git://git.denx.de/u-boot.git v2013.01-rc3 config: am335x_evm_config kernel: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git v3.8-rc4 config: omap2plus_defconfig -- Regards, Nishanth Menon ^ permalink raw reply [flat|nested] 64+ messages in thread
* OMAP baseline test results for v3.8-rc4 @ 2013-01-21 16:45 ` Nishanth Menon 0 siblings, 0 replies; 64+ messages in thread From: Nishanth Menon @ 2013-01-21 16:45 UTC (permalink / raw) To: linux-arm-kernel On 16:32-20130121, Mark Jackson wrote: > Vaibhav / Matt > > On 20/01/13 21:38, Paul Walmsley wrote: [...] > > > Failing tests: needing local investigation (may be due to testbed issues) > > ------------------------------------------------------------------------- > > > > Boot tests: > > > > * AM335x Beaglebone: omap2plus_defconfig kernels don't boot > > - May be fixed now, pending retest: > > - http://marc.info/?l=linux-omap&m=135082257727502&w=2 > > - Not yet part of the automated test suite > > - Nishanth Menon & Vaibhav Hiremath report that it works for them > > * May be due to an old U-boot with FDT support problems used here? > > Pending local investigation and re-test > > Does anyone know when the BeagleBone support is going to be fixed in mainline ? > > I've just tried the latest linux-next git, and no joy. > > However, Matt's edma-dmaengine-am33xx-v5 branch on github seems to be working:- > > Uncompressing Linux... done, booting the kernel. > [ 0.000000] Booting Linux on physical CPU 0x0 > [ 0.000000] Linux version 3.8.0-rc3-61978-g108da76-dirty (mpfj at mpfj-nanobone) (gcc version 4.5.4 > (Buildroot 2012.11-git-00497-ge48bf89) ) #7 SMP Mon Jan 21 15:52:14 GMT 2013 > [ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d > [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache > [ 0.000000] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone > > Are we just waiting for Matt's DMA stuff to be accepted ? > for MMC filesystem - we need the edma series. for a ramdisk, I am able to boot up to shell with 3.8-rc4 tag see: http://pastebin.com/bGNxJnZJ build configuration: compiler: $ arm-linux-gnueabi-gcc --version arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. U-boot: git://git.denx.de/u-boot.git v2013.01-rc3 config: am335x_evm_config kernel: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git v3.8-rc4 config: omap2plus_defconfig -- Regards, Nishanth Menon ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: OMAP baseline test results for v3.8-rc4 2013-01-21 16:45 ` Nishanth Menon @ 2013-01-21 18:20 ` Richard Cochran -1 siblings, 0 replies; 64+ messages in thread From: Richard Cochran @ 2013-01-21 18:20 UTC (permalink / raw) To: Nishanth Menon Cc: Mark Jackson, mporter, Paul Walmsley, linux-omap, linux-arm-kernel, Hiremath, Vaibhav On Mon, Jan 21, 2013 at 10:45:10AM -0600, Nishanth Menon wrote: > for MMC filesystem - we need the edma series. for a ramdisk, I am able > to boot up to shell with 3.8-rc4 tag Yep, I also could boot 3.8-rc3 using ramfs, no problem. Thanks, Richard ^ permalink raw reply [flat|nested] 64+ messages in thread
* OMAP baseline test results for v3.8-rc4 @ 2013-01-21 18:20 ` Richard Cochran 0 siblings, 0 replies; 64+ messages in thread From: Richard Cochran @ 2013-01-21 18:20 UTC (permalink / raw) To: linux-arm-kernel On Mon, Jan 21, 2013 at 10:45:10AM -0600, Nishanth Menon wrote: > for MMC filesystem - we need the edma series. for a ramdisk, I am able > to boot up to shell with 3.8-rc4 tag Yep, I also could boot 3.8-rc3 using ramfs, no problem. Thanks, Richard ^ permalink raw reply [flat|nested] 64+ messages in thread
[parent not found: <f36acfaf128c4844b8f696ea4440e253@DLEE74.ent.ti.com>]
* Re: OMAP baseline test results for v3.8-rc4 [not found] ` <f36acfaf128c4844b8f696ea4440e253@DLEE74.ent.ti.com> @ 2013-01-21 18:24 ` Matt Porter 0 siblings, 0 replies; 64+ messages in thread From: Matt Porter @ 2013-01-21 18:24 UTC (permalink / raw) To: Richard Cochran Cc: Menon, Nishanth, Mark Jackson, Paul Walmsley, linux-omap, linux-arm-kernel, Hiremath, Vaibhav On Mon, Jan 21, 2013 at 06:20:03PM +0000, Richard Cochran wrote: > On Mon, Jan 21, 2013 at 10:45:10AM -0600, Nishanth Menon wrote: > > for MMC filesystem - we need the edma series. for a ramdisk, I am able > > to boot up to shell with 3.8-rc4 tag > > Yep, I also could boot 3.8-rc3 using ramfs, no problem. Do you use appended dtb? The only different that jumped out at me first Paul's reported hang is he uses appended dtb and I boot my boards with a single uImage and multiple dtbs the traditional DT way. -Matt ^ permalink raw reply [flat|nested] 64+ messages in thread
* OMAP baseline test results for v3.8-rc4 @ 2013-01-21 18:24 ` Matt Porter 0 siblings, 0 replies; 64+ messages in thread From: Matt Porter @ 2013-01-21 18:24 UTC (permalink / raw) To: linux-arm-kernel On Mon, Jan 21, 2013 at 06:20:03PM +0000, Richard Cochran wrote: > On Mon, Jan 21, 2013 at 10:45:10AM -0600, Nishanth Menon wrote: > > for MMC filesystem - we need the edma series. for a ramdisk, I am able > > to boot up to shell with 3.8-rc4 tag > > Yep, I also could boot 3.8-rc3 using ramfs, no problem. Do you use appended dtb? The only different that jumped out at me first Paul's reported hang is he uses appended dtb and I boot my boards with a single uImage and multiple dtbs the traditional DT way. -Matt ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: OMAP baseline test results for v3.8-rc4 2013-01-21 18:24 ` Matt Porter @ 2013-01-21 18:34 ` Richard Cochran -1 siblings, 0 replies; 64+ messages in thread From: Richard Cochran @ 2013-01-21 18:34 UTC (permalink / raw) To: Matt Porter Cc: Menon, Nishanth, Mark Jackson, Paul Walmsley, linux-omap, linux-arm-kernel, Hiremath, Vaibhav On Mon, Jan 21, 2013 at 01:24:19PM -0500, Matt Porter wrote: > On Mon, Jan 21, 2013 at 06:20:03PM +0000, Richard Cochran wrote: > > On Mon, Jan 21, 2013 at 10:45:10AM -0600, Nishanth Menon wrote: > > > for MMC filesystem - we need the edma series. for a ramdisk, I am able > > > to boot up to shell with 3.8-rc4 tag > > > > Yep, I also could boot 3.8-rc3 using ramfs, no problem. > > Do you use appended dtb? The only different that jumped out at me first > Paul's reported hang is he uses appended dtb and I boot my boards with a > single uImage and multiple dtbs the traditional DT way. No, not appended. I have a u-boot that supports dtb: U-Boot SPL 2012.10-rc1-00148-g4668a08 (Sep 30 2012 - 09:35:20) U-Boot 2012.10-rc1-00148-g4668a08 (Sep 30 2012 - 09:35:20) and using the omap2plus_defconfig, with a minicom script like the one below, and it works just fine. HTH, Richard verbose on send setenv ipaddr 192.168.1.77 send setenv serverip 192.168.1.12 send setenv netmask 255.255.255.0 send setenv bootargs console=ttyO0,115200n8 mem=256M root=/dev/ram rw initrd=0x82000000,16MB ramdisk_size=16384 earlyprintk=serial send tftp 81000000 uImage expect { "U-Boot# " } send tftp 82000000 beaglebone-initrd.gz expect { "U-Boot# " } send tftp 80000000 am335x-bone.dtb expect { "U-Boot# " } send bootm 81000000 - 80000000 ^ permalink raw reply [flat|nested] 64+ messages in thread
* OMAP baseline test results for v3.8-rc4 @ 2013-01-21 18:34 ` Richard Cochran 0 siblings, 0 replies; 64+ messages in thread From: Richard Cochran @ 2013-01-21 18:34 UTC (permalink / raw) To: linux-arm-kernel On Mon, Jan 21, 2013 at 01:24:19PM -0500, Matt Porter wrote: > On Mon, Jan 21, 2013 at 06:20:03PM +0000, Richard Cochran wrote: > > On Mon, Jan 21, 2013 at 10:45:10AM -0600, Nishanth Menon wrote: > > > for MMC filesystem - we need the edma series. for a ramdisk, I am able > > > to boot up to shell with 3.8-rc4 tag > > > > Yep, I also could boot 3.8-rc3 using ramfs, no problem. > > Do you use appended dtb? The only different that jumped out at me first > Paul's reported hang is he uses appended dtb and I boot my boards with a > single uImage and multiple dtbs the traditional DT way. No, not appended. I have a u-boot that supports dtb: U-Boot SPL 2012.10-rc1-00148-g4668a08 (Sep 30 2012 - 09:35:20) U-Boot 2012.10-rc1-00148-g4668a08 (Sep 30 2012 - 09:35:20) and using the omap2plus_defconfig, with a minicom script like the one below, and it works just fine. HTH, Richard verbose on send setenv ipaddr 192.168.1.77 send setenv serverip 192.168.1.12 send setenv netmask 255.255.255.0 send setenv bootargs console=ttyO0,115200n8 mem=256M root=/dev/ram rw initrd=0x82000000,16MB ramdisk_size=16384 earlyprintk=serial send tftp 81000000 uImage expect { "U-Boot# " } send tftp 82000000 beaglebone-initrd.gz expect { "U-Boot# " } send tftp 80000000 am335x-bone.dtb expect { "U-Boot# " } send bootm 81000000 - 80000000 ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: OMAP baseline test results for v3.8-rc4 2013-01-21 18:24 ` Matt Porter @ 2013-01-21 20:36 ` Peter Korsgaard -1 siblings, 0 replies; 64+ messages in thread From: Peter Korsgaard @ 2013-01-21 20:36 UTC (permalink / raw) To: Matt Porter Cc: Richard Cochran, Menon, Nishanth, Mark Jackson, Paul Walmsley, linux-omap, linux-arm-kernel, Hiremath, Vaibhav >>>>> "Matt" == Matt Porter <mporter@ti.com> writes: Matt> On Mon, Jan 21, 2013 at 06:20:03PM +0000, Richard Cochran wrote: >> On Mon, Jan 21, 2013 at 10:45:10AM -0600, Nishanth Menon wrote: >> > for MMC filesystem - we need the edma series. for a ramdisk, I am able >> > to boot up to shell with 3.8-rc4 tag >> >> Yep, I also could boot 3.8-rc3 using ramfs, no problem. Matt> Do you use appended dtb? The only different that jumped out at me first Matt> Paul's reported hang is he uses appended dtb and I boot my boards with a Matt> single uImage and multiple dtbs the traditional DT way. It works for me with appended dtb as well. -- Bye, Peter Korsgaard ^ permalink raw reply [flat|nested] 64+ messages in thread
* OMAP baseline test results for v3.8-rc4 @ 2013-01-21 20:36 ` Peter Korsgaard 0 siblings, 0 replies; 64+ messages in thread From: Peter Korsgaard @ 2013-01-21 20:36 UTC (permalink / raw) To: linux-arm-kernel >>>>> "Matt" == Matt Porter <mporter@ti.com> writes: Matt> On Mon, Jan 21, 2013 at 06:20:03PM +0000, Richard Cochran wrote: >> On Mon, Jan 21, 2013 at 10:45:10AM -0600, Nishanth Menon wrote: >> > for MMC filesystem - we need the edma series. for a ramdisk, I am able >> > to boot up to shell with 3.8-rc4 tag >> >> Yep, I also could boot 3.8-rc3 using ramfs, no problem. Matt> Do you use appended dtb? The only different that jumped out at me first Matt> Paul's reported hang is he uses appended dtb and I boot my boards with a Matt> single uImage and multiple dtbs the traditional DT way. It works for me with appended dtb as well. -- Bye, Peter Korsgaard ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: OMAP baseline test results for v3.8-rc4 2013-01-21 20:36 ` Peter Korsgaard @ 2013-01-22 2:24 ` Paul Walmsley -1 siblings, 0 replies; 64+ messages in thread From: Paul Walmsley @ 2013-01-22 2:24 UTC (permalink / raw) To: Matt Porter, Richard Cochran, Menon\, Nishanth, Mark Jackson, Hiremath\, Vaibhav, Vaibhav Bedia, Peter Korsgaard Cc: linux-omap\@vger.kernel.org, linux-arm-kernel\@lists.infradead.org Hi guys, Regarding the AM33xx test failures with appended DTBs, it would be very helpful if especially the TI people could try reproducing the problem. Otherwise it's going to cause problems with merging any new AM33xx patches, since I won't be able to test them without additional work. Plus, this is something that used to work up until d01e4afd, so something isn't right. You'll need to use the bootloader that TI originally shipped with the BeagleBones: U-Boot 2011.09-00009-gcf6e04d (Mar 08 2012 - 17:15:43) This is because many folks don't replace their bootloader. I do plan to add a test with a recent version of u-boot, but the kernel should not be dependent on the bootloader in any way to work correctly. If it is, then we need to document what u-boot version the kernel started to work with. The Kconfig that I use is here: http://www.pwsan.com/omap/testlogs/test_v3.8-rc4/20130120122039/build/am33xx_only/am33xx_only It's possible that there's something wrong with the Kconfig. It's basically just omap2plus_defconfig, but with all OMAP support for non-AM33xx turned off, and with the appended DTB and ATAG compatibility options turned on. Let's try to do this ASAP. That way, if it's some bootloader dependency or bug in the kernel, some fix can be merged during the v3.8-rc series, which is rapidly drawing to a close. - Paul ^ permalink raw reply [flat|nested] 64+ messages in thread
* OMAP baseline test results for v3.8-rc4 @ 2013-01-22 2:24 ` Paul Walmsley 0 siblings, 0 replies; 64+ messages in thread From: Paul Walmsley @ 2013-01-22 2:24 UTC (permalink / raw) To: linux-arm-kernel Hi guys, Regarding the AM33xx test failures with appended DTBs, it would be very helpful if especially the TI people could try reproducing the problem. Otherwise it's going to cause problems with merging any new AM33xx patches, since I won't be able to test them without additional work. Plus, this is something that used to work up until d01e4afd, so something isn't right. You'll need to use the bootloader that TI originally shipped with the BeagleBones: U-Boot 2011.09-00009-gcf6e04d (Mar 08 2012 - 17:15:43) This is because many folks don't replace their bootloader. I do plan to add a test with a recent version of u-boot, but the kernel should not be dependent on the bootloader in any way to work correctly. If it is, then we need to document what u-boot version the kernel started to work with. The Kconfig that I use is here: http://www.pwsan.com/omap/testlogs/test_v3.8-rc4/20130120122039/build/am33xx_only/am33xx_only It's possible that there's something wrong with the Kconfig. It's basically just omap2plus_defconfig, but with all OMAP support for non-AM33xx turned off, and with the appended DTB and ATAG compatibility options turned on. Let's try to do this ASAP. That way, if it's some bootloader dependency or bug in the kernel, some fix can be merged during the v3.8-rc series, which is rapidly drawing to a close. - Paul ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: OMAP baseline test results for v3.8-rc4 2013-01-22 2:24 ` Paul Walmsley @ 2013-01-22 8:55 ` Peter Korsgaard -1 siblings, 0 replies; 64+ messages in thread From: Peter Korsgaard @ 2013-01-22 8:55 UTC (permalink / raw) To: Paul Walmsley Cc: Matt Porter, Richard Cochran, Menon, Nishanth, Mark Jackson, Hiremath, Vaibhav, Vaibhav Bedia, linux-omap, linux-arm-kernel >>>>> "Paul" == Paul Walmsley <paul@pwsan.com> writes: Paul> Hi guys, Paul> Regarding the AM33xx test failures with appended DTBs, it would Paul> be very helpful if especially the TI people could try reproducing Paul> the problem. Otherwise it's going to cause problems with merging Paul> any new AM33xx patches, since I won't be able to test them Paul> without additional work. Plus, this is something that used to Paul> work up until d01e4afd, so something isn't right. Paul> You'll need to use the bootloader that TI originally shipped with Paul> the BeagleBones: Paul> U-Boot 2011.09-00009-gcf6e04d (Mar 08 2012 - 17:15:43) FYI, my beaglebone came with a slightly different U-Boot: U-Boot 2011.09-00000-gf63b270-dirty (Nov 14 2011 - 10:37:14) But I have the same behaviour. Recent kernels work with a modern U-Boot, but not the original. The build I'm doing is very similar to yours: git describe v3.8-rc4-71-g9a92841 make ARCH=arm CROSS_COMPILE=arm-linux- omap2plus_defconfig echo CONFIG_ARM_APPENDED_DTB=y >> .config echo CONFIG_ARM_ATAG_DTB_COMPAT=y >> .config yes ''| make ARCH=arm CROSS_COMPILE=arm-linux- oldconfig make ARCH=arm CROSS_COMPILE=arm-linux- cat arch/arm/boot/dts/am335x-bone.dtb >> arch/arm/boot/zImage make ARCH=arm CROSS_COMPILE=arm-linux- uImage # old u-boot (ethernet not stable here, so load from sd) U-Boot SPL 2011.09-00000-gf63b270-dirty (Nov 14 2011 - 10:37:14) Texas Instruments Revision detection unimplemented No AC power, disabling frequency switch OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img U-Boot 2011.09-00000-gf63b270-dirty (Nov 14 2011 - 10:37:14) I2C: ready DRAM: 256 MiB No daughter card present NAND: HW ECC Hamming Code selected nand_get_flash_type: unknown NAND device: Manufacturer ID: 0x10, Chip ID: 0x10 No NAND device found!!! 0 MiB MMC: OMAP SD/MMC: 0 *** Warning - readenv() failed, using default environment Net: cpsw Hit any key to stop autoboot: 0 U-Boot# mmc rescan U-Boot# fatload mmc 0:1 0x80200000 uImage.new reading uImage.new 3945127 bytes read U-Boot# setenv bootargs console=$console U-Boot# bootm 0x80200000 ## Booting kernel from Legacy Image at 80200000 ... Image Name: Linux-3.8.0-rc4-00071-g9a92841 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3945063 Bytes = 3.8 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... And it hangs. With a reasonably modern U-Boot it works: U-Boot SPL 2012.10 (Oct 29 2012 - 23:39:02) OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img U-Boot 2012.10 (Oct 29 2012 - 23:39:02) I2C: ready DRAM: 256 MiB WARNING: Caches not enabled MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 Using default environment Net: cpsw Hit any key to stop autoboot: 0 U-Boot# dhcp link up on port 0, speed 100, full duplex BOOTP broadcast 1 DHCP client bound to address 172.16.1.2 Using cpsw device TFTP from server 172.16.1.1; our IP address is 172.16.1.2 Filename 'uImage'. Load address: 0x80200000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ######### done Bytes transferred = 3945127 (3c32a7 hex) U-Boot# setenv bootargs console=$console U-Boot# bootm ## Booting kernel from Legacy Image at 80200000 ... Image Name: Linux-3.8.0-rc4-00071-g9a92841 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3945063 Bytes = 3.8 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 3.8.0-rc4-00071-g9a92841 (peko@dell) (gcc version 3 [ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instructie [ 0.000000] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335e [ 0.000000] Memory policy: ECC disabled, Data cache writeback [ 0.000000] AM335X ES1.0 (neon ) ... For the failing case, __log_buf doesn't contain anything sensible so I guess it crashes early: grep __log_buf System.map c07cc450 b __log_buf U-Boot# md 807cc450 807cc450: e5749fbf ef220eff 3df957df acebffbd ..t..."..W.=.... 807cc460: 61dfffff 7e93c5ef ddbafdfd bb2ac2fd ...a...~......*. 807cc470: 7ffffff1 f7fafd7f 717ddf7f 3feecfbc ..........}q...? 807cc480: bddb573d beeaba9b c57f7b99 f77dfbfe =W.......{....}. 807cc490: 6b7dde97 ebffcfaf fdf62df5 77e5f7bb ..}k.....-.....w 807cc4a0: 5fdffdf5 7bc2d8be 7d977ddd feafafff ..._...{.}.}.... 807cc4b0: f7429df5 76e2fd6d dedffd3d cf6769ff ..B.m..v=....ig. 807cc4c0: fb5644dd bdcf3a69 ffbfffd9 befff9ae .DV.i:.......... 807cc4d0: f7537fd7 feafe2f2 f37c7c2f fe5ffded ..S...../||..._. 807cc4e0: d757dcff 4aefffbf f5dfdbdf febccbef ..W....J........ 807cc4f0: 0efff5fd 9effca7a f757ffff 07fffeff ....z.....W..... 807cc500: deffd1db edbe5ef7 d5e7e579 bf63deef .....^..y.....c. 807cc510: edbece57 7cfdebbf f5371f9e f0ffffb3 W......|..7..... 807cc520: 3fa4ffdf cae9fd66 f6f71d4f ab777d5f ...?f...O..._}w. 807cc530: ed9df97d f7fcfeee dff7fb7c 3dbacafe }.......|......= 807cc540: 47effd7c b9f9b78e ddc5f7b7 fe2f2bea |..G.........+/. Any ideas? -- Bye, Peter Korsgaard ^ permalink raw reply [flat|nested] 64+ messages in thread
* OMAP baseline test results for v3.8-rc4 @ 2013-01-22 8:55 ` Peter Korsgaard 0 siblings, 0 replies; 64+ messages in thread From: Peter Korsgaard @ 2013-01-22 8:55 UTC (permalink / raw) To: linux-arm-kernel >>>>> "Paul" == Paul Walmsley <paul@pwsan.com> writes: Paul> Hi guys, Paul> Regarding the AM33xx test failures with appended DTBs, it would Paul> be very helpful if especially the TI people could try reproducing Paul> the problem. Otherwise it's going to cause problems with merging Paul> any new AM33xx patches, since I won't be able to test them Paul> without additional work. Plus, this is something that used to Paul> work up until d01e4afd, so something isn't right. Paul> You'll need to use the bootloader that TI originally shipped with Paul> the BeagleBones: Paul> U-Boot 2011.09-00009-gcf6e04d (Mar 08 2012 - 17:15:43) FYI, my beaglebone came with a slightly different U-Boot: U-Boot 2011.09-00000-gf63b270-dirty (Nov 14 2011 - 10:37:14) But I have the same behaviour. Recent kernels work with a modern U-Boot, but not the original. The build I'm doing is very similar to yours: git describe v3.8-rc4-71-g9a92841 make ARCH=arm CROSS_COMPILE=arm-linux- omap2plus_defconfig echo CONFIG_ARM_APPENDED_DTB=y >> .config echo CONFIG_ARM_ATAG_DTB_COMPAT=y >> .config yes ''| make ARCH=arm CROSS_COMPILE=arm-linux- oldconfig make ARCH=arm CROSS_COMPILE=arm-linux- cat arch/arm/boot/dts/am335x-bone.dtb >> arch/arm/boot/zImage make ARCH=arm CROSS_COMPILE=arm-linux- uImage # old u-boot (ethernet not stable here, so load from sd) U-Boot SPL 2011.09-00000-gf63b270-dirty (Nov 14 2011 - 10:37:14) Texas Instruments Revision detection unimplemented No AC power, disabling frequency switch OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img U-Boot 2011.09-00000-gf63b270-dirty (Nov 14 2011 - 10:37:14) I2C: ready DRAM: 256 MiB No daughter card present NAND: HW ECC Hamming Code selected nand_get_flash_type: unknown NAND device: Manufacturer ID: 0x10, Chip ID: 0x10 No NAND device found!!! 0 MiB MMC: OMAP SD/MMC: 0 *** Warning - readenv() failed, using default environment Net: cpsw Hit any key to stop autoboot: 0 U-Boot# mmc rescan U-Boot# fatload mmc 0:1 0x80200000 uImage.new reading uImage.new 3945127 bytes read U-Boot# setenv bootargs console=$console U-Boot# bootm 0x80200000 ## Booting kernel from Legacy Image at 80200000 ... Image Name: Linux-3.8.0-rc4-00071-g9a92841 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3945063 Bytes = 3.8 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... And it hangs. With a reasonably modern U-Boot it works: U-Boot SPL 2012.10 (Oct 29 2012 - 23:39:02) OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img U-Boot 2012.10 (Oct 29 2012 - 23:39:02) I2C: ready DRAM: 256 MiB WARNING: Caches not enabled MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 Using default environment Net: cpsw Hit any key to stop autoboot: 0 U-Boot# dhcp link up on port 0, speed 100, full duplex BOOTP broadcast 1 DHCP client bound to address 172.16.1.2 Using cpsw device TFTP from server 172.16.1.1; our IP address is 172.16.1.2 Filename 'uImage'. Load address: 0x80200000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ######### done Bytes transferred = 3945127 (3c32a7 hex) U-Boot# setenv bootargs console=$console U-Boot# bootm ## Booting kernel from Legacy Image at 80200000 ... Image Name: Linux-3.8.0-rc4-00071-g9a92841 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3945063 Bytes = 3.8 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 3.8.0-rc4-00071-g9a92841 (peko at dell) (gcc version 3 [ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instructie [ 0.000000] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335e [ 0.000000] Memory policy: ECC disabled, Data cache writeback [ 0.000000] AM335X ES1.0 (neon ) ... For the failing case, __log_buf doesn't contain anything sensible so I guess it crashes early: grep __log_buf System.map c07cc450 b __log_buf U-Boot# md 807cc450 807cc450: e5749fbf ef220eff 3df957df acebffbd ..t..."..W.=.... 807cc460: 61dfffff 7e93c5ef ddbafdfd bb2ac2fd ...a...~......*. 807cc470: 7ffffff1 f7fafd7f 717ddf7f 3feecfbc ..........}q...? 807cc480: bddb573d beeaba9b c57f7b99 f77dfbfe =W.......{....}. 807cc490: 6b7dde97 ebffcfaf fdf62df5 77e5f7bb ..}k.....-.....w 807cc4a0: 5fdffdf5 7bc2d8be 7d977ddd feafafff ..._...{.}.}.... 807cc4b0: f7429df5 76e2fd6d dedffd3d cf6769ff ..B.m..v=....ig. 807cc4c0: fb5644dd bdcf3a69 ffbfffd9 befff9ae .DV.i:.......... 807cc4d0: f7537fd7 feafe2f2 f37c7c2f fe5ffded ..S...../||..._. 807cc4e0: d757dcff 4aefffbf f5dfdbdf febccbef ..W....J........ 807cc4f0: 0efff5fd 9effca7a f757ffff 07fffeff ....z.....W..... 807cc500: deffd1db edbe5ef7 d5e7e579 bf63deef .....^..y.....c. 807cc510: edbece57 7cfdebbf f5371f9e f0ffffb3 W......|..7..... 807cc520: 3fa4ffdf cae9fd66 f6f71d4f ab777d5f ...?f...O..._}w. 807cc530: ed9df97d f7fcfeee dff7fb7c 3dbacafe }.......|......= 807cc540: 47effd7c b9f9b78e ddc5f7b7 fe2f2bea |..G.........+/. Any ideas? -- Bye, Peter Korsgaard ^ permalink raw reply [flat|nested] 64+ messages in thread
* RE: OMAP baseline test results for v3.8-rc4 2013-01-22 8:55 ` Peter Korsgaard @ 2013-01-22 13:02 ` Bedia, Vaibhav -1 siblings, 0 replies; 64+ messages in thread From: Bedia, Vaibhav @ 2013-01-22 13:02 UTC (permalink / raw) To: Peter Korsgaard, Paul Walmsley Cc: Porter, Matt, Richard Cochran, Menon, Nishanth, Mark Jackson, Hiremath, Vaibhav, linux-omap, linux-arm-kernel Hi, On Tue, Jan 22, 2013 at 14:25:13, Peter Korsgaard wrote: > >>>>> "Paul" == Paul Walmsley <paul@pwsan.com> writes: > > Paul> Hi guys, > > Paul> Regarding the AM33xx test failures with appended DTBs, it would > Paul> be very helpful if especially the TI people could try reproducing > Paul> the problem. Otherwise it's going to cause problems with merging > Paul> any new AM33xx patches, since I won't be able to test them > Paul> without additional work. Plus, this is something that used to > Paul> work up until d01e4afd, so something isn't right. > > Paul> You'll need to use the bootloader that TI originally shipped with > Paul> the BeagleBones: > > Paul> U-Boot 2011.09-00009-gcf6e04d (Mar 08 2012 - 17:15:43) > > FYI, my beaglebone came with a slightly different U-Boot: > > U-Boot 2011.09-00000-gf63b270-dirty (Nov 14 2011 - 10:37:14) > > But I have the same behaviour. Recent kernels work with a modern U-Boot, > but not the original. The build I'm doing is very similar to yours: > > git describe > v3.8-rc4-71-g9a92841 > > make ARCH=arm CROSS_COMPILE=arm-linux- omap2plus_defconfig > echo CONFIG_ARM_APPENDED_DTB=y >> .config > echo CONFIG_ARM_ATAG_DTB_COMPAT=y >> .config > yes ''| make ARCH=arm CROSS_COMPILE=arm-linux- oldconfig > make ARCH=arm CROSS_COMPILE=arm-linux- > cat arch/arm/boot/dts/am335x-bone.dtb >> arch/arm/boot/zImage > make ARCH=arm CROSS_COMPILE=arm-linux- uImage > > # old u-boot (ethernet not stable here, so load from sd) > > U-Boot SPL 2011.09-00000-gf63b270-dirty (Nov 14 2011 - 10:37:14) > Texas Instruments Revision detection unimplemented > No AC power, disabling frequency switch > OMAP SD/MMC: 0 > reading u-boot.img > reading u-boot.img > > > U-Boot 2011.09-00000-gf63b270-dirty (Nov 14 2011 - 10:37:14) > > I2C: ready > DRAM: 256 MiB > No daughter card present > NAND: HW ECC Hamming Code selected > nand_get_flash_type: unknown NAND device: Manufacturer ID: 0x10, Chip ID: 0x10 > No NAND device found!!! > 0 MiB > MMC: OMAP SD/MMC: 0 > *** Warning - readenv() failed, using default environment > > Net: cpsw > Hit any key to stop autoboot: 0 > U-Boot# mmc rescan > U-Boot# fatload mmc 0:1 0x80200000 uImage.new > reading uImage.new > > 3945127 bytes read > U-Boot# setenv bootargs console=$console > U-Boot# bootm 0x80200000 > ## Booting kernel from Legacy Image at 80200000 ... > Image Name: Linux-3.8.0-rc4-00071-g9a92841 > Image Type: ARM Linux Kernel Image (uncompressed) > Data Size: 3945063 Bytes = 3.8 MiB > Load Address: 80008000 > Entry Point: 80008000 > Verifying Checksum ... OK > Loading Kernel Image ... OK > OK > > Starting kernel ... > > And it hangs. With a reasonably modern U-Boot it works: > I just re-built U-Boot from f63b270 and the kernel from 9a92841 using commands similar to Peter's and the kernel boots for me with the appended DTB. (For some reason U-Boot version string doesn't have the commit id and I can't recollect what causes this) U-Boot SPL 2011.09 (Jan 22 2013 - 18:06:56) Texas Instruments Revision detection unimplemented OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img U-Boot 2011.09 (Jan 22 2013 - 16:00:25) I2C: ready DRAM: 256 MiB WARNING: Caches not enabled No daughter card present NAND: HW ECC Hamming Code selected nand_get_flash_type: unknown NAND device: Manufacturer ID: 0x10, Chip ID: 0x10 No NAND device found!!! 0 MiB MMC: OMAP SD/MMC: 0 *** Warning - readenv() failed, using default environment Net: cpsw Hit any key to stop autoboot: 0 U-Boot# U-Boot# U-Boot# setenv bootargs console=$console U-Boot# setenv serverip 172.24.133.119 U-Boot# setenv bootfile uImage U-Boot# dhcp 80200000 link up on port 0, speed 100, full duplex BOOTP broadcast 1 DHCP client bound to address 172.24.190.59 Using cpsw device TFTP from server 172.24.133.119; our IP address is 172.24.190.59; sending through gateway 172.24.188.1 Filename 'uImage'. Load address: 0x80200000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################### done Bytes transferred = 3917327 (3bc60f hex) U-Boot# bootm 0x80200000 ## Booting kernel from Legacy Image at 80200000 ... Image Name: Linux-3.8.0-rc4-00071-g9a92841 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3917263 Bytes = 3.7 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 3.8.0-rc4-00071-g9a92841 (a0393953@psplinux063) (gcc version 4.5.3 20110311 (prerelease) (GCC) ) #1 SMP Tue Jan 22 17:50:24 IST 2013 [ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [ 0.000000] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone [ 0.000000] Memory policy: ECC disabled, Data cache writeback [ 0.000000] AM335X ES1.0 (neon ) [ 0.000000] PERCPU: Embedded 9 pages/cpu @c0f24000 s12992 r8192 d15680 u36864 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64768 [ 0.000000] Kernel command line: console=ttyO0,115200n8 [ 0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes) [ 0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [ 0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) [ 0.000000] __ex_table already sorted, skipping sort [ 0.000000] Memory: 255MB = 255MB total [ 0.000000] Memory: 245376k/245376k available, 16768k 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] vmalloc : 0xd0800000 - 0xff000000 ( 744 MB) [ 0.000000] lowmem : 0xc0000000 - 0xd0000000 ( 256 MB) [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) [ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB) [ 0.000000] .text : 0xc0008000 - 0xc06d80d8 (6977 kB) [ 0.000000] .init : 0xc06d9000 - 0xc072b2c0 ( 329 kB) [ 0.000000] .data : 0xc072c000 - 0xc07bd9b8 ( 583 kB) [ 0.000000] .bss : 0xc07bd9b8 - 0xc0d186b0 (5484 kB) [ 0.000000] Hierarchical RCU implementation. ... Paul, The commit-id of U-Boot that you have is not present in my local tree. Will need to track down which tree your U-Boot came from before experimenting. Regards, Vaibhav ^ permalink raw reply [flat|nested] 64+ messages in thread
* OMAP baseline test results for v3.8-rc4 @ 2013-01-22 13:02 ` Bedia, Vaibhav 0 siblings, 0 replies; 64+ messages in thread From: Bedia, Vaibhav @ 2013-01-22 13:02 UTC (permalink / raw) To: linux-arm-kernel Hi, On Tue, Jan 22, 2013 at 14:25:13, Peter Korsgaard wrote: > >>>>> "Paul" == Paul Walmsley <paul@pwsan.com> writes: > > Paul> Hi guys, > > Paul> Regarding the AM33xx test failures with appended DTBs, it would > Paul> be very helpful if especially the TI people could try reproducing > Paul> the problem. Otherwise it's going to cause problems with merging > Paul> any new AM33xx patches, since I won't be able to test them > Paul> without additional work. Plus, this is something that used to > Paul> work up until d01e4afd, so something isn't right. > > Paul> You'll need to use the bootloader that TI originally shipped with > Paul> the BeagleBones: > > Paul> U-Boot 2011.09-00009-gcf6e04d (Mar 08 2012 - 17:15:43) > > FYI, my beaglebone came with a slightly different U-Boot: > > U-Boot 2011.09-00000-gf63b270-dirty (Nov 14 2011 - 10:37:14) > > But I have the same behaviour. Recent kernels work with a modern U-Boot, > but not the original. The build I'm doing is very similar to yours: > > git describe > v3.8-rc4-71-g9a92841 > > make ARCH=arm CROSS_COMPILE=arm-linux- omap2plus_defconfig > echo CONFIG_ARM_APPENDED_DTB=y >> .config > echo CONFIG_ARM_ATAG_DTB_COMPAT=y >> .config > yes ''| make ARCH=arm CROSS_COMPILE=arm-linux- oldconfig > make ARCH=arm CROSS_COMPILE=arm-linux- > cat arch/arm/boot/dts/am335x-bone.dtb >> arch/arm/boot/zImage > make ARCH=arm CROSS_COMPILE=arm-linux- uImage > > # old u-boot (ethernet not stable here, so load from sd) > > U-Boot SPL 2011.09-00000-gf63b270-dirty (Nov 14 2011 - 10:37:14) > Texas Instruments Revision detection unimplemented > No AC power, disabling frequency switch > OMAP SD/MMC: 0 > reading u-boot.img > reading u-boot.img > > > U-Boot 2011.09-00000-gf63b270-dirty (Nov 14 2011 - 10:37:14) > > I2C: ready > DRAM: 256 MiB > No daughter card present > NAND: HW ECC Hamming Code selected > nand_get_flash_type: unknown NAND device: Manufacturer ID: 0x10, Chip ID: 0x10 > No NAND device found!!! > 0 MiB > MMC: OMAP SD/MMC: 0 > *** Warning - readenv() failed, using default environment > > Net: cpsw > Hit any key to stop autoboot: 0 > U-Boot# mmc rescan > U-Boot# fatload mmc 0:1 0x80200000 uImage.new > reading uImage.new > > 3945127 bytes read > U-Boot# setenv bootargs console=$console > U-Boot# bootm 0x80200000 > ## Booting kernel from Legacy Image at 80200000 ... > Image Name: Linux-3.8.0-rc4-00071-g9a92841 > Image Type: ARM Linux Kernel Image (uncompressed) > Data Size: 3945063 Bytes = 3.8 MiB > Load Address: 80008000 > Entry Point: 80008000 > Verifying Checksum ... OK > Loading Kernel Image ... OK > OK > > Starting kernel ... > > And it hangs. With a reasonably modern U-Boot it works: > I just re-built U-Boot from f63b270 and the kernel from 9a92841 using commands similar to Peter's and the kernel boots for me with the appended DTB. (For some reason U-Boot version string doesn't have the commit id and I can't recollect what causes this) U-Boot SPL 2011.09 (Jan 22 2013 - 18:06:56) Texas Instruments Revision detection unimplemented OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img U-Boot 2011.09 (Jan 22 2013 - 16:00:25) I2C: ready DRAM: 256 MiB WARNING: Caches not enabled No daughter card present NAND: HW ECC Hamming Code selected nand_get_flash_type: unknown NAND device: Manufacturer ID: 0x10, Chip ID: 0x10 No NAND device found!!! 0 MiB MMC: OMAP SD/MMC: 0 *** Warning - readenv() failed, using default environment Net: cpsw Hit any key to stop autoboot: 0 U-Boot# U-Boot# U-Boot# setenv bootargs console=$console U-Boot# setenv serverip 172.24.133.119 U-Boot# setenv bootfile uImage U-Boot# dhcp 80200000 link up on port 0, speed 100, full duplex BOOTP broadcast 1 DHCP client bound to address 172.24.190.59 Using cpsw device TFTP from server 172.24.133.119; our IP address is 172.24.190.59; sending through gateway 172.24.188.1 Filename 'uImage'. Load address: 0x80200000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################### done Bytes transferred = 3917327 (3bc60f hex) U-Boot# bootm 0x80200000 ## Booting kernel from Legacy Image at 80200000 ... Image Name: Linux-3.8.0-rc4-00071-g9a92841 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3917263 Bytes = 3.7 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 3.8.0-rc4-00071-g9a92841 (a0393953 at psplinux063) (gcc version 4.5.3 20110311 (prerelease) (GCC) ) #1 SMP Tue Jan 22 17:50:24 IST 2013 [ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [ 0.000000] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone [ 0.000000] Memory policy: ECC disabled, Data cache writeback [ 0.000000] AM335X ES1.0 (neon ) [ 0.000000] PERCPU: Embedded 9 pages/cpu @c0f24000 s12992 r8192 d15680 u36864 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64768 [ 0.000000] Kernel command line: console=ttyO0,115200n8 [ 0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes) [ 0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [ 0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) [ 0.000000] __ex_table already sorted, skipping sort [ 0.000000] Memory: 255MB = 255MB total [ 0.000000] Memory: 245376k/245376k available, 16768k 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] vmalloc : 0xd0800000 - 0xff000000 ( 744 MB) [ 0.000000] lowmem : 0xc0000000 - 0xd0000000 ( 256 MB) [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) [ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB) [ 0.000000] .text : 0xc0008000 - 0xc06d80d8 (6977 kB) [ 0.000000] .init : 0xc06d9000 - 0xc072b2c0 ( 329 kB) [ 0.000000] .data : 0xc072c000 - 0xc07bd9b8 ( 583 kB) [ 0.000000] .bss : 0xc07bd9b8 - 0xc0d186b0 (5484 kB) [ 0.000000] Hierarchical RCU implementation. ... Paul, The commit-id of U-Boot that you have is not present in my local tree. Will need to track down which tree your U-Boot came from before experimenting. Regards, Vaibhav ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: OMAP baseline test results for v3.8-rc4 2013-01-22 2:24 ` Paul Walmsley @ 2013-01-22 9:24 ` Jan Lübbe -1 siblings, 0 replies; 64+ messages in thread From: Jan Lübbe @ 2013-01-22 9:24 UTC (permalink / raw) To: Paul Walmsley Cc: Matt Porter, Richard Cochran, Menon\, Nishanth, Mark Jackson, Hiremath\, Vaibhav, Vaibhav Bedia, Peter Korsgaard, linux-omap\@vger.kernel.org, linux-arm-kernel\@lists.infradead.org On Tue, 2013-01-22 at 02:24 +0000, Paul Walmsley wrote: > Regarding the AM33xx test failures with appended DTBs, it would be very > helpful if especially the TI people could try reproducing the problem. > Otherwise it's going to cause problems with merging any new AM33xx > patches, since I won't be able to test them without additional work. > Plus, this is something that used to work up until d01e4afd, so something > isn't right. Just a guess, but there can be problems when the appended DTB crosses an 1MB boundary. See this mail for details and a patch: http://www.spinics.net/lists/arm-kernel/msg216898.html Regards, Jan -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | ^ permalink raw reply [flat|nested] 64+ messages in thread
* OMAP baseline test results for v3.8-rc4 @ 2013-01-22 9:24 ` Jan Lübbe 0 siblings, 0 replies; 64+ messages in thread From: Jan Lübbe @ 2013-01-22 9:24 UTC (permalink / raw) To: linux-arm-kernel On Tue, 2013-01-22 at 02:24 +0000, Paul Walmsley wrote: > Regarding the AM33xx test failures with appended DTBs, it would be very > helpful if especially the TI people could try reproducing the problem. > Otherwise it's going to cause problems with merging any new AM33xx > patches, since I won't be able to test them without additional work. > Plus, this is something that used to work up until d01e4afd, so something > isn't right. Just a guess, but there can be problems when the appended DTB crosses an 1MB boundary. See this mail for details and a patch: http://www.spinics.net/lists/arm-kernel/msg216898.html Regards, Jan -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: OMAP baseline test results for v3.8-rc4 2013-01-22 9:24 ` Jan Lübbe @ 2013-01-22 9:40 ` Peter Korsgaard -1 siblings, 0 replies; 64+ messages in thread From: Peter Korsgaard @ 2013-01-22 9:40 UTC (permalink / raw) To: Jan Lübbe Cc: Paul Walmsley, Matt Porter, Richard Cochran, Menon, Nishanth, Mark Jackson, Hiremath, Vaibhav, Vaibhav Bedia, linux-omap, linux-arm-kernel >>>>> "Jan" == Jan Lübbe <jlu@pengutronix.de> writes: Jan> On Tue, 2013-01-22 at 02:24 +0000, Paul Walmsley wrote: >> Regarding the AM33xx test failures with appended DTBs, it would be very >> helpful if especially the TI people could try reproducing the problem. >> Otherwise it's going to cause problems with merging any new AM33xx >> patches, since I won't be able to test them without additional work. >> Plus, this is something that used to work up until d01e4afd, so something >> isn't right. Jan> Just a guess, but there can be problems when the appended DTB Jan> crosses an 1MB boundary. See this mail for details and a patch: Jan> http://www.spinics.net/lists/arm-kernel/msg216898.html True, but that doesn't seem to be the case here: ls -la arch/arm/boot/uImage -rw-r--r-- 1 peko peko 3945127 Jan 22 09:26 arch/arm/boot/uImage E.G. far from the 1MB boundary. -- Bye, Peter Korsgaard -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 64+ messages in thread
* OMAP baseline test results for v3.8-rc4 @ 2013-01-22 9:40 ` Peter Korsgaard 0 siblings, 0 replies; 64+ messages in thread From: Peter Korsgaard @ 2013-01-22 9:40 UTC (permalink / raw) To: linux-arm-kernel >>>>> "Jan" == Jan L?bbe <jlu@pengutronix.de> writes: Jan> On Tue, 2013-01-22 at 02:24 +0000, Paul Walmsley wrote: >> Regarding the AM33xx test failures with appended DTBs, it would be very >> helpful if especially the TI people could try reproducing the problem. >> Otherwise it's going to cause problems with merging any new AM33xx >> patches, since I won't be able to test them without additional work. >> Plus, this is something that used to work up until d01e4afd, so something >> isn't right. Jan> Just a guess, but there can be problems when the appended DTB Jan> crosses an 1MB boundary. See this mail for details and a patch: Jan> http://www.spinics.net/lists/arm-kernel/msg216898.html True, but that doesn't seem to be the case here: ls -la arch/arm/boot/uImage -rw-r--r-- 1 peko peko 3945127 Jan 22 09:26 arch/arm/boot/uImage E.G. far from the 1MB boundary. -- Bye, Peter Korsgaard ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: OMAP baseline test results for v3.8-rc4 2013-01-22 9:40 ` Peter Korsgaard @ 2013-01-22 9:52 ` Russell King - ARM Linux -1 siblings, 0 replies; 64+ messages in thread From: Russell King - ARM Linux @ 2013-01-22 9:52 UTC (permalink / raw) To: Peter Korsgaard Cc: Jan Lübbe, Menon, Nishanth, Matt Porter, Paul Walmsley, Richard Cochran, Hiremath, Vaibhav, Vaibhav Bedia, linux-omap, Mark Jackson, linux-arm-kernel On Tue, Jan 22, 2013 at 10:40:46AM +0100, Peter Korsgaard wrote: > >>>>> "Jan" == Jan Lübbe <jlu@pengutronix.de> writes: > > Jan> On Tue, 2013-01-22 at 02:24 +0000, Paul Walmsley wrote: > >> Regarding the AM33xx test failures with appended DTBs, it would be very > >> helpful if especially the TI people could try reproducing the problem. > >> Otherwise it's going to cause problems with merging any new AM33xx > >> patches, since I won't be able to test them without additional work. > >> Plus, this is something that used to work up until d01e4afd, so something > >> isn't right. > > Jan> Just a guess, but there can be problems when the appended DTB > Jan> crosses an 1MB boundary. See this mail for details and a patch: > Jan> http://www.spinics.net/lists/arm-kernel/msg216898.html > > True, but that doesn't seem to be the case here: > ls -la arch/arm/boot/uImage > -rw-r--r-- 1 peko peko 3945127 Jan 22 09:26 arch/arm/boot/uImage > > E.G. far from the 1MB boundary. Don't rely on that. Remember, if the compressed image occupies the same location as the decompressed kernel, the decompressor will copy the data to a different location in RAM first - I think at RAM offset + 32K + decompressed kernel size. So yes, please try the patch in the link above. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 64+ messages in thread
* OMAP baseline test results for v3.8-rc4 @ 2013-01-22 9:52 ` Russell King - ARM Linux 0 siblings, 0 replies; 64+ messages in thread From: Russell King - ARM Linux @ 2013-01-22 9:52 UTC (permalink / raw) To: linux-arm-kernel On Tue, Jan 22, 2013 at 10:40:46AM +0100, Peter Korsgaard wrote: > >>>>> "Jan" == Jan L?bbe <jlu@pengutronix.de> writes: > > Jan> On Tue, 2013-01-22 at 02:24 +0000, Paul Walmsley wrote: > >> Regarding the AM33xx test failures with appended DTBs, it would be very > >> helpful if especially the TI people could try reproducing the problem. > >> Otherwise it's going to cause problems with merging any new AM33xx > >> patches, since I won't be able to test them without additional work. > >> Plus, this is something that used to work up until d01e4afd, so something > >> isn't right. > > Jan> Just a guess, but there can be problems when the appended DTB > Jan> crosses an 1MB boundary. See this mail for details and a patch: > Jan> http://www.spinics.net/lists/arm-kernel/msg216898.html > > True, but that doesn't seem to be the case here: > ls -la arch/arm/boot/uImage > -rw-r--r-- 1 peko peko 3945127 Jan 22 09:26 arch/arm/boot/uImage > > E.G. far from the 1MB boundary. Don't rely on that. Remember, if the compressed image occupies the same location as the decompressed kernel, the decompressor will copy the data to a different location in RAM first - I think at RAM offset + 32K + decompressed kernel size. So yes, please try the patch in the link above. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: OMAP baseline test results for v3.8-rc4 2013-01-22 9:52 ` Russell King - ARM Linux @ 2013-01-22 12:19 ` Peter Korsgaard -1 siblings, 0 replies; 64+ messages in thread From: Peter Korsgaard @ 2013-01-22 12:19 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Jan Lübbe, Menon, Nishanth, Matt Porter, Paul Walmsley, Richard Cochran, Hiremath, Vaibhav, Vaibhav Bedia, linux-omap, Mark Jackson, linux-arm-kernel >>>>> "Russell" == Russell King <- ARM Linux <linux@arm.linux.org.uk>> writes: Russell> Don't rely on that. Remember, if the compressed image Russell> occupies the same location as the decompressed kernel, the Russell> decompressor will copy the data to a different location in RAM Russell> first - I think at RAM offset + 32K + decompressed kernel Russell> size. Ok, but this is with the exact same kernel image loaded at the same address for the two cases. The only difference is U-Boot version. Russell> So yes, please try the patch in the link above. I did. No visible difference. Also not with changing the uImage load address (2M/16M/32M from start of RAM). -- Bye, Peter Korsgaard ^ permalink raw reply [flat|nested] 64+ messages in thread
* OMAP baseline test results for v3.8-rc4 @ 2013-01-22 12:19 ` Peter Korsgaard 0 siblings, 0 replies; 64+ messages in thread From: Peter Korsgaard @ 2013-01-22 12:19 UTC (permalink / raw) To: linux-arm-kernel >>>>> "Russell" == Russell King <- ARM Linux <linux@arm.linux.org.uk>> writes: Russell> Don't rely on that. Remember, if the compressed image Russell> occupies the same location as the decompressed kernel, the Russell> decompressor will copy the data to a different location in RAM Russell> first - I think at RAM offset + 32K + decompressed kernel Russell> size. Ok, but this is with the exact same kernel image loaded at the same address for the two cases. The only difference is U-Boot version. Russell> So yes, please try the patch in the link above. I did. No visible difference. Also not with changing the uImage load address (2M/16M/32M from start of RAM). -- Bye, Peter Korsgaard ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: OMAP baseline test results for v3.8-rc4 2013-01-22 9:24 ` Jan Lübbe @ 2013-01-25 8:23 ` Paul Walmsley -1 siblings, 0 replies; 64+ messages in thread From: Paul Walmsley @ 2013-01-25 8:23 UTC (permalink / raw) To: Jan Lübbe Cc: Matt Porter, Richard Cochran, Menon\\, Nishanth, Mark Jackson, Hiremath\\, Vaibhav, Vaibhav Bedia, Peter Korsgaard, linux-omap\\@vger.kernel.org, linux-arm-kernel\\@lists.infradead.org [-- Attachment #1: Type: TEXT/PLAIN, Size: 320 bytes --] Hello Jan, On Tue, 22 Jan 2013, Jan Lübbe wrote: > Just a guess, but there can be problems when the appended DTB crosses an > 1MB boundary. See this mail for details and a patch: > http://www.spinics.net/lists/arm-kernel/msg216898.html Thanks for the suggestion. That patch didn't fix it for me. - Paul ^ permalink raw reply [flat|nested] 64+ messages in thread
* OMAP baseline test results for v3.8-rc4 @ 2013-01-25 8:23 ` Paul Walmsley 0 siblings, 0 replies; 64+ messages in thread From: Paul Walmsley @ 2013-01-25 8:23 UTC (permalink / raw) To: linux-arm-kernel Hello Jan, On Tue, 22 Jan 2013, Jan L?bbe wrote: > Just a guess, but there can be problems when the appended DTB crosses an > 1MB boundary. See this mail for details and a patch: > http://www.spinics.net/lists/arm-kernel/msg216898.html Thanks for the suggestion. That patch didn't fix it for me. - Paul ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: OMAP baseline test results for v3.8-rc4 2013-01-22 2:24 ` Paul Walmsley @ 2013-01-22 10:15 ` Mark Jackson -1 siblings, 0 replies; 64+ messages in thread From: Mark Jackson @ 2013-01-22 10:15 UTC (permalink / raw) To: Paul Walmsley Cc: Matt Porter, Richard Cochran, Menon\, Nishanth, Hiremath\, Vaibhav, Vaibhav Bedia, Peter Korsgaard, linux-omap\@vger.kernel.org, linux-arm-kernel\@lists.infradead.org On 22/01/13 02:24, Paul Walmsley wrote: > > Hi guys, > > Regarding the AM33xx test failures with appended DTBs, it would be very > helpful if especially the TI people could try reproducing the problem. My non-working setup (I'm using a recent U-Boot) is as follows ... [Note that the DTB patch mentioned elsewhere in this thread seems to be *already* applied to -next] $ git describe next-20130121 $ make -j 8 ARCH=arm CROSS_COMPILE=arm-linux- omap2plus_defconfig $ make -j 8 ARCH=arm CROSS_COMPILE=arm-linux- menuconfig CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_EARLY_PRINTK=y $ make -j 8 ARCH=arm CROSS_COMPILE=arm-linux- $ cat arch/arm/boot/zImage arch/arm/boot/dtb/am335x-bone.dtb > arch/arm/boot/zImage-dtb.am335x-bone $ scripts/mkuboot.sh -A arm -O linux -C none -T kernel -a 0×80008000 -e 0×80008000 -n ‘Linux’ -d arch/arm/boot/zImage-dtb.am335x-bone arch/arm/boot/uImage-dtb.am335x-bone $ cp arch/arm/boot/uImage-dtb.am335x-bone /tftpboot/nanobone/uImage-dtb And when I boot:- U-Boot SPL 2013.01 (Jan 16 2013 - 15:20:58) OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img U-Boot 2013.01 (Jan 16 2013 - 15:20:58) I2C: ready DRAM: 256 MiB WARNING: Caches not enabled NAND: No NAND device found!!! 0 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 *** Warning - readenv() failed, using default environment musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Peripheral mode controller at 47401000 using PIO, IRQ 0 musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Host mode controller at 47401800 using PIO, IRQ 0 Net: cpsw, usb_ether Hit any key to stop autoboot: 0 mmc0 is current device SD/MMC found on device 0 reading uEnv.txt 167 bytes read in 3 ms (53.7 KiB/s) Loaded environment from uEnv.txt Importing environment from mmc ... Running uenvcmd ... cpsw Waiting for PHY auto negotiation to complete. done link up on port 0, speed 100, full duplex BOOTP broadcast 1 BOOTP broadcast 2 *** Unhandled DHCP Option in OFFER/ACK: 44 *** Unhandled DHCP Option in OFFER/ACK: 46 *** Unhandled DHCP Option in OFFER/ACK: 44 *** Unhandled DHCP Option in OFFER/ACK: 46 DHCP client bound to address 10.0.0.112 Using cpsw device TFTP from server 10.0.0.100; our IP address is 10.0.0.112 Filename '/nanobone/uImage-dtb'. Load address: 0x80000000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ########### 627.9 KiB/s done Bytes transferred = 3963919 (3c7c0f hex) ## Booting kernel from Legacy Image at 80000000 ... Image Name: Linux Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3963855 Bytes = 3.8 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 64+ messages in thread
* OMAP baseline test results for v3.8-rc4 @ 2013-01-22 10:15 ` Mark Jackson 0 siblings, 0 replies; 64+ messages in thread From: Mark Jackson @ 2013-01-22 10:15 UTC (permalink / raw) To: linux-arm-kernel On 22/01/13 02:24, Paul Walmsley wrote: > > Hi guys, > > Regarding the AM33xx test failures with appended DTBs, it would be very > helpful if especially the TI people could try reproducing the problem. My non-working setup (I'm using a recent U-Boot) is as follows ... [Note that the DTB patch mentioned elsewhere in this thread seems to be *already* applied to -next] $ git describe next-20130121 $ make -j 8 ARCH=arm CROSS_COMPILE=arm-linux- omap2plus_defconfig $ make -j 8 ARCH=arm CROSS_COMPILE=arm-linux- menuconfig CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_EARLY_PRINTK=y $ make -j 8 ARCH=arm CROSS_COMPILE=arm-linux- $ cat arch/arm/boot/zImage arch/arm/boot/dtb/am335x-bone.dtb > arch/arm/boot/zImage-dtb.am335x-bone $ scripts/mkuboot.sh -A arm -O linux -C none -T kernel -a 0?80008000 -e 0?80008000 -n ?Linux? -d arch/arm/boot/zImage-dtb.am335x-bone arch/arm/boot/uImage-dtb.am335x-bone $ cp arch/arm/boot/uImage-dtb.am335x-bone /tftpboot/nanobone/uImage-dtb And when I boot:- U-Boot SPL 2013.01 (Jan 16 2013 - 15:20:58) OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img U-Boot 2013.01 (Jan 16 2013 - 15:20:58) I2C: ready DRAM: 256 MiB WARNING: Caches not enabled NAND: No NAND device found!!! 0 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 *** Warning - readenv() failed, using default environment musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Peripheral mode controller at 47401000 using PIO, IRQ 0 musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Host mode controller at 47401800 using PIO, IRQ 0 Net: cpsw, usb_ether Hit any key to stop autoboot: 0 mmc0 is current device SD/MMC found on device 0 reading uEnv.txt 167 bytes read in 3 ms (53.7 KiB/s) Loaded environment from uEnv.txt Importing environment from mmc ... Running uenvcmd ... cpsw Waiting for PHY auto negotiation to complete. done link up on port 0, speed 100, full duplex BOOTP broadcast 1 BOOTP broadcast 2 *** Unhandled DHCP Option in OFFER/ACK: 44 *** Unhandled DHCP Option in OFFER/ACK: 46 *** Unhandled DHCP Option in OFFER/ACK: 44 *** Unhandled DHCP Option in OFFER/ACK: 46 DHCP client bound to address 10.0.0.112 Using cpsw device TFTP from server 10.0.0.100; our IP address is 10.0.0.112 Filename '/nanobone/uImage-dtb'. Load address: 0x80000000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ########### 627.9 KiB/s done Bytes transferred = 3963919 (3c7c0f hex) ## Booting kernel from Legacy Image at 80000000 ... Image Name: Linux Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3963855 Bytes = 3.8 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: OMAP baseline test results for v3.8-rc4 2013-01-22 10:15 ` Mark Jackson @ 2013-01-22 12:21 ` Peter Korsgaard -1 siblings, 0 replies; 64+ messages in thread From: Peter Korsgaard @ 2013-01-22 12:21 UTC (permalink / raw) To: Mark Jackson Cc: Paul Walmsley, Matt Porter, Richard Cochran, Menon, Nishanth, Hiremath, Vaibhav, Vaibhav Bedia, linux-omap, linux-arm-kernel >>>>> "Mark" == Mark Jackson <mpfj-list@mimc.co.uk> writes: Hi, Mark> Bytes transferred = 3963919 (3c7c0f hex) Mark> ## Booting kernel from Legacy Image at 80000000 ... Mark> Image Name: Linux Mark> Image Type: ARM Linux Kernel Image (uncompressed) Mark> Data Size: 3963855 Bytes = 3.8 MiB Mark> Load Address: 80008000 Mark> Entry Point: 80008000 Mark> Verifying Checksum ... OK Mark> Loading Kernel Image ... OK Mark> OK I haven't tried a recent -next build, but what is your kernel command line and did you try without EARLY_PRINTK? -- Bye, Peter Korsgaard ^ permalink raw reply [flat|nested] 64+ messages in thread
* OMAP baseline test results for v3.8-rc4 @ 2013-01-22 12:21 ` Peter Korsgaard 0 siblings, 0 replies; 64+ messages in thread From: Peter Korsgaard @ 2013-01-22 12:21 UTC (permalink / raw) To: linux-arm-kernel >>>>> "Mark" == Mark Jackson <mpfj-list@mimc.co.uk> writes: Hi, Mark> Bytes transferred = 3963919 (3c7c0f hex) Mark> ## Booting kernel from Legacy Image at 80000000 ... Mark> Image Name: Linux Mark> Image Type: ARM Linux Kernel Image (uncompressed) Mark> Data Size: 3963855 Bytes = 3.8 MiB Mark> Load Address: 80008000 Mark> Entry Point: 80008000 Mark> Verifying Checksum ... OK Mark> Loading Kernel Image ... OK Mark> OK I haven't tried a recent -next build, but what is your kernel command line and did you try without EARLY_PRINTK? -- Bye, Peter Korsgaard ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: OMAP baseline test results for v3.8-rc4 2013-01-22 12:21 ` Peter Korsgaard @ 2013-01-22 13:45 ` Mark Jackson -1 siblings, 0 replies; 64+ messages in thread From: Mark Jackson @ 2013-01-22 13:45 UTC (permalink / raw) To: Peter Korsgaard Cc: Paul Walmsley, Matt Porter, Richard Cochran, Menon, Nishanth, Hiremath, Vaibhav, Vaibhav Bedia, linux-omap, linux-arm-kernel On 22/01/13 12:21, Peter Korsgaard wrote: >>>>>> "Mark" == Mark Jackson <mpfj-list@mimc.co.uk> writes: > > Hi, > > Mark> Bytes transferred = 3963919 (3c7c0f hex) > Mark> ## Booting kernel from Legacy Image at 80000000 ... > Mark> Image Name: Linux > Mark> Image Type: ARM Linux Kernel Image (uncompressed) > Mark> Data Size: 3963855 Bytes = 3.8 MiB > Mark> Load Address: 80008000 > Mark> Entry Point: 80008000 > Mark> Verifying Checksum ... OK > Mark> Loading Kernel Image ... OK > Mark> OK > > I haven't tried a recent -next build, but what is your kernel command > line and did you try without EARLY_PRINTK? > Kernel command line: console=ttyO0,115200n8 earlyprintk debug root=/dev/mmcblk0p2 ro rootfstype=ext2 rootwait I understand that MMC is not in the mainline. Aha ... I tried without EARLY_PRINTK and it now boots up to the point of rootfs access. Cheers Mark J. ^ permalink raw reply [flat|nested] 64+ messages in thread
* OMAP baseline test results for v3.8-rc4 @ 2013-01-22 13:45 ` Mark Jackson 0 siblings, 0 replies; 64+ messages in thread From: Mark Jackson @ 2013-01-22 13:45 UTC (permalink / raw) To: linux-arm-kernel On 22/01/13 12:21, Peter Korsgaard wrote: >>>>>> "Mark" == Mark Jackson <mpfj-list@mimc.co.uk> writes: > > Hi, > > Mark> Bytes transferred = 3963919 (3c7c0f hex) > Mark> ## Booting kernel from Legacy Image at 80000000 ... > Mark> Image Name: Linux > Mark> Image Type: ARM Linux Kernel Image (uncompressed) > Mark> Data Size: 3963855 Bytes = 3.8 MiB > Mark> Load Address: 80008000 > Mark> Entry Point: 80008000 > Mark> Verifying Checksum ... OK > Mark> Loading Kernel Image ... OK > Mark> OK > > I haven't tried a recent -next build, but what is your kernel command > line and did you try without EARLY_PRINTK? > Kernel command line: console=ttyO0,115200n8 earlyprintk debug root=/dev/mmcblk0p2 ro rootfstype=ext2 rootwait I understand that MMC is not in the mainline. Aha ... I tried without EARLY_PRINTK and it now boots up to the point of rootfs access. Cheers Mark J. ^ permalink raw reply [flat|nested] 64+ messages in thread
* RE: OMAP baseline test results for v3.8-rc4 2013-01-22 10:15 ` Mark Jackson @ 2013-01-22 13:32 ` Bedia, Vaibhav -1 siblings, 0 replies; 64+ messages in thread From: Bedia, Vaibhav @ 2013-01-22 13:32 UTC (permalink / raw) To: Mark Jackson, Paul Walmsley Cc: Porter, Matt, Richard Cochran, Menon, Nishanth, Hiremath, Vaibhav, Peter Korsgaard, linux-omap\@vger.kernel.org, linux-arm-kernel\@lists.infradead.org On Tue, Jan 22, 2013 at 15:45:08, Mark Jackson wrote: > On 22/01/13 02:24, Paul Walmsley wrote: > > > > Hi guys, > > > > Regarding the AM33xx test failures with appended DTBs, it would be very > > helpful if especially the TI people could try reproducing the problem. > > My non-working setup (I'm using a recent U-Boot) is as follows ... > > [Note that the DTB patch mentioned elsewhere in this thread seems to be *already* applied to -next] > > $ git describe > next-20130121 > $ make -j 8 ARCH=arm CROSS_COMPILE=arm-linux- omap2plus_defconfig > $ make -j 8 ARCH=arm CROSS_COMPILE=arm-linux- menuconfig > CONFIG_ARM_APPENDED_DTB=y > CONFIG_ARM_ATAG_DTB_COMPAT=y > CONFIG_EARLY_PRINTK=y > $ make -j 8 ARCH=arm CROSS_COMPILE=arm-linux- > $ cat arch/arm/boot/zImage arch/arm/boot/dtb/am335x-bone.dtb > arch/arm/boot/zImage-dtb.am335x-bone > $ scripts/mkuboot.sh -A arm -O linux -C none -T kernel -a 0×80008000 -e 0×80008000 -n ‘Linux’ -d > arch/arm/boot/zImage-dtb.am335x-bone arch/arm/boot/uImage-dtb.am335x-bone > $ cp arch/arm/boot/uImage-dtb.am335x-bone /tftpboot/nanobone/uImage-dtb > > And when I boot:- > > U-Boot SPL 2013.01 (Jan 16 2013 - 15:20:58) > OMAP SD/MMC: 0 > reading u-boot.img > reading u-boot.img > > > U-Boot 2013.01 (Jan 16 2013 - 15:20:58) > > I2C: ready > DRAM: 256 MiB > WARNING: Caches not enabled > NAND: No NAND device found!!! > 0 MiB > MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 > *** Warning - readenv() failed, using default environment > > musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn) > musb-hdrc: MHDRC RTL version 2.0 > musb-hdrc: setup fifo_mode 4 > musb-hdrc: 28/31 max ep, 16384/16384 memory > USB Peripheral mode controller at 47401000 using PIO, IRQ 0 > musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn) > musb-hdrc: MHDRC RTL version 2.0 > musb-hdrc: setup fifo_mode 4 > musb-hdrc: 28/31 max ep, 16384/16384 memory > USB Host mode controller at 47401800 using PIO, IRQ 0 > Net: cpsw, usb_ether > Hit any key to stop autoboot: 0 > mmc0 is current device > SD/MMC found on device 0 > reading uEnv.txt > 167 bytes read in 3 ms (53.7 KiB/s) > Loaded environment from uEnv.txt > Importing environment from mmc ... > Running uenvcmd ... > cpsw Waiting for PHY auto negotiation to complete. done > link up on port 0, speed 100, full duplex > BOOTP broadcast 1 > BOOTP broadcast 2 > *** Unhandled DHCP Option in OFFER/ACK: 44 > *** Unhandled DHCP Option in OFFER/ACK: 46 > *** Unhandled DHCP Option in OFFER/ACK: 44 > *** Unhandled DHCP Option in OFFER/ACK: 46 > DHCP client bound to address 10.0.0.112 > Using cpsw device > TFTP from server 10.0.0.100; our IP address is 10.0.0.112 > Filename '/nanobone/uImage-dtb'. > Load address: 0x80000000 > Loading: ################################################################# > ################################################################# > ################################################################# > ################################################################# > ########### > 627.9 KiB/s > done > Bytes transferred = 3963919 (3c7c0f hex) > ## Booting kernel from Legacy Image at 80000000 ... > Image Name: Linux > Image Type: ARM Linux Kernel Image (uncompressed) > Data Size: 3963855 Bytes = 3.8 MiB > Load Address: 80008000 > Entry Point: 80008000 > Verifying Checksum ... OK > Loading Kernel Image ... OK > OK > > Starting kernel ... > > Following works for me: Kernel === git checkout next-20130122 make distclean make omap2plus_defconfig <Enable the appended DTB related options via menuconfig> make -j7 cat arch/arm/boot/zImage arch/arm/boot/dts/am335x-bone.dtb > arch/arm/boot/zImage-dtb.am335x-bone mkimage -A arm -O linux -C none -T kernel -a 0x80008000 -e 0x80008000 -n 'Linux' -d arch/arm/boot/zImage-dtb.am335x-bone arch/arm/boot/uImage-dtb.am335x-bone U-Boot === Built from v2013.01 Bootlog === U-Boot SPL 2013.01 (Jan 22 2013 - 18:47:57) OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img U-Boot 2013.01 (Jan 22 2013 - 18:47:57) I2C: ready DRAM: 256 MiB WARNING: Caches not enabled NAND: No NAND device found!!! 0 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 *** Warning - readenv() failed, using default environment musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Peripheral mode controller at 47401000 using PIO, IRQ 0 musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Host mode controller at 47401800 using PIO, IRQ 0 Net: cpsw, usb_ether Hit any key to stop autoboot: 0 U-Boot# setenv serverip 172.24.133.119 U-Boot# setenv bootfile uImage-dtb.am335x-bone U-Boot# dhcp 80200000 link up on port 0, speed 100, full duplex BOOTP broadcast 1 DHCP client bound to address 172.24.190.59 Using cpsw device TFTP from server 172.24.133.119; our IP address is 172.24.190.59; sending through gateway 172.24.188.1 Filename 'uImage-dtb.am335x-bone'. Load address: 0x80200000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ##T ############################################################### ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ########################################################## 183.6 KiB/s done Bytes transferred = 3956239 (3c5e0f hex) U-Boot# setenv bootargs console=ttyO0,115200n8 debug ignore_loglevel earlyprintk=serial init=/bin/sh mem=128M root=/dev/ram rw initrd=0x82000000,16MB ramdisk_size=65536 U-Boot# mmc rescan 0 U-Boot# fatload mmc 0 82000000 ramdisk-pm.gz reading ramdisk-pm.gz 2022580 bytes read in 252 ms (7.7 MiB/s) U-Boot# bootm 0x80200000 ## Booting kernel from Legacy Image at 80200000 ... Image Name: Linux Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3956175 Bytes = 3.8 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 3.8.0-rc4-next-20130122 (a0393953@psplinux063) (gcc version 4.5.3 20110311 (prerelease) (GCC) ) #1 SMP Tue Jan 22 18:43:06 IST 2013 [ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [ 0.000000] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone [ 0.000000] debug: ignoring loglevel setting. [ 0.000000] Memory policy: ECC disabled, Data cache writeback [ 0.000000] On node 0 totalpages: 32512 [ 0.000000] free_area_init_node: node 0, pgdat c07d3ec0, node_mem_map c0d35000 [ 0.000000] Normal zone: 256 pages used for memmap [ 0.000000] Normal zone: 0 pages reserved [ 0.000000] Normal zone: 32512 pages, LIFO batch:7 [ 0.000000] AM335X ES1.0 (neon ) [ 0.000000] PERCPU: Embedded 9 pages/cpu @c0e3d000 s13056 r8192 d15616 u36864 [ 0.000000] pcpu-alloc: s13056 r8192 d15616 u36864 alloc=9*4096 [ 0.000000] pcpu-alloc: [0] 0 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32256 [ 0.000000] Kernel command line: console=ttyO0,115200n8 debug ignore_loglevel earlyprintk=serial init=/bin/sh mem=128M root=/dev/ram rw initrd=0x82000000,16MB ramdisk_size=65536 [ 0.000000] PID hash table entries: 512 (order: -1, 2048 bytes) [ 0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) [ 0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) [ 0.000000] __ex_table already sorted, skipping sort [ 0.000000] Memory: 127MB = 127MB total [ 0.000000] Memory: 98944k/98944k available, 32128k 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] vmalloc : 0xc8800000 - 0xff000000 ( 872 MB) [ 0.000000] lowmem : 0xc0000000 - 0xc8000000 ( 128 MB) [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) [ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB) [ 0.000000] .text : 0xc0008000 - 0xc06e9880 (7047 kB) [ 0.000000] .init : 0xc06ea000 - 0xc073e300 ( 337 kB) [ 0.000000] .data : 0xc0740000 - 0xc07d6860 ( 603 kB) [ 0.000000] .bss : 0xc07d6860 - 0xc0d317b0 (5484 kB) [ 0.000000] Hierarchical RCU implementation. [ 0.000000] RCU restricting CPUs from NR_CPUS=2 to nr_cpu_ids=1. [ 0.000000] NR_IRQS:16 nr_irqs:16 16 [ 0.000000] IRQ: Found an INTC at 0xfa200000 (revision 5.0) with 128 interrupts [ 0.000000] Total of 128 interrupts on 1 active controller [ 0.000000] OMAP clockevent source: GPTIMER1 at 24000000 Hz [ 0.000000] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms [ 0.000000] OMAP clocksource: GPTIMER2 at 24000000 Hz [ 0.000000] Console: colour dummy device 80x30 [ 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.001254] Calibrating delay loop... 364.48 BogoMIPS (lpj=1425408) [ 0.109085] pid_max: default: 32768 minimum: 301 [ 0.109681] Security Framework initialized [ 0.109882] Mount-cache hash table entries: 512 [ 0.121969] CPU: Testing write buffer coherency: ok [ 0.123774] CPU0: thread -1, cpu 0, socket -1, mpidr 0 [ 0.123868] Setting up static identity map for 0x804ecd48 - 0x804ecdb8 [ 0.127107] Brought up 1 CPUs [ 0.127140] SMP: Total of 1 processors activated (364.48 BogoMIPS). [ 0.130829] devtmpfs: initialized [ 0.146231] ttyO0 used as console in debug mode: uart0 clocks will not be gated [ 0.209016] pinctrl core: initialized pinctrl subsystem [ 0.216451] regulator-dummy: no parameters [ 0.219522] NET: Registered protocol family 16 [ 0.220528] DMA: preallocated 256 KiB pool for atomic coherent allocations [ 0.222118] omap-gpmc omap-gpmc: GPMC revision 6.0 [ 0.251333] gpiochip_add: registered GPIOs 0 to 31 on device: gpio [ 0.251927] OMAP GPIO hardware version 0.1 [ 0.255800] gpiochip_add: registered GPIOs 32 to 63 on device: gpio [ 0.259807] gpiochip_add: registered GPIOs 64 to 95 on device: gpio [ 0.263355] gpiochip_add: registered GPIOs 96 to 127 on device: gpio [ 0.278062] No ATAGs? [ 0.278097] hw-breakpoint: debug architecture 0x4 unsupported. [ 0.282814] Serial: AMBA PL011 UART driver [ 0.361131] bio: create slab <bio-0> at 0 [ 0.465566] omap-dma-engine omap-dma-engine: OMAP DMA engine driver [ 0.476999] SCSI subsystem initialized [ 0.480100] usbcore: registered new interface driver usbfs [ 0.480733] usbcore: registered new interface driver hub [ 0.481725] usbcore: registered new device driver usb [ 0.484797] omap_i2c 44e0b000.i2c: did not get pins for i2c error: -19 [ 0.487289] omap_i2c 44e0b000.i2c: bus 0 rev0.11 at 400 kHz [ 0.494498] DCDC1: at 1800 mV [ 0.497346] vdd_mpu: 925 <--> 1325 mV at 1275 mV [ 0.500720] vdd_core: 925 <--> 1150 mV at 1100 mV [ 0.503612] LDO1: at 1800 mV [ 0.506134] LDO2: at 3300 mV [ 0.509103] LDO3: at 3300 mV [ 0.511612] LDO4: at 3300 mV [ 0.513852] tps65217 0-0024: TPS65217 ID 0xf version 1.1 [ 0.523930] Switching to clocksource gp_timer [ 0.692430] NET: Registered protocol family 2 [ 0.694878] TCP established hash table entries: 1024 (order: 1, 8192 bytes) [ 0.695123] TCP bind hash table entries: 1024 (order: 3, 36864 bytes) [ 0.695757] TCP: Hash tables configured (established 1024 bind 1024) [ 0.696026] TCP: reno registered [ 0.696069] UDP hash table entries: 256 (order: 2, 20480 bytes) [ 0.696653] UDP-Lite hash table entries: 256 (order: 2, 20480 bytes) [ 0.697852] NET: Registered protocol family 1 [ 0.699530] RPC: Registered named UNIX socket transport module. [ 0.699559] RPC: Registered udp transport module. [ 0.699576] RPC: Registered tcp transport module. [ 0.699592] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 0.700848] Trying to unpack rootfs image as initramfs... [ 0.703450] rootfs image is not initramfs (no cpio magic); looks like an initrd [ 0.841357] Freeing initrd memory: 16384K [ 0.841625] NetWinder Floating Point Emulator V0.97 (double precision) [ 0.842474] CPU PMU: probing PMU on CPU 0 [ 0.842520] hw perfevents: enabled with ARMv7 Cortex-A8 PMU driver, 5 counters available [ 1.054500] VFS: Disk quotas dquot_6.5.2 [ 1.054811] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) [ 1.058444] NFS: Registering the id_resolver key type [ 1.059059] Key type id_resolver registered [ 1.059089] Key type id_legacy registered [ 1.059272] jffs2: version 2.2. (NAND) (SUMMARY) © 2001-2006 Red Hat, Inc. [ 1.059967] msgmni has been set to 225 [ 1.064654] io scheduler noop registered [ 1.064688] io scheduler deadline registered [ 1.064811] io scheduler cfq registered (default) [ 1.066454] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568 [ 1.072242] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled [ 1.081518] omap_uart 44e09000.serial: did not get pins for uart0 error: -19 [ 1.082185] 44e09000.serial: ttyO0 at MMIO 0x44e09000 (irq = 88) is a OMAP UART0 [ 1.810770] console [ttyO0] enabled [ 1.857842] brd: module loaded [ 1.888668] loop: module loaded [ 1.898978] mtdoops: mtd device (mtddev=name/number) must be supplied [ 1.907161] OneNAND driver initializing [ 1.919778] usbcore: registered new interface driver asix [ 1.926317] usbcore: registered new interface driver cdc_ether [ 1.933710] usbcore: registered new interface driver smsc95xx [ 1.940554] usbcore: registered new interface driver net1080 [ 1.947405] usbcore: registered new interface driver cdc_subset [ 1.954393] usbcore: registered new interface driver zaurus [ 1.960925] usbcore: registered new interface driver cdc_ncm [ 1.970109] usbcore: registered new interface driver cdc_wdm [ 1.976072] Initializing USB Mass Storage driver... [ 1.982138] usbcore: registered new interface driver usb-storage [ 1.988616] USB Mass Storage support registered. [ 1.994334] usbcore: registered new interface driver usbtest [ 2.003751] mousedev: PS/2 mouse device common for all mice [ 2.014783] i2c /dev entries driver [ 2.021637] Driver for 1-wire Dallas network protocol. [ 2.033754] omap_wdt: OMAP Watchdog Timer Rev 0x01: initial timeout 60 sec [ 2.048194] usbcore: registered new interface driver usbhid [ 2.054080] usbhid: USB HID core driver [ 2.059877] oprofile: using arm/armv7 [ 2.065057] TCP: cubic registered [ 2.068566] Initializing XFRM netlink socket [ 2.073446] NET: Registered protocol family 17 [ 2.078271] NET: Registered protocol family 15 [ 2.083554] Key type dns_resolver registered [ 2.088379] VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 3 [ 2.096622] ThumbEE CPU extension supported. [ 2.173009] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6 [ 2.179436] davinci_mdio 4a101000.mdio: detected phy mask fffffffe [ 2.189615] libphy: 4a101000.mdio: probed [ 2.193878] davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00, driver SMSC LAN8710/LAN8720 [ 2.204140] Random MACID = ca:fe:8a:07:ba:03 [ 2.214820] drivers/rtc/hctosys.c: unable to open rtc device (rtc0) [ 2.226373] RAMDISK: gzip image found at block 0 [ 2.691956] VFS: Mounted root (ext2 filesystem) on device 1:0. [ 2.699599] devtmpfs: mounted [ 2.703581] Freeing init memory: 336K /bin/sh: can't access€ÑÑåoR½‰½¹Ñɽ±¢Õ?.«¤Ë–VHè Òä / # A dumb question... in your case what's the bootargs set? Note that the mainline kernel for AM335x doesn't have MMC support yet and the default bootargs is set to rootfs on MMC. Regards, Vaibhav ^ permalink raw reply [flat|nested] 64+ messages in thread
* OMAP baseline test results for v3.8-rc4 @ 2013-01-22 13:32 ` Bedia, Vaibhav 0 siblings, 0 replies; 64+ messages in thread From: Bedia, Vaibhav @ 2013-01-22 13:32 UTC (permalink / raw) To: linux-arm-kernel On Tue, Jan 22, 2013 at 15:45:08, Mark Jackson wrote: > On 22/01/13 02:24, Paul Walmsley wrote: > > > > Hi guys, > > > > Regarding the AM33xx test failures with appended DTBs, it would be very > > helpful if especially the TI people could try reproducing the problem. > > My non-working setup (I'm using a recent U-Boot) is as follows ... > > [Note that the DTB patch mentioned elsewhere in this thread seems to be *already* applied to -next] > > $ git describe > next-20130121 > $ make -j 8 ARCH=arm CROSS_COMPILE=arm-linux- omap2plus_defconfig > $ make -j 8 ARCH=arm CROSS_COMPILE=arm-linux- menuconfig > CONFIG_ARM_APPENDED_DTB=y > CONFIG_ARM_ATAG_DTB_COMPAT=y > CONFIG_EARLY_PRINTK=y > $ make -j 8 ARCH=arm CROSS_COMPILE=arm-linux- > $ cat arch/arm/boot/zImage arch/arm/boot/dtb/am335x-bone.dtb > arch/arm/boot/zImage-dtb.am335x-bone > $ scripts/mkuboot.sh -A arm -O linux -C none -T kernel -a 0?80008000 -e 0?80008000 -n ?Linux? -d > arch/arm/boot/zImage-dtb.am335x-bone arch/arm/boot/uImage-dtb.am335x-bone > $ cp arch/arm/boot/uImage-dtb.am335x-bone /tftpboot/nanobone/uImage-dtb > > And when I boot:- > > U-Boot SPL 2013.01 (Jan 16 2013 - 15:20:58) > OMAP SD/MMC: 0 > reading u-boot.img > reading u-boot.img > > > U-Boot 2013.01 (Jan 16 2013 - 15:20:58) > > I2C: ready > DRAM: 256 MiB > WARNING: Caches not enabled > NAND: No NAND device found!!! > 0 MiB > MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 > *** Warning - readenv() failed, using default environment > > musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn) > musb-hdrc: MHDRC RTL version 2.0 > musb-hdrc: setup fifo_mode 4 > musb-hdrc: 28/31 max ep, 16384/16384 memory > USB Peripheral mode controller at 47401000 using PIO, IRQ 0 > musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn) > musb-hdrc: MHDRC RTL version 2.0 > musb-hdrc: setup fifo_mode 4 > musb-hdrc: 28/31 max ep, 16384/16384 memory > USB Host mode controller at 47401800 using PIO, IRQ 0 > Net: cpsw, usb_ether > Hit any key to stop autoboot: 0 > mmc0 is current device > SD/MMC found on device 0 > reading uEnv.txt > 167 bytes read in 3 ms (53.7 KiB/s) > Loaded environment from uEnv.txt > Importing environment from mmc ... > Running uenvcmd ... > cpsw Waiting for PHY auto negotiation to complete. done > link up on port 0, speed 100, full duplex > BOOTP broadcast 1 > BOOTP broadcast 2 > *** Unhandled DHCP Option in OFFER/ACK: 44 > *** Unhandled DHCP Option in OFFER/ACK: 46 > *** Unhandled DHCP Option in OFFER/ACK: 44 > *** Unhandled DHCP Option in OFFER/ACK: 46 > DHCP client bound to address 10.0.0.112 > Using cpsw device > TFTP from server 10.0.0.100; our IP address is 10.0.0.112 > Filename '/nanobone/uImage-dtb'. > Load address: 0x80000000 > Loading: ################################################################# > ################################################################# > ################################################################# > ################################################################# > ########### > 627.9 KiB/s > done > Bytes transferred = 3963919 (3c7c0f hex) > ## Booting kernel from Legacy Image at 80000000 ... > Image Name: Linux > Image Type: ARM Linux Kernel Image (uncompressed) > Data Size: 3963855 Bytes = 3.8 MiB > Load Address: 80008000 > Entry Point: 80008000 > Verifying Checksum ... OK > Loading Kernel Image ... OK > OK > > Starting kernel ... > > Following works for me: Kernel === git checkout next-20130122 make distclean make omap2plus_defconfig <Enable the appended DTB related options via menuconfig> make -j7 cat arch/arm/boot/zImage arch/arm/boot/dts/am335x-bone.dtb > arch/arm/boot/zImage-dtb.am335x-bone mkimage -A arm -O linux -C none -T kernel -a 0x80008000 -e 0x80008000 -n 'Linux' -d arch/arm/boot/zImage-dtb.am335x-bone arch/arm/boot/uImage-dtb.am335x-bone U-Boot === Built from v2013.01 Bootlog === U-Boot SPL 2013.01 (Jan 22 2013 - 18:47:57) OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img U-Boot 2013.01 (Jan 22 2013 - 18:47:57) I2C: ready DRAM: 256 MiB WARNING: Caches not enabled NAND: No NAND device found!!! 0 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 *** Warning - readenv() failed, using default environment musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Peripheral mode controller at 47401000 using PIO, IRQ 0 musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Host mode controller at 47401800 using PIO, IRQ 0 Net: cpsw, usb_ether Hit any key to stop autoboot: 0 U-Boot# setenv serverip 172.24.133.119 U-Boot# setenv bootfile uImage-dtb.am335x-bone U-Boot# dhcp 80200000 link up on port 0, speed 100, full duplex BOOTP broadcast 1 DHCP client bound to address 172.24.190.59 Using cpsw device TFTP from server 172.24.133.119; our IP address is 172.24.190.59; sending through gateway 172.24.188.1 Filename 'uImage-dtb.am335x-bone'. Load address: 0x80200000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ##T ############################################################### ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ########################################################## 183.6 KiB/s done Bytes transferred = 3956239 (3c5e0f hex) U-Boot# setenv bootargs console=ttyO0,115200n8 debug ignore_loglevel earlyprintk=serial init=/bin/sh mem=128M root=/dev/ram rw initrd=0x82000000,16MB ramdisk_size=65536 U-Boot# mmc rescan 0 U-Boot# fatload mmc 0 82000000 ramdisk-pm.gz reading ramdisk-pm.gz 2022580 bytes read in 252 ms (7.7 MiB/s) U-Boot# bootm 0x80200000 ## Booting kernel from Legacy Image at 80200000 ... Image Name: Linux Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3956175 Bytes = 3.8 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 3.8.0-rc4-next-20130122 (a0393953 at psplinux063) (gcc version 4.5.3 20110311 (prerelease) (GCC) ) #1 SMP Tue Jan 22 18:43:06 IST 2013 [ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [ 0.000000] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone [ 0.000000] debug: ignoring loglevel setting. [ 0.000000] Memory policy: ECC disabled, Data cache writeback [ 0.000000] On node 0 totalpages: 32512 [ 0.000000] free_area_init_node: node 0, pgdat c07d3ec0, node_mem_map c0d35000 [ 0.000000] Normal zone: 256 pages used for memmap [ 0.000000] Normal zone: 0 pages reserved [ 0.000000] Normal zone: 32512 pages, LIFO batch:7 [ 0.000000] AM335X ES1.0 (neon ) [ 0.000000] PERCPU: Embedded 9 pages/cpu @c0e3d000 s13056 r8192 d15616 u36864 [ 0.000000] pcpu-alloc: s13056 r8192 d15616 u36864 alloc=9*4096 [ 0.000000] pcpu-alloc: [0] 0 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32256 [ 0.000000] Kernel command line: console=ttyO0,115200n8 debug ignore_loglevel earlyprintk=serial init=/bin/sh mem=128M root=/dev/ram rw initrd=0x82000000,16MB ramdisk_size=65536 [ 0.000000] PID hash table entries: 512 (order: -1, 2048 bytes) [ 0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) [ 0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) [ 0.000000] __ex_table already sorted, skipping sort [ 0.000000] Memory: 127MB = 127MB total [ 0.000000] Memory: 98944k/98944k available, 32128k 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] vmalloc : 0xc8800000 - 0xff000000 ( 872 MB) [ 0.000000] lowmem : 0xc0000000 - 0xc8000000 ( 128 MB) [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) [ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB) [ 0.000000] .text : 0xc0008000 - 0xc06e9880 (7047 kB) [ 0.000000] .init : 0xc06ea000 - 0xc073e300 ( 337 kB) [ 0.000000] .data : 0xc0740000 - 0xc07d6860 ( 603 kB) [ 0.000000] .bss : 0xc07d6860 - 0xc0d317b0 (5484 kB) [ 0.000000] Hierarchical RCU implementation. [ 0.000000] RCU restricting CPUs from NR_CPUS=2 to nr_cpu_ids=1. [ 0.000000] NR_IRQS:16 nr_irqs:16 16 [ 0.000000] IRQ: Found an INTC at 0xfa200000 (revision 5.0) with 128 interrupts [ 0.000000] Total of 128 interrupts on 1 active controller [ 0.000000] OMAP clockevent source: GPTIMER1 at 24000000 Hz [ 0.000000] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms [ 0.000000] OMAP clocksource: GPTIMER2 at 24000000 Hz [ 0.000000] Console: colour dummy device 80x30 [ 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.001254] Calibrating delay loop... 364.48 BogoMIPS (lpj=1425408) [ 0.109085] pid_max: default: 32768 minimum: 301 [ 0.109681] Security Framework initialized [ 0.109882] Mount-cache hash table entries: 512 [ 0.121969] CPU: Testing write buffer coherency: ok [ 0.123774] CPU0: thread -1, cpu 0, socket -1, mpidr 0 [ 0.123868] Setting up static identity map for 0x804ecd48 - 0x804ecdb8 [ 0.127107] Brought up 1 CPUs [ 0.127140] SMP: Total of 1 processors activated (364.48 BogoMIPS). [ 0.130829] devtmpfs: initialized [ 0.146231] ttyO0 used as console in debug mode: uart0 clocks will not be gated [ 0.209016] pinctrl core: initialized pinctrl subsystem [ 0.216451] regulator-dummy: no parameters [ 0.219522] NET: Registered protocol family 16 [ 0.220528] DMA: preallocated 256 KiB pool for atomic coherent allocations [ 0.222118] omap-gpmc omap-gpmc: GPMC revision 6.0 [ 0.251333] gpiochip_add: registered GPIOs 0 to 31 on device: gpio [ 0.251927] OMAP GPIO hardware version 0.1 [ 0.255800] gpiochip_add: registered GPIOs 32 to 63 on device: gpio [ 0.259807] gpiochip_add: registered GPIOs 64 to 95 on device: gpio [ 0.263355] gpiochip_add: registered GPIOs 96 to 127 on device: gpio [ 0.278062] No ATAGs? [ 0.278097] hw-breakpoint: debug architecture 0x4 unsupported. [ 0.282814] Serial: AMBA PL011 UART driver [ 0.361131] bio: create slab <bio-0> at 0 [ 0.465566] omap-dma-engine omap-dma-engine: OMAP DMA engine driver [ 0.476999] SCSI subsystem initialized [ 0.480100] usbcore: registered new interface driver usbfs [ 0.480733] usbcore: registered new interface driver hub [ 0.481725] usbcore: registered new device driver usb [ 0.484797] omap_i2c 44e0b000.i2c: did not get pins for i2c error: -19 [ 0.487289] omap_i2c 44e0b000.i2c: bus 0 rev0.11 at 400 kHz [ 0.494498] DCDC1: at 1800 mV [ 0.497346] vdd_mpu: 925 <--> 1325 mV at 1275 mV [ 0.500720] vdd_core: 925 <--> 1150 mV at 1100 mV [ 0.503612] LDO1: at 1800 mV [ 0.506134] LDO2: at 3300 mV [ 0.509103] LDO3: at 3300 mV [ 0.511612] LDO4: at 3300 mV [ 0.513852] tps65217 0-0024: TPS65217 ID 0xf version 1.1 [ 0.523930] Switching to clocksource gp_timer [ 0.692430] NET: Registered protocol family 2 [ 0.694878] TCP established hash table entries: 1024 (order: 1, 8192 bytes) [ 0.695123] TCP bind hash table entries: 1024 (order: 3, 36864 bytes) [ 0.695757] TCP: Hash tables configured (established 1024 bind 1024) [ 0.696026] TCP: reno registered [ 0.696069] UDP hash table entries: 256 (order: 2, 20480 bytes) [ 0.696653] UDP-Lite hash table entries: 256 (order: 2, 20480 bytes) [ 0.697852] NET: Registered protocol family 1 [ 0.699530] RPC: Registered named UNIX socket transport module. [ 0.699559] RPC: Registered udp transport module. [ 0.699576] RPC: Registered tcp transport module. [ 0.699592] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 0.700848] Trying to unpack rootfs image as initramfs... [ 0.703450] rootfs image is not initramfs (no cpio magic); looks like an initrd [ 0.841357] Freeing initrd memory: 16384K [ 0.841625] NetWinder Floating Point Emulator V0.97 (double precision) [ 0.842474] CPU PMU: probing PMU on CPU 0 [ 0.842520] hw perfevents: enabled with ARMv7 Cortex-A8 PMU driver, 5 counters available [ 1.054500] VFS: Disk quotas dquot_6.5.2 [ 1.054811] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) [ 1.058444] NFS: Registering the id_resolver key type [ 1.059059] Key type id_resolver registered [ 1.059089] Key type id_legacy registered [ 1.059272] jffs2: version 2.2. (NAND) (SUMMARY) ?? 2001-2006 Red Hat, Inc. [ 1.059967] msgmni has been set to 225 [ 1.064654] io scheduler noop registered [ 1.064688] io scheduler deadline registered [ 1.064811] io scheduler cfq registered (default) [ 1.066454] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568 [ 1.072242] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled [ 1.081518] omap_uart 44e09000.serial: did not get pins for uart0 error: -19 [ 1.082185] 44e09000.serial: ttyO0 at MMIO 0x44e09000 (irq = 88) is a OMAP UART0 [ 1.810770] console [ttyO0] enabled [ 1.857842] brd: module loaded [ 1.888668] loop: module loaded [ 1.898978] mtdoops: mtd device (mtddev=name/number) must be supplied [ 1.907161] OneNAND driver initializing [ 1.919778] usbcore: registered new interface driver asix [ 1.926317] usbcore: registered new interface driver cdc_ether [ 1.933710] usbcore: registered new interface driver smsc95xx [ 1.940554] usbcore: registered new interface driver net1080 [ 1.947405] usbcore: registered new interface driver cdc_subset [ 1.954393] usbcore: registered new interface driver zaurus [ 1.960925] usbcore: registered new interface driver cdc_ncm [ 1.970109] usbcore: registered new interface driver cdc_wdm [ 1.976072] Initializing USB Mass Storage driver... [ 1.982138] usbcore: registered new interface driver usb-storage [ 1.988616] USB Mass Storage support registered. [ 1.994334] usbcore: registered new interface driver usbtest [ 2.003751] mousedev: PS/2 mouse device common for all mice [ 2.014783] i2c /dev entries driver [ 2.021637] Driver for 1-wire Dallas network protocol. [ 2.033754] omap_wdt: OMAP Watchdog Timer Rev 0x01: initial timeout 60 sec [ 2.048194] usbcore: registered new interface driver usbhid [ 2.054080] usbhid: USB HID core driver [ 2.059877] oprofile: using arm/armv7 [ 2.065057] TCP: cubic registered [ 2.068566] Initializing XFRM netlink socket [ 2.073446] NET: Registered protocol family 17 [ 2.078271] NET: Registered protocol family 15 [ 2.083554] Key type dns_resolver registered [ 2.088379] VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 3 [ 2.096622] ThumbEE CPU extension supported. [ 2.173009] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6 [ 2.179436] davinci_mdio 4a101000.mdio: detected phy mask fffffffe [ 2.189615] libphy: 4a101000.mdio: probed [ 2.193878] davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00, driver SMSC LAN8710/LAN8720 [ 2.204140] Random MACID = ca:fe:8a:07:ba:03 [ 2.214820] drivers/rtc/hctosys.c: unable to open rtc device (rtc0) [ 2.226373] RAMDISK: gzip image found at block 0 [ 2.691956] VFS: Mounted root (ext2 filesystem) on device 1:0. [ 2.699599] devtmpfs: mounted [ 2.703581] Freeing init memory: 336K /bin/sh: can't access????oR?????????????.????VH? ?? / # A dumb question... in your case what's the bootargs set? Note that the mainline kernel for AM335x doesn't have MMC support yet and the default bootargs is set to rootfs on MMC. Regards, Vaibhav ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: OMAP baseline test results for v3.8-rc4 2013-01-22 13:32 ` Bedia, Vaibhav @ 2013-01-22 13:39 ` Mark Jackson -1 siblings, 0 replies; 64+ messages in thread From: Mark Jackson @ 2013-01-22 13:39 UTC (permalink / raw) To: Bedia, Vaibhav Cc: Menon, Nishanth, Porter, Matt, Paul Walmsley, Richard Cochran, Hiremath, Vaibhav, Peter Korsgaard, linux-omap\@vger.kernel.org, linux-arm-kernel\@lists.infradead.org On 22/01/13 13:32, Bedia, Vaibhav wrote: <snip> > Following works for me: > > Kernel > === > git checkout next-20130122 > make distclean > make omap2plus_defconfig > <Enable the appended DTB related options via menuconfig> > make -j7 > cat arch/arm/boot/zImage arch/arm/boot/dts/am335x-bone.dtb > arch/arm/boot/zImage-dtb.am335x-bone > mkimage -A arm -O linux -C none -T kernel -a 0x80008000 -e 0x80008000 -n 'Linux' -d arch/arm/boot/zImage-dtb.am335x-bone arch/arm/boot/uImage-dtb.am335x-bone > > U-Boot > === > Built from v2013.01 <snip> > A dumb question... in your case what's the bootargs set? Note that the mainline > kernel for AM335x doesn't have MMC support yet and the default bootargs is set to > rootfs on MMC. Yes ... I'm trying to boot from a rootfs on MMC:- Kernel command line: console=ttyO0,115200n8 earlyprintk debug root=/dev/mmcblk0p2 ro rootfstype=ext2 rootwait But I should get *something* from the kernel before it starts trying to access the rootfs ? Regards Mark J. ^ permalink raw reply [flat|nested] 64+ messages in thread
* OMAP baseline test results for v3.8-rc4 @ 2013-01-22 13:39 ` Mark Jackson 0 siblings, 0 replies; 64+ messages in thread From: Mark Jackson @ 2013-01-22 13:39 UTC (permalink / raw) To: linux-arm-kernel On 22/01/13 13:32, Bedia, Vaibhav wrote: <snip> > Following works for me: > > Kernel > === > git checkout next-20130122 > make distclean > make omap2plus_defconfig > <Enable the appended DTB related options via menuconfig> > make -j7 > cat arch/arm/boot/zImage arch/arm/boot/dts/am335x-bone.dtb > arch/arm/boot/zImage-dtb.am335x-bone > mkimage -A arm -O linux -C none -T kernel -a 0x80008000 -e 0x80008000 -n 'Linux' -d arch/arm/boot/zImage-dtb.am335x-bone arch/arm/boot/uImage-dtb.am335x-bone > > U-Boot > === > Built from v2013.01 <snip> > A dumb question... in your case what's the bootargs set? Note that the mainline > kernel for AM335x doesn't have MMC support yet and the default bootargs is set to > rootfs on MMC. Yes ... I'm trying to boot from a rootfs on MMC:- Kernel command line: console=ttyO0,115200n8 earlyprintk debug root=/dev/mmcblk0p2 ro rootfstype=ext2 rootwait But I should get *something* from the kernel before it starts trying to access the rootfs ? Regards Mark J. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: OMAP baseline test results for v3.8-rc4 2013-01-22 13:39 ` Mark Jackson @ 2013-01-22 18:23 ` Tony Lindgren -1 siblings, 0 replies; 64+ messages in thread From: Tony Lindgren @ 2013-01-22 18:23 UTC (permalink / raw) To: Mark Jackson Cc: Bedia, Vaibhav, Menon, Nishanth, Porter, Matt, Paul Walmsley, Richard Cochran, Hiremath, Vaibhav, Peter Korsgaard, linux-omap, linux-arm-kernel, Kevin Hilman * Mark Jackson <mpfj-list@mimc.co.uk> [130122 05:46]: > On 22/01/13 13:32, Bedia, Vaibhav wrote: > > <snip> > > > Following works for me: > > > > Kernel > > === > > git checkout next-20130122 > > make distclean > > make omap2plus_defconfig > > <Enable the appended DTB related options via menuconfig> > > make -j7 > > cat arch/arm/boot/zImage arch/arm/boot/dts/am335x-bone.dtb > arch/arm/boot/zImage-dtb.am335x-bone > > mkimage -A arm -O linux -C none -T kernel -a 0x80008000 -e 0x80008000 -n 'Linux' -d arch/arm/boot/zImage-dtb.am335x-bone arch/arm/boot/uImage-dtb.am335x-bone > > > > U-Boot > > === > > Built from v2013.01 > > <snip> > > > A dumb question... in your case what's the bootargs set? Note that the mainline > > kernel for AM335x doesn't have MMC support yet and the default bootargs is set to > > rootfs on MMC. > > Yes ... I'm trying to boot from a rootfs on MMC:- > > Kernel command line: console=ttyO0,115200n8 earlyprintk debug root=/dev/mmcblk0p2 ro rootfstype=ext2 > rootwait > > But I should get *something* from the kernel before it starts trying to access the rootfs ? Here's something Kevin fixed but did not send it out before going to a vacation. Can you give it a try with earlyprintk enabled? Note that this does not help with no output early on, that sounds like a bug configuring the DEBUG_LL port somewhere. Regards, Tony From: Kevin Hilman <khilman@deeprootsystems.com> Date: Tue, 15 Jan 2013 14:12:24 -0800 Subject: [PATCH] Fix omap_serial as module with debug_ll and earlyprintk Otherwise we can race with the earlyconsole getting turned off which can cause a non-booting system with earlyprintk enabled. [tony@atomide.com: updated description] Signed-off-by: Tony Lindgren <tony@atomide.com> --- Kevin, can I add your Signed-off-by to this one? --- a/arch/arm/mach-omap2/omap_device.c +++ b/arch/arm/mach-omap2/omap_device.c @@ -1298,4 +1298,4 @@ static int __init omap_device_late_init(void) bus_for_each_dev(&platform_bus_type, NULL, NULL, omap_device_late_idle); return 0; } -omap_late_initcall(omap_device_late_init); +late_initcall_sync(omap_device_late_init); ^ permalink raw reply [flat|nested] 64+ messages in thread
* OMAP baseline test results for v3.8-rc4 @ 2013-01-22 18:23 ` Tony Lindgren 0 siblings, 0 replies; 64+ messages in thread From: Tony Lindgren @ 2013-01-22 18:23 UTC (permalink / raw) To: linux-arm-kernel * Mark Jackson <mpfj-list@mimc.co.uk> [130122 05:46]: > On 22/01/13 13:32, Bedia, Vaibhav wrote: > > <snip> > > > Following works for me: > > > > Kernel > > === > > git checkout next-20130122 > > make distclean > > make omap2plus_defconfig > > <Enable the appended DTB related options via menuconfig> > > make -j7 > > cat arch/arm/boot/zImage arch/arm/boot/dts/am335x-bone.dtb > arch/arm/boot/zImage-dtb.am335x-bone > > mkimage -A arm -O linux -C none -T kernel -a 0x80008000 -e 0x80008000 -n 'Linux' -d arch/arm/boot/zImage-dtb.am335x-bone arch/arm/boot/uImage-dtb.am335x-bone > > > > U-Boot > > === > > Built from v2013.01 > > <snip> > > > A dumb question... in your case what's the bootargs set? Note that the mainline > > kernel for AM335x doesn't have MMC support yet and the default bootargs is set to > > rootfs on MMC. > > Yes ... I'm trying to boot from a rootfs on MMC:- > > Kernel command line: console=ttyO0,115200n8 earlyprintk debug root=/dev/mmcblk0p2 ro rootfstype=ext2 > rootwait > > But I should get *something* from the kernel before it starts trying to access the rootfs ? Here's something Kevin fixed but did not send it out before going to a vacation. Can you give it a try with earlyprintk enabled? Note that this does not help with no output early on, that sounds like a bug configuring the DEBUG_LL port somewhere. Regards, Tony From: Kevin Hilman <khilman@deeprootsystems.com> Date: Tue, 15 Jan 2013 14:12:24 -0800 Subject: [PATCH] Fix omap_serial as module with debug_ll and earlyprintk Otherwise we can race with the earlyconsole getting turned off which can cause a non-booting system with earlyprintk enabled. [tony at atomide.com: updated description] Signed-off-by: Tony Lindgren <tony@atomide.com> --- Kevin, can I add your Signed-off-by to this one? --- a/arch/arm/mach-omap2/omap_device.c +++ b/arch/arm/mach-omap2/omap_device.c @@ -1298,4 +1298,4 @@ static int __init omap_device_late_init(void) bus_for_each_dev(&platform_bus_type, NULL, NULL, omap_device_late_idle); return 0; } -omap_late_initcall(omap_device_late_init); +late_initcall_sync(omap_device_late_init); ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: OMAP baseline test results for v3.8-rc4 2013-01-22 18:23 ` Tony Lindgren @ 2013-01-23 10:18 ` Mark Jackson -1 siblings, 0 replies; 64+ messages in thread From: Mark Jackson @ 2013-01-23 10:18 UTC (permalink / raw) To: Tony Lindgren Cc: Bedia, Vaibhav, Menon, Nishanth, Porter, Matt, Paul Walmsley, Richard Cochran, Hiremath, Vaibhav, Peter Korsgaard, linux-omap, linux-arm-kernel, Kevin Hilman On 22/01/13 18:23, Tony Lindgren wrote: > * Mark Jackson <mpfj-list@mimc.co.uk> [130122 05:46]: >> On 22/01/13 13:32, Bedia, Vaibhav wrote: >> >> <snip> >> >>> Following works for me: >>> >>> Kernel >>> === >>> git checkout next-20130122 >>> make distclean >>> make omap2plus_defconfig >>> <Enable the appended DTB related options via menuconfig> >>> make -j7 >>> cat arch/arm/boot/zImage arch/arm/boot/dts/am335x-bone.dtb > arch/arm/boot/zImage-dtb.am335x-bone >>> mkimage -A arm -O linux -C none -T kernel -a 0x80008000 -e 0x80008000 -n 'Linux' -d arch/arm/boot/zImage-dtb.am335x-bone arch/arm/boot/uImage-dtb.am335x-bone >>> >>> U-Boot >>> === >>> Built from v2013.01 >> >> <snip> >> >>> A dumb question... in your case what's the bootargs set? Note that the mainline >>> kernel for AM335x doesn't have MMC support yet and the default bootargs is set to >>> rootfs on MMC. >> >> Yes ... I'm trying to boot from a rootfs on MMC:- >> >> Kernel command line: console=ttyO0,115200n8 earlyprintk debug root=/dev/mmcblk0p2 ro rootfstype=ext2 >> rootwait >> >> But I should get *something* from the kernel before it starts trying to access the rootfs ? > > Here's something Kevin fixed but did not send it out before going to > a vacation. Can you give it a try with earlyprintk enabled? > > Note that this does not help with no output early on, that sounds > like a bug configuring the DEBUG_LL port somewhere. > > Regards, > > Tony > > > > From: Kevin Hilman <khilman@deeprootsystems.com> > Date: Tue, 15 Jan 2013 14:12:24 -0800 > Subject: [PATCH] Fix omap_serial as module with debug_ll and earlyprintk > > Otherwise we can race with the earlyconsole getting turned off > which can cause a non-booting system with earlyprintk enabled. > > [tony@atomide.com: updated description] > Signed-off-by: Tony Lindgren <tony@atomide.com> > > --- > > Kevin, can I add your Signed-off-by to this one? > > --- a/arch/arm/mach-omap2/omap_device.c > +++ b/arch/arm/mach-omap2/omap_device.c > @@ -1298,4 +1298,4 @@ static int __init omap_device_late_init(void) > bus_for_each_dev(&platform_bus_type, NULL, NULL, omap_device_late_idle); > return 0; > } > -omap_late_initcall(omap_device_late_init); > +late_initcall_sync(omap_device_late_init); > Sorry ... still no joy:- U-Boot# askenv bootargs Please enter 'bootargs':ttyO0,115200n8 earlyprintk root=/dev/mmcblk0p2 ro rootfstype=ext2 rootwait U-Boot# dhcp 80000000 10.0.0.100:/nanobone/uImage-dtb;bootm 80000000 link up on port 0, speed 100, full duplex BOOTP broadcast 1 *** Unhandled DHCP Option in OFFER/ACK: 44 *** Unhandled DHCP Option in OFFER/ACK: 46 *** Unhandled DHCP Option in OFFER/ACK: 44 *** Unhandled DHCP Option in OFFER/ACK: 46 DHCP client bound to address 10.0.0.112 Using cpsw device TFTP from server 10.0.0.100; our IP address is 10.0.0.112 Filename '/nanobone/uImage-dtb'. Load address: 0x80000000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ########### 625 KiB/s done Bytes transferred = 3972199 (3c9c67 hex) ## Booting kernel from Legacy Image at 80000000 ... Image Name: Linux 3.8.0-rc3-12154-gac00f0e-d Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3972135 Bytes = 3.8 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... My .config can be found at http://pastebin.com/rj5ptt7W Cheers Mark J. ^ permalink raw reply [flat|nested] 64+ messages in thread
* OMAP baseline test results for v3.8-rc4 @ 2013-01-23 10:18 ` Mark Jackson 0 siblings, 0 replies; 64+ messages in thread From: Mark Jackson @ 2013-01-23 10:18 UTC (permalink / raw) To: linux-arm-kernel On 22/01/13 18:23, Tony Lindgren wrote: > * Mark Jackson <mpfj-list@mimc.co.uk> [130122 05:46]: >> On 22/01/13 13:32, Bedia, Vaibhav wrote: >> >> <snip> >> >>> Following works for me: >>> >>> Kernel >>> === >>> git checkout next-20130122 >>> make distclean >>> make omap2plus_defconfig >>> <Enable the appended DTB related options via menuconfig> >>> make -j7 >>> cat arch/arm/boot/zImage arch/arm/boot/dts/am335x-bone.dtb > arch/arm/boot/zImage-dtb.am335x-bone >>> mkimage -A arm -O linux -C none -T kernel -a 0x80008000 -e 0x80008000 -n 'Linux' -d arch/arm/boot/zImage-dtb.am335x-bone arch/arm/boot/uImage-dtb.am335x-bone >>> >>> U-Boot >>> === >>> Built from v2013.01 >> >> <snip> >> >>> A dumb question... in your case what's the bootargs set? Note that the mainline >>> kernel for AM335x doesn't have MMC support yet and the default bootargs is set to >>> rootfs on MMC. >> >> Yes ... I'm trying to boot from a rootfs on MMC:- >> >> Kernel command line: console=ttyO0,115200n8 earlyprintk debug root=/dev/mmcblk0p2 ro rootfstype=ext2 >> rootwait >> >> But I should get *something* from the kernel before it starts trying to access the rootfs ? > > Here's something Kevin fixed but did not send it out before going to > a vacation. Can you give it a try with earlyprintk enabled? > > Note that this does not help with no output early on, that sounds > like a bug configuring the DEBUG_LL port somewhere. > > Regards, > > Tony > > > > From: Kevin Hilman <khilman@deeprootsystems.com> > Date: Tue, 15 Jan 2013 14:12:24 -0800 > Subject: [PATCH] Fix omap_serial as module with debug_ll and earlyprintk > > Otherwise we can race with the earlyconsole getting turned off > which can cause a non-booting system with earlyprintk enabled. > > [tony at atomide.com: updated description] > Signed-off-by: Tony Lindgren <tony@atomide.com> > > --- > > Kevin, can I add your Signed-off-by to this one? > > --- a/arch/arm/mach-omap2/omap_device.c > +++ b/arch/arm/mach-omap2/omap_device.c > @@ -1298,4 +1298,4 @@ static int __init omap_device_late_init(void) > bus_for_each_dev(&platform_bus_type, NULL, NULL, omap_device_late_idle); > return 0; > } > -omap_late_initcall(omap_device_late_init); > +late_initcall_sync(omap_device_late_init); > Sorry ... still no joy:- U-Boot# askenv bootargs Please enter 'bootargs':ttyO0,115200n8 earlyprintk root=/dev/mmcblk0p2 ro rootfstype=ext2 rootwait U-Boot# dhcp 80000000 10.0.0.100:/nanobone/uImage-dtb;bootm 80000000 link up on port 0, speed 100, full duplex BOOTP broadcast 1 *** Unhandled DHCP Option in OFFER/ACK: 44 *** Unhandled DHCP Option in OFFER/ACK: 46 *** Unhandled DHCP Option in OFFER/ACK: 44 *** Unhandled DHCP Option in OFFER/ACK: 46 DHCP client bound to address 10.0.0.112 Using cpsw device TFTP from server 10.0.0.100; our IP address is 10.0.0.112 Filename '/nanobone/uImage-dtb'. Load address: 0x80000000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ########### 625 KiB/s done Bytes transferred = 3972199 (3c9c67 hex) ## Booting kernel from Legacy Image at 80000000 ... Image Name: Linux 3.8.0-rc3-12154-gac00f0e-d Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3972135 Bytes = 3.8 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... My .config can be found at http://pastebin.com/rj5ptt7W Cheers Mark J. ^ permalink raw reply [flat|nested] 64+ messages in thread
* RE: OMAP baseline test results for v3.8-rc4 2013-01-22 18:23 ` Tony Lindgren @ 2013-01-23 14:32 ` Bedia, Vaibhav -1 siblings, 0 replies; 64+ messages in thread From: Bedia, Vaibhav @ 2013-01-23 14:32 UTC (permalink / raw) To: Tony Lindgren, Mark Jackson Cc: Menon, Nishanth, Porter, Matt, Paul Walmsley, Richard Cochran, Hiremath, Vaibhav, Peter Korsgaard, linux-omap, linux-arm-kernel, Kevin Hilman Hi Tony, On Tue, Jan 22, 2013 at 23:53:32, Tony Lindgren wrote: [...] > > > > But I should get *something* from the kernel before it starts trying to access the rootfs ? > > Here's something Kevin fixed but did not send it out before going to > a vacation. Can you give it a try with earlyprintk enabled? > > Note that this does not help with no output early on, that sounds > like a bug configuring the DEBUG_LL port somewhere. > I think earlyprintk on AM335x has not been functional for a while [1]. Will the latest patches from you to enable multiplatform debug-ll be sufficient to test this out? I am trying to track down the boot issues reported and just want to be sure of the dependencies. [1] http://marc.info/?l=linux-omap&m=134642491119235&w=2 [2] https://patchwork.kernel.org/patch/1896851/ Regards, Vaibhav ^ permalink raw reply [flat|nested] 64+ messages in thread
* OMAP baseline test results for v3.8-rc4 @ 2013-01-23 14:32 ` Bedia, Vaibhav 0 siblings, 0 replies; 64+ messages in thread From: Bedia, Vaibhav @ 2013-01-23 14:32 UTC (permalink / raw) To: linux-arm-kernel Hi Tony, On Tue, Jan 22, 2013 at 23:53:32, Tony Lindgren wrote: [...] > > > > But I should get *something* from the kernel before it starts trying to access the rootfs ? > > Here's something Kevin fixed but did not send it out before going to > a vacation. Can you give it a try with earlyprintk enabled? > > Note that this does not help with no output early on, that sounds > like a bug configuring the DEBUG_LL port somewhere. > I think earlyprintk on AM335x has not been functional for a while [1]. Will the latest patches from you to enable multiplatform debug-ll be sufficient to test this out? I am trying to track down the boot issues reported and just want to be sure of the dependencies. [1] http://marc.info/?l=linux-omap&m=134642491119235&w=2 [2] https://patchwork.kernel.org/patch/1896851/ Regards, Vaibhav ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: OMAP baseline test results for v3.8-rc4 2013-01-23 14:32 ` Bedia, Vaibhav @ 2013-01-25 16:59 ` Tony Lindgren -1 siblings, 0 replies; 64+ messages in thread From: Tony Lindgren @ 2013-01-25 16:59 UTC (permalink / raw) To: Bedia, Vaibhav Cc: Mark Jackson, Menon, Nishanth, Porter, Matt, Paul Walmsley, Richard Cochran, Hiremath, Vaibhav, Peter Korsgaard, linux-omap, linux-arm-kernel, Kevin Hilman * Bedia, Vaibhav <vaibhav.bedia@ti.com> [130123 06:35]: > Hi Tony, > > On Tue, Jan 22, 2013 at 23:53:32, Tony Lindgren wrote: > [...] > > > > > > But I should get *something* from the kernel before it starts trying to access the rootfs ? > > > > Here's something Kevin fixed but did not send it out before going to > > a vacation. Can you give it a try with earlyprintk enabled? > > > > Note that this does not help with no output early on, that sounds > > like a bug configuring the DEBUG_LL port somewhere. > > > > I think earlyprintk on AM335x has not been functional for a while [1]. > Will the latest patches from you to enable multiplatform debug-ll be sufficient > to test this out? I am trying to track down the boot issues reported and just > want to be sure of the dependencies. Yes you should check with current linux next and select the DEBUG_LL port manually. > [1] http://marc.info/?l=linux-omap&m=134642491119235&w=2 This one should no longer be needed as we now use the machine_id for board-generic.c for DT boot. > [2] https://patchwork.kernel.org/patch/1896851/ This alone won't work without multiplatform support. At least modifying the Kconfig to use the new settings for OMAP2PLUS is needed. Probably easiest to make sure it works in linux next first. Regards, Tony ^ permalink raw reply [flat|nested] 64+ messages in thread
* OMAP baseline test results for v3.8-rc4 @ 2013-01-25 16:59 ` Tony Lindgren 0 siblings, 0 replies; 64+ messages in thread From: Tony Lindgren @ 2013-01-25 16:59 UTC (permalink / raw) To: linux-arm-kernel * Bedia, Vaibhav <vaibhav.bedia@ti.com> [130123 06:35]: > Hi Tony, > > On Tue, Jan 22, 2013 at 23:53:32, Tony Lindgren wrote: > [...] > > > > > > But I should get *something* from the kernel before it starts trying to access the rootfs ? > > > > Here's something Kevin fixed but did not send it out before going to > > a vacation. Can you give it a try with earlyprintk enabled? > > > > Note that this does not help with no output early on, that sounds > > like a bug configuring the DEBUG_LL port somewhere. > > > > I think earlyprintk on AM335x has not been functional for a while [1]. > Will the latest patches from you to enable multiplatform debug-ll be sufficient > to test this out? I am trying to track down the boot issues reported and just > want to be sure of the dependencies. Yes you should check with current linux next and select the DEBUG_LL port manually. > [1] http://marc.info/?l=linux-omap&m=134642491119235&w=2 This one should no longer be needed as we now use the machine_id for board-generic.c for DT boot. > [2] https://patchwork.kernel.org/patch/1896851/ This alone won't work without multiplatform support. At least modifying the Kconfig to use the new settings for OMAP2PLUS is needed. Probably easiest to make sure it works in linux next first. Regards, Tony ^ permalink raw reply [flat|nested] 64+ messages in thread
* RE: OMAP baseline test results for v3.8-rc4 2013-01-25 16:59 ` Tony Lindgren @ 2013-01-28 12:23 ` Bedia, Vaibhav -1 siblings, 0 replies; 64+ messages in thread From: Bedia, Vaibhav @ 2013-01-28 12:23 UTC (permalink / raw) To: Tony Lindgren Cc: Mark Jackson, Menon, Nishanth, Porter, Matt, Paul Walmsley, Richard Cochran, Hiremath, Vaibhav, Peter Korsgaard, linux-omap, linux-arm-kernel, Kevin Hilman On Fri, Jan 25, 2013 at 22:29:43, Tony Lindgren wrote: > * Bedia, Vaibhav <vaibhav.bedia@ti.com> [130123 06:35]: > > Hi Tony, > > > > On Tue, Jan 22, 2013 at 23:53:32, Tony Lindgren wrote: > > [...] > > > > > > > > But I should get *something* from the kernel before it starts trying to access the rootfs ? > > > > > > Here's something Kevin fixed but did not send it out before going to > > > a vacation. Can you give it a try with earlyprintk enabled? > > > > > > Note that this does not help with no output early on, that sounds > > > like a bug configuring the DEBUG_LL port somewhere. > > > > > > > I think earlyprintk on AM335x has not been functional for a while [1]. > > Will the latest patches from you to enable multiplatform debug-ll be sufficient > > to test this out? I am trying to track down the boot issues reported and just > > want to be sure of the dependencies. > > Yes you should check with current linux next and select the DEBUG_LL > port manually. > Verified on linux-next that selecting the right UART port gives a functional early_console. (One of the rare cases where forcing a kernel panic early in the boot process makes sense ;) Regards, Vaibhav ^ permalink raw reply [flat|nested] 64+ messages in thread
* OMAP baseline test results for v3.8-rc4 @ 2013-01-28 12:23 ` Bedia, Vaibhav 0 siblings, 0 replies; 64+ messages in thread From: Bedia, Vaibhav @ 2013-01-28 12:23 UTC (permalink / raw) To: linux-arm-kernel On Fri, Jan 25, 2013 at 22:29:43, Tony Lindgren wrote: > * Bedia, Vaibhav <vaibhav.bedia@ti.com> [130123 06:35]: > > Hi Tony, > > > > On Tue, Jan 22, 2013 at 23:53:32, Tony Lindgren wrote: > > [...] > > > > > > > > But I should get *something* from the kernel before it starts trying to access the rootfs ? > > > > > > Here's something Kevin fixed but did not send it out before going to > > > a vacation. Can you give it a try with earlyprintk enabled? > > > > > > Note that this does not help with no output early on, that sounds > > > like a bug configuring the DEBUG_LL port somewhere. > > > > > > > I think earlyprintk on AM335x has not been functional for a while [1]. > > Will the latest patches from you to enable multiplatform debug-ll be sufficient > > to test this out? I am trying to track down the boot issues reported and just > > want to be sure of the dependencies. > > Yes you should check with current linux next and select the DEBUG_LL > port manually. > Verified on linux-next that selecting the right UART port gives a functional early_console. (One of the rare cases where forcing a kernel panic early in the boot process makes sense ;) Regards, Vaibhav ^ permalink raw reply [flat|nested] 64+ messages in thread
* RE: OMAP baseline test results for v3.8-rc4 2013-01-22 2:24 ` Paul Walmsley @ 2013-01-24 12:49 ` Bedia, Vaibhav -1 siblings, 0 replies; 64+ messages in thread From: Bedia, Vaibhav @ 2013-01-24 12:49 UTC (permalink / raw) To: Paul Walmsley, Porter, Matt, Richard Cochran, Menon, Nishanth, Mark Jackson, Hiremath, Vaibhav, Peter Korsgaard Cc: linux-omap\@vger.kernel.org, linux-arm-kernel\@lists.infradead.org Hi Paul, On Tue, Jan 22, 2013 at 07:54:44, Paul Walmsley wrote: > > Hi guys, > > Regarding the AM33xx test failures with appended DTBs, it would be very > helpful if especially the TI people could try reproducing the problem. > Otherwise it's going to cause problems with merging any new AM33xx > patches, since I won't be able to test them without additional work. > Plus, this is something that used to work up until d01e4afd, so something > isn't right. > > You'll need to use the bootloader that TI originally shipped with the > BeagleBones: > > U-Boot 2011.09-00009-gcf6e04d (Mar 08 2012 - 17:15:43) > > This is because many folks don't replace their bootloader. I do plan to > add a test with a recent version of u-boot, but the kernel should not be > dependent on the bootloader in any way to work correctly. If it is, then > we need to document what u-boot version the kernel started to work with. > > The Kconfig that I use is here: > > http://www.pwsan.com/omap/testlogs/test_v3.8-rc4/20130120122039/build/am33xx_only/am33xx_only > > It's possible that there's something wrong with the Kconfig. It's > basically just omap2plus_defconfig, but with all OMAP support for > non-AM33xx turned off, and with the appended DTB and ATAG compatibility > options turned on. > > Let's try to do this ASAP. That way, if it's some bootloader dependency > or bug in the kernel, some fix can be merged during the v3.8-rc series, > which is rapidly drawing to a close. > I could not track down U-Boot that you were using so I used the v2013.01 tag for U-Boot. However, using your build configs for v3.7 and v3.8-rcX I got the same observations i.e. v3.7 boots but others don't. One difference that I found was that post v3.7 the configs that you are using have CONFIG_EARLY_PRINTK set. Once I disabled that I was able to bootup v3.8-rc1/4 (didn't try rc2/3 but I suspect early_printk was the culprit there too). I checked with Santosh on this and he mentioned that for DT-only boot, which AM335x is, that's expected behavior. Can you update your AM335x-only config to disable CONFIG_EARLY_PRINTK or just skip earlyprintk option in the bootargs for now? If you still have issues booting can you update your U-Boot to v2013.01 since things seem to be working fine at this point. Regards, Vaibhav ^ permalink raw reply [flat|nested] 64+ messages in thread
* OMAP baseline test results for v3.8-rc4 @ 2013-01-24 12:49 ` Bedia, Vaibhav 0 siblings, 0 replies; 64+ messages in thread From: Bedia, Vaibhav @ 2013-01-24 12:49 UTC (permalink / raw) To: linux-arm-kernel Hi Paul, On Tue, Jan 22, 2013 at 07:54:44, Paul Walmsley wrote: > > Hi guys, > > Regarding the AM33xx test failures with appended DTBs, it would be very > helpful if especially the TI people could try reproducing the problem. > Otherwise it's going to cause problems with merging any new AM33xx > patches, since I won't be able to test them without additional work. > Plus, this is something that used to work up until d01e4afd, so something > isn't right. > > You'll need to use the bootloader that TI originally shipped with the > BeagleBones: > > U-Boot 2011.09-00009-gcf6e04d (Mar 08 2012 - 17:15:43) > > This is because many folks don't replace their bootloader. I do plan to > add a test with a recent version of u-boot, but the kernel should not be > dependent on the bootloader in any way to work correctly. If it is, then > we need to document what u-boot version the kernel started to work with. > > The Kconfig that I use is here: > > http://www.pwsan.com/omap/testlogs/test_v3.8-rc4/20130120122039/build/am33xx_only/am33xx_only > > It's possible that there's something wrong with the Kconfig. It's > basically just omap2plus_defconfig, but with all OMAP support for > non-AM33xx turned off, and with the appended DTB and ATAG compatibility > options turned on. > > Let's try to do this ASAP. That way, if it's some bootloader dependency > or bug in the kernel, some fix can be merged during the v3.8-rc series, > which is rapidly drawing to a close. > I could not track down U-Boot that you were using so I used the v2013.01 tag for U-Boot. However, using your build configs for v3.7 and v3.8-rcX I got the same observations i.e. v3.7 boots but others don't. One difference that I found was that post v3.7 the configs that you are using have CONFIG_EARLY_PRINTK set. Once I disabled that I was able to bootup v3.8-rc1/4 (didn't try rc2/3 but I suspect early_printk was the culprit there too). I checked with Santosh on this and he mentioned that for DT-only boot, which AM335x is, that's expected behavior. Can you update your AM335x-only config to disable CONFIG_EARLY_PRINTK or just skip earlyprintk option in the bootargs for now? If you still have issues booting can you update your U-Boot to v2013.01 since things seem to be working fine at this point. Regards, Vaibhav ^ permalink raw reply [flat|nested] 64+ messages in thread
* RE: OMAP baseline test results for v3.8-rc4 2013-01-24 12:49 ` Bedia, Vaibhav @ 2013-01-25 8:42 ` Paul Walmsley -1 siblings, 0 replies; 64+ messages in thread From: Paul Walmsley @ 2013-01-25 8:42 UTC (permalink / raw) To: Bedia, Vaibhav Cc: Porter, Matt, Richard Cochran, Menon, Nishanth, Mark Jackson, Hiremath, Vaibhav, Peter Korsgaard, linux-omap\\@vger.kernel.org, linux-arm-kernel\\@lists.infradead.org Hi, On Thu, 24 Jan 2013, Bedia, Vaibhav wrote: > Can you update your AM335x-only config to disable CONFIG_EARLY_PRINTK or > just skip earlyprintk option in the bootargs for now? I'll give this a try over the next few days. If EARLY_PRINTK is known to be broken for DT boots, could you please put together a Kconfig patch that prevents either EARLY_PRINTK from being selected when a DT-only board is selected, or vice-versa? - Paul ^ permalink raw reply [flat|nested] 64+ messages in thread
* OMAP baseline test results for v3.8-rc4 @ 2013-01-25 8:42 ` Paul Walmsley 0 siblings, 0 replies; 64+ messages in thread From: Paul Walmsley @ 2013-01-25 8:42 UTC (permalink / raw) To: linux-arm-kernel Hi, On Thu, 24 Jan 2013, Bedia, Vaibhav wrote: > Can you update your AM335x-only config to disable CONFIG_EARLY_PRINTK or > just skip earlyprintk option in the bootargs for now? I'll give this a try over the next few days. If EARLY_PRINTK is known to be broken for DT boots, could you please put together a Kconfig patch that prevents either EARLY_PRINTK from being selected when a DT-only board is selected, or vice-versa? - Paul ^ permalink raw reply [flat|nested] 64+ messages in thread
* RE: OMAP baseline test results for v3.8-rc4 2013-01-24 12:49 ` Bedia, Vaibhav @ 2013-02-06 22:00 ` Paul Walmsley -1 siblings, 0 replies; 64+ messages in thread From: Paul Walmsley @ 2013-02-06 22:00 UTC (permalink / raw) To: Bedia, Vaibhav Cc: Porter, Matt, Richard Cochran, Menon, Nishanth, Mark Jackson, Hiremath, Vaibhav, Peter Korsgaard, linux-omap\@vger.kernel.org, linux-arm-kernel\@lists.infradead.org Hi Vaibhav, On Thu, 24 Jan 2013, Bedia, Vaibhav wrote: > I could not track down U-Boot that you were using It's posted now at: http://www.pwsan.com/omap/bootloaders/beaglebone/u-boot/2011.09-00009-gcf6e04d__20120803171543/ Care to try it? > However, using your build configs for v3.7 and v3.8-rcX I got the same > observations i.e. v3.7 boots but others don't. > > One difference that I found was that post v3.7 the configs that you are using have > CONFIG_EARLY_PRINTK set. Once I disabled that I was able to bootup v3.8-rc1/4 > (didn't try rc2/3 but I suspect early_printk was the culprit there too). > > I checked with Santosh on this and he mentioned that for DT-only boot, which AM335x is, > that's expected behavior. > > Can you update your AM335x-only config to disable CONFIG_EARLY_PRINTK Setting CONFIG_EARLY_PRINTK=n doesn't fix the problem I'm seeing. I also tried building a v3.8-rc6 kernel with the old v3.7-rc config that was used before; no luck. > or just skip earlyprintk option in the bootargs for now? Haven't tried this one yet. > If you still have issues booting can you update your U-Boot to v2013.01 since things > seem to be working fine at this point. Let's try to identify and get rid of bootloader dependencies in the kernel. They indicate that the kernel isn't initializing something appropriately, which could cause strange problems later. - Paul ^ permalink raw reply [flat|nested] 64+ messages in thread
* OMAP baseline test results for v3.8-rc4 @ 2013-02-06 22:00 ` Paul Walmsley 0 siblings, 0 replies; 64+ messages in thread From: Paul Walmsley @ 2013-02-06 22:00 UTC (permalink / raw) To: linux-arm-kernel Hi Vaibhav, On Thu, 24 Jan 2013, Bedia, Vaibhav wrote: > I could not track down U-Boot that you were using It's posted now at: http://www.pwsan.com/omap/bootloaders/beaglebone/u-boot/2011.09-00009-gcf6e04d__20120803171543/ Care to try it? > However, using your build configs for v3.7 and v3.8-rcX I got the same > observations i.e. v3.7 boots but others don't. > > One difference that I found was that post v3.7 the configs that you are using have > CONFIG_EARLY_PRINTK set. Once I disabled that I was able to bootup v3.8-rc1/4 > (didn't try rc2/3 but I suspect early_printk was the culprit there too). > > I checked with Santosh on this and he mentioned that for DT-only boot, which AM335x is, > that's expected behavior. > > Can you update your AM335x-only config to disable CONFIG_EARLY_PRINTK Setting CONFIG_EARLY_PRINTK=n doesn't fix the problem I'm seeing. I also tried building a v3.8-rc6 kernel with the old v3.7-rc config that was used before; no luck. > or just skip earlyprintk option in the bootargs for now? Haven't tried this one yet. > If you still have issues booting can you update your U-Boot to v2013.01 since things > seem to be working fine at this point. Let's try to identify and get rid of bootloader dependencies in the kernel. They indicate that the kernel isn't initializing something appropriately, which could cause strange problems later. - Paul ^ permalink raw reply [flat|nested] 64+ messages in thread
* RE: OMAP baseline test results for v3.8-rc4 2013-02-06 22:00 ` Paul Walmsley @ 2013-02-06 22:20 ` Paul Walmsley -1 siblings, 0 replies; 64+ messages in thread From: Paul Walmsley @ 2013-02-06 22:20 UTC (permalink / raw) To: Bedia, Vaibhav Cc: Porter, Matt, Richard Cochran, Menon, Nishanth, Mark Jackson, Hiremath, Vaibhav, Peter Korsgaard, linux-omap\@vger.kernel.org, linux-arm-kernel\@lists.infradead.org On Wed, 6 Feb 2013, Paul Walmsley wrote: > Setting CONFIG_EARLY_PRINTK=n doesn't fix the problem I'm seeing. And just tried this with u-boot v2013.01 on a BeagleBoard A6a, does not fix it. > > If you still have issues booting can you update your U-Boot to v2013.01 since things > > seem to be working fine at this point. > > Let's try to identify and get rid of bootloader dependencies in the > kernel. They indicate that the kernel isn't initializing something > appropriately, which could cause strange problems later. Oh and it's worth noting that parts of u-boot v2013.01 don't work correctly on earlier BeagleBones, i.e. Ethernet booting. - Paul ^ permalink raw reply [flat|nested] 64+ messages in thread
* OMAP baseline test results for v3.8-rc4 @ 2013-02-06 22:20 ` Paul Walmsley 0 siblings, 0 replies; 64+ messages in thread From: Paul Walmsley @ 2013-02-06 22:20 UTC (permalink / raw) To: linux-arm-kernel On Wed, 6 Feb 2013, Paul Walmsley wrote: > Setting CONFIG_EARLY_PRINTK=n doesn't fix the problem I'm seeing. And just tried this with u-boot v2013.01 on a BeagleBoard A6a, does not fix it. > > If you still have issues booting can you update your U-Boot to v2013.01 since things > > seem to be working fine at this point. > > Let's try to identify and get rid of bootloader dependencies in the > kernel. They indicate that the kernel isn't initializing something > appropriately, which could cause strange problems later. Oh and it's worth noting that parts of u-boot v2013.01 don't work correctly on earlier BeagleBones, i.e. Ethernet booting. - Paul ^ permalink raw reply [flat|nested] 64+ messages in thread
* RE: OMAP baseline test results for v3.8-rc4 2013-02-06 22:00 ` Paul Walmsley @ 2013-02-07 14:42 ` Bedia, Vaibhav -1 siblings, 0 replies; 64+ messages in thread From: Bedia, Vaibhav @ 2013-02-07 14:42 UTC (permalink / raw) To: Paul Walmsley Cc: Porter, Matt, Richard Cochran, Menon, Nishanth, Mark Jackson, Hiremath, Vaibhav, Peter Korsgaard, linux-omap\@vger.kernel.org, linux-arm-kernel\@lists.infradead.org On Thu, Feb 07, 2013 at 03:30:56, Paul Walmsley wrote: > Hi Vaibhav, > > On Thu, 24 Jan 2013, Bedia, Vaibhav wrote: > > > I could not track down U-Boot that you were using > > It's posted now at: > > http://www.pwsan.com/omap/bootloaders/beaglebone/u-boot/2011.09-00009-gcf6e04d__20120803171543/ > > Care to try it? > Thanks. Unfortunately, I'll be able to do this early next week only. > > However, using your build configs for v3.7 and v3.8-rcX I got the same > > observations i.e. v3.7 boots but others don't. > > > > One difference that I found was that post v3.7 the configs that you are using have > > CONFIG_EARLY_PRINTK set. Once I disabled that I was able to bootup v3.8-rc1/4 > > (didn't try rc2/3 but I suspect early_printk was the culprit there too). > > > > I checked with Santosh on this and he mentioned that for DT-only boot, which AM335x is, > > that's expected behavior. > > > > Can you update your AM335x-only config to disable CONFIG_EARLY_PRINTK > > Setting CONFIG_EARLY_PRINTK=n doesn't fix the problem I'm seeing. > > I also tried building a v3.8-rc6 kernel with the old v3.7-rc config that > was used before; no luck. > Ah, I was really hoping you wouldn't say that ;) > > or just skip earlyprintk option in the bootargs for now? > > Haven't tried this one yet. > > > If you still have issues booting can you update your U-Boot to v2013.01 since things > > seem to be working fine at this point. > > Let's try to identify and get rid of bootloader dependencies in the > kernel. They indicate that the kernel isn't initializing something > appropriately, which could cause strange problems later. > Agreed. It could also be that the boot-loader is doing something crazy but we do need to know what's the dependency. Regards, Vaibhav ^ permalink raw reply [flat|nested] 64+ messages in thread
* OMAP baseline test results for v3.8-rc4 @ 2013-02-07 14:42 ` Bedia, Vaibhav 0 siblings, 0 replies; 64+ messages in thread From: Bedia, Vaibhav @ 2013-02-07 14:42 UTC (permalink / raw) To: linux-arm-kernel On Thu, Feb 07, 2013 at 03:30:56, Paul Walmsley wrote: > Hi Vaibhav, > > On Thu, 24 Jan 2013, Bedia, Vaibhav wrote: > > > I could not track down U-Boot that you were using > > It's posted now at: > > http://www.pwsan.com/omap/bootloaders/beaglebone/u-boot/2011.09-00009-gcf6e04d__20120803171543/ > > Care to try it? > Thanks. Unfortunately, I'll be able to do this early next week only. > > However, using your build configs for v3.7 and v3.8-rcX I got the same > > observations i.e. v3.7 boots but others don't. > > > > One difference that I found was that post v3.7 the configs that you are using have > > CONFIG_EARLY_PRINTK set. Once I disabled that I was able to bootup v3.8-rc1/4 > > (didn't try rc2/3 but I suspect early_printk was the culprit there too). > > > > I checked with Santosh on this and he mentioned that for DT-only boot, which AM335x is, > > that's expected behavior. > > > > Can you update your AM335x-only config to disable CONFIG_EARLY_PRINTK > > Setting CONFIG_EARLY_PRINTK=n doesn't fix the problem I'm seeing. > > I also tried building a v3.8-rc6 kernel with the old v3.7-rc config that > was used before; no luck. > Ah, I was really hoping you wouldn't say that ;) > > or just skip earlyprintk option in the bootargs for now? > > Haven't tried this one yet. > > > If you still have issues booting can you update your U-Boot to v2013.01 since things > > seem to be working fine at this point. > > Let's try to identify and get rid of bootloader dependencies in the > kernel. They indicate that the kernel isn't initializing something > appropriately, which could cause strange problems later. > Agreed. It could also be that the boot-loader is doing something crazy but we do need to know what's the dependency. Regards, Vaibhav ^ permalink raw reply [flat|nested] 64+ messages in thread
[parent not found: <49ca66a84bb245ca9cfe4fd044c4d6f6@DFLE72.ent.ti.com>]
* Re: OMAP baseline test results for v3.8-rc4 [not found] ` <49ca66a84bb245ca9cfe4fd044c4d6f6@DFLE72.ent.ti.com> @ 2013-01-21 17:10 ` Matt Porter 0 siblings, 0 replies; 64+ messages in thread From: Matt Porter @ 2013-01-21 17:10 UTC (permalink / raw) To: Mark Jackson Cc: Hiremath, Vaibhav, Paul Walmsley, linux-omap, linux-arm-kernel On Mon, Jan 21, 2013 at 04:32:13PM +0000, Mark Jackson wrote: > Vaibhav / Matt > > On 20/01/13 21:38, Paul Walmsley wrote: > > > > Here are some basic OMAP test results for Linux v3.8-rc4. > > Logs and other details at: > > > > http://www.pwsan.com/omap/testlogs/test_v3.8-rc4/20130120122039/ > > <snip> > > > Failing tests: needing investigation > > ------------------------------------ > > > > Boot tests: > > > > * am335xbone: hangs after "Starting kernel" > > - Cause unknown > > - http://www.mail-archive.com/linux-omap@vger.kernel.org/msg82297.html > > <snip> > > > Failing tests: needing local investigation (may be due to testbed issues) > > ------------------------------------------------------------------------- > > > > Boot tests: > > > > * AM335x Beaglebone: omap2plus_defconfig kernels don't boot > > - May be fixed now, pending retest: > > - http://marc.info/?l=linux-omap&m=135082257727502&w=2 > > - Not yet part of the automated test suite > > - Nishanth Menon & Vaibhav Hiremath report that it works for them > > * May be due to an old U-boot with FDT support problems used here? > > Pending local investigation and re-test > > Does anyone know when the BeagleBone support is going to be fixed in mainline ? Hi Mark, I'm not sure what needs to be fixed. The only thing my edma dmaengine series adds is new features (specifically, mmc and spi dma support). I would suspect some boot problem specific to Paul's configuration if it's hanging. I just booted current mainline with an omap2plus_defconfig build on my bone a5 and it came up fine. > I've just tried the latest linux-next git, and no joy. > > However, Matt's edma-dmaengine-am33xx-v5 branch on github seems to be working:- > > > Uncompressing Linux... done, booting the kernel. > [ 0.000000] Booting Linux on physical CPU 0x0 > [ 0.000000] Linux version 3.8.0-rc3-61978-g108da76-dirty (mpfj@mpfj-nanobone) (gcc version 4.5.4 > (Buildroot 2012.11-git-00497-ge48bf89) ) #7 SMP Mon Jan 21 15:52:14 GMT 2013 > [ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d > [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache > [ 0.000000] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone > > Are we just waiting for Matt's DMA stuff to be accepted ? For the features I listed above, yes. Also Mark Greer's crypto patches for AM33xx depend on that series as does a patch series (not ready yet) that I have to support the Bone audio capes. There's a dependency I'm working through in a separate thread on lkml since the dmaengine edma series requires the proposed dma_get_channel_caps() api...still discussing that implementation. -Matt ^ permalink raw reply [flat|nested] 64+ messages in thread
* OMAP baseline test results for v3.8-rc4 @ 2013-01-21 17:10 ` Matt Porter 0 siblings, 0 replies; 64+ messages in thread From: Matt Porter @ 2013-01-21 17:10 UTC (permalink / raw) To: linux-arm-kernel On Mon, Jan 21, 2013 at 04:32:13PM +0000, Mark Jackson wrote: > Vaibhav / Matt > > On 20/01/13 21:38, Paul Walmsley wrote: > > > > Here are some basic OMAP test results for Linux v3.8-rc4. > > Logs and other details at: > > > > http://www.pwsan.com/omap/testlogs/test_v3.8-rc4/20130120122039/ > > <snip> > > > Failing tests: needing investigation > > ------------------------------------ > > > > Boot tests: > > > > * am335xbone: hangs after "Starting kernel" > > - Cause unknown > > - http://www.mail-archive.com/linux-omap at vger.kernel.org/msg82297.html > > <snip> > > > Failing tests: needing local investigation (may be due to testbed issues) > > ------------------------------------------------------------------------- > > > > Boot tests: > > > > * AM335x Beaglebone: omap2plus_defconfig kernels don't boot > > - May be fixed now, pending retest: > > - http://marc.info/?l=linux-omap&m=135082257727502&w=2 > > - Not yet part of the automated test suite > > - Nishanth Menon & Vaibhav Hiremath report that it works for them > > * May be due to an old U-boot with FDT support problems used here? > > Pending local investigation and re-test > > Does anyone know when the BeagleBone support is going to be fixed in mainline ? Hi Mark, I'm not sure what needs to be fixed. The only thing my edma dmaengine series adds is new features (specifically, mmc and spi dma support). I would suspect some boot problem specific to Paul's configuration if it's hanging. I just booted current mainline with an omap2plus_defconfig build on my bone a5 and it came up fine. > I've just tried the latest linux-next git, and no joy. > > However, Matt's edma-dmaengine-am33xx-v5 branch on github seems to be working:- > > > Uncompressing Linux... done, booting the kernel. > [ 0.000000] Booting Linux on physical CPU 0x0 > [ 0.000000] Linux version 3.8.0-rc3-61978-g108da76-dirty (mpfj at mpfj-nanobone) (gcc version 4.5.4 > (Buildroot 2012.11-git-00497-ge48bf89) ) #7 SMP Mon Jan 21 15:52:14 GMT 2013 > [ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d > [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache > [ 0.000000] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone > > Are we just waiting for Matt's DMA stuff to be accepted ? For the features I listed above, yes. Also Mark Greer's crypto patches for AM33xx depend on that series as does a patch series (not ready yet) that I have to support the Bone audio capes. There's a dependency I'm working through in a separate thread on lkml since the dmaengine edma series requires the proposed dma_get_channel_caps() api...still discussing that implementation. -Matt ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: OMAP baseline test results for v3.8-rc4 2013-01-21 17:10 ` Matt Porter @ 2013-01-21 20:36 ` Peter Korsgaard -1 siblings, 0 replies; 64+ messages in thread From: Peter Korsgaard @ 2013-01-21 20:36 UTC (permalink / raw) To: Matt Porter Cc: Mark Jackson, Paul Walmsley, linux-omap, linux-arm-kernel, Hiremath, Vaibhav >>>>> "Matt" == Matt Porter <mporter@ti.com> writes: Matt> On Mon, Jan 21, 2013 at 04:32:13PM +0000, Mark Jackson wrote: >> Does anyone know when the BeagleBone support is going to be fixed in >> mainline ? Matt> Hi Mark, Matt> I'm not sure what needs to be fixed. The only thing my edma dmaengine Matt> series adds is new features (specifically, mmc and spi dma support). Matt> I would suspect some boot problem specific to Paul's configuration Matt> if it's hanging. I just booted current mainline with an Matt> omap2plus_defconfig build on my bone a5 and it came up fine. It also works here. I have noticed issues with nfs boot and recent mainline when powered from the USB cable though. I suspect we're getting close to the power limit. -- Bye, Peter Korsgaard ^ permalink raw reply [flat|nested] 64+ messages in thread
* OMAP baseline test results for v3.8-rc4 @ 2013-01-21 20:36 ` Peter Korsgaard 0 siblings, 0 replies; 64+ messages in thread From: Peter Korsgaard @ 2013-01-21 20:36 UTC (permalink / raw) To: linux-arm-kernel >>>>> "Matt" == Matt Porter <mporter@ti.com> writes: Matt> On Mon, Jan 21, 2013 at 04:32:13PM +0000, Mark Jackson wrote: >> Does anyone know when the BeagleBone support is going to be fixed in >> mainline ? Matt> Hi Mark, Matt> I'm not sure what needs to be fixed. The only thing my edma dmaengine Matt> series adds is new features (specifically, mmc and spi dma support). Matt> I would suspect some boot problem specific to Paul's configuration Matt> if it's hanging. I just booted current mainline with an Matt> omap2plus_defconfig build on my bone a5 and it came up fine. It also works here. I have noticed issues with nfs boot and recent mainline when powered from the USB cable though. I suspect we're getting close to the power limit. -- Bye, Peter Korsgaard ^ permalink raw reply [flat|nested] 64+ messages in thread
end of thread, other threads:[~2013-02-07 14:42 UTC | newest] Thread overview: 64+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-01-20 21:38 OMAP baseline test results for v3.8-rc4 Paul Walmsley 2013-01-20 21:38 ` Paul Walmsley 2013-01-21 16:32 ` Mark Jackson 2013-01-21 16:32 ` Mark Jackson 2013-01-21 16:45 ` Nishanth Menon 2013-01-21 16:45 ` Nishanth Menon 2013-01-21 18:20 ` Richard Cochran 2013-01-21 18:20 ` Richard Cochran [not found] ` <f36acfaf128c4844b8f696ea4440e253@DLEE74.ent.ti.com> 2013-01-21 18:24 ` Matt Porter 2013-01-21 18:24 ` Matt Porter 2013-01-21 18:34 ` Richard Cochran 2013-01-21 18:34 ` Richard Cochran 2013-01-21 20:36 ` Peter Korsgaard 2013-01-21 20:36 ` Peter Korsgaard 2013-01-22 2:24 ` Paul Walmsley 2013-01-22 2:24 ` Paul Walmsley 2013-01-22 8:55 ` Peter Korsgaard 2013-01-22 8:55 ` Peter Korsgaard 2013-01-22 13:02 ` Bedia, Vaibhav 2013-01-22 13:02 ` Bedia, Vaibhav 2013-01-22 9:24 ` Jan Lübbe 2013-01-22 9:24 ` Jan Lübbe 2013-01-22 9:40 ` Peter Korsgaard 2013-01-22 9:40 ` Peter Korsgaard 2013-01-22 9:52 ` Russell King - ARM Linux 2013-01-22 9:52 ` Russell King - ARM Linux 2013-01-22 12:19 ` Peter Korsgaard 2013-01-22 12:19 ` Peter Korsgaard 2013-01-25 8:23 ` Paul Walmsley 2013-01-25 8:23 ` Paul Walmsley 2013-01-22 10:15 ` Mark Jackson 2013-01-22 10:15 ` Mark Jackson 2013-01-22 12:21 ` Peter Korsgaard 2013-01-22 12:21 ` Peter Korsgaard 2013-01-22 13:45 ` Mark Jackson 2013-01-22 13:45 ` Mark Jackson 2013-01-22 13:32 ` Bedia, Vaibhav 2013-01-22 13:32 ` Bedia, Vaibhav 2013-01-22 13:39 ` Mark Jackson 2013-01-22 13:39 ` Mark Jackson 2013-01-22 18:23 ` Tony Lindgren 2013-01-22 18:23 ` Tony Lindgren 2013-01-23 10:18 ` Mark Jackson 2013-01-23 10:18 ` Mark Jackson 2013-01-23 14:32 ` Bedia, Vaibhav 2013-01-23 14:32 ` Bedia, Vaibhav 2013-01-25 16:59 ` Tony Lindgren 2013-01-25 16:59 ` Tony Lindgren 2013-01-28 12:23 ` Bedia, Vaibhav 2013-01-28 12:23 ` Bedia, Vaibhav 2013-01-24 12:49 ` Bedia, Vaibhav 2013-01-24 12:49 ` Bedia, Vaibhav 2013-01-25 8:42 ` Paul Walmsley 2013-01-25 8:42 ` Paul Walmsley 2013-02-06 22:00 ` Paul Walmsley 2013-02-06 22:00 ` Paul Walmsley 2013-02-06 22:20 ` Paul Walmsley 2013-02-06 22:20 ` Paul Walmsley 2013-02-07 14:42 ` Bedia, Vaibhav 2013-02-07 14:42 ` Bedia, Vaibhav [not found] ` <49ca66a84bb245ca9cfe4fd044c4d6f6@DFLE72.ent.ti.com> 2013-01-21 17:10 ` Matt Porter 2013-01-21 17:10 ` Matt Porter 2013-01-21 20:36 ` Peter Korsgaard 2013-01-21 20:36 ` Peter Korsgaard
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.