All Activity

Hello all I have broken my installation when I tried to install the kernel 6.1 my current kernel 5.10.160-legacy-rk35xx. My nanopc t6 do not start. My installation is on EMMC and start on it. Could you please help me to recover it ? I have a backup file from OMV but I don't know how to push the backup to the EMMC? other possibility I guess copy the boot folder backup to EMMC boot folder but I do not know if it is enough. I really appreciate an help furthermore a clear turial could help evryone to recover an installation on EMMC memory. Thanks in advance for your support.

Debian Buster is EOL. Remove Armbian related entries from apt sources and you are good to go. There won't be any further updates from Armbian for this userspace. https://docs.armbian.com/User-Guide_FAQ/#how-do-i-upgrade-from-armbian-buster-to-bullseye Debug boot issue: https://debug.armbian.de Put SD card into your Linux computer and mount it.

@voapilro I think there could be another mistake besides that, my memory computation is using unsigned long long, my guess is that'd be 64 bits, that becomes the 'offset' in mctl_mem_matches_top(offset). I made a guess that the unsigned long long would be truncated dropping the high order 32 bits, that would still match the 32 bits based address, but could be wrong. For reasons uncertain, searching for CONFIG_SYS_SDRAM_BASE 'returns a blank' in my source base, as such I took a liberty to define that as 0. A thing is memsz is computed as 2 GB ( 2048 * 1024 * 1024 ), as I guess observed, I'm not too sure if that might be offset away a little, say the 'bottom' 32kb

removed

@ag123 Thanks for testing it! But I think there is a mistake in your patch. Why you redefine CONFIG_SYS_SDRAM_BASE as 0? I forked u-boot and made a branch with my changes here and this is the patch. Please, can you try it?

My Nextcloudpi was running like a charm for years on an Odroid HC1 (no possibility to attache a monitor). It was still running Debian Buster 19.11.7. It was running so well that I neglected it a little too much. And then, when I attempted to upgrade the distro, it went bad. During the upgrade the following error occured: `` Err:5 http://httpredir.debian.org/debian buster-backports Release 404 Not Found [IP: 2a04:4e42:6f::644 80] Ign:6 http://mirrors.dotsrc.org/armbian-apt buster InRelease Err:7 http://mirrors.dotsrc.org/armbian-apt buster Release 404 Not Found [IP: 2001:878:346::116 80] Reading package lists... Done E: The repository 'http://httpredir.debian.org/debian buster-backports Release' no longer has a Release file. N: Updating from such a repository can't be done securely, and is therefore disabled by default. N: See apt-secure(8) manpage for repository creation and user configuration details. E: The repository 'http://apt.armbian.com buster Release' no longer has a Release file. N: Updating from such a repository can't be done securely, and is therefore disabled by default. N: See apt-secure(8) manpage for repository creation and user configuration details. Something went wrong. Fix it and try again `` Then I followed this [guidance](https://forum.armbian.com/topic/19237-armbian-upgrade-from-buster-to-bullseye/) In `/etc/apt/sources.list.d/armbian.list` I commented out the armbian repo and in `/etc/apt/sources.list` I changed from buster to bullseye. The I ran `apt update`, then `apt upgrade --without-new-pkgs`, then `apt full-upgrade`and then I rebooted the system. The Ordoid HC1 seemed to have started up again, I also see it my router, but it cannot be accessed via SSH, via the webbrowser nor the web-domain. 1. Is there a way to fix the install? 2. If not, is there a way to retreive the data and configs? (Not sure if the drive was encrypted. What is the default of Nextcloudpi?) Would really appreciate help.

@voapilro I tried patching those codes into my custom u-boot loader https://github.com/ag88/1.5GB_Fix_for_Armbian_on_OrangePiZero3/ unfortunately, when I tried booting with the updated u-boot, I noted 2 scenarios that is goofy and didn't work first the board is incorrectly detect as a 4GB board. For reasons I'm unsure, the detection is not stable. Sometimes it is detected as a 4GB board, other times 2GB. when it is correctly detected as 2GB, apparently I'm observing the 'dram wraparound' problem, i.e. writing to a little before 2GB spoofs and faked memory at that location when there is actually none. If it is working correctly, it should detect 2048M and return 1.5GB instead. The patch is like such: As such, I reverted the codes to the old 1.5GB hard coded version. It would have been good if this works (well), at least that it can be used on all the different Orange Pi Zero 3 boards

Tested with Armbian_24.2.3_Orangepi5-plus_bookworm_legacy_5.10.160_minimal and Armbian_24.2.4_Orangepi5-plus_jammy_vendor_6.1.43_kde-neon-amazingfated_desktop - the server version kernel panics, the desktop version freezes.

so, I tried it again with the kernel 6.1.43 and with the instructions from the howto. That resulted in the scrambled picture when opening kodi. (see above post) Then I built mpp, rga, ffmpeg_rockchip and kodi new. After a restart I could not open kodi as it complained about the missing dbdev module. Then I build drm-package and the mesa driver again. Then kodi opened again only to give the following errors when opening a movie: 2024-05-06 09:43:53.882 T:6596 info <general>: Creating InputStream 2024-05-06 09:43:53.916 T:6596 info <general>: Creating Demuxer 2024-05-06 09:43:53.990 T:6596 info <general>: Opening stream: 0 source: 256 2024-05-06 09:43:53.990 T:6596 info <general>: Creating video codec with codec id: 173 2024-05-06 09:43:53.990 T:6596 info <general>: CDVDVideoCodecDRMPRIME::Open - using decoder Rockchip MPP (Media Process Platform) HEVC decoder 2024-05-06 09:43:53.991 T:6596 info <general>: Creating video thread 2024-05-06 09:43:53.991 T:6600 info <general>: running thread: video_thread 2024-05-06 09:43:53.992 T:6596 info <general>: Opening stream: 1 source: 256 2024-05-06 09:43:53.992 T:6596 info <general>: Finding audio codec for: 86060 2024-05-06 09:43:53.992 T:6596 info <general>: CDVDAudioCodecFFmpeg::Open() Successful opened audio decoder truehd 2024-05-06 09:43:53.992 T:6596 info <general>: OpenStream: Allowing max Out-Of-Sync Value of 10 ms 2024-05-06 09:43:53.992 T:6596 info <general>: Creating audio thread 2024-05-06 09:43:53.992 T:6601 info <general>: running thread: CVideoPlayerAudio::Process() 2024-05-06 09:43:53.992 T:6596 info <general>: Opening stream: 9 source: 256 2024-05-06 09:43:54.003 T:6601 info <general>: Creating audio stream (codec id: 86060, channels: 8, sample rate: 48000, no pass-through) 2024-05-06 09:43:54.032 T:1329 error <general>: CEGLImage::SupportsFormat - format not supported: YU10 2024-05-06 09:43:54.033 T:1329 info <general>: GLES: Selecting single pass rendering 2024-05-06 09:43:54.033 T:1329 info <general>: GLES: Selecting YUV 2 RGB shader 2024-05-06 09:43:54.033 T:1329 error <general>: CBaseRenderer::GetShaderFormat - unsupported format 179 2024-05-06 09:43:54.033 T:1329 error <general>: GLES: BaseYUV2RGBGLSLShader - unsupported format none 2024-05-06 09:43:54.034 T:1674 info <general>: Skipped 1 duplicate messages.. So this means, that the original howto's for Rock 5b do not work anymore. And I did not find any working or reproducible collection of steps needed to get kodi reliably working with hw acceleration. This is quite a nightmare. I have this thing for over a year now and i am not able to use it.

Hi, uptime more 5 days with my pattern test and ebin-dev's file for voltage change, not crash. now i use helios64 on normal condition to see if better than before for information my pattern test never pass on my helios64 with ondemand gov and 408-1800 freqs since i have it Keep in touch root@helios64:~# uptime 10:06:08 up 5 days, 40 min, 2 users, load average: 1.94, 2.49, 2.65 root@helios64:~# uname -a Linux helios64 6.6.29-current-rockchip64 #1 SMP PREEMPT Sat Apr 27 15:11:44 UTC 2024 aarch64 GNU/Linux helios64@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 root@helios64:~# cat /etc/default/cpufrequtils ENABLE=true MIN_SPEED=408000 MAX_SPEED=1800000 GOVERNOR=ondemand

Hello, I hope someone might help me on this. Is anyone here using the ENC28J60 Ethernet port on an Orange Pi Zero 2W or Orange Pi Zero 3? If so, can you please share the file .dts (or .dtbo) that is working for you? I've generated a .dtbo using the file in https://github.com/armbian/sunxi-DT-overlays/blob/master/examples/spi-enc28j60.dts, with: dtc -I dts -O dtb -o /boot/overlay-user/spi-enc28j60.dtbo spi-enc28j60.dts but still it doesn't work. It says "chip not found". I'm using the same cable pinout as in my Raspberry Pi Zero 2W and it works successfully, but not in the Orange Pi Zero 2W. Any idea?

Hello, I have recently setup Armbian on my Orange Pi Zero 2W for a project I am working on. Everything works great so far but one thing I have noticed is that permissions feel much reduced to my user account. I require sudo to do basically everything from create a file in the home folder to use apt. This feels very different from the feel of the Raspbian install on like a Raspberry Pi. Is there any way I can change the user permissions so I won't have to use sudo for everything? Its been a bigger problem for a project I'm using Clion for where files are synced between my laptop to the pi using SFTP and Rsync but I constantly get errors about unable to create or transfer files and folders due to permission errors causing me to need to delete the remote changes and manually copy them over with sudo. I understand that doing this compromises security and is riskier but I'm fine with that. Any and all help would be great

Please tell me how to edit your message. Thank you.

@jock i have read some comment for issue RK3229 suddenly turn off HDMI when burn image to flash, so luckyly when i try an old armbian that will sussesful with no problem. i read while the 8x page with no answear so that if anyone have the same problem can solve this issue. 1st: Armbian_24.2.5_Rk322x-box_bookworm_current_6.6.22_xfce_desktop.img.xz --> HDMI suddenly turn off 2nd : Armbian_21.02.1_Rk322x-box_buster_current_5.10.12_minimal.img.xz --> sussesful

I may have found the culprit after monitoring htop. "vnstat -n" process eats up CPU cycles, sometimes reaching up to "6+" load-average (even if this OrangePi is quad-core equipped) This only happens intermittently and I can't seem to find the pattern. Sharing my observations here: Only affects Linux 6.6.16-current-sunxi and higher (such as edge), legacy firmware is not affected (stable for more than a week) Installing Pihole with cloudflared DoH package seems to trigger high CPU usage of vnstat Reboot fixes it (or a power cycle) Having PiHole with dnscrypt-proxy does not trigger the issue (so far, this test instance is already at the 16-hr mark, will keep on updating uptime) Since it was stable overnight I now have two instances with this configuration, hoping for the best! Not sure if helpful, but this is all that I have for now. Thanks!

hey guys! nice to meet you all! my goal is to get TV-OUT working on Zero 2W (posting here instead of Zero 2W topic since this one is more live ). I've seen in this discussion that @VioletGiraffe have the same goal as well. I'm trying to modify those 6.1 (H2 H3 H5) patches for 6.6 || 6.7. If someone is working on that as well, let's collaborate (actually I'm open for an extra donation if someone does that btw) and please share if there is some progress with that. Many thanks in advance! One question to clarify: - as I understand there is no code in 6.8 that fix TV-OUT issue, right?

I reinstalled armbian, uname -r gets me: 6.6.16-current-meson64 with reinstalled I mean I downloaded the image from the armbian website

I'll see if I can get those release imgs updated to something more recent and inquire about the breakage.

Damn. That's not good. Sorry to hear that.

Any Ideas how I can get my installation to update? Edit: I just rebooted the system one more time after the autoreboot and now I only get some errors and pxelinux is booting... Guess my installation just is f'ed and neets full repair (aka new flashing with SD-Card and copying to eMMC) Guess this topic can be also closed...

Hmm. It appears ur still on 6.6.16-current-meson64 which does not include the fix.

Hello! I tried update the kernel vai armbian-config --> System --> Other. There was only one option available, which I chose. System installed something, rebooted. Problem still persists so. What am I missing? https://paste.armbian.com/zojomiciwu Thanks in advance - cad435

This has already been fixed upstream and backported to 6.6.y LTS. https://lore.kernel.org/lkml/20240322164525.2617508-1-christianshewitt@gmail.com/ My suggestion is to update the kernel. If you don't wanna update you may just be able to blacklist the driver, which was what I did until it was fixed. It comes down to what is required by Klipper in your case.