All Activity

Hi guys, I updated my Orange Pi Lite some time ago and it caused it to stop booting. The boot log is below. Can someone please help me recover this? I'm not sure where to start. I've loaded the SD card into an Ubuntu VM and it reads perfectly fine. U-Boot SPL 2022.07-armbian (Feb 17 2023 - 22:31:53 +0000) DRAM: 512 MiB Trying to boot from MMC1 U-Boot 2022.07-armbian (Feb 17 2023 - 22:31:53 +0000) Allwinner Technology CPU: Allwinner H3 (SUN8I 1680) Model: Xunlong Orange Pi Lite DRAM: 512 MiB Core: 61 devices, 16 uclasses, devicetree: separate WDT: Not starting watchdog@1c20ca0 MMC: mmc@1c0f000: 0, mmc@1c10000: 1 Loading Environment from FAT... Unable to use mmc 0:1... In: serial@1c28000 Out: serial@1c28000 Err: serial@1c28000 Net: No ethernet found. starting USB... Bus usb@1c1b000: USB EHCI 1.00 Bus usb@1c1b400: USB OHCI 1.0 Bus usb@1c1c000: USB EHCI 1.00 Bus usb@1c1c400: USB OHCI 1.0 scanning bus usb@1c1b000 for devices... 1 USB Device(s) found scanning bus usb@1c1b400 for devices... 1 USB Device(s) found scanning bus usb@1c1c000 for devices... 1 USB Device(s) found scanning bus usb@1c1c400 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Autoboot in 1 seconds, press <Space> to stop switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 4077 bytes read in 3 ms (1.3 MiB/s) ## Executing script at 43100000 U-boot loaded from SD Boot script loaded from mmc 153 bytes read in 2 ms (74.2 KiB/s) 16203531 bytes read in 671 ms (23 MiB/s) 10954600 bytes read in 455 ms (23 MiB/s) Found mainline kernel configuration 34541 bytes read in 8 ms (4.1 MiB/s) 4185 bytes read in 5 ms (817.4 KiB/s) Applying kernel provided DT fixup script (sun8i-h3-fixup.scr) ## Executing script at 45000000 Kernel image @ 0x42000000 [ 0x000000 - 0xa72768 ] ## Loading init Ramdisk from Legacy Image at 43400000 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 16203467 Bytes = 15.5 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 43000000 Booting using the fdt blob at 0x43000000 Loading Ramdisk to 4908c000, end 49fffecb ... OK Loading Device Tree to 4901b000, end 4908bfff ... OK Starting kernel ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems done. Begin: Will now check root file system ... fsck from util-linux 2.36.1 [/sbin/fsck.ext4 (1) -- /dev/mmcblk0p1] fsck.ext4 -a -C0 /dev/mmcblk0p1 armbi_root: clean, 60912/1812480 files, 1248402/7711744 blocks done. mount: No such device Failed to mount /dev/mmcblk0p1 as root file system.

So when writing the u-boot to SD card, you need to follow a special process to "skip" over some bytes to prevent trashing the partition table. see https://www.cnx-software.com/2016/11/19/how-to-create-a-bootable-recovery-sd-card-for-amlogic-tv-boxes/ TLDR, something like: sudo umount /dev/sdX* sudo dd if=aml_sdc_burn.UBOOT of=/dev/sdX bs=1 count=442 sudo dd if=aml_sdc_burn.UBOOT of=/dev/sdX seek=1 skip=1 bs=512 sync

Have you tried `/boot/dtb/amlogic/meson-gxm-mini-m8s-pro.dtb` ? What is wifi chip? Is it LTM8830? If so this is QCA9377 clone, and this dtb should be fully working.

Any luck yet? I have a v4.1 board. None of the image is working. Anyone tried these ? https://github.com/velvet-os/imagebuilder/blob/main/systems/allwinner_h616/readme.md

Hi everyone, I’m working on a custom Armbian build for an RK3588-based board (cm3588-nas) and trying to completely disable the Rockchip crypto driver (rk_crypto2), since it's negatively impacting LUKS (AES-XTS) performance. Despite several attempts, the module continues to register algorithms in /proc/crypto after boot: driver : rk2-sm3 module : rk_crypto2 driver : rk2-sha512 module : rk_crypto2 driver : xts-aes-rk2 module : rk_crypto2 ... ------------------------------------------------------------ What I’ve Tried ------------------------------------------------------------ 1. Kernel Config Override - Added CONFIG_CRYPTO_DEV_ROCKCHIP=n and CONFIG_CRYPTO_DEV_ROCKCHIP2=n to: userpatches/linux-rockchip-rk3588-edge.config - Verified .config has it set to n after build. - Used CLEAN_LEVEL="make,debs,oldcache" in the build command. 2. Blacklisting & Deletion in customize-image.sh echo "blacklist rk_crypto" > /etc/modprobe.d/blacklist-rk_crypto.conf rm -f /lib/modules/*/kernel/drivers/crypto/rockchip/rk_crypto.ko* 3. Post-Boot Verification - lsmod | grep rk_crypto → empty - modinfo rk_crypto → module not found - /proc/crypto still shows rk2-* drivers tied to rk_crypto2 4. Manual Source Removal - Commented out this line in drivers/crypto/rockchip/Makefile: # obj-$(CONFIG_CRYPTO_DEV_ROCKCHIP) += rk_crypto.o - Also removed or disabled its Kconfig entry. ------------------------------------------------------------ System Details ------------------------------------------------------------ Board : cm3588-nas (RK3588) Kernel : rockchip-rk3588 edge (Linux 6.8.x) Builder : Official Armbian compile.sh ------------------------------------------------------------ Goal ------------------------------------------------------------ I want to fully disable the Rockchip crypto engine (rk_crypto2): - It should not load, not build, and not register anything in /proc/crypto. - LUKS should fall back to software crypto (cryptd, aesni, or default fallback). ------------------------------------------------------------ Any help is appreciated. I’d love to hear from anyone who’s successfully disabled rk_crypto2 entirely or has ideas for where the registration is coming from even when the module appears removed. Thanks!

We keep (most of) old images here: https://fi.mirror.armbian.de/archive/ https://fi.mirror.armbian.de/oldarchive/

I see, now I get it! So it's everyone's duty to keep around what they think might still be necessary ahead. Did not know of this quirk in the world of Linux. Definitely OT: This explains the running gag among data hoarders when they justify their ample storage space with "Linux ISOs" but really mean socially less accepted things.

Hi @Carlos Hartmann, Backups of anything are a good thing. So my advise would be to always keep the ISOs you downloaded somewhere 'safe'. Not that safe that you will forget where you stashed it of course (looking at you @djurny...). Groetjes,

Hi @Vodalex, Write down the MAC address of the interface you want to use to wake up the Helios4. ip link show You would need to put the Helios4 in suspend, by either: sudo pm-suspend or: echo 'suspend' | sudo tee /sys/power/state To wake it up, from another system, make sure that wakeonlan is installed. Then: wakeonlan ${HARDWARE_ADDRESS} That should be it. Groetjes,

Oh yes, I've been meaning to test an older version but didn't find any anywhere. Can you upload here directly? Maybe slightly OT: Do you know why older versions aren't preserved anywhere? I thought it'd be easy to find buster and bullseye images but didn't manage at all. Seems like it can't be too uncommon that a newer version causes issues and one has to fall back.

Did anyone managed to get Linux working on TX6S?

Next week Collabora will be covering a lot of ground, attending 3 separate events in 3 different time zones: ISC High Performance, Augmented World Expo, and InfoComm! Catch up with us at one of these events. View the full article

Thanks for fixing wol. How can be this tested?

This is what AI tells: Role of BL30 The BL30 component serves as the firmware for the Amlogic Secure Co-Processor (SCP). Its primary responsibilities include managing system-level operations such as Dynamic Voltage and Frequency Scaling (DVFS) and handling suspend/resume functionalities. These tasks are crucial for optimizing power consumption and ensuring efficient thermal management within the system. lists.denx.de In addition to BL30, there is a closely related component called BL301. BL301 acts as a board-specific firmware "plug-in" that provides customized parameters for DVFS and suspend/resume operations, tailored to the specific hardware configuration of the board. lists.denx.de Integration into the Boot Process The typical boot sequence in Amlogic devices follows this order: BL2 → BL30 → BL31 → BL33. Each stage is responsible for initializing specific aspects of the system, with BL30 focusing on power management and system control tasks. If any stage fails, the boot process may attempt to fall back to an alternative boot medium, although this behavior can vary depending on the specific SoC and its configuration. 7Ji’s Blog+1lists.denx.de+1 Understanding the role of BL30 is essential for developers and system integrators working with Amlogic platforms, especially when customizing firmware or troubleshooting boot-related issues. All Amlogic SoCs boards needs this. AFAIK here we don't have open source alternative. Only from the owner of this file after you sign certain papers https://www.amlogic.com/#Company/Contact/index.html This is complex operation and possible where / when there is a big enough interest and when more people join in this common interest and are willing to sacrifice months of their precious private time. https://github.com/crust-firmware/crust Here is an example of similar feature for some other SoC (allwinner). It works, but it's also not feature complete and probably never will. Many of those SoCs are already commercially obsolete, similar for the one you are asking.

Ver 20250602-legacy kernel 6.6.10

Hi there, I think what would be next is to try an older image to see if the serial console and hardware itself are still working. If you're interested, I still have a version here locally: Armbian_20.08.10_Helios64_buster_current_5.8.14.img.xz. Groetjes,

Thanks! Just run upgrade to 6.12.30 - and sounds works! (on 6.12.20 was no sound card in aplay -l )

@MBeck @batoisai I’m selling mine as well (Belgium) if one of you guys are still interested. Work as intended, maintained well (looks as new), no 2.5Gbit LAN mod done either.

I set up an Ubuntu VM on my Mac to do linux stuff. With that I edited the ambianEnv.txt as you said. Behavior is the same. I should also add that there is a regular double-blink of the System LED after the initial fans (of about 2-3 seconds). I now remember that back when I set up the Helios, I was told to use PuTTY on Windows instead of my mac. Maybe there's an incompatibility of some sort? I checked and they recommend a set of drivers for Mac that I hadn't installed. I did and after playing around -- and only occasionally while playing around with connecting, disconnecting, rebooting -- did I sometimes get some garbled output in the serial window: posting it because it's the longest and least garbled output I've gotten so far. The command was exactly as on the Helios64 website, i.e. the baud rate was correct. Not sure where to go from here and what to blame.

Replying to my own again...UEFI doesn't seem to boot from SD if you don't modify the HW, it does boot from the internal eMMC, though! All you need to do is flash the EDK2/UEFI bios (1.1 at the point of writing) to the internal eMMC and then fix the GPT (I just run GParted or KDE Partition Manager - that asks you a couple of questions and fixes the parition table). After that you can just run the e.g. Fedora Rawhide ARM64 iso and install to the same eMMC (just have the installer "add the OS" - it will not change the GPT or overwrite the bios). After that you can boot from USB, SD, NVME and even a SATA with a m2 sata adapter.

Replying to my own post. ... EDK2 has an UEFI BIOS which runs mainline linux - no custom builds. It supports ACPI and device tree. I run this now with Fedora Rawhide 43 with KDE (6.4 Beta) which runs ACPI out of the box, older kernels work with device tree. I haven't used the latest mainline Armbian but that should work, too (at least the latest mainline image). Rawhide runs mainline kernel 6.15/6.16 (latest build) which supports the SOC + GPU out of the box.

The analog audio output to the connector that is soldered to the board does not work for some reason. Although there is a code in the core, there is also a node in the DTS.

Audio output via HDMI should work on all H616-H618 devices. This was tested on the bananapi-m4-berry board for current and edge kernels. In the pulseaudio settings applet, you need to make several switches back and forth (turn on/off) for the sound to appear. Tested on gnome, ubuntu.

https://github.com/armbian/build/pull/8191

Testing the M2 16G with trunk 90 (Kernel 61.15) & trunk 38 (Kern 6.14.8) and the USB-C OTG port isn't working. [ +0.245948] usb 7-1: new full-speed USB device number 2 using xhci-hcd [ +0.124258] usb 7-1: device descriptor read/64, error -71 [ +0.227984] usb 7-1: device descriptor read/64, error -71 [ +0.223715] usb 7-1: new full-speed USB device number 3 using xhci-hcd [ +0.124295] usb 7-1: device descriptor read/64, error -71 [ +0.223803] usb 7-1: device descriptor read/64, error -71 [ +0.104107] usb usb7-port1: attempt power cycle [ +0.395844] usb 7-1: new full-speed USB device number 4 using xhci-hcd [ +0.000112] usb 7-1: Device not responding to setup address. [ +0.203891] usb 7-1: Device not responding to setup address. [ +0.203946] usb 7-1: device not accepting address 4, error -71 [ +0.000609] usb 7-1: WARN: invalid context state for evaluate context command. [ +0.119353] usb 7-1: new full-speed USB device number 5 using xhci-hcd [ +0.000118] usb 7-1: Device not responding to setup address. [ +0.204373] usb 7-1: Device not responding to setup address. [ +0.207473] usb 7-1: device not accepting address 5, error -71 [ +0.000613] usb 7-1: WARN: invalid context state for evaluate context command. [ +0.000109] usb usb7-port1: unable to enumerate USB device [ +30.217458] usb 7-1: new full-speed USB device number 6 using xhci-hcd [ +0.123993] usb 7-1: device descriptor read/64, error -71 [ +0.231951] usb 7-1: device descriptor read/64, error -71 [ +0.223935] usb 7-1: new full-speed USB device number 7 using xhci-hcd [ +0.120028] usb 7-1: device descriptor read/64, error -71 [ +0.224108] usb 7-1: device descriptor read/64, error -71 [ +0.103939] usb usb7-port1: attempt power cycle [ +0.396008] usb 7-1: new full-speed USB device number 8 using xhci-hcd [ +0.000139] usb 7-1: Device not responding to setup address. [ +0.203807] usb 7-1: Device not responding to setup address. [ +0.207853] usb 7-1: device not accepting address 8, error -71 [ +0.000608] usb 7-1: WARN: invalid context state for evaluate context command. [ +0.119394] usb 7-1: new full-speed USB device number 9 using xhci-hcd [ +0.000140] usb 7-1: Device not responding to setup address. [ +0.204031] usb 7-1: Device not responding to setup address. [ +0.203926] usb 7-1: device not accepting address 9, error -71 [ +0.000796] usb 7-1: WARN: invalid context state for evaluate context command. [ +0.000293] usb usb7-port1: unable to enumerate USB device [Jun 2 19:50] usb 7-1: new full-speed USB device number 10 using xhci-hcd [ +0.123926] usb 7-1: device descriptor read/64, error -71 [ +0.116517] xhci-hcd xhci-hcd.7.auto: remove, state 4 [ +0.000011] usb usb8: USB disconnect, device number 1 [ +0.000280] xhci-hcd xhci-hcd.7.auto: USB bus 8 deregistered [ +0.000009] xhci-hcd xhci-hcd.7.auto: remove, state 1 [ +0.000004] usb usb7: USB disconnect, device number 1 [ +0.055430] usb usb7-port1: attempt power cycle Same USB-C device (CCD camera) tested and working in the USB-3 port.