All Activity

@Nick A Thank you for the reply! I am still eager to try and load a different OS onto these two sticks. Sorry for the delay, somehow I just found the e-mail notifying me of your response now I'm not familiar with the process of trying to flash an image so I will start there, but before I do, is there a possibility whatever changes are made won't work, can't be undone and then brick the device? I'd probably rather not risk it if that's a possibility. But if there's always a way to re-flash them, I'm totally interested in trying anything I possibly can I'll wait to hear back from you before I attempt anything -- thank you!!

Any comments on this would be welcome.

You'll spend the money once. Then you'll have the result thereafter. I would suggest deciding what you want, then spending whatever it costs. Orange PI is "cheap", not just in price, but in hardware reliability as well as software support. I'm not aware of such issues with Radxa. RK3588 is more powerful than Raspberry PI, but as you say Raspberry PI has great community and support. Perhaps the question is - What do you need it for? Raspberry PI might be powerful enough for your needs.

I have an Orange PI 5 Plus, and both USB-C connectors (including the one used for power delivery) are faulty. Also the second HDMI output is corrupted. Clearly their manufacturer leaves a lot to be desired.

Modproble probes modules built into the kernel itself. An external package (other than the kernel itself) shouldn't affect it. If it was present via modprobe before, and not after, that isn't the zfs package, that would indicate a module that had been built into 25.8.1 kernel, then excluded from the 25.8.2 kernel build for some reason.

Depends on your use case. If you need raw cpu power, better gpu or video processing, Go for RK3588/s based board. If you heavily rely on GPIO and its functions (PWM, I2C,...) go for RPi.

@Jeeva Kandasamy I haven't had that error before. Maybe your host is out of date. Have you tried "sudo apt update && sudo apt upgrade"?

sudo rm -rf /var/lib/apt/lists/* sudo apt clean sudo apt update sudo apt upgrade works for me.

I've heard people say that the Orange Pi is a "budget alternative" to the Raspberry Pi. On one hand, the Raspberry Pi has an excellent community, with a large user base that could really help you in your learning journey. On the other hand, the Orange Pi offers great value for money, and it's really tempting because the Raspberry Pi can be a bit pricey. What's your suggestion?

I don't think simply documenting what needs to be installed is the solution. (Since I've already managed to figure that out, assuming my previous message went through.) I was trying to highlight that if a service is integrated into the installer (f2fs formatting), it would be elegant (or we could call it necessary) if that minimal package were part of the stock system, so the armbian-install doesn't break."

Found with google: https://forum.armbian.com/topic/34923-csc-armbian-for-rk322x-tv-box-boards/page/96/#findComment-218361

Did you check already merged PRs which were adding new boards? Like https://github.com/armbian/build/pull/8754/files Should give some clues.

I am currently trying to add the board support "the official way" by forking the repo and adding the board in the "Community maintained" category. To me it seems that this requires not "normal" .config files, but ".csc" files. This is fine and I created one accordingly. But I dont know where to place it. What would be the best place for that? Additionally, I have created a patch that pulled the latest DTS file for the M1S from the mainline kernel repo. That worked fine as well and after compilation there was a local DTS file created and everything worked so far. But here I have the same problem/question: where to put these patches? Or is it preferable to use the created DTS file and place that somwhere without the patches that pull the mainline DTS? So basically I wish for a little bit support where to put which files to be "Board support Rules" compliant. Greetings!

Good point! I was not aware of that. I will try today and report back.

Lowest price is what makes it popular. But software is the biggest key of the package and there they are among the worst. On this SoC, we will be cooperating with SoC maker's board directly - working with Orangepi is too damaging for us: https://www.cnx-software.com/2025/04/27/muse-pi-pro-feature-packed-credit-card-sized-spacemit-m1-risc-v-sbc/ This will probably be done in a couple of weeks, so you can follow that and adjust accordingly.

Thank you for your quick answer, Jimbolaya. Yes, I did try different cables all with the same result. I wonder if there is another way to access the serial console, J13 perhaps? Albeit with some required soldering, I suppose. Then remains the question of which headers exactly relate to GND, TX and RX.

I don't think that's a relevant issue. I couldn't `modprobe zfs` in my case.

I noticed this problem a long time ago, but now I feel it is important to fix it: I get a slim black bar on the left side, and a portion of the pixels on the right get "cropped" because they don't fit in the LCD display area? Do you get the same in your LCD? Do you know a way to fix it? I am talking about this LCD: RED PCB LCD https://www.aliexpress.us/item/3256802847521952.html?

Hi @Nick A I tried build your fork repository and facing the following error, Can you please help me to fix this error? Source code: https://github.com/NickAlilovic/build/ $ git remote -v origin git@github.com:NickAlilovic/build.git (fetch) origin git@github.com:NickAlilovic/build.git (push) $ git branch main * v20250306 Build command: ./compile.sh build BOARD=x96q-lpddr3-v1-3 BRANCH=edge BUILD_DESKTOP=no BUILD_MINIMAL=yes KERNEL_CONFIGURE=yes RELEASE=trixie Error: [🐳|🌱] git: Fetch from remote completed, rev-parsing... [ 'debootstrap-debian-devel' 'master' 'FETCH_HEAD' ] [🐳|🌱] Debootstrap version [ '1.0.142' for /armbian/cache/sources/debootstrap-debian-devel/debootstrap ] [🐳|🌱] Installing base system with 5 packages [ Stage 1/2 ] [🐳|🔨] I: Retrieving InRelease [🐳|🔨] I: Checking Release signature [🐳|🔨] E: Release signed by unknown key (key id 762F67A0B2C39DE4) [🐳|🔨] The specified keyring /usr/share/keyrings/debian-archive-keyring.gpg may be incorrect or out of date. [🐳|🔨] You can find the latest Debian release key at https://ftp-master.debian.org/keys.html [🐳|💥] error! [ Debootstrap first stage failed /armbian/cache/sources/debootstrap-debian-devel/debootstrap trixie yes ] [🐳|💥] Cleaning up [ please wait for cleanups to finish ]

Unfortunately I don't have experience with the onboard flash, but I've never had an issue with the serial port. You've tried different cables i assume?

@jock Tested this and got a 1mim watchdog crash. I dont know if it helps to track this issue but with: "rk322x_tee_1.0.1-72-gf230aa2.bin" it goes to a 30mim. Like i said before, im kinda new to this. so i might have done something wrong when building armbian. If anyone here has a working build that does not trigger this watchdog, please let me know.

In theory, it shouldn't

I received a Helios4 and was finally able to get it to boot. As per instructions, I booted from microSD and flashed the latest Armbian image to sda1 via the nand-sata-install command. This reboots fine now, but only with the microSD-card present and the SW1 dipswitch set to "SD card boot mode". Is anybody here using "SPI NOR Flash" or "SATA1" boot mode to get rid of the microSD card? I am bit handicapped here since my serial port on the microUSB only comes up maybe 1 in 10 times. I wonder if it's worn out or if I am simply doing something wrong. Related Links: 1 2 3

@jock Does it make a diference witch multitool trusted OS i use?

I'm looking for Orange Pi RV2 RISC-V support. This board is gaining popularity due to the Orange Pi manufacturer's good reputation with Arm. I have successfully built both Orange Pi and Raspberry Pi aarch64 builds on Debian from source so I'd like to know how to build Armbian for Orange Pi RV2 riscv64. What would I need to modify in the build process? Thanks!!