Myy

Members
  • Content count

    176
  • Joined

  • Last visited

About Myy

  • Rank
    Elite member

Contact Methods

  • Website URL
    https://github.com/Miouyouyou/RockMyy

Profile Information

  • Gender
    Not Telling
  • Interests
    https://pledgie.com/campaigns/33598

Recent Profile Visitors

826 profile views
  1. Myy

    preview Asus Tinkerboard

    `/lib/firmware/rtlwifi` only contain the firmware themselves. Though, you could test if a new firmware gets you a better connection. For that, be sure that the name of the new firmware is equivalent to the old one. Try `dmesg | grep -i bin` to get a clue of which firmwares are loaded by the kernel.
  2. @JMCC I was aware of the Ayaka's fork but not of HermanChen's one. Thanks. Still, there are things that either really require extensive H264 knowledge, or things were named... in a very weird way. For example, the register where to store the input buffer address, containing the encoded H264 frame, is named rlc_vlc_st_adr in MPP code. Thanks to the Chromium team code who named it VDPU_REG_ADDR_STR I was able to quickly understand what it does. Still, is that standard H264 naming scheme ? When you're a H264 decoder developer, you don't talk about the raw encoded frame bitstream but about the "RLC VLC source" ?
  3. I'm currently watching a conversation between Tomasz Figa (Member of the Chromium team) and a developer named Baruch Siach about how to port the V4L2 driver to the mainline kernel. Meanwhile, now that I got a roughly good idea on how DMA and IOMMU interoperate, and a documentation of the VPU registers (that was not easy due to the split of the drivers informations between the Rockchip VPU driver and their MPP codebase), I'm currently : trying to get a patched version of MPP working on 4.4 kernel working on a spare MiQi, using @JMCC scripts; get a snapshot of a H264 frame sent to the VPU, with all the VPU registers parameters, with that patched MPP; reproduce this in my last driver and see how it fares. Now, I had to a few troubles, between the fact that my current job takes (too much) time, a few bugs had to be dealt with, I had to buy a second screen because using my main screen and unplugging the HDMI output of my Radeon Vega is a NO-NO due to some vega driver bug (I have to report this bug...)... And I still need to get a few things setup to make the whole Tinkerboard/MiQi/RK3399 juggling painless. The reason I have to peek MPP memory buffers instead of producing a H264 naked frame by myself is that : I currently don't know how to produce a H264 by myself (there's a few tutorials here and there...), and there's a lot of parameters in this standard that require a very good understanding of how video work in general, and some extensive knowledge of the norm. I mean, just computing the dimensions of a frame requires some special math that is not intuitive. Still, if I can send a frame to VPU and have it decoded, than I will be able to focus on trying to get with working with the V4L2 API, which seems to be setup for GPU<->VPU communication, reusing the code Tomasz Figa wrote for the Chromium team.
  4. Myy

    NanoPC T4

    Okay, I've been able to boot an Armbian and I'm now trying to get a mainline kernel working. I've been able to get a seemingly working HDMI output, but I got no Ethernet and the logs were spammed about some iio.device and dwmc3 devices badly configured, in my port of @hjc DTSI and DTS. Also getting to X11 takes at least 30 seconds. Anyway here are the issues I encountered https://github.com/Miouyouyou/RockMyy64/issues I'll play with the RK3399 again next week. Meanwhile, I guess I'll take a tour of all the others repositories mentioned, see if at least I could solve a few issues. Also, since my repository also generates fragmentation, I guess I should add in the README that, yes, you can take, and modify, my patches and do whatever you want with them.
  5. Myy

    RK3288 Media Testing Script

    Ah, EOVERFLOW... You might need that kind of patch applied to the Mali drivers : https://github.com/Miouyouyou/RockMyy/blob/master/patches/Midgard/r19p0-01rel0/0009-GPU-ARM-Midgard-Adapt-to-the-new-mmap-call-checks.patch They might have imported Linus Torvalds patch to mmap into the 4.14 series.
  6. Myy

    RK3288 Media Testing Script

    I don't know which glmark2 you're using, but if you can, try to compile the latest version from their GIT https://github.com/glmark2/glmark2 If that doesn't work, could you try to paste the following : The result of echo $LD_LIBRARY_PATH The 50 last lines of strace glmark2-es2-drm Executed as root from a simple terminal (CTRL+ALT+F1 or chvt 1 from SSH)
  7. The most important feature for the Mali drivers is the DMABUF infrastructure. Also, be sure to test the userland Mali drivers with the GBM/DRM OpenGL output before testing with the X11, since the X11 requires a very specific setup. glmark2 should help you in that regard.
  8. Myy

    NanoPC T4

    It seems that Picocom did a better job for transmitting input. Still, that seems to require an awful lot of tinkering to get it working with a Linux system... I guess I'm missing something.
  9. Myy

    NanoPC T4

    Do you need to flash another U-boot to be able to input something during initialization, when starting from the Android Nougat image ? (´・ω・ `) I'm able to read the input but not send anything and quite frankly the boot phase is FAST. Less than 1 second to react. Also is minicom the best tool for the job ? It seems recommended on FriendlyArm Wiki but... Even though I've used it a lot with the Tinkerboard and MiQi, it still feels clunky.
  10. Another example here : https://stackoverflow.com/questions/10490756/how-to-use-sched-getaffinity-and-sched-setaffinity-in-linux-from-c
  11. I'm pretty sure that you'll need to play with CPU affinity parameters, in your code. Now, this requires extensive testing and measurements to understand if you get any benefit or not, and I'm no expert in this domain. You might get more help on ARM Community or StackOverflow. Meanwhile, see http://man7.org/linux/man-pages/man2/sched_setaffinity.2.html and search for usages of this function. Random example here : https://github.com/intel/u-nit/blob/b5added7b9b0298dc3286601298432e8c3ca37e1/src/main.c#L355
  12. I don't think this is "required" per se. To reserve memory for the CMA allocator, you need to pass the cma=Size parameter to the kernel, at boot time. Edit your boot file accordingly and add something like cma=32M . Now this will reserve 32M of RAM for the CMA allocator. Meaning that, if it's not used, you'll just lose 32M of RAM for nothing.
  13. Myy

    GPU driver?

    If you don't need X11 support, just grab the Rockchip libmali drivers, put them in a folder like @JMCC script is doing, and set up LD_LIBRARY_PATH before calling the program that depends on GLES2/DRM or GLES2/Wayland. If you need X11 support, you could try to rebuild their X11 server but... this could be more pain than gain.
  14. Myy

    Terrible Synaptic performance

    What's the analysis of pkgTagFile::Jump with sysprof ? I don't know where to look up the source code of this function. Valgrind might help you find the culprit too, also, if it's a memory/caching/branch-prediction related issue. Well the source code is here : https://salsa.debian.org/apt-team/apt/blob/master/apt-pkg/tagfile.cc But I don't see what would cause that much of a slowdown at first. That said the code is far from being easily readable.
  15. Myy

    Tinker/MiQi default kernels

    Also, you need that patch if you want to use the Midgard drivers with a 4.17 : https://github.com/Miouyouyou/RockMyy/blob/master/patches/Midgard/r19p0-01rel0/0009-GPU-ARM-Midgard-Adapt-to-the-new-mmap-call-checks.patch This one is nasty because the user-space drivers will fail mmap2 call silently with -EOVERFLOW errors and the whole 3D stack will fail to perform any operation. This basically translates in getting a framebuffer/DRM console but no X11 starting or anything.