[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#928861: flash-kernel: Please add an entry for FriendlyArm NanoPi NEO 2

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


  ... env exists devplist || setenv devplist 1 ...


  ... 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

> * 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


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,

Attachment: signature.asc
Description: PGP signature

Reply to: