Jump to content

All Activity

This stream auto-updates

  1. Past hour
  2. @Pop AlexI haven't spent a lot of time on GPU acceleration but I know there's another member here who has. He's using the official Radxa's GPU drivers. https://github.com/chainsx/build/blob/a0527bd977bbe55b13c1f46ec46d0aab4369c798/extensions/radxa-bxm-img-gpu.sh
  3. Today
  4. Just tested a build i made locally from your branch, on the A7Z build, build with the latest Debian + XFCE Nice job @Nick A. Seems to work fine, but it's lacking GPU acceleration, in both Chrome and VLC, same as the official builds. Do you have any info on that? Is there any work going on the Armbian team for supporting the Imagination GPU? I know Imagination has pretty shitty software support.
  5. @kvvvp Build from branch v20251014 (kernel 6.17.2)
  6. how to apply a patche for t527? i have updated Armbian now and ready to build a test image to share to everybody
  7. Because they forked an old version of our framework and replaced "armbian" with "orangepi".
  8. https://fi.mirror.armbian.de/oldarchive/ If its not there, its gone.
  9. Yesterday
  10. Hi, sudo systemctl stop media-nano-Z.mount it really works, but if you forget to do it manually, then when you try to reboot or turn off the single-board computer, it will freeze, because it tries to unmount the disk itself, apparently using umount. Okay, I did all this after upgrading to Armbian 26.2.0-trunk.86 trixie armv7l, and when I tried to unmount the drive the old way with umount, I found that everything worked. It looks like the problem is already fixed.
  11. Hello, I am looking for a specific legacy image for the Orange Pi Zero 2W: Armbian 23.02.2 Bullseye with Kernel 5.10.160. The reason I need this specific version is to use the device as a USB UVC (Webcam) gadget via ConfigFS. On the newer 6.6/6.12 mainline kernels, I am facing a "Permission Denied" error when trying to write to hHeight, even as root. After researching, it seems this is a known kernel-level restriction in newer versions, and the legacy 5.10 kernel is the most stable for UVC gadget functionality. I’ve checked the current archive mirrors but could only find the 6.6.x versions. Could anyone provide an official archive or a reliable mirror link for the following image? Filename: Armbian_23.02.2_Orangepizero2w_bullseye_legacy_5.10.160.img.xz Thank you for your help.
  12. Grmbl. As it turns out after some reversing and building uboot for the RV2, there seems to be a toolchain by xunlong with much similarities to armbian-build on https://github.com/orangepi-xunlong/orangepi-build.git There is an Ubuntu image for the RV2 one can download from gdrive and install to SD. This image has a package linux-u-boot-orangepirv2-current.deb installed. With very much the same postinst script than the similar package from Armbian / Banana Pi F3. Hence the RV2 package obviously was build from their build tree, family file is external/config/sources/families/ky.conf which looks familiar. Also their project has some non-documentation, meaning there is a "build.sh" and a very small README.md. I'm unsure if I should continue this...
  13. This is based on mines, running Armbian Trixie: - NM can work without dhclient, it has it DHCP internally as well. So maybe look at that instead of AI with old info and certainly no clue about a specific SBC - modern kernel it is end0 - systemd-networkd is also an option - you also might use ifupdown still, also not needed, NM can do internally as well
  14. Mine does not have any pinholes near the lcd display. Send a pic, or/and trace their paths into some chip and see what that chip does by its id
  15. Here is my findings and solution. Hope this also solves your problem. When the network hangs, I can see that IPv4 address is lost using "ip a" on the console. I then check "journalctl -b -e" for logging and obviously it's a consequence of dhcp4 failure. Dec 19 22:54:10 pbsbc01h3 dhclient[4720]: DHCPREQUEST for 192.168.2.190 on eth0 to 192.168.2.55 port 67 (xid=0xb07e1eb) Dec 19 22:54:10 pbsbc01h3 dhclient[4720]: DHCPACK of 192.168.2.190 from 192.168.2.55 (xid=0xebe1070b) Dec 19 22:54:10 pbsbc01h3 NetworkManager[5189]: <error> [1766156050.2239] dhcp4 (eth0): error -111 dispatching events Dec 19 22:54:10 pbsbc01h3 NetworkManager[5189]: <info> [1766156050.2243] dhcp4 (eth0): state changed bound -> fail Dec 19 22:54:10 pbsbc01h3 NetworkManager[5189]: <info> [1766156050.2248] device (eth0): DHCPv4: trying to acquire a new lease within 90 seconds Dec 19 22:54:10 pbsbc01h3 dhclient[4720]: bound to 192.168.2.190 -- renewal in 288 seconds. With the help from ChatGPT, I modify "/etc/dhcp/dhclient.conf" with the following and the problem is gone. timeout 5; retry 60; reboot 10;
  16. I am not sure if this will lead to problems. The SBC is a Radxa ROCK3A. It might be EVB was used for development and never changed. Maybe won't matter as later on kernel rock-3a dtb is loaded. But could be a reason for issues I saw (year ago) with mainline u-boot, therefor I use Radxa's one / legacy.
  17. Maybe. If it is better you'll have to see. Install package 'linux-u-boot-rockpi-4c-edge' and with dpkg -L linux-u-boot-rockpi-4c-edge you can see where the u-boot binary is located, then: strings <u-boot binary> | grep armbian
  18. I was able to console in with the HAT attached. U-Boot TPL 2022.07_armbian-2022.07-Se092-P621f-H28b4-V23b0-Bbf55-R448a (Dec 04 2025 - 04:39:41) NOTICE: BL31: v1.3(release):845ee93 NOTICE: BL31: Built : 15:51:11, Jul 22 2020 NOTICE: BL31: Rockchip release version: v1.1 INFO: GICv3 with legacy support detected. ARM GICV3 driver initialized in EL3 INFO: Using opteed sec cpu_context! INFO: boot cpu mask: 0 INFO: If lpddr4 need support multi frequency, INFO: please update loader! INFO: Current ctl index[0] freq=400MHz INFO: Current ctl index[1] freq=800MHz INFO: plat_rockchip_pmu_init(1196): pd status 3e INFO: BL31: Initializing runtime services WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK ERROR: Error initializing runtime service opteed_fast INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x200000 INFO: SPSR = 0x3c9 Guess the question now is. Is there a newer bootloader. Trying to understand all this.
  19. Ok, I got it booting, so I did: set devtype nvme set devnum 0 set distro_bootpart 0 set prefix /boot/ load nvme 0:0 $loadaddr /boot/boot.scr source Doing a printenv before I see: => printenv arch=arm baudrate=1500000 board=evb_rk3568 board_name=evb_r_targets=mmc1 mmc0 nvme scsi usb pxe dhcp spi bootcmd=bootflow scan -lb bootdelay=1 bootp_arcNDI:003000 cpu=armv8 cpuid#=54434e4b383000000000000000070d19 dnsip=192.168.1.253 eth1addr=1e000 ethaddr=1e:f2:d5:f1:74:04 fdt_addr_r=0x12000000 fdtcontroladdr=7ded3a80 fdtfile=rockchipr=0x12100000 gatewayip=192.168.1.254 hostname=rock-3a ipaddr=192.168.1.253 kernel_addr_r=0x00 kernel_comp_size=0x8000000 loadaddr=0xc00800 netmask=255.255.255.0 pxefile_addr_r=0x00e000offset_f=0xffe000 script_size_f=0x2000 scriptaddr=0x00c00000 serial#=09103e09ce4edd27 serverserial@fe660000 stdin=serial@fe660000 stdout=serial@fe660000 vendor=rockchip Environment size: 916/126972 bytes So this is not finding the boot.scr with the bootflow scan -lb, so now is time to make it boot automatically.
  20. @Sarang He Try these images https://github.com/NickAlilovic/build/releases/tag/20250306
  21. Ricardo put some real effort into Rk3528 here :https://github.com/armbian/build/pull/9102 Since the 2A/2F are using the same SoC this should actually help a lot.
  22. @Thịnh Nguyễn: pls give me link to download, I also have tv98. Thank you
  23. I can confirm the above `flash-image-DDR4-1g_1cs_5-1200_750` image boots to U-Boot on the ESPRESSObin Ultra. I wasn't able to test past that because U-Boot isn't being built with Standard Boot enabled (which I use): WTMI-devel-18.12.1-a3e1c67 WTMI: system early-init SVC REV: 5, CPU VDD voltage: 1.260V Setting clocks: CPU 1200 MHz, DDR 750 MHz CZ.NIC's Armada 3720 Secure Firmware d6d9646-dirty (Nov 5 2025 09:00:30) Running on ESPRESSObin Ultra NOTICE: Booting Trusted Firmware NOTICE: BL1: v2.12.8(release):95bbf00da NOTICE: BL1: Built : 09:02:55, Nov 5 2025 NOTICE: BL1: Booting BL2 NOTICE: BL2: v2.12.8(release):95bbf00da NOTICE: BL2: Built : 09:02:56, Nov 5 2025 NOTICE: BL1: Booting BL31 NOTICE: BL31: v2.12.8(release):95bbf00da NOTICE: BL31: Built : 09:02:56, Nov 5 2025 serial_mvebu serial@12000: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 U-Boot 2025.10_armbian-2025.10-Se50b-P3205-H05ce-V9535-Bbf55-R448a (Nov 05 2025 - 09:00:02 +0000) DRAM: 1 GiB Core: 48 devices, 24 uclasses, devicetree: separate WDT: Not starting watchdog@8300 Comphy chip #0: Comphy-0: USB3_HOST0 5 Gbps Comphy-1: PEX0 5 Gbps Comphy-2: SATA0 6 Gbps Target spinup took 0 ms. AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode flags: ncq led only pmp fbss pio slum part sxs PCIe: Link down MMC: sdhci@d0000: 0, sdhci@d8000: 1 Loading Environment from SPIFlash... SF: Detected mx25u3235f with page size 256 Bytes, erase size 4 KiB, total 4 MiB OK Model: Globalscale Marvell ESPRESSOBin Board Net: eth0: ethernet@30000 [PRIME] Hit any key to stop autoboot: 0 Flags not supported: enable CONFIG_BOOTSTD_FULL bootflow - Boot flows Usage: bootflow scan - boot first available bootflow If you enable Standard Boot and want me to test again, happy to. Cheers!
  24. Last week
  25. Hello! I have a strange behavior at compiling As i knew, fwnode_for_each_available_child_node_scoped was committed to kernel at 2024 year.. Thats my kernel Any ideas?
  26. Hi again, it booted and I get console output using this config: # Rockchip RK3528 quad core 1-4GB SoC WIFI/BT 0-32GB eMMC BOARD_NAME="ROCK 2F" BOARD_VENDOR="radxa" BOARDFAMILY="rk35xx" BOOTCONFIG="rock-2-rk3528_defconfig" BOARD_MAINTAINER="CodeChenL" KERNEL_TARGET="vendor,edge" KERNEL_TEST_TARGET="vendor" FULL_DESKTOP="yes" BOOT_LOGO="desktop" BOOT_FDT_FILE="rockchip/rk3528-rock-2f.dtb" BOOT_SCENARIO="spl-blobs" IMAGE_PARTITION_TABLE="gpt" enable_extension "radxa-aic8800" AIC8800_TYPE="usb" function post_family_config__rock2f_use_mainline_uboot() { [[ "${BRANCH}" == "vendor" ]] && return 0 display_alert "$BOARD" "Mainline U-Boot overrides for $BOARD - $BRANCH" "info" # To reuse ATF code in rockchip64_common, let's change the BOOT_SCENARIO and call prepare_boot_configuration() again # BOOT_SCENARIO="tpl-blob-atf-mainline" # prepare_boot_configuration # declare -g BOOTCONFIG="generic-rk3528_defconfig" declare -g BOOTDELAY=1 declare -g BOOTSOURCE="https://github.com/u-boot/u-boot.git" declare -g BOOTBRANCH="tag:v2026.01-rc4" declare -g BOOTPATCHDIR="v2026.01" declare -g BOOTDIR="u-boot-${BOARD}" declare -g UBOOT_TARGET_MAP="BL31=${RKBIN_DIR}/${BL31_BLOB} ROCKCHIP_TPL=${RKBIN_DIR}/${DDR_BLOB};;u-boot-rockchip.bin" unset uboot_custom_postprocess write_uboot_platform write_uboot_platform_mtd # disable stuff from rockchip64_common; we're using binman here which does all the work already declare -g BOOTSCRIPT="boot-rockchip64-ttyS0.cmd:boot.cmd" declare -g SERIALCON="ttyS0" # Just use the binman-provided u-boot-rockchip.bin, which is ready-to-go function write_uboot_platform() { dd "if=$1/u-boot-rockchip.bin" "of=$2" bs=32k seek=1 conv=notrunc status=none } function write_uboot_platform_mtd() { flashcp -v -p "$1/u-boot-rockchip-spi.bin" /dev/mtd0 } } I'll try working on it using github. Still I cannot write in the serial console for some reason. There is zero input. So from what I understand, USB won't work with kernel 6.18, right? The wifi won't work as its aic8800-usb, and usb Ethernet either. With no serial input I have no way to communicate with the board. EDIT: I fixed the issue with not being able to conect via serial, it was because of a HAT that was connected. EDIT2: I figured out how to compile kernel 6.19-rc1. Some patches failed, I just removed them for now. I can send you @johlnx the command. EDIT3: Managed to boot 6.19 but it's pretty barebones. No usb, no pci etc. Time is not correct below. Linux rock-2f 6.19.0-rc1-edge-rockchip64 #8 SMP PREEMPT Sun Dec 14 04:05:07 UTC 2025 aarch64 GNU/Linux Now I can wait for your proper implementation.
  27. One might think that if this was a perfect world. The reality is that very few people want to spend the time to find and read tutorials/FAQs/documentation. They just come to these forums and expect expert hand holding support for free from people who are volunteering their time. Igor has a lot more important things to be working on to keep Armbian afloat then even responding to posts in these forums. While I don't personally deal with rockchip sbc's, so I can't help you specifically here, as a moderator of these forums, I end up answering the same questions over and over again simply because people expect free support, not a community of people just trying to help. In the spirit of open source the easiest way for someone to contribute to help others is to dig in, learn and then contribute back what they have learned either through these forums, through contributing to the Armbian documentation or through actual code. (I'm mostly writing this, so that Igor doesn't need to take his time to respond, since I want him to be using his time elsewhere)
  28. Are you sure about the math, because if you write a tutorial, even a relatively brief one, covering at least a few points to guide me more than just a few hints, you'll save a lot of work for a lot of people who would otherwise spend hours doing it. 😉
  29. @johlnx Please use paste.armbian.eu, also it seems a bit off-topic Ah I see, you just made a typo and wrote "RK3588" instead of "RK3528".
  1. Load more activity
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines