l-m-c and hwpacks need to be updated for latest x-loader deb

[John Rigby]

There is a new x-loader source package:

https://launchpad.net/ubuntu/+source/x-loader/1.4.4+git20101223+6f3a261-1ubuntu0

That produces two debs:
x-loader-omap3-beagle containing MLO in ./usr/lib/x-loader/omap3530beagle/MLO
and
x-loader-omap4-panda containing MLO in ./usr/lib/x-loader/omap4430panda/MLO

The old MLO works fine for beagle but the new panda boards require this new MLO.

[Steve Langasek (vorlon)]

Hi John,

On Thu, Jan 13, 2011 at 10:38:07PM -0000, John Rigby wrote:
> That produces two debs:
> x-loader-omap3-beagle containing MLO in ./usr/lib/x-loader/omap3530beagle/MLO
> and
> x-loader-omap4-panda containing MLO in ./usr/lib/x-loader/omap4430panda/MLO

> The old MLO works fine for beagle but the new panda boards require this
> new MLO.

Why the specific path names in these packages? This is
backwards-incompatible with the existing packages and will require
special-casing in linaro-image-tools - and will require us to push updated
linaro-image-tools out for use on released versions of Ubuntu. Are these
paths going to be stable going forward?

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

[John Rigby (jcrigby)]

I don't know how the paths were chosen I was just reporting the change. One method that will work since we only have one platform per deb we can use find to locate the binary then future changes will not break us.

[Loïc Minier (lool)]

First, I'm not sure whether relying on one x-loader or u-boot per .deb is a good idea. This was discussed in an u-boot Debian bug recently:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594937
(I'm not repeating the arguments here)

Second, even if that was the case, multiple .debs could be installed on the same system. I don't have any use case for that, but it would break a "find" expecting exactly one file.

Now, one reason for the issue is that we install bootloaders like x-loader and u-boot in the rootfs, but they wont e.g. get flashed on install or upgrade, they are copied to the boot partition or flashed and then essentially useless! Maybe this will change in the future, but in most cases people don't want their bootloaders to be automatically upgraded on installed system, so it seems we shouldn't be installing them.

Perhaps one way to fix this would be for hwpacks to distinguish between stuff that gets "dpkg -i"-installed in the rootfs, and bootloaders to create the boot partition?

In the short term, I think we're better off updating expected package names / pathnames and trying to be consistent in naming.

[Loïc Minier (lool)]

Current hwpack builds are broken by the package name changes as well.

[Loïc Minier (lool)]

After some discussion on IRC with salgado and asac, we agreed that:
- proper fix involves storing more board information in the hwpacks themselves, but we need time to design this properly
- we need a fix ASAP, so we should go with the find as suggested in this bug; this should work with both maverick and natty hwpacks

[Loïc Minier (lool)]

I've fixed these hwpacks: omap3, omap3-x11-base, panda

I've also rebuilt them; they now use the new package names from the new x-loader source package.

Many things need to be fixed still:
- we should rename omap3 hwpacks to beagle
- we should move away from .deb and ship MLO / u-boot directly
- the hwpacks themselves should host board specific data such as u-boot load address, or command-line args