[bug#35217] gnu: u-boot: Update to 2019.04.

[Vagrant Cascadian <vagrant@debian.org>]

[-- Attachment #1: Type: text/plain, Size: 1629 bytes --]

> On 2019-04-10, Vagrant Cascadian wrote:
> * gnu/packages/bootloaders (u-boot): Update to 2019.04.
...
>   (u-boot-am335x-evm): New variable.
>   (u-boot-am335x-boneblack): Deprecate variable.

The am335x-boneblack configuration was dropped from upstream.

The am335x-evm image is considerably larger than the am335x-boneblack
images, which leads to issues when installing at a device offset, as it
will overwrite the first partition unless the first partition starts
significantly later than most tools (parted, cfdisk) default of sector
2048 (beagleboard.org images start the first partition at sector 8192).

The embedded-os-installation code should probably check to make sure
they aren't trampling the first partition if installing to the raw
device offset.

Alternately, it's possible to copy the u-boot.img onto the first FAT
partition of the microSD/eMMC, which will be loaded instead of the
offset. But that takes some rethinking of how to install the bootloader
(which would be good to not diverge from upstream for other platforms,
such as u-boot-novena).

I've unsuccessfully tried to make a minimal variant of the am335x-evm
that only supports the beaglebone black, by removing the other device
trees, which made it considerably smaller, but not small enough.
Disabling NAND and related features might still be possible, but I
haven't managed to get a configuration that compiles.

So there's no clear upgrade path for existing beaglebone black installs.

The upside to all this is that am335x-evm supports multiple boards!

In light of all that, I'm not sure what a proper way forward is...


live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]