royk
-
Posts
261 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by royk
-
-
Post the UART log.
-
Did you also install the dtb that belongs to that kernel version?
You could check if the dtbo is compatible with your dtb with:
fdtoverlay -v -i /boot/dtb/current.dtb -o /tmp/test.dtb your-overlay.dtboIt would be better to compile the dts with armbian-add-overlay your-overlay.dts so it will automatically install it to /boot/overlay-user and added to your armbianEnv.txt. In this way it also won't get overwritten when you update the dtb. And of course like Werner said, check the debug serial console, you'll see much more detailed information.
And check if the symlinks are correctly linked to your kernel version.
ls -l /boot -
@Werner I agree that it's more convenient for everyone, but it took me some time to find out how and testing it in an image.
https://github.com/armbian/build/pull/8707/commits -
I had some difficulties to make my sata disk work and found out that the regulator had to be switched on. So here a dtbo and source to make it hopefully a bit easier for some others.
Easiest way to install is "sudo armbian-add-overlay orangepi-5-sata.dts" -
You could try to write the bootloader again to the SD-card, it seems like it's mixed up. Old with new.
not sure if the names are exactly like this but something like this:
cd /usr/lib/linux-u-boot-vendor-orangepi-5sudo dd if=u-boot-rockchip.bin of=/dev/sdx seek=64 conv=fsync
sudo sync
Or is ls -l /boot to see if the symlinks are correct.
The correct dtb in armbianEnv.txt?
The correct dtb for your current kernel version?
-
Maybe try another power adapter
Or add to /boot/armbiEnv.txt
extraargs=pcie_aspm=off nvme_core.default_ps_max_latency_us=0 pci=pcie_bus_safe
Otherwise you could try an image of Radxa first, if that works then it might be an issue with the dtb -
It's enabled by default. I believe that you have the wires swapped. There's a topic here about it where I also added a overlay to adjust what speed at which temperature.
I'm not sure if the overlay is still compatible, but since you've already found the source you can change it accordingly.
-
@Chris C In case going's suggestion doesn't help, the kernel should be compatible with the Rock 5b. I don't think that you need to install the dtb if you're already running Armbian with vendor kernel 6.1.x. So just install with "sudo apt install ./linux-image*.deb and the headers if you need them to compile drivers that you need for testing. To be sure if the install went correct you should look if the symlinks are all to the correct kernel. "ls -l /boot" otherwise "sudo ln -sf correct-vmlinuz Image" and so on
But adding a log is always helpful indeed. Send it after the nvme stopped working. -
@Chris C In the past there was a commit to fix sata issues with the Rock 5a, but this gave problems for nvme with Orange Pi. After that I also read some problems with nvme and the Rock 5B although I don't know if that was related.
https://forum.armbian.com/topic/46601-2484-latest-apt-upgrade-breaks-multiple-things-including-the-gnome-desktop/?do=findComment&comment=204829This is a bit older kernel with RT patch where I reverted that commit. If that works you could compile a "normal" kernel with that commit reverted.
https://drive.google.com/drive/folders/1r76sUsfG_F8pq0pkzzPgEyzqdRG6fGcz?usp=drive_link -
You could try to add one of these in armbianEnv.txt
extraargs=pci=pcie_gen2extraargs=nvme_core.io_timeout=4294967295
extraargs=nvme_core.default_ps_max_latency_us=0
-
Try to upload the old and new driver to an AI with you overlay included. Here it gives some suggestions for what you can try. The power sequence seems to be changed with the new driver and it might be too fast for your display. It suggests to put some parameters in the overlay to delay some parts, with higher chance with the first 3:
Under "dsi0_panel: panel@0 {"
prepare-delay-ms = <120>;
reset-delay-ms = <50>;
init-delay-ms = <150>;
enable-delay-ms = <50>;
disable-delay-ms = <50>;
unprepare-delay-ms = <120>; -
What does the following command show?
sudo fdtoverlay -v -i /sys/firmware/fdt -o /dev/null /path/to/your_overlay.dtbopanel-simple-dsi ... Expected bpc in {6,8} but got: 0
So possibly the default with the older kernel was by accident correct and now you should define it.And it seems that you use an overlay meant for the 5a on a 5c?
-
-
There is no overlay for that, but at your own risk you can edit the current overlay with some help of AI. But it will need the exact data of the data sheet. Just upload the data sheet, overlay and relevant dts/dtsi files (some of the includes and includes of the includes of rk3588/rk3588s) and ask to make an overlay for this display for Armbian.
-
Yes, when you out it in device tree mode: https://github.com/edk2-porting/edk2-rk3588?tab=readme-ov-file
-
This one I made for the Orange Pi 5, perhaps it works also on yours:
https://drive.google.com/drive/folders/1r76sUsfG_F8pq0pkzzPgEyzqdRG6fGcz
These for RK3399
https://drive.google.com/drive/folders/12VfNmKC30vxNzaNAk2EN5sHDfeCnnzYX
For the 5.10.160 kernel there's an already rt patched source from Orange Pi:
https://github.com/orangepi-xunlong/linux-orangepi/tree/orange-pi-5.10-rk35xx-rt
And when you apply an rt patch in Armbian, you should remove the local version patch. Armbian doesn't support local versions
-
@Jacob Olness The SD-card has priority, otherwise it would be difficult to recover.
-
The boot directory is on the nvme, so likely the btrfs file system is not supported by the bootloader.
Please put in your title that you've solved it
-
Maybe it's secure boot that's enabled in the bios why the unsigned module won't load?
-
@ArmBoy1988 I gave you already the answer if you want full hardware decoding support. Maybe you don't like it, but it's the only way. So a Flatpak won't work unless it's specifically built with rkmpp support. At this moment using the vendor kernel and build Kodi with FFmpeg with rkmpp support it the way to go.
-
@Gullik To me it sounds like a problem with Mesa. This happens with an x86 box that I have after a kernel update or something with a self compiled Mesa, then in the folder /usr/lib64 the files libGL.so.1, libGLESv2.so.2 and libEGL.so.1 will be relinked to the original files (with a higher version number). In that case relinking them solves the issue.
Enter "ls -ltr" in the lib64 folder to see the newest files under
-
While playing a video press the letter "O" to check if you're using hardware or software decoding. For hardware decoding you need to compile Kodi with FFmpeg that supports rkmmp hardware decoding and with gless. For 10 bit decoding you should run Kodi from GBM. You'll also need to change a setting in Kodi under video, set render method to "Direct to plane".
So install FFmpeg as described at:
https://github.com/nyanmisaka/ffmpeg-rockchip/wiki/Compilation
Build Kodi as described at:
https://github.com/xbmc/xbmc/blob/master/docs/README.Linux.md#41-configure-build
with as cmake command for example:
cmake ../kodi -DCMAKE_INSTALL_PREFIX=/usr/local -DCORE_PLATFORM_NAME="wayland gbm" -DAPP_RENDER_SYSTEM=gles
-
You could check the UUID with blkid
/dev/mmcblk0p1: UUID="b23e98d0-700e-4a09-88b6-95675ee524f5"
Then check if this is the same in /boot/armbianEnv.txt and /etc/fstab
-
@Mr.Tree Yes you can find the compiled one also on the OneDrive. If your application checks /sys/kernel/realtime you'll need a small patch from 6.12 which you can also find on the OneDrive. But it needs the following config:
- CRASH_DUMP [=y] && ARCH_SUPPORTS_CRASH_DUMP [=y] && KEXEC_CORE [=y]
- PROC_KCORE [=y] && PROC_FS [=y] && MMU [=y]
Temperature and fan control on OPI5
in Orange Pi 5
Posted
@JohnU Which kernel version of the desktop installation and which with the minimal?