Bug#928863: Bug#928861: flash-kernel: Please add an entry for FriendlyArm NanoPi NEO 2
Hi all, It seems I missed some messages here and yesterday I realized it, I apologize for the delay. I prepared a MR to add the last bits for NanoPI NEO Air inclusion in the installer [0]. Please merge. Kind regards, Domenico [0] https://salsa.debian.org/installer-team/debian-installer/-/merge_requests/15 -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05
Bug#928861: flash-kernel: Please add an entry for FriendlyArm NanoPi NEO 2
Domenico Andreoli writes: > Now NanoPi Neo2 is supported out of the box, thanks everybody for the > support :) Does that cover the NanoPi Neo AIR as well? If not, I have a few of those, so would be happy to do any testing needed to make sure they are supported too. Cheers, Phil. P.S. I'll need pointers towards how one is expected to run d-i on these little things though, as I've never done anything more complicated with them than grabbing an e.g. Armbian image, and sticking it on an SD card. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#928861: flash-kernel: Please add an entry for FriendlyArm NanoPi NEO 2
Hi, On Thu, May 23, 2019 at 09:18:26AM +0200, Domenico Andreoli wrote: > On Tue, May 14, 2019 at 11:22:14PM -0700, Vagrant Cascadian wrote: > > > ... > > I'm thinking we should just merge the flash-kernel support, which will > > make it much easier to test properly, and can be reverted if need be... > > Vagrant, can we merge it or do you want me to do some other test before? After flash-kernel 3.99 migrated to testing I could try the new d-i nightly build. I created the sdcard using the firmware+partitions approach and successfully installed and booted the new system. I'll send a complete installation report once RC2 is out. Now NanoPi Neo2 is supported out of the box, thanks everybody for the support :) Regards, Domenico -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 signature.asc Description: PGP signature
Bug#928861: flash-kernel: Please add an entry for FriendlyArm NanoPi NEO 2
On Tue, May 14, 2019 at 11:22:14PM -0700, Vagrant Cascadian wrote: > ... > I'm thinking we should just merge the flash-kernel support, which will > make it much easier to test properly, and can be reverted if need be... Vagrant, can we merge it or do you want me to do some other test before? I've the feeling that situation stalled but I don't see what could be the reason and what else I could do to unblock it. I see a glowing green button "Merge" on Salsa, and I could even press it, but is there any planned upload of the package? > > Since kibi merged the NanoPI NEO 2 debian-installer support, and I just > added support for SD-card-images, it should be much easier to test. > When the daily images for 20190516 are generated they should include > "netboot/SD-card-images" for several allwinner arm64 boards: > > https://d-i.debian.org/daily-images/arm64/ > > Then, as long as you don't rewrite the partition table, you should be > able to install to microSD and it won't create a GPT partition table and > won't use grub-efi... and it should use the flash-kernel boot.scr! As reported in [0], the installer worked nicely except that it did not create any boot.scr, I did not make any tweak during the installation. > > live well, > vagrant thanks, Domenico [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928863 -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 signature.asc Description: PGP signature
Bug#928861: flash-kernel: Please add an entry for FriendlyArm NanoPi NEO 2
On Wed, May 15, 2019 at 08:06:53AM -0700, Vagrant Cascadian wrote: > On 2019-05-15, Domenico Andreoli wrote: > > Scanning mmc 0:2... > > Found /boot/extlinux/extlinux.conf > > Retrieving file: /boot/extlinux/extlinux.conf > > 753 bytes read in 12 ms (60.5 KiB/s) > > U-Boot menu > > 1: Debian GNU/Linux kernel 4.19.0-4-arm64 > > 2: Debian GNU/Linux kernel 4.19.0-4-arm64 (rescue target) > > Enter choice: 1:Debian GNU/Linux kernel 4.19.0-4-arm64 > > To test flash-kernel's boot.scr, you'll need to remove or disable > checking for extlinux.conf, since that comes before loading the boot.scr > that flash-kernel produces. Right, sharp eye! > > From the u-boot prompt unset the the variable that checks for extlinux: > > setenv scan_dev_for_extlinux false > > Alternately, remove /boot/extlinux/extlinux.conf and reboot. Ok, uninstalled u-boot-menu and grub packages (and all the related config & co files). Emptied the first partition and moved /boot into it. Now the system boots without manual intervention, no user/grub clutters the bootlog any more ;) U-Boot SPL 2019.01+dfsg-6 (May 12 2019 - 01:20:19 +) DRAM: 1024 MiB Trying to boot from MMC1 NOTICE: BL31: v2.0(debug): NOTICE: BL31: Built : 23:33:29, Nov 27 2018 NOTICE: BL31: Detected Allwinner H5 SoC (1718) NOTICE: BL31: Found U-Boot DTB at 0x407f100, model: FriendlyARM NanoPi NEO 2 INFO:ARM GICv2 driver initialized INFO:Configuring SPC Controller NOTICE: BL31: PMIC: Defaulting to PortL GPIO according to H5 reference design. INFO:BL31: Platform setup done INFO:BL31: Initializing runtime services INFO:BL31: cortex_a53: CPU workaround for 855873 was applied INFO:BL31: Preparing for EL3 exit to normal world INFO:Entry point address = 0x4a00 INFO:SPSR = 0x3c9 U-Boot 2019.01+dfsg-6 (May 12 2019 - 01:20:19 +) Allwinner Technology CPU: Allwinner H5 (SUN50I) Model: FriendlyARM NanoPi NEO 2 DRAM: 1 GiB MMC: SUNXI SD/MMC: 0 Loading Environment from FAT... Unable to use mmc 0:1... In:serial Out: serial Err: serial Net: phy interface7 eth0: ethernet@1c3 starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 USB2: USB EHCI 1.00 USB3: USB OHCI 1.0 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 2 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot.scr 2228 bytes read in 5 ms (434.6 KiB/s) ## Executing script at 4fc0 18558832 bytes read in 824 ms (21.5 MiB/s) 16815 bytes read in 10 ms (1.6 MiB/s) 24721329 bytes read in 1092 ms (21.6 MiB/s) Booting Debian 4.19.0-4-arm64 from mmc 0:1... ## Flattened Device Tree blob at 4fa0 Booting using the fdt blob at 0x4fa0 EHCI failed to shut down host controller. EHCI failed to shut down host controller. Loading Ramdisk to 4886c000, end 49fff7b1 ... OK Loading Device Tree to 48864000, end 4886b1ae ... OK Starting kernel ... [0.00] Booting Linux on physical CPU 0x00 [0x410fd034] [0.00] Linux version 4.19.0-4-arm64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-2)) #1 SMP Debian 4.19.28-2 (2019-03-15) [0.00] Machine model: FriendlyARM NanoPi NEO 2 [0.00] efi: Getting EFI parameters from FDT: [0.00] efi: UEFI not found. [0.00] cma: Reserved 64 MiB at 0x7c00 [0.00] NUMA: No NUMA configuration found [0.00] NUMA: Faking a node at [mem 0x-0x7fff] [0.00] NUMA: NODE_DATA [mem 0x7bfdd5c0-0x7bfded7f] [0.00] Zone ranges: [0.00] DMA32[mem 0x4000-0x7fff] [0.00] Normal empty [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x4000-0x7fff] [0.00] Initmem setup node 0 [mem 0x4000-0x7fff] [0.00] psci: probing for conduit method from DT. [0.00] psci: PSCIv1.1 detected in firmware. [0.00] psci: Using standard PSCI v0.2 function IDs [0.00] psci: MIGRATE_INFO_TYPE not supported. [0.00] psci: SMC Calling Convention v1.1 [0.00] random: get_random_bytes called from start_kernel+0x9c/0x4c0 with crng_init=0 [0.00] percpu: Embedded 24 pages/cpu @(ptrval) s60120 r8192 d29992 u98304 [0.00] Detected VIPT I-cache on CPU0 [0.00] CPU features: enabling workaround for ARM erratum 845719 [0.00] Speculative Store Bypass Disable mitigation not required [0.00] CPU features: detected: Kernel page table isolation (KPTI) [0.00] Built 1 zonelists, mobility grouping on. Total pages: 258048 [0.00] Policy zone: DMA32 [0.00] Kernel command line: console=ttyS0,115200 panic=7 [0.00] Memory: 923100K/104857
Bug#928861: flash-kernel: Please add an entry for FriendlyArm NanoPi NEO 2
On 2019-05-15, Domenico Andreoli wrote: > Scanning mmc 0:2... > Found /boot/extlinux/extlinux.conf > Retrieving file: /boot/extlinux/extlinux.conf > 753 bytes read in 12 ms (60.5 KiB/s) > U-Boot menu > 1: Debian GNU/Linux kernel 4.19.0-4-arm64 > 2: Debian GNU/Linux kernel 4.19.0-4-arm64 (rescue target) > Enter choice: 1:Debian GNU/Linux kernel 4.19.0-4-arm64 To test flash-kernel's boot.scr, you'll need to remove or disable checking for extlinux.conf, since that comes before loading the boot.scr that flash-kernel produces. From the u-boot prompt unset the the variable that checks for extlinux: setenv scan_dev_for_extlinux false Alternately, remove /boot/extlinux/extlinux.conf and reboot. live well, vagrant signature.asc Description: PGP signature
Bug#928861: flash-kernel: Please add an entry for FriendlyArm NanoPi NEO 2
On Tue, May 14, 2019 at 11:02:14AM -0700, Vagrant Cascadian wrote:
> On 2019-05-14, Domenico Andreoli wrote:
> >
...
> 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.
editenv.. nice, I did not know it. Anyway, here is the bootlog:
U-Boot SPL 2019.01+dfsg-6 (May 12 2019 - 01:20:19 +)
DRAM: 1024 MiB
Trying to boot from MMC1
NOTICE: BL31: v2.0(debug):
NOTICE: BL31: Built : 23:33:29, Nov 27 2018
NOTICE: BL31: Detected Allwinner H5 SoC (1718)
NOTICE: BL31: Found U-Boot DTB at 0x407f100, model: FriendlyARM NanoPi NEO 2
INFO:ARM GICv2 driver initialized
INFO:Configuring SPC Controller
NOTICE: BL31: PMIC: Defaulting to PortL GPIO according to H5 reference design.
INFO:BL31: Platform setup done
INFO:BL31: Initializing runtime services
INFO:BL31: cortex_a53: CPU workaround for 855873 was applied
INFO:BL31: Preparing for EL3 exit to normal world
INFO:Entry point address = 0x4a00
INFO:SPSR = 0x3c9
U-Boot 2019.01+dfsg-6 (May 12 2019 - 01:20:19 +) Allwinner Technology
CPU: Allwinner H5 (SUN50I)
Model: FriendlyARM NanoPi NEO 2
DRAM: 1 GiB
MMC: SUNXI SD/MMC: 0
Loading Environment from FAT... *** Warning - bad CRC, using default environment
In:serial
Out: serial
Err: serial
Net: phy interface7
eth0: ethernet@1c3
starting USB...
USB0: USB EHCI 1.00
USB1: USB OHCI 1.0
USB2: USB EHCI 1.00
USB3: USB OHCI 1.0
scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 2 for devices... 1 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot: 0
=>
=>
=>
=>
=>
=>
=>
=> editenv scan_dev_for_boot_part
edit: part list ${devtype} ${devnum} -bootable devplist; env exists devplist;
setenv devplist 2; for distro_bootpart
=>
=>
=>
=> boot
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:2...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
753 bytes read in 12 ms (60.5 KiB/s)
U-Boot menu
1: Debian GNU/Linux kernel 4.19.0-4-arm64
2: Debian GNU/Linux kernel 4.19.0-4-arm64 (rescue target)
Enter choice: 1:Debian GNU/Linux kernel 4.19.0-4-arm64
Retrieving file: /boot/initrd.img-4.19.0-4-arm64
24721329 bytes read in 1119 ms (21.1 MiB/s)
Retrieving file: /boot/vmlinuz-4.19.0-4-arm64
18558832 bytes read in 839 ms (21.1 MiB/s)
append: root=UUID=ffb5c903-632b-49c7-a435-885cc2490423 ro panic=7
Retrieving file:
/usr/lib/linux-image-4.19.0-4-arm64/allwinner/sun50i-h5-nanopi-neo2.dtb
16815 bytes read in 32 ms (512.7 KiB/s)
## Flattened Device Tree blob at 4fa0
Booting using the fdt blob at 0x4fa0
EHCI failed to shut down host controller.
EHCI failed to shut down host controller.
Loading Ramdisk to 4886c000, end 49fff7b1 ... OK
Loading Device Tree to 48864000, end 4886b1ae ... OK
Starting kernel ...
[0.00] Booting Linux on physical CPU 0x00 [0x410fd034]
[0.00] Linux version 4.19.0-4-arm64 (debian-ker...@lists.debian.org)
(gcc version 8.3.0 (Debian 8.3.0-2)) #1SMP Debian 4.19.28-2 (2019-03-15)
[0.00] Machine model: FriendlyARM NanoPi NEO 2
[0.00] efi: Getting EFI parameters from FDT:
[0.00] efi: UEFI not found.
[0.00] cma: Reserved 64 MiB at 0x7c00
[0.00] NUMA: No NUMA configuration found
[0.00] NUMA: Faking a node at [mem
0x-0x7fff]
[0.00] NUMA: NODE_DATA [mem 0x7bfdd5c0-0x7bfded7f]
[0.00] Zone ranges:
[0.00] DMA32[mem 0x4000-0x7fff]
[0.00] Normal empty
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00] node 0: [mem 0x4000-0x7fff]
[0.00] Initmem setup node 0 [mem 0x4000-0x7fff]
[0.00] psci: probing for conduit method from DT.
[0.00] psci: PSCIv1.1 detected in firmware.
[0.00] psci: Using standard PSCI v0.2 function IDs
[0.00] psci: MIGRATE_INFO_TYPE not supported.
[0.00] psci: SMC Calling Convention v1.1
[0.00] random: get_random_bytes called from start_kernel+0x9c/0x4c0
with crng_init=0
[0.00] percpu: Embedded 24 pages/cpu @(ptrval) s60120 r8192
d29992 u98304
[0.00] Detected VIPT I-cache on CPU0
[0.00] CPU features: enabling workaround for ARM erratum 845719
[0.00] Speculative Store Bypass Disable mitigation not required
[0.00] CPU features: detected: Ke
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. >> ... >> > 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. ... >> 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 ... I'm thinking we should just merge the flash-kernel support, which will make it much easier to test properly, and can be reverted if need be... Since kibi merged the NanoPI NEO 2 debian-installer support, and I just added support for SD-card-images, it should be much easier to test. When the daily images for 20190516 are generated they should include "netboot/SD-card-images" for several allwinner arm64 boards: https://d-i.debian.org/daily-images/arm64/ Then, as long as you don't rewrite the partition table, you should be able to install to microSD and it won't create a GPT partition table and won't use grub-efi... and it should use the flash-kernel boot.scr! live well, vagrant signature.asc Description: PGP signature
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 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 signature.asc Description: PGP signature
Bug#928861: flash-kernel: Please add an entry for FriendlyArm NanoPi NEO 2
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 signature.asc Description: PGP signature
Bug#928861: flash-kernel: Please add an entry for FriendlyArm NanoPi NEO 2
On 2019-05-12, Karsten Merker wrote: > On Sun, May 12, 2019 at 10:40:39AM +0200, Domenico Andreoli wrote: >> +Machine: FriendlyARM NanoPi NEO 2 >> +Kernel-Flavors: arm64 >> +Boot-Script-Path: /boot/boot.scr >> +DTB-Id: allwinner/sun50i-h5-nanopi-neo2.dtb >> +U-Boot-Script-Name: bootscr.uboot-generic >> +Required-Packages: u-boot-tools >> + >> >> I was not able to cross-build the arm64 installer from amd64 so the >> patch is not tested. >> >> 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? 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 ... live well, vagrant signature.asc Description: PGP signature
Bug#928861: flash-kernel: Please add an entry for FriendlyArm NanoPi NEO 2
Package: flash-kernel Version: 3.98 Severity: wishlist Tags: patch Dear Maintainer, please add the new entry for supporting FriendlyArm NanoPi NEO 2. Patch is attached but also MR is available on Salsa: https://salsa.debian.org/installer-team/flash-kernel/merge_requests/5 This is the entry: +Machine: FriendlyARM NanoPi NEO 2 +Kernel-Flavors: arm64 +Boot-Script-Path: /boot/boot.scr +DTB-Id: allwinner/sun50i-h5-nanopi-neo2.dtb +U-Boot-Script-Name: bootscr.uboot-generic +Required-Packages: u-boot-tools + I was not able to cross-build the arm64 installer from amd64 so the patch is not tested. Please mind that the NanoPi NEO 2 target for u-boot has just been merged in sid so it's not yet in Buster. Regards, Domenico -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 commit 6ccf67adb6b44e7b7173420840b7d564f328020e Author: Domenico Andreoli Date: Sun May 12 09:49:10 2019 +0200 Add support for NanoPi NEO2 diff --git a/db/all.db b/db/all.db index 0839d50..fe740ae 100644 --- a/db/all.db +++ b/db/all.db @@ -481,6 +481,13 @@ DTB-Id: sun8i-h3-nanopi-neo-air.dtb U-Boot-Script-Name: bootscr.sunxi Required-Packages: u-boot-tools +Machine: FriendlyARM NanoPi NEO 2 +Kernel-Flavors: arm64 +Boot-Script-Path: /boot/boot.scr +DTB-Id: allwinner/sun50i-h5-nanopi-neo2.dtb +U-Boot-Script-Name: bootscr.uboot-generic +Required-Packages: u-boot-tools + Machine: Gemei G9 Tablet Kernel-Flavors: armmp Boot-Script-Path: /boot/boot.scr signature.asc Description: PGP signature
