All Activity

Seems to be a kernel thing that has changed... Made me curious and I found this: https://forums.raspberrypi.com/viewtopic.php?t=325309 Obv not a solution for you since the tread is about rpi OS (but other hardware outside of rpi is actually mentioned). You might get some good info on how to move forward reading that. I do not know how to do this on armbian. Maybe you can use x11vnc (I have no idea if this exists in the repos) and set the resolution as described here (very old thread): https://stackoverflow.com/questions/12050021/how-to-make-xvfb-display-visible/40678605#40678605 Or maybe you can do the solution mentioned here, where you get a cheap usb > hdmi adapter for a few $$ that fools the SBC that it has a monitor connected.

nightly kernel? I think you are talking about nightly releases that are not yet stable or tested. Unfortunately I don't have time to test kernels and wait for any bugs.

==> shrink-backup v1.0 <== I have made the decision to not deal with other partitions than boot and root for the 1.0 release. Instead I introduced the --loop function to let the user expand the img file using the [extra space] option and then manually create partitions by running for example: sudo gparted /dev/loop0 in a terminal to edit partitions in a graphical interface using gparted. I want to give the user freedom, but I also have to stay true to my initial plan with this script: a very fast utility to create a bootable img file from the system and subsequently keep it updated. I haven't dropped the idea of at least handling /home completely, but the script goes from "kinda basic functionality" to "advanced script" pretty fast when I start working on the feature. If I do this, I still want the script to be as easy as possible to use, but at the same time give power users the ability to fine tune, ie a lot of work. Features in the release: Introduction of --loop, --fix & -z (zoom speed) Now crosschecks fstab with lsblk for certain operations. Changed MB to MiB etc. Old habits die hard. Will now, if needed, check and/or ask for installing gdisk on debian and arch based systems. GPT partition table now supported Various bug fixes. I hope you find it useful!

Hi @TDCroPower Have you got any issue with systemd-networkd service ? I systematically have a timeout as it seems waiting for all network interface to be ready. $ systemctl status systemd-networkd-wait-online.service × systemd-networkd-wait-online.service - Wait for Network to be Configured Loaded: loaded (/lib/systemd/system/systemd-networkd-wait-online.service; enabled; preset: disabled) Drop-In: /etc/systemd/system/systemd-networkd-wait-online.service.d └─override.conf Active: failed (Result: exit-code) since Fri 2024-04-19 16:33:57 CEST; 18min ago Docs: man:systemd-networkd-wait-online.service(8) Process: 1188 ExecStart=/lib/systemd/systemd-networkd-wait-online (code=exited, status=1/FAILURE) Main PID: 1188 (code=exited, status=1/FAILURE) CPU: 48ms I use end0 network interface. The other enx646266d00b79 isn't connected I've got a bridge br0 with a virtual tap0 interface (OpenVPN) podman runs a container and enable the interface veth7198de08 and the bridge cni-podman. $ networkctl IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 end0 ether enslaved configuring 4 enx646266d00b79 ether no-carrier configured 5 br0 bridge routable configured 6 tap0 ether enslaved configuring 7 cni-podman0 bridge routable unmanaged 8 veth7198de08 ether enslaved unmanaged 7 links listed.

By the way, Running Armbian 23.08.0-trunk Bookworm with Linux 6.6.8-edge-rockchip64 I notice an error at the beginning of linux boot. "mdadm: initramfs boot message: /scripts/local-bottom/mdadm: rm: not found" Seems an old one as I follow these instructions for Helios4 to solve the issue https://wiki.kobol.io/helios4/mdadm/#fix-mdadm

9 out of 10 times this is better to configure on your dhcp server, usually your router. Set a static ip on your router for the MAC adress on your board. WAY less headaches than starting configuring only the client. :)

The problem here I suspect is the sd-card got tear and wear, hence the capacity might drop, but if you ran a full dd of the entire card, the iso might become bigger than what fits on the sd-card (that now is a tiny bit smaller). It's not unusual that the cells are still readable but not writable, ie you can not modify the data. So when you create the img file, it is a complete one, but your card can no longer fit that img. Let me shamelessly invite you to use my little project: shrink-backup That way your img file becomes the size of the DATA on the device, not the entire thing. Then it will get re-expanded to use the entire sd-card when you boot it the first time after restoration. (if your os is supported, armbian is)

Hi @prahal I've just done a test with your cpufreq-switching-2 program. I'm running Helios64 on Armbian 23.08.0-trunk Bookworm with Linux 6.6.8-edge-rockchip64 I've started with LITTLE (CPUL = 1) The program ran the 100 loops without issue. Then I ran with big (CPUB = 1) So far it failed at the 6th loop Before a third run, I tried to change the interrupt allocation on xhci and ahci as you suggested Please note the interrupts may vary after reboot (e.g. ahci was 76-80, after reboot it is 75-79) # cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 18: 0 0 0 0 0 0 GICv3 25 Level vgic 20: 0 0 0 0 0 0 GICv3 27 Level kvm guest vtimer 23: 7947 8876 6014 7156 18916 24271 GICv3 30 Level arch_timer 25: 6601 5232 4476 4609 11249 4343 GICv3 113 Level rk_timer 31: 0 0 0 0 0 0 GICv3 37 Level ff6d0000.dma-controller 32: 0 0 0 0 0 0 GICv3 38 Level ff6d0000.dma-controller 33: 0 0 0 0 0 0 GICv3 39 Level ff6e0000.dma-controller 34: 0 0 0 0 0 0 GICv3 40 Level ff6e0000.dma-controller 36: 915 0 0 0 0 0 GICv3 132 Level ttyS2 37: 0 0 0 0 0 0 GICv3 147 Level ff650800.iommu 38: 0 0 0 0 0 0 GICv3 149 Level ff660480.iommu 39: 0 0 0 0 0 0 GICv3 151 Level ff8f3f00.iommu, ff8f0000.vop 40: 0 0 0 0 0 0 GICv3 150 Level ff903f00.iommu, ff900000.vop 41: 0 0 0 0 0 0 GICv3 75 Level ff914000.iommu 42: 0 0 0 0 0 0 GICv3 76 Level ff924000.iommu 43: 0 0 0 0 0 0 GICv3 85 Level ff1d0000.spi 44: 0 0 0 0 0 0 GICv3 84 Level ff1e0000.spi 45: 0 0 0 0 0 0 GICv3 164 Level ff200000.spi 46: 1399 0 0 0 1775 0 GICv3 142 Level xhci-hcd:usb1 47: 30 0 0 0 0 0 GICv3 67 Level ff120000.i2c 48: 0 0 0 0 0 0 GICv3 68 Level ff160000.i2c 49: 5031 0 0 0 0 0 GICv3 89 Level ff3c0000.i2c 50: 540 0 0 0 0 0 GICv3 88 Level ff3d0000.i2c 51: 0 0 0 0 0 0 GICv3 90 Level ff3e0000.i2c 52: 0 0 0 0 0 0 GICv3 129 Level rockchip_thermal 53: 0 0 0 0 0 0 GICv3 152 Edge ff848000.watchdog 54: 0 0 0 0 0 0 GICv3-23 0 Level arm-pmu 55: 0 0 0 0 0 0 GICv3-23 1 Level arm-pmu 56: 0 0 0 0 0 0 rockchip_gpio_irq 9 Edge 2-0020 57: 0 0 0 0 0 0 rockchip_gpio_irq 10 Level rk808 63: 0 0 0 0 0 0 rk808 5 Edge RTC alarm 67: 2 0 0 0 0 0 GICv3 94 Level ff100000.saradc 68: 0 0 0 0 0 0 GICv3 97 Level dw-mci 69: 0 0 0 0 0 0 rockchip_gpio_irq 7 Edge fe320000.mmc cd 70: 0 0 0 0 0 0 GICv3 81 Level pcie-sys 72: 0 0 0 0 0 0 GICv3 83 Level pcie-client 74: 0 0 0 0 0 0 ITS-MSI 0 Edge PCIe PME, aerdrv 75: 0 489 0 0 524 0 ITS-MSI 524288 Edge ahci0 76: 0 0 237 0 0 904 ITS-MSI 524289 Edge ahci1 77: 0 0 0 489 31578 0 ITS-MSI 524290 Edge ahci2 78: 0 0 0 0 249 0 ITS-MSI 524291 Edge ahci3 79: 0 0 0 0 0 248 ITS-MSI 524292 Edge ahci4 83: 14093 0 0 0 0 0 GICv3 43 Level mmc1 84: 0 0 0 0 0 0 rockchip_gpio_irq 5 Edge Power 85: 0 0 0 0 0 0 rockchip_gpio_irq 3 Edge User Button 1 86: 0 0 0 931 0 0 GICv3 44 Level end0 87: 5 0 0 0 0 0 rockchip_gpio_irq 2 Level fsc_interrupt_int_n 88: 0 0 0 0 0 0 GICv3 59 Level rockchip_usb2phy 89: 0 0 0 0 0 0 GICv3 135 Level rockchip_usb2phy_bvalid 90: 0 0 0 0 0 0 GICv3 136 Level rockchip_usb2phy_id 91: 0 0 0 0 0 0 GICv3 60 Level ohci_hcd:usb4 92: 0 0 0 0 0 0 GICv3 58 Level ehci_hcd:usb3 93: 0 0 0 0 0 0 GICv3 137 Level dwc3-otg, xhci-hcd:usb5 94: 0 0 0 0 0 0 GICv3 32 Level rk-crypto 95: 0 0 0 0 0 0 GICv3 146 Level ff650000.video-codec 96: 0 0 0 0 0 0 GICv3 87 Level ff680000.rga 97: 0 0 0 0 0 0 GICv3 145 Level ff650000.video-codec 98: 0 0 0 0 0 0 GICv3 148 Level ff660000.video-codec 99: 0 0 0 0 0 0 rockchip_gpio_irq 2 Edge gpio-charger 100: 0 0 0 0 0 0 rockchip_gpio_irq 27 Edge gpio-charger 101: 2 0 0 0 0 0 GICv3 51 Level panfrost-gpu 102: 0 0 0 0 0 0 GICv3 53 Level panfrost-mmu 103: 0 0 0 0 0 0 GICv3 52 Level panfrost-job IPI0: 1384 1517 1472 1311 4816 7551 Rescheduling interrupts IPI1: 12225 10971 9100 9240 10161 26978 Function call interrupts IPI2: 0 0 0 0 0 0 CPU stop interrupts IPI3: 0 0 0 0 0 0 CPU stop (for crash dump) interrupts IPI4: 2213 2003 2357 2402 2137 1671 Timer broadcast interrupts IPI5: 598 601 747 496 1106 784 IRQ work interrupts IPI6: 0 0 0 0 0 0 CPU wake-up interrupts Err: 0 I reallocated the interrupts over the little core. # echo 0 > /proc/irq/46/smp_affinity_list # echo 1 > /proc/irq/75/smp_affinity_list # echo 2 > /proc/irq/76/smp_affinity_list # echo 3 > /proc/irq/77/smp_affinity_list # echo 0 > /proc/irq/78/smp_affinity_list # echo 1 > /proc/irq/79/smp_affinity_list Then I ran the program on the big again (CPUB = 1) And I reach the 25th loop before it failed.

OG Zero has been doing just fine on community support since it stopped having official support, but I think we may be at the point where we will start to see the limitations of community support. If this overheating issue is a quirk specific to Orange Pi Zero, it may never get fixed. Or at least we may have to hope that it gets fixed in the mainline kernel, rather than in the Armbian image. Do you know if it's possible to switch to the nightly kernel as easily as you can switch to the legacy kernel?

1080p on linux? the gpu was working?

OK - I am currently testing your opp-table-1 values (added the missing ones): opp-table-1 { compatible = "operating-points-v2"; opp-shared; phandle = <0x0d>; opp00 { opp-hz = <0x00 0x18519600>; opp-microvolt = <0xdbba0 0xdbba0 0x1312d0>; clock-latency-ns = <0x9c40>; }; opp01 { opp-hz = <0x00 0x23c34600>; opp-microvolt = <0xdbba0 0xdbba0 0x1312d0>; }; opp02 { opp-hz = <0x00 0x30a32c00>; opp-microvolt = <0xdbba0 0xdbba0 0x1312d0>; }; opp03 { opp-hz = <0x00 0x3c14dc00>; opp-microvolt = <0xe7ef0 0xe7ef0 0x1312d0>; }; opp04 { opp-hz = <0x00 0x47868c00>; opp-microvolt = <0xfa3e8 0xfa3e8 0x1312d0>; }; opp05 { opp-hz = <0x00 0x54667200>; opp-microvolt = <0x10c8e0 0x10c8e0 0x1312d0>; }; opp06 { opp-hz = <0x00 0x5fd82200>; opp-microvolt = <0x11edd8 0x11edd8 0x1312d0>; }; opp07 { opp-hz = <0x00 0x6b49d200>; opp-microvolt = <0x1312d0 0x1312d0 0x1312d0>; }; };

Will attempt tonight.

I got past that DRAM: 0 Bytes it is my own goof when I'm editing the u-boot codes U-Boot SPL 2024.04-00757-gbeac958153-dirty (Apr 19 2024 - 18:04:53 +0800) sunxi_board_init DRAM:sunxi_dram_initmemsize 2048 M 1536 MiB spl_board_init_r Trying to boot from MMC1 NOTICE: BL31: v2.10.0(release):v2.10.0-729-gc8be7c08c NOTICE: BL31: Built : 23:11:18, Apr 18 2024 NOTICE: BL31: Detected Allwinner H616 SoC (1823) NOTICE: BL31: Found U-Boot DTB at 0x4a0be348, model: OrangePi Zero3 ERROR: RSB: set run-time address: 0x10003 ... the hack seemed to work next I'd need to learn u-boot,

I just enable the enable PIN 12 from HCY6335 I dont know how to select kernel drivers I think this driver dont work with 6.6 to test the driver on 6.1 kernel on armbian v23.11 git clone https://github.com/hqnicolas/build-23.git cd build-23 sudo chmod 777 compile.sh ./compile.sh

Unfortunately for the second time I found my home server blocked and this time the heat deformed the printed ABS case, I decided that I will put the latest 6.1.53 kernel image starting from scratch with the installation and I will deactivate the kernel updates

Hi, I am glad we have a working image for Rock 3C. I compiled mine and it also works. I have tested HDMI output, network, wifi, and USB. Also, lxd has no issue with the latest kernel. Because it is an unofficial image I found a missing feature to get wifi working as a hotspot. There were a lot of disappeared lines in /etc/hostpad.conf and also there was a message from the console reporting the hostapd is masked in other words is not running during testing maximum wifi speed.

@mongoose I didn't understand the problem, but if you need help here is a tutorial on the orange pi zero. https://hackaday.io/project/181169-orange-pi-zero-native-network-boot/log/196475-step-2-enable-spi-flash-and-and-write-u-boot

@Hqnicolas Do you specifically select Broadcom 43xx SDIO kernel drivers as they were not enabled per default on my side. Lets see what will come out of this build process.

I will answer my question very soon, but let me first introduce the candidate that bring us a lot of attention here: aegisub. Most of us think its dev has ended in 2018 and we are stuck to 3.2.2 since. It is not the case there are 2 candidates on the row. I made a big picture and bring the evaluation. I used latest armbian 24.2.1 bookworm arm64 on a sdcard for the test. At the begining it was armbian buster version. I override files and updrade package since. I ensured also to have hardware GL accel with the output on inxi -Gs, we have our Mali friend aboard. Nice! Let's start each aegisub to have the "Big Picture": I ordered from left to right the versions. What I discovered is the copyright date statement back to the past of aegisub 3.2.2 What happen to us when we try yo launch and chose a subtitle/ video file? -aegisub 2.30.2 , open with no popup, we can select a video and play it, sound is ok but we can not move in the video using the sound slider. When we play the video the sound slider does not move..Bad luck! -aegisub 3.2.2 : after cleaning lua scripts /usr/share/aegisub/automation due to unicode incompatibility used in karaskel that make crash aegisub on launch, we enjoy "Wx assert" popups that we can close by unchecking Show this dialog next time and click on Continue button When we open a video then it crash. Oh noo!!! Normally play ends here but many said snap is robust. So I look at it on snapcraft.io and there was a... -aegisub 3.3.3 is provided by procles which is a snap of wanqr latest release. A sudo apt install snapd and then snap install aegisub-procless. makes installation succeed, It installs the ubunto core 22 based ecosystem. Unfortunately, when we trigger it, it did not start. After digging a while , it is due to lua bug in 64 bits arch. I switched to 32bit bit removing snapd:arm64 and installing snap:armhf to force 32bit It went further but I remember we loosed the hardware accel this time . so snapd that could have saved us is not usable. For now, the only fully working aegisub with wx assert annoyances is using debootstrap with schroot in bookworm from jammy. I tried with latest bookworm , it works too.

Good work! Will try to compile it and test it out on my side.

Some settings that were set at build time can't be modified at runtime. This requires a new firmware build, e.g. to set the boot delay to 0, the build configuration has to be set to "CONFIG_BOOTDELAY=0". This is due to the build configuration. The build configuration determines the properties of a binary created from a certain source. These can be detail settings, or even decisive for which hardware it is usable. Finally, U-Boot can be built for all devices from the same source of a given release version. E.g. "make libretech-cc_defconfig" prepares a default configuration for LePotato. You can use "make menuconfig" to fine tune it afterwards. I don't know the details of Armbian's build framework, but I'm sure you can inject a patch that implements your desired change.

Hi, This morning, i do cold boot and crash after few minutes (less than 10min...) Boot is okok but lose ssh connection and to same with usb wire console, i have login and password ask but then i am block... (i can't find if problem hardware... systemd... software...) I use reset bottom and after 15min uptime, i try the same and not lose connection, (i don't understand why not lose connection, i do nothing and Helios64 seem Okok...) i do: (3 times) root@helios64:/tmp# ./cpufreq-switching allocated 64MB test: toggle freq before write 99/100 test: toggle freq before read 9/10, 99/100 root@helios64:/tmp# ./cpufreq-switching allocated 64MB test: toggle freq before write 99/100 test: toggle freq before read 9/10, 99/100 root@helios64:/tmp# ./cpufreq-switching allocated 64MB test: toggle freq before write 99/100 test: toggle freq before read 9/10, 99/100 root@helios64:/tmp# Not crash/freeze and during this test, i have samba Time Machine backup work and lot of I/O Network and 1GO of data pass from my mac to helios. I don't tune voltage, juste use 6.6.28 Kernel and my standard configuaration.... I run again you program and, i have again Time Machine Backup (samba share in background): | | | | ___| (_) ___ ___ / /_ | || | | |_| |/ _ \ | |/ _ \/ __| '_ \| || |_ | _ | __/ | | (_) \__ \ (_) |__ _| |_| |_|\___|_|_|\___/|___/\___/ |_| Welcome to Armbian-unofficial 24.5.0-trunk Bookworm with Linux 6.6.28-current-rockchip64 No end-user support: built from trunk System load: 86% Up time: 27 min Local users: 2 Memory usage: 11% of 3.77G IP: 10.0.0.155 CPU temp: 41°C Usage of /: 47% of 14G RX today: 1.5 GiB [ General system configuration (beta): armbian-config ] Web console: https://helios64:9090/ You have no mail. helios64@helios64:~$ su - Mot de passe : root@helios64:~# cd /tmp/ root@helios64:/tmp# uptime ; ./cpufreq-switching ; uptime 06:34:39 up 28 min, 3 users, load average: 5.87, 4.75, 3.61 allocated 64MB test: toggle freq before write 99/100 test: toggle freq before read 9/10, 99/100 06:36:12 up 29 min, 3 users, load average: 4.99, 4.71, 3.70 root@helios64:/tmp# No Problem, To conclude for moment, to my side; 6.6.28 stable but not at cold boot... stable after. Something (hardware or software) when cold boot crash or do bug in linux software... and after reset buttom is Okok... It's crazy i know ! (Possible problem in cold ramlog boot is /var/log full... i view is full just now... i will investigate next week...) If you want next week, i build a Vanilla armbian from source with official framework and run your cpufreq-switching on it, i think i will have same this day with my standard configuration but maybe not with crash at cold boot If you read my history message about Helios64 since about 3 years... it never stable with standard parameter. I do many tests and to change Kernel and this day the Best Kernel i never use is 6.6.27 and upper because not crash at standard frequency Schedutil Governor The very bad Kernel was 6.X branch, with thing kernel, Helios crash often just when i unlock my raid10 with LUKS cryptosetup And le 5.15.(something)69 or just before was the best stable Kernel with 400-1400Mhz schelutil (i speak about this in very old post) I try again you program, Time Machine Backup is finish... root@helios64:/tmp# uptime ; ./cpufreq-switching ; uptime 06:51:25 up 44 min, 3 users, load average: 3.98, 4.58, 4.24 allocated 64MB test: toggle freq before write 99/100 test: toggle freq before read 9/10, 99/100 06:53:01 up 46 min, 3 users, load average: 3.03, 4.09, 4.10 root@helios64:/tmp# Not crash, now i go to work office and then pass a weekend with my familly, keep in touch next week During this weekend, i run on my helios64 a script do in loop: echo check > /sys/block/md0/md/sync_action and: btrfs check --readonly --check-data-csum --progress /dev/disk/by-uuid/1d4e2c84-1c43-4d73-8acb-XXXXXXXXXXXXXX If Monday morning when i back my Helios64 not crash/freeze, for me 6.6.28 is good Kernel. Have a good day

@usual user I think this is what happens, within the microprocessor soc, there is sram likely small 10s-100s of K bytes is likely, so the on board rom loads u-boot as a SPL (secondary program loader) also into s-ram. Then that u-boot needs to *clock the dram* (i.e. setup the dram so that it is actually working), determine dram size, configure dram to be up and running e.g. the 'rows and columns', setup memory mapping. All these in *sram* it did not even touch dram. Then that once everything is up, u-boot loads the *linux kernel* into dram, pass over the DTS and pass over the dram memory size and jumps into the kernel code, then linux boots up from there on. The trouble is that u-boot did not detect the DRAM and the codes is directly from the stem (mainline) https://source.denx.de/u-boot/u-boot I added a lot of debug() statements to trace execution flow and it seemed apparently that it did not even go into the dram initialization parts of the code. So I actually need help with the u-boot codes. I can't figure out why it is not working. All that BL31 etc is mainly for power management (e.g. shutdown / suspend etc), didn't seem to deal with DRAM https://github.com/ARM-software/arm-trusted-firmware/tree/master/plat/allwinner/sun50i_h616

@Protx Thank you very much. I am currently compiling other systems, and I will test your solution later. Additionally, I have found that the latest official trunk403 build, as well as the previous trunk250, both exhibit this error. I am testing using an SD card.

Hello everyone Now I have finished compiling armbian once and want to check and change the device tree of uboot, but I don't know where to download it, only see the kernel source code in cache/source, so I want to ask