OMAP baseline test results for v3.8-rc4

OMAP baseline test results for v3.8-rc4

[Paul Walmsley]

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

OMAP baseline test results for v3.8-rc4

[Paul Walmsley]

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

Re: OMAP baseline test results for v3.8-rc4

[Mark Jackson]

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.

OMAP baseline test results for v3.8-rc4

[Mark Jackson]

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.

Re: OMAP baseline test results for v3.8-rc4

[Nishanth Menon]

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

OMAP baseline test results for v3.8-rc4

[Nishanth Menon]

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

Re: OMAP baseline test results for v3.8-rc4

[Richard Cochran]

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

OMAP baseline test results for v3.8-rc4

[Richard Cochran]

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

Re: OMAP baseline test results for v3.8-rc4

[Matt Porter]

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

OMAP baseline test results for v3.8-rc4

[Matt Porter]

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

Re: OMAP baseline test results for v3.8-rc4

[Richard Cochran]

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

OMAP baseline test results for v3.8-rc4

[Richard Cochran]

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

Re: OMAP baseline test results for v3.8-rc4

[Peter Korsgaard]

>>>>> "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

OMAP baseline test results for v3.8-rc4

[Peter Korsgaard]

>>>>> "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

Re: OMAP baseline test results for v3.8-rc4

[Paul Walmsley]

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

OMAP baseline test results for v3.8-rc4

[Paul Walmsley]

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

Re: OMAP baseline test results for v3.8-rc4

[Peter Korsgaard]

>>>>> "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

OMAP baseline test results for v3.8-rc4

[Peter Korsgaard]

>>>>> "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

RE: OMAP baseline test results for v3.8-rc4

[Bedia, Vaibhav]

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

OMAP baseline test results for v3.8-rc4

[Bedia, Vaibhav]

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

Re: OMAP baseline test results for v3.8-rc4

[Jan Lübbe]

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 |

OMAP baseline test results for v3.8-rc4

[Jan Lübbe]

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 |

Re: OMAP baseline test results for v3.8-rc4

[Peter Korsgaard]

>>>>> "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

OMAP baseline test results for v3.8-rc4

[Peter Korsgaard]

>>>>> "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

Re: OMAP baseline test results for v3.8-rc4

[Russell King - ARM Linux]

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

OMAP baseline test results for v3.8-rc4

[Russell King - ARM Linux]

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.

Re: OMAP baseline test results for v3.8-rc4

[Peter Korsgaard]

>>>>> "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

OMAP baseline test results for v3.8-rc4

[Peter Korsgaard]

>>>>> "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

Re: OMAP baseline test results for v3.8-rc4

[Paul Walmsley]

[-- 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

OMAP baseline test results for v3.8-rc4

[Paul Walmsley]

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

Re: OMAP baseline test results for v3.8-rc4

[Mark Jackson]

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

OMAP baseline test results for v3.8-rc4

[Mark Jackson]

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 ...

Re: OMAP baseline test results for v3.8-rc4

[Peter Korsgaard]

>>>>> "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

OMAP baseline test results for v3.8-rc4

[Peter Korsgaard]

>>>>> "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

Re: OMAP baseline test results for v3.8-rc4

[Mark Jackson]

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.

OMAP baseline test results for v3.8-rc4

[Mark Jackson]

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.

RE: OMAP baseline test results for v3.8-rc4

[Bedia, Vaibhav]

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

OMAP baseline test results for v3.8-rc4

[Bedia, Vaibhav]

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

Re: OMAP baseline test results for v3.8-rc4

[Mark Jackson]

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.

OMAP baseline test results for v3.8-rc4

[Mark Jackson]

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.

Re: OMAP baseline test results for v3.8-rc4

[Tony Lindgren]

* 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);

OMAP baseline test results for v3.8-rc4

[Tony Lindgren]

* 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);

Re: OMAP baseline test results for v3.8-rc4

[Mark Jackson]

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.

OMAP baseline test results for v3.8-rc4

[Mark Jackson]

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.

RE: OMAP baseline test results for v3.8-rc4

[Bedia, Vaibhav]

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

OMAP baseline test results for v3.8-rc4

[Bedia, Vaibhav]

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

Re: OMAP baseline test results for v3.8-rc4

[Tony Lindgren]

* 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

OMAP baseline test results for v3.8-rc4

[Tony Lindgren]

* 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

RE: OMAP baseline test results for v3.8-rc4

[Bedia, Vaibhav]

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

OMAP baseline test results for v3.8-rc4

[Bedia, Vaibhav]

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

RE: OMAP baseline test results for v3.8-rc4

[Bedia, Vaibhav]

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

OMAP baseline test results for v3.8-rc4

[Bedia, Vaibhav]

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

RE: OMAP baseline test results for v3.8-rc4

[Paul Walmsley]

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

OMAP baseline test results for v3.8-rc4

[Paul Walmsley]

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

RE: OMAP baseline test results for v3.8-rc4

[Paul Walmsley]

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

OMAP baseline test results for v3.8-rc4

[Paul Walmsley]

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

RE: OMAP baseline test results for v3.8-rc4

[Paul Walmsley]

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

OMAP baseline test results for v3.8-rc4

[Paul Walmsley]

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

RE: OMAP baseline test results for v3.8-rc4

[Bedia, Vaibhav]

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

OMAP baseline test results for v3.8-rc4

[Bedia, Vaibhav]

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

Re: OMAP baseline test results for v3.8-rc4

[Matt Porter]

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

OMAP baseline test results for v3.8-rc4

[Matt Porter]

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

Re: OMAP baseline test results for v3.8-rc4

[Peter Korsgaard]

>>>>> "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

OMAP baseline test results for v3.8-rc4

[Peter Korsgaard]

>>>>> "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