On Sun, May 12, 2019 at 10:13:50AM -0700, Vagrant Cascadian wrote: > On 2019-05-12, Karsten Merker wrote: > > On Sun, May 12, 2019 at 10:40:39AM +0200, Domenico Andreoli wrote: > > > ... > > > > > > Please mind that the NanoPi NEO 2 target for u-boot has just been merged > > > in sid so it's not yet in Buster. > ... > > while the change looks ok to me, I'd very much prefer if it was > > actually tested before committing it (the same is true for > > bug#928863). > > Would it be ok to test it in-place on an installed system by adding the > entry to /etc/flash-kernel/db? That's how I usually test boards I've > added. Or do you not have an installed system? Yes, I've a running system and the locally built flash-kernel now creates a nice boot.scr in /boot. Now the problem is that my first partition is for EFI (I installed with regular Buster RC1 installer) and so u-boot does not find the newly created boot.scr and just goes with grub. If I put the boot.scr in the EFI partition, grub is still used. I'm a bit struggling to understand why. I'll try to manually boot with boot.scr, just to validate it. > > It's a bit difficult to fully test within debian-installer, as the > installer typically pulls in .udebs from the archive, and you have a bit > of chicken-and-egg problem to require testing from d-i, or a lot of > manual fiddling within the installer. You could also patch > /target/etc/flash-kernel/db or /target/usr/share/flash-kernel/db from > within the install at just the right moment ... Thanks for the trick but you don't say when it's the right moment :) Aside from that, a few other things are not clear to me: * is it true that Debian arm64 implies UEFI+grub? if not, how does e.g. Pine64 handle bare u-boot vs u-boot + grub? * is the partition table label (msdos vs. gpt) dependent on the board? if not, how does e.g. Pine64 handle GPT + spl? Is an updated flash-kernel-installer udeb going to automagically solve all the above issues or am I missing some other moving part here? I'm definitively impressed by the evolution reached to handle all the specially crafted variants supported out of the box. Thanks for the support. Regards, Domenico -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13
Attachment:
signature.asc
Description: PGP signature