All Activity

I had no idea that there's an OpiZ3W Just in case, it is nothing at all like the Orange Pi Zero 3, which has a lot in common with the OpiZ2W. Yeely: what are your first impressions about this board? Are there demos for the NPU?

@Nick A My bad, cleaned my build folder and it compiled fine. Still, it is still stuck in the bootloader Bootlog: https://pastebin.com/ckqP10Bb I tried with both of my board with and without emmc installed.

@Marvin-03 that's odd. The test branch I cloned has "0011-Add-BSP-support-files-54e9e5fb62" patch. Compiles fine on my build. Try to clone it again. git clone https://github.com/NickAlilovic/build.git --branch Radxa-mainline-WIP-test

Tomb Raider (2013) Armbian 26.05-trunk (Linux kernel 7.0.10-edge-rockchip64) + Panvk: Mesa 26.2.0-devel (git-3df406633e) + DXVK 2.7.1-stripped (https://github.com/khanh-it/dxvk/releases) + Wine: wine-11.9-staging-tkg-amd64-wow64 (https://github.com/Kron4ek/Wine-Builds/releases) + box64: box64-rk3588_0.4.3+20260529.5b7308f-1 (https://github.com/ryanfortner/box64-debs/) ~30fps@720p (default settings)

Okay I will try that when I get back from work, thanks for your time

correct. If the soc does not detect a valid boot loader on spi it will fall back to its hard coded boot order which is spi, emmc, microsd or something like this.

Ok thanks my apologies. Oh thanks, I missed that point. This box should've been ewaste long ago I gotbthe bright idea.of using it as a low power 'digital sign' driver for my wife's store . I started with ohub bookworm server for the board. I couldn't get the boot toothpick to read cards or usb. It wasn't until I flashed CoreELEC to a card and was trying to see if it was a distro issue that I realized the box was trying to go into android recovery with the toothpick not looking for boot drives. I put aml_autoscript from the CoreELEC root folder and zipped it then I used android recovery mode to clear the cache and update from card pointing at the zip file. Even though the final output was that it failed it actually loaded CoreELEC autoscript and when I rebooted it read the bootloader on sdcard. After discovering that little nuance I did the same for the flashed Arabian distro but it didn't seem to catch the bootloader on sdcard. I assumed I wasn't getting the right dtd.img copied so I tried the most likely for the chip and when I.asked ai it thought I needed a legacy version. When I throw the CoreELEC in now it still boots from the card. I made the assumption that the modifications to android boot would work accross distros so it didn't seem strange that CoreELEC might boot even if it was the bookworm autoscript being used by android. Thanks for taking the time to reply even though it's the wrong forum and my apologies I should've thought that through. Looking at the hub forum it didn't seem like there was much in the way of replies happening. Cheers

Hello, After more research it seems that despite the Wikipedia screenshot, M2 Ultra & M2 Berry do not really have the same CPU : M2U uses R40 and M2B uses V40 This is most probably why it does not work. After checking watchdog & sysrq, I almost rebooted with : echo 1 > /proc/sys/kernel/sysrq echo b > /proc/sysrq-trigger but still hung in the end. I was about to throw the Banana PI away, and I finally found this website which provides a (very) raw debian image for the M2 Berry, and it works correcty including reboot. Sharing the link in case it helps other people with M2B : https://sd-card-images.johang.se/boards/banana_pi_m2_berry.html Thanks for your help Regards

Hi, thanks for the reply. I've tried this already following this guide https://docs.radxa.com/en/e/e24c/getting-started/install-os/nvme-system/spi-flash#flash-spi-boot-firmware. I tried to flash both the release and debug images I found here https://dl.radxa.com/rock5/sw/images/loader/rock-5b/ When you say wipe it, do you mean wipe it and don't flash something else?

Second point, per the faq install instructions on this site. It you have ever run another distribution (like coreelec), you have changed the uboot environment in ways incompatible with Armbian. You need to flash a clean android firmware before using armbian. (Balbes had issues with coreelec and made his code incompatible)

Ophub is a fork of Armbian. They use the Armbian name without permission. They are not Armbian. They do not contribute to Armbian development nor do they participate in these forums. You need to ask questions regarding ophub in there support channels.

Hello Aniket, as i mentioned the armbian is not working because of the different DRAM Voltage setting in uboot. The board was running with original debian version from RADXA https://github.com/radxa-build/radxa-cubie-a5e/releases. If you check the log you see the dram voltage settings and training. For me i'm waiting until a board with 2/4GB which hopefully runs with armbian. Rolf

I am facing similar issue with this board and now I am stuck with it.

Hi I am trying to breathe some life into an older generic Amlogic TV box on my workbench and am hitting a brick wall with modern mainline images. I’m looking for a copy of a legacy, community-archived Armbian image (Kernel 5.4.y, 5.10.y, or 4.19.y) tailored for the S905X / S905W (meson-gxl) architecture. The newer automated GitHub builds (6.12+ kernels) completely purge the old asset files, and modern multi-stage boot configurations (boot.scr) are being entirely bypassed by my box's legacy onboard bootloader. Hardware Specs & Current Context: SoC: Amlogic S905X / S905W variant (Generic budget clone box, likely 1GB RAM) Target DTBs I'm testing: meson-gxl-s905x-p212.dtb or meson-gxl-s905w-tx3-mini.dtb The Baseline (Crucial Detail): CoreELEC-Amlogic.arm-9.2.8-Generic boots instantly and functions flawlessly from a Class 4 MicroSD card on this box. CoreELEC The Problem: Modern Armbian ophub images (6.x mainline kernels) fail to engage the bootloader at power-on and skip straight to the internal, native Android OS, even with aml_autoscript renames or script adjustments. Because CoreELEC 9.2.8 catches immediately, I know the physical hardware, SD slot bus, and basic external boot priority work perfectly. It confirms this specific box requires a primitive build structure that still utilizes the true legacy u-boot.ext chain-loader file on the root partition and simple text configuration (uEnv.ini or early uEnv.txt configurations) which these stubborn eMMC controllers require to handshake. CoreELEC If anyone has a preserved .img.xz or .img.gz file sitting on a local drive or a private cloud mirror (like an old balbes150 or flippy build from 2020–2022), I would greatly appreciate a download link! Thanks in advance for keeping the legacy hardware archive alive.

Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

I guess dirty spi. wipe it and try again

Hello, I am attempting to run armbian off of UFS on an a7z and running into issues. I don't know if I'm missing something fairly basic. - Board is unmodified by me. I don't know how commonly sellers mod these boards themselves, but there is a bit of scuffing on the ram and UFS chip. It has 8gb ram, the official hsf, and the official power supply. Display over HDMI, USB hub for IO. - I can boot the official radxa image from the ufs, flashing it with sudo dd if=<path_to_image> of=/dev/sda bs=4M status=progress conv=fsync - I have successfully built and booted armbian trixie 6.6 kernel with kde on the sd card. I had to do some tty backflips to get kde to launch once it booted, but it did run. I have also booted the released armbian xfce build from sd, which I had no problems with at all. - Currently I have the official radxa image booted off the sd card, and I have been attempting to build and flash armbian for ufs. - I built with ./compile.sh, board selection: radxa-cubie-a7z-ufs, vendor 6.6, trixie, desktop, kde, no extras - Flashed to the ufs with the same command from above from my session on the radxa build sd card, and rebooted without the sd card. The green LED comes on solid, then the fan kicks in, then the LED turns off. My display comes up out of sleep, black screen for a second, then no signal. - After about 25 minutes, I disconnected power, and booted back into the sd card. Here is the boot.log from the ufs: https://pastebin.com/ASpndqVU

Nick's instructions: You need to add this line to the bottom. "+CONFIG_SPL_IMAGE_TYPE_SUNXI_TOC0=y" and change "@@ -0,0 +1,31 @@" to @@ -0,0 +1,32 @@. ./compile.sh choose "Do not change kernel configuration" choose "Show CSC/WIP/EOS/TVB" choose "I understand and agree" choose "X98H" choose "edge" rest is up to you. Your image should be in output/images directory.

Hello, I tired to boot Armbian for my Rock5b but whatever image I choose to use, I'm never able to get past U-boot into linux when looking at the Uart output. Here are the log I get: ``` U-Boot SPL board init U-Boot SPL 2017.09-gd1cf49135ee-220414-dirty #stephen (May 23 2024 - 19:39:28) Trying to boot from MMC2 GUID Partition Table Entry Array CRC is wrong: 0x71678773 != 0xab54d286 part_get_info_efi: *** ERROR: Invalid GPT *** part_get_info_efi: *** Using Backup GPT *** spl: partition error Trying fit image at 0x4000 sector ## Verified-boot: 0 ## Checking atf-1 0x00040000 ... sha256(7612223b82...) + OK ## Checking uboot 0x00200000 ... sha256(b6f9939e11...) + OK ## Checking fdt 0x003200d8 ... sha256(e3b0c44298...) + OK fdt_record_loadable: FDT_ERR_BADMAGIC ## Checking atf-2 0xff100000 ... sha256(70505bb764...) + OK fdt_record_loadable: FDT_ERR_BADMAGIC ## Checking atf-3 0x000f0000 ... sha256(b2af21b504...) + OK fdt_record_loadable: FDT_ERR_BADMAGIC Jumping to U-Boot(0x00200000) via ARM Trusted Firmware(0x00040000) Total: 729.286/924.898 ms INFO: Preloader serial: 2 NOTICE: BL31: v2.3():v2.3-868-g040d2de11:derrick.huang, fwver: v1.48 NOTICE: BL31: Built : 15:02:44, Dec 19 2024 INFO: spec: 0x1 INFO: code: 0x88 INFO: ext 32k is not valid INFO: ddr: stride-en 4CH INFO: GICv3 without legacy support detected. INFO: ARM GICv3 driver initialized in EL3 INFO: valid_cpu_msk=0xff bcore0_rst = 0x0, bcore1_rst = 0x0 INFO: l3 cache partition cfg-0 INFO: system boots from cpu-hwid-0 INFO: disable memory repair INFO: idle_st=0x21fff, pd_st=0x11fff9, repair_st=0xfff70001 INFO: dfs DDR fsp_params[0].freq_mhz= 2112MHz INFO: dfs DDR fsp_params[1].freq_mhz= 528MHz INFO: dfs DDR fsp_params[2].freq_mhz= 1068MHz INFO: dfs DDR fsp_params[3].freq_mhz= 1560MHz INFO: BL31: Initialising Exception Handling Framework 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 ``` I tried to use multiple SDcard and different power supply (67W 5v phone charger and USB-PD bricks) but I never got any logs after `INFO: SPSR = 0x3c9`. I tried multiple Armbian images with vendor and current kernel, minimal ones and ubuntu gnome ones. I'm starting to wonder if my board is broken but I can boot the Android image that I found here https://forum.radxa.com/t/rom-rock5a-b-androidtv-12-by-mo123/15527

@Nick A I had to modify the "0011-Add-BSP-support-files-afa7aabb90" patch in the "Radxa-mainline-WIP-test" branch to allow compiling. This is the new patch file: https://pastebin.com/3Qc2bGPY After flashing the image to the emmc I got this bootlog: https://pastebin.com/eqsZ2d1r It seems like it wont leave the U-Boot. I used this command to flash the image: sudo dd if=/mnt/transcend/Armbian-unofficial_26.02.0-trunk_Radxa-cubie-a7a_trixie_edge_6.18.19_gnome_desktop.img of=/dev/mmcblk1 bs=4M status=progress conv=fsync @alexc Do you know if the A523 and A733 use the same pcie driver? I've already optimized the A523 pcie driver and its in the mainline armbian.

How To Fix the “Aw, Snap!” Error. Nothing help

Hello, Thanks for your answer, in fact I chose this M2U image because the hardware between M2B & M2U is almost the same : same CPU & arch, just a difference in RAM size & ports number (see image below) Maybe it is a "noob" way of thinking anyway, so I will try to adapt and find a solution around watchdog & sysrq, and if it does not work I will go back to raspberry pi. Have a nice day Regards

There's been a few changes to make etehrnet work on H6 that broek it for H616/H618 seemingly. Your best course of action for now would be to downgrade to 6.12 and lock the `linux-*` from being upgraded.

Hi, I can suggest a general procedure but it is not guaranteed to work for every TV-Box. 1) Be sure of what TV-box you have (Allwinner, Ambian or Rockship); 2) download git clone --depth=1 --branch=main https://github.com/armbian/build 3) open downloaded git and search for /build/patch/u-boot 4) select the directory that corresponds to your TV-box. For example: /build/patch/u-boot/u-boot-sunxi 5) edit arm64-sun50i-H313-add-lpddr3-deconfig.patch, if you have a secure image: add +CONFIG_SPL_IMAGE_TYPE_SUNXI_TOC0=y and increment the counter to 32 (@@ -0,0 +1,32 @@) and "secure-boot.patch" to /build/patch/u-boot/u-boot-sunxi. See procedure here https://forum.armbian.com/profile/210518-nick-a/ 6) ./compile.sh observing Nick's instructions.

Just to let you know usb bug is still present in 7.1 rc3 [ 2.596444] usb 4-1: new full-speed USB device number 2 using ohci-platform [ 2.784449] usb 4-1: device descriptor read/64, error -62 [ 3.076447] usb 4-1: device descriptor read/64, error -62 [ 3.356447] usb 4-1: new full-speed USB device number 3 using ohci-platform [ 3.532450] usb 4-1: device descriptor read/64, error -62 [ 3.824440] usb 4-1: device descriptor read/64, error -62 [ 3.928486] usb usb4-port1: attempt power cycle [ 4.140440] usb 4-1: new full-speed USB device number 4 using ohci-platform [ 4.548447] usb 4-1: device not accepting address 4, error -62 [ 4.732456] usb 4-1: new full-speed USB device number 5 using ohci-platform [ 5.140438] usb 4-1: device not accepting address 5, error -62 [ 5.140481] usb usb4-port1: unable to enumerate USB device