Igor

It should work in both cases. I am running it from NVME. But with eMMC boot. SPI boot loader is broken.

Fail 3 times. https://github.com/armbian/build/blob/master/packages/bsp/common/usr/lib/armbian/armbian-firstlogin#L252-L298 Or set a proper password once and then change your password at any time. But it annoys me a bit too. One possible solution is to just issue a warning or specifically asks you - are you sure to use unsafe password.

If you are talking about build host support, then this commit is adding support.

This is how mainline Linux looks like. Features breaks all the time (caused by constant kernel changes / development) and its impossible to track as this is simply too expensive. Linux distributions in majority are not doing any testings of those functions, while our test system is too primitive to detect something like this. A few more hundreds of thousands would be needed to put in, which is, in case you want free service, impossible. If detection would be made, someone needs to invest hours to fix it. Currently waiting things, average resolving rate = 400 days. So you have an idea how little you are investing into maintenance on top and around chaotic mainline Linux experience. Workaround? Those usually always exists. One of them is going to armbian-config -> system -> other kernels and switch to older kernel, where this function was working. Then freeze kernel (which is anyway good thing for production deployment) and check from time to time if this was fixes. No, nobody will send you email when this will be fixed ...

Armbian usually has better hardware support then Ubuntu. Especially on ARM. https://docs.armbian.com/#what-is-armbian

Of course. We are using pretty much unchanged kernel from Rpi foundation. Did you check here https://github.com/raspberrypi/linux/issues ?

I think there is nothing wrong if those are added to the defaults: https://github.com/armbian/build/blob/master/packages/blobs/desktop/skel/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-keyboard-shortcuts.xml https://docs.armbian.com/Process_Contribute/

In general we don't have much archives for those as they were not yet fully supported. We still don't have a dedicated maintainer, while I can't keep an eye also on this hardware. Automated test builds are made automatically directly from development branch - those are expected to break here and there. I have rebuild images from stable branch right now. Please check if they work for you: https://www.armbian.com/rpi4b/ (I have tested Armbian_22.08.7_Rpi4b_jammy_current_5.15.74_gnome_desktop.img.xz on Rpi 400 and looks fine)

Additional changes has been applied to the download pages - moving automated builds at the end, greying them out, adding additional remarks. Stable + automated builds https://www.armbian.com/rpi4b/ Automated only: https://www.armbian.com/rock-5b/ Those automated are ATM present only for WIP / rolling targets (such as Rpi or Rockpi 5b) but all others could get them.

Currently we only maintain 5.15.y mvebu as for everything else we don't have time to catch up https://armbian.atlassian.net/browse/AR-1313

How problems looks like? Try this: (armbian-config -> alternative kernels) https://imola.armbian.com/apt/pool/main/l/linux-5.15.72-bcm2711/

Patience for getting human response on whatever your problem is. Before you are going to switch some problems with another, please read this FAQ.

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.