All Activity

I have the installed community build 24.5.0-trunk.417 Bookwarm. Radxa official guidance (link) asks to edit /boot/hw_intfc.conf file to change between host & OTG mode. Armbian build does not have hw_intfc.conf file but I believe /boot/ArmbianEnv.txt is Armbian way to manage the config. what is the correct way add "intfc:dtoverlay=rk3399-usb-otg" overlay in ArmbianEnv.txt file?

Hi, My command: To scrub RAID10: echo check > /sys/block/md0/md/sync_action At same time i check BTRFS with: btrfs check --readonly --check-data-csum --progress /dev/disk/by-uuid/1d4e2c84-1c43-4d73-8acb-XXXXXXXXXXXXX At at same time i do copy/delete/copy random from personnal computer to helios64 samba share one pass finished after about 36h... i run pass 3 times For information, i use LUKS overs my raid10 My fancontrol file is: root@helios64:~# cat /etc/fancontrol # Helios64 PWM Fan Control Configuration # Temp source : /dev/thermal-cpu #INTERVAL=10 INTERVAL=30 FCTEMPS=/dev/fan-p6/pwm1=/dev/thermal-cpu/temp1_input /dev/fan-p7/pwm1=/dev/thermal-cpu/temp1_input MINTEMP=/dev/fan-p6/pwm1=40 /dev/fan-p7/pwm1=40 #MAXTEMP=/dev/fan-p6/pwm1=110 /dev/fan-p7/pwm1=110 MAXTEMP=/dev/fan-p6/pwm1=50 /dev/fan-p7/pwm1=50 #MINSTART=/dev/fan-p6/pwm1=60 /dev/fan-p7/pwm1=60 MINSTART=/dev/fan-p6/pwm1=20 /dev/fan-p7/pwm1=20 #MINSTOP=/dev/fan-p6/pwm1=40 /dev/fan-p7/pwm1=40 MINSTOP=/dev/fan-p6/pwm1=20 /dev/fan-p7/pwm1=20 MINPWM=20 and i install: Full Firmware deb package to remove error with 2,5G ethernet driver I do extend of swap by swapfile to 6Go and i run 2 containers with podman, Plex and SFTPGO

Ive never frozen the kernel when doing upgrades. So that shouldn't be necessary. I would recommend redoing the upgrade, and at the end looking at the list of obsolete packages and not removing them. Finish the upgrade (without removing obsolete packages) then go see what the status of your /etc/apt/sources.d/armbian.list file is and make that correct, then use apt to update/upgrade your armbian packages. Then look at your obsolete packages and make sure the list is sane (that is it's not removing any armbian needed packages, *armbian*, linux-image-* or linux-dtb-*.) Only then would I remove obsolete packages.

@voapilro, @bjorn, @electricworry I'm attempting to fix (at least a hack) the 1.5GB problem by attempting to build a custom u-boot to attempt to resolve the issue. The thing is the codes are pretty complex. https://docs.u-boot.org/en/latest/ https://source.denx.de/u-boot but that actually I succeeded in building u-boot The trouble is I'm getting this: U-Boot SPL 2024.04-00757-gbeac958153-dirty (Apr 18 2024 - 23:22:28 +0800) DRAM: 0 MiB Trying to boot from MMC1 NOTICE: BL31: v2.10.0(release):v2.10.0-729-gc8be7c08c NOTICE: BL31: Built : 23:11:18, Apr 18 2024 NOTICE: BL31: Detected Allwinner H616 SoC (1823) NOTICE: BL31: Found U-Boot DTB at 0x4a0be348, model: OrangePi Zero3 ERROR: RSB: set run-time address: 0x10003 ion U-Boot 2024.04-00757-gbeac958153-dirty (Apr 18 2024 - 23:22:28 +0800) Allwinner Technology size=30, ptr=590, limit=2000: 26370 CPU: Allwinner H616 (SUN50I) Model: OrangePi Zero3 DRAM: 0 Bytes So I literally need help with the codes, I'm doing pretty tedious debug etc with a 1.5G OPi Z3 board I bought for this purpose. if you run the 'original' images, that has a 'working' u-boot, it reads DRAM 2GB https://www.armbian.com/orange-pi-zero-3/ still 'incorrect' but that accordingly there'd be fixes for it (in u-boot) https://forum.openwrt.org/t/can-someone-make-a-build-for-orange-pi-zero-3/168930/42 https://gist.github.com/iuncuim The trouble as i try to trace where the calls are going is that it is not even going into the dram initialization codes in u-boot meant for H616/H618 to initialize and size up the lpddr4 dram. the codes are complex and I'd hope to get some leads there to attempt a solution. if a 'custom u-boot' can fix that, it'd at least help those who still only have 1.5GB boards to get Armbian running on it. By *replacing* the u-boot (practically the boot loader (and BIOS)) in the image or sd card. The image (and on the SD card) looks like this 0-7 KB (unused/reserved) 8 KB - 1 MB u-boot 1 MB - the rest of your sd card (this is your linux partition and Armbian proper (Debian or Ubuntu) lives here) u-boot does the bulk of the 'black magic' dealing with memory initialization and sizing, and then passing that across to linux during boot up. and linux uses the device tree (DTB, DTS) to configure the various devices uart, usb, sd card, leds, etc etc and subsequently present various of them in /dev. a 'custom u-boot' apparently seem to be a most feasible 'solution' (hack) to at least get past the 1.5GB problem. it is quite easy to simply take the original image, and substitute one u-boot made to say the memory is 1.5GB.

@voapilro orange pi's suffer from a few things, in particular poor software support and if you have an issue and goto their forums http://www.orangepi.org/orangepibbsen/ you can see a lot of no responses, spams etc. and that for the 'official' images you have obtained, those are the relevant support forums as they are different from Armbian today. The images released from Orange Pi are linux kernel versions 6.1 which has yet been updated, nothing 'wrong' about it, but that linux version progress is relentless. in fact Orange Pi Zero 3 (and a little later Zero 2W) is supported out of mainline linux from kernel release 6.6, i.e. the DTS (device tree configuration) is released open sourced. And that the implementation from mainline is completely developed open sourced (by various talented individuals outside here in linux-sunxi i think, and subsequently the few of us here siezed on the opportunity and tried to make Armbian run on it, browse the earlier part of this thread and you see @Gunjan Gupta, @pixdrift, @Stephen Graf et.al working this, we also found that a lot of things are undocumented and it is a *miracle* that it is after all running (well) today. try getting a 1G / 2G / 4G board and run Armbian on it. https://www.armbian.com/orange-pi-zero-3/ And I'd like to add that Armbian itself @Igor and team contributes in no small measure that makes this project possible (just consider catching up with the linux versions with so many platforms to carry), considering that there is no 'big company' (e.g. Intel, Rpi etc) behind this. it is all little contributors whom you see here. In this sense, the users of Armbian are the contributors and maintainers as well, a co-operative, practically the spirit of open source, if after all that economic model works. A good thing is that you can literally build ths whole thing (the images for your board from *source*) https://github.com/armbian/build you can configure all the kernel parameters for all you want for the build, edit the source codes, fix bugs, add features etc, there are many 'upstream' projects which include the linux kernel itself, u-boot, the distributions Debian / Ubuntu that contributes into the assembly, probably others as well, and the armbian build framework at this day is huge and complex considering the platforms (boards) that is supported. This probably also matter to 'security conscious' people who want to know every nut that is in there. But that it is up to you to make the effort to inspect that there are no 'holes' (e.g. trojans, backdoors, connecting to 'unauthorized' C2 (command and control) sites that you don't want etc). e.g. you can inspect and tweak all you want and afterwards run the build. And not least being open sourced means that it is nearly / practically *bare metal*, the codes work the metal (transistors / silicion / registers) directly, no blobs in-between. The trouble with blobs is your app is release to you as a binary, the driver is a binary (blob), then a new os (e.g. linux version, you can even consider windows) is released, now your binary app and or driver no longer works in the new os version (linux or windows), and you can use your device (e.g. mouse) as your new door stop. buy a new one and again more binaries , more device driver blobs.

Yes, in the very end I was asked to remove obsolete packages. I said yes all the times. I don't remember what was in the list, since it was about 76~ packages I may try with no option to keep them Is there any way to enforce this manually pre-upgrade? I only freeze the kernel, i suppose it is something different? Or maybe I can try to upgrade without freezing kernel? Or is that a guaranteed fail?

I do not want to start a discussion on this subject. I just want to clarify my point of view. I have several flavours of RPi2, RPi3, RPi4 and I will buy a RPi5 soon. I really like RPi, not only the boards, specially software provided by both manufacturer and community. Just googling a while you can find a lot of resources on RPi, and as a contrary much less for OPi. I do not think RPi4 or RPi5 are expensive, they are new desings, very powerfull, so they cost money. But must of the times, in my case, a RPi3B+ is more than enough, it is an old design, but still powerfull enough for a lot of things, and very well supported. What I do not understand is that RPi3B+ is almost the price of RPi4B-1GB. If RPi3B+ price was more reasonable, I would not be looking for alternatives like OPi. I guess this way RPi manufacturer is pushing us to RPi4 and RPi5, but what they get is that some people like me are looking for other options same power as RPi3.

Please submit a PR, and this can be discussed there.

@darcyg What i meant was that you manually apply the uw5622-fix-adjust-for-rockchip-post-6.1.patch before ./compile command. Then after compilation check that : --> (15) INFO: * patch/misc/wireless-uwe5622/uwe5622-adjust-for-rockchip-post-6.1.patch is included in the log file. BTW: Do not mind the * applying patch/misc/wireless-uwe5622/w-wireless-fix-out-of-tree-build.patch That was a patch I saw was included in the ubuntu rockchip kernel. I do not think that is needed, does not seem to make a difference.

I translated it wrong 0x0f 15 PB7 https://github.com/hqnicolas/ArmBoardBringUp/blob/main/patch/kernel/archive/rockchip64-6.6/dt/rk3566-h96-tvbox.dts Testing.....

Can you provide the exact commands you run to get the crash? Also for most of the instability (big CPU cluster) see my comment above, that is up the opp-table-1 voltages by 75mV. Else I will post the DTS block to up the opp-table-1 voltages by 75mV in a few days at most, I hope.

Hello, I would like to propose a change to the default kernel config for the r4s. Currently in .config # # USB HID support # CONFIG_USB_HID=y CONFIG_HID_PID=y CONFIG_USB_HIDDEV=y This should be altered to CONFIG_USB_HID=m This change has been requested previously for other boards: here and is also explained properly. To summarise : the change would allow those using APCUPSD to communicate with their APC UPS device. TiA!

@ebin-devI discussed with on IRC #u-boot and I believe one board designer told me that there could be issue with the regulatorh hardware design (CPU big). He suggested me to up the voltage to max after looking at the schematics (that are available in the wiki in the left pane documents section) to try if it fixed my crashes and this indeed fixed lost of them. That is I first tried every opp-table-1 ie cpu-b at 1.2V then I tried with voltage closer to the vanilla rk3399 ones. In the end I was able to run the cpufreq switching test I gave you 100 times without a crash with upping all the opp voltages for cpu-b by 75mV. Any of the opp run mostly stable with only 50mV but in I still had crashes. So up 75mV looks fine. I still have crash around once a day but not with my cpufreq test case as far as I know. I am now on on demand cpufreq governor with freq from 408MHz to 1.8GHz. Still I would really like to be able to be able to reproduce the crashes I still get. They might be from gpu opp voltages as they have the same hardware design as the CPU-big. Or something else. But I doubt the kernel is involved except that any kernel version might stress the board less. But for one I had added a big delay between CPU-b frequent switching and still had crashes, so I doubt the speed has anything to do with it. And in my test I tried with all cpu-b OPP voltages to 1.2V except even the lowest one and was still able to get random crashes with my cpufreq test case, so I doubt this had anything to do with high freq. Only that 1.6GHz was the one the most sensible to a voltage without 75mV up from upstream rk3399 OPP voltage values. And 408/600 were the less likely to crash but still crashed from time to time. I don't know if you know how to redefine the opp voltage values for cpu-b. I will try to post you my patch asap ( currently on my phone).

I would suggest you use the armbian build system and build the CLI minimal build for your board. That should be sufficient for your needs as a starting point. It is also a low barrier to entry as you can get that working with minimal understanding of what is going on behind the scenes. Then you can dig into the details to learn as you need.

Hi, I have not much time either, but I would like to see an Armbian release for the M1S. I have one M1S unit with me I could use for testing, but I will have to share it with other tasks. Maybe I could help accelerate the process somehow, I just don't know where to start. I have been using Linux on embedded systems for some years, but never went very deep. I have tried the linuxfactory bookworm image and it works, even with the Vu8S 8" display which connects to the MIPI connector. It must be installed to the onboard eMMC. Does someone want to guide me on this? Or maybe supply ready to flash images I could test?

https://elixir.bootlin.com/linux/latest/source/arch/arm64/boot/dts/rockchip/rk3566-box-demo.dts This one looks promising. Maybe we only need to change some pins.

moved ssh is enabled by default on all images. Check if there is further information in journal why it did not start.

@darcyg First let me say that I am no expert on this. I have not tried to compile it lately, but I see that that commit does not longer exist on kwiboo's github. So I don't now if you need to revert to an older version of u-boot. And if you have an EmmC og SPI with u-boot, then it should work to boot from SC card with the new uboot anyway. My log was with debug enabled (and from uart), and I dont have that log anymore. mtty_probe+0x1e8/0x2b0 [sprdbt_tty] So I am not sure the error is the same wireless / bluetooth related error that I got . But I think it is. Make sure that the patch uw5622-fix-adjust-for-rockchip-post-6.1.patch got applied. Take a look in the /output/logs, If you have build the kernel several times it could be using a cached kernel and not included in the log!?, (look in the largest log files). And verify that uw5622-fix-adjust-for-rockchip-post-6.1.patch was included in your compilation: --> (15) INFO: Adding [ Drivers for Unisoc uwe5622 found on some Allwinner and Rockchip boards ] --> (15) INFO: * applying patch/misc/wireless-uwe5622/uwe5622-allwinner.patch --> (15) INFO: * applying patch/misc/wireless-uwe5622/uwe5622-allwinner-bugfix.patch --> (15) INFO: * applying patch/misc/wireless-uwe5622/uwe5622-warnings.patch --> (15) INFO: * applying patch/misc/wireless-uwe5622/uwe5622-park-link-v6.1-post.patch --> (15) INFO: * applying patch/misc/wireless-uwe5622/uwe5622-v6.1.patch --> (15) INFO: * patch/misc/wireless-uwe5622/uwe5622-adjust-for-rockchip-post-6.1.patch --> (15) INFO: * applying patch/misc/wireless-uwe5622/wireless-uwe5622-Fix-compilation-with-6.7-kernel.patch --> (15) INFO: * applying patch/misc/wireless-uwe5622/wireless-uwe5622-reduce-system-load.patch --> (15) INFO: * applying patch/misc/wireless-uwe5622/w-wireless-fix-out-of-tree-build.patch --> (15) INFO: Preparing driver [ driver_rtl8723cs ]

Hello all. I can say that now I'm almost happy owner of the Orange Pi Zero 3 board. It took me weeks of googling to get to this awsome thread. Links from official OPi site lead to outdated images where many things didin't work as expected and with broken graphics acceleration. Finally I found armbian and its latest builds for Orange Pi Zero 3 board with working graphics at least. So, first of all, thanks to all people who contributed to this builds, it's an awsome work. I'm total noob in Linux, so I can't do much help here, however, if something needs testing with this board (OPi Zero 3, 2Gb RAM) I'll try to help. Inspite of being able to make my own toy OS for x86 platform I struggle with Linux as it is seems very complex to me so I came here for help or at least right direction. My current goal with Zero 3 board is to get very minimal Linux build which includes: - all CPU cores workig and ability to run single graphics application without desktop environment at all - working 3D acceleration for smooth graphics - working sound (either built in or through i2s interface, preferably) - working GPIO/SPI/UART for communicating with other peripherials built with 8-bit MCUs like ATmel 8-bit chips Currently I'm just learning how to build such kind of Linux images. I've already tried buildroot and "default" build didn't work for me, I guess it is not configured to use HDMI output for terminal by default and I couldn't find how to do that. I also found sunxi site and as I understood armbian is based on that. I tried to follow their instructions to build uboot and kernel however stuck with some steps and errors, and it's also not very clear if they managed to set up HDMI/Mail graphics working with their builds as some instructions labeled as outdated. I also tried Bookworm image and it works pretty well, I even set up xorg there and run glgears app for testing it, but it still pretty big to me and there are several issues with running graphical apps without desktop environment. So, any help on these two topics is very appreciated: - How to get really minimum build and where to find actual informaton about that kind of builds as there are many tutorials but they seems to be outdated/incomplete or do not cover board specifics. - How to get single graphics app running fullscreen without desktop environment (for this experiment I can start with Bookworm build) Thank you.

Orange Pi 5 plus. It seems that in the 'edge' kernels, ssh is disabled by default. Since HDMI doesn't function this is a problem. I used the debugging UART and after setup I got the message "ssh.service is disabled" I enabled the service and all is well. Any reason why ssh would be disabled?

A significant reason that the Raspberry Pis are more expensive is that the manufacturer actually invests time and resources into the underlying software. OrangePi does not. OrangePi takes advantage of the open source community hoping they can get software support for free without contributing much if anything to that process. There is a reason that OrangePi boards are not generally supported by Armbian, and lack of manufacturer support is a big reason. So that means that if you want good software to run on OrangePi boards, then OrangePi expects you to do the work. And that is a lot about what this thread in the forum is about - the community trying to support these boards.

@Dbosco (Assuming you set the settings in Kodi correct: settings->player->videos->render method Allow using DRM PRIME Decoder=enable Allow Hardware Acceleation with DRM PRIME=enable Prime Render Method=Direct to Plane) Perhaps something is wrong with your ffmpeg, mpp or rga. Try to follow the steps on: https://github.com/nyanmisaka/ffmpeg-rockchip/wiki/Compilation After that run the cmake command for kodi again before make and install.

Thanks @electricworry for your help! I installed an official Debian build for Orange Pi Zero 3 with 1.5GB, downloaded from here and named Orangepizero3_1.0.2_debian_bookworm_server_linux6.1.31_1.5gb.7z. I coud see that there is no official Armbian release, just an unofficial community release not tested by Armbian, so I did not try it. I could not find any other trustable build I could try, so please let me kown if there are other options. Regarding "vendor build" you mentioned, are you talking about a build provided by seller? If that is the case, I do not think they can provide it, they just sell the boards. Regarding the number of times I observe correct and incorrect memory size, it is difficult to say. I rebooted and power cycled the boards a lot of times since last monday, that is when I receved them, and it is quite ramdom. Sometimes it is easy to get and incorrect memory size once and again, other times is more difficult, and I do not see a pattern. I have both boards powered on all the time, and from time to time I reboot or power cycle them. Anyway, I would say that memory size is incorrect 1 of 4 times in all, but it is just an overall perception. I really like these boards, and 1.5GB memory size is the best option for my purposes. I bought two other Orange Pi Zero 3 with 1GB memory two months ago and they are working well. I am using them for creating a VPN, and they are more than enough. However, I would like to install some network management software that should fit in 1 GB memory, but I prefer to have some spare memory, just in case. I have being using some Raspberry Pi for several years, and I am happy with them, but prices are higher year by year, so Orange Pi could be a good alternative.

I'm sorry but I don't know the answer, I use my fake Tanix TX3 mini TV box with SOC 905L2-B as a server and I don't know if it's possible to have graphics acceleration with the Linux kernel. This post is related to android factory firmware request. I advise you to write a new one to ask specifically, you could ask in the general chat section of TV boxes forum.

thanks @royk now Kodi starts unfortunately when i'm playing a file the video is not showing, and I can listen the audio in the background. same with sudo systemctl stop gdm3 -> env FFMPEG_RKMPP_DEC_OPT="afbc=on" kodi --windowing=gbm --audio-backend=alsa to recap: build: Armbian_24.2.4_Orangepi5_jammy_vendor_6.1.43_kde-neon-amazingfated_desktop patched with 0001-rga3_uncompact_fix.patch and 0002-vop2_rbga2101010_capability_fix.patch Kodi Nexus GBM+GLES, with patches 0001-windowing-gbm-Dynamic-plane-selection.patch and 0002-VideoLayerBridgeDRMPRIME-Use-crop-fields-to-render-t.patch tested with GDM3 and SDDM dunno what i'm doing wrong