nokirunner

I don't know, I tend not to trust these measures, my soc also measured 80 - 90 degrees, with no particular operation except a desktop started. yet when I touched the heatsink it seemed quite warm. Could it be that they are not degrees celsius?

@fabiobassa Yes I understand the hint, cheaper devices, cheaper support etc .. but what I don't understand, their modules being based on the linux kernel anyway, why don't they have a native release of the drivers sources? They don't violate the Linux kernel GPL license ?? I noticed this also happens on other arm phones, due to their blob drivers, which then remain abandoned to old kernels which are difficult to update.. I also noticed that this happened more frequently in the past years .. now they tend to release drivers sources more easily to have them natively included in the linux kernel main line, maybe they have realized that it is more convenient for general maintenance, and to stay up to date with kernels with security and more.

Hey @jock, hey @fabiobassa, what's up? just from time to time come to this topic to see how is evolving all, never mind that I find some nice surprises and I miss them. Actually to be honest, I cut short and betrayed the case with a 4 gb rasberry-pi 4 which for my jobs with the diy CNC that I built myself, and with the 3d printer with octoprint, is optimal, I admit that it is also convenient for browsing and since the videos on youtube run in full hd without problems, and now that they have developed the Vulkan 3D drivers it's even better .. i noticed the big difference between armbian and raspberry pi os where the whole community is concentrated to make the software run better on those few existing hardware versions and I must say that in my opinion it is a good technique ... having all the same hardware it is easier to find bugs, to be fixed and there is a greater e solid stability between hardware and software. While armbian focuses on trying to get the same os to work on the most varied arm-based hardware in existence, and it's a nice challenge that doesn't always succeed. However, I admit that I enjoyed chatting on this channel, seeing the progress, and in a sense there is a small niche that has focused on these specific devices, which are actually a big deal, too bad the hardware and drivers creators are a bit stupid (or conveniently stupid for some obscure reason), they didn't directly decide to release good openosource drivers and made everything more complicated, the community would take care to keep them working well .. Already, I just wanted to comment with my opinions based on the accumulated experience, and now I come here mostly for hobbies and fun, I would like to have more skills to make some contribution greater than just as a beta tester, or one who goes to try the luck in making things work, well I'd like to, but unfortunately it's not in my ability.

well, the period of despair has passed, now I'm ready to throw myself back into the fray to experiment, I'm curious how firefox behaves, I'm writing this comment while the image is written on the sdcard .. ..then no LIMA, no 3D, or can we recover the 3D acceleration from the old owners drivers? ... I suspect no, no 3d at all. funny, that by blacklisting LIMA, you get a bit of decent 2D, it is very clear then, that the 3D drivers are going to use something wrong ... despite having noticed that LIMA's 3D worked .., when I come to the end to understand something I will be very happy.

maybe, but anyway I gave up, I tried for a couple of days to "try my luck by experimenting", but I couldn't get much, the level of skills needed are well beyond my abilities

guys, I had an idea, if we can roughly identify in a technical way the problem that this rk322x rockchip driver have whether it is the dri rockchip kernel or mesa LIMA, we could open a bugreport on the LIMA mesa git issues or on the dri (lima) kernel issues or both, maybe we are lucky and they already know how to fix it.

well, lately I got excited with the mainline kernel for more reasons, I thought that with a bit of cunning and a few tricks I would be able to fit both accelerations by force ... well it's obvious that it's not as simple as I thought .. I did this also because I see the 4.4 kernel as a dead end, we might as well concentrate the forces with the new ones, also because many improvements are still in sight, both on the gpu side and in other functions in general. (hoping these problems with the rk322x socs will be solved)

this is where the big players start playing and everything becomes so dark that I can only catch small shreds of light. but I try to ask a question: why when we force "modesetting" on card1 we have 2D acceleration but the 3D acceleration disappears? or rather, it is channeled to the cpu through softrender llvmpipe ... wouldn't it be the easiest way to try change the code by telling it to use the 3d acceleration libraries in these conditions? do you think it is possible to do such a thing?

@Gabriel Vinicius did you then do a test with the ir and this new image? it works??

Yes, but obviously something goes wrong with glamoregl, because not only is there no 2d acceleration, but everything becomes so slow that it is almost not usable. In my opinion it is as if channels some registers that should use hardware of any kind for the correct use, but here something is not going well, which worsens the situation even compared to a context without acceleration at all. That's what I wanted to highlight. all obviously refers to my hardware based on soc rk322x exsperience.

with this configuration I get a decent "2d acceleration" on card0 there is no trace of glamoregl, and there is no trace of 3d acceleration, in fact MESA tells me that it is in softrender on cpu via llvmpipe I also did a test putting modesetting in place of fbdev and glamoregl immediately comes back, 3d acceleration is activated on MALI, but there is a terribly slow 2D. At this point I give up. it is evident there is something broken somewhere. I would be curious to know if the same thing happens on other rk322x Major sister socs or is it just a problem of these rk322x socs

Xorg driver as "rockchip" Xorg.0_driver_as_rockchip.log Xorg driver as "modesetting" Xorg.0_driver_as_modesetting.log my mistake, I don't know where I saw "2020" ,perhaps searching and scrolling through this chronology I got confused with the latest HDMI commit https://github.com/torvalds/linux/commits/master/drivers/gpu/drm/rockchip what is the command to see the devices tree like the one you attached?

I tried this on my rk232x based device and i suspect it doesn't work. If I put "modesetting" as driver then it recognizes rockchip and vdpau-rockchip, but with the method described by you I don't get the same result, it tells me that the driver rockchip is not found and starts the same through modesetting ... I suspect that for the rk322x it does not work ... and I also suspect that it is for this reason that glamoregl even if it seems to start does not work as 2d acceleration ... this driver dri is not optimized at all (or partially brocken) for rk322x at least the 5.6 kernel, maybe the latest versions like the upcoming kernel 5.9 already contain these fixes. edit : in fact there seems to be no trace of rk3228 registers. https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/rockchip/rockchip_vop_reg.h (Visual Output Processor) is the Display Controller for the Rockchip series of SoCs which transfers the image data from a video memory buffer to an external LCD interface look only other rockchip socs : edit2: better investingating maybe 14 june 2020 is added a basic hdmi support for rk3228 ... (is valid also for rk3229 ?) https://github.com/torvalds/linux/commit/53ffa1ee8de2cdfb0fcbef798486ba9c7f9316fd#diff-0f18fb301f41340ce62f8d1b44e1247e evidenced code here:

@jockMine are obviously just guesses of reasoning, based on the information I gathered, but I couldn't test . You will probably be right, being much more grounded and experienced. Only for fun I like to test things to verify, maybe you never know, with a bit of (culo) some miracle happens. I checked the drm kernel folder, there is only the module LIMA, why is not the there rockchip module also? one thing is certain and makes me suspect that something has gone wrong, something is wrong with the monitor recognition, only one resolution comes out, and the refresh management marks "zero" (showing that it is broken), perhaps, and it's just a guess, this module is not compiled.

@jockwell, thanks for the explanations. the fact is that there is certainly something badly designed right now. we hope for notable improvements in the future. i managed to compile and install the latest mesa with the latest LIMA driver updates, but nothing has changed. the last test I would like to do is to install the dri module for the kernel with the latest patches, but I would not want to recompile the whole kernel, but only the module I need, I wonder if I can do it while using an older kernel. ... this: https://github.com/torvalds/linux/commits/master/drivers/gpu/drm/lima but also this, which I understand is the display driver, and takes care of interfacing with the hdmi manages the resolutions of the monitors and so on .. (which apparently, according to the LIMA documentation, must be started with xorg together with LIMA, but reading you and how you configured xorg, it seems to me that you have totally ignored the existence of this other "display driver" and that must be "mixed" with the LIMA driver) https://github.com/torvalds/linux/commits/master/drivers/gpu/drm/rockchip according to the LIMA documentation, the two drivers must be combined in this way: (pay particular attention to that MatchDriver "display DRM driver" ... which must be replaced with "rockchip" or other drivers according to the various brands of the various socs) Section "ServerFlags" Option "AutoAddGPU" "off" Option "Debug" "dmabuf_capable" EndSection Section "OutputClass" Identifier "Lima" MatchDriver "<display DRM driver>" Driver "modesetting" Option "PrimaryGPU" "true" EndSection

i'm not an expert, but i just try a guess, maybe the IR system, in these tvbox, depends from box to box, you should check the dts tree (the original one from your tvbox) and see how it's configured inside, then i don't know how the kernel is put if there is or isn't the right driver.

@jock @fabiobassa I was able to compile the module armsoc, but unfortunately i can't start it, probably something is missing, i compiled it with everything by default .. here's what the xorg log result is, i get it find the screen but it's not usable, i tried to configure xorg with a section screen with custom resolutions, but I can't go further, I always get the same error. here the log:

LOL I didn't associate, stupid me, I'm distracted. i will try, but i don't know if i will succeed, the last time i compiled a kernel, those rare times i did it was over ten years ago

@jock here I am again, I have some interesting information that I discovered doing experiments. if you remember, some time ago I did some experiments with xorg and acceleration media files on legacy kernels I had "found" that xorg worked with both the "modesetting" and "armsoc" driver but found that armsoc was definitely much slower than modesetting https://forum.armbian.com/topic/12656-csc-armbian-for-rk322x-tv-boxes/?do=findComment&comment=104900 so I wanted to experiment with the 5.6 kernel as well.... here's what i found: on legacy kernel, I found that armsoc and libmali (specifically libmali-rk-utgard-400-r7p0-x11_1.7-1_armhf.deb) conflict, in fact uninstalling this library, and starting xorg with armsoc driver, x11 goes fast. obviously, however, the functionality of opengles is lost. but it does not matter. I wanted to check. I found relevant information that could also be functional on kernel 5.6. investigating I saw that an armsoc driver was available on the apt repositories, I tried to install it but nothing, x11 did not start. So i tried to install xserver-xorg-video-armsoc_1.4-2_armhf.deb of the legacy kernel media pack and it works! x11 starts .. well partially, we lost the window manager, the background and the desktop icons (all black) but we see that the acceleration is active and all there !, so I tried to mix the LIMA drivers with armsoc and it seems to work, or at least glxinfo tells me that the opengl mali 400 acceleration is present. Section "ServerFlags" Option "AutoAddGPU" "off" EndSection Section "Device" Identifier "armsoc" Driver "armsoc" EndSection Section "OutputClass" Identifier "Lima" MatchDriver "armsoc" Driver "modesetting" Option "PrimaryGPU" "true" EndSection now it is evident that the armsoc driver does not work because I assume it is compiled for the legacy kernel I also searched the net to understand why this driver works, and the one in the repository doesn't. and that's because this version is compatible with rockchip soc! https://github.com/paolosabatino/xf86-video-armsoc Now I assume that by compiling these armsoc drivers for kernel 5.6 there is a good chance it will work correctly, and can be mixed with the LIMA 3D driver. my limitation from trying at the moment, is that I don't know how to compile these, I've never done a cross compilation, and don't know (currently) how to do it. And I don't even know how to create installable .deb files from a build (my other current limitation)

yes i had seen, yesterday i had peeked a little bit all bugtrackers, but i still don't believe it's a 3D side , problem issue, it's a bug in buffering kernel DRI driver badly managed somehow, i don't know if you have noticed, but the slowness is in fits and starts (a singhiozzo) as if it were speeded up, and then the buffering cycle stops for some reason, especially noticeable when drag a window, it is just noticeable that it is something derived from a poorly done mechanism, sometimes slow so much that if we try to click some icon, the refresh is so poor that it fails to operate the function. I am even more convinced of this because by going to see the patches they worked on the management of the hdmi https://github.com/torvalds/linux/commits/master/drivers/gpu/drm/rockchip and there are other patches under review that may be coming: (dw-hdmi bridging) https://patchwork.freedesktop.org/project/dri-devel/list/?submitter=15894 well, at least hopefully I'm right .. the "2D" just that there is glamor, should be accelerated without problems by the LIMA driver, instead it is totally broken (singhiozzo). while windows that contain 3D elements is accelerated working fine. The rockchip custom "card" should only manage the buffering and the hdmi functions, and in any case it is so slow , that you can see that it is not merely a question of poor performance, it is as if the 2D rastering functions were managed by "cpu" functions , as if the gpu drivers totally missing (reminds me of old windows xp machines when drivers are not installed yet) or thinking about it better, managed by llvmpipe 3D emulation via cpu ... just like when we put "card1" ... that 2D is accelerated to a lot, but 3D is managed by llvmpipe via cpu however we are here to try hypothesize the problem, when the best thing to do would be to make the problem known with a bug report, I would do it, but I have not the faintest idea how to describe the problem at the technical level...

@jock From what I have investigated, I don't think it's a question of SOC performance, I think the driver especially the kernel side dri rockchip is badly built at some point. It should take care of the management of the hdmi and of the video buffering and little more and it is evident that it is poorly managed, so much so that when we put card1 instead of card0 it becomes 2D fast but the hdmi loses the management of the monitor resolutions, and even in the "very slow" mode with card0 the resolution management of the monitor works only to a limited extent (many resolutions are missing) it may also be that in the latest kernel these problems have already been solved, I noticed that these drivers, both on the kernel side and on the mesa are heavy developed. Looking at the git of the rockchip dri kernel you see there are a lot of changes in the last few months, i would be curious to see if the upcoming kernel 5.9 has fixed these known problems.

@jock right now i'm trying to understand each other better, apparently, lima is just "the rederer" every producer then has his own drivers or something like that .. in our case it should be rockchip ... i'm just investigating right now https://gitlab.freedesktop.org/lima/web above in the wiki : edit: the display drivers it could be these: https://github.com/rockchip-linux/libmali which appears to have been updated to work with mesa 20.1.5 APIs... which as far as I understand are the blobs updated to work with the new mesa

Guys, I have something new, I don't know if it's only valid on my device or if it concerns others. With the Armbian image 20.08.0 - Ubuntu Focal Desktop - Mainline kernel 5.6.19 which contains the LIMA open source video drivers I found that the default configuration the acceleration does not work. these socs have two videocard card0 and card1, on my xorg configuration card0 was set, it worked in the sense that the desktop started but the video acceleration was bad. I changed this setting to card1 and voilà the acceleration is activated as it should. the file to edit is this: /etc/X11/xorg.conf.d/40-serverflags.conf change card0 with card1 Section "ServerFlags" Option "AutoAddGPU" "off" EndSection Section "Device" Identifier "meson" Driver "modesetting" Option "kmsdev" "/dev/dri/card1" #card1 now is good EndSection My device is a scishion-v88 I don't know if it is a problem that only concerned my device or is it a much more general problem, in the meantime I have reported it, in case other devices are afflicted by the same problem with the LIMA drivers. @jock I tried to activate the wifi ssv6x5x drivers on the 5.6 kernel but I couldn't, are the new drivers working on the legacy kernel also compatible with the 5.6 kernel?

thanks mate, this makes life so much easier

@jockI would like to ask you something, are the images updated with all recent fixes? I mean drivers for wifi, 3d acceleration, etc ..