jernej

Can you upload your fex file somewhere?

TV out driver supports only PAL and NTSC - codes 11 and 14. I'm pretty sure that codes are correct. At least they are listed as such in fex files.

Experimental mainline image (currently without support) will do just that... Legacy image unfortunately doesn't support this resolution because it is not standard. However, it can be added by patching a kernel. Which way do you want to go?

You mean waiting on Display Engine 2 and HDMI driver?

Ok, sorry for any confusion. No, you can't use Mali drivers with mainline YET, only chance is legacy kernel. @zador.blood.stained, simplefb also doesn't provide vsync event, although that does not prevent you to make it work, but there will be some tearing. @CNLohr, You just have to to have matching kernel driver to userspace library. In short, if user space library is r3p2 so it has to be kernel driver. There is easy way, go with r3p2 fbdev user space library and you don't have to recompile anything, or try to upgrade to newer version and then you have to find appropriate sources. Ones from ARM site doesn't work, because you need Allwinner hacks, so the easiest way is to find some Allwinner kernel code drop with appropriate version of Mali driver. And no, you can't compile userspace drivers, they are always in binary form, but at least they are kernel neutral, they connect only to Mali kernel driver.

First, are you trying to set up OGL ES on mainline kernel? That will not work yet, because SimpleFB driver doesn't support double buffering and everything else which is needed for Mali driver to work, so only real possibility is legacy kernel for now. I'm working on mainline driver which will fix that but it is not ready yet. Secondly, as you figured out, my OpenELEC fork uses r4p0 driver and there is even r6 Mali driver, but they have all same issue - license. Allwinner for some reason doesn't want to add proper license, which make redistribution legal grey area or even prevents it. That's why Armbian doesn't include any newer driver. Yes, X-less OGL ES context is possible, I'm using it on my OpenELEC fork. Trick is that you have to use fbdev version of Mali driver, which means that you have to find it and copy it by yourself, since Armbian supports only X version. And if you doing it, be aware that kernel driver version and userspace lib version have to match. For example, if you will copy Mali r4p0 from my OpenELEC fork, you will have to check my kernel (only big difference with Armbian kernel is Mali driver) and either patch Armbian kernel with same Mali source or compile driver out of tree (https://github.com/jernejsk/linux/tree/master/drivers/gpu/mali). Of course it is much easier just to use mali r3p2 fbdev version. As you can see, it is possible on legacy kernel, since I'm using it on my OpenELEC fork, but it is tedious to get it right.

You can't, yet. SimpleFB driver used for now doesn't support anything besides simple framebuffer. Actually, framebuffer is set up by U-Boot and Linux knows only where in memory is located and how big it is, that's all. Proper HDMI driver is in the work by me (already written, but not yet functional, I have to fix all the issues first), which will allow to do all that.

I'm glad that it works for you. I found them in kernel source code when I was working on OpenELEC fork and I needed to know as much as possible about display driver in order to optimize video rendering.

Well, unfortunately, T230 now also needs 4.7 kernel (same change as with RTL2832, check above). I'm not sure how to properly use older version of media_build. Probably you need to check out older version using git, and then manually specifying older driver package. Tell me if you want to go this way, but I can't promise you anything. Recompiling kernel should not be needed anymore, because all the needed changes were introduced after the solution in that thread was found. BTW, just curious, does the issue, present in 4.9 and newer kernels, affect all DVB dongles?

No, it is directly connected to power supply line. Which display do you have exactly? It is hard to suggest alternatives without knowing exact pinout.

Tough luck. 4.8 kernel should be usable for you just enough, because in this version USB support was introduced for H3, but I'm not sure how to make Armbian image with it. Probably the best way would be to do kernel bisect to pinpoint bad commit between 4.8 and 4.9, but this is tedious work and it should be done on HW supported by SW, e.g. LibreELEC on RPi or something similar. Once bad commit is found, it could be analyzed and fixed. Fix could be then included in Armbian.

Yes, of course you can compile media_build with older kernel, but you will get few driver less. MN88473 should be present with 3.4 kernel. I'm not sure if you can omit part of functionality. To be honest, I don't use DVB dongles, I only help to compile them. Still, media_build has nice warning, which tells you that it is not "production quality". This means that sometimes you need to have some kernel developing experiences to solve the issues. BTW, RTL2832 change to be dependand on 4.7 kernel was made only 2 months ago. Before it was dependand on 3.8 kernel which means you could easily compile it on RPi's 4.4 kernel, but still unable to compile it on 3.4 kernel.

I can tell you only that you can't make it work on 3.4.113 kernel. According to RPi log you provided, Astrometa stick uses RTL2832 chip, which is supported on media_build, but only if you have kernel 4.7 or newer. Here is the relevant info: https://git.linuxtv.org/media_build.git/tree/v4l/versions.txt#n4 It may be that in the past it was possible to build this driver with older backports, but this can be messy... If you are ok with shortcomings of mainline version of Armbian (including little or no official support), then I suggest you try it. At least you won't have to compile any drivers (relevant drivers are already included as modules and they should be auto loaded once you plug in your stick).

That is unfortunate. The only other solution I know is this: sudo su cd /sys/kernel/debug/dispdbg/ echo "switch" > command echo "disp" > name echo "0 5" > param echo "1" > start Actually, second number for "param" could be anything. If you want to reenable, then you should write "4 5" to param, where 4 means HDMI output and 5 is wanted resolution, the same number as it is used in script.bin and with h3disp utility (most commonly 10 for 1080p60 and 5 for 720p60) .

RK3288 has Mali-T760 MP4 which supports OpenCL...

Ok, I found what needs to be done. If you do: sudo su cd /sys/kernel/debug/dispdbg/ echo "blank" > command echo "disp" > name echo "0" > param echo "1" > start Then you will blank the screen. If you change 0 to 1, then you will "unblank" it. Please note that I didn't test this on board, but it should work. Let me know if it works for you or not. Root access is unfortunately needed due to writing to debugfs.

Yes, all things should be supported by legacy, although switching hdmi on/off at runtime is a bit tricky. IIRC, "blank" sysfs property also doesn't work, but there are debugfs entries which enables to do that. I already described this method on this forum, although description was about switching modes, but turning off is also part of that. I will try to find it.

Which kernel do you have? If it is not legacy 3.4.113, then you are out of luck, because on mainline kernel video output support is in early state and it is not possible to change any setting in runtime.

@tkaiser you mean this commit https://github.com/jernejsk/OpenELEC-OPi2/commit/3de7bcdf1adc3886938d2b0220c9e30203a1ef0e ? It doesn't have any detailed message, but IIRC I commented somewhere, probably on github. Anyway, if that parameter has a value, then USB gets probed. Because I changed how the kernel behaves - wifi is always powered on at boot to enable autodetection, this mechanism became redundant and even it could cause troubles, so I disabled it. Of course, wifi driver has to be patched too, where probably issue lies. That's way I added another patch which solves loading rtl8188eu driver: https://github.com/jernejsk/OpenELEC-OPi2/commit/85205e9449a4ff65c967101fbbc736a456afbf2d

The only possible way is to buy a converter.

No need to depend on board maker support, because official Rockchip version should work pretty well and basically all drivers are mainlined anyway. Yes, it is possible, but I'm not sure how easy or interesting it is. If it is based on reference design, then yes, it is matter of hours for some who knows DT stuff. Another issue is how hard to find or extract is manufacturer dtb file. I doubt that they provide schematic. It is also the question if it is worth the effort. I guess it should be similar enough to some existing board which has support already manilined. The biggest difference between the boards I saw is which power management chip is used.

Yeah, I know. Well, also Allwinner manuals are sometimes "leaked" and someone also uploaded Synopsys UART specs which are also regarded "confidential". I don't know when it is safe to use, but once it is easily publicly available, it can't be regarded as secret anymore. Anyway, imx6 manual has more or less everything covered already, except maybe I2S audio part, but that is already implemented in the kernel driver. So I would say not much new info, if at all.

@Igor unfortunately, Armbian uses my first version of the driver, which means that it should work flawlessly. Yesterday on irc discussion was about new version of the driver. I can only make it work on monitors I have and both drivers work with both of them...

Ok, now it should be fully supported (eth, usb, video, emmc, etc.) https://github.com/jernejsk/u-boot/tree/miqi Binary (14 days available): https://transfer.sh/fVGr4/u-boot-rockchip-miqi-sd.bin Unfortunately, many patches are not in any stable release, so for testing purposes it would be best just to use my branch and miqi-rk3288_defconfig

Yes, it is in very early stage. I will be more clear next time.