All Activity

So you don't want to remove: armbian-config armbian-firmware armbian-zsh linux-dtb-current-sunxi linux-image-current-sunxi (those last two are your linux kernel and dtb files - which was the reason you couldn't boot previously) So you can see here the upgrade disabled the armbian apt repository. So it can't install the updated armbian packages. So should be: deb http://apt.armbian.com jammy main jammy-utils jammy-desktop (So uncomment and change all references from focal to jammy) That is coming from one of the armbian* files located in /etc. I don't remember which one. If after everything is upgraded, if it still isn't showing the correct value, you can edit. I think this should get updated by the installation of the correct armbian-bsp-* package.

@ezpc98 armbian-config is just automating the setting of the parameters in ArmbianEnv.txt. So after running it, you can see what is set and adjust manually if you prefer.

Hi Nick. I'm on a business trip now, I'll be able to check on Monday. Maybe I'm just not assembling the firmware correctly? I’ll try to compile it again and publish the output of dmesg or whatever you suggest to understand the problem. Thank you very much for your time and help.

Werner Looks like it's just trixie. built an image with Bookworm (bookworm_edge_6.8.7_minimal) and works with no issues so far Bill

Ok, upgraded successfully. I said no to removing obsolete stuff in the end and it seemed to want to delete armbian stuff. I did not freeze the kernel this time one thing is a bit weird Now it says Armbian 23.02.2 Jammy shouldn't the version be 24. something? I am nearly done, let me know if I can safely run apt update/upgrade? I'd really hate to start over. My /etc/apt/sources.list.d/armbian.list file contents - the directory was a bit different Thank you all so far!

windows WSL2 Delete just the h96 max DTS and DTB from patch\kernel\archive\rockchip64-6.6 Drop the new https://github.com/hqnicolas/ArmBoardBringUp and compile again. sudo gpioinfo I'm also using this method to figure out how to enable 1.8v on Pin12 to AP6335 32*4 + 8*3 + 5 = GPIO4 RK_PD5 8*0 = A 8*1 = B 8*2 = C 8*3 = D Also Trying to disable the kernel 6.2 GPIO I can confirm: the enable pin is RK_PB1 from GPIO2 it will enable wifi by 1.8v on Pin12 to AP6335 I have FIxed the problem with this pin in kernel 6.6 the problem is here: GPIO_ACTIVE_LOW sdio_pwrseq: sdio-pwrseq { status = "okay"; compatible = "mmc-pwrseq-simple"; clocks = <&rk809 1>; clock-names = "ext_clock"; pinctrl-names = "default"; pinctrl-0 = <&wifi_enable_h>; reset-gpios = <&gpio2 RK_PB1 GPIO_ACTIVE_HIGH>; post-power-on-delay-ms = <100>; };

How are you compiling this dts? Is there a shorter way or you are recompiling the whole kernel?

This is not correct. Due to its size, U-Boot must be run from RAM. The RAM must therefore already be initialized before U-Boot can be loaded at all. This is usually done by Trusted Firmware-A (TF-A). U-Boot is only the payload (in TF-A terminology: BL33). You might want to read TF-A's documentation to understand the boot flow, I think here is a good place to start. You're lucky if TF-A is open source for your SoC, but often only a binary BLOOB for BL2 and BL31 is provided by the SoC manufacturers.

After first boot and initial setup and login, I can enable and start the openssh server with no problem. I'm not sure how generating a set of new keys would help. This happens with numerous images. Armbian_24.5.0-trunk.429_Orangepi5-plus_trixie_edge_6.8.6_minimal.img Armbian_24.5.0-trunk.429_Orangepi5-plus_trixie_vendor_6.1.43_minimal.img Among others. Legacy image with 5.10.160 kernel does not have this problem Regards Bill

Hi, Not change millivolt value because i afraid to do a mistake I just setting differentes values of freq For moment i am at 400-1200Mhz and not lose connection... Can you explain me command to change milivolt setting if i have futur courage or crazy spirit to try this idea? And i have question, i install my 6.6.27 Kernel .deb build my self with official framework, then i reboot and do my pattern 3 times without crash... Today i reboot and lose connection approximately 10min after boot when i set upper than 1400mhz... milivolt value work before reboot why not after, setting not change? Now i do: git clone --depth=1 --branch=main https://github.com/armbian/build ; cd build/ ./compile.sh kernel BOARD=helios64 BRANCH=current dpkg -i *.deb to install Kernel 6.6.28 4 packages reboot and... uptime 18min... not loose connection ! i become crazy !

Do I understand you correctly that you suggest to increase all opp-microvolt values in opp-table-1 by 75 millivolt ? This would i.e. change opp-microvolt = <0xc96a8 0xc96a8 0x1312d0>; to opp-microvolt = <0xdbba0 0xdbba0 0x1437c8>; # here are my current values opp-table-1 { compatible = "operating-points-v2"; opp-shared; phandle = <0x0d>; opp00 { opp-hz = <0x00 0x18519600>; opp-microvolt = <0xc96a8 0xc96a8 0x1312d0>; clock-latency-ns = <0x9c40>; }; opp01 { opp-hz = <0x00 0x23c34600>; opp-microvolt = <0xc96a8 0xc96a8 0x1312d0>; }; opp02 { opp-hz = <0x00 0x30a32c00>; opp-microvolt = <0xc96a8 0xc96a8 0x1312d0>; }; opp03 { opp-hz = <0x00 0x3c14dc00>; opp-microvolt = <0xd59f8 0xd59f8 0x1312d0>; }; opp04 { opp-hz = <0x00 0x47868c00>; opp-microvolt = <0xe7ef0 0xe7ef0 0x1312d0>; }; opp05 { opp-hz = <0x00 0x54667200>; opp-microvolt = <0xfa3e8 0xfa3e8 0x1312d0>; }; opp06 { opp-hz = <0x00 0x5fd82200>; opp-microvolt = <0x10c8e0 0x10c8e0 0x1312d0>; }; opp07 { opp-hz = <0x00 0x6b49d200>; opp-microvolt = <0x124f80 0x124f80 0x1312d0>; }; };

have you tried to run dpkg-reconfigure openssh-server so a fresh bunch of keys is being generated? Seems like for some reason key generation fails on first boot....

Ok that's all clear now, thanks a lot for the answers!

Hi Dave, I don't see any difference between our dts (That deal with hdmi/audio). Maybe the overlay dtbo_a changed something.? If you can extract that. Have you tried your box with different TV/monitors and hdmi cables? Here's my dts. devicetree.dts

Thanks for the pointer, much appreciated. I scrolled through the list (System > Hardware) and there is an overlay module "rockpi4cplus-usb-host". At least the name suggest it is for this board. If I toggle this option and reboot, assume it will switch the port from OTG To host mode.

You would use armbian-config to enable overlays. But in a quick look there is no such overlay in Armbian.

Here is the partial boot log Starting ssh.service - OpenBSD Secure Shell server... sshd: no hostkeys available -- exiting. ssh.service: Control process exited, code=exited, status=1/FAILURE ssh.service: Failed with result 'exit-code'. Failed to start ssh.service - OpenBSD Secure Shell server. ssh.service: Scheduled restart job, restart counter is at 1. Starting ssh.service - OpenBSD Secure Shell server... sshd: no hostkeys available -- exiting. Not sure what to do as keys have not been generated yet. Thanks, Bill

....Grrrr I reboot... and now i lose network connection random time (approximately 6-10min) after full boot... and i lose access by USB wire to console... return in unstable world... I become CRAZY ! Back to 400-1200Mhz max schedutil, if lose connection... back to 1200 1200 Performance (equal to fix freq 1200)

I have the installed community build 24.5.0-trunk.417 Bookwarm. Radxa official guidance (link) asks to edit /boot/hw_intfc.conf file to change between host & OTG mode. Armbian build does not have hw_intfc.conf file but I believe /boot/ArmbianEnv.txt is Armbian way to manage the config. what is the correct way add "intfc:dtoverlay=rk3399-usb-otg" overlay in ArmbianEnv.txt file?

Hi, My command: To scrub RAID10: echo check > /sys/block/md0/md/sync_action At same time i check BTRFS with: btrfs check --readonly --check-data-csum --progress /dev/disk/by-uuid/1d4e2c84-1c43-4d73-8acb-XXXXXXXXXXXXX At at same time i do copy/delete/copy random from personnal computer to helios64 samba share one pass finished after about 36h... i run pass 3 times For information, i use LUKS overs my raid10 My fancontrol file is: root@helios64:~# cat /etc/fancontrol # Helios64 PWM Fan Control Configuration # Temp source : /dev/thermal-cpu #INTERVAL=10 INTERVAL=30 FCTEMPS=/dev/fan-p6/pwm1=/dev/thermal-cpu/temp1_input /dev/fan-p7/pwm1=/dev/thermal-cpu/temp1_input MINTEMP=/dev/fan-p6/pwm1=40 /dev/fan-p7/pwm1=40 #MAXTEMP=/dev/fan-p6/pwm1=110 /dev/fan-p7/pwm1=110 MAXTEMP=/dev/fan-p6/pwm1=50 /dev/fan-p7/pwm1=50 #MINSTART=/dev/fan-p6/pwm1=60 /dev/fan-p7/pwm1=60 MINSTART=/dev/fan-p6/pwm1=20 /dev/fan-p7/pwm1=20 #MINSTOP=/dev/fan-p6/pwm1=40 /dev/fan-p7/pwm1=40 MINSTOP=/dev/fan-p6/pwm1=20 /dev/fan-p7/pwm1=20 MINPWM=20 and i install: Full Firmware deb package to remove error with 2,5G ethernet driver I do extend swap by swapfile to 6Go and i run 2 containers with podman, Plex and SFTPGO

Ive never frozen the kernel when doing upgrades. So that shouldn't be necessary. I would recommend redoing the upgrade, and at the end looking at the list of obsolete packages and not removing them. Finish the upgrade (without removing obsolete packages) then go see what the status of your /etc/apt/sources.d/armbian.list file is and make that correct, then use apt to update/upgrade your armbian packages. Then look at your obsolete packages and make sure the list is sane (that is it's not removing any armbian needed packages, *armbian*, linux-image-* or linux-dtb-*.) Only then would I remove obsolete packages.

@voapilro, @bjorn, @electricworry I'm attempting to fix (at least a hack) the 1.5GB problem by attempting to build a custom u-boot to attempt to resolve the issue. The thing is the codes are pretty complex. https://docs.u-boot.org/en/latest/ https://source.denx.de/u-boot but that actually I succeeded in building u-boot The trouble is I'm getting this: U-Boot SPL 2024.04-00757-gbeac958153-dirty (Apr 18 2024 - 23:22:28 +0800) DRAM: 0 MiB 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 ion U-Boot 2024.04-00757-gbeac958153-dirty (Apr 18 2024 - 23:22:28 +0800) Allwinner Technology size=30, ptr=590, limit=2000: 26370 CPU: Allwinner H616 (SUN50I) Model: OrangePi Zero3 DRAM: 0 Bytes So I literally need help with the codes, I'm doing pretty tedious debug etc with a 1.5G OPi Z3 board I bought for this purpose. if you run the 'original' images, that has a 'working' u-boot, it reads DRAM 2GB https://www.armbian.com/orange-pi-zero-3/ still 'incorrect' but that accordingly there'd be fixes for it (in u-boot) https://forum.openwrt.org/t/can-someone-make-a-build-for-orange-pi-zero-3/168930/42 https://gist.github.com/iuncuim The trouble as i try to trace where the calls are going is that it is not even going into the dram initialization codes in u-boot meant for H616/H618 to initialize and size up the lpddr4 dram. the codes are complex and I'd hope to get some leads there to attempt a solution. if a 'custom u-boot' can fix that, it'd at least help those who still only have 1.5GB boards to get Armbian running on it. By *replacing* the u-boot (practically the boot loader (and BIOS)) in the image or sd card. The image (and on the SD card) looks like this 0-7 KB (unused/reserved) 8 KB - 1 MB u-boot 1 MB - the rest of your sd card (this is your linux partition and Armbian proper (Debian or Ubuntu) lives here) u-boot does the bulk of the 'black magic' dealing with memory initialization and sizing, and then passing that across to linux during boot up. and linux uses the device tree (DTB, DTS) to configure the various devices uart, usb, sd card, leds, etc etc and subsequently present various of them in /dev. a 'custom u-boot' apparently seem to be a most feasible 'solution' (hack) to at least get past the 1.5GB problem. it is quite easy to simply take the original image, and substitute one u-boot made to say the memory is 1.5GB.

@voapilro orange pi's suffer from a few things, in particular poor software support and if you have an issue and goto their forums http://www.orangepi.org/orangepibbsen/ you can see a lot of no responses, spams etc. and that for the 'official' images you have obtained, those are the relevant support forums as they are different from Armbian today. The images released from Orange Pi are linux kernel versions 6.1 which has yet been updated, nothing 'wrong' about it, but that linux version progress is relentless. in fact Orange Pi Zero 3 (and a little later Zero 2W) is supported out of mainline linux from kernel release 6.6, i.e. the DTS (device tree configuration) is released open sourced. And that the implementation from mainline is completely developed open sourced (by various talented individuals outside here in linux-sunxi i think, and subsequently the few of us here siezed on the opportunity and tried to make Armbian run on it, browse the earlier part of this thread and you see @Gunjan Gupta, @pixdrift, @Stephen Graf et.al working this, we also found that a lot of things are undocumented and it is a *miracle* that it is after all running (well) today. try getting a 1G / 2G / 4G board and run Armbian on it. https://www.armbian.com/orange-pi-zero-3/ And I'd like to add that Armbian itself @Igor and team contributes in no small measure that makes this project possible (just consider catching up with the linux versions with so many platforms to carry), considering that there is no 'big company' (e.g. Intel, Rpi etc) behind this. it is all little contributors whom you see here. In this sense, the users of Armbian are the contributors and maintainers as well, a co-operative, practically the spirit of open source, if after all that economic model works. A good thing is that you can literally build ths whole thing (the images for your board from *source*) https://github.com/armbian/build you can configure all the kernel parameters for all you want for the build, edit the source codes, fix bugs, add features etc, there are many 'upstream' projects which include the linux kernel itself, u-boot, the distributions Debian / Ubuntu that contributes into the assembly, probably others as well, and the armbian build framework at this day is huge and complex considering the platforms (boards) that is supported. This probably also matter to 'security conscious' people who want to know every nut that is in there. But that it is up to you to make the effort to inspect that there are no 'holes' (e.g. trojans, backdoors, connecting to 'unauthorized' C2 (command and control) sites that you don't want etc). e.g. you can inspect and tweak all you want and afterwards run the build. And not least being open sourced means that it is nearly / practically *bare metal*, the codes work the metal (transistors / silicion / registers) directly, no blobs in-between. The trouble with blobs is your app is release to you as a binary, the driver is a binary (blob), then a new os (e.g. linux version, you can even consider windows) is released, now your binary app and or driver no longer works in the new os version (linux or windows), and you can use your device (e.g. mouse) as your new door stop. buy a new one and again more binaries , more device driver blobs.

Yes, in the very end I was asked to remove obsolete packages. I said yes all the times. I don't remember what was in the list, since it was about 76~ packages I may try with no option to keep them Is there any way to enforce this manually pre-upgrade? I only freeze the kernel, i suppose it is something different? Or maybe I can try to upgrade without freezing kernel? Or is that a guaranteed fail?