Should install u-boot and x-loader on IGEP

I thought this would be a bug against linaro-images as that's where we
define which goes in each hwpack, no? l-m-c will just install whatever
packages are listed in the hwpack's manifest...

The hwpack does have:
packages=linux-image-linaro-omap u-boot-linaro-igep0020 x-loader-omap3-igepv2 libertas-firmware wireless-tools wpasupplicant

I think it does get installed in the rootfs, but there is no u-boot flavor set, so it doesn't get matched?

Oh, right, so the packages are already in the hwpack and installed in
the rootfs but IGEP's config doesn't tell l-m-c to copy the u-boot.bin
to the boot partition. (The x-loader's MLO should be handled correctly
for IGEP)

ISTM that all we need is to set uboot_flavor to "igep0020" in
IgepConfig, but as Loïc pointed out, we need to make sure that doesn't
break l-m-c with 10.11 images, which don't have the u-boot package
installed.

 status triaged
 importance medium

I'm demilestoning this bug, it was a nice target for opportunity, but it didn't happen timely.

An easier approach is to just implement this next cycle unconditionally for IGEP as it will have been two cycles with u-boot + x-loader included in the hwpacks

Mattias, tried with hwpack v2, as described at https://code.launchpad.net/~rsalveti/linaro-images/hwpack.natty.linaro-igep, but got the following error while creating the image:

Traceback (most recent call last):
  File "./linaro-media-create", line 161, in <module>
    args.is_live, args.is_lowmem, args.consoles)
  File "/home/rsalveti/projects/linaro/linaro-image-tools/linaro_image_tools/media_create/boards.py", line 598, in populate_boot
    "uboot_in_boot_part is set but not uboot_flavor")
AssertionError: uboot_in_boot_part is set but not uboot_flavor

This is caused because the assert is called at populate_boot even if we're using v2:
"""
    def populate_boot(cls, chroot_dir, rootfs_uuid, boot_partition, boot_disk,
                      boot_device_or_file, is_live, is_lowmem, consoles):
        parts_dir = 'boot'
        if is_live:
            parts_dir = 'casper'
        uboot_parts_dir = os.path.join(chroot_dir, parts_dir)

        cmd_runner.run(['mkdir', '-p', boot_disk]).wait()
        with partition_mounted(boot_partition, boot_disk):
            if cls.uboot_in_boot_part:
                assert cls.uboot_flavor is not None, (
                    "uboot_in_boot_part is set but not uboot_flavor")
...
"""

With branch lp:~mabac/linaro-image-tools/igep-fix this error is gone, but then I noticed that the MLO is also not copied to the first partition, probably because IgepConfig defines it's own _make_boot_files, without calling install_omap_boot_loader.

On Mon, 12 Sep 2011 14:51:41 -0000, Ricardo Salveti <email address hidden> wrote:
> With branch lp:~mabac/linaro-image-tools/igep-fix this error is gone,
> but then I noticed that the MLO is also not copied to the first
> partition, probably because IgepConfig defines it's own
> _make_boot_files, without calling install_omap_boot_loader.

With hwpack v2 the IgepConfig class shouldn't be used, so that code
shouldn't be triggered, suggesting that the bug is somewhere else.

At least, that's my understanding of what should be happening :-)

Thanks,

James

On Mon, Sep 12, 2011 at 5:11 PM, James Westby <email address hidden> wrote:
> On Mon, 12 Sep 2011 14:51:41 -0000, Ricardo Salveti <email address hidden> wrote:
>> With branch lp:~mabac/linaro-image-tools/igep-fix this error is gone,
>> but then I noticed that the MLO is also not copied to the first
>> partition, probably because IgepConfig defines it's own
>> _make_boot_files, without calling install_omap_boot_loader.
>
> With hwpack v2 the IgepConfig class shouldn't be used, so that code
> shouldn't be triggered, suggesting that the bug is somewhere else.
>
> At least, that's my understanding of what should be happening :-)

That's what should be happening, yes. That will be the reality RSN. ;)
I forgot that I identified one more thing that needs work which is
exactly this: "Consolidate _make_boot_files() which is still board
specific: TODO". Initially I thought this was semi trivial but I
must've missed that IgepConfig does not look like the others.

>
> Thanks,
>
> James
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/716627
>
> Title:
>  Should install u-boot and x-loader on IGEP
>
> Status in Linaro Image Tools:
>  Triaged
>
> Bug description:
>  Hi
>
>  We now have x-loader and u-boot for IGEP in the hwpack, we should
>  install them.
>
>  These weren't in the 10.11 hwpack, so we need to allow for the files
>  to be missing.
>
>  An u-boot bug currently prevents this from being useful; bug #716540
>
>  Bye
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/linaro-image-tools/+bug/716627/+subscriptions
>

On Tue, Sep 13, 2011 at 4:14 AM, Mattias Backman
<email address hidden> wrote:
> On Mon, Sep 12, 2011 at 5:11 PM, James Westby <email address hidden> wrote:
>> On Mon, 12 Sep 2011 14:51:41 -0000, Ricardo Salveti <email address hidden> wrote:
>>> With branch lp:~mabac/linaro-image-tools/igep-fix this error is gone,
>>> but then I noticed that the MLO is also not copied to the first
>>> partition, probably because IgepConfig defines it's own
>>> _make_boot_files, without calling install_omap_boot_loader.
>>
>> With hwpack v2 the IgepConfig class shouldn't be used, so that code
>> shouldn't be triggered, suggesting that the bug is somewhere else.
>>
>> At least, that's my understanding of what should be happening :-)
>
> That's what should be happening, yes. That will be the reality RSN. ;)
> I forgot that I identified one more thing that needs work which is
> exactly this: "Consolidate _make_boot_files() which is still board
> specific: TODO". Initially I thought this was semi trivial but I
> must've missed that IgepConfig does not look like the others.

I don't mind fixing the Igep support even for V1, if that helps
getting it to work with V2, but the only requirement is that it should
still be able to work with previous hwpacks (copying x-loader/u-boot
should not be mandatory).

I have merged the make_boot_files changes which allows x-loader to be copied for any board without being mandatory. Can you give it a try?

Still broken for me, but because of another bug.

Call trace with current trunk:
`/tmp/tmpkA7QQp/u-boot/u-boot.bin' -> `/tmp/tmpEetHIm/boot-disc/u-boot.bin'
Traceback (most recent call last):
  File "./linaro-media-create", line 170, in <module>
    args.is_live, args.is_lowmem, args.consoles)
  File "/home/rsalveti/projects/linaro/linaro-image-tools/linaro_image_tools/media_create/boards.py", line 706, in populate_boot
    rootfs_uuid, boot_disk, boot_device_or_file)
  File "/home/rsalveti/projects/linaro/linaro-image-tools/linaro_image_tools/media_create/boards.py", line 817, in make_boot_files
    rootfs_uuid, boot_dir, boot_device_or_file)
  File "/home/rsalveti/projects/linaro/linaro-image-tools/linaro_image_tools/media_create/boards.py", line 587, in make_boot_files
    parts_dir)
  File "/home/rsalveti/projects/linaro/linaro-image-tools/linaro_image_tools/media_create/boards.py", line 714, in _get_kflavor_files
    return cls._get_kflavor_files_v2(path)
  File "/home/rsalveti/projects/linaro/linaro-image-tools/linaro_image_tools/media_create/boards.py", line 753, in _get_kflavor_files_v2
    "No kernel found matching %s." % (cls.vmlinuz))
ValueError: No kernel found matching vmlinuz-*-linaro-omap.

This is happening because path is pointing to chroot instead of chroot/boot, because of the following change:
270 def make_boot_files(cls, uboot_parts_dir, is_live, is_lowmem, consoles,
271 chroot_dir, rootfs_uuid, boot_dir, boot_device_or_file):
272 + if cls.hwpack_format == HardwarepackHandler.FORMAT_1:
273 + parts_dir = uboot_parts_dir
274 + else:
275 + parts_dir = chroot_dir

uboot_parts_dir is basically chroot_dir + "boot", so it works fine with V1 but then with V2 it fails as it'll try to look for the kernel file at chroot_dir instead.

Why can't we just use uboot_parts_dir for both? (and the variable name seems weird, as it's nothing actually related with uboot).

On Mon, 19 Sep 2011 16:10:54 -0000, Ricardo Salveti <email address hidden> wrote:
> Still broken for me, but because of another bug.
>
> Call trace with current trunk:
> `/tmp/tmpkA7QQp/u-boot/u-boot.bin' -> `/tmp/tmpEetHIm/boot-disc/u-boot.bin'
> Traceback (most recent call last):
> File "./linaro-media-create", line 170, in <module>
> args.is_live, args.is_lowmem, args.consoles)
> File "/home/rsalveti/projects/linaro/linaro-image-tools/linaro_image_tools/media_create/boards.py", line 706, in populate_boot
> rootfs_uuid, boot_disk, boot_device_or_file)
> File "/home/rsalveti/projects/linaro/linaro-image-tools/linaro_image_tools/media_create/boards.py", line 817, in make_boot_files
> rootfs_uuid, boot_dir, boot_device_or_file)
> File "/home/rsalveti/projects/linaro/linaro-image-tools/linaro_image_tools/media_create/boards.py", line 587, in make_boot_files
> parts_dir)
> File "/home/rsalveti/projects/linaro/linaro-image-tools/linaro_image_tools/media_create/boards.py", line 714, in _get_kflavor_files
> return cls._get_kflavor_files_v2(path)
> File "/home/rsalveti/projects/linaro/linaro-image-tools/linaro_image_tools/media_create/boards.py", line 753, in _get_kflavor_files_v2
> "No kernel found matching %s." % (cls.vmlinuz))
> ValueError: No kernel found matching vmlinuz-*-linaro-omap.
>
> This is happening because path is pointing to chroot instead of chroot/boot, because of the following change:
> 270 def make_boot_files(cls, uboot_parts_dir, is_live, is_lowmem, consoles,
> 271 chroot_dir, rootfs_uuid, boot_dir, boot_device_or_file):
> 272 + if cls.hwpack_format == HardwarepackHandler.FORMAT_1:
> 273 + parts_dir = uboot_parts_dir
> 274 + else:
> 275 + parts_dir = chroot_dir
>
> uboot_parts_dir is basically chroot_dir + "boot", so it works fine with
> V1 but then with V2 it fails as it'll try to look for the kernel file at
> chroot_dir instead.
>
> Why can't we just use uboot_parts_dir for both? (and the variable name
> seems weird, as it's nothing actually related with uboot).

Hi,

If you use the change that Mattias proposed for the hwpack config at

  https://code.launchpad.net/~mabac/linaro-images/hwpack.oneiric.linaro-igep/+merge/75989

then this should work.

We aren't assuming that things are found in /boot as we were burnt
recently by files moving to different directories, and explicit is
better than implicit.

Thanks,

James

On Mon, Sep 19, 2011 at 1:50 PM, James Westby <email address hidden> wrote:
> If you use the change that Mattias proposed for the hwpack config at
>
>  https://code.launchpad.net/~mabac/linaro-images/hwpack.oneiric.linaro-
> igep/+merge/75989
>
> then this should work.

Oh, true, didn't notice this merge proposal this morning when testing
l-i-t, thanks for the pointer.

> We aren't assuming that things are found in /boot as we were burnt
> recently by files moving to different directories, and explicit is
> better than implicit.

Fair enough, will merge the branch at the hwpack tree and test it
again with current l-i-t trunk.

Tested with latest trunk and it worked as expected:
evatp boot # ls -l
total 5956
-rw-r--r-- 1 rsalveti rsalveti 312 2011-09-19 16:57 board.dtb
-rw-r--r-- 1 rsalveti rsalveti 508 2011-09-19 16:57 boot.ini
-rw-r--r-- 1 rsalveti rsalveti 508 2011-09-19 16:57 boot.scr
-rw-r--r-- 1 rsalveti rsalveti 436 2011-09-19 16:57 boot.txt
-rw-r--r-- 1 rsalveti rsalveti 21588 2011-09-19 16:57 MLO
-rw-r--r-- 1 rsalveti rsalveti 253352 2011-09-19 16:57 u-boot.bin
-rw-r--r-- 1 rsalveti rsalveti 3948896 2011-09-19 16:57 uImage
-rw-r--r-- 1 rsalveti rsalveti 1871432 2011-09-19 16:57 uInitrd