On 2019-04-15, Danny Milosavljevic wrote:
> On Wed, 10 Apr 2019 15:22:18 -0700
> Vagrant Cascadian <vagrant@debian.org> wrote:
>
>> > 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.
>
> That would make the parted bindings a hard dependency, probably even
> build-side.  But I think that would still be better than the alternative:
> destroying user filesystems.

Could do some math; e.g. the offset is 768, first sector is 2048. So if
2048-768-(size-of-in-sectors u-boot.img) >> 0, it should be ok. Better
checking that done currently, at least.

But more sophisticated, of course, would be checking the actual layout
of the partition table... some targets (pine64+/pinebook) have offsets
that conflict with GPT partition tables, for example.


>> 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).
>
> Yeah, I think sooner or later it's going to come to this.  Might as well
> bite the bullet now.

Hmmm...


>> In light of all that, I'm not sure what a proper way forward is...
>
> Yeah, sounds like a bad situation with no nice solution that allows
> updating of existing installations.  In that case, keeping existing
> installations on the old version would be preferrable to breaking
> them.

Short of that, here's an updated u-boot 2019.04 patch that:

- Generates a u-boot-am335x-boneblack package with a slightly modified
  am335x_evm configuration removing extra device-trees; that *should* be
  small enough to fit with the common partition tables (but so far
  untested). It theoretically has about 80k of wiggle-room for
  u-boot.img to grow before it becomes a problem again.

- Better commented patch fixing mkimage to pass test-imagetools test
  suite. Patch was accepted in at least one of the maintainer trees
  upstream.

live well,
  vagrant