linaro-media-create fails for snowball_emmc

[Kalle Vahlman]

Using the following command to create a Snowball emmc image fails with current (updated on 18th of August) l-m-c:

linaro-media-create --image_file customSnowballImage.img --dev snowball_emmc --rootfs ext3 --hwpack hwpack_linaro-lt-snowball_20110818-0_armel_supported.tar.gz --binary nano-n-tar-20110818-1.tar.gz

The bottom of the trace is:

  File "/work/snowball/linaro/leb/linaro-image-tools/linaro_image_tools/media_create/boards.py", line 835, in get_file_info
    size = os.path.getsize(filename)
  File "/usr/lib/python2.6/genericpath.py", line 49, in getsize
    return os.stat(filename).st_size
OSError: [Errno 2] No such file or directory: '/tmp/tmpmr5VH2/binary/boot/u-boot.bin'

which would suggest that the u-boot.bin from the u-boot package is not installed correctly. And indeed, looking at the u-boot package it installs u-boot.bin to /usr/lib/u-boot/u8500_snowball and doesn't contain eg. linking to /boot, where the startupfiles package installs its binaries and the configuration that refers to u-boot.bin (and which l-m-c reads when creating the emmc image).

So it seems that either startupfiles should have a startfiles.cfg that points to the correct u-boot location or the u-boot package should install (or link) the u-boot.bin to /boot.

[Matt Waddel (mwaddel)]

I poked around a bit with the hwpack contents and found this patch will allow you to complete the build.

It's brute force and I'm sure there's a better way to do it, but at least it allowed me to finish the image creation.

[James Westby (james-w)]

Hi Mattias, could you have a look at this on Monday morning please?

Thanks,

James

[Mattias Backman (mabac)]

I'd say that the proper fix for this release is to make the u-boot package install the bin in /boot or link to that path, as Kalle suggests. That would make this hwpack behave like all the previous versions, and it's probably the solution with least effort involved.

When time permits we should change the format of the startupfiles.cfg so that absolute file names are specified. This means that the hwpack has to be respun anyway and that older hwpacks might break. Long term it's a better solution since full control is handed to whoever creates the hwpack.

Something along the lines of Matt's patch would work but that would mean dragging along the extra checks for the lifetime of this particular hwpack. I'd like to avoid that unless there's no way we can re-do the hwpack with either a fixed u-boot package or a startfiles packages with absolute paths.

[Mattias Backman (mabac)]

I've put together a fix for this. https://code.launchpad.net/~mabac/linaro-image-tools/bug-829220/+merge/72405

The best way to use it would be to change the startfiles.cfg to use an absolute path for (at least) the u-boot binary. Then we can avoid merging the fallback hack.

A good way would be to change the u-boot package to link to /boot which makes this change unnecessary atm, but it will add support for using absolute paths later to avoid this problem altogether.

As a last resort, no change to the hwpack and land the entire change which works with today's hwpack build.

[Mattias Backman (mabac)]

Support for full snowball startfiles paths in l-m-c added. mpourier is looking into fixing the u-boot package.

[Mattias Backman (mabac)]

Sorry, I didn't release it today.

[Mathieu Poirier (mathieu.poirier-deactivatedaccount)]

The location of u-boot.bin has definitely been moved to boot/. When mabac tested the modification the original problem (this bug) was confirmed to be fixed but the board couldn't be booted. This new problem came from a hwpack tailored for V3 boards while the target board was a V2. Since then a hwpack for V2 boards has been produced.

[Mattias Backman (mabac)]

On Fri, Sep 2, 2011 at 5:13 PM, Mathieu Poirier
<email address hidden> wrote:
> The location of u-boot.bin has definitely been moved to boot/.  When
> mabac tested the modification the original problem (this bug) was
> confirmed to be fixed but the board couldn't be booted.  This new
> problem came from a hwpack tailored for V3 boards while the target board
> was a V2.  Since then a hwpack for V2 boards has been produced.

I hear talk about a Snowball V5 that's on the way. Will we run in to
similar problems and have to create yet another hwpack to support that
hardware revision?

[Mathieu Poirier (mathieu.poirier-deactivatedaccount)]

There is now a hwpack for V2 and V3 boards - testing is required.

[Anmar Oueja (anmar)]

Mattias: The plan is to avoid multiple HWPacks of course. But we won't know until we get the boards in our hands, which hasn't happened yet.

[Mattias Backman (mabac)]

On Thu, Sep 15, 2011 at 9:12 PM, Anmar Oueja <email address hidden> wrote:
> Mattias:  The plan is to avoid multiple HWPacks of course. But we won't
> know until we get the boards in our hands, which hasn't happened yet.

Of course. I just found this table on igloocommunity and figured that
all following versions will be able to use the same startfiles:
    http://igloocommunity.org/support/Board_versions_and_markings

We'll have to wait and see of course.