On 2019-05-14, Domenico Andreoli wrote: > 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. ... >> 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. u-boot will look for a partition marked bootable, which is different for GPT partition tables, and falls back to the first partition if neither an msdos bootable partition nor a gpt bootable partition is found. You can interrupt the boot process at the u-boot prompt and change...: editenv scan_dev_for_boot_part change: ... env exists devplist || setenv devplist 1 ... to: ... env exists devplist ; setenv devplist 3 ... Assuming partition 3 is where /boot/boot.scr resides. >> 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 :) Before it runs flash-kernel, but after it's installed... or something. I haven't ever done that part. > Aside from that, a few other things are not clear to me: > > * is it true that Debian arm64 implies UEFI+grub? I think the goal was to stick to EFI on arm64 on Debian, but I think some hardware vendors have implemented some things in a way that makes that more difficult (e.g. allwinner 64-bit device offsets conflicting with standard GPT partitioning). > if not, how does e.g. Pine64 handle bare u-boot vs u-boot + grub? Manual configuration of the partition table. I *think* if you set the debconf priority to low it gives you the option to create an MSDOS/MBR style partition table. On my pinebook's initial installation, I managed to install with GPT partition tables and u-boot+EFI+GRUB and that sort of worked, except it wiped out the bootloader. Then I managed to convert the GPT partition table to MSDOS/MBR and re-installed u-boot and I've been using that ever since. > * is the partition table label (msdos vs. gpt) dependent on the board? > if not, how does e.g. Pine64 handle GPT + spl? Apparently it may be possible to install any of the 64-bit allwinner boards with a specially crafted GPT partition table with few enough partitions: https://salsa.debian.org/debian/u-boot/merge_requests/6 I haven't verified that it works yet. Or if simply creating four or fewer partitions will work correctly from the installer. > Is an updated flash-kernel-installer udeb going to automagically solve > all the above issues or am I missing some other moving part here? Definitely not, unfortunately. > I'm definitively impressed by the evolution reached to handle all the > specially crafted variants supported out of the box. > > Thanks for the support. Working on it ... still a long ways to go! Thanks for your help adding one more board! live well, vagrant
Attachment:
signature.asc
Description: PGP signature