Igor

Do you understand what "best effort support" means? And why software is released under such terms? Don't you think we would not rather tell you - "dear users. Thank you for downloading our investment. If you have any problems with your computer, come, we will be happy to solve it " - if that would be possible? Check support terms once again and try to understand who pays that? When you are taking your car to the car repair shop. Do you expect they will pay for the parts and service or is that on you to cover? Its not about you. This community has limited answering capacity and if you don't behave, you are only lowering your chances of getting attention. Look around - you are not the only one asking for something.

Problem was fixed in sources, but images still have this purely cosmetic problem. Operation of full images rebuilt is very expensive as it takes several days. You do expect images are tested, even that is almost exclusively our private cost. There is nothing more to support. Problem was solved. If you are not satisfied with a solution and you want more then your contracts provides, I am gladly willing to help you on commercial terms.

Desire is getting bigger but if there is no time ... Can you at least give me some directions so I don't start from scratch?

U-boot is not Armbian thing. We build it. You can build u-boot / kernel only - 1st switch in manual. You get deb files which you install to the system and update via armbian-config ... if system boots. If not, you need to flash it manually. Manually means - extracting binaries from that deb file alongside with the script that does the flashing. And run commands by hand. Apparently this board will need modified u-boot configuration which is defined in build system this way. Example of generating a dedicated configuration that doesn't exists upstream. For enabling USB scan its probably a switch within u-boot. Like I said, this is outside Armbian and I would tell you if I know, but without digging into the code (manuals are usually within the code), I have no clue. Check what FriendlyElec did to the u-boot they are using. Its some old one, so many things could be done differently ... but sometimes you can get some clues out of it. Possible solution is setting CONFIG_USB_EHCI_HCD to n ... Hope this helps.

Looking at your u-boot version it seems you haven't flashed correct image. Images from download section (22.08.6) have boot loader: U-Boot 2022.07-armbian (Oct 15 2022 - 16:00:51 +0000) Allwinner Technology

Just a reminder, if someone wants to fix it.

This is Armbian forum. We have no idea how stock software is glued together. Try to use Armbian. Hardware functions are enabled and disabled via armbian-config (if overlays exists). And all you need to do is - enable / disable + reboot. Or you can use DT editor and tackle with the DTS. No rebuild needed.

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.