JMCC
-
Posts
941 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Everything posted by JMCC
-
No. I think it could be because of some pre-installed libs in your system. I always compile in a clean buster chroot , and everything goes smoothly, just copying & pasting the commands I put on the README.md. Well, nothing special. Put the patches in "userpatches/kernel/rockchip64-legacy". Compile with "./compile.sh CREATE_PATCHES=yes", so it will stop after applying the patches and you can see if they worked or failed. If they fail, look at the log in "output/debug/compilation.log", and see what is the problem.
-
Ha, you are more polite than me, and wait for others to check the PR.
-
@balbes150 This commit takes care of the issue. I built and tested a xfce-buster image, and everything seems OK. I also added the session selector to LightDM greeter, so people can choose Kodi or any other desktop of their choice.
-
I used master. From what you say, it looks like we need to put some "Provides: armbian-xxx-desktop" field in the package control files, to ensure backwards compatibility. I will look into it.
-
@TheGuv Good news, I made some progress. I just got DP-out to work on the NanoPC T4. Now, I'll have to make a clean patch to incorporate the fix into the legacy kernel, and after that I can start to test and debug those errors you reported.
-
The problem with the nand-sata-install is that, if your SD card or reader is failing, they will replicate the errors. In this particular case, I would recommend booting the board and then flashing the image on the fly from the web, like this: wget https://redirect.armbian.com/rock64/Buster_legacy_desktop -O - | xzcat | dd of=/dev/mmcblk0 bs=1M Replacing /dev/mmcblk0 with the device node corresponding to your emmc.
-
Sure. Just follow the instructions at the README.md. Set up an Armbian Buster image (or chroot) with enough free space on your Rockpi, and then compiling is just a copy-paste from the instructions -- well, I probably forgot to mention that you need to install ccache, IIRC. Compilation takes about an hour the first time, and shorter in subsequent runs. If you get the patches to work, just make a PR and I will incorporate it.
-
@balbes150 I just built a M1 buster-legacy-desktop image, burned to SD, installed media-buster-legacy-rk3328 and played a 160Mbps Jellyfin HEVC 4K sample. Everything went smooth and without errors here
-
First: Can you send a screenshot of the option? Second: I don't know if you said what board are you using. In any case, can you also post the output of "sudo armbianmonitor -u" Third, I found these two LibreELEC kernel patches in master branch to be related to YCbCr: projects/Rockchip/patches/linux/default/linux-0021-drm-from-list.patch projects/Rockchip/patches/linux/default/linux-1001-drm-rockchip.patch In the 9.2 branch, there is this one: projects/Rockchip/patches/linux/rockchip-4.4/linux-0001-rockchip.patch This is just from a "grep -rli ycbcr" on the sources. It will need further investigation.
-
Last time I tried, it was working fine, but it was two weeks ago. Let me test when I get home.
-
SQL database errors, weird APT errors... It looks to me like a faulty storage media. Try with some new good quality SD card, like Sandisk Ultra. [EDIT]: IIRC, Rock64 has many hardware problems, that is the reason why we don't support it anymore. That can be the cause for the storage failures, probably a faulty SD card reader.
-
As I said above, there are some references to x11vnc on the logs you sent. You simply denied it, but I invite you to read them, x11vnc is there. That is the first problem that needs to be cleared out.
-
Yes, those patches are included in my repo. They only affect the headers, so are only meaningful during the compilation process, not on runtime. Well, the Armbian build script already does that for you, doesn't it? I'm ot sure what you mean with "getting the mainline kernel working". If what you mean is keeping up-to date the VPU patches, well, that is fairly well taken care of by the main RK kernel maintainers at Armbian. In any case, I think your best efforts can be focused on figuring out what are the bits that LibreELEC is using to switch the display to HDR mode. It can be some kodi patch, not necessarily a kernel modification. Or even more simple, some default kodi setting without any modification to the code. I would start there, exploring all the Kodi settings and see if you find something that can be changed to enable HDR.
-
Strange. Reinstall from scratch and post the error. ~/.kodi/temp/kodi.log
-
It shouldn't be like that. Can you post the full mpv output? And also, the output of cat /etc/mpv/mpv.conf
-
As I said, you can download the deb from the rockchip-linux github. The repo name is rk-rootfs-build, IIRC. Download the deb and install it The info about the sources for my packages are in the first post.
-
Rockchip-linux GitHub
-
Probably, but even more by looking at the Libreelec sources on GitHub. Documentation is minimal, but the sources are very intuitive. But, before that, you must read the docs about kodi compilation at the xbmc GitHub. -
Well, the framework can play HEVC 10-bit HDR content, but I don't know if it can switch the display to HDR, since I don't have such a display to test . The user cooperation as testers is necessary for that, I appreciate your getting involved with that. For the time being, can you send me a link to some HDR content that is causing playback trouble? So far, all the materials I tested worked fine, and I tried even 160 Mbps videos. Can you also make some other test? Simply do apt install librockchip-mpp1=1.4.0-1 And then try again to play your HDR content. [EDIT]: And please try all three available players: mpv in command line, Rockchip GST player, and Kodi.
-
Probably some Kernel patches being used in LibreELEC. I am not sure whether they updated to mainline yet, or are still using legacy, check that out too.
-
You are not providing enough information, like kernel flavor, or the output of "sudo armbianmonitor -u"
-
That's great! Well, modified packages are already on the process of upload and sync . Anyway, that will buy us some time until we get everything sorted out into rockchip64, and I can make some later update removing the "station-p1/station-m1" alternative.
-
I would like to bring something to attention. Right now, Station P1 and M1 legacy are being added as new kernel packages. I think ideally, the changes should be merged into some of the existing RK3399/Rockchip64 legacy kernels. We were aiming to reduce the multiplicity of RK kernels, but now we are introducing two new kernel packages, station-m1 and station-p1, one of each for a single device. Of course, I understand all the work involved on bringing up a new board, and how frustrating it is when new kernel configs or patches conflict with the existing one. But it is probably worth the effort to try and merge the changes for P1/M1 into Rockchip64, if that were possible. @piter75 @martinayotte @balbes150 @TonyMac32 @Igor What do you think?
-
The dependency is there to prevent it from being installed on Current/Dev. That would result in a broken desktop, due to Mali binaries replacing the Mesa libs, but the Mali kernel driver missing. I can add that other kernel as an alternative to the package dependencies. However, the ideal situation would be to merge the changes into some of the existing RK3399 kernels. But we can discuss this on a more appropriate thread. For the time being, I will just add that dependency, that will respond to the immediate need.
-
The meta-package depends on "linux-image-legacy-rockchip64 | linux-image-legacy-rk3399", but it doesn't specify any version. Source here What exactly is being replaced?