All Activity

i think there is not even useable nand support in the mainline allwinner kernel, so chances are close to zero to get this working currently

Update maintainers and board status synced status from the database rename to .csc where we don't have anyone If you want to become a board maintainer, adjust data here. Ref: Board Maintainers Procedures and Guidelines Contribute View the full article

Description Attempt to work towards one U-Boot bootscript for (at least) mvebu, sunxi and rockchip64. This adds: (Aligned) load address calculations This will remove the need to update any kernel_load_addr_r or ramdisk_addr_r in case kernel image increases. Calculation is based on either Flat kernel image image_size + text_offset as specified in the vmlinux(/Image) header info Compressed kernel image filesize (vmlinuz/zImage) Clear warnings to user in case files are not found, not able to load or application failed. Merge of armbianEnv.txt kernel options was attempted for sunxi, mvebu and rockchip64. DT folder determination based on sunxi approach. DT file determination based on sunxi approach. Compat with /boot/dtb/fdtfile.dtb and /boot/dtb/vendor/fdtfile.dtb. Simplified some constructs by assuming U-Boot has successfully sourced us with a set of pre-set variables, like ${prefix} ${devtype} etc. Actively set the ${kernel_comp_*} parameters based on calculations of load addresses. Ability to select different kernel/initrd by setting kver in armbianEnv.txt Also: Any warning or error includes a 10 second delay to make sure the user is able to see and read them. Any "informative" message added by the bootscript can be silenced by setting verbosity to 0 Attempted to make the bootscript 'reentrant' in away: all variables required for proper (re)execution are set, which should allow for the entire bootscript to be re-run on a next boot_target. All variables used in for-loops are actively cleared from the environment to ensure for loops work as expected. Any pre-set variable that might be used in next boot_target will be reset whenever necessary. Documentation summary for feature / change [ ] short description (copy / paste of PR title) [x] summary (description relevant for end users) Load address calculation can be disabled by adding load_addr_calc=off to armbianEnv.txt Load address calculation OBOE avoidance can be disabled by adding align_overlap_oboe_avoidance=off to armbianEnv.txt User can set custom fdtdir and fdtfile in armbianEnv.txt, but make sure to only specify DT filename in fdtfile. fdtdir will be used to both load DT, DT overlays and fixup scripts [ ] example of usage (how to see this in function) How Has This Been Tested? [x] Orangepi Zero (first gen):[12:39:52] U-Boot SPL 2024.01-armbian-2024.01-S866c-P6b16-Ha5c2-V367a-Bb703-R448a (Apr 29 2025 - 02:50:09 +0000) [12:39:52] DRAM: 512 MiB [12:39:52] Trying to boot from MMC1 [12:39:53] ns16550_serial serial@1c28000: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 [12:39:53] U-Boot 2024.01-armbian-2024.01-S866c-P6b16-Ha5c2-V367a-Bb703-R448a (Apr 29 2025 - 02:50:09 +0000) Allwinner Technology [12:39:53] CPU: Allwinner H3 (SUN8I 1680) [12:39:53] Model: Xunlong Orange Pi Zero [12:39:53] DRAM: 512 MiB [12:39:53] Core: 70 devices, 19 uclasses, devicetree: separate [12:39:53] WDT: Not starting watchdog@1c20ca0 [12:39:53] MMC: mmc@1c0f000: 0, mmc@1c10000: 1 [12:39:53] Loading Environment from FAT... Unable to use mmc 0:1... [12:39:53] In: serial,usbkbd [12:39:53] Out: serial [12:39:53] Err: serial [12:39:53] Starting SCP... [12:39:53] Net: SCP/INF: Crust v0.6.10000 [12:39:53] eth0: ethernet@1c30000 [12:39:53] starting USB... [12:39:53] Bus usb@1c1a000: sun4i_usb_phy phy@1c19400: External vbus detected, not enabling our own vbus [12:39:53] USB EHCI 1.00 [12:39:53] Bus usb@1c1a400: USB OHCI 1.0 [12:39:53] Bus usb@1c1b000: USB EHCI 1.00 [12:39:53] Bus usb@1c1b400: USB OHCI 1.0 [12:39:53] Bus usb@1c1c000: USB EHCI 1.00 [12:39:53] Bus usb@1c1c400: USB OHCI 1.0 [12:39:53] scanning bus usb@1c1a000 for devices... 1 USB Device(s) found [12:39:54] scanning bus usb@1c1a400 for devices... 1 USB Device(s) found [12:39:55] scanning bus usb@1c1b000 for devices... 1 USB Device(s) found [12:39:56] scanning bus usb@1c1b400 for devices... 1 USB Device(s) found [12:39:57] scanning bus usb@1c1c000 for devices... 1 USB Device(s) found [12:39:59] scanning bus usb@1c1c400 for devices... 1 USB Device(s) found [12:40:00] scanning usb for storage devices... 0 Storage Device(s) found [12:40:00] Autoboot in 1 seconds, press <Space> to stop [12:40:01] switch to partitions #0, OK [12:40:01] mmc0 is current device [12:40:01] Scanning mmc 0:1... [12:40:01] Found U-Boot script /boot/boot.scr [12:40:01] 18117 bytes read in 4 ms (4.3 MiB/s) [12:40:01] ## Executing script at 43100000 [12:40:01] Boot script loaded from mmc 0:1. [12:40:01] 687 bytes read in 3 ms (223.6 KiB/s) [12:40:01] Loaded/imported environment /boot/armbianEnv.txt to/from 0x45000000. [12:40:01] Found mainline kernel configuration. [12:40:01] 35473 bytes read in 11 ms (3.1 MiB/s) [12:40:01] Loaded DT /boot/dtb/sun8i-h2-plus-orangepi-zero.dtb to 0x43000000. [12:40:01] Working FDT set to 43000000 [12:40:01] Loading kernel provided DT overlay(s) from /boot/dtb/overlay to 0x45000000 .. [12:40:01] 504 bytes read in 10 ms (48.8 KiB/s) [12:40:01] Applied DT overlay usbhost2 (/boot/dtb/overlay/sun8i-h3-usbhost2.dtbo). [12:40:01] 504 bytes read in 10 ms (48.8 KiB/s) [12:40:01] Applied DT overlay usbhost3 (/boot/dtb/overlay/sun8i-h3-usbhost3.dtbo). [12:40:01] 617 bytes read in 10 ms (59.6 KiB/s) [12:40:01] Applied DT overlay tve (/boot/dtb/overlay/sun8i-h3-tve.dtbo). [12:40:01] 374 bytes read in 9 ms (40 KiB/s) [12:40:01] Applied DT overlay i2c0 (/boot/dtb/overlay/sun8i-h3-i2c0.dtbo). [12:40:01] Loading user provided DT overlay(s) from /boot/overlay-user to 0x45000000 .. [12:40:01] 835 bytes read in 3 ms (271.5 KiB/s) [12:40:01] Applied user DT overlay rtc0-i2c-ds3231-rtc1-soc (/boot/overlay-user/rtc0-i2c-ds3231-rtc1-soc.dtbo). [12:40:01] 4185 bytes read in 10 ms (408.2 KiB/s) [12:40:01] ## Executing script at 45000000 [12:40:01] Loaded/sourced fixup script /boot/dtb/overlay/sun8i-h3-fixup.scr to/at 0x45000000. [12:40:02] 10554192 bytes read in 441 ms (22.8 MiB/s) [12:40:02] Loaded compressed kernel image /boot/zImage to 4300a000. [12:40:02] Using compressed kernel image filesize 0xa10b50 bytes to calculate initial ramdisk load address. [12:40:02] 11621101 bytes read in 484 ms (22.9 MiB/s) [12:40:02] Loaded initial ramdisk /boot/uInitrd to 43a1b000. [12:40:02] Unknown command 'kaslrseed' - try 'help' [12:40:02] Not able to prepare for KASLR. [12:40:02] Kernel commandline arguments: [12:40:02] root=/dev/nfs [12:40:02] rootfstype=nfs [12:40:02] rootwait [12:40:02] splash=verbose [12:40:02] earlycon [12:40:02] console=ttyS0,115200 [12:40:02] consoleblank=0 [12:40:02] loglevel=8 [12:40:02] ubootpart=81f6566a-01 [12:40:02] usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u,0x174c:0x55aa:u [12:40:02] dwc_otg.fiq_enable=0 [12:40:02] net.ifnames=0 [12:40:02] ipv6.disable=1 [12:40:02] rw [12:40:02] nfsroot=192.168.2.34:/export/rootfs/blippi [12:40:02] ip=dhcp [12:40:02] nfsrootdebug [12:40:02] nfs.enable_ino64=0 [12:40:02] cgroup_enable=cpuset [12:40:02] cgroup_memory=1 [12:40:02] cgroup_enable=memory [12:40:02] Kernel image @ 0x4300a000 [ 0x000000 - 0xa10b50 ] [12:40:02] ## Loading init Ramdisk from Legacy Image at 43a1b000 ... [12:40:02] Image Name: uInitrd [12:40:02] Image Type: ARM Linux RAMDisk Image (gzip compressed) [12:40:02] Data Size: 11621037 Bytes = 11.1 MiB [12:40:02] Load Address: 00000000 [12:40:02] Entry Point: 00000000 [12:40:02] Verifying Checksum ... OK [12:40:02] ## Flattened Device Tree blob at 43000000 [12:40:02] Booting using the fdt blob at 0x43000000 [12:40:02] Working FDT set to 43000000 [12:40:02] Loading Ramdisk to 494ea000, end 49fff2ad ... OK [12:40:02] Loading Device Tree to 494de000, end 494e9fff ... OK [12:40:02] Working FDT set to 494de000 [12:40:02] Starting kernel ... [12:40:03] [ 0.000000] Booting Linux on physical CPU 0x0 [x] Orangepi zero (first gen): OKU-Boot SPL 2024.01-armbian (Feb 23 2024 - 10:47:39 +0000) DRAM: 256 MiB Trying to boot from MMC1 ns16550_serial serial@1c28000: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 U-Boot 2024.01-armbian (Feb 23 2024 - 10:47:39 +0000) Allwinner Technology CPU: Allwinner H3 (SUN8I 1680) Model: Xunlong Orange Pi Zero DRAM: 256 MiB Core: 70 devices, 19 uclasses, devicetree: separate WDT: Not starting watchdog@1c20ca0 MMC: mmc@1c0f000: 0, mmc@1c10000: 1 Loading Environment from FAT... Unable to use mmc 0:1... In: serial,usbkbd Out: serial Err: serial Starting SCP... Net: SCP/INF: Crust v0.6.10000 eth0: ethernet@1c30000 starting USB... Bus usb@1c1a000: sun4i_usb_phy phy@1c19400: External vbus detected, not enabling our own vbus USB EHCI 1.00 Bus usb@1c1a400: USB OHCI 1.0 Bus usb@1c1b000: USB EHCI 1.00 Bus usb@1c1b400: USB OHCI 1.0 Bus usb@1c1c000: USB EHCI 1.00 Bus usb@1c1c400: 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@1c1b000 for devices... 1 USB Device(s) found scanning bus usb@1c1b400 for devices... 1 USB Device(s) found scanning bus usb@1c1c000 for devices... 1 USB Device(s) found scanning bus usb@1c1c400 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Autoboot in 1 seconds, press <Space> to stop switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 18202 bytes read in 5 ms (3.5 MiB/s) ## Executing script at 43100000 Boot script loaded from mmc 0:1. 265 bytes read in 4 ms (64.5 KiB/s) Loaded/imported environment /boot/armbianEnv.txt to/from 0x45000000. Found mainline kernel configuration. 35473 bytes read in 9 ms (3.8 MiB/s) Loaded DT /boot/dtb/sun8i-h2-plus-orangepi-zero.dtb to 0x43000000. Working FDT set to 43000000 Loading kernel provided DT overlay(s) from /boot/dtb/overlay to 0x45000000 .. 504 bytes read in 11 ms (43.9 KiB/s) Applied DT overlay usbhost2 (/boot/dtb/overlay/sun8i-h3-usbhost2.dtbo). 504 bytes read in 12 ms (41 KiB/s) Applied DT overlay usbhost3 (/boot/dtb/overlay/sun8i-h3-usbhost3.dtbo). 4185 bytes read in 11 ms (371.1 KiB/s) ## Executing script at 45000000 Loaded/sourced fixup script /boot/dtb/overlay/sun8i-h3-fixup.scr to/at 0x45000000. 10554192 bytes read in 442 ms (22.8 MiB/s) Loaded compressed kernel image /boot/zImage to 4300a000. Using compressed kernel image filesize 0xa10b50 bytes to calculate initial ramdisk load address. 11867098 bytes read in 497 ms (22.8 MiB/s) Loaded initial ramdisk /boot/uInitrd to 43a1b000. Unknown command 'kaslrseed' - try 'help' Not able to prepare for KASLR. Kernel commandline arguments: root=PARTUUID=1c01f668-02 rootfstype=f2fs rootwait splash=verbose console=ttyS0,115200 consoleblank=0 loglevel=8 ubootpart=1c01f668-01 usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u,0x174c:0x55aa:u net.ifnames=0 ipv6.disable=1 cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory Kernel image @ 0x4300a000 [ 0x000000 - 0xa10b50 ] ## Loading init Ramdisk from Legacy Image at 43a1b000 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 11867034 Bytes = 11.3 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 43000000 Booting using the fdt blob at 0x43000000 Working FDT set to 43000000 Loading Ramdisk to 494ae000, end 49fff39a ... OK Loading Device Tree to 494a2000, end 494adfff ... OK Working FDT set to 494a2000 Starting kernel ... Checklist: [ ] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [x] I have commented my code, particularly in hard-to-understand areas [ ] My changes generate no new warnings New warnings introduced: Environment load failed Environment import failed DT load/application failed DT (user) overlay load/application failed Initial ramdisk load failed Kernel image load failed Boot failed [x] Any dependent changes have been merged and published in downstream modules Prequisite U-Boot setexpr command already merged via https://github.com/armbian/build/pull/8260. View the full article

I understand, but would I be able to do it officially?

We don't support 3rd party forks

Good afternoon. I need a little help here. I managed to compile a working version for this board. However, it does not recognize the internal disk, which in this case is a nand. I used this repo: https://github.com/sicXnull/armbian-build.git Branch: X96Q-5.1-DDR3 Could someone help me?

Also Check your PSU if the problem is intermittent.

In one post here I saw a "please buy hardware we recommend" quote, and I appreciate that, but I wasn't able to find a recommended boards list - is there even one? Or should I just use the standard/platinum support filtering on the main page? Anyway, I could also use some help / recommendation for a general purpose SBC as I ... didn't by one for years. I'm looking for a more recent SBC to run a small, low power server (think pihole, homeassistant, zigbee, etc). I don't have specific requirements, but I'd like the board to have some kind of "long term support" and I'd also like to choose something that the armbian team would recommend, maybe from a manufacturer that supports armbian directly, or at least provides good documentation. Headless install, may use GPIO, at least 3 USB ports, built-in ethernet + wifi + BT (not sure if there's an SBC that would support zigbee natively?). And also, avoid using an SD card. Ability to use eMMC or SSD would be important. Where I'm coming from: I still run two first-gen Raspberry Pis as webcams + dataloggers (the 26 pin GPIO ones with 256 and 512 MB RAM respectively) and I used OrangePi One and Lite as two surprisingly stable servers for years (one a small postfix mailserver + datalogger, the other even running 4 docker containers). I like using low-level hardware to its limits🙂 I have recently upgraded to an already outdated OrangePi PC+ that I found in the drawer - at least it has 1 GB of RAM and I was starting running into limits with the 512 MB ones. So yeah - I don't need the top of the range SBC but something ... reasonably priced (think ~40 €) that will run well for years to come. I heard good stuff about the Radxa boards with Rockchip SoCs but I have no experience as I haven't bought new SBCs in ... years. Thanks in advance 🙂

In this final article of a three-part series, I look at locking with C++ and Matt Godbolt's notion of CADR. View the full article

Hi, I got new H96 Max M9S and would like to ask some questions before flashing armbian on the device. 1. In this thread reset button is mentioned and I cannot find one on the case and neither on the board. Is there o photo of it or is it another name for maskrom switch? 2. I intend to flash from Linux, is the following method correct: - put device in maskrom mode - connect it to a computer by a USB A-A cable (to USB 2.0 port) - on a computer: rkdeveloptool ld (to list recognized devices) - on a computer: rkdeveloptool db RK3576_MiniLoaderAll.bin - on a computer: rkdeveloptool wl 0 h96_max_m9s_rk3576_20240930_1033.img - restart H96 Max M9S I also have a question regarding building Armbian image: which dtb file should I use to put in directory build/packages/blobs/h96-m9/ (is it H96-RK3576-BOX.dtb)? Best Regards and keep up the good work.

Having trouble with my klipper accelerometer every time the dtb is upgraded during a update/upgrade. I made this patch to fix the spi@5011000 { ...} section: 831c831 < status = "disabled"; --- > status = "okay"; 834a835,840 > spidev@0 { > compatible = "armbian,spi-dev"; > reg = <0x00>; > spi-max-frequency = <0xf4240>; > }; > And then dtc -I dtb -O dts -o sun50i-h6-orangepi-3-lts.dts /boot/dtb/allwinner/sun50i-h6-orangepi-3-lts.dtb patch -b sun50i-h6-orangepi-3-lts.dtso opi3lts-dtb.patch dtc -I dts -O dtb -o /boot/dtb/allwinner/sun50i-h6-orangepi-3-lts.dtb sun50i-h6-orangepi-3-lts.dts Not sure if this is a sane and safe way to do it, but it works for me at least. Hope it can find it's way in a sane form into a future release. Maybe it's better to do it in an overlay, rather than directly? opi3lts-dtb.patch

Hi, Not an expert here, but some educated guesses would be related to either timing, blocksizes towards the devices. Anything that might change or increase the amount of ATA commands towards the disks would be my bet to look at. You could experiment with enabling/disabling NCQ, reducing read-ahead, increasing chunksizes in case you use [software] RAID, increasing caching by tweaking vm options. Perhaps even the IO schedulers, there might have been some new IO schedulers introduced on the new kernel that show different behavior compared to the older kernel, etc. Groetjes,

Hi, If you want to know which kernel is used for your build, just run: ./compile.sh inventory-boards This will take some time. Open the resulting .csv file, which will contain all combinations possible. Groetjes,

I found an incredibly roundabout way of doing this. ./compile.sh \ kernel \ BOARD=$OPT_ARMBIAN_BOARD \ BRANCH=$OPT_ARMBIAN_KERNEL \ CLEAN_LEVEL=make,alldebs,images,cache \ EXPERT=yes \ PREFER_DOCKER=yes \ KERNEL_GIT=shallow KERNEL_CONFIG=$(find $KERNEL_DIR/cache/sources/linux-kernel-worktree -name .config) if [ ! -f $KERNEL_CONFIG ] then echo "Failed to find .config" exit 1 fi FULL_KERNEL_VERSION=$(cat $KERNEL_CONFIG | grep "Kernel Configuration" | grep -oE '[0-9]+\.[0-9]+\.[0-9]+') if [ "$FULL_KERNEL_VERSION" == "" ] then echo "Failed to get full kernel version." exit 1 fi

Thanks for the detailed description! Very useful post, especially for those who are just starting to tinker with Armbian on TV boxes. I had a similar situation with another S905X3 box - neither Wi-Fi nor Bluetooth worked, and there was trouble with HDMI audio. Special thanks for the advice on disabling unattended-upgrades and systemd-networkd-wait-online, I just encountered problems with long loading, now I understand where the legs are growing from. Regarding USB audio - an excellent solution, I didn't even know that it was so easy to bypass the lack of built-in sound. I will try with a similar adapter. If you have a chance, tell me later whether you managed to set up Wi-Fi via a USB adapter or in another way. And I wonder if you tried other window environments besides XFCE? LXQt, for example? In any case - a great guide, thanks for your work!

Description Currently, PocketBeagle 2 edge images cannot build (without patch 1) and fails to boot (without patch 3). The patch one just defines the missing variable for OPTEE. Patch 3 specifies root using path instead of UUID. For some reason, UUID does not work with PocketBeagle 2 U-boot. How Has This Been Tested? Tested on PocketBeagle 2 rev A0 Checklist: Please delete options that are not relevant. [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [x] I have commented my code, particularly in hard-to-understand areas [x] My changes generate no new warnings [x] Any dependent changes have been merged and published in downstream modules View the full article

Look at your board config file: config/boards/orangepi5b.csc In there you will find the board family, which in your case is: BOARDFAMILY="rockchip-rk3588" Then look at the corresponding board family config file: config/sources/families/rockchip-rk3588.conf There you will find a section for each branch (i.e vendor, current, edge) that will specify which kernel source is used: For BRANCH=vendor that would currently be: KERNELSOURCE='https://github.com/armbian/linux-rockchip.git' KERNELBRANCH='branch:rk-6.1-rkr5.1' KERNELPATCHDIR='rk35xx-vendor-6.1'

i.e. git clone -b main --depth 1 https://github.com/armbian/build.git cd build # I want to find out what kernel my board is building befor here. ./compile.sh kernel BOARD=orangepi5b BRANCH=vendor EXPERT=yes PREFER_DOCKER=yes KERNEL_GIT=shallow I need to do this so I can apply patches based on the selected kernel verison (e.g. 5.10, 6.1, 6.12) as they are all different patches due to Makefile changes. I don't see a clean way to do this with the builder unless I build the kernel first, search the kernel sources and then determine the kernel that way.

Hi ... thanks for your hint. Actually I forced on the old system sata speed to 3.0 GB ... which I did not on the new installation. Setting also the link speed to 3.0 GB did however not solve the issue, I had to set it down to 1.5 GB. Now the issue seems to be gone. Performancewise it is not noticeable for harddisks, but for the SSD I have it is - need to look further into it. I'm just wondering what (still) the difference is. Forcing link speed down to 1.5 GB was not needed before ... I'm tending to exclude "hardware" as source of issues, as the hardware is in both cases identicial, no single cable touched. CU Alex

Description The idea is to introduce the possibility to cache downloads from GH runners to lower downstream bandwidth used and increase overall speed. Especially on machines with lots of runner this could save quite some bandwidth while sacrificing disk space. http caching has been tested and seem to work nicely. https caching is a lot more tricky and may be introduced later. This PR has two parts: set apt repository to http instead of https where possible. Packages are signed anyways. Pass various proxy environment variables to docker so it respects those. Doesn't make sense not to pass them since when using PREFER_DOCKER=no and any of these variables are set beforehand they just work. So this more or less just harmonizes overall behavior. There is still an issue on line 4838 caused by https://github.com/armbian/build/blob/c0da65087aad628ba0714f23d8d29800f152d97c/lib/functions/rootfs/apt-install.sh#L67 due to absence of apt proxy setting there. Not sure why this is not added here? How Has This Been Tested? Please describe the tests that you ran to verify your changes. Please also note any relevant details for your test configuration. [x] build random image: https://paste.armbian.de/xopitiguyo , look for 10.100.0.87 to see where it is used [x] built the same random image but having all proxy env variables unset beforehand: builds just fine as well: https://paste.armbian.de/ozidivugor Checklist: [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [x] I have commented my code, particularly in hard-to-understand areas [x] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article

Hi, without owning this board, chatgpt is pointing out to an initialisation issue of the bluetooth system caused by the GPIO pin not being correctly handled at boot. [ 6.024062] WCN: marlin chip en dummy pull up -- need manually set GPIO The correct solution would be to handle the init in the dtb file, but you can try the following systemd initialisation as a workaround to see if it works. Create (as root) the following service file /etc/systemd/system/bt-gpio.service with the contents: [Unit] Description=Enable GPIO for Bluetooth chip Before=bluetooth.service [Service] Type=oneshot ExecStart=/bin/sh -c 'echo 225 > /sys/class/gpio/export || true; echo out > /sys/class/gpio/gpio225/direction; echo 1 > /sys/class/gpio/gpio225/value' [Install] WantedBy=multi-user.target Then enable it (as root): systemctl daemon-reexec systemctl daemon-reload systemctl enable bt-gpio.service Reboot and check if the bluetooth starts correctly. Post the boot log if it does not.

Description Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change. This PR adds the RT kernel config file for TI devices. If RT_KERNEL=yes is passed as an argument to ./compile.sh, a PREEMPT_RT image is built. How Has This Been Tested? Please describe the tests that you ran to verify your changes. Please also note any relevant details for your test configuration. Tested this on SK-AM62B. Test 1: boot test: the board successfully booted Test 2: uname -a test: PREEMPT_RT string was present in the output, thus suggesting that its indeed an RT image Test 3: zcat /proc/config.gz | grep -i RT: Further confirmed that the PREEMPT_RT config is enabled in the running image Checklist: Please delete options that are not relevant. [ ] My code follows the style guidelines of this project [ ] I have performed a self-review of my own code [ ] My changes generate no new warnings cc: @glneo @Grippy98 @nmenon @sadik-smd View the full article

direct boot from nvme isn't possible. Boot loader (u-boot to say) must be present on SPI, eMMC or microSD.

try: sudo gpg --keyserver keyserver.ubuntu.com --recv-keys 93D6889F9F0E78D5 sudo gpg --export 93D6889F9F0E78D5 | sudo tee /etc/apt/trusted.gpg.d/armbian-configng.gpg > /dev/null

sudo armbian-config