All Activity

Yea my biggest issue here is getting it to run without having to keep android on it . We have successfully created a duel boot but that takes up mem I also know a project that uses raspberry pi boot loader to install onto the rockchip . Your right it seems its a free for all

Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

If the image in question is not at Github its gone. trunk images are not archived over longer period. The amount of storage needed for this task would be just insane.

Thank you for taking the time to respond. Will you have the trunk.286 image to download? I looked for it and couldn't find it... the one I have saved is trunk.287. Thank you so much I tried to download it but it does not exist: https://github.com/armbian/os/releases/download/24.5.0-trunk.286/Armbian_24.5.0-trunk.286_Orangepi5_trixie_edge_6.8.1_minimal.img.xz

The world of open source is all about reverse engineering things where manufacturers don't want to invest in openness. That is why Armbian exists. But it takes a lot of effort. Here are a couple of threads that show how the process works and the time it takes to do what you want without support from the manufacturer: https://forum.armbian.com/topic/24091-efforts-to-develop-firmware-for-h96-max-v56-rk3566-4g32g https://forum.armbian.com/topic/28895-efforts-to-develop-firmware-for-h96-max-v56-rk3566-8g64g

In other words we are beholden to the manufacture...

@SteeMan Yes i did it that way. Inserted the SD with the fix for boot. It booted, then I powered of and removed SD. After that I Inserted the Armbian SD card but then is when the boot loop appears. So there was no way to boot form any SD card anymore. But still works on Android TV when no SD card is present. Please let me know if I'm doing something wrong. Thank you.

Rkdevtool has nothing to do with building working code for your board. You need to think of this as a coding project. You need to build something that is installable and runnable for your board. Nothing that exists is going to work on it. Each board requires a custom code set to boot and run in the arm world today.

@Sig That procedure is a one time this thing. If you pressed the reset button correctly it will have reset the boot loader environment. So remove the SD card and try booting without and SD card (that should be android as normal), then try the Armbian. If it doesn't work, try the reset process again (there is no good way to know if you timed the pressing and holding of the reset button correctly, except through trial and error). ( I generally find holding the reset for about 5 seconds while power is applied is about right, but too long or too short and it won't work as intended)

@cuker thank you for the tip. I've just tried, but after installing the aml_autoscript suggested on that link the box with Armbian on Sd inserted starts a boot loop. It boot normally to Android TV with no SD card inserted. Any other suggestions will be appreciated.

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 ?

If you can't determine what device you have, there is no way you are going to be able to install Armbian on it. The world of linux on ARM is very different than linux on x86. There are no real standards for a boot environment and on board device management. For this reason you need an individual build for each device. One that has a boot environment that can boot the device and also a device specific dtb (device tree) that tells the linux kernel what hardware the board has. Those components need to be developed for each board at often the expense of many man months as the board manufactures have no interest in supporting the process of having mainline linux work on their devices. If you have the skills and resources to invest a very significant amount of time into such an effort, it can be done (if you have schematics and support from the device manufacturer that helps a lot). But the first step would be to open the device to get as the motherboard and understand what components you are working with. Then get a usb-uart connector hooked up and start monitoring the boot process to figure out how the device is booting (off of what media so you know where you are going to need to install a new boot loader to) Since the board is running android (which is only enough like real linux to get in the way generally), what comes installed isn't going to be very helpful in your process.

Hello SteeMAn Sorry but I'm new to the arm chip world 30 plus years in Tandem ,Unix, Linux Multiple platforms So if this sounds crazy i apologize This device is sealed from the manufacture designing for us Its a all in one healthcare device That being said we command line into it while its running android How would I get that info you have asked for? Thanks in advance

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