All Activity

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.

@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

Hi, yes this was also my conclusion. The pins were defined OK, but there was no voltage on that VCCIO4 domain - so the whole GPIOx was kept inactive or in a reset. It was confusing me, why BT is running, but there is no WiFi - the chip has to be powered somehow. I also see that you already defined the backlights on this PCBA. This one is also confusing me - how is this one PD7? It should normally be PB7 on the GPIO2. Maybe can you share your current dtb file and I will also test it out?

@Dbosco Build and install with at least GBM Paste the following in /usr/share/wayland-sessions/kodi-wayland.desktop [Desktop Entry] Name=Kodi Wayland Comment=This session will start Kodi media center Exec=env FFMPEG_RKMPP_DEC_OPT="afbc=on" kodi --windowing=gbm --audio-backend=alsa TryExec=kodi-standalone Type=Application Keywords=audio;video;media;center;tv;movies;series;songs;remote; Icon=kodi Otherwise try to stop the window manager and start it manually to see if it gives an error, from login window press: ctrl+alt+F2 -> sudo systemctl stop gdm3 -> env FFMPEG_RKMPP_DEC_OPT="afbc=on" kodi --windowing=gbm --audio-backend=alsa

@royk after applying the patches i've tried to build Kodi with severals of the configurations available and always with GLES, but there are some issues: cmake ../kodi -DCMAKE_INSTALL_PREFIX=/usr/local -DCORE_PLATFORM_NAME="x11 wayland gbm" -DAPP_RENDER_SYSTEM=gles it start Kodi but with X11 cmake ../kodi -DCMAKE_INSTALL_PREFIX=/usr/local -DCORE_PLATFORM_NAME=gbm -DAPP_RENDER_SYSTEM=gles and cmake ../kodi -DCMAKE_INSTALL_PREFIX=/usr/local -DCORE_PLATFORM_NAME=wayland -DAPP_RENDER_SYSTEM=gles Kodi doesn't starts, it just return to the login page for all the cases the session name is "Kodi" and not "Kodi-Wayland" as was before with GDM3 and previous kernel. ls /usr/share/xsessions plasmax11.desktop ls /usr/share/wayland-sessions plasma.desktop any idea? thanks!

analysing DTS File From H96_MAX Kernel 6.6 Using this method From Kernel 6.6: It's the same as Firefly board I have tested the pin12 from HCY6335 with kernel 6.2 it receives 1.8v with kernel 6.6 it receives 0.0v From Kernel 6.2: From Kernel 6.2: GPIO Definition: Applyed changes here: https://github.com/hqnicolas/ArmBoardBringUp/blob/main/patch/kernel/archive/rockchip64-6.6/dt/rk3566-h96-tvbox.dts Testing..............

hi Protx: Hello, I have just started learning the compilation of Armbian. I am also using the OrangePI3b with the RK3566. I need to study the startup of rknpu in version 6.1.43. I downloaded the latest repository from https://github.com/armbian/build, specifically the main branch. I compiled it according to your compilation configuration. There was an error message upon booting. ** Booting bootflow 'mmc@fe2b0000.bootdev.part_1' with script Boot script loaded from mmc 1:1 155 bytes read in 3 ms (49.8 KiB/s) 8598033 bytes read in 724 ms (11.3 MiB/s) 37388800 bytes read in 3133 ms (11.4 MiB/s) 167999 bytes read in 47 ms (3.4 MiB/s) Working FDT set to a100000 Trying kaslrseed command... Info: Unknown command can be safely ignored since kaslrseed does not apply to all boards. Unknown command 'kaslrseed' - try 'help' Moving Image from 0x2080000 to 0x2200000, end=4660000 ## Loading init Ramdisk from Legacy Image at 0a200000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 8597969 Bytes = 8.2 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 0a100000 Booting using the fdt blob at 0xa100000 Working FDT set to a100000 Loading Ramdisk to ec68e000, end ecec11d1 ... OK ERROR: reserving fdt memory region failed (addr=0 size=0 flags=0) ERROR: reserving fdt memory region failed (addr=0 size=0 flags=0) Loading Device Tree to 00000000ec5fc000, end 00000000ec68dfff ... OK Working FDT set to ec5fc000 Starting kernel ... [ 14.607208] Internal error: Oops: 0000000096000044 [#1] SMP [ 14.607281] pwm-backlight backlight: Looking up power-supply from device tree [ 14.607780] Modules linked in: [ 14.607848] pwm-backlight backlight: Looking up power-supply property in node /backlight failed [ 14.608469] sprdbt_tty(+) [ 14.608536] pwm-backlight backlight: supply power not found, using dummy regulator [ 14.608569] fuse dm_mod ip_tables ipv6 panel_simple pwm_bl [ 14.611186] CPU: 1 PID: 312 Comm: systemd-modules Tainted: G W 6.1.43-vendor-rk35xx #1 [ 14.612092] Hardware name: Rockchip RK3566 OPi 3B (DT) [ 14.612601] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 14.613282] pc : tty_unregister_driver+0x44/0x78 [ 14.613752] lr : tty_unregister_driver+0x40/0x78 [ 14.614212] sp : ffff80000d02b7c0 [ 14.614544] x29: ffff80000d02b7c0 x28: ffff80000a10f0c8 x27: 0000000000000000 [ 14.615242] x26: 0000000000000000 x25: ffff80000a23f000 x24: ffff0000092f8400 [ 14.615937] x23: ffff80000122d000 x22: ffff80000122e178 x21: 00000000ffffffef [ 14.616632] x20: ffff80000a2272e0 x19: ffff000008c7fb00 x18: 0000000000000000 [ 14.617328] x17: 7420797274207427 x16: 6e6f64202c545349 x15: 5845452d20687469 [ 14.618028] x14: 7720305442797474 x13: 2e79726f74636572 x12: 696420656d617320 [ 14.618724] x11: 656874206e692065 x10: 6d616e20656d6173 x9 : ffff80000915ee50 [ 14.619420] x8 : 696166206c616e72 x7 : 65746e695f646461 x6 : 0000000000000000 [ 14.620115] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 14.624209] x2 : ffff000001731c80 x1 : dead000000000100 x0 : dead000000000122 [ 14.628287] Call trace: [ 14.631921] tty_unregister_driver+0x44/0x78 [ 14.635732] mtty_probe+0x1e8/0x2b0 [sprdbt_tty] [ 14.639572] platform_probe+0x70/0xc0 [ 14.643282] really_probe+0x1cc/0x390 [ 14.646981] __driver_probe_device+0x140/0x158 [ 14.650736] driver_probe_device+0x48/0xd0 [ 14.654452] __device_attach_driver+0xd8/0x128 [ 14.658174] bus_for_each_drv+0xa0/0xc8 [ 14.661870] __device_attach+0xf8/0x180 [ 14.665557] device_initial_probe+0x1c/0x28 [ 14.669266] bus_probe_device+0x38/0x9c [ 14.672951] device_add+0x550/0x688 [ 14.676590] platform_device_add+0xec/0x224 [ 14.680286] mtty_pdev_init+0x50/0x1000 [sprdbt_tty] [ 14.684061] do_one_initcall+0x94/0x1e4 [ 14.687709] do_init_module+0x58/0x1e0 [ 14.691329] load_module+0x1818/0x18e0 [ 14.694906] __do_sys_finit_module+0xf8/0x118 [ 14.698524] __arm64_sys_finit_module+0x24/0x30 [ 14.702132] invoke_syscall+0x8c/0x128 [ 14.705606] el0_svc_common.constprop.0+0xd8/0x128 [ 14.709161] do_el0_svc+0xac/0xbc [ 14.712551] el0_svc+0x2c/0x54 [ 14.715888] el0t_64_sync_handler+0xac/0x13c [ 14.719319] el0t_64_sync+0x19c/0x1a0 [ 14.722684] [ 14.722684] PC: 0xffff80000875f79c: [ 14.723515] rk_pcie_establish_link: 132 callbacks suppressed I found that the latest repository does not match your operating instructions. For example, the commit 63073b4af636146d26a7f0f258610eed060c8f34 in the Kwiboog's uboot repository branch rk3568-2023.10 is no longer found. However, the compilation does not report any errors. Could you please share your compilation repository and configuration? Thank you. @Protx kernel.log

Your firmware is build without persistent Environment. Only the compiled-in Environment is used, which can only be modified before build.

Here's the latest build if anyone wants to test it out. https://armdev.pixeldrift.net/transpeed/8k618-t/

https://docs.u-boot.org/en/latest/usage/cmd/env.html Yes I should be able to change the boot-delay of u-boot but it doesn't persist, when I restart the value is gone. I interrupt the boot by hitting any key. Then I do Then I should be able to do but "save" doesn't exist. I will look into how to build/replace this version of U-boot

I'm working here too, I reflash my device with the official github armbian compiled and extracted again the DTB to DTS rk3566-h96max.dtsrk3566-firefly-roc-pc.dts RK3566-firefly-roc-pc = DTS Kernel 6.2 RK3566-h96max = DTS Kernel 6.6 The regulator is TCS4525 and i'ts the same as the Armbian Repo!

Hello, Is it possible install armbian on allwinner h616 - Cortex A53 - x96 mate ? If yes, where is procedure to do that ? Sorry for my poor english. Thank you for your help.

@voapilro I can offer to help but I might not be able to help at the speed you desire; it might take me a few days to have time to offer some patches. You may find that if you power on the board a number of times you will observe correct and incorrect memory counts, and having an approximate percentage of how often it's wrong would be interesting. My direction of attack would be to look at the vendor BSP and check what's different between the 1.5GB build they offer and the build for 1GB/2GB/4GB. The difference should provide a clue to what might need patched and whether something might be missing from the Armbian patch collection. (Out of interest have you tried the vendor build, and if so does it exhibit the same problem? Does it fail with the same percentage?) I'm not working directly in Armbian with the Orange Pi Zero 3 but have been working on a yocto layer which incorporates patches collated by @Nick A.