OMAP baseline test results for v3.7-rc2

OMAP baseline test results for v3.7-rc2

[Paul Walmsley]

Here are some basic OMAP test results for Linux v3.7-rc2.
Logs and other details at:

    http://www.pwsan.com/omap/testlogs/test_v3.7-rc2/20121020134755/


Passing tests
-------------

Boot to userspace: 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm,
                   4430es2panda, 5912osk, am335xbone

PM ret/off, suspend + dynamic idle: (none)


Failing tests: fixed by posted patches
--------------------------------------

Boot tests:

* 2430sdp: vfp_reload_hw oops during MMC initialization
  - Kernel attempts to save FP registers that don't exist; fix posted:
    - http://www.spinics.net/lists/arm-kernel/msg200646.html

* 2420n800: boot hangs during UART initialization
  - http://lkml.org/lkml/2012/9/11/454
  - Apparently fixed by http://marc.info/?l=linux-omap&m=135068547918479&w=2

* AM335x Beaglebone: omap2plus_defconfig kernels don't boot
  - due to a GPMC bug
  - Apparently fixed by http://www.spinics.net/lists/arm-kernel/msg200787.html

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

* 4430es2panda: omap_hwmod: mcpdm: cannot be enabled for reset (3)
  - clock source is from an external I2C-controlled source
  - must skip reset until the switchover to hwmod late init 
  - http://www.spinics.net/lists/arm-kernel/msg178138.html


Failing tests: needing investigation
------------------------------------

Boot tests:

* 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

* 3517EVM & CM-T3517: boot hangs with NFS root
  - Likely some Kconfig, board file, and PM issues with EMAC

* CM-T3517: boot hangs with MMC boot
  - Due to missing MMC setup in board file

* 4460pandaes: boot fails early
  - Appears to be timer-related

* 3530ES3 Beagle: I2C timeouts during userspace init
  - Intermittent, appears on 5 out of 6 boots here
  - Aaro Koskinen observes this also on N900
  - Appears to be caused by commit 3db11feffc1ad2ab9dea27789e6b5b3032827adc
    - http://marc.info/?l=linux-arm-kernel&m=135071372426971&w=2

PM tests:

* 3530es3beagle, 37xxevm, 3730beaglexm: I2C fails during resume from suspend
  - Causes MMC to become unusable since regulators are not reenabled
  - Can be worked around by reverting the I2C driver conversion to
    threaded IRQs:
    - http://marc.info/?l=linux-i2c&m=135026587102887&w=2
  - Appears to be due to either an accounting or clocksource problem;
    under discussion:
    - http://marc.info/?l=linux-arm-kernel&m=135042360725821&w=2
    - http://marc.info/?l=linux-arm-kernel&m=135066462211056&w=2

* 3530es3beagle: hangs during off-mode dynamic idle test
  - Appears to be caused by commit 6c31b2150ff96755d24e0ab6d6fea08a7bf5c44c:
    - http://marc.info/?l=linux-omap&m=135075364705188&w=2

* 37xx EVM: CORE not entering dynamic off-idle
  - Cause unknown; dynamic retention-idle seems to work; system suspend to 
    off works

* 3730 Beagle XM: does not serial wake from off-idle suspend when console
  UART doesn't clock gate ("debug ignore_loglevel")
  - Not shown in the current test logs; cause unknown

* 3730 Beagle XM: OPPs do not initialize
  - Several "find_device_opp: Invalid parameters" messages appear on boot; 
    related warnings follow
  - Appears to be caused by commit 24d7b40a60cf19008334bcbcbd98da374d4d9c64
    - http://marc.info/?l=linux-omap&m=135071425527076&w=2

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



- Paul

OMAP baseline test results for v3.7-rc2

[Paul Walmsley]

Here are some basic OMAP test results for Linux v3.7-rc2.
Logs and other details at:

    http://www.pwsan.com/omap/testlogs/test_v3.7-rc2/20121020134755/


Passing tests
-------------

Boot to userspace: 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm,
                   4430es2panda, 5912osk, am335xbone

PM ret/off, suspend + dynamic idle: (none)


Failing tests: fixed by posted patches
--------------------------------------

Boot tests:

* 2430sdp: vfp_reload_hw oops during MMC initialization
  - Kernel attempts to save FP registers that don't exist; fix posted:
    - http://www.spinics.net/lists/arm-kernel/msg200646.html

* 2420n800: boot hangs during UART initialization
  - http://lkml.org/lkml/2012/9/11/454
  - Apparently fixed by http://marc.info/?l=linux-omap&m=135068547918479&w=2

* AM335x Beaglebone: omap2plus_defconfig kernels don't boot
  - due to a GPMC bug
  - Apparently fixed by http://www.spinics.net/lists/arm-kernel/msg200787.html

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

* 4430es2panda: omap_hwmod: mcpdm: cannot be enabled for reset (3)
  - clock source is from an external I2C-controlled source
  - must skip reset until the switchover to hwmod late init 
  - http://www.spinics.net/lists/arm-kernel/msg178138.html


Failing tests: needing investigation
------------------------------------

Boot tests:

* 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

* 3517EVM & CM-T3517: boot hangs with NFS root
  - Likely some Kconfig, board file, and PM issues with EMAC

* CM-T3517: boot hangs with MMC boot
  - Due to missing MMC setup in board file

* 4460pandaes: boot fails early
  - Appears to be timer-related

* 3530ES3 Beagle: I2C timeouts during userspace init
  - Intermittent, appears on 5 out of 6 boots here
  - Aaro Koskinen observes this also on N900
  - Appears to be caused by commit 3db11feffc1ad2ab9dea27789e6b5b3032827adc
    - http://marc.info/?l=linux-arm-kernel&m=135071372426971&w=2

PM tests:

* 3530es3beagle, 37xxevm, 3730beaglexm: I2C fails during resume from suspend
  - Causes MMC to become unusable since regulators are not reenabled
  - Can be worked around by reverting the I2C driver conversion to
    threaded IRQs:
    - http://marc.info/?l=linux-i2c&m=135026587102887&w=2
  - Appears to be due to either an accounting or clocksource problem;
    under discussion:
    - http://marc.info/?l=linux-arm-kernel&m=135042360725821&w=2
    - http://marc.info/?l=linux-arm-kernel&m=135066462211056&w=2

* 3530es3beagle: hangs during off-mode dynamic idle test
  - Appears to be caused by commit 6c31b2150ff96755d24e0ab6d6fea08a7bf5c44c:
    - http://marc.info/?l=linux-omap&m=135075364705188&w=2

* 37xx EVM: CORE not entering dynamic off-idle
  - Cause unknown; dynamic retention-idle seems to work; system suspend to 
    off works

* 3730 Beagle XM: does not serial wake from off-idle suspend when console
  UART doesn't clock gate ("debug ignore_loglevel")
  - Not shown in the current test logs; cause unknown

* 3730 Beagle XM: OPPs do not initialize
  - Several "find_device_opp: Invalid parameters" messages appear on boot; 
    related warnings follow
  - Appears to be caused by commit 24d7b40a60cf19008334bcbcbd98da374d4d9c64
    - http://marc.info/?l=linux-omap&m=135071425527076&w=2

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



- Paul

Re: OMAP baseline test results for v3.7-rc2

[Paul Walmsley]

On Sat, 20 Oct 2012, Paul Walmsley wrote:

> Here are some basic OMAP test results for Linux v3.7-rc2.
> Logs and other details at:
> 
>     http://www.pwsan.com/omap/testlogs/test_v3.7-rc2/20121020134755/

...

> Failing tests: needing investigation
> ------------------------------------
> 
> PM tests:
> 
> * 37xx EVM: CORE not entering dynamic off-idle
>   - Cause unknown; dynamic retention-idle seems to work; system suspend to 
>     off works

Just confirmed that this longstanding bug affects both MMC root and NFS 
root.


- Paul

OMAP baseline test results for v3.7-rc2

[Paul Walmsley]

On Sat, 20 Oct 2012, Paul Walmsley wrote:

> Here are some basic OMAP test results for Linux v3.7-rc2.
> Logs and other details at:
> 
>     http://www.pwsan.com/omap/testlogs/test_v3.7-rc2/20121020134755/

...

> Failing tests: needing investigation
> ------------------------------------
> 
> PM tests:
> 
> * 37xx EVM: CORE not entering dynamic off-idle
>   - Cause unknown; dynamic retention-idle seems to work; system suspend to 
>     off works

Just confirmed that this longstanding bug affects both MMC root and NFS 
root.


- Paul

Re: OMAP baseline test results for v3.7-rc2

[Jon Hunter]

Hi Paul,

On 10/20/2012 04:26 PM, Paul Walmsley wrote:

...

> 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

I am not seeing this on my omap4430 panda. I have an OMAP4430 ES2.3 and
I am using u-boot release 2012.10. What do you have?

Cheers
Jon

OMAP baseline test results for v3.7-rc2

[Jon Hunter]

Hi Paul,

On 10/20/2012 04:26 PM, Paul Walmsley wrote:

...

> 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

I am not seeing this on my omap4430 panda. I have an OMAP4430 ES2.3 and
I am using u-boot release 2012.10. What do you have?

Cheers
Jon

Re: OMAP baseline test results for v3.7-rc2

[Jon Hunter]

Hi Paul,

On 10/20/2012 04:26 PM, Paul Walmsley wrote:
> 
> Here are some basic OMAP test results for Linux v3.7-rc2.
> Logs and other details at:
> 
>     http://www.pwsan.com/omap/testlogs/test_v3.7-rc2/20121020134755/
> 
> 
> Passing tests
> -------------
> 
> Boot to userspace: 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm,
>                    4430es2panda, 5912osk, am335xbone
> 
> PM ret/off, suspend + dynamic idle: (none)
> 
> 
> Failing tests: fixed by posted patches
> --------------------------------------
> 
> Boot tests:
> 
> * 2430sdp: vfp_reload_hw oops during MMC initialization
>   - Kernel attempts to save FP registers that don't exist; fix posted:
>     - http://www.spinics.net/lists/arm-kernel/msg200646.html
> 
> * 2420n800: boot hangs during UART initialization
>   - http://lkml.org/lkml/2012/9/11/454
>   - Apparently fixed by http://marc.info/?l=linux-omap&m=135068547918479&w=2
> 
> * AM335x Beaglebone: omap2plus_defconfig kernels don't boot
>   - due to a GPMC bug
>   - Apparently fixed by http://www.spinics.net/lists/arm-kernel/msg200787.html

This is now addressed and I have verified it is booting on v3.7-rc2. The
following patch address this boot problem ...

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8119024ef7363591fd958ec89ebfaee7c18209e3

> 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
> 
> * 4430es2panda: omap_hwmod: mcpdm: cannot be enabled for reset (3)
>   - clock source is from an external I2C-controlled source
>   - must skip reset until the switchover to hwmod late init 
>   - http://www.spinics.net/lists/arm-kernel/msg178138.html
> 
> 
> Failing tests: needing investigation
> ------------------------------------
> 
> Boot tests:
> 
> * 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
> 
> * 3517EVM & CM-T3517: boot hangs with NFS root
>   - Likely some Kconfig, board file, and PM issues with EMAC
> 
> * CM-T3517: boot hangs with MMC boot
>   - Due to missing MMC setup in board file
> 
> * 4460pandaes: boot fails early
>   - Appears to be timer-related

I tried v3.7-rc2 on my pandaES and it is booting fine for me.

I have an OMAP4460 ES1.1 and u-boot release 2012.10.

I don't wish to create more work for you, but it could be good to add
silicon revision, u-boot release (if applicable) and toolchain used for
any failures.

Cheers
Jon

OMAP baseline test results for v3.7-rc2

[Jon Hunter]

Hi Paul,

On 10/20/2012 04:26 PM, Paul Walmsley wrote:
> 
> Here are some basic OMAP test results for Linux v3.7-rc2.
> Logs and other details at:
> 
>     http://www.pwsan.com/omap/testlogs/test_v3.7-rc2/20121020134755/
> 
> 
> Passing tests
> -------------
> 
> Boot to userspace: 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm,
>                    4430es2panda, 5912osk, am335xbone
> 
> PM ret/off, suspend + dynamic idle: (none)
> 
> 
> Failing tests: fixed by posted patches
> --------------------------------------
> 
> Boot tests:
> 
> * 2430sdp: vfp_reload_hw oops during MMC initialization
>   - Kernel attempts to save FP registers that don't exist; fix posted:
>     - http://www.spinics.net/lists/arm-kernel/msg200646.html
> 
> * 2420n800: boot hangs during UART initialization
>   - http://lkml.org/lkml/2012/9/11/454
>   - Apparently fixed by http://marc.info/?l=linux-omap&m=135068547918479&w=2
> 
> * AM335x Beaglebone: omap2plus_defconfig kernels don't boot
>   - due to a GPMC bug
>   - Apparently fixed by http://www.spinics.net/lists/arm-kernel/msg200787.html

This is now addressed and I have verified it is booting on v3.7-rc2. The
following patch address this boot problem ...

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8119024ef7363591fd958ec89ebfaee7c18209e3

> 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
> 
> * 4430es2panda: omap_hwmod: mcpdm: cannot be enabled for reset (3)
>   - clock source is from an external I2C-controlled source
>   - must skip reset until the switchover to hwmod late init 
>   - http://www.spinics.net/lists/arm-kernel/msg178138.html
> 
> 
> Failing tests: needing investigation
> ------------------------------------
> 
> Boot tests:
> 
> * 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
> 
> * 3517EVM & CM-T3517: boot hangs with NFS root
>   - Likely some Kconfig, board file, and PM issues with EMAC
> 
> * CM-T3517: boot hangs with MMC boot
>   - Due to missing MMC setup in board file
> 
> * 4460pandaes: boot fails early
>   - Appears to be timer-related

I tried v3.7-rc2 on my pandaES and it is booting fine for me.

I have an OMAP4460 ES1.1 and u-boot release 2012.10.

I don't wish to create more work for you, but it could be good to add
silicon revision, u-boot release (if applicable) and toolchain used for
any failures.

Cheers
Jon

Re: OMAP baseline test results for v3.7-rc2

[Tony Lindgren]

* Jon Hunter <jon-hunter@ti.com> [121022 09:30]:
> On 10/20/2012 04:26 PM, Paul Walmsley wrote:
> > 
> > * 2430sdp: vfp_reload_hw oops during MMC initialization
> >   - Kernel attempts to save FP registers that don't exist; fix posted:
> >     - http://www.spinics.net/lists/arm-kernel/msg200646.html

Has that one been posted to RMK's patch system?

> > * AM335x Beaglebone: omap2plus_defconfig kernels don't boot
> >   - due to a GPMC bug
> >   - Apparently fixed by http://www.spinics.net/lists/arm-kernel/msg200787.html
> 
> This is now addressed and I have verified it is booting on v3.7-rc2. The
> following patch address this boot problem ...
> 
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8119024ef7363591fd958ec89ebfaee7c18209e3

That's in v3.7-rc2 already, is there some other problem too?

Regards,

Tony

OMAP baseline test results for v3.7-rc2

[Tony Lindgren]

* Jon Hunter <jon-hunter@ti.com> [121022 09:30]:
> On 10/20/2012 04:26 PM, Paul Walmsley wrote:
> > 
> > * 2430sdp: vfp_reload_hw oops during MMC initialization
> >   - Kernel attempts to save FP registers that don't exist; fix posted:
> >     - http://www.spinics.net/lists/arm-kernel/msg200646.html

Has that one been posted to RMK's patch system?

> > * AM335x Beaglebone: omap2plus_defconfig kernels don't boot
> >   - due to a GPMC bug
> >   - Apparently fixed by http://www.spinics.net/lists/arm-kernel/msg200787.html
> 
> This is now addressed and I have verified it is booting on v3.7-rc2. The
> following patch address this boot problem ...
> 
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8119024ef7363591fd958ec89ebfaee7c18209e3

That's in v3.7-rc2 already, is there some other problem too?

Regards,

Tony

Re: OMAP baseline test results for v3.7-rc2

[Paul Walmsley]

Hi Jon

On Mon, 22 Oct 2012, Jon Hunter wrote:

> On 10/20/2012 04:26 PM, Paul Walmsley wrote:
> 
> ...
> 
> > 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
> 
> I am not seeing this on my omap4430 panda. I have an OMAP4430 ES2.3 and
> I am using u-boot release 2012.10. What do you have?

It's documented in the bootlog:

http://www.pwsan.com/omap/testlogs/test_v3.7-rc2/20121020134755/boot/4430es2panda/4430es2panda_log.txt

It's "U-Boot 2012.07-00136-g755de79 (Aug 24 2012 - 14:19:44)" on an 
OMAP4430 ES2.0.


- Paul

OMAP baseline test results for v3.7-rc2

[Paul Walmsley]

Hi Jon

On Mon, 22 Oct 2012, Jon Hunter wrote:

> On 10/20/2012 04:26 PM, Paul Walmsley wrote:
> 
> ...
> 
> > 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
> 
> I am not seeing this on my omap4430 panda. I have an OMAP4430 ES2.3 and
> I am using u-boot release 2012.10. What do you have?

It's documented in the bootlog:

http://www.pwsan.com/omap/testlogs/test_v3.7-rc2/20121020134755/boot/4430es2panda/4430es2panda_log.txt

It's "U-Boot 2012.07-00136-g755de79 (Aug 24 2012 - 14:19:44)" on an 
OMAP4430 ES2.0.


- Paul

Re: OMAP baseline test results for v3.7-rc2

[Paul Walmsley]

On Mon, 22 Oct 2012, Paul Walmsley wrote:

> On Mon, 22 Oct 2012, Jon Hunter wrote:
> 
> > I am not seeing this on my omap4430 panda. I have an OMAP4430 ES2.3 and
> > I am using u-boot release 2012.10. What do you have?
> 
> It's documented in the bootlog:
> 
> http://www.pwsan.com/omap/testlogs/test_v3.7-rc2/20121020134755/boot/4430es2panda/4430es2panda_log.txt
> 
> It's "U-Boot 2012.07-00136-g755de79 (Aug 24 2012 - 14:19:44)" on an 
> OMAP4430 ES2.0.

By the way, would be happy to send a copy of the bootloader/MLO if you'd 
like it.


- Paul

OMAP baseline test results for v3.7-rc2

[Paul Walmsley]

On Mon, 22 Oct 2012, Paul Walmsley wrote:

> On Mon, 22 Oct 2012, Jon Hunter wrote:
> 
> > I am not seeing this on my omap4430 panda. I have an OMAP4430 ES2.3 and
> > I am using u-boot release 2012.10. What do you have?
> 
> It's documented in the bootlog:
> 
> http://www.pwsan.com/omap/testlogs/test_v3.7-rc2/20121020134755/boot/4430es2panda/4430es2panda_log.txt
> 
> It's "U-Boot 2012.07-00136-g755de79 (Aug 24 2012 - 14:19:44)" on an 
> OMAP4430 ES2.0.

By the way, would be happy to send a copy of the bootloader/MLO if you'd 
like it.


- Paul

Re: OMAP baseline test results for v3.7-rc2

[Paul Walmsley]

(including the lists in my reply this time, oops; also adding some more 
detail)

On Mon, 22 Oct 2012, Jon Hunter wrote:

> On 10/20/2012 04:26 PM, Paul Walmsley wrote:
>
> > Failing tests: fixed by posted patches
> > --------------------------------------
> > 
> > Boot tests:
> > 
> > * AM335x Beaglebone: omap2plus_defconfig kernels don't boot
> >   - due to a GPMC bug
> >   - Apparently fixed by http://www.spinics.net/lists/arm-kernel/msg200787.html
> 
> This is now addressed and I have verified it is booting on v3.7-rc2. The
> following patch address this boot problem ...
> 
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8119024ef7363591fd958ec89ebfaee7c18209e3

Great, thanks, will update the README.  Did you also enable 
CONFIG_ARM_APPENDED_DTB and CONFIG_ARM_ATAG_DTB_COMPAT, or were you able 
to pass the DTB from the bootloader?

> > * 4460pandaes: boot fails early
> >   - Appears to be timer-related
> 
> I tried v3.7-rc2 on my pandaES and it is booting fine for me.
> 
> I have an OMAP4460 ES1.1 and u-boot release 2012.10.

Tony's reporting the same thing so maybe this is a bootloader problem.  
Just sent you the bootloader/MLO from my board here, maybe you can give it 
a quick test if you have a moment.  Probably the kernel is implicitly 
assuming that the bootloader has enabled something.

> I don't wish to create more work for you, but it could be good to add
> silicon revision, u-boot release (if applicable)

These can be found by clicking through the link at the top of the message.  
In this case:

http://www.pwsan.com/omap/testlogs/test_v3.7-rc2/20121020134755/

Click on 'boot' and '4460pandaes'

> and toolchain used for any failures.

This would indeed be useful and will try to figure out a good way to add 
that information.


- Paul

OMAP baseline test results for v3.7-rc2

[Paul Walmsley]

(including the lists in my reply this time, oops; also adding some more 
detail)

On Mon, 22 Oct 2012, Jon Hunter wrote:

> On 10/20/2012 04:26 PM, Paul Walmsley wrote:
>
> > Failing tests: fixed by posted patches
> > --------------------------------------
> > 
> > Boot tests:
> > 
> > * AM335x Beaglebone: omap2plus_defconfig kernels don't boot
> >   - due to a GPMC bug
> >   - Apparently fixed by http://www.spinics.net/lists/arm-kernel/msg200787.html
> 
> This is now addressed and I have verified it is booting on v3.7-rc2. The
> following patch address this boot problem ...
> 
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8119024ef7363591fd958ec89ebfaee7c18209e3

Great, thanks, will update the README.  Did you also enable 
CONFIG_ARM_APPENDED_DTB and CONFIG_ARM_ATAG_DTB_COMPAT, or were you able 
to pass the DTB from the bootloader?

> > * 4460pandaes: boot fails early
> >   - Appears to be timer-related
> 
> I tried v3.7-rc2 on my pandaES and it is booting fine for me.
> 
> I have an OMAP4460 ES1.1 and u-boot release 2012.10.

Tony's reporting the same thing so maybe this is a bootloader problem.  
Just sent you the bootloader/MLO from my board here, maybe you can give it 
a quick test if you have a moment.  Probably the kernel is implicitly 
assuming that the bootloader has enabled something.

> I don't wish to create more work for you, but it could be good to add
> silicon revision, u-boot release (if applicable)

These can be found by clicking through the link at the top of the message.  
In this case:

http://www.pwsan.com/omap/testlogs/test_v3.7-rc2/20121020134755/

Click on 'boot' and '4460pandaes'

> and toolchain used for any failures.

This would indeed be useful and will try to figure out a good way to add 
that information.


- Paul

Re: OMAP baseline test results for v3.7-rc2

[Paul Walmsley]

On Mon, 22 Oct 2012, Paul Walmsley wrote:

> On Mon, 22 Oct 2012, Jon Hunter wrote:
> 
> > and toolchain used for any failures.
> 
> This would indeed be useful and will try to figure out a good way to add 
> that information.

Just realized that some of this appears in the beginning of the bootlogs:

[    0.000000] Linux version 3.7.0-rc2-00331-g6f0c058 (paul@nozomi) (gcc 
version 4.5.1 (Sourcery G++ Lite 2010.09-50) ) #1 SMP Sat Oct 20 14:04:56 
MDT 2012

Not the easiest information to find, but maybe it serves your needs?


- Paul

OMAP baseline test results for v3.7-rc2

[Paul Walmsley]

On Mon, 22 Oct 2012, Paul Walmsley wrote:

> On Mon, 22 Oct 2012, Jon Hunter wrote:
> 
> > and toolchain used for any failures.
> 
> This would indeed be useful and will try to figure out a good way to add 
> that information.

Just realized that some of this appears in the beginning of the bootlogs:

[    0.000000] Linux version 3.7.0-rc2-00331-g6f0c058 (paul at nozomi) (gcc 
version 4.5.1 (Sourcery G++ Lite 2010.09-50) ) #1 SMP Sat Oct 20 14:04:56 
MDT 2012

Not the easiest information to find, but maybe it serves your needs?


- Paul

Re: OMAP baseline test results for v3.7-rc2

[Jon Hunter]

On 10/22/2012 01:35 PM, Paul Walmsley wrote:
> (including the lists in my reply this time, oops; also adding some more 
> detail)
> 
> On Mon, 22 Oct 2012, Jon Hunter wrote:
> 
>> On 10/20/2012 04:26 PM, Paul Walmsley wrote:
>>
>>> Failing tests: fixed by posted patches
>>> --------------------------------------
>>>
>>> Boot tests:
>>>
>>> * AM335x Beaglebone: omap2plus_defconfig kernels don't boot
>>>   - due to a GPMC bug
>>>   - Apparently fixed by http://www.spinics.net/lists/arm-kernel/msg200787.html
>>
>> This is now addressed and I have verified it is booting on v3.7-rc2. The
>> following patch address this boot problem ...
>>
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8119024ef7363591fd958ec89ebfaee7c18209e3
> 
> Great, thanks, will update the README.  Did you also enable 
> CONFIG_ARM_APPENDED_DTB and CONFIG_ARM_ATAG_DTB_COMPAT, or were you able 
> to pass the DTB from the bootloader?

Actually, I built u-boot release 2012.10 for the am335x-evm and that
worked for the bone board too. So that is what I used. I have not
checked with Vaibhav and team if that is what they are using. So with
this u-boot I just passed the dtb to the kernel and did not append.

Cheers
Jon

OMAP baseline test results for v3.7-rc2

[Jon Hunter]

On 10/22/2012 01:35 PM, Paul Walmsley wrote:
> (including the lists in my reply this time, oops; also adding some more 
> detail)
> 
> On Mon, 22 Oct 2012, Jon Hunter wrote:
> 
>> On 10/20/2012 04:26 PM, Paul Walmsley wrote:
>>
>>> Failing tests: fixed by posted patches
>>> --------------------------------------
>>>
>>> Boot tests:
>>>
>>> * AM335x Beaglebone: omap2plus_defconfig kernels don't boot
>>>   - due to a GPMC bug
>>>   - Apparently fixed by http://www.spinics.net/lists/arm-kernel/msg200787.html
>>
>> This is now addressed and I have verified it is booting on v3.7-rc2. The
>> following patch address this boot problem ...
>>
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8119024ef7363591fd958ec89ebfaee7c18209e3
> 
> Great, thanks, will update the README.  Did you also enable 
> CONFIG_ARM_APPENDED_DTB and CONFIG_ARM_ATAG_DTB_COMPAT, or were you able 
> to pass the DTB from the bootloader?

Actually, I built u-boot release 2012.10 for the am335x-evm and that
worked for the bone board too. So that is what I used. I have not
checked with Vaibhav and team if that is what they are using. So with
this u-boot I just passed the dtb to the kernel and did not append.

Cheers
Jon

Re: OMAP baseline test results for v3.7-rc2

[Jon Hunter]

On 10/22/2012 01:36 PM, Paul Walmsley wrote:
> On Mon, 22 Oct 2012, Paul Walmsley wrote:
> 
>> On Mon, 22 Oct 2012, Jon Hunter wrote:
>>
>>> and toolchain used for any failures.
>>
>> This would indeed be useful and will try to figure out a good way to add 
>> that information.
> 
> Just realized that some of this appears in the beginning of the bootlogs:
> 
> [    0.000000] Linux version 3.7.0-rc2-00331-g6f0c058 (paul@nozomi) (gcc 
> version 4.5.1 (Sourcery G++ Lite 2010.09-50) ) #1 SMP Sat Oct 20 14:04:56 
> MDT 2012
> 
> Not the easiest information to find, but maybe it serves your needs?

Yes, it does. The boot log has all the info we need :-)

Cheers
Jon

OMAP baseline test results for v3.7-rc2

[Jon Hunter]

On 10/22/2012 01:36 PM, Paul Walmsley wrote:
> On Mon, 22 Oct 2012, Paul Walmsley wrote:
> 
>> On Mon, 22 Oct 2012, Jon Hunter wrote:
>>
>>> and toolchain used for any failures.
>>
>> This would indeed be useful and will try to figure out a good way to add 
>> that information.
> 
> Just realized that some of this appears in the beginning of the bootlogs:
> 
> [    0.000000] Linux version 3.7.0-rc2-00331-g6f0c058 (paul at nozomi) (gcc 
> version 4.5.1 (Sourcery G++ Lite 2010.09-50) ) #1 SMP Sat Oct 20 14:04:56 
> MDT 2012
> 
> Not the easiest information to find, but maybe it serves your needs?

Yes, it does. The boot log has all the info we need :-)

Cheers
Jon

Re: OMAP baseline test results for v3.7-rc2

[Kevin Hilman]

+Igor

Paul Walmsley <paul@pwsan.com> writes:

> Here are some basic OMAP test results for Linux v3.7-rc2.
> Logs and other details at:
>
>     http://www.pwsan.com/omap/testlogs/test_v3.7-rc2/20121020134755/

[...]

> * 37xx EVM: CORE not entering dynamic off-idle
>   - Cause unknown; dynamic retention-idle seems to work; system suspend to 
>     off works

I got a start on this one, and discovered (using CM_IDLEST1_CORE) that
SPI1 was not idle when going off.  A quick hack disabling the
touchscreen showed that after that, core was hitting idle just fine.

I ran out of time today debugging this, but it's definitely realted to
the GPIO debounce setting for the touchscreen.  Changing it to zero[1]
makes CORE hit retention again in idle.

Igor, I'm hoping you might know what's going on here since we already
had some problems with this ads7846 init stuff and you're more familiar
with this debounce init.

Kevin

[1]
diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
index b9b776b..3afdc50 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -734,7 +734,7 @@ static void __init omap3_evm_init(void)
 	omap_nand_flash_init(NAND_BUSWIDTH_16, omap3evm_nand_partitions,
 			     ARRAY_SIZE(omap3evm_nand_partitions));
 
-	omap_ads7846_init(1, OMAP3_EVM_TS_GPIO, 310, NULL);
+	omap_ads7846_init(1, OMAP3_EVM_TS_GPIO, 0, NULL);
 	omap3evm_init_smsc911x();
 	omap3_evm_display_init();
 	omap3_evm_wl12xx_init();

OMAP baseline test results for v3.7-rc2

[Kevin Hilman]

+Igor

Paul Walmsley <paul@pwsan.com> writes:

> Here are some basic OMAP test results for Linux v3.7-rc2.
> Logs and other details at:
>
>     http://www.pwsan.com/omap/testlogs/test_v3.7-rc2/20121020134755/

[...]

> * 37xx EVM: CORE not entering dynamic off-idle
>   - Cause unknown; dynamic retention-idle seems to work; system suspend to 
>     off works

I got a start on this one, and discovered (using CM_IDLEST1_CORE) that
SPI1 was not idle when going off.  A quick hack disabling the
touchscreen showed that after that, core was hitting idle just fine.

I ran out of time today debugging this, but it's definitely realted to
the GPIO debounce setting for the touchscreen.  Changing it to zero[1]
makes CORE hit retention again in idle.

Igor, I'm hoping you might know what's going on here since we already
had some problems with this ads7846 init stuff and you're more familiar
with this debounce init.

Kevin

[1]
diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
index b9b776b..3afdc50 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -734,7 +734,7 @@ static void __init omap3_evm_init(void)
 	omap_nand_flash_init(NAND_BUSWIDTH_16, omap3evm_nand_partitions,
 			     ARRAY_SIZE(omap3evm_nand_partitions));
 
-	omap_ads7846_init(1, OMAP3_EVM_TS_GPIO, 310, NULL);
+	omap_ads7846_init(1, OMAP3_EVM_TS_GPIO, 0, NULL);
 	omap3evm_init_smsc911x();
 	omap3_evm_display_init();
 	omap3_evm_wl12xx_init();

Re: OMAP baseline test results for v3.7-rc2

[Matt Porter]

On Mon, Oct 22, 2012 at 01:48:37PM -0500, Jon Hunter wrote:
> 
> On 10/22/2012 01:35 PM, Paul Walmsley wrote:
> > (including the lists in my reply this time, oops; also adding some more 
> > detail)
> > 
> > On Mon, 22 Oct 2012, Jon Hunter wrote:
> > 
> >> On 10/20/2012 04:26 PM, Paul Walmsley wrote:
> >>
> >>> Failing tests: fixed by posted patches
> >>> --------------------------------------
> >>>
> >>> Boot tests:
> >>>
> >>> * AM335x Beaglebone: omap2plus_defconfig kernels don't boot
> >>>   - due to a GPMC bug
> >>>   - Apparently fixed by http://www.spinics.net/lists/arm-kernel/msg200787.html
> >>
> >> This is now addressed and I have verified it is booting on v3.7-rc2. The
> >> following patch address this boot problem ...
> >>
> >> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8119024ef7363591fd958ec89ebfaee7c18209e3
> > 
> > Great, thanks, will update the README.  Did you also enable 
> > CONFIG_ARM_APPENDED_DTB and CONFIG_ARM_ATAG_DTB_COMPAT, or were you able 
> > to pass the DTB from the bootloader?
> 
> Actually, I built u-boot release 2012.10 for the am335x-evm and that
> worked for the bone board too. So that is what I used. I have not
> checked with Vaibhav and team if that is what they are using. So with
> this u-boot I just passed the dtb to the kernel and did not append.

I've mentioned this a few times in various threads...no need to use
appended DTB on a current U-Boot. Some of us are indeed booting this way
with the DTB properly passed separately from the bootloader and chosen
filled out by the bootloader. And yes, am335x_evm_config applies to all
AM33xx TI EVMs and the BeagleBone board. There's an EEPROM onboard all
that is used to determine what board is present so a single
MLO/u-boot.img can be used.

BTW, if you pick up an RS-232 cape, you can avoid using the FTDI->UART0
connection for console and switch to any UART brought out on the Bone
connectors. This is useful for those using a power controller and
console server for local automated testing.

-Matt

OMAP baseline test results for v3.7-rc2

[Matt Porter]

On Mon, Oct 22, 2012 at 01:48:37PM -0500, Jon Hunter wrote:
> 
> On 10/22/2012 01:35 PM, Paul Walmsley wrote:
> > (including the lists in my reply this time, oops; also adding some more 
> > detail)
> > 
> > On Mon, 22 Oct 2012, Jon Hunter wrote:
> > 
> >> On 10/20/2012 04:26 PM, Paul Walmsley wrote:
> >>
> >>> Failing tests: fixed by posted patches
> >>> --------------------------------------
> >>>
> >>> Boot tests:
> >>>
> >>> * AM335x Beaglebone: omap2plus_defconfig kernels don't boot
> >>>   - due to a GPMC bug
> >>>   - Apparently fixed by http://www.spinics.net/lists/arm-kernel/msg200787.html
> >>
> >> This is now addressed and I have verified it is booting on v3.7-rc2. The
> >> following patch address this boot problem ...
> >>
> >> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8119024ef7363591fd958ec89ebfaee7c18209e3
> > 
> > Great, thanks, will update the README.  Did you also enable 
> > CONFIG_ARM_APPENDED_DTB and CONFIG_ARM_ATAG_DTB_COMPAT, or were you able 
> > to pass the DTB from the bootloader?
> 
> Actually, I built u-boot release 2012.10 for the am335x-evm and that
> worked for the bone board too. So that is what I used. I have not
> checked with Vaibhav and team if that is what they are using. So with
> this u-boot I just passed the dtb to the kernel and did not append.

I've mentioned this a few times in various threads...no need to use
appended DTB on a current U-Boot. Some of us are indeed booting this way
with the DTB properly passed separately from the bootloader and chosen
filled out by the bootloader. And yes, am335x_evm_config applies to all
AM33xx TI EVMs and the BeagleBone board. There's an EEPROM onboard all
that is used to determine what board is present so a single
MLO/u-boot.img can be used.

BTW, if you pick up an RS-232 cape, you can avoid using the FTDI->UART0
connection for console and switch to any UART brought out on the Bone
connectors. This is useful for those using a power controller and
console server for local automated testing.

-Matt

Re: OMAP baseline test results for v3.7-rc2

[Paul Walmsley]

On Mon, 22 Oct 2012, Matt Porter wrote:

> I've mentioned this a few times in various threads...no need to use
> appended DTB on a current U-Boot. Some of us are indeed booting this way
> with the DTB properly passed separately from the bootloader and chosen
> filled out by the bootloader. And yes, am335x_evm_config applies to all
> AM33xx TI EVMs and the BeagleBone board. There's an EEPROM onboard all
> that is used to determine what board is present so a single
> MLO/u-boot.img can be used.

As Kevin mentioned earlier, this is unfortunately not true for those of us 
with earlier BeagleBoards:

   http://marc.info/?l=linux-omap&m=135094296931913&w=2

Do you know what the minimum board revision is that you all are 
supporting in U-boot?



- Paul

OMAP baseline test results for v3.7-rc2

[Paul Walmsley]

On Mon, 22 Oct 2012, Matt Porter wrote:

> I've mentioned this a few times in various threads...no need to use
> appended DTB on a current U-Boot. Some of us are indeed booting this way
> with the DTB properly passed separately from the bootloader and chosen
> filled out by the bootloader. And yes, am335x_evm_config applies to all
> AM33xx TI EVMs and the BeagleBone board. There's an EEPROM onboard all
> that is used to determine what board is present so a single
> MLO/u-boot.img can be used.

As Kevin mentioned earlier, this is unfortunately not true for those of us 
with earlier BeagleBoards:

   http://marc.info/?l=linux-omap&m=135094296931913&w=2

Do you know what the minimum board revision is that you all are 
supporting in U-boot?



- Paul

Re: OMAP baseline test results for v3.7-rc2

[Paul Walmsley]

On Tue, 23 Oct 2012, Paul Walmsley wrote:

> As Kevin mentioned earlier, this is unfortunately not true for those of us 
> with earlier BeagleBoards:

er, BeagleBones, rather...


- Paul

OMAP baseline test results for v3.7-rc2

[Paul Walmsley]

On Tue, 23 Oct 2012, Paul Walmsley wrote:

> As Kevin mentioned earlier, this is unfortunately not true for those of us 
> with earlier BeagleBoards:

er, BeagleBones, rather...


- Paul

Re: OMAP baseline test results for v3.7-rc2

[Matt Porter]

On Tue, Oct 23, 2012 at 03:15:44AM +0000, Paul Walmsley wrote:
> On Mon, 22 Oct 2012, Matt Porter wrote:
> 
> > I've mentioned this a few times in various threads...no need to use
> > appended DTB on a current U-Boot. Some of us are indeed booting this way
> > with the DTB properly passed separately from the bootloader and chosen
> > filled out by the bootloader. And yes, am335x_evm_config applies to all
> > AM33xx TI EVMs and the BeagleBone board. There's an EEPROM onboard all
> > that is used to determine what board is present so a single
> > MLO/u-boot.img can be used.
> 
> As Kevin mentioned earlier, this is unfortunately not true for those of us 
> with earlier BeagleBoards:
> 
>    http://marc.info/?l=linux-omap&m=135094296931913&w=2

Yes, we spoke about this a bit.
 
> Do you know what the minimum board revision is that you all are 
> supporting in U-boot?

It's not so much a revision as it is getting the right contents in the
EEPROM. As it's a community board, it's generally only supported over at
beagleboard@googlegroups.com. Jason Kridner recommends posting support
questions there (like why isn't my A2 supported in U-Boot?). If there
isn't some solution suggested there for updating the A2 I would contact
him directly. I have an A1 Bone here that also doesn't work with
mainline U-Boot even after configuring the EEPROM. You can try this
procedure if you want to write the proper contents in, an A2 may work
but for some reason there's no available history on Bone revisions prior
to A3. I vaguely recall a lot of chatter around the phy and so forth in
the A1 to A2 timeframe so it's entirely possible that your A2 will work
with just the eeprom contents programmed. Without it, it's guaranteed to
fail as the pin muxing is tied to detecting the board this way. Also,
you may need to change <offset>.1 in the below example to <offset>.2 for
your eeprom i/o to work as A2 may require an address length of 2.

-Matt

U-Boot 2012.10-00286-gfe27b3b (Oct 22 2012 - 16:40:21)

I2C:   ready
DRAM:  256 MiB
WARNING: Caches not enabled
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
Using default environment

Net:   PHY reset timed out
cpsw
Hit any key to stop autoboot:  0
U-Boot# i2c dev 0
Setting bus to 0
U-Boot# i2c md 50 0.1
0000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
U-Boot# mm.b 84000000
84000000: 55 ? aa
84000001: 51 ? 55
84000002: 16 ? 33
84000003: 00 ? ee
84000004: 40 ? 41
84000005: 94 ? 33
84000006: 28 ? 33
84000007: 41 ? 35
84000008: 11 ? 42
84000009: 55 ? 4f
8400000a: 80 ? 4e
8400000b: 8e ? 45
8400000c: 03 ? 30
8400000d: 5d ? 30
8400000e: 44 ? 41
8400000f: a0 ? 32
84000010: 46 ? .
U-Boot# i2c write 84000000 50 0.1 10
U-Boot# i2c md 50 0.1 10
0000: aa 55 33 ee 41 33 33 35 42 4f 4e 45 30 30 41 32
.U3.A335BONE00A2
U-Boot#

OMAP baseline test results for v3.7-rc2

[Matt Porter]

On Tue, Oct 23, 2012 at 03:15:44AM +0000, Paul Walmsley wrote:
> On Mon, 22 Oct 2012, Matt Porter wrote:
> 
> > I've mentioned this a few times in various threads...no need to use
> > appended DTB on a current U-Boot. Some of us are indeed booting this way
> > with the DTB properly passed separately from the bootloader and chosen
> > filled out by the bootloader. And yes, am335x_evm_config applies to all
> > AM33xx TI EVMs and the BeagleBone board. There's an EEPROM onboard all
> > that is used to determine what board is present so a single
> > MLO/u-boot.img can be used.
> 
> As Kevin mentioned earlier, this is unfortunately not true for those of us 
> with earlier BeagleBoards:
> 
>    http://marc.info/?l=linux-omap&m=135094296931913&w=2

Yes, we spoke about this a bit.
 
> Do you know what the minimum board revision is that you all are 
> supporting in U-boot?

It's not so much a revision as it is getting the right contents in the
EEPROM. As it's a community board, it's generally only supported over at
beagleboard at googlegroups.com. Jason Kridner recommends posting support
questions there (like why isn't my A2 supported in U-Boot?). If there
isn't some solution suggested there for updating the A2 I would contact
him directly. I have an A1 Bone here that also doesn't work with
mainline U-Boot even after configuring the EEPROM. You can try this
procedure if you want to write the proper contents in, an A2 may work
but for some reason there's no available history on Bone revisions prior
to A3. I vaguely recall a lot of chatter around the phy and so forth in
the A1 to A2 timeframe so it's entirely possible that your A2 will work
with just the eeprom contents programmed. Without it, it's guaranteed to
fail as the pin muxing is tied to detecting the board this way. Also,
you may need to change <offset>.1 in the below example to <offset>.2 for
your eeprom i/o to work as A2 may require an address length of 2.

-Matt

U-Boot 2012.10-00286-gfe27b3b (Oct 22 2012 - 16:40:21)

I2C:   ready
DRAM:  256 MiB
WARNING: Caches not enabled
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
Using default environment

Net:   PHY reset timed out
cpsw
Hit any key to stop autoboot:  0
U-Boot# i2c dev 0
Setting bus to 0
U-Boot# i2c md 50 0.1
0000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
U-Boot# mm.b 84000000
84000000: 55 ? aa
84000001: 51 ? 55
84000002: 16 ? 33
84000003: 00 ? ee
84000004: 40 ? 41
84000005: 94 ? 33
84000006: 28 ? 33
84000007: 41 ? 35
84000008: 11 ? 42
84000009: 55 ? 4f
8400000a: 80 ? 4e
8400000b: 8e ? 45
8400000c: 03 ? 30
8400000d: 5d ? 30
8400000e: 44 ? 41
8400000f: a0 ? 32
84000010: 46 ? .
U-Boot# i2c write 84000000 50 0.1 10
U-Boot# i2c md 50 0.1 10
0000: aa 55 33 ee 41 33 33 35 42 4f 4e 45 30 30 41 32
.U3.A335BONE00A2
U-Boot#

Re: OMAP baseline test results for v3.7-rc2

[Matt Porter]

On Tue, Oct 23, 2012 at 08:24:36AM -0400, Matt Porter wrote:
> On Tue, Oct 23, 2012 at 03:15:44AM +0000, Paul Walmsley wrote:
> > On Mon, 22 Oct 2012, Matt Porter wrote:
> > 
> > > I've mentioned this a few times in various threads...no need to use
> > > appended DTB on a current U-Boot. Some of us are indeed booting this way
> > > with the DTB properly passed separately from the bootloader and chosen
> > > filled out by the bootloader. And yes, am335x_evm_config applies to all
> > > AM33xx TI EVMs and the BeagleBone board. There's an EEPROM onboard all
> > > that is used to determine what board is present so a single
> > > MLO/u-boot.img can be used.
> > 
> > As Kevin mentioned earlier, this is unfortunately not true for those of us 
> > with earlier BeagleBoards:
> > 
> >    http://marc.info/?l=linux-omap&m=135094296931913&w=2
> 
> Yes, we spoke about this a bit.
>  
> > Do you know what the minimum board revision is that you all are 
> > supporting in U-boot?
> 
> It's not so much a revision as it is getting the right contents in the
> EEPROM. As it's a community board, it's generally only supported over at
> beagleboard@googlegroups.com. Jason Kridner recommends posting support
> questions there (like why isn't my A2 supported in U-Boot?). If there
> isn't some solution suggested there for updating the A2 I would contact
> him directly. I have an A1 Bone here that also doesn't work with
> mainline U-Boot even after configuring the EEPROM. You can try this
> procedure if you want to write the proper contents in, an A2 may work
> but for some reason there's no available history on Bone revisions prior
> to A3. I vaguely recall a lot of chatter around the phy and so forth in
> the A1 to A2 timeframe so it's entirely possible that your A2 will work
> with just the eeprom contents programmed. Without it, it's guaranteed to
> fail as the pin muxing is tied to detecting the board this way. Also,
> you may need to change <offset>.1 in the below example to <offset>.2 for
> your eeprom i/o to work as A2 may require an address length of 2.

Ok, very quick update...no need to mess around with the eeprom. I just
received the official word on what will be supported. Since A2 is
pre-release, simply go to http://beagleboard.org/support/rma and fill
out the form to have it replaced with the current revision (A6).

This applies to *anyone* that received a pre-release A2 board.

-Matt

OMAP baseline test results for v3.7-rc2

[Matt Porter]

On Tue, Oct 23, 2012 at 08:24:36AM -0400, Matt Porter wrote:
> On Tue, Oct 23, 2012 at 03:15:44AM +0000, Paul Walmsley wrote:
> > On Mon, 22 Oct 2012, Matt Porter wrote:
> > 
> > > I've mentioned this a few times in various threads...no need to use
> > > appended DTB on a current U-Boot. Some of us are indeed booting this way
> > > with the DTB properly passed separately from the bootloader and chosen
> > > filled out by the bootloader. And yes, am335x_evm_config applies to all
> > > AM33xx TI EVMs and the BeagleBone board. There's an EEPROM onboard all
> > > that is used to determine what board is present so a single
> > > MLO/u-boot.img can be used.
> > 
> > As Kevin mentioned earlier, this is unfortunately not true for those of us 
> > with earlier BeagleBoards:
> > 
> >    http://marc.info/?l=linux-omap&m=135094296931913&w=2
> 
> Yes, we spoke about this a bit.
>  
> > Do you know what the minimum board revision is that you all are 
> > supporting in U-boot?
> 
> It's not so much a revision as it is getting the right contents in the
> EEPROM. As it's a community board, it's generally only supported over at
> beagleboard at googlegroups.com. Jason Kridner recommends posting support
> questions there (like why isn't my A2 supported in U-Boot?). If there
> isn't some solution suggested there for updating the A2 I would contact
> him directly. I have an A1 Bone here that also doesn't work with
> mainline U-Boot even after configuring the EEPROM. You can try this
> procedure if you want to write the proper contents in, an A2 may work
> but for some reason there's no available history on Bone revisions prior
> to A3. I vaguely recall a lot of chatter around the phy and so forth in
> the A1 to A2 timeframe so it's entirely possible that your A2 will work
> with just the eeprom contents programmed. Without it, it's guaranteed to
> fail as the pin muxing is tied to detecting the board this way. Also,
> you may need to change <offset>.1 in the below example to <offset>.2 for
> your eeprom i/o to work as A2 may require an address length of 2.

Ok, very quick update...no need to mess around with the eeprom. I just
received the official word on what will be supported. Since A2 is
pre-release, simply go to http://beagleboard.org/support/rma and fill
out the form to have it replaced with the current revision (A6).

This applies to *anyone* that received a pre-release A2 board.

-Matt

Re: OMAP baseline test results for v3.7-rc2

[Kevin Hilman]

Kevin Hilman <khilman@deeprootsystems.com> writes:

> +Igor
>
> Paul Walmsley <paul@pwsan.com> writes:
>
>> Here are some basic OMAP test results for Linux v3.7-rc2.
>> Logs and other details at:
>>
>>     http://www.pwsan.com/omap/testlogs/test_v3.7-rc2/20121020134755/
>
> [...]
>
>> * 37xx EVM: CORE not entering dynamic off-idle
>>   - Cause unknown; dynamic retention-idle seems to work; system suspend to 
>>     off works
>
> I got a start on this one, and discovered (using CM_IDLEST1_CORE) that
> SPI1 was not idle when going off.  A quick hack disabling the
> touchscreen showed that after that, core was hitting idle just fine.
>
> I ran out of time today debugging this, but it's definitely realted to
> the GPIO debounce setting for the touchscreen.  Changing it to zero[1]
> makes CORE hit retention again in idle.

OK, found the root cause of this in the GPIO driver.  Patch submitted:

    http://marc.info/?l=linux-omap&m=135101577925972&w=2

however...

> Igor, I'm hoping you might know what's going on here since we already
> had some problems with this ads7846 init stuff and you're more familiar
> with this debounce init.

... board files that are setting debounce values for ads7846 will no
longer work.  

Currently, omap_ads7846_init() in common-board-devices.c does this:

   gpio_request_one()
   gpio_set_debounce()
   gpio_free()                    

because of a bug in the GPIO driver, the debounce settings were sticky
and lingered even after the gpio_free().  That bug has been fixed by the
above patch, which means the above gpio_set_debounce() is completely
pointless because it's followed immediately by a gpio_free().

IMO, the whole GPIO init for the ads7846 needs a rethink as it's
currently partially done by common-board-devices.c and done (again) in
the ads7846 driver.  If the gpio_free() isn't done in
common-board-devices, then the ads7846 driver will currently fail to
probe/load becasue it can't request a GPIO line.

Having found and fixed the PM regression, I'll leave the ads7846 cleanup to
somone else.

Kevin

OMAP baseline test results for v3.7-rc2

[Kevin Hilman]

Kevin Hilman <khilman@deeprootsystems.com> writes:

> +Igor
>
> Paul Walmsley <paul@pwsan.com> writes:
>
>> Here are some basic OMAP test results for Linux v3.7-rc2.
>> Logs and other details at:
>>
>>     http://www.pwsan.com/omap/testlogs/test_v3.7-rc2/20121020134755/
>
> [...]
>
>> * 37xx EVM: CORE not entering dynamic off-idle
>>   - Cause unknown; dynamic retention-idle seems to work; system suspend to 
>>     off works
>
> I got a start on this one, and discovered (using CM_IDLEST1_CORE) that
> SPI1 was not idle when going off.  A quick hack disabling the
> touchscreen showed that after that, core was hitting idle just fine.
>
> I ran out of time today debugging this, but it's definitely realted to
> the GPIO debounce setting for the touchscreen.  Changing it to zero[1]
> makes CORE hit retention again in idle.

OK, found the root cause of this in the GPIO driver.  Patch submitted:

    http://marc.info/?l=linux-omap&m=135101577925972&w=2

however...

> Igor, I'm hoping you might know what's going on here since we already
> had some problems with this ads7846 init stuff and you're more familiar
> with this debounce init.

... board files that are setting debounce values for ads7846 will no
longer work.  

Currently, omap_ads7846_init() in common-board-devices.c does this:

   gpio_request_one()
   gpio_set_debounce()
   gpio_free()                    

because of a bug in the GPIO driver, the debounce settings were sticky
and lingered even after the gpio_free().  That bug has been fixed by the
above patch, which means the above gpio_set_debounce() is completely
pointless because it's followed immediately by a gpio_free().

IMO, the whole GPIO init for the ads7846 needs a rethink as it's
currently partially done by common-board-devices.c and done (again) in
the ads7846 driver.  If the gpio_free() isn't done in
common-board-devices, then the ads7846 driver will currently fail to
probe/load becasue it can't request a GPIO line.

Having found and fixed the PM regression, I'll leave the ads7846 cleanup to
somone else.

Kevin

Re: OMAP baseline test results for v3.7-rc2

[Paul Walmsley]

On Mon, 22 Oct 2012, Tony Lindgren wrote:

> * Jon Hunter <jon-hunter@ti.com> [121022 09:30]:
> > On 10/20/2012 04:26 PM, Paul Walmsley wrote:
> > > 
> > > * 2430sdp: vfp_reload_hw oops during MMC initialization
> > >   - Kernel attempts to save FP registers that don't exist; fix posted:
> > >     - http://www.spinics.net/lists/arm-kernel/msg200646.html
> 
> Has that one been posted to RMK's patch system?

Just did that, let's see what happens.

> > > * AM335x Beaglebone: omap2plus_defconfig kernels don't boot
> > >   - due to a GPMC bug
> > >   - Apparently fixed by http://www.spinics.net/lists/arm-kernel/msg200787.html
> > 
> > This is now addressed and I have verified it is booting on v3.7-rc2. The
> > following patch address this boot problem ...
> > 
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8119024ef7363591fd958ec89ebfaee7c18209e3
> 
> That's in v3.7-rc2 already, is there some other problem too?

Will try a re-test.

- Paul

OMAP baseline test results for v3.7-rc2

[Paul Walmsley]

On Mon, 22 Oct 2012, Tony Lindgren wrote:

> * Jon Hunter <jon-hunter@ti.com> [121022 09:30]:
> > On 10/20/2012 04:26 PM, Paul Walmsley wrote:
> > > 
> > > * 2430sdp: vfp_reload_hw oops during MMC initialization
> > >   - Kernel attempts to save FP registers that don't exist; fix posted:
> > >     - http://www.spinics.net/lists/arm-kernel/msg200646.html
> 
> Has that one been posted to RMK's patch system?

Just did that, let's see what happens.

> > > * AM335x Beaglebone: omap2plus_defconfig kernels don't boot
> > >   - due to a GPMC bug
> > >   - Apparently fixed by http://www.spinics.net/lists/arm-kernel/msg200787.html
> > 
> > This is now addressed and I have verified it is booting on v3.7-rc2. The
> > following patch address this boot problem ...
> > 
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8119024ef7363591fd958ec89ebfaee7c18209e3
> 
> That's in v3.7-rc2 already, is there some other problem too?

Will try a re-test.

- Paul

Re: OMAP baseline test results for v3.7-rc2

[Kevin Hilman]

Matt Porter <mporter@ti.com> writes:

[...]

> Ok, very quick update...no need to mess around with the eeprom. I just
> received the official word on what will be supported. Since A2 is
> pre-release, simply go to http://beagleboard.org/support/rma and fill
> out the form to have it replaced with the current revision (A6).
>
> This applies to *anyone* that received a pre-release A2 board.

Hmm, doesn't seem the RMA people are aware of this.  They just rejected
my request since it's not a "hardware related issue":

   Kevin,

   We only work with hardware related issue here. BeagleBone revision A2
   was not officially released. We recommend you to work with the
   community for support in Uboot. You can post your questions at the
   BeagleBoard Google Groups:
   https://groups.google.com/forum/?fromgroups=#!forum/beagleboard

   Regards,
   RMA Team

OMAP baseline test results for v3.7-rc2

[Kevin Hilman]

Matt Porter <mporter@ti.com> writes:

[...]

> Ok, very quick update...no need to mess around with the eeprom. I just
> received the official word on what will be supported. Since A2 is
> pre-release, simply go to http://beagleboard.org/support/rma and fill
> out the form to have it replaced with the current revision (A6).
>
> This applies to *anyone* that received a pre-release A2 board.

Hmm, doesn't seem the RMA people are aware of this.  They just rejected
my request since it's not a "hardware related issue":

   Kevin,

   We only work with hardware related issue here. BeagleBone revision A2
   was not officially released. We recommend you to work with the
   community for support in Uboot. You can post your questions at the
   BeagleBoard Google Groups:
   https://groups.google.com/forum/?fromgroups=#!forum/beagleboard

   Regards,
   RMA Team

Re: OMAP baseline test results for v3.7-rc2

[Matt Porter]

On Tue, Oct 23, 2012 at 02:03:43PM -0700, Kevin Hilman wrote:
> Matt Porter <mporter@ti.com> writes:
> 
> [...]
> 
> > Ok, very quick update...no need to mess around with the eeprom. I just
> > received the official word on what will be supported. Since A2 is
> > pre-release, simply go to http://beagleboard.org/support/rma and fill
> > out the form to have it replaced with the current revision (A6).
> >
> > This applies to *anyone* that received a pre-release A2 board.
> 
> Hmm, doesn't seem the RMA people are aware of this.  They just rejected
> my request since it's not a "hardware related issue":
> 
>    Kevin,
> 
>    We only work with hardware related issue here. BeagleBone revision A2
>    was not officially released. We recommend you to work with the
>    community for support in Uboot. You can post your questions at the
>    BeagleBoard Google Groups:
>    https://groups.google.com/forum/?fromgroups=#!forum/beagleboard
> 
>    Regards,
>    RMA Team

That's sad considering the beagleboard.org/BeagleBone hardware designer
specifically said they would be replaced via this route. *sigh*. Ok, I'll
go back and share this with him.

-Matt

OMAP baseline test results for v3.7-rc2

[Matt Porter]

On Tue, Oct 23, 2012 at 02:03:43PM -0700, Kevin Hilman wrote:
> Matt Porter <mporter@ti.com> writes:
> 
> [...]
> 
> > Ok, very quick update...no need to mess around with the eeprom. I just
> > received the official word on what will be supported. Since A2 is
> > pre-release, simply go to http://beagleboard.org/support/rma and fill
> > out the form to have it replaced with the current revision (A6).
> >
> > This applies to *anyone* that received a pre-release A2 board.
> 
> Hmm, doesn't seem the RMA people are aware of this.  They just rejected
> my request since it's not a "hardware related issue":
> 
>    Kevin,
> 
>    We only work with hardware related issue here. BeagleBone revision A2
>    was not officially released. We recommend you to work with the
>    community for support in Uboot. You can post your questions at the
>    BeagleBoard Google Groups:
>    https://groups.google.com/forum/?fromgroups=#!forum/beagleboard
> 
>    Regards,
>    RMA Team

That's sad considering the beagleboard.org/BeagleBone hardware designer
specifically said they would be replaced via this route. *sigh*. Ok, I'll
go back and share this with him.

-Matt

Re: OMAP baseline test results for v3.7-rc2

[Igor Grinberg]

On 10/23/12 20:19, Kevin Hilman wrote:
> Kevin Hilman <khilman@deeprootsystems.com> writes:
> 
>> +Igor
>>
>> Paul Walmsley <paul@pwsan.com> writes:
>>
>>> Here are some basic OMAP test results for Linux v3.7-rc2.
>>> Logs and other details at:
>>>
>>>     http://www.pwsan.com/omap/testlogs/test_v3.7-rc2/20121020134755/
>>
>> [...]
>>
>>> * 37xx EVM: CORE not entering dynamic off-idle
>>>   - Cause unknown; dynamic retention-idle seems to work; system suspend to 
>>>     off works
>>
>> I got a start on this one, and discovered (using CM_IDLEST1_CORE) that
>> SPI1 was not idle when going off.  A quick hack disabling the
>> touchscreen showed that after that, core was hitting idle just fine.
>>
>> I ran out of time today debugging this, but it's definitely realted to
>> the GPIO debounce setting for the touchscreen.  Changing it to zero[1]
>> makes CORE hit retention again in idle.
> 
> OK, found the root cause of this in the GPIO driver.  Patch submitted:
> 
>     http://marc.info/?l=linux-omap&m=135101577925972&w=2

Ok that one looks good.

> 
> however...
> 
>> Igor, I'm hoping you might know what's going on here since we already
>> had some problems with this ads7846 init stuff and you're more familiar
>> with this debounce init.
> 
> ... board files that are setting debounce values for ads7846 will no
> longer work.  
> 
> Currently, omap_ads7846_init() in common-board-devices.c does this:
> 
>    gpio_request_one()
>    gpio_set_debounce()
>    gpio_free()                    
> 
> because of a bug in the GPIO driver, the debounce settings were sticky
> and lingered even after the gpio_free().  That bug has been fixed by the
> above patch, which means the above gpio_set_debounce() is completely
> pointless because it's followed immediately by a gpio_free().
> 
> IMO, the whole GPIO init for the ads7846 needs a rethink as it's
> currently partially done by common-board-devices.c and done (again) in
> the ads7846 driver.  If the gpio_free() isn't done in
> common-board-devices, then the ads7846 driver will currently fail to
> probe/load becasue it can't request a GPIO line.
> 
> Having found and fixed the PM regression, I'll leave the ads7846 cleanup to
> somone else.

Ok, understood, I'll look into this one soon.


-- 
Regards,
Igor.

OMAP baseline test results for v3.7-rc2

[Igor Grinberg]

On 10/23/12 20:19, Kevin Hilman wrote:
> Kevin Hilman <khilman@deeprootsystems.com> writes:
> 
>> +Igor
>>
>> Paul Walmsley <paul@pwsan.com> writes:
>>
>>> Here are some basic OMAP test results for Linux v3.7-rc2.
>>> Logs and other details at:
>>>
>>>     http://www.pwsan.com/omap/testlogs/test_v3.7-rc2/20121020134755/
>>
>> [...]
>>
>>> * 37xx EVM: CORE not entering dynamic off-idle
>>>   - Cause unknown; dynamic retention-idle seems to work; system suspend to 
>>>     off works
>>
>> I got a start on this one, and discovered (using CM_IDLEST1_CORE) that
>> SPI1 was not idle when going off.  A quick hack disabling the
>> touchscreen showed that after that, core was hitting idle just fine.
>>
>> I ran out of time today debugging this, but it's definitely realted to
>> the GPIO debounce setting for the touchscreen.  Changing it to zero[1]
>> makes CORE hit retention again in idle.
> 
> OK, found the root cause of this in the GPIO driver.  Patch submitted:
> 
>     http://marc.info/?l=linux-omap&m=135101577925972&w=2

Ok that one looks good.

> 
> however...
> 
>> Igor, I'm hoping you might know what's going on here since we already
>> had some problems with this ads7846 init stuff and you're more familiar
>> with this debounce init.
> 
> ... board files that are setting debounce values for ads7846 will no
> longer work.  
> 
> Currently, omap_ads7846_init() in common-board-devices.c does this:
> 
>    gpio_request_one()
>    gpio_set_debounce()
>    gpio_free()                    
> 
> because of a bug in the GPIO driver, the debounce settings were sticky
> and lingered even after the gpio_free().  That bug has been fixed by the
> above patch, which means the above gpio_set_debounce() is completely
> pointless because it's followed immediately by a gpio_free().
> 
> IMO, the whole GPIO init for the ads7846 needs a rethink as it's
> currently partially done by common-board-devices.c and done (again) in
> the ads7846 driver.  If the gpio_free() isn't done in
> common-board-devices, then the ads7846 driver will currently fail to
> probe/load becasue it can't request a GPIO line.
> 
> Having found and fixed the PM regression, I'll leave the ads7846 cleanup to
> somone else.

Ok, understood, I'll look into this one soon.


-- 
Regards,
Igor.

Re: OMAP baseline test results for v3.7-rc2

[Kevin Hilman]

Matt Porter <mporter@ti.com> writes:

> On Tue, Oct 23, 2012 at 02:03:43PM -0700, Kevin Hilman wrote:
>> Matt Porter <mporter@ti.com> writes:
>> 
>> [...]
>> 
>> > Ok, very quick update...no need to mess around with the eeprom. I just
>> > received the official word on what will be supported. Since A2 is
>> > pre-release, simply go to http://beagleboard.org/support/rma and fill
>> > out the form to have it replaced with the current revision (A6).
>> >
>> > This applies to *anyone* that received a pre-release A2 board.
>> 
>> Hmm, doesn't seem the RMA people are aware of this.  They just rejected
>> my request since it's not a "hardware related issue":
>> 
>>    Kevin,
>> 
>>    We only work with hardware related issue here. BeagleBone revision A2
>>    was not officially released. We recommend you to work with the
>>    community for support in Uboot. You can post your questions at the
>>    BeagleBoard Google Groups:
>>    https://groups.google.com/forum/?fromgroups=#!forum/beagleboard
>> 
>>    Regards,
>>    RMA Team
>
> That's sad considering the beagleboard.org/BeagleBone hardware designer
> specifically said they would be replaced via this route. *sigh*. Ok, I'll
> go back and share this with him.

Just and update...

Something happened behind the scenes (thanks Matt) and they've accepted
my RMA request.  I'll be sending back my board in order to get a new
one.

Thanks,

Kevin

OMAP baseline test results for v3.7-rc2

[Kevin Hilman]

Matt Porter <mporter@ti.com> writes:

> On Tue, Oct 23, 2012 at 02:03:43PM -0700, Kevin Hilman wrote:
>> Matt Porter <mporter@ti.com> writes:
>> 
>> [...]
>> 
>> > Ok, very quick update...no need to mess around with the eeprom. I just
>> > received the official word on what will be supported. Since A2 is
>> > pre-release, simply go to http://beagleboard.org/support/rma and fill
>> > out the form to have it replaced with the current revision (A6).
>> >
>> > This applies to *anyone* that received a pre-release A2 board.
>> 
>> Hmm, doesn't seem the RMA people are aware of this.  They just rejected
>> my request since it's not a "hardware related issue":
>> 
>>    Kevin,
>> 
>>    We only work with hardware related issue here. BeagleBone revision A2
>>    was not officially released. We recommend you to work with the
>>    community for support in Uboot. You can post your questions at the
>>    BeagleBoard Google Groups:
>>    https://groups.google.com/forum/?fromgroups=#!forum/beagleboard
>> 
>>    Regards,
>>    RMA Team
>
> That's sad considering the beagleboard.org/BeagleBone hardware designer
> specifically said they would be replaced via this route. *sigh*. Ok, I'll
> go back and share this with him.

Just and update...

Something happened behind the scenes (thanks Matt) and they've accepted
my RMA request.  I'll be sending back my board in order to get a new
one.

Thanks,

Kevin