* OMAP baseline test results for v3.7-rc2
@ 2012-10-20 21:26 ` Paul Walmsley
0 siblings, 0 replies; 46+ messages in thread
From: Paul Walmsley @ 2012-10-20 21:26 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 46+ messages in thread* Re: OMAP baseline test results for v3.7-rc2
2012-10-20 21:26 ` Paul Walmsley
@ 2012-10-21 17:06 ` Paul Walmsley
-1 siblings, 0 replies; 46+ messages in thread
From: Paul Walmsley @ 2012-10-21 17:06 UTC (permalink / raw)
To: linux-omap, linux-arm-kernel, khilman
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: OMAP baseline test results for v3.7-rc2
2012-10-20 21:26 ` Paul Walmsley
@ 2012-10-22 16:10 ` Jon Hunter
-1 siblings, 0 replies; 46+ messages in thread
From: Jon Hunter @ 2012-10-22 16:10 UTC (permalink / raw)
To: Paul Walmsley; +Cc: linux-omap, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* OMAP baseline test results for v3.7-rc2
@ 2012-10-22 16:10 ` Jon Hunter
0 siblings, 0 replies; 46+ messages in thread
From: Jon Hunter @ 2012-10-22 16:10 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: OMAP baseline test results for v3.7-rc2
2012-10-22 16:10 ` Jon Hunter
@ 2012-10-22 17:17 ` Paul Walmsley
-1 siblings, 0 replies; 46+ messages in thread
From: Paul Walmsley @ 2012-10-22 17:17 UTC (permalink / raw)
To: Jon Hunter; +Cc: linux-omap, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* OMAP baseline test results for v3.7-rc2
@ 2012-10-22 17:17 ` Paul Walmsley
0 siblings, 0 replies; 46+ messages in thread
From: Paul Walmsley @ 2012-10-22 17:17 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: OMAP baseline test results for v3.7-rc2
2012-10-22 17:17 ` Paul Walmsley
@ 2012-10-22 17:18 ` Paul Walmsley
-1 siblings, 0 replies; 46+ messages in thread
From: Paul Walmsley @ 2012-10-22 17:18 UTC (permalink / raw)
To: Jon Hunter; +Cc: linux-omap, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: OMAP baseline test results for v3.7-rc2
2012-10-20 21:26 ` Paul Walmsley
@ 2012-10-22 16:28 ` Jon Hunter
-1 siblings, 0 replies; 46+ messages in thread
From: Jon Hunter @ 2012-10-22 16:28 UTC (permalink / raw)
To: Paul Walmsley; +Cc: linux-omap, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* OMAP baseline test results for v3.7-rc2
@ 2012-10-22 16:28 ` Jon Hunter
0 siblings, 0 replies; 46+ messages in thread
From: Jon Hunter @ 2012-10-22 16:28 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: OMAP baseline test results for v3.7-rc2
2012-10-22 16:28 ` Jon Hunter
@ 2012-10-22 16:38 ` Tony Lindgren
-1 siblings, 0 replies; 46+ messages in thread
From: Tony Lindgren @ 2012-10-22 16:38 UTC (permalink / raw)
To: Jon Hunter; +Cc: Paul Walmsley, linux-omap, linux-arm-kernel
* 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
^ permalink raw reply [flat|nested] 46+ messages in thread
* OMAP baseline test results for v3.7-rc2
@ 2012-10-22 16:38 ` Tony Lindgren
0 siblings, 0 replies; 46+ messages in thread
From: Tony Lindgren @ 2012-10-22 16:38 UTC (permalink / raw)
To: linux-arm-kernel
* 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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: OMAP baseline test results for v3.7-rc2
2012-10-22 16:38 ` Tony Lindgren
@ 2012-10-23 19:34 ` Paul Walmsley
-1 siblings, 0 replies; 46+ messages in thread
From: Paul Walmsley @ 2012-10-23 19:34 UTC (permalink / raw)
To: Tony Lindgren; +Cc: Jon Hunter, linux-omap, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: OMAP baseline test results for v3.7-rc2
2012-10-22 16:28 ` Jon Hunter
@ 2012-10-22 18:35 ` Paul Walmsley
-1 siblings, 0 replies; 46+ messages in thread
From: Paul Walmsley @ 2012-10-22 18:35 UTC (permalink / raw)
To: Jon Hunter; +Cc: linux-omap, linux-arm-kernel
(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
^ permalink raw reply [flat|nested] 46+ messages in thread
* OMAP baseline test results for v3.7-rc2
@ 2012-10-22 18:35 ` Paul Walmsley
0 siblings, 0 replies; 46+ messages in thread
From: Paul Walmsley @ 2012-10-22 18:35 UTC (permalink / raw)
To: linux-arm-kernel
(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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: OMAP baseline test results for v3.7-rc2
2012-10-22 18:35 ` Paul Walmsley
@ 2012-10-22 18:36 ` Paul Walmsley
-1 siblings, 0 replies; 46+ messages in thread
From: Paul Walmsley @ 2012-10-22 18:36 UTC (permalink / raw)
To: Jon Hunter; +Cc: linux-omap, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* OMAP baseline test results for v3.7-rc2
@ 2012-10-22 18:36 ` Paul Walmsley
0 siblings, 0 replies; 46+ messages in thread
From: Paul Walmsley @ 2012-10-22 18:36 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: OMAP baseline test results for v3.7-rc2
2012-10-22 18:36 ` Paul Walmsley
@ 2012-10-22 18:50 ` Jon Hunter
-1 siblings, 0 replies; 46+ messages in thread
From: Jon Hunter @ 2012-10-22 18:50 UTC (permalink / raw)
To: Paul Walmsley; +Cc: linux-omap, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* OMAP baseline test results for v3.7-rc2
@ 2012-10-22 18:50 ` Jon Hunter
0 siblings, 0 replies; 46+ messages in thread
From: Jon Hunter @ 2012-10-22 18:50 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: OMAP baseline test results for v3.7-rc2
2012-10-22 18:35 ` Paul Walmsley
@ 2012-10-22 18:48 ` Jon Hunter
-1 siblings, 0 replies; 46+ messages in thread
From: Jon Hunter @ 2012-10-22 18:48 UTC (permalink / raw)
To: Paul Walmsley; +Cc: linux-omap, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* OMAP baseline test results for v3.7-rc2
@ 2012-10-22 18:48 ` Jon Hunter
0 siblings, 0 replies; 46+ messages in thread
From: Jon Hunter @ 2012-10-22 18:48 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: OMAP baseline test results for v3.7-rc2
2012-10-22 18:48 ` Jon Hunter
@ 2012-10-23 1:53 ` Matt Porter
-1 siblings, 0 replies; 46+ messages in thread
From: Matt Porter @ 2012-10-23 1:53 UTC (permalink / raw)
To: Jon Hunter; +Cc: Paul Walmsley, linux-omap, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* OMAP baseline test results for v3.7-rc2
@ 2012-10-23 1:53 ` Matt Porter
0 siblings, 0 replies; 46+ messages in thread
From: Matt Porter @ 2012-10-23 1:53 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: OMAP baseline test results for v3.7-rc2
2012-10-23 1:53 ` Matt Porter
@ 2012-10-23 3:15 ` Paul Walmsley
-1 siblings, 0 replies; 46+ messages in thread
From: Paul Walmsley @ 2012-10-23 3:15 UTC (permalink / raw)
To: Matt Porter; +Cc: Jon Hunter, linux-omap, khilman, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* OMAP baseline test results for v3.7-rc2
@ 2012-10-23 3:15 ` Paul Walmsley
0 siblings, 0 replies; 46+ messages in thread
From: Paul Walmsley @ 2012-10-23 3:15 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: OMAP baseline test results for v3.7-rc2
2012-10-23 3:15 ` Paul Walmsley
@ 2012-10-23 4:57 ` Paul Walmsley
-1 siblings, 0 replies; 46+ messages in thread
From: Paul Walmsley @ 2012-10-23 4:57 UTC (permalink / raw)
To: Matt Porter; +Cc: Jon Hunter, linux-omap, khilman, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: OMAP baseline test results for v3.7-rc2
2012-10-23 3:15 ` Paul Walmsley
@ 2012-10-23 12:24 ` Matt Porter
-1 siblings, 0 replies; 46+ messages in thread
From: Matt Porter @ 2012-10-23 12:24 UTC (permalink / raw)
To: Paul Walmsley; +Cc: Jon Hunter, linux-omap, khilman, linux-arm-kernel
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#
^ permalink raw reply [flat|nested] 46+ messages in thread
* OMAP baseline test results for v3.7-rc2
@ 2012-10-23 12:24 ` Matt Porter
0 siblings, 0 replies; 46+ messages in thread
From: Matt Porter @ 2012-10-23 12:24 UTC (permalink / raw)
To: linux-arm-kernel
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#
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: OMAP baseline test results for v3.7-rc2
2012-10-23 12:24 ` Matt Porter
@ 2012-10-23 13:11 ` Matt Porter
-1 siblings, 0 replies; 46+ messages in thread
From: Matt Porter @ 2012-10-23 13:11 UTC (permalink / raw)
To: Paul Walmsley; +Cc: khilman, linux-omap, Jon Hunter, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* OMAP baseline test results for v3.7-rc2
@ 2012-10-23 13:11 ` Matt Porter
0 siblings, 0 replies; 46+ messages in thread
From: Matt Porter @ 2012-10-23 13:11 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: OMAP baseline test results for v3.7-rc2
2012-10-23 13:11 ` Matt Porter
@ 2012-10-23 21:03 ` Kevin Hilman
-1 siblings, 0 replies; 46+ messages in thread
From: Kevin Hilman @ 2012-10-23 21:03 UTC (permalink / raw)
To: Matt Porter; +Cc: Paul Walmsley, Jon Hunter, linux-omap, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* OMAP baseline test results for v3.7-rc2
@ 2012-10-23 21:03 ` Kevin Hilman
0 siblings, 0 replies; 46+ messages in thread
From: Kevin Hilman @ 2012-10-23 21:03 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: OMAP baseline test results for v3.7-rc2
2012-10-23 21:03 ` Kevin Hilman
@ 2012-10-23 21:11 ` Matt Porter
-1 siblings, 0 replies; 46+ messages in thread
From: Matt Porter @ 2012-10-23 21:11 UTC (permalink / raw)
To: Kevin Hilman; +Cc: Paul Walmsley, Jon Hunter, linux-omap, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* OMAP baseline test results for v3.7-rc2
@ 2012-10-23 21:11 ` Matt Porter
0 siblings, 0 replies; 46+ messages in thread
From: Matt Porter @ 2012-10-23 21:11 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: OMAP baseline test results for v3.7-rc2
2012-10-23 21:11 ` Matt Porter
@ 2012-10-25 14:14 ` Kevin Hilman
-1 siblings, 0 replies; 46+ messages in thread
From: Kevin Hilman @ 2012-10-25 14:14 UTC (permalink / raw)
To: Matt Porter; +Cc: Paul Walmsley, Jon Hunter, linux-omap, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* OMAP baseline test results for v3.7-rc2
@ 2012-10-25 14:14 ` Kevin Hilman
0 siblings, 0 replies; 46+ messages in thread
From: Kevin Hilman @ 2012-10-25 14:14 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: OMAP baseline test results for v3.7-rc2
2012-10-20 21:26 ` Paul Walmsley
@ 2012-10-23 1:04 ` Kevin Hilman
-1 siblings, 0 replies; 46+ messages in thread
From: Kevin Hilman @ 2012-10-23 1:04 UTC (permalink / raw)
To: Paul Walmsley, grinberg; +Cc: linux-omap, linux-arm-kernel
+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();
^ permalink raw reply related [flat|nested] 46+ messages in thread
* OMAP baseline test results for v3.7-rc2
@ 2012-10-23 1:04 ` Kevin Hilman
0 siblings, 0 replies; 46+ messages in thread
From: Kevin Hilman @ 2012-10-23 1:04 UTC (permalink / raw)
To: linux-arm-kernel
+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();
^ permalink raw reply related [flat|nested] 46+ messages in thread
* Re: OMAP baseline test results for v3.7-rc2
2012-10-23 1:04 ` Kevin Hilman
@ 2012-10-23 18:19 ` Kevin Hilman
-1 siblings, 0 replies; 46+ messages in thread
From: Kevin Hilman @ 2012-10-23 18:19 UTC (permalink / raw)
To: Paul Walmsley; +Cc: grinberg, linux-omap, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 46+ messages in thread* OMAP baseline test results for v3.7-rc2
@ 2012-10-23 18:19 ` Kevin Hilman
0 siblings, 0 replies; 46+ messages in thread
From: Kevin Hilman @ 2012-10-23 18:19 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 46+ messages in thread* Re: OMAP baseline test results for v3.7-rc2
2012-10-23 18:19 ` Kevin Hilman
@ 2012-10-24 9:01 ` Igor Grinberg
-1 siblings, 0 replies; 46+ messages in thread
From: Igor Grinberg @ 2012-10-24 9:01 UTC (permalink / raw)
To: Kevin Hilman; +Cc: Paul Walmsley, linux-omap, linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 46+ messages in thread
* OMAP baseline test results for v3.7-rc2
@ 2012-10-24 9:01 ` Igor Grinberg
0 siblings, 0 replies; 46+ messages in thread
From: Igor Grinberg @ 2012-10-24 9:01 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 46+ messages in thread