Jump to content

Myy

Members
  • Posts

    365
  • Joined

  • Last visited

Everything posted by Myy

  1. So far, I'm stuck with : Assertion p_hal->vcodec_type & ((0x00000200) | (0x00000001) | (0x00000002)) failed at hal_h264d_init:187 Which in MPP code is written like this : mpp_assert(p_hal->vcodec_type & (HAVE_RKVDEC | HAVE_VPU1 | HAVE_VPU2)); So I'm trying to check what could cause this issue. This issue is triggered by MPP when I use the MPP test-suite and when I use MPV.
  2. Is that special GL headers with very recent extensions too ? Anyway, I'll try this patched version, thanks.
  3. Alright, trying to compile MPV led me to EGL extensions definitions issues... That's not common... ../video/out/opengl/hwdec_drmprime_egl.c:39:9: error: ‘EGL_DMA_BUF_PLANE3_FD_EXT’ undeclared here (not in a function) EGL_DMA_BUF_PLANE3_FD_EXT, ^ ../video/out/opengl/hwdec_drmprime_egl.c:45:9: error: ‘EGL_DMA_BUF_PLANE3_OFFSET_EXT’ undeclared here (not in a function) EGL_DMA_BUF_PLANE3_OFFSET_EXT, ^ ../video/out/opengl/hwdec_drmprime_egl.c:51:9: error: ‘EGL_DMA_BUF_PLANE3_PITCH_EXT’ undeclared here (not in a function) EGL_DMA_BUF_PLANE3_PITCH_EXT, I searched for the first extension, it's defined in the eglext.h provided by Mesa, thanks to a patch provided in November 2016. The Mali OpenGL development headers provided by Rockchip do not define that extension. I could add it manually tough. So, basically, trying to compile MPV on Ubuntu LTS seems to be a no-no. So my question is @Kwiboo Did you compile MPV ? If yes, on which distribution did you compile it ? The latest Ubuntu ? Debian testing ?
  4. Alright, the new patches are available from the VPU branch of RockMyy. A new build, including the horrendous DRM security shunting patch, is available through the VPU branch of RockMyy-Build. A new tarball release has been generated too. The rockchip-vcodec repository has been updated, and the kernel patches required to compile and run the VPU code correctly have been copied in it. Still untested though, beside running the kernel, checking that the module was loaded correctly, unloading the module, loading it again, checking that /dev/vpu-service and /dev/hevc-service were created and rebooting.
  5. Alright, I've reassembled and rearranged, when necessary, all the patches used by wzyy2 on the mainline kernel. They compile fine but they're still untested. I'll publish them, with the rc3 release. So far, so long, the MPP test suite is still... "clunky". Like, some tests require you to provide raw videos content, meaning H26x or VP8 content without the file header... A bit like when you strip the BMP header and keep the data to feed it directly to the GPU. Testing the FFMPEG plugin using the h264_rkmpp or vp8_rkmpp decoders throw me some "Operation not permitted" errors. I don't know why though, strace didn't help pinpoint this issue. So, once all the new patches added and test, I'll test with MPV, see if I can get some useful error messages at least. In the new patches, there's another implementation of the rockchip_gem_prime_import_sg_table function. I was using the one provided by the ARM guys before. I also found the mainline kernel patch that adds RGA, the Rockchip 2D hardware rasterizer, which is always a nice little addition. There's a patch that adds the real rockchip_pmu_idle_request used by the VPU driver. I thought the VPU needed rockchip_pmu_set_idle_request , but it looks like it needed an unimplemented function instead. The new patch will add it. Then there's some 10 bits formats additions, like NV10 and a Rockchip specific version of this format, if I understand correctly. In a special branch, I'll also add the patch that shunts the DRM security, FOR TESTING PURPOSES ONLY. I really think that this patch is uncalled for, but I have to use the same environment as the testers in order to report that some things don't work, when they don't. So yeah, all of that with the rc3 for tomorrow.
  6. I'll try this today. wzyy2 also linked me two patches that might be required to get the VPU working under x11. The things is, while I think I've already implemented a good part of the first patch, the second one is... It basically shunts all the security features of DRM drivers... Yeah... Anyway, I'll deal with these patches with the next kernel release. Today, I'm dealing with the user-space mess, focusing on the DRM/KMS part first, since that interface works well on my MiQi board.
  7. Hmm, given that the BTC Keyboard ID have been added 7 years ago, I guess it's more related to Bluetooth dongles getting detected correctly, indeed.
  8. Alright. I've provided a first build of the 4.12.0-rc2 with the VPU included. Now, if you don't want to clone an entire repo, I made a tarball release of this build, so just grab it and install it on your machine. You still need to get the user-space softwares installed correctly though. The kernel loads up, enable the VPU services and the VPU module can be unloaded without issues. Still, no optimization has been added for the moment, as I'm trying to get things working, before trying to get things working nicely. So this week-end will be untangling the user-space.
  9. Glad to hear that most of the work is done through GLES via DRM/KMS, since I mainly test the Mali drivers on my kernels using this interface. Thanks for the link to LongChair's ffmpeg, and your version. I'll try to compile and install the patched libraries, compile mpv and kodi against them and test all of this, this week-end. Tonight I'll try to : add the kernel patch required to use this VPU driver to RockMyy; generate a new script that cross-compiles a new kernel, using RockMyy script, and then cross-compile the VPU module against this kernel; distribute a new kernel build through RockMyy-Build, in a new branch, that integrates the VPU module directly. The last step will make it easier for anyone that already has all the right software installed, to test the VPU driver on mainline kernels.
  10. 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.
  11. But wait... you got Bluetooth working on 4.12 kernels ? Are you using an external Bluetooth dongle or did you just start your Bluetooth keyboard and it worked out the box ? Edit : Ah, didn't read correctly, you're using an external dongle. Well given the bad feedback I got from the tinkering forum on the internal Bluetooth, I guess it's the best choice.
  12. That too, yeah. But at least, you'll know which one it is.
  13. Try to execute lsmod on the working kernel. Since most drivers are compiled modules, that should tell you what is the driver, I think. Then, from the module name, you can retrace the config option required and its dependencies. It might also be possible to determine the driver used using /sys nodes. But I don't know how exactly. udevadm can also help you. But yeah, try lsmod first.
  14. Alright. The issue seems to be fixed anyway. If it works, just paste your uname -a and tell me which DTB you're using, for the record.
  15. If you remove references to loglevel in the boot parameters, does it improve anything ?
  16. Well, I'll see if everything goes fine in my Github issue page tomorrow. If everything goes fine, I'll consider the case closed for now ! Yay !
  17. Yay ! So we got a 4.13 kernel that can reboot on ASUS Systems then ?
  18. Alright, I've regenerated a kernel based on @TonyMac32 patch. The base patch doesn't work on MiQi, generating kernel panic during the reboot phase (´・ω・` ). The new patch tries to resolve the issue : https://github.com/Miouyouyou/RockMyy/blob/Tinkering/patches/kernel/v4.13/0005-Fugly-MMC-hack-trying-to-resolve-Tinkerboard-s-reboo.patch https://github.com/Miouyouyou/RockMyy/tree/Tinkering https://github.com/Miouyouyou/RockMyy-Build/tree/Tinkering
  19. Could you provide your cat /proc/cmdline output ? There might a log=X in your current boot command line that defines another loglevel.
  20. Give me that package ! I'll test it ! ( ・`ω・´)
  21. By that time, ASUS will already be using 4.9 kernels ! That said, if echo b > /proc/sysrq-trigger works, one workaround will be to put this as the last action before rebooting.
  22. The emergency reboot one or the rockchip_tinkerbootfix one ? Anyway, glad to see some progress !
  23. Yeah, that seems to do the trick, thanks for the information. So, in order to display all the kernel messages on the serial console : open up /etc/sysctl/10-console-messages.conf replace kernel.printk values with 7 4 1 7 Save the file, reboot and enjoy a serial console acting like a serial console ! To see even the debug messages, you might need to set it up to 8 4 1 7. The meaning of the values are defined in syslog(2)
  24. I missed the target then, I guess. My cmdline is earlyprintk console=ttyS2,115200n8 rw root=/dev/mmcblk1p5 rootfstype=ext4 init=/sbin/init Which is the same I used on my Gentoo system, however I got the kernel messages on Gentoo. So, yeah, that might be 10-console-messages.conf # the following stops low-level messages on console kernel.printk = 4 4 1 7 I guess that setting this to 7 4 1 7 will allow kernel messages on... the console ? Like every console ? I'll give it a try.
  25. Indeed. No virtual platform representing this device really makes things difficult. The schematics won't lead us far in knowing what's going on exactly. And systemd seems to love shunting kernel messages logging on the serial console, making things harder to analyze. And contrary to what the StackOverflow guys said, not putting any loglevel on the command line makes no difference when it comes to not displaying kernel messages, beside the emergency ones, on the serial console. Maybe the journald developers thought that people would like to use serial consoles every day, because, you know, DVI and HDMI are so overrated. Well, the last issue can be alleviated by just spouting log messages with printk using the "emergency" log level. It's ugly but everything is ugly on test kernels anyway. I really need to investigate this issue however. If I have some time this week, I'll see if I can force the Rockchip system to reboot in various modes, and test if one of this mode just resolve the issue automagically. Anyway, I'm not in a hurry. Take your time.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines