Search the Community

Hello all, As subtitler guy, I experienced many troubles making aegisub work. , I finally made the subtitle editor, working with hardware under armbian jammy but having still annoyances. I want to share my thought and my discoveries on it. First I would like to thanks all who post on this already, including alternative ways such as schroot and of course the armbian team for the improvements of the boot .. schroot allow to run an linux in a linux. According to what I experienced, meson driver development is leaded by oibaf and in advance in ubuntu but here aegisub does exists only on debian. The idea was thus to boot on debian jammy and chroot in debian buster armhf at least or better bookworm arm64. By doing so, I crashed many time aegisub 3.2.2 due to lua badly supported. schrooting and debian bookworm gives many warning messages (see the pict below, I washed the lua script directory too) but goes further if we dare to skip assert warnings. Moreover, at this point, we are no more dealing with Llvm (software accel using 100% of CPUs) but meson-drm and panfrost (harware accel, using 20% of CPUs). aegisub still remains very fragile but very responsive. So today I decided to switch and to boot into bookworm directly. After launching aegisub 3.20.3 on arm64 with panfrost enabled (you can check this with glxinfo -B, or inxi -Gs), I discovered it is very stable but suffered of responsivity due to a flood in the logs Hewitt has just given... a patch yesterday against "panfrost ffe40000.gpu: l2 power transition timeout" log flood here: https://lkml.org/lkml/2024/3/22/977 You will also be unable to set brightness by software (too bright for my eyes) at least on xfce4, trying my luck with all techniques https://askubuntu.com/questions/894465/changing-the-screen-brightness-of-the-external-screen that did not succeed except that ddcci-dkms gave me a clue during install : BACKLIGHT_CLASS_DEVICE disabled in this kernel I suggest enabling dkms and this for future kernel and taking Hewitt patch into account. With these findings, did someone has noticed the same and manage to make sound and videos responsive without unsync? PS/ For now, the armbian is on a sdcard, the log flood may be the cause of the unsync. I have to test further. Trying with latest jammy and schrooting under bookworm.

A stable Armbian Bookworm configuration for your Helios64 is provided here (solved). ************************************************************************* Recently a new Armbian 23.08.1 Bookworm image with linux-6.1.50 was made available for Helios64 on its download page (see here) - which is as such great 😀. Everything starts up nicely, but unlike the previous Bookworm 23.05 image, the current one has an issue with accessing USB devices. In the boot process the following error occurs: # cat /var/log/syslog | grep error 2023-09-07T12:31:05.671598+02:00 helios64 kernel: [ 2.537009] dwc3 fe900000.usb: error -ETIMEDOUT: failed to initialize core 2023-09-07T12:31:05.671602+02:00 helios64 kernel: [ 2.537107] dwc3: probe of fe900000.usb failed with error -110 No USB device could be accessed. As this seems to be related to the realtek driver r8152, I compiled and installed the current version of that driver (see below) and after that the USB devices were accessible. # compile and install the current realtek driver git clone https://github.com/wget/realtek-r8152-linux.git cd realtek-r8152-linux... make sudo make install

Hi, This morning, i do cold boot and crash after few minutes (less than 10min...) Boot is okok but lose ssh connection and to same with usb wire console, i have login and password ask but then i am block... (i can't find if problem hardware... systemd... software...) I use reset bottom and after 15min uptime, i try the same and not lose connection, (i don't understand why not lose connection, i do nothing and Helios64 seem Okok...) i do: (3 times) root@helios64:/tmp# ./cpufreq-switching allocated 64MB test: toggle freq before write 99/100 test: toggle freq before read 9/10, 99/100 root@helios64:/tmp# ./cpufreq-switching allocated 64MB test: toggle freq before write 99/100 test: toggle freq before read 9/10, 99/100 root@helios64:/tmp# ./cpufreq-switching allocated 64MB test: toggle freq before write 99/100 test: toggle freq before read 9/10, 99/100 root@helios64:/tmp# Not crash/freeze and during this test, i have samba Time Machine backup work and lot of I/O Network and 1GO of data pass from my mac to helios. I don't tune voltage, juste use 6.6.28 Kernel and my standard configuaration.... I run again you program and, i have again Time Machine Backup (samba share in background): | | | | ___| (_) ___ ___ / /_ | || | | |_| |/ _ \ | |/ _ \/ __| '_ \| || |_ | _ | __/ | | (_) \__ \ (_) |__ _| |_| |_|\___|_|_|\___/|___/\___/ |_| Welcome to Armbian-unofficial 24.5.0-trunk Bookworm with Linux 6.6.28-current-rockchip64 No end-user support: built from trunk System load: 86% Up time: 27 min Local users: 2 Memory usage: 11% of 3.77G IP: 10.0.0.155 CPU temp: 41°C Usage of /: 47% of 14G RX today: 1.5 GiB [ General system configuration (beta): armbian-config ] Web console: https://helios64:9090/ You have no mail. helios64@helios64:~$ su - Mot de passe : root@helios64:~# cd /tmp/ root@helios64:/tmp# uptime ; ./cpufreq-switching ; uptime 06:34:39 up 28 min, 3 users, load average: 5.87, 4.75, 3.61 allocated 64MB test: toggle freq before write 99/100 test: toggle freq before read 9/10, 99/100 06:36:12 up 29 min, 3 users, load average: 4.99, 4.71, 3.70 root@helios64:/tmp# No Problem, To conclude for moment, to my side; 6.6.28 stable but not at cold boot... stable after. Something (hardware or software) when cold boot crash or do bug in linux software... and after reset buttom is Okok... It's crazy i know ! If you want next week, i build a Vanilla armbian from source with official framework and run your cpufreq-switching on it, i think i will have same this day with my standard configuration but maybe not with crash at cold boot If you read my history message about Helios64 since about 3 years... it never stable with standard parameter. I do many tests and to change Kernel and this day the Best Kernel i never use is 6.6.27 and upper because not crash at standard frequency Schedutil Governor The very bad Kernel was 6.X branch, with thing kernel, Helios crash often just when i unlock my raid10 with LUKS cryptosetup And le 5.15.(something)69 or just before was the best stable Kernel with 400-1400Mhz schelutil (i speak about this in very old post) I try again you program, Time Machine Backup is finish... root@helios64:/tmp# uptime ; ./cpufreq-switching ; uptime 06:51:25 up 44 min, 3 users, load average: 3.98, 4.58, 4.24 allocated 64MB test: toggle freq before write 99/100 test: toggle freq before read 9/10, 99/100 06:53:01 up 46 min, 3 users, load average: 3.03, 4.09, 4.10 root@helios64:/tmp# Not crash, now i go to work office and then pass a weekend with my familly, keep in touch next week Have a good day

@usual user I think this is what happens, within the microprocessor soc, there is sram likely small 10s-100s of K bytes is likely, so the on board rom loads u-boot as a SPL (secondary program loader) also into s-ram. Then that u-boot needs to *clock the dram* (i.e. setup the dram so that it is actually working), determine dram size, configure dram to be up and running e.g. the 'rows and columns', setup memory mapping. All these in *sram* it did not even touch dram. Then that once everything is up, u-boot loads the *linux kernel* into dram, pass over the DTS and pass over the dram memory size and jumps into the kernel code, then linux boots up from there on. The trouble is that u-boot did not detect the DRAM and the codes is directly from the stem (mainline) https://source.denx.de/u-boot/u-boot I added a lot of debug() statements to trace execution flow and it seemed apparently that it did not even go into the dram initialization parts of the code. So I actually need help with the u-boot codes. I can't figure out why it is not working. All that BL31 etc is mainly for power management (e.g. shutdown / suspend etc), didn't seem to deal with DRAM https://github.com/ARM-software/arm-trusted-firmware/tree/master/plat/allwinner/sun50i_h616

Hi. I testing out different images for my DIY NAS project. My plan is to use the Orangepi3b board with armbian bookworm and OMV. I have built images from armbian github, (main,trunk) the edge 6.7.10 kernel is working great. But I do get some Iperf3 retries when sending from Opi3b. From Opi3b 60-70MB/s To Opi3b 110MB/s. With Orangepi own bookworm image I have 110/110 and no retries. The same with Joshua Riek's Ubuntu server image, no retries and 110/110. Orangepi3b armbian with 6.7.10 kernel orangepi@orangepi3b:~$ iperf3 -c 192.168.10.197 -f M Connecting to host 192.168.10.197, port 5201 [ 5] local 192.168.10.155 port 56514 connected to 192.168.10.197 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 74.5 MBytes 74.5 MBytes/sec 217 19.8 KBytes [ 5] 1.00-2.00 sec 75.9 MBytes 75.9 MBytes/sec 218 11.3 KBytes [ 5] 2.00-3.00 sec 79.1 MBytes 79.1 MBytes/sec 200 25.5 KBytes [ 5] 3.00-4.00 sec 73.3 MBytes 73.3 MBytes/sec 225 29.7 KBytes [ 5] 4.00-5.00 sec 79.1 MBytes 79.1 MBytes/sec 210 33.9 KBytes [ 5] 5.00-6.00 sec 77.8 MBytes 77.8 MBytes/sec 211 86.3 KBytes [ 5] 6.00-7.00 sec 77.4 MBytes 77.4 MBytes/sec 202 36.8 KBytes [ 5] 7.00-8.00 sec 76.1 MBytes 76.1 MBytes/sec 207 73.5 KBytes [ 5] 8.00-9.00 sec 75.0 MBytes 75.0 MBytes/sec 222 12.7 KBytes [ 5] 9.00-10.00 sec 73.3 MBytes 73.3 MBytes/sec 239 11.3 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 761 MBytes 76.1 MBytes/sec 2151 sender [ 5] 0.00-10.04 sec 760 MBytes 75.7 MBytes/sec receiver Orangepi3b Ubuntu with 6.1 kernel ubuntu@ubuntu:~$ iperf3 -R -c 192.168.10.197 -f M Connecting to host 192.168.10.197, port 5201 Reverse mode, remote host 192.168.10.197 is sending [ 5] local 192.168.10.154 port 42888 connected to 192.168.10.197 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 112 MBytes 112 MBytes/sec [ 5] 1.00-2.00 sec 112 MBytes 112 MBytes/sec [ 5] 2.00-3.00 sec 112 MBytes 112 MBytes/sec [ 5] 3.00-4.00 sec 112 MBytes 112 MBytes/sec [ 5] 4.00-5.00 sec 112 MBytes 112 MBytes/sec [ 5] 5.00-6.00 sec 112 MBytes 112 MBytes/sec [ 5] 6.00-7.00 sec 112 MBytes 112 MBytes/sec [ 5] 7.00-8.00 sec 112 MBytes 112 MBytes/sec [ 5] 8.00-9.00 sec 112 MBytes 112 MBytes/sec [ 5] 9.00-10.00 sec 112 MBytes 112 MBytes/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.04 sec 1.10 GBytes 112 MBytes/sec 1 sender [ 5] 0.00-10.00 sec 1.10 GBytes 112 MBytes/sec receiver So to see if the vendor kernel was different I built with the new 6.1.43-vendor-rk35xx kernel, but It will not boot. build command: ./compile.sh build BOARD=orangepi3b BRANCH=edge BUILD_DESKTOP=no BUILD_MINIMAL=yes KERNEL_CONFIGURE=no RELEASE=bookworm J=4 It seems to be something with power to the NPU. ? "rockchip-pm-domain fdd90000.power-management:power-controller: failed to get ack on domain 'npu', target_idle = 0, target_ack = 0, val=0x6" uart log attachment kernelpanic.log

Yes, mine is 10/100M. I'm using it to watch content on a 1080p TV and works pretty fine. If useful to you, it has an USB 3.0 port, to use an external HDD or probabbly a gygabit LAN to USB dongle...

I tried to dump the full firmware to have a backup but I couldn't do this because its read protection. Apparently I could only extract uboot.img and many other files. There is a workoround by unpacking that file, editing 4 bytes with any HEX editor, repacking and flashing, that allows to fully dump the firmware after tweaking it. I'm not sure of any risk of bricking the device If anything goes wrong. By the momment I cannot unppack the uboot.img file to do the trick. Also I'm looking for some more information about how to use the UART interface with it. I have a UART USB dongle (CP2102 chip) that I believe I can use to connect it. Any information would be appreciated.

Hello everyone, I seem to have a problem with not knowing how to change the top usb3 port of my Rock pi 4+ to host mode from otg mode, I just got it and installed armbian on it and open media vault, only to notice that I couldn't connect anything to the top usb 3 port and have it show up in open media vault, the other ports work fine and looking at the internet seems to have found that the answer is that the port is in OTG mode and on the official website they do have a way to change it to host mode, but not in armbian and I'm not skilled enough in linux to find where the file I need to change is. I'm running this build "Armbian_v22.05.2_Rockpi-4cplus_bullseye_current_6.1.33.img.xz" downloaded from the armbian website. Thanks in advance for the help :)

windows WSL2 Delete just the h96 max DTS and DTB from patch\kernel\archive\rockchip64-6.6 Drop the new https://github.com/hqnicolas/ArmBoardBringUp and compile again. sudo gpioinfo I'm also using this method to figure out how to enable 1.8v on Pin12 to AP6335 32*4 + 8*3 + 5 = GPIO4 RK_PD5 8*0 = A 8*1 = B 8*2 = C 8*3 = D Also Trying to disable the kernel 6.2 GPIO I can confirm: the enable pin is RK_PB1 from GPIO2 it will enable wifi by 1.8v on Pin12 to AP6335 I have FIxed the problem with this pin in kernel 6.6 the problem is here: GPIO_ACTIVE_LOW sdio_pwrseq: sdio-pwrseq { status = "okay"; compatible = "mmc-pwrseq-simple"; clocks = <&rk809 1>; clock-names = "ext_clock"; pinctrl-names = "default"; pinctrl-0 = <&wifi_enable_h>; reset-gpios = <&gpio2 RK_PB1 GPIO_ACTIVE_HIGH>; post-power-on-delay-ms = <100>; };

Thanks for the pointer, much appreciated. I scrolled through the list (System > Hardware) and there is an overlay module "rockpi4cplus-usb-host". At least the name suggest it is for this board. If I toggle this option and reboot, assume it will switch the port from OTG To host mode.

....Grrrr I reboot... and now i lose network connection random time (approximately 6-10min) after full boot... and i lose access by USB wire to console... return in unstable world... I become CRAZY ! Back to 400-1200Mhz max schedutil, if lose connection... back to 1200 1200 Performance (equal to fix freq 1200)

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?

@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.

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.

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!

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 purchased this fake clone TV box of the classic Tanix TX3 Mini 2GB Ram 16GB Rom for around 20 dollars (including shipping). I discovered that the soc is S905L2-B and before bricking the card with attempts to install it on eMMC I wanted to know if anyone of you found a firmware for this TV box compatible with the Amlogic USB Burning tool. On the internet I only found two tx boxes that mount the S905L2 soc and they are the X7 5G and ipbs9505 and I couldn't find firmware to try to load them on my tv box, it's difficult on the Chinese forums for me to be able to find the downloads. Any advice is welcome because with boot from the SD and the armbian-ddbr command I get an image but which I can only restore with the same command after booting from the SD so if the TV box is bricked and I can't boot this path won't work. I can use it to restore the Android factory image

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

Since I am interested in the connection ability, I figured the info we gather should go into ONE thread. I have tried to build new kernels, but can only see USB controllers and devices two ports. I have seen a lot of work by Sebasitian Reichel @ Collabora, and his patches, but these do not seem to have the desired result on my test board. Orange PI 5. There seems to be an issue with the port mux, FUSB302, that either connects the last USB to the "vertical" port or to the "USB C" connector. I will comment my findings and attempts to correct this in this thread, and think we could find out where we are if you add your findings, successes and failures, rather than cluttering everywhere Regards, Gullik

@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.

Hi everyone, I'm new in this forum. I'm trying to boot armbian on a Mecool KM1 tv box. It's an armlogic S905X3 with 4GB ram,, 32Gb storage. Cant find a viable uboot and dtb combination for it as the usb flashdrive or microSD card simply won't boot. I can, however, run coreelec with no issues. Does anybody had any success with this box? Thanks

Hi! I just bought two Orange Pi Zero 3 with 1.5 GB RAM, and I think they have same memory size detection mentioned earlier in this thread. I am looking for a quick solution, as I do not have much time to return them if it is not possible to fix them. I installed Debian Bookworm for 1.5 GB board with kernel version 6 and without GUI. Apparently it was working well, but sometimes rebooting via SSH just powered off. I did not see anything wrong in dmesg and syslog, but after plugging in a console cable I could see that when reboot failed, u-boot detected 3 GB of memory. Even more, next power cycle boots board with 3 GB memory detected. I did not have time to stress boad, but this issue will probably make board unstable appart not being able to reboot all the times. I attached console output with some comment for details. Any help would be welcome. I you want, I can provide more information or make more tests, in order to look for a solution. Thanks in advance for your help. commented-boot-20240417.out

Hello im new and im Italian so i hope you will not hate me if i write not perfectly (Who said Google Translate?? No No No) This Guide is for a "client to client" setup of the box, we will internally switch Wifi to Eth, so a working computer can access internet from its eth port even if the router signal source is wireless. Router AP -----> ARM BOX [WIFI internal or usb dongle] ===>> internal eth0 ------> ethernet cable --> client eth port Make sure WiFi in arm box is connected using nmtui command FROM NOW ON <WIFI CARD> is the wifi adapter name es: replace "<WIFI CARD>" with "wlx0013eff301ee" Execute: sudo apt-get update && sudo apt-get install dnsmasq iptables iptables-persistent -y say no to save actual iptables rules (we dont have any yet) Edit /etc/network/interfaces comment if exist the part of eth0 "iface eth0" to "#iface eth0" add those lines allow-hotplug eth0 iface eth0 inet static address 172.24.1.1 netmask 255.255.255.0 network 172.24.1.0 broadcast 172.24.1.255 dns-nameservers 1.1.1.1 1.0.0.1 #########{Static}########### up ip addr add 172.24.0.1/24 dev eth0 execute those commands REMEMBER TO REPLACE <WIFI CARD> ip addr add 172.24.0.1/24 dev eth0 iptables -A FORWARD -o <WIFI CARD> -i eth0 -s 172.24.0.0/24 -m conntrack --ctstate NEW -j ACCEPT iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT iptables -t nat -F POSTROUTING iptables -t nat -A POSTROUTING -o <WIFI CARD> -j MASQUERADE sh -c "iptables-save > /etc/iptables.ipv4.nat" sh -c "echo 1 > /proc/sys/net/ipv4/ip_forward" /etc/init.d/dnsmasq stop cp /etc/dnsmasq.conf /etc/dnsmasq.conf-backup Edit /etc/dnsmasq.conf inserting interface=eth0 listen-address=172.24.1.1 bind-interfaces server=1.1.1.1 domain-needed bogus-priv dhcp-range=172.24.0.100,172.24.0.250,72h Edit /etc/sysctl.conf inserting net.ipv4.conf.default.forwarding=1 net.ipv4.conf.all.forwarding=1 Edit /etc/rc.local inserting before "exit 0" iptables-restore < /etc/iptables.ipv4.nat execute those commands systemctl enable dnsmasq systemctl enable iptables Explainations: We set static net to eht0 then we set routing in iptables [forward and back] wlan<->eth then we make this setup persistent so that will persist after reboot. Working on my RK3318 Armbian bullseye 5.15 minimal and USB3 dongle RTL8814AU (also tested with a 8812au)

Since the specific USB hardware support is now in place, I thought it would be good to discuss pitfalls and remedies for transitioning to a modern kernel. I have now tested the 6.8.5 based Armbian. None of the latest packages (.408 - .411) come up with HDMI output. You have to have a serial console connected, and then correct the problems. 1) This is what you are greeted with: [ 6.828040] panthor fb000000.gpu: [drm] *ERROR* Failed to load firmware image 'mali_csffw.bin' To fix this do apt install armbian-firmware-full and reboot 2) The 8821cu driver has performance problems. Also, the stupid "windows" adapter comes up as a CDROM, and has to be cycled by removing and inserting with its driver loaded, for the wifi to be recognized. These seem minor fixes, firmware repackaging etc... Hopefully we can document results from testing and workarounds in this thread. A big hurray, for Armbian bringing mainstream to OPI 5..... Gullik

@Hqnicolas Nice Job! Sorry I was away for the weekend and I already see that I need to reflash the board. Well I needed to start again with the version 1.2 - I started with Bluetooth and made it work - Although still not sure what is physically written on the chip and how it behaves. I have hcy6335, which in turn should be AP6335 containing the BCM4335 and for Bluetooth BCM4339. Somehow the chip gets represented as hci0: BCM4335A0 (002.001.006) build 0000. I am attaching the hcd file to this post that needs to be copied to the /lib/firmware/brcm. I also changed the dtb for the uart1 as there is no UART1 DMA mode possible otherwise. One just needs to add the dma-names to serial@fe650000 node: serial@fe650000 { compatible = "rockchip,rk3568-uart\0snps,dw-apb-uart"; reg = <0x00 0xfe650000 0x00 0x100>; interrupts = <0x00 0x75 0x04>; clocks = <0x0e 0x11f 0x0e 0x11c>; clock-names = "baudclk\0apb_pclk"; dmas = <0x24 0x02 0x24 0x03>; dma-names = "tx\0rx"; pinctrl-0 = <0x91 0x92 0x93>; pinctrl-names = "default"; reg-io-width = <0x04>; reg-shift = <0x02>; status = "okay"; phandle = <0x10a>; bluetooth { compatible = "brcm,bcm43438-bt"; clocks = <0x94 0x01>; clock-names = "lpo"; device-wakeup-gpios = <0x95 0x11 0x00>; host-wakeup-gpios = <0x95 0x10 0x00>; shutdown-gpios = <0x95 0x0f 0x00>; max-speed = <0x16e360>; pinctrl-names = "default"; pinctrl-0 = <0x96 0x97 0x98>; vbat-supply = <0x23>; vddio-supply = <0x63>; }; }; These are now the dmesg logs that I am getting [ 16.268929] Bluetooth: hci0: BCM: chip id 82 [ 16.269548] Bluetooth: hci0: BCM: features 0x2f [ 16.272162] Bluetooth: hci0: BCM4335A0 [ 16.272173] Bluetooth: hci0: BCM4335A0 (002.001.006) build 0000 [ 16.274413] Bluetooth: hci0: BCM4335A0 'brcm/BCM4335A0.hcd' Patch [ 17.114840] systemd[1]: Finished Armbian memory supported logging. [ 17.152605] systemd[1]: Starting Journal Service... [ 17.299179] systemd[1]: Started Journal Service. [ 17.339995] systemd-journald[632]: Received client request to flush runtime journal. [ 17.369055] Bluetooth: hci0: BCM: features 0x2f [ 17.372008] Bluetooth: hci0: BCM4335B0 JF-LTE MurataXJ AFH_LimitPwr_EDR 2STOPBIT-0343 [ 17.372025] Bluetooth: hci0: BCM4335A0 (002.001.006) build 0353 [ 17.482709] RPC: Registered named UNIX socket transport module. [ 17.482729] RPC: Registered udp transport module. [ 17.482733] RPC: Registered tcp transport module. [ 17.482736] RPC: Registered tcp-with-tls transport module. [ 17.482740] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 18.604874] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 18.604896] Bluetooth: BNEP filters: protocol multicast [ 18.604914] Bluetooth: BNEP socket layer initialized [ 18.647499] Bluetooth: MGMT ver 1.22 ... [ 23.677339] Bluetooth: RFCOMM TTY layer initialized [ 23.677399] Bluetooth: RFCOMM socket layer initialized [ 23.677430] Bluetooth: RFCOMM ver 1.11 h96-tvbox-3566-wifi:~:% hciconfig -a hci0: Type: Primary Bus: UART BD Address: 43:35:B0:07:1F:AC ACL MTU: 1021:8 SCO MTU: 64:1 UP RUNNING RX bytes:4846 acl:0 sco:0 events:556 errors:0 TX bytes:71684 acl:0 sco:0 commands:556 errors:0 Features: 0xbf 0xfe 0xcf 0xff 0xdf 0xff 0x7b 0x87 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: RSWITCH SNIFF Link mode: PERIPHERAL ACCEPT Name: 'h96-tvbox-3566-wifi' Class: 0x6c0000 Service Classes: Rendering, Capturing, Audio, Telephony Device Class: Miscellaneous, HCI Version: 4.0 (0x6) Revision: 0x161 LMP Version: 4.0 (0x6) Subversion: 0x4106 Manufacturer: Broadcom Corporation (15) h96-tvbox-3566-wifi:~:% bluetoothctl Agent registered [CHG] Controller 43:35:B0:07:1F:AC Pairable: yes [bluetooth]# show Controller 43:35:B0:07:1F:AC (public) Name: h96-tvbox-3566-wifi Alias: h96-tvbox-3566-wifi Class: 0x006c0000 Powered: yes Discoverable: no DiscoverableTimeout: 0x000000b4 Pairable: yes UUID: A/V Remote Control (0000110e-0000-1000-8000-00805f9b34fb) UUID: Handsfree Audio Gateway (0000111f-0000-1000-8000-00805f9b34fb) UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb) UUID: Audio Sink (0000110b-0000-1000-8000-00805f9b34fb) UUID: Headset (00001108-0000-1000-8000-00805f9b34fb) UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb) UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb) UUID: Audio Source (0000110a-0000-1000-8000-00805f9b34fb) UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb) UUID: Device Information (0000180a-0000-1000-8000-00805f9b34fb) Modalias: usb:v1D6Bp0246d0540 Discovering: no Roles: central Roles: peripheral Advertising Features: ActiveInstances: 0x00 (0) SupportedInstances: 0x05 (5) SupportedIncludes: tx-power SupportedIncludes: appearance SupportedIncludes: local-name [bluetooth]# scan on Discovery started [CHG] Controller 43:35:B0:07:1F:AC Discovering: yes [NEW] Device 4C:BA:D7:02:F5:B7 4C-BA-D7-02-F5-B7 @ning @Hqnicolas UART1 speed is set to max-speed = <1500000>; but according to the datasheet (still no clue if it is the right one) we can go up to 4 MBit/s. Another thing is the schematics that I found somewhere on the internet, but still they are using some AP6xxx wifi/BT chip. Need to dive into this, but hey, now we see the missing components needed for SD-Card slot. Heartbeat is a nice thing, but I will try to enable the backlight blue LEDs, WiFi runniung, and then try to get some HDMI audio out of this thing. BCM4335A0.hcd p562297-AP6335 datasheet_V1.3_02102014.pdf ROC-3566-PC-V10-20210419.pdf