All Activity

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

Did you reboot after installing headers? I tried on beta software https://paste.armbian.com/ayilamofor and kernel 6.8.7 ... it works https://paste.armbian.com/aqumeheguf.yaml

additional info: in armbian-config I see, that the kernel is frozen (I can't remembere to have that configured) When I select "Defreeze", the dialog just returns and still offers "Defreeze". On a odroidc2 I have similar issue with headers not regognized: In armbian-config of the odroidc2 device the kernel was not frozen so I could update to the latest (6.7.4-edge-meson64) installed headers: linux-headers-current-meson64/jammy,now 24.2.1 arm64 [installed] but `apt-get --reinstall install zfs-dkms` also returns Loading new zfs-2.2.3 DKMS files... Building for 6.7.4-edge-meson64 Module build for kernel 6.7.4-edge-meson64 was skipped since the kernel headers for this kernel does not seem to be installed.

Im running Armbian 24.2.1 jammy on odroidm1 with additional zfs volumes. On update, sometimes I had to reinstall the zfs kernel module, but now I have the problem, that the system does not recognize the kernel headers: sudo apt-get --reinstall install zfs-dkms Reading package lists... Done Building dependency tree... Done Reading state information... Done 0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded. Need to get 2,397 kB of archives. After this operation, 0 B of additional disk space will be used. Get:1 http://mirrors.dotsrc.org/armbian-apt jammy/jammy-utils arm64 zfs-dkms all 2.2.3-1 [2,397 kB] Fetched 2,397 kB in 1s (3,567 kB/s) Preconfiguring packages ... (Reading database ... 72929 files and directories currently installed.) Preparing to unpack .../zfs-dkms_2.2.3-1_all.deb ... Deleting module zfs-2.2.3 completely from the DKMS tree. Unpacking zfs-dkms (2.2.3-1) over (2.2.3-1) ... Setting up zfs-dkms (2.2.3-1) ... Loading new zfs-2.2.3 DKMS files... Building for 6.1.12-rk3568-odroid Module build for kernel 6.1.12-rk3568-odroid was skipped since the kernel headers for this kernel does not seem to be installed. Processing triggers for initramfs-tools (0.140ubuntu13.4) ... update-initramfs: Generating /boot/initrd.img-6.1.12-rk3568-odroid W: Possible missing firmware /lib/firmware/nvidia/tegra194/xusb.bin for built-in driver xhci_tegra W: Possible missing firmware /lib/firmware/nvidia/tegra186/xusb.bin for built-in driver xhci_tegra W: Possible missing firmware /lib/firmware/nvidia/tegra210/xusb.bin for built-in driver xhci_tegra W: Possible missing firmware /lib/firmware/nvidia/tegra124/xusb.bin for built-in driver xhci_tegra update-initramfs: Armbian: Converting to u-boot format: /boot/uInitrd-6.1.12-rk3568-odroid Image Name: uInitrd Created: Thu Apr 25 11:27:48 2024 Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 27753116 Bytes = 27102.65 KiB = 26.47 MiB Load Address: 00000000 Entry Point: 00000000 update-initramfs: Armbian: Symlinking /boot/uInitrd-6.1.12-rk3568-odroid to /boot/uInitrd '/boot/uInitrd' -> 'uInitrd-6.1.12-rk3568-odroid' update-initramfs: Armbian: done. I already removed and reinstalled the headers via armbian-config > Headers_remove, Headers_install but without change. apt-get list --installed |grep header linux-headers-edge-rockchip64/jammy,now 24.2.1 arm64 [installed] do I need to create some magic symlinks or parameters for apt-get to get the headers resolved since the kernel version is missing in the package?

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

@SteeMan Thank you for your quick answer! I missed that line I'm sorry. I assume Corelec and Emuelec will cause same problem with boot. Not sure how to reinstall firmware , I've only run automatic updates. Any advise to get and install original firmware?

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

You do not supply enough information about your issue. First off what SBC are you working with. Armbian builds are specific to each device. Second what build are you attempting to use?

Moved to what I think is the correct forum.

What build and instructions are you using? https://forum.armbian.com/topic/33676-installation-instructions-for-tv-boxes-with-amlogic-cpus If you are using the above instructions, note the first sentence about having ever run another distro on the box. If so a reinstall of the original android firmware is required to reset the box to a unmodified state (I point this out as you say you have run emuelec on the box - and yes running from sd card counts as running on the box).

Hello team Hoping I can get some advice here We have a custom device running rockchip3588 It boot up into android 12 This device has no SD card option We installed RKdevtool on a laptop connected to the back of the device via usb C installed Ubuntu 20.04 desktop using firefly by partitioning the free space We simply dragged and dropped the image over to the space using firefly However it failed with no free space to even run a standard update We are trying to wipe it out and install Ambian directly onto it removing android We should then have enough space not having to boot up with android Does anyone have any idea on hw to accomplish this

Hi Guys, I was trying to install Armbian in a couple of boxes buit I had no luck. One is a SEI500W from SEI Robotics with AML 905X2 and the other is a Sagecom DIW 585 with AML 905X I followed the process and after trying to boot to recovery they start Andoid tv as normal (just takes more time). In the other hand I was able to run EMUELEC (Gaming emulator) on both devices with an image on SD so I'm assuming the problem is not a block. What do you think? Is there any ideas to try? Thank you in advance!

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

Hi Long Vu, you should install a UART Serial port so we can find out where it hangs.

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

Why are you expecting these services to be pre configured for you out of the box? Any file sharing service is a potential security hole, so any good distribution isn't going to have them enabled by default.

@lucky62 Change your line 736 to pin->pin = of_get_named_gpio(pdev->dev.of_node, name, 0);

even for sftp its not working..

Google how to install/setup samba for file sharing on Linux.

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.