All Activity

Yup, I opened a bug report about this on his github, I have yet to receive an answer. I'm having trouble figuring out if it's a hardware issue or a software issue, since I don't have a second bug to test at the same time. When I try the Makerbase OS on this same board, I don't have connectivity either, but at least, the link led turns on and off with the cable connect/disconnect.

Did you try to build the image with compile.sh and this following setting? INCLUDE_HOME_DIR=yes See https://docs.armbian.com/Developer-Guide_Build-Switches/#advanced

Hello ! I'm trying to build my custom Armbian image for a Raspberry Pi. When I build it with these settings, I get a rolling release, which I don't want. compile.sh BRANCH=current BUILD_DESKTOP=no BUILD_MINIMAL=yes DISABLE_IPV6=true INCLUDE_HOME_DIR=yes KERNEL_CONFIGURE=no NETWORKING_STACK=network-manager RELEASE=trixie EXPERT=yes BOARD=rpi4b But when I boot with the official armbian minimal image (Armbian_25.8.1_Rpi4b_trixie_current_6.12.41_minimal.img) It's not on the rolling release. Do I miss a setting ? edit: I've tried with building the image on the main and the v25.08 branch.

@Ducdanh Nguyen you forgot these steps choose "Show CSC/WIP/EOS/TVB" choose "I understand and agree" you should see a few x96q in the list.

@Nick A heres the complete info : 🧠 DRAM Chip 1: Marking: MPF694C4G-P Maker: UniIC (UnilC) Type: DDR3/DDR3L Density: 4 Gb (512 MB) Date code: 2021 (week 11) Chip 2: Marking: SBC13H4G150 Maker: UniIC (UnilC) Type: DDR3/DDR3L Density: 4 Gb (512 MB) Date code: 2020 (week 11) ✅ Total RAM = 1 GB (2 × 512 MB) 💾 Storage (eMMC) Chip: Marking (line 1): NCEMAM60-08G Maker: FORESEE Type: eMMC Flash (not raw NAND) Capacity: 8 GB Marking (line 2): 000 Serial/Batch: Z1S1801147073 Date code: 1802 → Year 2018, Week 02 ✅ Total storage = 8 GB eMMC (manufactured early 2018)

@eselarm Thanks for the reply. We are using U-Boot: 2024.01-armbian-2024.01-S866c-P00ff-Ha5c2-V4cad-Bb703-R448a (Jan 21 2025 - 02:21:57 +0000) Allwinner Technology U-Boot 2024.01-armbian-2024.01-S866c-P00ff-Ha5c2-V4cad-Bb703-R448a (Jan 21 2025 - 02:21:57 +0000) Allwinner Technology CPU: Allwinner H3 (SUN8I 1680) Model: FriendlyARM NanoPi NEO Air DRAM: 512 MiB Core: 64 devices, 16 uclasses, devicetree: separate WDT: Not starting watchdog@1c20ca0 MMC: mmc@1c0f000: 0, mmc@1c10000: 2, mmc@1c11000: 1 Loading Environment from FAT... Unable to use mmc 0:1... In: serial,usbkbd Out: serial Err: serial Net: No ethernet found. starting USB... No working controllers found Autoboot in 1 seconds, press <Space> to stop

@laibsch Thanks for the reply. Yes. The filesystem is formatted as ext4. # df -h Filesystem Size Used Avail Use% Mounted on udev 186M 0 186M 0% /dev tmpfs 49M 5.7M 43M 12% /run /dev/mmcblk2p1 7.0G 5.2G 1.5G 79% / tmpfs 244M 0 244M 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 244M 8.0K 244M 1% /tmp /dev/zram1 49M 5.5M 40M 13% /var/log tmpfs 49M 0 49M 0% /run/user/0 tmpfs 49M 0 49M 0% /run/user/1000 # file -sL /dev/mmcblk2p1 /dev/mmcblk2p1: Linux rev 1.0 ext4 filesystem data, UUID=d3fe76cc-f19f-40a6-b8db-44a87f92714f (needs journal recovery) (extents) (64bit) (large files) (huge files) By bricked, I mean exactly that. Device boot is interrupted on the "Loading kernel" message. In these cases, the device can be recovered by booting from an SD Card and running fsck

I have identified the ram chip and nand, but don't know where wifi is, i think thats not very important since i have alot of usb wifi and ethernet

@IBV Thanks! I will look into that info and check if we can do this conversion is runtime, and if so, how it can be automated.

Yeah, also on my laptop (Arch with upstream 6.16 kernel) this problem does not happen, so it shouldn't be because of specific patches to the rtw88 kernel in the RPi kernel repo. It only happens when I use the kernel built with Armbian build system. I am completely clueless about what could be causing this 🤷‍♂️

Sorry that was resolved 2 days ago, but I don't see and never seen this long list. Only 3 options vendor 6.1, 6.12 and edge (6.16), This morning I also seen the u-boot wasn't the good one. I downloaded for rock5-itx, but had linux-u-boot-cyber-aib-rk3588-edge instead of linux-u-boot-rock-5-itx-edge, changed it, rebooted (on 6.16) worked, tried again 6.12, still no display. I needed to arch-chroot on the armbian to take a screenshot (but I've the same dispay on armbian itself): I seen 6.16.4 is now available and work, after /boot/config-6.16.4-edge-rockchip64, gcc 13.3.0 is now again used instead of old 11.x :). Debian Trixie has GCC 14.2.0 CONFIG_CC_VERSION_TEXT="aarch64-linux-gnu-gcc (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0" And after changelog on kernel.org, patch for AV1 acceleration had been applied on this version: https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.16.4 Fixes: 003afda97c65 ("media: verisilicon: Enable AV1 decoder on rk3588") Sorry I maybe mix too much subjects in the same post, but: I also seen a minimal IoT version of Trixie for Rock5-itx. Can I made safely a debian os upgrade from apt? Or is it better to wait release for desktop version ? Another point. On armbian, only LLVMpipe is used, I compiled last mesa git on arch, will try to do this for debian too. and some application that need to use EGL+dri (wings3D, blender, obs) report broken DRI2 access. I'm not sure if it's due to some kernel patchs (I reuse the armbian 6.16 kernel on arch), or to the current state of mesa-git. They all works with llvmpipe. Othere applications like PPSSPPSDL work fine without it. Ex, with wings3d + forced zink: MESA_LOADER_DRIVER_OVERRIDE=zink GALLIUM_DRIVER=zink wings3d WARNING: Some incorrect rendering might occur because the selected Vulkan device (Mali-G610) doesn't support base Zink requirements: feats.features.fillModeNonSolid feats.features.shaderClipDistance libEGL warning: egl: failed to create dri2 screen WARNING: Some incorrect rendering might occur because the selected Vulkan device (Mali-G610) doesn't support base Zink requirements: feats.features.fillModeNonSolid feats.features.shaderClipDistance

Hello @Nick A i did everything git cloned now im in setup, heres what i choosed: 1. Do not change kernel configuration And after that, i don't found any compactible for my h313 also note that mine firmware is based off d9 Pro 5g so i think it could use the same dram settings and wifi chip except for the cpu. Hope this helps!

Use the provided curl command at the end of every build run or use "SHARE_LOG=yes" with the compile command to auto-upload. Nobody will try to read through this unformatted mess.

Easiest way is to use the customize-image.sh file in userpatches. Stuff there gets executed within chroot on the sdcard just before its closed and assembled. More advanced way is using extensions. Check extensions folder for examples.

You can either experiment with the CLEAN_LEVEL switch or use kernel-patch or uboot-patch (depending on what you want to modify) to create proper patch files from the diff.

Try change the folder permission, chmod -r 775 /home/odroid/

The apt source is always overwritten by the cache source when modified. How can I modify this cache source. How can I modify this cache source?? help help

Did you download stretch already, before I remove it to put up Bionic?

@Nick A I woke up and i'll start working on it.

Looks good! Thank you. What's the best way to get start customizing the build?

Great! Thank you. I will try it.

OH MY GOD YOU HAVE THAT TOO? can you please share it? i need that image, i can host it on google drive myself if someone would need it

Hello, everyone. I'm using Armbian_25.5.2_Orangepizero3_bookworm_current_6.12.30-homeassistant_minimal on 4GB OpiZero3. When booting from sd, the bluetooth controller is initialized correctly. I made a boot from usb-ssd via armbian-config: everything works fine, but the bluetooth controller is not initialized. /sys/class/bluetooth is empty. Switch back to sd - it works again. Boot from ssd - no. I compared whether it transferred the distribution correctly from sd to ssd - all files are the same. What could be the problem?

This looks normal. Most of those boards have bootloaders at locations prior to boot partition. Boot loop. This can be many things - i would guess kernel crash and watchdog issue restart. Why that happens? Hard to tell. This way? sudo screen /dev/ttyUSB0 115200 It should prompt out something.

Hi, I used to run a full docker environment using the Radxa Debian buster image upgraded to bullseye. Lately as the backport repo has been archived I decided to move onto Armbian as upgrading bullseye to bookworm did not boot (or seemed so...). After flashing the latest Rockpi4 image to the Rockpi4, I copied the docker configuration and files backups. I now have a akward behavior: - starting all the stacks (or containers) works fine, all seems ok - rebooting via sudo reboot provokes an endless reboot cycle which is only ended if I unplug the USB Zigbee coordinator key. Once the loop is stopped, the RockPi does not have any IPv4 address (only IPv6) and is unreacheable by SSH. - power cycling with the USB key unplugged fixes the boot loop and everything is back to "normal", except the following dmseg errors: rock@rockpi4b:~$ sudo dmesg -l 0,1,2,3 [ 3.099273] rockchip-pcie f8000000.pcie: PCIe link training gen1 timeout! [ 3.099333] rockchip-pcie f8000000.pcie: probe with driver rockchip-pcie failed with error -110 [ 11.200510] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43456-sdio for chip BCM4345/9 [ 11.731680] brcmfmac: brcmf_c_process_txcap_blob: no txcap_blob available (err=-2) [ 11.732234] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/9 wl0: Jun 16 2017 12:38:26 version 7.45.96.2 (66c4e21@sh-git) (r) FWID 01-1813af84 [ 99.980012] cpu cpu4: _set_opp_voltage: failed to set voltage (825000 825000 1250000 mV): -6 [ 99.980072] cpu cpu4: Failed to set regulator voltages: -6 [ 99.980097] cpufreq: __target_index: Failed to change cpu frequency: -6 [ 246.811985] cpu cpu4: _set_opp_voltage: failed to set voltage (825000 825000 1250000 mV): -6 [ 246.812046] cpu cpu4: Failed to set regulator voltages: -6 [ 246.812070] cpufreq: __target_index: Failed to change cpu frequency: -6 [ 400.087329] cpu cpu4: _set_opp_voltage: failed to set voltage (825000 825000 1250000 mV): -6 [ 400.087387] cpu cpu4: Failed to set regulator voltages: -6 [ 400.087410] cpufreq: __target_index: Failed to change cpu frequency: -6 Now this is where it gets strange: if I prevent zigbee2mqtt container to automatically start at boot (which cannot be a permanent solution obviously) it doesn't matter if the USB key is plugged in or not (whichever usb port), Armbian boots ok and all other containers start ok. I already checked the /dev/ttyusb0 access rights, tried to change the docker container user, activate the rockchipdw3 overlay, changing the USB port for the Zigbee key, switching from rolling to stable and vice versa, to no avail. No need to say that the same config worked under bullseye. Does someone have any lead or clue about what's happening ? Where can I look as logs don't show anything special... Any help would be greatly appreciated, thanks in advance! My config: Rockpi4B, Armbian_community_25.11.0-trunk.70_Rockpi-4b_bookworm_current_6.12.43_minimal.img, usb-ITead_Sonoff_Zigbee_3.0_USB_Dongle_Plus