Am 2018-02-18 um 01:22 schrieb Vagrant Cascadian:
> I do think we should consider replacing flash-kernel with something else
> at this point. The tool has grown and evolved all sorts of features;
> I've never used it to "flash a kernel". I've exclusively used it for
> purposes other than it's original design (mostly just copying a .dtb and
> generating a boot script that is essentially re-useable on most boards I
> use it with).
> Scalability is a bit questionable; it actually cats the entire contents
> of all.db and reads it into a variable, and then does "echo $VARIABLE |
> grep FOO" type things in order to get data out of it. With new sunxi
> boards coming out what *feels* like twice each week, grepping through an
> echo'ed variable starts to seem like a bad idea to me.
> Of course, it also kind of works well enough for what it is... but
> adding new features is, in my experience, an unpleasant task. And
> occasionally those new features are really needed with modern changes.
> I've used u-boot-menu on a handful of boards, although it also currently
> has some limitations. For example, it doesn't support /boot on a
> separate partition without manual configuration ... anyone remember the
> lovely hack "ln -s . /boot/boot" ... well, yeah... using *that*
> again. It also doesn't handle copying the .dtb into /boot, so I still
> need flash-kernel for that.
> And then there's the support for u-boot emulating EFI so you could use
> grub-efi-*, which has made great progress in recent u-boot versions. But
> then we could use grub on more platforms ... that would be a nice goal
> for buster, at least.
Yes, I'd appreciate grub.
When debugging the boot process with an encrypted rootfs on my Odroid
XU4s I found it very comfortable to be able to easily switch between
boot configurations with grub (which I had thanks to sesse's install
script for XU4). And maybe it's not just me, because one of the usage
scenarios for SBCs will be self-hosted services (think of freedombox),
for which disk encryption can be an issue.