All Activity

Hi again, Quick update for potential other readers, and some questions. I've now also got overlayroot setup to keep the internal flash mounted as readonly for normal operation. So as to not burn through the flash's endurance counters within a year on a device that's writing logs, status information, etc. to flash continuously. And also to protect it against issues when people just pull the plug while it's operational, potentially corrupting flash and making it unusable without physical recovery. Seems to be working great, but had to adjust the initramfs hook and script files (mount -o move instead of mount --move in script, and adding lines to copy_exec /bin/grep, /usr/bin/stat, and /bin/echo to the initramfs. Seems to be working just great including with pikvm. Two questions: My rk3318 android tv box "H96 Max v11" does have the two red/blue leds on the pcb, but no clock display. There are solder points on the pcb though. Would it be possible to use these pins for GPIO access (maybe even add an I2C RTC module), or would that not be possible within the limits of hardware/firmware? Any pointers on where to start looking, if at all possible? In pikvm config, following generic instructions, I was able to easily add the usb ethernet gadget and do routing/masquerading for the attached device. Yet, when I tried to configure usb mass storage gadget, the result was that the keyboard/mouse stopped responding in pikvm. From the pikvm documentation (unfolding the USB limitations section) it looks like there could be an issue with capabilities of the chip in relation to the number of endpoints needed. Yet, that page mentions mass storage would require 2 endpoints for each msd, and usb ethernet would require 3 endpoints per emulated device. So it's strange that ethernet does work but msd does not. Enabling only one at a time, of course. Is there any data on the number of endpoints available on the rk3318 chip? Or maybe someone knows how to make msd working? Or.. maybe it was intentionally disabled in srepac's kvmd-armbian because it's not working either way? The usb ethernet gadget was disabled in the config as well but works like a charm, so not sure why msd didn't work as expected. Or maybe msd is only supported for the usb3 port and not on the usb2 port that I'm now using for otg connection to the remote? Sorry, too many question marks here... Any pointers would be much appreciated!

@McTurbo OrangPi official images use the vendor kernel 5.10 with various custom patches and drivers. Armbian does not offer vendor kernel anymore because after a while they become old and unmaintained.

Do you see CPU stalls in kernel logs/dmesg? We have two reports with sunxi family boards and 6.6.16 kernel, reporting high CPU usage, unstable operation and kernel logs reveal CPU stalls every few minutes. I'll build and test with latest Linux 6.6, else with edge, in the hope it can be fixed forward instead of backwards. Nasty to debug (for me) since no process, cron job or anything else is obviously associated with those CPU stall events.

Here is my solution. I created a sdcard with u-boot firmware according to the instructions on this webpage: https://docs.u-boot.org/en/latest/board/starfive/visionfive2.html I noticed these instructions will use OpenSBI v1.4. The Starfive firmware is still using OpenSBI v1.2. Flip the boot selector switch on the board ==> to select boot from sdcard. Insert the sdcard created from that u-boot website. Boot the system. It will boot without starting any operating system. U-Boot 2024.07-rc1 (Apr 26 2024 - 10:32:34 +0300) OpenSBI v1.4 Swap the sdcard with the Armbian sdcard. Enter these commands: mmc list mmc dev 1 load mmc 1:1 ${fdt_addr_r} /boot/dtb/starfive/jh7110-visionfive-v2.dtb load mmc 1:1 ${kernel_addr_r} /boot/vmlinuz-5.15.0-edge-starfive2 load mmc 1:1 ${ramdisk_addr_r} /boot/initrd.img-5.15.0-edge-starfive2 setenv bootargs 'root=/dev/mmcblk1p1 rw console=tty0 console=ttyS0,115200 earlycon rootwait stmmaceth=chain_mode:1 selinux=0' setenv kernel_comp_addr_r 0x5a000000 setenv kernel_comp_size 0x04000000 booti $kernel_addr_r $ramdisk_addr_r:$filesize $fdt_addr_r This will boot Armbian and recognize the 8GB RAM. I also found there is a problem recognizing the UUID of the sdcard or nvme during operating system boot. For sdcard boot I needed to edit the /etc/fstab -- switch the UUID to the device name sdcard example: # cat /etc/fstab /dev/mmcblk1p1 / ext4 defaults,noatime,commit=600,errors=remount-ro 0 1 tmpfs /tmp tmpfs defaults,nosuid 0 0 These instructions also worked with Ubuntu 24.04. I saw the same memory problem as with Armbian.

I found that the official OrangePi images enable 4:4:4 output, but only with the Debian image. The Ubuntu image only has 4:2:2 output. I couldn't figure out how they did this as I couldn't see any difference in the driver config. So it seems they changed something in the code to get it working, possibly something similar to the patch you linked.

Probably no dtbo will be needed. Find the 5 pins in your orange pi, that would be contacted by the hat, and try to control them with the Python code here: https://forum.armbian.com/topic/33800-orange-pi-zero-3-gpio/?do=findComment&comment=181191 if that lorahat software is open source, then change that source code to point to the correct pin addresses

Please, can you share your hostapd.conf (minus the ssid and keys of course) I am running into other problems, but I am glad that others are getting hostapd working 👍

After the usb4-1 lines, you should have seen cdc_acm something You can check that you have the acm driver with: zcat /proc/config.gz|grep ACM you should see config_usb_acm=m Have you tried: ls /dev/ttyUSB* ? When you see the ttyACM*, you should get the by-serial files appear automatically (devrules function)

any one help me to amlogic s805 latest ver plz.. plz......

Hi @Gunjan Gupta I am helping a client with an issue on their nanopi neo where armbianEnv.txt and other files are seen to be corrupted. The symptoms resemble the various complaints seen over the years on this forum. A system restart generally seems to be involved. I am speculating that they are removing power without a safe shutdown. You mentioned earlier in the discussion on Dec 2023: Do you recall which commit the changes to filesystem options were made so that we can code review? My client is using a build from May 2023. So I am wondering if they are missing some critical changes that would make the file system more reliable. Please let me know if you remember what filesystem options were changed and when they were made. A link into Git would be very helpful here. My customer is not ready to upgrade, but would be open to have me patch in upstream fixes. Thanks, Chris N.

@pocosparc Can You Manage some fixes for this H96 Max vendor DTB Kernel 6.1.43 to included on armbian build?

You can use this method: https://forum.armbian.com/topic/28895-efforts-to-develop-firmware-for-h96-max-v56-rk3566-8g64g/?do=findComment&comment=189369 to shrink your 60gb image onto small file

thats why I'm making an Kernel legacy rockchip 5.10 righ now. the video codecs make difference Will try this compilation

A thank you to @Hqnicolas and success report. Did a trunk build with kernel 6.6 and flashed using rkdevtool and your instructions (had a little trouble finding the required H96-MAX-8gb-MiniLoaderAll.bin buried in the threads), and it worked like a charm. I did need to supply an NVRAM file for the wifi adapter, that is missing from your wifi bringup instructions. I found one in the libreelec repo that did not work, I ended up extracting the factory image from the h96max website and grabbing the stock nvram_bcm4335.txt, renaming to brcmfmac4335-sdio.txt and placing in /lib/firmware/brcm. Once that was done, wireless worked. Display works, HDMI audio works, video acceleration sort of works but drops frames under any load and throws audio sync warnings, i chock that up to hantro not being as developed as rkvdec2? Chromium appears to have acceleration too. Great result for a first try trunk build. cd /lib/firmware/brcm/ sudo wget https://github.com/CoreELEC/brcmfmac_sdio-firmware-aml/raw/master/firmware/brcm/fw_bcm4335b0_ag.bin sudo ln -s fw_bcm4335b0_ag.bin brcmfmac4335-sdio.h96-TVbox,rk3566.bin sudo cat > /lib/firmware/brcm/brcmfmac4335-sdio.txt << "EOF" # bcm94335wlcspMS_ES50_RC171p24p23_04052013_AM_mdfy_PAparam.txt -- 4/5/2013 by Murata, based on bcm94335wlcspMS_ES50_RC171p24p20_04022013_AM.txt, changed PA parameters and txidxcap parameters and ccode. # bcm94335wlcspMS_ES50_RC171p24p20_04022013_AM.txt -- 4/2/2013 by Broadcom Corporation # Use with AARDVARK_REL_6_30_171_24_23 -- Murata BCM4335 WLCSP 11AC Module # Sample variables file for Murata Type-XJ ES5.0 (0x00 0x11) -- bcm94335wlcspMS_AM_P400.txt as original sromrev=11 boardrev=0x1500 boardtype=0x064b boardflags=0x10401001 boardflags2=0x0 #updated boardflags3 for forcing to enable external LPO boardflags3=0x0800c08b macaddr=00:90:4c:c5:12:38 #ccode modified by Murata #ccode=0 ccode=XS regrev=0 antswitch=0 pdgain5g=1 pdgain2g=1 tworangetssi2g=0 tworangetssi5g=0 femctrl=4 vendid=0x14e4 devid=0x43ae manfid=0x2d0 #prodid=0x052e nocrc=1 #otpimagesize=502 xtalfreq=37400 extpagain2g=1 extpagain5g=1 rxgains2gelnagaina0=2 rxgains2gtrisoa0=6 rxgains2gtrelnabypa0=1 rxgains5gelnagaina0=3 rxgains5gtrisoa0=5 rxgains5gtrelnabypa0=1 rxchain=1 txchain=1 aa2g=1 aa5g=1 ag0=0 ag1=0 tssipos5g=1 tssipos2g=1 #PA parameters (2G20M/2G40M/5G20M/5G40M/5G80M) #PA parameters modified by Murata #pa2ga0=-208,6208,-764 #pa2ga1=-203,6429,-793 #pa5ga0=-167,5736,-685,-157,5669,-670,-157,5548,-665,-141,5621,-664 #pa5ga1=-101,6543,-735,-99,6452,-731,-147,5743,-695,-75,6468,-723 #pa5ga2=-172,5903,-708,-160,5868,-698,-113,6264,-722,-125,5915,-684 pa2ga0=0xff31,0x1759,0xFD1D pa2ga1=0xff35,0x18BB,0xFCEC pa5ga0=0xff78,0x1715,0xFD49,0xff89,0x1714,0xFD57,0xff86,0x1652,0xFD62,0xffa9,0x1760,0xFD5E pa5ga1=0xff56,0x1596,0xFD5F,0xff88,0x1764,0xFD45,0xff89,0x1632,0xFD65,0xff69,0x160E,0xFD49 pa5ga2=0xff5a,0x1667,0xFD4E,0xff5f,0x15F7,0xFD5E,0xff5a,0x1531,0xFD68,0xff6e,0x1587,0xFD6A # Default Target Power for 2G -- 17dBm(11)/14dBm(54)/13dBm(MCS7,MCS8)/16dBm(6,MCS0) maxp2ga0=74 cckbw202gpo=0 cckbw20ul2gpo=0 dot11agofdmhrbw202gpo=0x6666 ofdmlrbw202gpo=0x0022 mcsbw202gpo=0x88866662 # Default Target Power for 5G -- 14dBm(54)/13dBm(HT20-MCS7,VHT20-MCS8)/12dBm(HT40-MCS7,VHT40-MCS9)/11dBm(VHT80-MCS8/MCS9)/16dBm(6,20HT-MCS0) maxp5ga0=74,74,74,74 # Low mcslr5glpo=0 mcsbw205glpo=0x88866662 mcsbw405glpo=0xAAA88884 mcsbw805glpo=0xCCCAAAA6 # Mid mcslr5gmpo=0 mcsbw205gmpo=0x88866662 mcsbw405gmpo=0xAAA88884 mcsbw805gmpo=0xCCCAAAA6 # High mcslr5ghpo=0 mcsbw205ghpo=0x88866662 mcsbw405ghpo=0xAAA88884 mcsbw805ghpo=0xCCCAAAA6 #20MHz High Rate sb20in40hrpo=0x0 sb20in80and160hr5glpo=0x0 sb20in80and160hr5gmpo=0x0 sb20in80and160hr5ghpo=0x0 #40MHz High Rate sb40and80hr5glpo=0x0 sb40and80hr5gmpo=0x0 sb40and80hr5ghpo=0x0 #20MHz Low Rate sb20in40lrpo=0x0 sb20in80and160lr5glpo=0x0 sb20in80and160lr5gmpo=0x0 sb20in80and160lr5ghpo=0x0 #40MHz Low Rate sb40and80lr5glpo=0x0 sb40and80lr5gmpo=0x0 sb40and80lr5ghpo=0x0 dot11agduphrpo=0x0 dot11agduplrpo=0x0 tssifloor2g=80 tssifloor5g=160,190,240,260 #rpcal:use with 171.17 or later, compensates filter ripple rpcal2g=0x0 rpcal5gb0=0x0 #cckdigfilttype[0-7] 0:default cckdigfilttype=2 phycal_tempdelta=25 #GPIO 0 for SDIO HW OOB interruption muxenab=0x10 #sd_gpout=0 #sd_oobonly=1 rssicorrnorm_c0=-3,-2 rssicorrnorm5g_c0=-1,0,-3,-1,0,-3,-3,-2,-4,-3,-2,-4 #txidxcap2g and txidxcap5g modified by Murata #txidxcap2g=32 #txidxcap5g=44 txidxcap2g=36 txidxcap5g=36 paparambwver=1 EOF sudo rmmod brcmfmac_wcc brcmfmac brcmutil modprobe brcmfmac brcmfmac4335-sdio.txt

It's finally working now! And it probably was working before, but I didn't notice it, because for whatever reason the IP address of the Orange Pi changed when using the ssd. When I tried to ssh on the device, I couldn't get any connection, since I was using the IP to connect. When using the new IP of the device (I was checking the web interface of my router and it showed me an Orange Pi 5 with a new IP), it worked like a charm! Thanks for your input @royk & @igelkotten! Just to clarify @igelkotten: I didn't use dd in my last attempt at all. I created one single partition on the ssd and did what @royk suggested from the very beginning: Use armbian-install (which is btw also accessible through armbian-config) and then "4 Boot from MTD Flash - system on SATA, USB or NVMe". After that is completed, it asks you if you want to install/update the bootloader on MTD Flash, which I agreed. Then I didn't already reboot the device. Instead I took a look at the armbianEnv.txt and /etc/fstab to see if the UUID is correct. Everything looked fine, so I rebooted without the micro sd card and apparently the Orange Pi was working the whole time, but using a different IP. Anyway, it's working now and I'm happily using the ssd! Thanks again for the help!

Today I manage to Start RK3576 and RK3506 IoT processors, Linux 6.1 SDK image source: ubuntu-24.04-beta-preinstalled-desktop-arm64-orangepi-3b.img.xz The system starts but after reboot it crashes. This is the error LOG on BOOT DTS+DTB=510(to develop 610): https://drive.google.com/file/d/1weNysgsmMXu5rf47mmdnhqovtGnVS3mU/view?usp=sharing With this DTB I managed to start Opios-arch-aarch64-xfce-opi3b-23.08.1-linux5.10.160 (this Opio is ARK linux and is slower than Kernel 6.6 mainline) rk3566-h96-tvbox.dts

@Markus Braun edit: I have an orange pi 5 plus! I have mine booting without any SD card. I sadly don't recall whatever guide I followed but I am pretty sure I had to toogle nvme booting somwhere in armbian-config or some command that updated the bootloader on the opi5+ This is my /boot/armbianEnv.txt verbosity=1 bootlogo=true overlay_prefix=rockchip-rk3588 fdtfile=rockchip/rk3588-orangepi-5-plus.dtb rootdev=UUID=4578f871-5c8a-406a-87bd-be8562b1f8bf rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u my /etc/fstab look like this UID=4578f871-5c8a-406a-87bd-be8562b1f8bf / ext4 defaults,noatime,commit=600,errors=remount-ro 0 1 UUID=dce8fefd-ace9-468e-8695-55071f59094f /boot ext4 defaults,commit=600,errors=remount-ro 0 2 tmpfs /tmp tmpfs defaults,nosuid 0 0 [... nfs and other irrelevant junk] Did you change your fstab before running dd so it reflects the UUID of the the nvmes /boot disk? or change it to /dev/nvme... blabla ? I will be getting a new opi5+ in a week or two with an nvme so I will need to revisit these steps anyway. Let me know if I can check something on my side.

@Gullik I would assume we can get some ideas on progress with rk3588 from this link(even if it isn't specific for opi5/opi5+): https://gitlab.collabora.com/hardware-enablement/rockchip-3588/notes-for-rockchip-3588/-/blob/main/mainline-status.md It seems HDMI audio is not even being worked on but it might also come 'natual' with the GPU stuff/other hdmi stuff(I dont know) Maybe it works with the libmali stuff I don't know. But I find it pretty wonky as it is with the legacy kernel that is supposed to work with it.

I removed the line "overlays=ssd-sata", but it still doesn't boot. I didn't think that I had to buy any additional equipment just to be able to use my ssd on the Orange Pi 5.

@Markus Braun In armbianEnv.txt remove the line "overlays=ssd-sata" A ftdi adapter doesn't cost the world and it saves you from a lot of hassle.

note that various armbian os images are linked on github https://github.com/armbian/os https://github.com/armbian/os/releases are you able to download images from there? you probably have to copy that say into a usb thumb/flash drive bring that home and you can try flashing that using dd from your raspberry pi I think there are also torrents link as alternative on the boards web pages, but I'm not too sure if you are able to download torrents say on a public terminal.

I don't have a ftdi adapter. How exactly do I disable the sata overlay? The files in /boot on my nvme are: armbianEnv.txt boot.bmp boot.scr dtb initrd.img-5.10.160-rockchip-rk3588 uInitrd armbian_first_run.txt.template boot.cmd config-5.10.160-rockchip-rk3588 Image System.map-5.10.160-rockchip-rk3588 The armbianEnv.txt on the nvme says: verbosity=1 bootlogo=false overlay_prefix=rockchip-rk3588 fdtfile=rockchip/rk3588s-orangepi-5.dtb rootdev=UUID=e389976d-765a-4392-97c0-fdc69e5fb045 rootfstype=ext4 overlays=ssd-sata usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u My /etc/fstab on the nvme says: # <file system> <mount point> <type> <options> <dump> <pass> tmpfs /tmp tmpfs defaults,nosuid 0 0 UUID=e389976d-765a-4392-97c0-fdc69e5fb045 / ext4 defaults,noatime,commit=600,errors=remount-ro,x-gvfs-hide 0 1 lsblk -f gives me: NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS loop0 squashfs 4.0 0 100% /snap/certbot/3641 loop1 squashfs 4.0 0 100% /snap/core/16578 loop2 squashfs 4.0 0 100% /snap/certbot/3698 loop3 squashfs 4.0 0 100% /snap/core/16931 loop4 squashfs 4.0 0 100% /snap/core20/2186 loop5 squashfs 4.0 0 100% /snap/core20/2267 loop6 squashfs 4.0 0 100% /snap/hello-world/29 mtdblock0 mmcblk1 ├─mmcblk1p1 vfat FAT16 armbi_boot F086-14E9 153M 40% /boot └─mmcblk1p2 ext4 1.0 armbi_root 384d3db4-7e83-40fe-933e-22e63200cb80 12.4G 55% /var/log.hdd / zram0 [SWAP] zram1 35.6M 17% /var/log nvme0n1 └─nvme0n1p1 ext4 1.0 e389976d-765a-4392-97c0-fdc69e5fb045 I'm a little desperate here, but thanks for your support @royk! Any other ideas? I cannot be the only one with this problem, can I? My ssd is 2 TBs, maybe this is too much? Do you have any other ideas?

Le potato won't boot from SSD. Followed the steps from 1) James Chamber's SSD Boot Guide also 2) Using Libre Flash Tool. Always getting errors: Not sure what is happening but would anyone know how this can be resolved? Using Armbian Home Assistant Supervised image from here.

@Markus Braun It might be a good idea to check the serial console to see what's going wrong, keep in mind that you need a ftdi adapter that can handle a high baudrate. Things you could check: Did you disable the sata overlay? Did you check if all the files are in the /boot folder of the nvme? Checked if the correct UUID is in /boot/armbianENV.txt and /etc/fstab Removed the SD-card at the first boot from NVME?

AFAIK, to get fully working 4:4:4 modes, there is the need to import some "experimental" patches that are floating in the rockchip kernel mailing list. The patches have been tested a lot by libreelec users on various rockchip platform (32 bit rockchip device like rk322x and rk3288 already have them merge in), but have been judged "too complicated to maintain" for rockchip64 repository. You can see the last attempt here and the previous attempt here, useful to get the points of the discussion.