Igor

This is my situation, but i am using gpios for driving relays with this simple script: ls -l /sys/class/gpio total 0 --w------- 1 root root 4096 Jan 1 1970 export lrwxrwxrwx 1 root root 0 Jan 1 1970 gpiochip0 -> ../../devices/platform/soc/1c20800.pinctrl/gpio/gpiochip0 lrwxrwxrwx 1 root root 0 Jan 1 1970 gpiochip352 -> ../../devices/platform/soc/1f02c00.pinctrl/gpio/gpiochip352 lrwxrwxrwx 1 root root 0 Oct 20 11:22 gpiochip412 -> ../../devices/platform/soc/1c1c000.usb/usb2/2-1/2-1.4/2-1.4.4/2-1.4.4.1/2-1.4.4.1:1.0/gpio/gpiochip412 --w------- 1 root root 4096 Jan 1 1970 unexport If this can help you in some way ...

Thanks to @brentr we got new images with several fixes: https://armbian.atlassian.net/browse/AR-1269 RockPI WiFi assigned different MAC address on each boot https://armbian.atlassian.net/browse/AR-1268 RockPI-S WiFi throughput only 300K bytes/second https://armbian.atlassian.net/browse/AR-1265 Rock PI-S images will not boot from internal EMMC (SDNAND) https://www.armbian.com/rockpi-s/

Patience

An update was sent to stable branch. I believe this problem was fixed, but can't make tests.

This manual needs updating. This is my script that download X86 (for ARM its the same) UEFI image, convert it to qcow2, create bridged VM, run it and run 1st boot steps:

Just leave this problem to someone with a device and know-how.

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.