Active threads

We can use RKdevtool. But It sounds like what you are saying is we need to email the manufacture for this information Is that correct ?

@Hqnicolas I created a pull request for a working HDMI sound: https://github.com/hqnicolas/ArmBoardBringUp/pull/1/files

Hi Long Vu . I use Vontar H618 2GB ram. it's running well with armbian 6.7.10 . only need to fix wifi driver

Thanks @Igor for your help, yes, I did, but now found out, that installed headers are: /usr/src/linux-headers-6.6.16-current-rockchip64 while kernel still was Linux odroidm1 6.1.12-rk3568-odroid #23.02.2 SMP PREEMPT Sat Feb 18 00:05:38 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux I got my Frozen kernel in armbian-config somehow solved by updating firmware and rebooting several times. Now kernel and headers are in sync again and zfs-module gets loaded! I will need to reanimate my odroidc2, which I use as a standby for the odroidm1, since that device doesn't boot any more after reinstall latest kernel, but that's another story ... Thanks!

Restore from CoreELEC: https://wiki.coreelec.org/coreelec:restore

@snakekick Thanks, that seems to confirm my findings back a few months ago. Adding a 5ms delay in the test case did not prevent the crash. Though it could be the system load is at play. Maybe adding a delay at the kernel level would do. pcie is tagged on the big CPUs so the SATA disks seem to matter (as the ethernet port). One could try in emergency mode (passing emergency to the kernel (I do it by "setenv extraboardargs emergency" after halting u-boot with a key press then enter "boot"). You will have just the root partition mounted read-only (so no network connection, a serial console is required). Then run the test. Also note that the design of the GPU regulator has the same issue as the CPU b one ... (for my tests I blacklisted panfrost, ie the GPU driver). After looking at the rockchip64 board schematics the design around the CPU b regulator is not similar but exactly the same as the helios64 one (rockchip64 uses a tcs4545 regulator for cpu b and tcs4546 for GPU). I wonder if the easiest fix would not be to pay someone to desolder the syr837 regulator and solder a tcs4545 instead - same for the GPU regulator a tcs4546 instead of the syr838... except that these chips from Torch Chip seem nowhere to be found. Maybe rip them from a rockpro64 board. @aprayoga can you confirm the Helios64 design for the rk3399 big cpu and gpu regulators are the same as the RockPro64 ones? Would it make sense (and would it fix the unstable cpu_b) to desolder the syr837/syr838 to replace them with tcs4545/tcs4546? Ie the tcs4535 datasheet (I am still unable to find the tcs4545 datasheet) I found tells tcs425 has internal pulldown for VSEL and EN which syr837 does not, the syr837 datasheet requires a 22uF capacitor for VIN but the helios64 has a 10uF one like the rockpro64 for the tcs4545. The SW pin of the helios64 has 470uH inductor with 4 x 22uF capacitors like the rockpro64 for the tcs4545 (like the typical application in the tcs4535 datasheet with 470uH inductor with two 22uF capacitors)? Do you know a replacement for the TCS4545/TCS4546 that has closer specs than the syr837/syr838? I cannot seem to find TCS4545/TCS4546 for sale (maybe I could buy a rockproc64 to desolder them at least for a test... or could you check on your side with a helios64 board that the cpufreq-switching-2-b test above crash with syr837 but not with tcs4545 with vanilla rk3399 opp definitions in dts? Sorry if the burnout is not over, please let me know. I lack the skills but I can harass other folks 😕 Hope you are well. Sadly the Helios64 filled a market that is left unfilled. People who do not have the know-how to go full low-wattage DIY NAS and who also cannot afford to pay 1K€ for a NAS (and who might need two NASs to make things worse). In the meantime, I spend a lot of time learning about DIY NAS, but it is still hard to get wattage at full load (they tend to give all idle power usage). I probably will end up gambling and buying one build and pray... but with Helios64 I had the metrics before buying. I found that the Rock960 has the same design for the cpu_b and gpu regulators except for the inductor which is 0.240uH on the rock960 and 0.470uH on the Helios64. But hard to tell if the Rock960 is stable with my cpufreq switching test for the big cpus of the rk3399, might be the use of the board does not stress it as much as a raid10 on the helios64 pcie sata which is tagged to the cpu_b ... (initially it was 4 3TB WD Red - the old CMR model WD30EFRX-68EUZN0), from Helios4 setup as advertised by Kobol wiki for the Helios4... the board crashes on first boot after assembly with this raid setup. Mind I found that the Pinebook Pro also has the same design as the Helios64 this time around the syr837/syr838 ... I begin to wonder if either they are all broken (could be the amount of stress of a NAS ethernet or raid10 pcie is not that common) or if this is not the issue at stake.

Greetings Armbian Community, We’re thrilled to share our latest strides in enhancing partnerships, expanding support, and advancing innovations within the Armbian ecosystem. Here’s a roundup of recent developments: 1. Strengthening Partnerships in Shenzhen: We’ve embarked on a mission to fortify our collaborations with partners in Shenzhen, aimed at fostering better support for our community. During our visit, we engaged with both existing and potential partners to deepen our ties and enhance the services we offer to you. Read more 2. Platinum Support and Giveaway for Bananapi M7: We’re excited to announce the launch of platinum support and a special giveaway for the latest Bananapi M7, a collaborative effort between Bananapi and ARMSOM. This initiative aims to provide unparalleled assistance and rewards to our valued users. Learn more 3. Expansion of Community Build Framework: Our community interaction has led to the integration of several new boards, including SakuraPi and H96 TV box, into our build framework. Additionally, we’ve upgraded u-boot on 32-bit Rockchip devices and successfully ported Khadas Edge 2 to kernel 6.1. Moreover, FriendlyElec NAS now runs on mainline-based kernels, enriching our ecosystem with more versatile options. 4. Ongoing Upgrades and Future Ventures: In the pipeline, we have several exciting upgrades underway. We’re working on upgrading the Odroid XU kernel to version 6.6 and adding support for Orangepi 5 PRO. Furthermore, we’re introducing mainline kernel support for Orangepi Zero 2W, and our team is eagerly diving into the development of the new Radxa Rock 5 ITX board and Rock 5C. Stay tuned for more updates as we continue to elevate the Armbian experience! Best regards, The Armbian Team View the full article

@astrosky @tERBO this may help you getting hardware decoded videos, but don't expect your browser work with them. Mixing hardware video decoding into browsers compositors is not an easy task.

@mamasaur1 It might be that it tries to read the layout of Orange Pi 5 instead of 5b, on the 5-plus I had to enter: echo "BOARD=orangepi5plus" | sudo tee /etc/orangepi-release So probably for yours it should be: echo "BOARD=orangepi5b" | sudo tee /etc/orangepi-release By the way, it's not a good idea to connect a 2-pins fan directly to a gpio pin, too much current. Search for a pwm fan instead that's compatible for a raspberry pi.

You are probably going to need a share name after the IP address smb://10.10.2.101/sharename Running smbclient from the command line will give you more feedback and allow you to search for shares.

Seems this issue has been fixed, I am able to use the new kernel now with video playback. I did not do anything different...just update/upgrade.

This comment describes a recovery method without shorting the pins. I haven't tried this method.

Hello, I need to create images for multiple boards (rpi4b, rpi5b, rock3a, rock5b, orangepi5, orangepi-plus, nanopct6 and khadas-vim4) for a Kubernetes cluster running ceph and cilium, hence I need some new modules and parameters in the kernel. I created a simple playbook that changes the parameters in build/config/kernel/linux-* which works. What does not work is calling compile.sh with the required parameters. The task gives an error and stops after 5 minutes or so. If I run the commands from the prompt, everything is fine...but not convenient. The Ubuntu VM used for the compilation is created on a Fedora 40, with Vagrant, and I gave it 30 cores and 30GB of RAM with plenty of disk to run. vars: board_build: rpi4b: "BOARD=rpi4b BRANCH=edge BUILD_DESKTOP=no BUILD_MINIMAL=yes CLI_TARGET=bullseye KERNEL_CONFIGURE=no RELEASE=bookworm" rpi5b: "BOARD=rpi5b BRANCH=edge BUILD_DESKTOP=yes BUILD_MINIMAL=no \ DESKTOP_APPGROUPS_SELECTED='browsers desktop_tools internet multimedia remote_desktop' DESKTOP_ENVIRONMENT=xfce \ DESKTOP_ENVIRONMENT_CONFIG_NAME=config_base KERNEL_CONFIGURE=no RELEASE=jammy" rock3a: "BOARD=rock-3a BRANCH=edge BUILD_DESKTOP=no BUILD_MINIMAL=yes CLI_TARGET=bullseye KERNEL_CONFIGURE=no RELEASE=bookworm" rock5b: "BOARD=rock-5b BRANCH=edge BUILD_DESKTOP=no BUILD_MINIMAL=yes CLI_TARGET=bullseye KERNEL_CONFIGURE=no RELEASE=bookworm" opi5: "BOARD=orangepi5 BRANCH=edge BUILD_DESKTOP=no BUILD_MINIMAL=yes CLI_TARGET=bullseye KERNEL_CONFIGURE=no RELEASE=bookworm" opi5p: "BOARD=orangepi5-plus BRANCH=edge BUILD_DESKTOP=no BUILD_MINIMAL=yes CLI_TARGET=bullseye KERNEL_CONFIGURE=no RELEASE=bookworm" nanopct6_edge: "BOARD=nanopct6 BRANCH=edge BUILD_DESKTOP=no BUILD_MINIMAL=yes CLI_TARGET=bullseye KERNEL_CONFIGURE=no RELEASE=bookworm" nanopct6_legacy: "BOARD=nanopct6 BRANCH=legacy BUILD_DESKTOP=no BUILD_MINIMAL=yes CLI_TARGET=bullseye KERNEL_CONFIGURE=no RELEASE=bookworm" vim4: "BOARD=khadas-vim4 BRANCH=legacy BUILD_DESKTOP=no BUILD_MINIMAL=yes CLI_TARGET=bullseye KERNEL_CONFIGURE=no RELEASE=bookworm" [...] - name: Compile images ignore_errors: true ansible.builtin.shell: | ./compile.sh {{ board_build[item] }} args: executable: /bin/bash chdir: build register: compile_output changed_when: true loop: "{{ board_build.keys() }}" loop_control: label: "{{ item }}" Thank you, Stefanita Vilcu

Bookworm is latest stable. You can only upgrade to unstable ... which is not recommended for production. You could upgrade kernels, but we don't provide them anymore for bullseye. That is correct. This is the list of packages per distribution: https://fi.mirror.armbian.de/apt/content.html Bullseye only has some files, probably by mistake. It should be just empty as its not supported anymore. Change tags in armbian.list from bullseye to bookworm and update. Should be fine .... at least as far as from Armbian perspective. We can't vouch for packages that are coming from Debian repository as they might come into some conflicts between each other. This is the problem we observe on older releases and have no capacity nor wish to address.

@Ikesankom I did a quick test jiggling with bootloader to try and test multiple cases with both sdcard and emmc. I found a little "bug": there is no "alias" for the mmc devices in the device tree, so sometimes at boot the emmc is mmcblk0 and sdcard il mmcblk2, sometimes they get swapped. Anyway, despite this bug, the installer never broke the existing bootloader, at most it could miss the right device (I should check the logic behind, as it is not so easy guess what is the booting device) if you have both emmc and sdcard plugged. It's not a big deal though: the bootloader has got no real updates in a while since it works fine and the important thing is that the script does not destroy anymore the existing bootloader 😁 Anyway, if the board is remotely installed and controls something important, and you want extra-safety, you can do apt-mark hold linux-u-boot-tinkerboard-current and prevent bootloader upgrades

Thank you so much Micsa! This config really "just" worked for me. Now Banana Pi detects either my DS3231 or DS1307 clock.

Directly no as it doesn't have any software that would allow this. This way (via SD or eMMC): https://docs.armbian.com/User-Guide_Getting-Started/#how-to-install-to-emmc-sata-nvme-usb

@royk thanks for the build, still i didn't test it but i performed some new tests, using the dist from Joshua Riek as Ubuntu is ready, with GPU, and the Kernel is already patched And same problem with Nexus, but i was able to build Omega and is working fine if in System -> Video i select my TV on not the default option (dunno why), after that i can change the resolution to 1080p and everything is working fine, HDR10, x265, x264, 4k.. all good although when i start a video the change of resolution is a bit slow and in the Kodi logs i can see an issue with the EDID: 2024-04-22 10:53:53.119 T:2038 error <general>: [display-info] Error parsing EDID: 2024-04-22 10:53:53.119 T:2038 error <general>: [display-info] ---------------------------------------------- 2024-04-22 10:53:53.119 T:2038 error <general>: [display-info] Block 1, CTA-861 Extension Block: 2024-04-22 10:53:53.119 T:2038 error <general>: [display-info] Colorimetry Data Block: Reserved bits MD0-MD3 must be 0. 2024-04-22 10:53:53.119 T:2038 error <general>: [display-info] 2024-04-22 10:53:53.119 T:2038 error <general>: [display-info] ---------------------------------------------- after these messages in can see in the Kodi log that is able to load all the resolutions profiles Don't know if there is a fix for the EDID After installing Omega it create automatically the GBM profile, using that Kodi works, meanwhile if I'm using yours with the FFMPEG_RKMPP_DEC_OPT="afbc=on" option the video is not showing and Kodi crash cat /usr/local/share/wayland-sessions/kodi-gbm.desktop [Desktop Entry] Name=Kodi on GBM Comment=This session will start Kodi media center Exec=kodi-standalone --windowing=gbm TryExec=kodi-standalone Type=Application Keywords=audio;video;media;center;tv;movies;series;songs;remote; Icon=kodi Also, there was an issue with the python IMP module not found that caused some crashes, and addon probs. finally resolved installing python3-zombie-imp

Hello. Here are in this thread I post Armbian 24.5.0 Bookworm images that should be compatible with Vontar KK MAX. Also added remarks about dualboot for ex. if we want to make untouched Android and at the same time boot only from SD-Card. Also added recommendations for installation on eMMC.

What UART parameters have you set, especially flow control?

I'm facing the same situation with a unstable system after trying to update. Having spent a lot of time into troubleshooting and expecting that community support for this device at least will not get better I am also looking for an alternative. Looking for an alternative board is also not that easy because the size (nano-ITX) is not widely spread. Furthermore one requirement for me would be very common hardware/architecture to not depend on special linux distribution, so getting a good mainline support. These days was the release of a new Odroid x86 board "H4" which comes with 4 Sata-Ports. The board physically seems to fit into the Helios64-case but maybe requires some adaption to different hole-positions. Did anybody else already considered that as an option ?

Debian Buster is end of life. There haven't been any armbian updates for a long time. You can ignore the error as there are no updates to get. You really need to upgrade to a supported Debian release.

Using overlays on the PI whilst on Armbian should be no different than doing so on RaspiOS. https://www.raspberrypi.com/documentation/computers/config_txt.html#overlay_prefix If you don't know how to use them I suggest you use google or check the foundation docs.

I could not get simple SPI device to work even on the Orange Pi Debian image. (So am not sure there is any SPI capable system for it yet). I got normal GPIO operations to work and I2C though but no SPI.