On Tue, Feb 21, 2012 at 10:30 PM, Paul Larson paul.larson@linaro.orgwrote:
So if I'm understanding correctly, these are actual failures. It would be nice to have some tree that actually worked, but if it fails because it's missing this patch, then it fails. I think we test the Linaro 3.1 tree there though right? Shouldn't that include this, or is this not what we currently ship in the LEB images?
http://people.linaro.org/~asac/githttp/linux-linaro-3.1.git/ is the one I'm referring to, though I think it should really refer to the real upstream tree, not the one in Alex's people.linaro.org account.
Yes we build the linux-linaro 3.1 from http://people.linaro.org/~asac/githttp/linux-linaro-3.1.git/ which points to the latest upstream changes as well. But the origen hwpack fails for this tree as well.
@ Sangwook,
So should we apply the patch for all the trees (arm-soc, linus(torvalds), linux-linaro, linux-next) and build the kernel for testing on the origen boards?
Thanks,
Paul Larson
On Tue, Feb 21, 2012 at 6:57 AM, Sangwook Lee sangwook.lee@linaro.orgwrote:
On 16 February 2012 11:39, Deepti Kalakeri deepti.kalakeri@linaro.org wrote:
Hello Sangwook,
On Thu, Feb 16, 2012 at 4:37 PM, Sangwook Lee sangwook.lee@linaro.org wrote:
The initial problem, you faced is due to the wrong kernel selected by someone. If you tried kernel from CI (arnd) , it should be based on 3.2 kernel,
but
it was not true. It was based on 2.6.35-rxxx. Where does this kernel come from ? At first, please select the proper kernel and then try LAVA again.
I have rectified this. Actually we were using a repository setup by
Arnd on
git.linaro.org to build the kernel. We did not notice the move to git.kernel.org and we built the old
things.
But, otherwise also there are hwpacks built for linus(torvalds),
linux-next
tree with exynos4 defconfig using the latest upstream changes. I have not seen the hwpacks coming out for these trees either being successful to boot on the LAVA origen boards. Hence this is a problem that the hwpacks built for the origen boards do
not
work at all and not specific to just arm-soc tree. Can you check as an example if you can verify if the hwpacks built today works fine on your Origen board.
http://ci.linaro.org/kernel_hwpack/linux-arm-soc-for-next/linux-arm-soc-for-... .
With this image, I couldn't see the booting message.
Do we need to apply the patch you gave yesterday on top of the Arnd
latest
changes to make it work ?
Yes,
I downloaded git:// git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git and then could see the booting message with the patch.
On 15 February 2012 21:35, Paul Larson paul.larson@linaro.org wrote:
On Wed, Feb 15, 2012 at 3:46 AM, Deepti Kalakeri deepti.kalakeri@linaro.org wrote:
On Wed, Feb 15, 2012 at 4:32 PM, Sangwook Lee <
sangwook.lee@linaro.org>
wrote: > > > > On 14 February 2012 16:40, Paul Larson paul.larson@linaro.org
wrote:
>> >> On Tue, Feb 14, 2012 at 2:21 AM, Sangwook Lee >> sangwook.lee@linaro.org wrote: >>> >>> Hi Paul >>> >>> On 14 February 2012 01:03, Paul Larson paul.larson@linaro.org >>> wrote: >>>> >>>> Looking at the latest results on.the kernel CI view I pointed out >>>> earlier, here is a serial.log from a recent one >>>>
http://validation.linaro.org/lava-server/dashboard/streams/anonymous/ci-linu...
>>>> >>>> You can see the test kernel starting to boot at around line 19560 >>>> and at 19660 it gets only as far as the starting kernel message,
hangs, and
>>>> eventually times out. >>> >>> I think there is no option to download this log, maybe only for
LAVA
>>> team. >>> If I download serial.log file as html, I must follow the link to >>> serial log but again I have a broken link. >> >> Yes, we need a download link there - known feature request that
we'll
>> hopefully get to soon. >>>> >>>> but replaces the kernel with the output from jenkins building the >>>> selected kernel. I'm guessing that perhaps we're missing
something critical
>>>> from the kernel configuration? >>> >>> Yes, That's right. I am attaching the patch to fix this problem. >>> Unfortunately, currently this is not up-streamable. Hope that we >>> apply this as doing debian packaing. >>> please let me if you have further problem. >> >> >> I'm not sure what you mean here. If this patch fixes the problem, >> what is preventing it from going upstream? > > > arnd kernel (mainline kernel) we have to do the following for Origen > board > 1) Select exynos4_defconfig > All boards for exynos CPU are sharing one > configuration. > So It select all boards configs and then set
UART
> port to 1 > 2) We have to set UART port to 2 manually only for
Origen
> > The patch I sent to you is to select debug UART port to 2 by
default,
> only for Origen > If we release this patch into mainline, all other boards using
Exynos
> will manually select UART port again. > > >> >> I guess we have this fix somewhere in the kernel produced by the >> landing team? If so, it seems maybe we should also add the
landing team
>> tree here for testing so that we can see it pass. > > > Here is our branch: > Git: > git://git.linaro.org/landing-teams/working/samsung/kernel.git > branch: tracking > > Initially I thought LAVA team is using hwpack built by John > >
https://code.launchpad.net/~jcrigby/+recipe/linux-linaro-3.2-lt-origen-dailyhttps://code.launchpad.net/%7Ejcrigby/+recipe/linux-linaro-3.2-lt-origen-daily
> > Does Lave team build their own hwpack from kernel ?
Not the LAVA team. We(Infra) team build the latest upstream changes
on
ci.linaro.org and then send them to LAVA for testing.
Right, so I guess the better question would be, is there a bug for
this
already, and is there a better solution? Can we pass something on the
boot
cmdline that selects the proper uart? Why don't we have this problem
with
the linaro kernel in our leb images, do they include this workaround
there?
Thanks, Paul Larson
-- Thanks and Regards, Deepti Infrastructure Team Member, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#%21/linaroorg - http://www.linaro.org/linaro-blog