OMAP baseline test results for v3.10-rc6

OMAP baseline test results for v3.10-rc6

[Paul Walmsley]

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

    http://www.pwsan.com/omap/testlogs/test_v3.10-rc6/20130616211951/


Test summary
------------

Build: uImage:
    Pass (16/16): am33xx_only, n800_multi_omap2xxx, n800_only_a,
                  omap1_defconfig, omap1_defconfig_1510innovator_only, 
                  omap1_defconfig_5912osk_only, omap2plus_defconfig, 
                  omap2plus_defconfig_2430sdp_only
                  omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, 
                  omap2plus_defconfig_omap2_4_only, 
                  omap2plus_defconfig_omap3_4_only, 
                  rmk_omap3430_ldp_allnoconfig, 
                  rmk_omap3430_ldp_oldconfig, 
                  rmk_omap4430_sdp_allnoconfig, 
                  rmk_omap4430_sdp_oldconfig

Build: zImage:
    Pass ( 1/ 1): omap2plus_defconfig

Boot to userspace:
    FAIL ( 3/12): 37xxevm, am335xbone, am335xbonelt
    Pass ( 9/12): 2420n800, 2430sdp, 3517evm, 3530es3beagle,
                  3730beaglexm, 4430es2panda, 4460pandaes, 5912osk,
                  cmt3517

PM: chip retention via suspend:
    FAIL ( 3/ 6): 2430sdp, 37xxevm, 4430es2panda
    Pass ( 3/ 6): 3530es3beagle, 3730beaglexm, 4460pandaes

PM: chip retention via dynamic idle:
    FAIL ( 4/ 6): 2430sdp, 37xxevm, 4430es2panda, 4460pandaes
    Pass ( 2/ 6): 3530es3beagle, 3730beaglexm

PM: chip off except CORE via suspend:
    Pass ( 1/ 1): 3730beaglexm

PM: chip off except CORE via dynamic idle:
    Pass ( 1/ 1): 3730beaglexm

PM: chip off via suspend:
    FAIL ( 3/ 4): 37xxevm, 4430es2panda, 4460pandaes
    Pass ( 1/ 4): 3530es3beagle

PM: chip off via dynamic idle:
    FAIL ( 3/ 4): 37xxevm, 4430es2panda, 4460pandaes
    Pass ( 1/ 4): 3530es3beagle



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

* 37xx EVM: boot fails
  - as of v3.10-rc1
  - Fixed by http://marc.info/?l=linux-arm-kernel&m=137112093431021&w=2
  
* 2430SDP, 3730 Beagle XM, 3530 Beagle, 3517EVM, CM-T3517: {dmic,mcpdm} lookup failure
  - Cause unknown
  - These IP blocks don't exist on OMAP3xxx/AM35xx chips
  - Fixed by http://marc.info/?l=linux-omap&m=137093955903130&w=2


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

Boot tests:

* 3517EVM & CM-T3517: boot hangs with NFS root
  - Likely some Kconfig, board file, and PM issues with EMAC
  - Longstanding bug
  - Not currently part of the automated test suite

Boot warnings:

* 2420N800, 2430sdp: failed to get counter_32k resource
  - "omap2_sync32k_clocksource_init: failed to get counter_32k resource"
  - Cause unknown

* 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

* 3730 Beagle XM, 3517EVM, CM-T3517: uart4_rx.uart4_rx mux failure
  - Cause unknown
  - May be related to the OMAP serial driver and/or DT mux data
  - http://marc.info/?l=linux-arm-kernel&m=137121357528854&w=2

PM tests:

* 2430sdp: power domains not entering retention
  - Cause unknown

* 3730 Beagle XM: does not serial wake from off-idle suspend when console
  UART doesn't clock-gate ("debug ignore_loglevel")
  - Cause unknown
  - Not yet part of the automated test suite
  - Re-tested at v3.7; still failing:
    http://www.pwsan.com/omap/transcripts/20121211-3730beaglexm-3.7-pm-offmode-fail-debug.txt

* 4430es2panda: pwrdm state mismatch on CAM, DSS

* 4430es2panda: CORE, TESLA, IVAHD, L3INIT didn't enter target state
  - Probably due to lack of reset code for M3, DSP, SL2IF, FSUSB
    per discussion with Tero Kristo
  - Likely dependent on the bootloader version
    - fails with 2012.07-00136-g755de79
  - http://marc.info/?l=linux-arm-kernel&m=136432340618226&w=2

* 4430es2panda: MPU, ABE didn't enter target state
  - New for v3.10-rc

* 4460pandaes: pwrdm state mismatch on DSS, ABE, IVAHD, TESLA

* 4460pandaes: chip not entering retention in dynamic idle
  - Presumably 4430es2panda also fails this
  - Suspend-to-RAM enters full chip retention

Other:

* 4430es2panda: omap_hwmod: l3_instr: _wait_target_disable failed
  - Unknown cause; could be due to the lack of hierarchical enable/disable
    in hwmod code
  - Jon Hunter and Santosh Shilimkar report this does not appear with
    the same X-loader/bootloader on his 4430ES2.3 Panda, so could be
    ES-level dependent


Failing tests: reported by others 
---------------------------------

- RTC wakeup from suspend broken on 3730beaglexm
  - as of v3.10-rc1
  - discussion here: http://marc.info/?l=linux-omap&m=136915841625434&w=2


vmlinux object size
(delta in bytes from test_v3.10-rc5 
(317ddd256b9c24b0d78fa8018f80f1e495481a10)):
   text     data      bss    total  kernel
   +673      +56        0     +729  am33xx_only
   +444       +8        0     +452  n800_multi_omap2xxx
   +412       +8        0     +420  n800_only_a
   +808      +32        0     +840  omap1_defconfig
   +776      +24        0     +800  omap1_defconfig_1510innovator_only
   +808      +64        0     +872  omap1_defconfig_5912osk_only
   +537      +56        0     +593  omap2plus_defconfig
   +768      -24        0     +744  omap2plus_defconfig_2430sdp_only
   +537      +56        0     +593  omap2plus_defconfig_cpupm
   +613       -8        0     +605  omap2plus_defconfig_no_pm
   +545      -24        0     +521  omap2plus_defconfig_omap2_4_only
   +537      +56        0     +593  omap2plus_defconfig_omap3_4_only
   +440       -8      -64     +368  rmk_omap3430_ldp_allnoconfig
   +476      +72        0     +548  rmk_omap3430_ldp_oldconfig
   +440       -8      -64     +368  rmk_omap4430_sdp_allnoconfig
   +665     +168        0     +833  rmk_omap4430_sdp_oldconfig


Boot-time memory difference
(delta in bytes from test_v3.10-rc5 
(317ddd256b9c24b0d78fa8018f80f1e495481a10))
  avail  rsrvd   high  freed  board          kconfig
    -8k     8k      .      .  2420n800       n800_only_a

OMAP baseline test results for v3.10-rc6

[Felipe Balbi]

Hi,

On Mon, Jun 17, 2013 at 05:23:17AM +0000, Paul Walmsley wrote:
> Boot to userspace:
>     FAIL ( 3/12): 37xxevm, am335xbone, am335xbonelt

Paul, we have at least 2 different folks who can't reproduce your bone
and bone black boot to userspace failures. I wonder how you're trying to
boot them.

Care to share your test scripts ?

Also, if you could share the entire thing, we will add your scripts to
our nightly tests as to try and avoid future regressions.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130625/f6887588/attachment.sig>

OMAP baseline test results for v3.10-rc6

[Paul Walmsley]

+ Vaibhav and Kevin

Hi,

On Tue, 25 Jun 2013, Felipe Balbi wrote:

> On Mon, Jun 17, 2013 at 05:23:17AM +0000, Paul Walmsley wrote:
> > Boot to userspace:
> >     FAIL ( 3/12): 37xxevm, am335xbone, am335xbonelt
> 
> Paul, we have at least 2 different folks who can't reproduce your bone
> and bone black boot to userspace failures. I wonder how you're trying to
> boot them.
> 
> Care to share your test scripts ?

Sure... the methodology is completely open and has been posted in the 
online logs since the first test cycle.  (For some reason, almost no one 
clicks through the test directory trees that I post online.  Is this a 
documentation issue?  What can we do to make it easier for people to 
explore this?)

Anyway, for BeagleBone white, here's the last working test log, from 3.7:

http://www.pwsan.com/omap/testlogs/test_v3.7/20121211094536/boot/am335xbone/am335xbone_log.txt

The concatenated kernel and DTB, along with the Kconfig used to build, are
here:

http://www.pwsan.com/omap/testlogs/test_v3.7/20121211094536/build/am33xx_only/

The boot broke immediately afterwards with v3.8-rc1 and has never worked 
since:

http://www.pwsan.com/omap/testlogs/test_v3.8-rc1/20121228031713/boot/am335xbone/

You can find all of the archived testlogs here:

http://www.pwsan.com/omap/testlogs/

You'll probably only be interested in the ones that start with "test_v3.".

...

As for BeagleBone Black, here's the latest non-booting log:

http://www.pwsan.com/omap/testlogs/test_v3.10-rc6/20130616211951/boot/am335xbonelt/am335x-bone/am335xbonelt_log.txt

This has never booted on mainline for me.  The closest I got was with the 
ti-linux-3.8.y tree on Vaibhav's github account, which booted with 
the 'am335x-boneblack.dtb' built from the same tree.  Mainline didn't boot 
with either the am335x-bone.dtb or Vaibhav's am335x-boneblack.dtb, but 
since it booted on 3.8.y with am335x-boneblack.dtb, I've kept that 
around for the mainline boot tests (as you can see from the logs).

There's nothing exotic about the kernel used here, it's a pure 
omap2plus_defconfig zImage.

The bootloader and DTB used are here (booted via serial from the boot 
ROM):

http://www.pwsan.com/tmp/boneblack-20130625/

Please let me know if you need more binaries shared from the test runs!

...

Am certainly open to the idea that there's something wrong with the way 
that I'm booting either of these.  But AFAIK no one's been able to 
identify exactly what it could be.  I haven't had the time recently to 
spend hours going through the various permutations, given all the other 
breakage :-(  BeagleBone-white has the additional complication that it is 
not easy to automate, due to the way that power is delivered to the board, 
so there is an extra dimension of difficulty there.

> Also, if you could share the entire thing, we will add your scripts to
> our nightly tests as to try and avoid future regressions.

It would be great to have TI folks running those tests, or something 
similar to them!  An early version of the test system has been shared with 
a handful of folks, but it needs to be cleaned up further before broader 
release.


- Paul

OMAP baseline test results for v3.10-rc6

[Tom Rini]

On 06/25/2013 02:20 PM, Paul Walmsley wrote:
> + Vaibhav and Kevin
> 
> Hi,
> 
> On Tue, 25 Jun 2013, Felipe Balbi wrote:
> 
>> On Mon, Jun 17, 2013 at 05:23:17AM +0000, Paul Walmsley wrote:
>>> Boot to userspace:
>>>     FAIL ( 3/12): 37xxevm, am335xbone, am335xbonelt
>>
>> Paul, we have at least 2 different folks who can't reproduce your bone
>> and bone black boot to userspace failures. I wonder how you're trying to
>> boot them.
>>
>> Care to share your test scripts ?
> 
> Sure... the methodology is completely open and has been posted in the 
> online logs since the first test cycle.  (For some reason, almost no one 
> clicks through the test directory trees that I post online.  Is this a 
> documentation issue?  What can we do to make it easier for people to 
> explore this?)

Well, another link never hurts the search results :)

[snip]
> Am certainly open to the idea that there's something wrong with the way 
> that I'm booting either of these.  But AFAIK no one's been able to 
> identify exactly what it could be.  I haven't had the time recently to 
> spend hours going through the various permutations, given all the other 
> breakage :-(  BeagleBone-white has the additional complication that it is 
> not easy to automate, due to the way that power is delivered to the board, 
> so there is an extra dimension of difficulty there.

Ah-ha, I reproduced your failure.  If I make up a concat uImage + DTB,
rather than pass them separately, it fails to boot.  If you switch to
mainline U-Boot (v2012.10 or later) you get support for separate image +
dtb (v2013.04 gives you bootz and zImage support).  v2013.04 will also
work out of the box for BeagleBone-Black.

And yeah, I feel your pain about power cycling BeagleBone-White.  The QA
folks here sent me one of the relay controllers they use, and I think
Felipe is partial to one from phidgets.

>> Also, if you could share the entire thing, we will add your scripts to
>> our nightly tests as to try and avoid future regressions.
> 
> It would be great to have TI folks running those tests, or something 
> similar to them!  An early version of the test system has been shared with 
> a handful of folks, but it needs to be cleaned up further before broader 
> release.

We've got "something similar", at least wrt boot tests.  But since we
use separate kernel + DT, we hadn't seen this problem.

-- 
Tom

OMAP baseline test results for v3.10-rc6

[Kevin Hilman]

Tom Rini <trini@ti.com> writes:

> On 06/25/2013 02:20 PM, Paul Walmsley wrote:
>> + Vaibhav and Kevin
>> 
>> Hi,
>> 
>> On Tue, 25 Jun 2013, Felipe Balbi wrote:
>> 
>>> On Mon, Jun 17, 2013 at 05:23:17AM +0000, Paul Walmsley wrote:
>>>> Boot to userspace:
>>>>     FAIL ( 3/12): 37xxevm, am335xbone, am335xbonelt
>>>
>>> Paul, we have at least 2 different folks who can't reproduce your bone
>>> and bone black boot to userspace failures. I wonder how you're trying to
>>> boot them.
>>>
>>> Care to share your test scripts ?
>> 
>> Sure... the methodology is completely open and has been posted in the 
>> online logs since the first test cycle.  (For some reason, almost no one 
>> clicks through the test directory trees that I post online.  Is this a 
>> documentation issue?  What can we do to make it easier for people to 
>> explore this?)
>
> Well, another link never hurts the search results :)
>
> [snip]
>> Am certainly open to the idea that there's something wrong with the way 
>> that I'm booting either of these.  But AFAIK no one's been able to 
>> identify exactly what it could be.  I haven't had the time recently to 
>> spend hours going through the various permutations, given all the other 
>> breakage :-(  BeagleBone-white has the additional complication that it is 
>> not easy to automate, due to the way that power is delivered to the board, 
>> so there is an extra dimension of difficulty there.
>
> Ah-ha, I reproduced your failure.  If I make up a concat uImage + DTB,
> rather than pass them separately, it fails to boot.  If you switch to
> mainline U-Boot (v2012.10 or later) you get support for separate image +
> dtb (v2013.04 gives you bootz and zImage support).  v2013.04 will also
> work out of the box for BeagleBone-Black.

Just to confirm, my problems with mainline were with appended DTB also.
Separate DTB and zImage work fine (at least using u-boot v2013.04.)

That being said, appended DTB should still work, so there's a bug hiding
someplace that needs to be found fixed.

Can you guys update your tests to test appended DTB also?

Kevin

OMAP baseline test results for v3.10-rc6

[Tom Rini]

On 06/25/2013 03:57 PM, Kevin Hilman wrote:
> Tom Rini <trini@ti.com> writes:
> 
>> On 06/25/2013 02:20 PM, Paul Walmsley wrote:
>>> + Vaibhav and Kevin
>>>
>>> Hi,
>>>
>>> On Tue, 25 Jun 2013, Felipe Balbi wrote:
>>>
>>>> On Mon, Jun 17, 2013 at 05:23:17AM +0000, Paul Walmsley wrote:
>>>>> Boot to userspace:
>>>>>     FAIL ( 3/12): 37xxevm, am335xbone, am335xbonelt
>>>>
>>>> Paul, we have at least 2 different folks who can't reproduce your bone
>>>> and bone black boot to userspace failures. I wonder how you're trying to
>>>> boot them.
>>>>
>>>> Care to share your test scripts ?
>>>
>>> Sure... the methodology is completely open and has been posted in the 
>>> online logs since the first test cycle.  (For some reason, almost no one 
>>> clicks through the test directory trees that I post online.  Is this a 
>>> documentation issue?  What can we do to make it easier for people to 
>>> explore this?)
>>
>> Well, another link never hurts the search results :)
>>
>> [snip]
>>> Am certainly open to the idea that there's something wrong with the way 
>>> that I'm booting either of these.  But AFAIK no one's been able to 
>>> identify exactly what it could be.  I haven't had the time recently to 
>>> spend hours going through the various permutations, given all the other 
>>> breakage :-(  BeagleBone-white has the additional complication that it is 
>>> not easy to automate, due to the way that power is delivered to the board, 
>>> so there is an extra dimension of difficulty there.
>>
>> Ah-ha, I reproduced your failure.  If I make up a concat uImage + DTB,
>> rather than pass them separately, it fails to boot.  If you switch to
>> mainline U-Boot (v2012.10 or later) you get support for separate image +
>> dtb (v2013.04 gives you bootz and zImage support).  v2013.04 will also
>> work out of the box for BeagleBone-Black.
> 
> Just to confirm, my problems with mainline were with appended DTB also.
> Separate DTB and zImage work fine (at least using u-boot v2013.04.)
> 
> That being said, appended DTB should still work, so there's a bug hiding
> someplace that needs to be found fixed.

Since we've narrowed down what the problem is, someone can bisect it
now, yeah.

> Can you guys update your tests to test appended DTB also?

What is the official position on appending DTBs?

-- 
Tom

OMAP baseline test results for v3.10-rc6

[Russell King - ARM Linux]

On Tue, Jun 25, 2013 at 04:22:29PM -0400, Tom Rini wrote:
> On 06/25/2013 03:57 PM, Kevin Hilman wrote:
> > Just to confirm, my problems with mainline were with appended DTB also.
> > Separate DTB and zImage work fine (at least using u-boot v2013.04.)
> > 
> > That being said, appended DTB should still work, so there's a bug hiding
> > someplace that needs to be found fixed.
> 
> Since we've narrowed down what the problem is, someone can bisect it
> now, yeah.
> 
> > Can you guys update your tests to test appended DTB also?
> 
> What is the official position on appending DTBs?

If a platform goes from being able to boot without a DTB to requiring
a DTB, we must continue to support booting on that platform in some
manner otherwise it is a regression.

And no, I don't term upgrading uboot as an acceptable regression fix.
So if appended DTB doesn't work, that needs fixing before the non-DTB
support for a platform is removed, otherwise we _will_ have a regression.

OMAP baseline test results for v3.10-rc6

[Tom Rini]

On 06/26/2013 05:15 AM, Russell King - ARM Linux wrote:
> On Tue, Jun 25, 2013 at 04:22:29PM -0400, Tom Rini wrote:
>> On 06/25/2013 03:57 PM, Kevin Hilman wrote:
>>> Just to confirm, my problems with mainline were with appended DTB also.
>>> Separate DTB and zImage work fine (at least using u-boot v2013.04.)
>>>
>>> That being said, appended DTB should still work, so there's a bug hiding
>>> someplace that needs to be found fixed.
>>
>> Since we've narrowed down what the problem is, someone can bisect it
>> now, yeah.
>>
>>> Can you guys update your tests to test appended DTB also?
>>
>> What is the official position on appending DTBs?
> 
> If a platform goes from being able to boot without a DTB to requiring
> a DTB, we must continue to support booting on that platform in some
> manner otherwise it is a regression.
> 
> And no, I don't term upgrading uboot as an acceptable regression fix.
> So if appended DTB doesn't work, that needs fixing before the non-DTB
> support for a platform is removed, otherwise we _will_ have a regression.

am335x never had a board file in mainline, so it's always required a DTB.

Now, I assume you're still saying that whatever software, except for the
kernel of course, shipped on the SD card, has to be supported for
forever by the kernel, right?

-- 
Tom

OMAP baseline test results for v3.10-rc6

[Hiremath, Vaibhav]

> -----Original Message-----
> From: linux-arm-kernel [mailto:linux-arm-kernel-
> bounces at lists.infradead.org] On Behalf Of Kevin Hilman
> Sent: Wednesday, June 26, 2013 1:28 AM
> To: Rini, Tom
> Cc: Paul Walmsley; linux-omap at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; Balbi, Felipe; Hiremath, Vaibhav
> Subject: Re: OMAP baseline test results for v3.10-rc6
> 
> Tom Rini <trini@ti.com> writes:
> 
> > On 06/25/2013 02:20 PM, Paul Walmsley wrote:
> >> + Vaibhav and Kevin
> >>
> >> Hi,
> >>
> >> On Tue, 25 Jun 2013, Felipe Balbi wrote:
> >>
> >>> On Mon, Jun 17, 2013 at 05:23:17AM +0000, Paul Walmsley wrote:
> >>>> Boot to userspace:
> >>>>     FAIL ( 3/12): 37xxevm, am335xbone, am335xbonelt
> >>>
> >>> Paul, we have at least 2 different folks who can't reproduce your
> bone
> >>> and bone black boot to userspace failures. I wonder how you're
> trying to
> >>> boot them.
> >>>
> >>> Care to share your test scripts ?
> >>
> >> Sure... the methodology is completely open and has been posted in
> the
> >> online logs since the first test cycle.  (For some reason, almost no
> one
> >> clicks through the test directory trees that I post online.  Is this
> a
> >> documentation issue?  What can we do to make it easier for people to
> >> explore this?)
> >
> > Well, another link never hurts the search results :)
> >
> > [snip]
> >> Am certainly open to the idea that there's something wrong with the
> way
> >> that I'm booting either of these.  But AFAIK no one's been able to
> >> identify exactly what it could be.  I haven't had the time recently
> to
> >> spend hours going through the various permutations, given all the
> other
> >> breakage :-(  BeagleBone-white has the additional complication that
> it is
> >> not easy to automate, due to the way that power is delivered to the
> board,
> >> so there is an extra dimension of difficulty there.
> >
> > Ah-ha, I reproduced your failure.  If I make up a concat uImage +
> DTB,
> > rather than pass them separately, it fails to boot.  If you switch to
> > mainline U-Boot (v2012.10 or later) you get support for separate
> image +
> > dtb (v2013.04 gives you bootz and zImage support).  v2013.04 will
> also
> > work out of the box for BeagleBone-Black.
> 
> Just to confirm, my problems with mainline were with appended DTB also.
> Separate DTB and zImage work fine (at least using u-boot v2013.04.)
> 
> That being said, appended DTB should still work, so there's a bug
> hiding
> someplace that needs to be found fixed.
> 
> Can you guys update your tests to test appended DTB also?
> 

What is missing here is, 

CONFIG_ARM_APPENDED_DTB = y
CONFIG_ARM_ATAG_DTB_COMPAT = y


And for the code which is required in case of appended DTB, please refer to the code
"arch/arm/boot/compressed/head.S"


Please __NOTE__ that these options are not enabled in default omap2plus_defconfig.


Thanks,
Vaibhav

OMAP baseline test results for v3.10-rc6

[Rajendra Nayak]

>>
>> Just to confirm, my problems with mainline were with appended DTB also.
>> Separate DTB and zImage work fine (at least using u-boot v2013.04.)
>>
>> That being said, appended DTB should still work, so there's a bug
>> hiding
>> someplace that needs to be found fixed.
>>
>> Can you guys update your tests to test appended DTB also?
>>
> 
> What is missing here is, 
> 
> CONFIG_ARM_APPENDED_DTB = y
> CONFIG_ARM_ATAG_DTB_COMPAT = y
> 
> 
> And for the code which is required in case of appended DTB, please refer to the code
> "arch/arm/boot/compressed/head.S"
> 
> 
> Please __NOTE__ that these options are not enabled in default omap2plus_defconfig.

Paul/Kevin,

Apart from confirming if you are manually enabling these options, can you also give some
details on how you append the dtb to the kernel image?

Most of us use an out-of-tree patch from Grant to do this, which I have shared below [2]

Even without the patch with the below commands [1] to append the dtb, it still works, so it
would be good to know what steps you follow to append the dtb to the kernel image.

regards,
Rajendra

[1]
cat arch/arm/boot/zImage arch/arm/boot/dts/am335x-bone.dtb > zImage
mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n "Linux" -d zImage uImage 

[2]
From: Grant Likely <grant.likely@secretlab.ca>
Date: Tue, 24 Apr 2012 16:19:29 +0530
Subject: Makefile: Build a uImage with dtb already appended

Do not commit to mainline; this is a useful hack only for now.

Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
 arch/arm/Makefile      |    2 ++
 arch/arm/boot/Makefile |    7 +++++++
 2 files changed, 9 insertions(+)

Index: linux-2.6/arch/arm/Makefile
===================================================================
--- linux-2.6.orig/arch/arm/Makefile    2013-04-24 12:25:22.547990009 +0530
+++ linux-2.6/arch/arm/Makefile 2013-04-26 14:30:57.143150733 +0530
@@ -295,6 +295,8 @@

 %.dtb: scripts
        $(Q)$(MAKE) $(build)=$(boot)/dts MACHINE=$(MACHINE) $(boot)/dts/$@
+uImage.%: uImage
+       $(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $(boot)/$@

 dtbs: scripts
        $(Q)$(MAKE) $(build)=$(boot)/dts MACHINE=$(MACHINE) dtbs
Index: linux-2.6/arch/arm/boot/Makefile
===================================================================
--- linux-2.6.orig/arch/arm/boot/Makefile       2013-04-24 12:25:22.547990009 +0530
+++ linux-2.6/arch/arm/boot/Makefile    2013-04-26 14:30:57.151150508 +0530
@@ -55,6 +55,9 @@
        $(call if_changed,objcopy)
        @$(kecho) '  Kernel: $@ is ready'

+$(obj)/zImage-dtb.%:   $(obj)/dts/%.dtb $(obj)/zImage
+       cat $(obj)/zImage $< > $@
+
 endif

 ifneq ($(LOADADDR),)
@@ -80,6 +83,10 @@
        $(call if_changed,uimage)
        @$(kecho) '  Image $@ is ready'

+$(obj)/uImage.%:       $(obj)/zImage-dtb.% FORCE
+       $(call if_changed,uimage)
+       @echo '  Image $@ is ready'
+
 $(obj)/bootp/bootp: $(obj)/zImage initrd FORCE
        $(Q)$(MAKE) $(build)=$(obj)/bootp $@
        @:

OMAP baseline test results for v3.10-rc6

[Tom Rini]

On 06/26/2013 09:22 AM, Rajendra Nayak wrote:
>>>
>>> Just to confirm, my problems with mainline were with appended DTB also.
>>> Separate DTB and zImage work fine (at least using u-boot v2013.04.)
>>>
>>> That being said, appended DTB should still work, so there's a bug
>>> hiding
>>> someplace that needs to be found fixed.
>>>
>>> Can you guys update your tests to test appended DTB also?
>>>
>>
>> What is missing here is, 
>>
>> CONFIG_ARM_APPENDED_DTB = y
>> CONFIG_ARM_ATAG_DTB_COMPAT = y
>>
>>
>> And for the code which is required in case of appended DTB, please refer to the code
>> "arch/arm/boot/compressed/head.S"
>>
>>
>> Please __NOTE__ that these options are not enabled in default omap2plus_defconfig.
> 
> Paul/Kevin,
> 
> Apart from confirming if you are manually enabling these options, can you also give some
> details on how you append the dtb to the kernel image?

Yes, please confirm that they're being set.  I've managed to reproduce
the failure, with them off, and enabling them brings things back to life.

Pending rmk's reply in another part of the thread, I'll submit a patch
to enable the above in omap2plus_defconfig.

-- 
Tom

OMAP baseline test results for v3.10-rc6

[Paul Walmsley]

On Wed, 26 Jun 2013, Tom Rini wrote:

> Yes, please confirm that they're being set.

For the Kconfig that I use to boot the BeagleBone-white, which is called 
"am33xx_only", yes, both of those are set.  

Here's the v3.8-rc1 version of this Kconfig as an example:

http://www.pwsan.com/omap/testlogs/test_v3.8-rc1/20121228031713/build/am33xx_only/am33xx_only


- Paul

OMAP baseline test results for v3.10-rc6

[Tom Rini]

On 06/26/2013 01:28 PM, Paul Walmsley wrote:
> On Wed, 26 Jun 2013, Tom Rini wrote:
> 
>> Yes, please confirm that they're being set.
> 
> For the Kconfig that I use to boot the BeagleBone-white, which is called 
> "am33xx_only", yes, both of those are set.  
> 
> Here's the v3.8-rc1 version of this Kconfig as an example:
> 
> http://www.pwsan.com/omap/testlogs/test_v3.8-rc1/20121228031713/build/am33xx_only/am33xx_only

OK, is there a reason to not be using omap2plus_defconfig?  My pass/fail
here is based on that config and enabling, or not, dtb append.  Seems
like it would be one less thing to maintain on your end and it would be
on TIs end (roughly speaking) to make sure our platforms that ought to
be working upstream have what they need enabled in the defconfig(s) in
question.

-- 
Tom

OMAP baseline test results for v3.10-rc6

[Paul Walmsley]

On Wed, 26 Jun 2013, Tom Rini wrote:

> OK, is there a reason to not be using omap2plus_defconfig?  My pass/fail
> here is based on that config and enabling, or not, dtb append.  Seems
> like it would be one less thing to maintain on your end and it would be
> on TIs end (roughly speaking) to make sure our platforms that ought to
> be working upstream have what they need enabled in the defconfig(s) in
> question.

That would be convenient for me, but part of the goal is to verify that a 
Kconfig that deselects all OMAPs other than AM33xx continues to work.

So the build process for am33xx_only here goes something like:

1. Start with omap2plus_defconfig

2. Turn off support for everything other than AM33xx in the SoC target 
selection menus

3. Turn on the appended DTB and compat ATAGs options

You might consider adding something like this to your pass/fail tests.


- Paul

OMAP baseline test results for v3.10-rc6

[Tom Rini]

On 06/26/2013 01:58 PM, Paul Walmsley wrote:
> On Wed, 26 Jun 2013, Tom Rini wrote:
> 
>> OK, is there a reason to not be using omap2plus_defconfig?  My pass/fail
>> here is based on that config and enabling, or not, dtb append.  Seems
>> like it would be one less thing to maintain on your end and it would be
>> on TIs end (roughly speaking) to make sure our platforms that ought to
>> be working upstream have what they need enabled in the defconfig(s) in
>> question.
> 
> That would be convenient for me, but part of the goal is to verify that a 
> Kconfig that deselects all OMAPs other than AM33xx continues to work.
> 
> So the build process for am33xx_only here goes something like:
> 
> 1. Start with omap2plus_defconfig
> 
> 2. Turn off support for everything other than AM33xx in the SoC target 
> selection menus
> 
> 3. Turn on the appended DTB and compat ATAGs options
> 
> You might consider adding something like this to your pass/fail tests.

Adding more and different build+boot tests is on the list.  I guess you
could automate this with a fraagment of everything am33xx must have to
boot+root and alldefconfig for the rest?

-- 
Tom

OMAP baseline test results for v3.10-rc6

[Kevin Hilman]

Tom Rini <trini@ti.com> writes:

> On 06/26/2013 01:58 PM, Paul Walmsley wrote:
>> On Wed, 26 Jun 2013, Tom Rini wrote:
>> 
>>> OK, is there a reason to not be using omap2plus_defconfig?  My pass/fail
>>> here is based on that config and enabling, or not, dtb append.  Seems
>>> like it would be one less thing to maintain on your end and it would be
>>> on TIs end (roughly speaking) to make sure our platforms that ought to
>>> be working upstream have what they need enabled in the defconfig(s) in
>>> question.
>> 
>> That would be convenient for me, but part of the goal is to verify that a 
>> Kconfig that deselects all OMAPs other than AM33xx continues to work.
>> 
>> So the build process for am33xx_only here goes something like:
>> 
>> 1. Start with omap2plus_defconfig
>> 
>> 2. Turn off support for everything other than AM33xx in the SoC target 
>> selection menus
>> 
>> 3. Turn on the appended DTB and compat ATAGs options
>> 
>> You might consider adding something like this to your pass/fail tests.
>
> Adding more and different build+boot tests is on the list.  I guess you
> could automate this with a fraagment of everything am33xx must have to
> boot+root and alldefconfig for the rest?

Since I recently discovered scripts/kconfig/merge_config.sh, I thought
I'd share a very convenient way of automating the variations on a
kconfig theme, just in case I'm not the last one to discover this useful
tool.

For example, I have the following in am335x_only.config:

  CONFIG_ARCH_OMAP2=n
  CONFIG_ARCH_OMAP3=n
  CONFIG_ARCH_OMAP4=n
  CONFIG_SOC_OMAP5=n
  CONFIG_SOC_AM33XX=y

Then I run:

  scripts/kconfig/merge_config.sh arch/arm/configs/omap2plus_defconfig /path/to/am335x_only.config

This gives me omap2plus_defconfig with overrides from my fragment.

Kevin

OMAP baseline test results for v3.10-rc6

[Paul Walmsley]

On Wed, 26 Jun 2013, Rajendra Nayak wrote:

> Apart from confirming if you are manually enabling these options, can you also give some
> details on how you append the dtb to the kernel image?
> 
> Most of us use an out-of-tree patch from Grant to do this, which I have shared below [2]
> 
> Even without the patch with the below commands [1] to append the dtb, it still works, so it
> would be good to know what steps you follow to append the dtb to the kernel image.

Here's how I do it:

ARCH=arm CROSS_COMPILE=${TOOLCHAIN_PATH}/bin/${TOOLCHAIN_PREFIX} nice make -j$CORES zImage am335x-bone.dtb

cat arch/arm/boot/zImage arch/arm/boot/am335x-bone.dtb > arch/arm/boot/zImage-dtb.am335x-bone

scripts/mkuboot.sh -A arm -O linux -C none  -T kernel -a 0x80008000 -e 0x80008000 -n 'Linux-' -d arch/arm/boot/zImage-dtb.am335x-bone arch/arm/boot/uImage-dtb.am335x-bone


- Paul

OMAP baseline test results for v3.10-rc6

[Lokesh Vutla]

Hi Paul,
On Wednesday 26 June 2013 10:56 PM, Paul Walmsley wrote:
> On Wed, 26 Jun 2013, Rajendra Nayak wrote:
>
>> Apart from confirming if you are manually enabling these options, can you also give some
>> details on how you append the dtb to the kernel image?
>>
>> Most of us use an out-of-tree patch from Grant to do this, which I have shared below [2]
>>
>> Even without the patch with the below commands [1] to append the dtb, it still works, so it
>> would be good to know what steps you follow to append the dtb to the kernel image.
>
> Here's how I do it:
>
> ARCH=arm CROSS_COMPILE=${TOOLCHAIN_PATH}/bin/${TOOLCHAIN_PREFIX} nice make -j$CORES zImage am335x-bone.dtb
>
> cat arch/arm/boot/zImage arch/arm/boot/am335x-bone.dtb > arch/arm/boot/zImage-dtb.am335x-bone
Here is the catch..
Your dtb is generated in arch/arm/boot/dts/ folder(before V3.8 dtb was 
generated in arch/arm/boot).
You are using very old dtb file. Please delete all your dtb files in 
arch/arm/boot/ folder and check once.
Here is the patch from Grant Likely which does that.
https://patchwork.kernel.org/patch/1813321/
Can you please give a try updating this ..:)

Thanks and regards,
Lokesh
>
> scripts/mkuboot.sh -A arm -O linux -C none  -T kernel -a 0x80008000 -e 0x80008000 -n 'Linux-' -d arch/arm/boot/zImage-dtb.am335x-bone arch/arm/boot/uImage-dtb.am335x-bone
>
>
> - Paul
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

OMAP baseline test results for v3.10-rc6

[Paul Walmsley]

Hi Lokesh

On Thu, 27 Jun 2013, Lokesh Vutla wrote:

> On Wednesday 26 June 2013 10:56 PM, Paul Walmsley wrote:
> > 
> > Here's how I do it:
> > 
> > ARCH=arm CROSS_COMPILE=${TOOLCHAIN_PATH}/bin/${TOOLCHAIN_PREFIX} nice make
> > -j$CORES zImage am335x-bone.dtb
> > 
> > cat arch/arm/boot/zImage arch/arm/boot/am335x-bone.dtb >
> > arch/arm/boot/zImage-dtb.am335x-bone
> Here is the catch..
> Your dtb is generated in arch/arm/boot/dts/ folder(before V3.8 dtb was
> generated in arch/arm/boot).

Ugh... that's probably it :-(

> You are using very old dtb file. Please delete all your dtb files in
> arch/arm/boot/ folder and check once.

The tree is freshly recreated for each build, so the most likely scenario 
is that there's no DTB file at all appended to the image.

> Here is the patch from Grant Likely which does that.
> https://patchwork.kernel.org/patch/1813321/
> Can you please give a try updating this ..:)

Yeah will try that, probably either today or tomorrow.


- Paul

OMAP baseline test results for v3.10-rc6

[Paul Walmsley]

On Fri, 28 Jun 2013, Paul Walmsley wrote:

> On Thu, 27 Jun 2013, Lokesh Vutla wrote:
>
> > Here is the catch..
> > Your dtb is generated in arch/arm/boot/dts/ folder(before V3.8 dtb was
> > generated in arch/arm/boot).
> 
> Ugh... that's probably it :-(

Indeed, this was at least one major problem.  With this fixed, and with 
CONFIG_MACH_OMAP_GENERIC=y in the v3.10-rc Kconfigs, the BeagleBone white 
boots here now with v3.10-rc7.  Will test the previous releases going back 
to v3.8 and will update the web-linked READMEs as appropriate.

Thanks for the help and the fixes.  Vaibhav and Rajendra, thanks also for 
looking into it.


- Paul

OMAP baseline test results for v3.10-rc6

[Hiremath, Vaibhav]

> -----Original Message-----
> From: Paul Walmsley [mailto:paul at pwsan.com]
> Sent: Monday, July 01, 2013 7:46 AM
> To: Vutla, Lokesh
> Cc: Nayak, Rajendra; Hiremath, Vaibhav; Kevin Hilman; Rini, Tom; linux-
> omap at vger.kernel.org; Balbi, Felipe; linux-arm-
> kernel at lists.infradead.org
> Subject: Re: OMAP baseline test results for v3.10-rc6
> 
> On Fri, 28 Jun 2013, Paul Walmsley wrote:
> 
> > On Thu, 27 Jun 2013, Lokesh Vutla wrote:
> >
> > > Here is the catch..
> > > Your dtb is generated in arch/arm/boot/dts/ folder(before V3.8 dtb
> was
> > > generated in arch/arm/boot).
> >
> > Ugh... that's probably it :-(
> 
> Indeed, this was at least one major problem.  With this fixed, and with
> CONFIG_MACH_OMAP_GENERIC=y in the v3.10-rc Kconfigs, the BeagleBone
> white
> boots here now with v3.10-rc7.  Will test the previous releases going
> back

Surely it will boot. :)

Thanks,
Vaibhav

OMAP baseline test results for v3.10-rc6

[Nishanth Menon]

On 07/01/2013 11:29 PM, Hiremath, Vaibhav wrote:
>
>> -----Original Message-----
>> From: Paul Walmsley [mailto:paul at pwsan.com]
>> Sent: Monday, July 01, 2013 7:46 AM
>> To: Vutla, Lokesh
>> Cc: Nayak, Rajendra; Hiremath, Vaibhav; Kevin Hilman; Rini, Tom; linux-
>> omap at vger.kernel.org; Balbi, Felipe; linux-arm-
>> kernel at lists.infradead.org
>> Subject: Re: OMAP baseline test results for v3.10-rc6
>>
>> On Fri, 28 Jun 2013, Paul Walmsley wrote:
>>
>>> On Thu, 27 Jun 2013, Lokesh Vutla wrote:
>>>
>>>> Here is the catch..
>>>> Your dtb is generated in arch/arm/boot/dts/ folder(before V3.8 dtb
>> was
>>>> generated in arch/arm/boot).
>>>
>>> Ugh... that's probably it :-(
to prevent this from happening again, Lokesh did post a patch:
https://patchwork.kernel.org/patch/2796921/

Will be good to ack it if we think it might prevent such scenarios in 
the future.

-- 
Regards,
Nishanth Menon

OMAP baseline test results for v3.10-rc6

[Paul Walmsley]

On Tue, 2 Jul 2013, Nishanth Menon wrote:

> On 07/01/2013 11:29 PM, Hiremath, Vaibhav wrote:
> > 
> > > -----Original Message-----
> > > From: Paul Walmsley [mailto:paul at pwsan.com]
> > > Sent: Monday, July 01, 2013 7:46 AM
> > > To: Vutla, Lokesh
> > > Cc: Nayak, Rajendra; Hiremath, Vaibhav; Kevin Hilman; Rini, Tom; linux-
> > > omap at vger.kernel.org; Balbi, Felipe; linux-arm-
> > > kernel at lists.infradead.org
> > > Subject: Re: OMAP baseline test results for v3.10-rc6
> > > 
> > > On Fri, 28 Jun 2013, Paul Walmsley wrote:
> > > 
> > > > On Thu, 27 Jun 2013, Lokesh Vutla wrote:
> > > > 
> > > > > Here is the catch..
> > > > > Your dtb is generated in arch/arm/boot/dts/ folder(before V3.8 dtb
> > > was
> > > > > generated in arch/arm/boot).
> > > > 
> > > > Ugh... that's probably it :-(
> to prevent this from happening again, Lokesh did post a patch:
> https://patchwork.kernel.org/patch/2796921/
> 
> Will be good to ack it if we think it might prevent such scenarios in the
> future.

Thanks for the suggestion.  

Unfortunately it wouldn't have caught the problem, since, as I mentioned 
in the E-mail you quoted, I build from a fresh tree each time.  So there 
was no previous DTB.  This wasn't caught here because 'cat' was copying 
over the kernel to its standard output, even though it was returning an 
error, and I wasn't checking the 'cat' return value.  This is obviously 
being remedied here.

Also will modify the build scripts to output each command as it's being 
run.

As far as Lokesh's patch goes: it doesn't make sense to me to remove a 
file during 'make clean' that the build process doesn't create.  So while 
I understand the motivation for the patch, and don't mind if upstream 
takes it, I personally wouldn't care to ack it.


- Paul

OMAP baseline test results for v3.10-rc6

[Paul Walmsley]

On Wed, 3 Jul 2013, Paul Walmsley wrote:

> As far as Lokesh's patch goes: it doesn't make sense to me to remove a 
> file during 'make clean' that the build process doesn't create.  So while 
> I understand the motivation for the patch, and don't mind if upstream 
> takes it, I personally wouldn't care to ack it.

Incidentally, if there's any patch that would improve the current 
situation with appended DTBs by going upstream, it would be a patch like 
Grant's "HACK" patch to add appended DTB building into the kernel build 
system.  Maybe folks can push to something similar to that one upstream?


- Paul

OMAP baseline test results for v3.10-rc6

[Rajendra Nayak]

On Thursday 04 July 2013 11:42 PM, Paul Walmsley wrote:
> On Wed, 3 Jul 2013, Paul Walmsley wrote:
> 
>> As far as Lokesh's patch goes: it doesn't make sense to me to remove a 
>> file during 'make clean' that the build process doesn't create.  So while 
>> I understand the motivation for the patch, and don't mind if upstream 
>> takes it, I personally wouldn't care to ack it.
> 
> Incidentally, if there's any patch that would improve the current 
> situation with appended DTBs by going upstream, it would be a patch like 
> Grant's "HACK" patch to add appended DTB building into the kernel build 
> system.  Maybe folks can push to something similar to that one upstream?

Grant already made it clear when he posted that patch that neither that nor
anything similar would be taken up mainline because the appended dtb was only
meant for folks stuck with legacy bootloaders and have no way to upgrade.
Anyone who uses a bootloader capable of passing the dtb should *not* use the
appended dtb way.

> 
> 
> - Paul
> 

OMAP baseline test results for v3.10-rc6

[Tom Rini]

On 07/05/2013 01:48 AM, Rajendra Nayak wrote:
> On Thursday 04 July 2013 11:42 PM, Paul Walmsley wrote:
>> On Wed, 3 Jul 2013, Paul Walmsley wrote:
>>
>>> As far as Lokesh's patch goes: it doesn't make sense to me to remove a 
>>> file during 'make clean' that the build process doesn't create.  So while 
>>> I understand the motivation for the patch, and don't mind if upstream 
>>> takes it, I personally wouldn't care to ack it.
>>
>> Incidentally, if there's any patch that would improve the current 
>> situation with appended DTBs by going upstream, it would be a patch like 
>> Grant's "HACK" patch to add appended DTB building into the kernel build 
>> system.  Maybe folks can push to something similar to that one upstream?
> 
> Grant already made it clear when he posted that patch that neither that nor
> anything similar would be taken up mainline because the appended dtb was only
> meant for folks stuck with legacy bootloaders and have no way to upgrade.
> Anyone who uses a bootloader capable of passing the dtb should *not* use the
> appended dtb way.

The problem with that statement, and why I poked rmk the other week to
confirm, and posted a patch to enable appended dtb support in the
omap2plus_defconfig is that Grants statement conflicts with rmk's statement.

Now, my personal preference, with my U-Boot guy hat on, would be to say
that eval boards (those things that come with support and instructions
on un-bricking them, and really have to have bootloader source available
when applicable, or should be thrown back at the vendor, with extreme
prejudice) ought to require passed dtbs even if that means upgrading
bootloader.  Shipping product boards, well, you make do, and that
probably means passing a new bootloader to the locked bootloader to pass
in a separate dtb is going to be left to the folks who think that is
fun.  Everyone else will be happy just booting mainline(ish) kernels
with appended dtb.

-- 
Tom

OMAP baseline test results for v3.10-rc6

[Paul Walmsley]

On Fri, 5 Jul 2013, Rajendra Nayak wrote:

> Grant already made it clear when he posted that patch that neither that nor
> anything similar would be taken up mainline because the appended dtb was only
> meant for folks stuck with legacy bootloaders and have no way to upgrade.

He's not the final arbiter of what goes into the mainline kernel :-)

> Anyone who uses a bootloader capable of passing the dtb should *not* use
> the appended dtb way.

Look, either the kernel should support appended DTB booting, or it 
shouldn't.  If it shouldn't, then that code should be ripped out of the 
kernel completely, and we tell people 'tough luck'. If it should, then it 
makes sense to help the millions of folks out there with locked 
bootloaders to build and boot new kernels. This half-support that's in the 
kernel now is not good.


- Paul

OMAP baseline test results for v3.10-rc6

[Kevin Hilman]

"Hiremath, Vaibhav" <hvaibhav@ti.com> writes:

>> -----Original Message-----
>> From: linux-arm-kernel [mailto:linux-arm-kernel-
>> bounces at lists.infradead.org] On Behalf Of Kevin Hilman
>> Sent: Wednesday, June 26, 2013 1:28 AM
>> To: Rini, Tom
>> Cc: Paul Walmsley; linux-omap at vger.kernel.org; linux-arm-
>> kernel at lists.infradead.org; Balbi, Felipe; Hiremath, Vaibhav
>> Subject: Re: OMAP baseline test results for v3.10-rc6
>> 
>> Tom Rini <trini@ti.com> writes:
>> 
>> > On 06/25/2013 02:20 PM, Paul Walmsley wrote:
>> >> + Vaibhav and Kevin
>> >>
>> >> Hi,
>> >>
>> >> On Tue, 25 Jun 2013, Felipe Balbi wrote:
>> >>
>> >>> On Mon, Jun 17, 2013 at 05:23:17AM +0000, Paul Walmsley wrote:
>> >>>> Boot to userspace:
>> >>>>     FAIL ( 3/12): 37xxevm, am335xbone, am335xbonelt
>> >>>
>> >>> Paul, we have at least 2 different folks who can't reproduce your
>> bone
>> >>> and bone black boot to userspace failures. I wonder how you're
>> trying to
>> >>> boot them.
>> >>>
>> >>> Care to share your test scripts ?
>> >>
>> >> Sure... the methodology is completely open and has been posted in
>> the
>> >> online logs since the first test cycle.  (For some reason, almost no
>> one
>> >> clicks through the test directory trees that I post online.  Is this
>> a
>> >> documentation issue?  What can we do to make it easier for people to
>> >> explore this?)
>> >
>> > Well, another link never hurts the search results :)
>> >
>> > [snip]
>> >> Am certainly open to the idea that there's something wrong with the
>> way
>> >> that I'm booting either of these.  But AFAIK no one's been able to
>> >> identify exactly what it could be.  I haven't had the time recently
>> to
>> >> spend hours going through the various permutations, given all the
>> other
>> >> breakage :-(  BeagleBone-white has the additional complication that
>> it is
>> >> not easy to automate, due to the way that power is delivered to the
>> board,
>> >> so there is an extra dimension of difficulty there.
>> >
>> > Ah-ha, I reproduced your failure.  If I make up a concat uImage +
>> DTB,
>> > rather than pass them separately, it fails to boot.  If you switch to
>> > mainline U-Boot (v2012.10 or later) you get support for separate
>> image +
>> > dtb (v2013.04 gives you bootz and zImage support).  v2013.04 will
>> also
>> > work out of the box for BeagleBone-Black.
>> 
>> Just to confirm, my problems with mainline were with appended DTB also.
>> Separate DTB and zImage work fine (at least using u-boot v2013.04.)
>> 
>> That being said, appended DTB should still work, so there's a bug
>> hiding
>> someplace that needs to be found fixed.
>> 
>> Can you guys update your tests to test appended DTB also?
>> 
>
> What is missing here is, 
>
> CONFIG_ARM_APPENDED_DTB = y
> CONFIG_ARM_ATAG_DTB_COMPAT = y

Yes, yes... I use these options since I use appended DT with mainline
for *many* boards. Only the beaglebone stopped working.

I just tested v3.10-rc7 and it's back to working again for me with
appended DT.  I did not spend anymore time to figure out exactly which
versions worked or didn't work.

Kevin

OMAP baseline test results for v3.10-rc6

[Paul Walmsley]

On Tue, 25 Jun 2013, Tom Rini wrote:

> On 06/25/2013 02:20 PM, Paul Walmsley wrote:
> 
> > BeagleBone-white has the additional complication that it is not easy 
> > to automate, due to the way that power is delivered to the board, so 
> > there is an extra dimension of difficulty there.
> 
> Ah-ha, I reproduced your failure.  If I make up a concat uImage + DTB,
> rather than pass them separately, it fails to boot.  If you switch to
> mainline U-Boot (v2012.10 or later) you get support for separate image +
> dtb (v2013.04 gives you bootz and zImage support).

Yeah, I've tried to keep the original bootloader that came on the first SD 
card image that was used on that device.  But am starting to think that 
it's time to stop my bootloader independence jihad, since appended DTB 
booting is so broken - have seen similar problems on SoCs from other 
vendors as well :-(

> And yeah, I feel your pain about power cycling BeagleBone-White.  The QA
> folks here sent me one of the relay controllers they use, and I think
> Felipe is partial to one from phidgets.

Thanks yeah, I should have been more specific in my whining.  Here I use a 
USB cable with VBUS sliced and then connected to an Ethernet-controlled DC 
relay.  But there's a power delivery issue where, under some conditions, 
supplemental power has to be supplied through the DC jack also, requiring 
two separate contacts to be switched :-(


- Paul

OMAP baseline test results for v3.10-rc6

[Tom Rini]

On 06/26/2013 01:19 PM, Paul Walmsley wrote:
> On Tue, 25 Jun 2013, Tom Rini wrote:
> 
>> On 06/25/2013 02:20 PM, Paul Walmsley wrote:
>>
>>> BeagleBone-white has the additional complication that it is not easy 
>>> to automate, due to the way that power is delivered to the board, so 
>>> there is an extra dimension of difficulty there.
>>
>> Ah-ha, I reproduced your failure.  If I make up a concat uImage + DTB,
>> rather than pass them separately, it fails to boot.  If you switch to
>> mainline U-Boot (v2012.10 or later) you get support for separate image +
>> dtb (v2013.04 gives you bootz and zImage support).
> 
> Yeah, I've tried to keep the original bootloader that came on the first SD 
> card image that was used on that device.  But am starting to think that 
> it's time to stop my bootloader independence jihad, since appended DTB 
> booting is so broken - have seen similar problems on SoCs from other 
> vendors as well :-(

Well, me?  I'm all in favor of people using latest release of U-Boot for
their board and yelling and screaming (or just reporting bugs) when
things don't work.  I'm biased of course.  And assuming rmk answers the
way I expect he will, like it or not, the version(s) we kit up and get
in the box need to be factored into our test system setup so if folks
don't want to avail themselves of improvements, they still get a
functional system too.

-- 
Tom

OMAP baseline test results for v3.10-rc6

[Paul Walmsley]

Hi

On Wed, 26 Jun 2013, Tom Rini wrote:

> On 06/26/2013 01:19 PM, Paul Walmsley wrote:
> > On Tue, 25 Jun 2013, Tom Rini wrote:
> > 
> >> On 06/25/2013 02:20 PM, Paul Walmsley wrote:
> >>
> >>> BeagleBone-white has the additional complication that it is not easy 
> >>> to automate, due to the way that power is delivered to the board, so 
> >>> there is an extra dimension of difficulty there.
> >>
> >> Ah-ha, I reproduced your failure.  If I make up a concat uImage + DTB,
> >> rather than pass them separately, it fails to boot.  If you switch to
> >> mainline U-Boot (v2012.10 or later) you get support for separate image +
> >> dtb (v2013.04 gives you bootz and zImage support).
> > 
> > Yeah, I've tried to keep the original bootloader that came on the first SD 
> > card image that was used on that device.  But am starting to think that 
> > it's time to stop my bootloader independence jihad, since appended DTB 
> > booting is so broken - have seen similar problems on SoCs from other 
> > vendors as well :-(
> 
> Well, me?  I'm all in favor of people using latest release of U-Boot for
> their board and yelling and screaming (or just reporting bugs) when
> things don't work.  I'm biased of course.

That's exactly how bootloader developers should be testing their changes.  
But most of the rest of us kernel folks don't want to deal with constantly 
replacing bootloaders, and then dealing with the inevitable bootloader 
regressions, when what we're really trying to test is the kernel...
The kernel should be completely independent of the bootloader used.  

> And assuming rmk answers the way I expect he will, like it or not, the 
> version(s) we kit up and get in the box need to be factored into our 
> test system setup so if folks don't want to avail themselves of 
> improvements, they still get a functional system too.

Yep seems like a good idea from a customer service point of view.  Also 
most OMAP devices out there probably have locked bootloaders, so replacing 
the bootloader is often not an option.


- Paul

OMAP baseline test results for v3.10-rc6

[Tom Rini]

On 07/29/2013 04:29 AM, Paul Walmsley wrote:
> Hi
> 
> On Wed, 26 Jun 2013, Tom Rini wrote:
> 
>> On 06/26/2013 01:19 PM, Paul Walmsley wrote:
>>> On Tue, 25 Jun 2013, Tom Rini wrote:
>>>
>>>> On 06/25/2013 02:20 PM, Paul Walmsley wrote:
>>>>
>>>>> BeagleBone-white has the additional complication that it is not easy 
>>>>> to automate, due to the way that power is delivered to the board, so 
>>>>> there is an extra dimension of difficulty there.
>>>>
>>>> Ah-ha, I reproduced your failure.  If I make up a concat uImage + DTB,
>>>> rather than pass them separately, it fails to boot.  If you switch to
>>>> mainline U-Boot (v2012.10 or later) you get support for separate image +
>>>> dtb (v2013.04 gives you bootz and zImage support).
>>>
>>> Yeah, I've tried to keep the original bootloader that came on the first SD 
>>> card image that was used on that device.  But am starting to think that 
>>> it's time to stop my bootloader independence jihad, since appended DTB 
>>> booting is so broken - have seen similar problems on SoCs from other 
>>> vendors as well :-(
>>
>> Well, me?  I'm all in favor of people using latest release of U-Boot for
>> their board and yelling and screaming (or just reporting bugs) when
>> things don't work.  I'm biased of course.
> 
> That's exactly how bootloader developers should be testing their changes.  
> But most of the rest of us kernel folks don't want to deal with constantly 
> replacing bootloaders, and then dealing with the inevitable bootloader 
> regressions, when what we're really trying to test is the kernel...
> The kernel should be completely independent of the bootloader used.  

And thus the chicken and egg problems we have today.  The kernel should
be independent, but unless someone is also testing more recent U-Boots
as well, we may or may not have more hidden clock problems.  Or if there
is a bug in the bootloader for some particular use case, we don't find
out until a new device ships out with broken code for that case, and now
we're stuck for "forever".

I don't suspect what I'm going to say now will have a lot of traction,
but I really think that much like user space, every once in a while (6
months? year?) one ought to update their environment and make sure
things are still working too.

You folks don't need to test ever rev of U-Boot (that's my job), but it
often feels like there's this cycle of "U-Boot sucks and can't do ... !"
"We've had that fixed / improved / changed for years now, upgrade?" "No,
can't / won't!".  And...

>> And assuming rmk answers the way I expect he will, like it or not, the 
>> version(s) we kit up and get in the box need to be factored into our 
>> test system setup so if folks don't want to avail themselves of 
>> improvements, they still get a functional system too.
> 
> Yep seems like a good idea from a customer service point of view.  Also 
> most OMAP devices out there probably have locked bootloaders, so replacing 
> the bootloader is often not an option.

For shipping consumer product, or however you want to call those kind of
devices, yes, appended dtb needs to work since the bootloader is locked,
and making that boot something else to boot the kernel is an exercise
for us oddballs :)  But the boards which are designed as reference
platform, we can make your lives easier, if you let us help.  If
something is a pain to do, give us feedback.

-- 
Tom

OMAP baseline test results for v3.10-rc6

[Paul Walmsley]

Hi Tom,

On Mon, 29 Jul 2013, Tom Rini wrote:

> On 07/29/2013 04:29 AM, Paul Walmsley wrote:
> > On Wed, 26 Jun 2013, Tom Rini wrote:
> >>
> >> Well, me?  I'm all in favor of people using latest release of U-Boot for
> >> their board and yelling and screaming (or just reporting bugs) when
> >> things don't work.  I'm biased of course.
> > 
> > That's exactly how bootloader developers should be testing their changes.  
> > But most of the rest of us kernel folks don't want to deal with constantly 
> > replacing bootloaders, and then dealing with the inevitable bootloader 
> > regressions, when what we're really trying to test is the kernel...
> > The kernel should be completely independent of the bootloader used.  
> 
> And thus the chicken and egg problems we have today.  The kernel should
> be independent, but unless someone is also testing more recent U-Boots
> as well, we may or may not have more hidden clock problems.

It doesn't have to be this way :-)

IMHO the only thing that the bootloader should be responsible for is the 
minimum that's needed to get the kernel started.  Setting up RAM, maybe a 
handful of critical system clocks, and that's basically it.

In fact it would be great if there was a bootloader option where it would 
return the rest of the bits on the chip that it tweaked to power-on reset 
status.  That would let you guys off the hook for everything that we don't 
set up correctly in the kernel.  And it would allow the kernel folks to 
see where the problems really are.  And then for customer-targeted images, 
that bootloader option could be kept off so management doesn't freak out.

You might not believe this, but we went to great pain on the OMAP Linux 
kernel to reset as much as we could, as early as possible.  This was 
partially so that if kernel device driver authors assumed that the 
bootloader would configure their device, it would show up as a bug that 
would need to be fixed.  We were even resetting and reprogramming the 
SDRAM controller for a while.  Unfortunately we weren't able to reset the 
clocks...

> I don't suspect what I'm going to say now will have a lot of traction,
> but I really think that much like user space, every once in a while (6
> months? year?) one ought to update their environment and make sure
> things are still working too.
> 
> You folks don't need to test ever rev of U-Boot (that's my job), but it
> often feels like there's this cycle of "U-Boot sucks and can't do ... !"
> "We've had that fixed / improved / changed for years now, upgrade?" "No,
> can't / won't!".  And...

I've always wanted to switch most of the devices in my test platform over 
to serial-booted bootloaders and MLOs/X-loaders/SPLs.  That way any 
bootloader could be booted during automated test.  This is what's 
happening now on the BeagleBone-black here; that's really easy to 
cold-boot from serial due to the Xmodem download code implemented in the 
ROM, plus the lack of flash:

http://www.pwsan.com/omap/testlogs/test_v3.11-rc3/20130728224046/boot/am335xbonelt/am335x-bone/

Do you know if anyone ever got serial cold-booting working well for, say, 
OMAP3 and OMAP4 chips?
 
> For shipping consumer product, or however you want to call those kind of
> devices, yes, appended dtb needs to work since the bootloader is locked,
> and making that boot something else to boot the kernel is an exercise
> for us oddballs :)  But the boards which are designed as reference
> platform, we can make your lives easier, if you let us help.  If
> something is a pain to do, give us feedback.

OK I would love it if you would add a bootloader option 
"ASSUME_WORKING_KERNEL" that would reset every non-essential device on the 
board to power-on reset, and reset any non-essential clock register bits 
etc. to their POR values.  Unlock the USB DPLL, etc.  To start with, you'd 
need to leave that disabled for shipping customer images, but we could 
start testing with it and prevent patches from going upstream that 
implicitly rely on the bootloader settings.


- Paul

OMAP baseline test results for v3.10-rc6

[Nishanth Menon]

On 07/30/2013 03:23 PM, Paul Walmsley wrote:

> Do you know if anyone ever got serial cold-booting working well for, say,
> OMAP3 and OMAP4 chips?

I had done configuration header based OMAP3 boot[1] once upon a time, 
but serial boot straight to kernel, we need a second that gives control 
there.. could be done, have'nt heard it done + I dont directly see a 
customer usage model for it ("ROI for investment of time") - so doubt 
any investment was done.

CH was the closest I could get to avoiding bootloaders in it's entirety. 
but the level of interest fell off when there was no viable usage model 
for the same.


[1] http://marc.info/?t=127232401100003&r=1&w=2
-- 
Regards,
Nishanth Menon

OMAP baseline test results for v3.10-rc6

[Felipe Balbi]

Hi,

On Tue, Jun 25, 2013 at 06:20:51PM +0000, Paul Walmsley wrote:
> Am certainly open to the idea that there's something wrong with the way 
> that I'm booting either of these.  But AFAIK no one's been able to 
> identify exactly what it could be.  I haven't had the time recently to 
> spend hours going through the various permutations, given all the other 
> breakage :-(  BeagleBone-white has the additional complication that it is 
> not easy to automate, due to the way that power is delivered to the board, 
> so there is an extra dimension of difficulty there.

oh yeah, you can use something like [1] for that

[1] http://www.cleware-shop.de/epages/63698188.sf/en_US/?ObjectPath=/Shops/63698188/Products/01

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130625/8c904e0e/attachment.sig>

OMAP baseline test results for v3.10-rc6

[Hiremath, Vaibhav]

> -----Original Message-----
> From: linux-omap-owner at vger.kernel.org [mailto:linux-omap-
> owner at vger.kernel.org] On Behalf Of Paul Walmsley
> Sent: Tuesday, June 25, 2013 11:51 PM
> To: Balbi, Felipe
> Cc: linux-omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> Rini, Tom; Hiremath, Vaibhav; khilman at ti.com
> Subject: Re: OMAP baseline test results for v3.10-rc6
> 
> + Vaibhav and Kevin
> 
> Hi,
> 
> On Tue, 25 Jun 2013, Felipe Balbi wrote:
> 
> > On Mon, Jun 17, 2013 at 05:23:17AM +0000, Paul Walmsley wrote:
> > > Boot to userspace:
> > >     FAIL ( 3/12): 37xxevm, am335xbone, am335xbonelt
> >
> > Paul, we have at least 2 different folks who can't reproduce your
> bone
> > and bone black boot to userspace failures. I wonder how you're trying
> to
> > boot them.
> >
> > Care to share your test scripts ?
> 
> Sure... the methodology is completely open and has been posted in the
> online logs since the first test cycle.  (For some reason, almost no
> one
> clicks through the test directory trees that I post online.  Is this a
> documentation issue?  What can we do to make it easier for people to
> explore this?)
> 


That?s not quite true, I remember going through your log in detail multiple
Times.

The issue is, for appended DTB you must enable 2 config options,

CONFIG_ARM_APPENDED_DTB = y
CONFIG_ARM_ATAG_DTB_COMPAT = y

OR

If you don?t want to change/modify default config (omap2plus_defconfig), 
Use separate DTB and zImage, which is standard way of booting kernel.

Same applies to BeagleBone Black. Infact same DTB and zImage boots up fine
On both boards without any issues.

Thanks,
Vaibhav

OMAP baseline test results for v3.10-rc6

[Paul Walmsley]

On Wed, 26 Jun 2013, Hiremath, Vaibhav wrote:

> That?s not quite true, I remember going through your log in detail multiple
> Times.
> 
> The issue is, for appended DTB you must enable 2 config options,
> 
> CONFIG_ARM_APPENDED_DTB = y
> CONFIG_ARM_ATAG_DTB_COMPAT = y

Maybe you should look again.  Both of these options are set in the 
am33xx_only Kconfig which is used here for the Beaglebone-White boot.


- Paul


$ find . -type f -name "am33xx_only" -exec fgrep -q CONFIG_ARM_APPENDED_DTB=y '{}' ';' -print   |fgrep test_v3. | sort -t. -k3,3 -n
./test_v3.7/20121211094536/build/am33xx_only/am33xx_only
./test_v3.7-rc1/20121017205513/build/am33xx_only/am33xx_only
./test_v3.7-rc2/20121020134755/build/am33xx_only/am33xx_only
./test_v3.7-rc3/20121028162003/build/am33xx_only/am33xx_only
./test_v3.7-rc4/20121104142910/build/am33xx_only/am33xx_only
./test_v3.7-rc5/20121111081034/build/am33xx_only/am33xx_only
./test_v3.7-rc6/20121117093152/build/am33xx_only/am33xx_only
./test_v3.7-rc7/20121127152704/build/am33xx_only/am33xx_only
./test_v3.7-rc8/20121204220128/build/am33xx_only/am33xx_only
./test_v3.8/20130218214403/build/am33xx_only/am33xx_only
./test_v3.8-rc1/20121228031713/build/am33xx_only/am33xx_only
./test_v3.8-rc2/20130103093341/build/am33xx_only/am33xx_only
./test_v3.8-rc3/20130109222058/build/am33xx_only/am33xx_only
./test_v3.8-rc4/20130120122039/build/am33xx_only/am33xx_only
./test_v3.8-rc5/20130126003323/build/am33xx_only/am33xx_only
./test_v3.8-rc6/20130206155004/build/am33xx_only/am33xx_only
./test_v3.8-rc7/20130210080644/build/am33xx_only/am33xx_only
./test_v3.9/20130429104339/build/am33xx_only/am33xx_only
./test_v3.9-rc1/20130312100243/build/am33xx_only/am33xx_only
./test_v3.9-rc2/20130314094808/build/am33xx_only/am33xx_only
./test_v3.9-rc3/20130317194234/build/am33xx_only/am33xx_only
./test_v3.9-rc4/20130324120244/build/am33xx_only/am33xx_only
./test_v3.9-rc5/20130331205513/build/am33xx_only/am33xx_only
./test_v3.9-rc6/20130410123059/build/am33xx_only/am33xx_only
./test_v3.9-rc7/20130414220303/build/am33xx_only/am33xx_only
./test_v3.9-rc8/20130422154921/build/am33xx_only/am33xx_only
./test_v3.10-rc1/20130518212204/build/am33xx_only/am33xx_only
./test_v3.10-rc2/20130527225935/build/am33xx_only/am33xx_only
./test_v3.10-rc3/20130527220737/build/am33xx_only/am33xx_only
./test_v3.10-rc3/20130603032237/build/am33xx_only/am33xx_only
./test_v3.10-rc4/20130603034317/build/am33xx_only/am33xx_only
./test_v3.10-rc5/20130609031534/build/am33xx_only/am33xx_only
./test_v3.10-rc6/20130616211951/build/am33xx_only/am33xx_only
$ find . -type f -name "am33xx_only" -exec fgrep -q CONFIG_ARM_ATAG_DTB_COMPAT=y '{}' ';' -print   |fgrep test_v3. | sort -t. -k3,3 -n
./test_v3.7/20121211094536/build/am33xx_only/am33xx_only
./test_v3.7-rc1/20121017205513/build/am33xx_only/am33xx_only
./test_v3.7-rc2/20121020134755/build/am33xx_only/am33xx_only
./test_v3.7-rc3/20121028162003/build/am33xx_only/am33xx_only
./test_v3.7-rc4/20121104142910/build/am33xx_only/am33xx_only
./test_v3.7-rc5/20121111081034/build/am33xx_only/am33xx_only
./test_v3.7-rc6/20121117093152/build/am33xx_only/am33xx_only
./test_v3.7-rc7/20121127152704/build/am33xx_only/am33xx_only
./test_v3.7-rc8/20121204220128/build/am33xx_only/am33xx_only
./test_v3.8/20130218214403/build/am33xx_only/am33xx_only
./test_v3.8-rc1/20121228031713/build/am33xx_only/am33xx_only
./test_v3.8-rc2/20130103093341/build/am33xx_only/am33xx_only
./test_v3.8-rc3/20130109222058/build/am33xx_only/am33xx_only
./test_v3.8-rc4/20130120122039/build/am33xx_only/am33xx_only
./test_v3.8-rc5/20130126003323/build/am33xx_only/am33xx_only
./test_v3.8-rc6/20130206155004/build/am33xx_only/am33xx_only
./test_v3.8-rc7/20130210080644/build/am33xx_only/am33xx_only
./test_v3.9/20130429104339/build/am33xx_only/am33xx_only
./test_v3.9-rc1/20130312100243/build/am33xx_only/am33xx_only
./test_v3.9-rc2/20130314094808/build/am33xx_only/am33xx_only
./test_v3.9-rc3/20130317194234/build/am33xx_only/am33xx_only
./test_v3.9-rc4/20130324120244/build/am33xx_only/am33xx_only
./test_v3.9-rc5/20130331205513/build/am33xx_only/am33xx_only
./test_v3.9-rc6/20130410123059/build/am33xx_only/am33xx_only
./test_v3.9-rc7/20130414220303/build/am33xx_only/am33xx_only
./test_v3.9-rc8/20130422154921/build/am33xx_only/am33xx_only
./test_v3.10-rc1/20130518212204/build/am33xx_only/am33xx_only
./test_v3.10-rc2/20130527225935/build/am33xx_only/am33xx_only
./test_v3.10-rc3/20130527220737/build/am33xx_only/am33xx_only
./test_v3.10-rc3/20130603032237/build/am33xx_only/am33xx_only
./test_v3.10-rc4/20130603034317/build/am33xx_only/am33xx_only
./test_v3.10-rc5/20130609031534/build/am33xx_only/am33xx_only
./test_v3.10-rc6/20130616211951/build/am33xx_only/am33xx_only

OMAP baseline test results for v3.10-rc6

[Paul Walmsley]

On Wed, 26 Jun 2013, Paul Walmsley wrote:

> On Wed, 26 Jun 2013, Hiremath, Vaibhav wrote:
> 
> > That?s not quite true, I remember going through your log in detail multiple
> > Times.
> > 
> > The issue is, for appended DTB you must enable 2 config options,
> > 
> > CONFIG_ARM_APPENDED_DTB = y
> > CONFIG_ARM_ATAG_DTB_COMPAT = y
> 
> Maybe you should look again.  Both of these options are set in the 
> am33xx_only Kconfig which is used here for the Beaglebone-White boot.

(and I do appreciate the attention you brought to looking into this issue 
a few months ago)


- Paul

OMAP baseline test results for v3.10-rc6

[Lokesh Vutla]

Hi Paul,
On Tuesday 25 June 2013 11:50 PM, Paul Walmsley wrote:
> + Vaibhav and Kevin
>
> Hi,
>
> On Tue, 25 Jun 2013, Felipe Balbi wrote:
>
>> On Mon, Jun 17, 2013 at 05:23:17AM +0000, Paul Walmsley wrote:
>>> Boot to userspace:
>>>      FAIL ( 3/12): 37xxevm, am335xbone, am335xbonelt
>>
>> Paul, we have at least 2 different folks who can't reproduce your bone
>> and bone black boot to userspace failures. I wonder how you're trying to
>> boot them.
>>
>> Care to share your test scripts ?
>
> Sure... the methodology is completely open and has been posted in the
> online logs since the first test cycle.  (For some reason, almost no one
> clicks through the test directory trees that I post online.  Is this a
> documentation issue?  What can we do to make it easier for people to
> explore this?)
>
> Anyway, for BeagleBone white, here's the last working test log, from 3.7:
>
> http://www.pwsan.com/omap/testlogs/test_v3.7/20121211094536/boot/am335xbone/am335xbone_log.txt
>
> The concatenated kernel and DTB, along with the Kconfig used to build, are
> here:
>
> http://www.pwsan.com/omap/testlogs/test_v3.7/20121211094536/build/am33xx_only/
>
> The boot broke immediately afterwards with v3.8-rc1 and has never worked
> since:
>
> http://www.pwsan.com/omap/testlogs/test_v3.8-rc1/20121228031713/boot/am335xbone/
>
> You can find all of the archived testlogs here:
>
> http://www.pwsan.com/omap/testlogs/
>
> You'll probably only be interested in the ones that start with "test_v3.".
>
> ...
>
> As for BeagleBone Black, here's the latest non-booting log:
>
> http://www.pwsan.com/omap/testlogs/test_v3.10-rc6/20130616211951/boot/am335xbonelt/am335x-bone/am335xbonelt_log.txt
I checked your am33xx-only build config for v3.10-rc6 here:
http://www.pwsan.com/omap/testlogs/test_v3.10-rc6/20130616211951/build/am33xx_only/am33xx_only
I can see that you are disabling config MACH_OMAP_GENERIC
"# CONFIG_MACH_OMAP_GENERIC is not set"
If this is not selected you cannot boot with dt.
I copied your config and selected "CONFIG_MACH_OMAP_GENERIC"
then it boots fine.

Thanks and regards,
Lokesh
>
> This has never booted on mainline for me.  The closest I got was with the
> ti-linux-3.8.y tree on Vaibhav's github account, which booted with
> the 'am335x-boneblack.dtb' built from the same tree.  Mainline didn't boot
> with either the am335x-bone.dtb or Vaibhav's am335x-boneblack.dtb, but
> since it booted on 3.8.y with am335x-boneblack.dtb, I've kept that
> around for the mainline boot tests (as you can see from the logs).
>
> There's nothing exotic about the kernel used here, it's a pure
> omap2plus_defconfig zImage.
>
> The bootloader and DTB used are here (booted via serial from the boot
> ROM):
>
> http://www.pwsan.com/tmp/boneblack-20130625/
>
> Please let me know if you need more binaries shared from the test runs!
>
> ...
>
> Am certainly open to the idea that there's something wrong with the way
> that I'm booting either of these.  But AFAIK no one's been able to
> identify exactly what it could be.  I haven't had the time recently to
> spend hours going through the various permutations, given all the other
> breakage :-(  BeagleBone-white has the additional complication that it is
> not easy to automate, due to the way that power is delivered to the board,
> so there is an extra dimension of difficulty there.
>
>> Also, if you could share the entire thing, we will add your scripts to
>> our nightly tests as to try and avoid future regressions.
>
> It would be great to have TI folks running those tests, or something
> similar to them!  An early version of the test system has been shared with
> a handful of folks, but it needs to be cleaned up further before broader
> release.
>
>
> - Paul
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>

OMAP baseline test results for v3.10-rc6

[Paul Walmsley]

Hi

On Wed, 26 Jun 2013, Lokesh Vutla wrote:

> I checked your am33xx-only build config for v3.10-rc6 here:
> http://www.pwsan.com/omap/testlogs/test_v3.10-rc6/20130616211951/build/am33xx_only/am33xx_only
> I can see that you are disabling config MACH_OMAP_GENERIC
> "# CONFIG_MACH_OMAP_GENERIC is not set"
> If this is not selected you cannot boot with dt.

Hmm yeah, looks like there's some problem where that didn't get set for 
any of the am33xx_only Kconfigs after v3.8-rc7.  Will fix that and give it 
a try on v3.10-rc6.  But still that doesn't explain why none of the v3.8* 
kernels booted here.

Care to take a quick look at the v3.8-rc1 Kconfig?

http://www.pwsan.com/omap/testlogs/test_v3.8-rc1/20121228031713/build/am33xx_only/am33xx_only


- Paul

$ find . -type f -name "am33xx_only" -exec fgrep -q CONFIG_MACH_OMAP_GENERIC=y '{}' ';' -print   |fgrep test_v3. | sort -t. -k3,3 -n
./test_v3.7/20121211094536/build/am33xx_only/am33xx_only
./test_v3.7-rc1/20121017205513/build/am33xx_only/am33xx_only
./test_v3.7-rc2/20121020134755/build/am33xx_only/am33xx_only
./test_v3.7-rc3/20121028162003/build/am33xx_only/am33xx_only
./test_v3.7-rc4/20121104142910/build/am33xx_only/am33xx_only
./test_v3.7-rc5/20121111081034/build/am33xx_only/am33xx_only
./test_v3.7-rc6/20121117093152/build/am33xx_only/am33xx_only
./test_v3.7-rc7/20121127152704/build/am33xx_only/am33xx_only
./test_v3.7-rc8/20121204220128/build/am33xx_only/am33xx_only
./test_v3.8/20130218214403/build/am33xx_only/am33xx_only
./test_v3.8-rc1/20121228031713/build/am33xx_only/am33xx_only
./test_v3.8-rc2/20130103093341/build/am33xx_only/am33xx_only
./test_v3.8-rc3/20130109222058/build/am33xx_only/am33xx_only
./test_v3.8-rc4/20130120122039/build/am33xx_only/am33xx_only
./test_v3.8-rc5/20130126003323/build/am33xx_only/am33xx_only
./test_v3.8-rc6/20130206155004/build/am33xx_only/am33xx_only
./test_v3.8-rc7/20130210080644/build/am33xx_only/am33xx_only