~linaro-android/leb-panda build 184 does not boot

[Patrik Ryd]

Build https://android-build.linaro.org/builds/~linaro-android/leb-panda/#build=184 does not boot.

Build Status
------- --------
 175 Boots
 176 Boots
 176 Not tested
 178 Boots
 179 Does not exist
 180 Build failed.
 181 Failed
 182 Failed
 183 Does not exist
 184 Failed

[Patrik Ryd (patrik-ryd)]

Boot log:

Texas Instruments X-Loader 1.5.1 (Aug 25 2011 - 11:35:26)
Reading boot sector
Loading u-boot.bin from mmc

[Patrik Ryd (patrik-ryd)]

Build 178 has
<project name="boot/u-boot-linaro-stable" path="u-boot" remote="linaro-other" revision="9a1d882b96a119fe3fffd2be294e82e99b732a06"/>
<project name="x-loader/x-loader" path="device/linaro/x-loader" remote="gitorious" revision="c4289f1bee035dea41536c5ba5e1bc36c7d493c4"/>

Build 181 has
 <project name="boot/u-boot-linaro-stable" path="u-boot" remote="linaro-other" revision="01915ec14ee46a4ddfc1f6ea996096e92ff7e802"/>
<project name="x-loader/x-loader" path="device/linaro/x-loader" remote="gitorious" revision="c4289f1bee035dea41536c5ba5e1bc36c7d493c4"/>

[Patrik Ryd (patrik-ryd)]

According to LAVA there is no problem.

http://validation.linaro.org/lava-server/dashboard/streams/anonymous/android-daily/bundles/59d31181dfd440c4aaffd9a1d38620b270c074b7/

[Zach Pfeffer (pfefferz)]

I see this too:

Texas Instruments X-Loader 1.5.1 (Aug 26 2011 - 14:45:39)
Reading boot sector
Loading u-boot.bin from mmc

I don't think LAVA uses an updated bootloader.

[Zach Pfeffer (pfefferz)]

Taking MLO and u-boot.bin from https://android-build.linaro.org/builds/~linaro-android/panda-11.08-release/#build=4 allowed the build to work. In this build we're still using the precompiled MLO via:

cp device/linaro/pandaboard/MLO out/target/product/pandaboard/boot

<remote fetch="git://android.git.linaro.org/" name="linaro-android" review="review.android.git.linaro.org"/>
<project name="device/linaro/pandaboard" remote="linaro-android" revision="0aa9c72268f2f5eacd647643ff9b88ff205091a8"/>

This is:

commit 5f9209f75d318e2c0a39fa267cd3492605f90930
Author: Zach Pfeffer <email address hidden>
Date: Mon Jul 18 10:51:22 2011 -0500

    MLO: add new binary MLO

    Compiled with GCC 4.5.1 (not Linaro's GCC) from

    git://gitorious.org/x-loader/x-loader.git

    master

    particually:

    fca7cd29b6821df3e7d8c4369522f2a3d01a5d7b

    aka:

    Release 1.5.1

we switch from the precompiled version to the real version and things blow up.

[Zach Pfeffer (pfefferz)]

We're building with: omap4430panda_config.

[John Rigby (jcrigby)]

Unfortuneately the MLO from u-boot is a little bit different in the calling convention to u-boot. With the new one you need to use MLO and u-boot.img (not .bin).

[warmcat (andy-warmcat)]

WRT #3, as we learned at the Cambridge Connect, lava does not test your bootloader at all on Panda. It always comes up in its own bootloader and then net-boots your post-bootloader test environment and has a go.

There is a hardware solution to this I described some months ago but testing bootloaders was evidently regarded as not important enough.

[Christian Reis (kiko)]

Well, it was "not important enough" to block testing completely until we had said solution implemented ;-) However, we should still have a project in LAVA open to address this.

[Paul Larson (pwlars)]

Andy proposed a hardware solution a while back, iirc it was basically a dual sd adapter that could be switched back and forth between a card that would be used to load a small image with initramfs, and another that would be for the test image. This is worth considering, but would also require custom built hardware, and lava development around that hardware device for which I don't have a sample or anything. Andy, are you up for mass-producing these things?
There are other solutions we've considered as well, but mostly they require using hardware that doesn't seem to exist in any already-available form. However this is still something we would like to support, but have resisted so far because the currently available software solutions are fragile and board-specific (where they even exist) and the hardware solutions are not readily available.

[Alexander Sack (asac)]

Hmm. I think it's safe to say that we have no idea of what to do here yet. I feel reluctant to put a blueprint in the backlog about something in this state. I filed bug 837032 against the lava-lab project for now. Let's continue to discuss testing u-boot/bootloader there.

Andy can you give some details about the approach you presented at connect in that bug?

[warmcat (andy-warmcat)]

I didn't present at Connect about it, but discussed on Linaro-dev about 5 months ago.

It was during the Lava presentation at Connect that I realized what it meant was that bootloader testing was currently out of scope.

To be fair shortly after proposing it and doing some work on the hardware (I will post that on the other bug) the TI LT stuff really got started and I was / am preoccupied with that so I did not follow it up either.

[John Rigby (jcrigby)]

The MLO from x-loader to MLO from u-boot has been painful but I just want to say it is worth it. The way we are producing MLO from u-boot sources now (thanks to upstream work for AneeshV at TI) is the right thing because having intimate board knowledge in two different places in just wrong. MLO from u-boot sources for OMAP3 is a work in progress upstream so we will likely switch for omap3 platforms sometime in the future. We will however learn from the OMAP4 headaches to do it in a less painful way. Perhaps we need a separate (but nearly identical) tree for Android so we can handle the Ubuntu and Android pain separately on a schedule that meshes with the two teams own dev schedules better.

On the testing of bootloaders topic. One of my work items for 2011.09 is what we call omap4boot. We call it that because that is the name of the project we are starting with. It allows you to boot a Panda board from bare metal to u-boot using the USB gadget connector. Yes its like DFU, part of fast boot and some other hacks found in various places. The important thing is not the details of the protocol but the fact we can boot a board from bare metal. For this month it will only be for panda but having read enough docs and talking to enough people I am confident that the basic idea should work for all the platforms we support today.

[Zach Pfeffer (pfefferz)]

John Rigby ✆ to me
show details 19:15 (21 hours ago)
Zach,

The only folks who build these by hand "know what they are doing" so
there was no script for it. The official ubuntu builds happen in
debian/rules files that are in the packaging directories in bzr so I
did not point you there. Instead, I pulled the logic from the rules
files and created the attached stuff. There is a Makefile and a
couple of files that drive the flavors that get made.

This is not a production makefile but will hopefully give you what you need.

And on a different story, current u-boot-stable master on
git.linaro.org is stuck on a version that worked for bero. He had
trouble with building mx targets. The weird thing was that his
problem was exactly opposite of my observation and of the mx
maintainer upstream so I am a little confused.

[Paul Larson (pwlars)]

John, do you foresee the possibility of a generic version of omap4boot that would work across all boards? This would be a very interesting project

[warmcat (andy-warmcat)]

So... I take it we're booting again and can close this bug?

[Zach Pfeffer (pfefferz)]

We have a working build:

https://android-build.linaro.org/builds/~linaro-android/stage-panda-11.09-release/