schwar3kat
-
Posts
241 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by schwar3kat
-
-
9 hours ago, tiziano000 said:
any suggestions?
Devices not installed on the board are generally enabled using device tree overlays.
I don't have your board, but I did this some time ago with an Orange Pi Zero.
TutorialI used UART1 and PA7
From the tutorial:
Add two lines to /boot/armbianEnv.txt to tell the Orange Pi Zero to use PA7 for PPS and uart1 for GPS NMEA messages
overlays=uart1 pps-gpio
param_pps_pin=PA7
You may not need to edit the file manually, you can add overlays from armbian-config, System, Hardware (you can see which overlays are available for your device).
Overlays may have different names for different boards and families.
If you can't find one for your board, it may be that nobody has created one yet. -
What board is it?
If you can find a similar board, that would be a good starting point otherwise this is not a simple undertaking.
It's not just the CPU, it's the board and integrated devices.
These must be defined in a device tree.
Each of the devices has to have an appropriate driver compiled into the kernel.
-
8 hours ago, martivo said:
Should this also work with the 5.10.160-legacy-rk35xx kernel?
Probably. -
@InfernalWolf666 As you have provided no logs, I can't see what Armbian image you have used.
Your board is very new and it is likely that things are still missing from the upstream Kernel and the legacy build .
In such cases the legacy build is often more complete than the current build.
Those are device tree overlay files that you have found, however they are from another source and another board and are not relevant.
Hardware devices that are not included by default on the board are usually not included in the default device tree.
They would normally be added as device tree overlays.
They are not drivers, they just map the hardware addresses so that the devices can be addressed by software.
Drivers are generally included in the Kernel if they exist in the mainline Kernel or have been added as patches into the Armbian build.
Device tree overlays can be applied through armbian-config, System, Hardware. (possibly not relevant but included for your understanding)
Screenshots of armbian-config from a legacy build:
(From a console type armbian-config)
There are a number of overlays available for Opi5+ but I don't see anything related to your issue use the arrow keys to scroll.
I suspect that your device may not currently be supported by the build that you are using.
EDIT:According to the download page, you need to enable orangepi-5-ap6275p overlay from Hardware menu of armbian-config and reboot.
-
I don't see this load to early issue on any of my boards, perhaps it is specific to your board.
Please note that cpufrequtils is deprecated and has a number of issues with various boards that are unlikely to be addressed.
(the other issue with cpufrequtils not being enabled by default for all boards has been addressed). -
Good point about
18 hours ago, rpardini said:big.little clusters
I wouldn't have noticed, because personally, I haven't seen a need to use this armbian-config functionality but people are apparently using it so what do I know?
The main issue, as I understand it, is that an armbian-config function doesn't work as it could reasonably be expected to work.
I will mull over and test an idea and perhaps I can come up with a simple way to control expectations based on the ENABLED state.
Edit: AR-1883 -
On 10/3/2023 at 1:31 AM, 0ka said:
it doesn't apply until i manually change ENABLE to true in /etc/default/cpufrequtils
I can confirm that in current images that I examined, in /etc/default/cpufrequtils, ENABLE is set to false.
In older images that I examined ENABLE was set to true.
This affects all boards. Without ENABLE being set, the armbian-config CPU speed governor settings simply don't work.
Normally when cpufrequtils is installed, and a CPU driver exists, then the installer sets ENABLE to true. But cpufrequtils is pre-installed by Armbian build.
Before logging a Jira issue I thought that I should investigate further to try and understand what had changed led me to
this change tagged as [HIGHLY CONTENTIOUS CHANGE].
@rpardini do you have any insight into this change or advice? -
What are you plugging into the USB3 ports? Is your power supply capable of supplying enough current? If you measure USB3 inline voltage does it drop when you plug in the device?
I am running the same Kernel version on OPi 5+ and my USB3 ports work with externally powered HDD's.
Kernel and firmware upgrades disabled on mine. -
Because you are not using Armbian build for your u-boot, we can't know what might be wrong or missing.
Armbian build documentation
Have you tried to dd your entire SD card?
You might need to shrink your image if not copying to an identical or larger SD card.
Old instructions still work -
I think that something like this should work (I've done similar in the past, but I'm working from memory, so I may have missed something):
Flash the new SD card with the same OS image used for the original card (a similar image may also work if u-boot isn't too different).
Boot the card and allow it to expand the partition (or expand the partition using gparted or similar to about 80-90% of the SD card).
Back up /etc/fstab from the new SD card to a safe location (it's a good idea to backup the /boot directory as well).
Mount the new SD card RW on a Linux computer. You will need to be root or sudo su for most of the following.
Delete all directories and files except for the /boot directory and it's contents from the new SD card.
The new SD card root file system should now only contain /boot and it's contents.
Rename /boot to /boot-backupCopy all files retaining permissions and attributes including /boot directory from the original SD card to the new SD card.
https://www.makeuseof.com/preserve-file-permissions-in-linux-while-copying-them/
Replace /etc/fstab on the new card with the fstab that you backed up.
Or edit the /etc/fstab on the new SD card '/' to match the UUID in your backed up fstab (this method only required if your original has extra non standard fstab entries).
Change the UUID in /boot/armbianEnv.txt to match the entry in /boot-backup/armbianEnv.txt. (something like rootdev=UUID=f0920bd6-7fea-42cb-a9cd-3db938a68382). It should also match the '/' UUID in /etc/fstab.
Good luck and let us know how it goes. -
Just started - and I can see it configured in the Makefile. "obj-$(CONFIG_BLK_DEV_RBD) += rbd.o"
Halfway through - and it's built the module object. "rdb.o"
Completed - and I can see the file "rdb.o" in the image in "/lib/modules/5.10.160-rk35xx/kernel/drivers/block" which is correct. (Do you have this in your image?).
/boot/config-5.10.160-legacy-rk35xx contains "CONFIG_BLK_DEV_RBD=m" as expected.
Looks okay as far as i understand, but I'm no expert. Did you save your new configuration after selection and exits?
Your second build on the same clone should be faster because of caching. -
I don't have your board, so I can't test, and I'm not familiar with Rados block device, but I will build it and see if I can see the module.
-
In the screenshot, you are not root, so all modprobe commands require sudo privileges.
Try:
sudo modprobe rbd -
@Werner - Are there no more Armbian developers meeting videos? I was rather hoping that they might reappear. Maybe I missed some announcement.
I see Developers Meetup in the calendar. I haven't been able to attend, but I had been watching these videos to catch up.
I see a mention of Jitsi in the calendar event, but no link or instructions how to join the event if I could.
I thought maybe the video might be attached to the Jitsi event (I don't know if Jitsi can do this).
-
14 hours ago, Nicholay Riviera said:
I just didn't know if I could pull down a more recent build
I used https://mirror.yandex.ru/mirrors/armbian/archive/orangepi5-plus/archive/Armbian_23.5.4_Orangepi5-plus_jammy_legacy_5.10.160_xfce_desktop.img.xz but this is a different board. I guess any legacy Jammy 5.10.x should work.
Look here for something suitable https://mirror.yandex.ru/mirrors/armbian/archive/orangepi5/archive/Maybe:
https://mirror.yandex.ru/mirrors/armbian/archive/orangepi5/archive/Armbian_22.11.3_Orangepi5_jammy_legacy_5.10.110_xfce_desktop.img.xz
You can't use the official Kodi ppa version of Kodi. It doesn't include k35xx acceleration or a working widevine cdm for arm64.You must use amazingfate's ppa for Kodi and not the Kodi official ppa.
When updating or installing the inputstream.adaptive plugin from that ppa or from any Kodi repository, it will prompt you to update widevine. cdm, The widevine cdm update that is installed doesn't currently work with arm64 Linux. At the bottom of my notes below, you can follow how to manually copy the right one, assuming that you have it installed in amazingfate's Chromium.
If you have the wrong Kodi installed then remove it and remove the official ppa.
My notes are a couple of months old, but if my notes are correct these are the steps to get Chromium widevine cdm and Kodi installed
(use at your own risk) Good Luck:sudo add-apt-repository ppa:liujianfeng1994/panfork-mesa
sudo add-apt-repository ppa:liujianfeng1994/rockchip-multimedia
sudo apt update
sudo apt full-upgrade
sudo apt install libwidevinecdm
I might specifically have installed or reinstalled Chromium, but I don't have it in my notes. It may have done it automatically with the upgrade.
Some DRM streamers check the Chromium user agent on arm64 and won't work unless they find a ChromeOs user agent.
Create a launcher for DRM-Chromium with the correct user agent for widevine (or just launch it like this from the command line):
chromium-browser --user-agent="Mozilla/5.0 (X11; CrOS aarch64 15236.80.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.5414.125 Safari/537.36"Check widevine DRM works in Chromium with
https://bitmovin.com/demos/drm
sudo apt install ubuntu-desktop kodi
Start Kodi and install your plugins.
Try to run one DRM video and when it errors, do an apt install for inputstream.adaptive as recommended by the error message.
Install widevine cdm as prompted. This will create the directory structure for widevine and install the non-working version.Copy libwidevinecdm.so from /lib/chromium-browser/WidevineCdm/_platform_specific/linux_arm64/ to /home/{username}/.kodi/cdm/
Restart Kodi.
-
16 hours ago, numetaler said:
and inputstream.adaptive anymore.
You can't use the official Kodi ppa version of Kodi. It doesn't include k35xx acceleration or a working widevine cdm for arm64.
Assuming that you are using amazingfate's ppa for Kodi and haven't updated Kodi from the Kodi official ppa, then updating or installing the inputstream.adaptive plugin from that ppa or from any Kodi repository will prompt you to update widevine. cdm, The widevine cdm update that is installed doesn't currently work with arm64 Linux. So most likely you have the wrong libwidevinecdm.so installed. At the bottom of my notes below, you can follow how to manually copy the right one, assuming that you have it installed in amazingfate's Chromium.
If you have the wrong Kodi installed then remove it and remove the official ppa.
If my notes are correct these are the steps to get Chromium widevine cdm and Kodi installed (use at your own risk):sudo add-apt-repository ppa:liujianfeng1994/panfork-mesa
sudo add-apt-repository ppa:liujianfeng1994/rockchip-multimedia
sudo apt update
sudo apt full-upgrade
sudo apt install libwidevinecdm
I might specifically have installed or reinstalled Chromium, but I don't have it in my notes. It may have done it automatically with the upgrade.
Some DRM streamers check the Chromium user agent on arm64 and won't work unless they find a ChromeOs user agent.
Create a launcher for DRM-Chromium with the correct user agent for widevine (or just launch it like this from the command line):
chromium-browser --user-agent="Mozilla/5.0 (X11; CrOS aarch64 15236.80.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.5414.125 Safari/537.36"Check widevine DRM works in Chromium with
https://bitmovin.com/demos/drm
sudo apt install ubuntu-desktop kodi
Start Kodi and install your plugins.
Try to run one DRM video and when it errors, do an apt install for inputstream.adaptive as recommended by the error message.
Install widevine cdm as prompted. This will create the directory structure for widevine and install the non-working version.
Copy libwidevinecdm.so from /lib/chromium-browser/WidevineCdm/_platform_specific/linux_arm64/ to /home/{username}/.kodi/cdm/
Restart Kodi.
If this doesn't work perhaps follow the thread where I had a similar issue:
A useful resource that explains the issues.
https://www.da.vidbuchanan.co.uk/blog/netflix-on-asahi.html -
19 hours ago, schwar3kat said:
Hopefully Kodi will also be a simple fix.
It turns out that the slyguy plugins for the NZ services replaced the widevinecdm.so with apparently the same version but it had a different size.
I replaced it and it now works. -
16 minutes ago, amazingfate said:
Thanks @amazingfate Yes that's a good blog.
I've got both services working on Chromium. They must be similar to Netflix.
They didn't like the user-agent and when I changed to the Chromebook user-agent, they worked.
Hopefully Kodi will also be a simple fix. -
24 minutes ago, amazingfate said:
can see wideviine is detected on website https://bitmovin.com/demos/drm
Thanks @amazingfate that demo video works on my Chromium. So it looks like it is not a Widevine issue.
I will do some more investigating. -
On 1/28/2023 at 3:49 PM, amazingfate said:
For rk3588
Hi @amazingfate
Does your ppa:liujianfeng1994/rockchip-multimedia repo widevinecdm still work?
I'm running Armbian 23.08.0 Jammy with Linux 5.10.160-rk35xx on Opi5+
I installed your rockchip-multimedia-config, and kodi kodi-inputstream-adaptive libnss3
I'm trying to get some NZ streaming services to work on Kodi, but inputstream.adaptive errors with 'Unable to load widevine shared library (/home/kschwar3/.kodi/cdm/libwidevinecdm.so)'. The libwidevinecdm.so file from your repo exists in that location.
The Chromium browser also fails on these streaming services. I tried reinstalling chromium-browser, libc-bin and libc6 from your repo. -
Orangepi zero plus
Images boot, network connection functions (iperf3). USB ports function.
Orangepi R1
Images boot, both ethernet ports and wifi function as expected (iperf3). -
18 hours ago, Igor said:
IMO lets wait a day then proceed with a proposed fix.
PR submitted.
-
Orangepi R1 Plus LTS (RK3328) - networking issue AR-1747.
Caused by one of the network interface logical names changing from eth0 to end0.
I can can submit a PR to fix this with a rename in /etc/udev/rules.d/70-rename-lan.rules which is already created from a hook in the board config file (to rename the other network interface). Already tested and works as expected on current and edge, Ubuntu and Debian.
Before I take this route, I'm just wondering if anyone knows a reason for this happening that could possibly lead to a better fix? I didn't find anything obvious in the PR's. -
- Orange Pi PC
- Pine64
Images boot (xfce_desktop), network connection functions (iperf3). USB ports function, HDMI video and audio work.
NanoPi R5S Armbian Image
in Rockchip
Posted
Are you logged in as root? Your overlay_prefix=rockchip in the built image, so the menu should be visible under System then Hardware and should show all rockchip dtbo's.
This board is a work in progress, so probably there is stuff missing and not working.
Look in /boot/dtb/overlay to find available overlays.
Drop the overlay_prefix and the .dtbo if you add them manually into armbianEnv.txt
Reboot to activate.
Those beginning with rockchip may work but I suspect that rockchip-RK3568B2 may be different there are no guarantees for a WIP board.
Perhaps the suppliers image has overlays that you could harvest.