Igor

Not happening to me. On any of those: dtb-5.15.72-sunxi dtb-5.19.14-sunxi Anyway, problems solved!

I don't know why, but images indeed had old boot loader. I have rebuild images (22.08.6) and they work fine on my Nanopi Neo. Boot log: https://paste.armbian.com/aqinezihen Serial console: U-Boot 2022.07-armbian (Oct 15 2022 - 16:00:51 +0000) Allwinner Technology CPU: Allwinner H3 (SUN8I 1680) Model: FriendlyARM NanoPi NEO DRAM: 256 MiB Core: 63 devices, 17 uclasses, devicetree: separate WDT: Not starting watchdog@1c20ca0 MMC: mmc@1c0f000: 0, mmc@1c11000: 1 Loading Environment from FAT... Unable to use mmc 0:1... In: serial Out: serial Err: serial Net: phy interface1 eth0: ethernet@1c30000 starting USB... Bus usb@1c1a000: USB EHCI 1.00 Bus usb@1c1a400: USB OHCI 1.0 Bus usb@1c1d000: USB EHCI 1.00 Bus usb@1c1d400: USB OHCI 1.0 scanning bus usb@1c1a000 for devices... 1 USB Device(s) found scanning bus usb@1c1a400 for devices... 1 USB Device(s) found scanning bus usb@1c1d000 for devices... 1 USB Device(s) found scanning bus usb@1c1d400 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/boot.scr 4021 bytes read in 3 ms (1.3 MiB/s) ## Executing script at 43100000 U-boot loaded from SD

This is completely normal if you are running rolling release. It seems we will remove all those builds meant for testings as people does not understand what is their purpose.

Where did you download "Armbian" for Bananapi M5?

Its 2022 and you are using u-boot from 2020. Latest images and repository have 2022.07. This is first problem that needs to be adjusted. Nobody knows anyomore which bugs are hidden in that old version https://github.com/armbian/build/commit/3cb7175c667da480e59ef5b9bb23e238b4955cdf

We added many fixes to the installer in past two weeks. Please re-try with latest images (build today) from download section. And use armbian-install, which is going to replace old nand-sata-install tool once we are sure it doesn't break legacy installations.

Are you trying this with a latest software from the download section?

This fix already inside?

We provide beta.armbian.com for that, just s/apt/beta on armbian.list. It contains packages that are build upon code change (and every day if there are any changes) in this process https://github.com/armbian/build/actions/workflows/build-train.yml

You don't need to do anything as Armbian developers studied this in deep many years ago and adjust it best. Arnbian by default does this for you. Enjoy using it. If you care to understand, use search above and find original topics from 2015/16.

You have checked this https://linux-sunxi.org/GPIO ?

1. Each kernel upgrade usually fix something, messes something else. Speaking generally. In case of this device, this rarely happen, as its old. If you look more into the details, https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/drivers/gpio?h=v5.15.72 someone is fixing something else or just try to do it differently. Which is causing that our patched stopped working. Just a collateral damage. 2. He is the one you need to wait. I would state this already before, but we don't want that anyone put additional pressure, especially if problem is known and this can only helps that we don't do anything more ... you can also hire someone, pay him few hours, and share a patch with community. Why this should be his or my personal expense? Use provided workaround. Alternatives always exists.

I apologize for troubles, but that's all I can do. We finance maintaining and dealing with our "customers" almost in 100% so its always difficult to answer such questions. We are talking about few hours of work. If you would cover that, we would not have this conversation in first place. Don't know. Task is open to the person that knows something about and will not need weeks, just hours. It can take days, weeks ... years. To get there. Then an update must be pushed out which will almost certainly break something else. And someone else will ask for our attention, call for responsibility, ... Upstream delivers only general patches. I have removed this update from repository so at least nobody else got into the troubles. Which were, like usually, caused by upstream.

Workaround: armbian-config -> system -> alternative kernel , pick previous, freeze, wait

New fixes for armbian-install https://github.com/armbian/build/pull/4271 Common UEFI ARM64 image can boot from u-boot 2022.07 installed on NanoPC T4 eMMC. GRUB works even in serial console ... UEFI installation to eMMC is covered with this MR, perhaps some hardening / code cleaning is needed. It also works to NVME, but u-boot does not recognise it, so we can't boot from it. Alternatively we could hack this - to ask user where he wants to have EFI partition (eMMC). Perhaps adding that option too?

So far this is only planned: https://armbian.atlassian.net/browse/AR-1283 But as we pack kernels for many distro and as we cross-compile, this might cause some troubles. This is further complicating as we provide 56 different kernel binaries ... (that number will certainly go down). Welcome!

https://www.armbian.com/rock-5b/

AFAIK this feature is no enabled by default. It must work pretty much this way: https://www.lisenet.com/2013/set-up-wake-on-lan-wol-on-a-debian-wheezy-server/ This is known problem and we are developing things toward solution. We produce all different Docker images for that reason https://github.com/armbian/build/pkgs/container/build but what is missing is building header package under each one and store them into different repositories. Fix for that was just merged https://github.com/armbian/build/pull/4263 and updates are pushing out ASAP.

Starting this way https://www.armbian.com/bugs/ significantly improve chances to get some help.

Add: rm /root/.not_logged_in_yet Ref: https://github.com/armbian/build/blob/master/packages/bsp/common/usr/lib/armbian/armbian-firstlogin#L302 but this will disable whole 1st login procedure - check if script is doing something you might need.

What about recent ones from here https://github.com/armbian/community (those builds are unchecked - mainstream support only)

So you think adding this would be enough?

We are getting close to: cut & merge to it?

media. And all those that are going to be merged into generic kernel. I have also spoke about this with @ManoftheSeaas his Espressobin can also be moved there without any issues. To be on the safe side, kernel configs should be merged (media-*, mvebu64-*) to the arm64 generic kernel. If not already. mvebu family is good for another reasons - it covers one board only, which results in little testings needed. Yes. I assume it should just boot it? I haven't tried it yet. No DTB is IMO not that critical problem ... main question is how to make this change to be best from maintainership perspective. It has to be straight understandable if you look at the code structure. Currently we have chaos shattered around many locations. Then there is Rpi, which drags its own flash-image way, which is complicated and poorly maintained Debian version of our platform-install. We need to replace this too.