jernej

  • Posts

    1033
  • Joined

  • Last visited

Reputation Activity

  1. Like
    jernej reacted to zador.blood.stained in H3/H5/A64 DRM display driver   
    Did a quick test on OPi+2E. Video works, HDMI sound works, so that's a great work, thanks! Will try to do more tests (like resolution switching) later.
    Small note - framebuffer switching from u-boot to kernel (at least without simplefb nodes in the DT) displays a distorted picture for several seconds. Is this something that will need fixes/workarounds for mainlining?
     
    Also you added DT nodes to sun8i-h3.dtsi - so how big will be the differences for H5? Currently (for other hardware) some common properties are defined in sunxi-h3-h5.dtsi and then specific properties are added in sun8i-h3.dtsi and sun50i-h5.dtsi (including clocks, interrupts, "compatible" strings, etc.).
  2. Like
    jernej got a reaction from zador.blood.stained in H3/H5/A64 DRM display driver   
    Yes, but I have missed one patch which may or may not be important. It will have to wait till tomorrow.
     
    For now, yes. I guess this doesn't really matter since we could squash all HDMI patches to one?
     
    Driver should work (not tested), but DT must be updated.
     
    Once everything works, I was thinking about adding Mali driver. Fortunately, we could borrow properly licensed X11 driver from CHIP.
  3. Like
    jernej got a reaction from lanefu in H3/H5/A64 DRM display driver   
    Yes, but I have missed one patch which may or may not be important. It will have to wait till tomorrow.
     
    For now, yes. I guess this doesn't really matter since we could squash all HDMI patches to one?
     
    Driver should work (not tested), but DT must be updated.
     
    Once everything works, I was thinking about adding Mali driver. Fortunately, we could borrow properly licensed X11 driver from CHIP.
  4. Like
    jernej got a reaction from manuti in H3/H5/A64 DRM display driver   
    Yes, but I have missed one patch which may or may not be important. It will have to wait till tomorrow.
     
    For now, yes. I guess this doesn't really matter since we could squash all HDMI patches to one?
     
    Driver should work (not tested), but DT must be updated.
     
    Once everything works, I was thinking about adding Mali driver. Fortunately, we could borrow properly licensed X11 driver from CHIP.
  5. Like
    jernej reacted to Myy in The VPU driver   
    Alright, the biggest issue with the ASUS Tinkerboard being "resolved", I'm starting to take care of the VPU driver, in order to use it with mainline kernels.
     
    The hardware video encoding/decoding facilities are the real meat of the RK3288, and recent Rockchip boards.
    The VPU driver aims to use these facilities in order to provide the smooth video playback experience that every Netflix/Hulu addict expects when buying such boards.
     
    Which mean, once this part dealt with, you might be able to enjoy your Multimedia oriented distributions/softwares on your Rockchip boards (MiQi, Tinkerboard and maybe Pine64 too !)
     
    So the driver is already available in Rockchip 4.4 kernels, and started to be ported in an Out-Of-Tree fashion by phhusson on Github, and then got the attention of wzyy2, one of the Rockchip guy, which updated it and took care of multiple bugs that were present in this version.
     
    I'm now reassembling the code, include files and all in my rockchip-vcodec repository, patching the code to use it with the latest 4.13 kernels.
     
    Now, the problems are : I don't get the big picture from the user side. So it's kinda hard to test this quickly.
     
    Rockchip seems to rely on their library, MPP, and patched gstreamer packages if I understand correctly. Last time I tried the "test-suite" of the MPP library, things were "clunky". Since it's mostly maintained by one person, ayaka, I'm pretty sure that it's the kind of test-suite that only the owner clearly understands. I know that problem, as I did the same thing with some of my libraries.
     
     
    So, basically, the main goals are :
    ! Compile the VPU driver without issues. I took care of that for now. The driver compiles, loads AND unloads correctly, without issues. ? Understand clearly what packages, patches and software are needed to use the VPU services provided by the VPU driver. ? Enjoy 1080p movies without a hitch on RK3288 boards (and others Rockchip boards if possible) !  
    I'll add these goals on the Github pages so that everyone gets how things are going, from the GH page.
     
    If you have any issue with the driver and/or it's use, file it on my repository and I'll see what I can do.
  6. Like
    jernej got a reaction from Mike R9FT in 7" hdmi display   
    Actually you can't do much except patch U-Boot. H3 and newer chips uses driver in U-Boot which doesn't consider video-mode variable. Since kernel relies on U-Boot to set up HDMI for now, the only thing you can do is to create U-Boot patch and rebuild the image on your own. You only need to change line 131.
  7. Like
    jernej got a reaction from Joshua Ellinger in 5" 800x480 waveshare lcd working but messed up image.   
    It seems that numbers in hdmi driver are wrong for this mode. Here is a patch which might solve the issue, although not tested for obvious reasons:
    https://transfer.sh/UCKIH/zzz-fix-video-modes.patch
    Note that link is valid only for 14 days.
     
    You can add this patch to build system and build your own image. If it works, we can include it in upstream repo. Although if you are not familiar with linux, this might be a nice challenge, but you will learn a few things along.
  8. Like
    jernej got a reaction from Da Alchemist in ROCK64   
    That may be hard, but I just checked mpp source (Rockchip HW video acceleration library) and it mentions that RK3328 is fully supported. Rockchip kernel 4.4 also has initial support for video decoding. I would say that future is bright.
  9. Like
    jernej got a reaction from bozden in ROCK64   
    That may be hard, but I just checked mpp source (Rockchip HW video acceleration library) and it mentions that RK3328 is fully supported. Rockchip kernel 4.4 also has initial support for video decoding. I would say that future is bright.
  10. Like
    jernej got a reaction from hmartin in ROCK64   
    I know that Rockchip doesn't usually provide full user manuals, but is there a chance to get them anyway?
  11. Like
    jernej got a reaction from tkaiser in ROCK64   
    @tkaiser
    yes, my board should be on the way, but it has same USB3 issue.
  12. Like
    jernej got a reaction from op1tjaap in dwmac-sun8i  driver ..... v6   
    dwmac-sun8i v6 driver was just merged to net-next and it will be included from 4.13 onwards. So just a 2-3 months away.
  13. Like
    jernej got a reaction from zador.blood.stained in dwmac-sun8i  driver ..... v6   
    dwmac-sun8i v6 driver was just merged to net-next and it will be included from 4.13 onwards. So just a 2-3 months away.
  14. Like
    jernej got a reaction from tkaiser in dwmac-sun8i  driver ..... v6   
    dwmac-sun8i v6 driver was just merged to net-next and it will be included from 4.13 onwards. So just a 2-3 months away.
  15. Like
    jernej got a reaction from giri@nwrk.biz in PSA: Orange Pi Zero expansion board tv-out not working solution   
    TV unit is described only in A10 and R40 datasheet. Even in those two datasheets some register descriptions are missing, but they should be enough. You can find them through linux-sunxi.org
  16. Like
    jernej got a reaction from Da Alchemist in RK3328 Kernel   
    4.4 kernel should support it since last month or something like that (I was analyzing exactly that piece of the code), but I didn't test it.
  17. Like
    jernej got a reaction from zador.blood.stained in H2+/H3/H5/A64 Disp2 U-Boot video driver   
    Seems so. Compare this and this. Pick a place to fix it.
     
    Please note that TV out is not included in this patch. I will add it when I will have time.
     
    P.S.: It looks like this driver will be in next U-Boot release. Unfortunately, I can't say the same for fixes I sent later (they go in through different repo).
  18. Like
    jernej got a reaction from tkaiser in H2+/H3/H5/A64 Disp2 U-Boot video driver   
    Yes, I know. This was because DE2 itself needs DM_I2C to be enabled (not really, just to prevent warnings), so I had to do some intermediate patches which was ready few days after clocks were merged. However, pull to master for rc3 was done in between those few days when I was preparing DM_I2C patches... Now I'm really not sure if DE2 will be merged or not. One week chance
  19. Like
    jernej got a reaction from zador.blood.stained in H2+/H3/H5/A64 Disp2 U-Boot video driver   
    At least here is the (temporary) solution for simplefb:
    https://github.com/Icenowy/u-boot/commit/315edb971fa05d80fd0f17190406125f7455dc96
  20. Like
    jernej reacted to divis1969 in HW accelerated video decoding/encoding on BPI M?   
    I have reworked ffmpeg's cedrus264 encoder to use libcedrus and modified libcedrus to allow few clients to use VE (in the same process).
    How it is possible to use both vdpau-sunxi decoder and cedrus264 encoder to transcode the video.
    The results for
    ./ffmpeg -hwaccel vdpau -i big_buck_bunny_720p_H264_AAC_25fps_3400K.MP4 -pix_fmt nv12 -r 5 -an -b:v 64k -c:v cedrus264 stream.mp4 are the following:
    Video is viewable, CPU usage is ~80-90%, FPS while encoding ~6.7, time real 0m56.523s, user 0m28.210s, sys 0m15.720s
    It is not as good as I was expecting though. Perhaps, copying data in memory is a bottleneck.
    Not sure it could be improved
     
    The code is located at https://github.com/divis1969/libcedrus (branch master) and https://github.com/divis1969/FFmpeg (branch 2.8-cedrus)
  21. Like
    jernej got a reaction from Slackstick in Next thread Custom HDMI timings/resolution hints in dev   
    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.
  22. Like
    jernej reacted to Igor in RK3399 Orange Pi   
    First Rockchip RK3399 based board from Orangepi maker - under development, not much news except what can be scrapped from pictures. Chip: http://rockchip.wikidot.com/rk3399
     
     


  23. Like
    jernej reacted to hojnikb in OPI Prime board   
    PC+ was made before NAND started rapidly increasing in price.
  24. Like
    jernej got a reaction from tkaiser in Possible bug at compiling files for Orange PI Zero   
    @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
  25. Like
    jernej got a reaction from manuti in RK3328 Kernel   
    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.