Myy

Members
  • Content Count

    238
  • Joined

  • Last visited


Reputation Activity

  1. Like
    Myy reacted to Kwiboo in The VPU driver   
    https://github.com/Kwiboo/rockchip-vpu-regtool may also be interesting, it generated the template vpu code used for the rk mpeg-2 decoder.
    I will push an update including txt-files with hw regs that needs to be set for other codecs later, buffer and reference frame handling code will need to be created by hand.
  2. Like
    Myy reacted to Kwiboo in The VPU driver   
    For mpeg-2 on rk3288/rk3328 there are some other patches needed, see my rockchip-5.x-vpu branch for working rk3288/rk3328 mpeg-2 decoding on v5.0-rc6. clk, drm and dts patches will be sent upstream any day now.
    Also check out https://github.com/mpv-player/mpv/pull/6461 and the linked ffmpeg hwaccel if you want to use mpv or kodi-gbm for testing, I recently pushed dynamic selection of media/video device to hwaccel so should work without forcing decoder to /dev/video0.
     
    I pushed two libreelec test images to http://kwiboo.libreelec.tv/test/ for tinker board and rock64 if you want to test mpeg-2 decoder, it includes patches from my rockchip-5.x-rebase and rockchip-5.x-vpu linux branch.
  3. Like
    Myy got a reaction from manuti in The VPU driver   
    Well, while this is called a "Video Processing Unit", the thing is : there's a LOT of video file formats out there. Which mean, a lot of different parameters and decoding/decompressing methods, based on the format used. (I mean, there are different formats and there are "different" for a reason...)
    All the VPU I know are specialized in decoding a few formats, at most : H264, H265, VP8, VP9, ...
     
    For each format, the VPU must be configured to access external data like : The current frame, the configuration of the current stream (Width, Height, Bytes per pixel, Color format, ...), the different decoding tables if any (e.g. CABAC tables for H26x), ... .
    The amount of external data and configuration vary from format to format, knowing that some formats can also have "sub-formats" (H264 is a good example of this madness) which require more or less parameters.
     
    So, yeah, VPU are dedicated to a few formats, and for each format, the setup can be completely different. That can be due to configuration registers being mapped at different addresses depending on the decoded format, or the same registers having completely different meaning depending on the format decoded.
     
    Note that, in this case, the VPU decode one frame per one frame.
    You cannot just "Send the MKV to the VPU, get a video stream on the other end". It *clearly* doesn't have enough memory for that.
    Very roughly, the procedure goes as is :
    First, the user application must :
    Get the first frame of the video stream Send it to the VPU driver Then VPU driver must :
    Setup the VPU to decode the frame Launch the VPU decoding process Wait for the decoded result Send back the result to the user application. Then user application :
    Retrieves and shows the result, Rinces and repeat for every frame of the video. So, yeah, VPU are not CODEC agnostics. They are CODEC specialized. So the driver is setup slowly, but surely, to decode each format correctly.
  4. Like
    Myy got a reaction from manuti in The VPU driver   
    Well, while this is called a "Video Processing Unit", the thing is : there's a LOT of video file formats out there. Which mean, a lot of different parameters and decoding/decompressing methods, based on the format used. (I mean, there are different formats and there are "different" for a reason...)
    All the VPU I know are specialized in decoding a few formats, at most : H264, H265, VP8, VP9, ...
     
    For each format, the VPU must be configured to access external data like : The current frame, the configuration of the current stream (Width, Height, Bytes per pixel, Color format, ...), the different decoding tables if any (e.g. CABAC tables for H26x), ... .
    The amount of external data and configuration vary from format to format, knowing that some formats can also have "sub-formats" (H264 is a good example of this madness) which require more or less parameters.
     
    So, yeah, VPU are dedicated to a few formats, and for each format, the setup can be completely different. That can be due to configuration registers being mapped at different addresses depending on the decoded format, or the same registers having completely different meaning depending on the format decoded.
     
    Note that, in this case, the VPU decode one frame per one frame.
    You cannot just "Send the MKV to the VPU, get a video stream on the other end". It *clearly* doesn't have enough memory for that.
    Very roughly, the procedure goes as is :
    First, the user application must :
    Get the first frame of the video stream Send it to the VPU driver Then VPU driver must :
    Setup the VPU to decode the frame Launch the VPU decoding process Wait for the decoded result Send back the result to the user application. Then user application :
    Retrieves and shows the result, Rinces and repeat for every frame of the video. So, yeah, VPU are not CODEC agnostics. They are CODEC specialized. So the driver is setup slowly, but surely, to decode each format correctly.
  5. Like
    Myy got a reaction from jock in The VPU driver   
    You should like my Wayland example, then :3
     
    Anyway, I see that Ezecquiel Garcia is currently pushing patches to adapt the V4L2 patches from Ayaka, into something that works with V4L2 (and a few modifications) without the MPP layer in-between.
    He pushed support for MPEG-2 decoding support... I'll see if he pushes support for H264 this week.
    If not, I'll try to adapt Ayaka's patches.
  6. Like
    Myy got a reaction from jock in The VPU driver   
    You should like my Wayland example, then :3
     
    Anyway, I see that Ezecquiel Garcia is currently pushing patches to adapt the V4L2 patches from Ayaka, into something that works with V4L2 (and a few modifications) without the MPP layer in-between.
    He pushed support for MPEG-2 decoding support... I'll see if he pushes support for H264 this week.
    If not, I'll try to adapt Ayaka's patches.
  7. Like
    Myy got a reaction from manuti in The VPU driver   
    MPP/RKMPP is the RocKchip Media Process Platform.
    A set of libraries, made by Rockchip, to communicate with their VPU driver. The thing is done in such a way that the "driver" basically only handle a few things like memory management.
    The actual registers of the hardware are known by MPP and are setup by this library, then sent to the driver which almost blindly write the registers values into the hardware, or read them back and send them back to MPP.
    Which mean that, even if you have the sources of the Rockchip VPU driver, you need the sources of MPP to understand how the hardware is actually programmed, based on the format you want to decode/encode.
    This is the kind of setup which make you wonder, who's the real "driver" ?
    http://opensource.rock-chips.com/wiki_Mpp
     
    FFMPEG is one the most famous multimedia processing library and tool. This thing can combine audio/video from different sources and combine/convert them into a LOT of formats.
    It comes as a library AND as a binary, which is one of the swiss-army knife for Audio-Video processing.
    https://ffmpeg.org/
     
    MPV is a Media Player, fork of Mplayer2, which use FFMPEG as a backend. It currently have a RKMPP backend to decode video frames using the RKMPP libraries.
    https://mpv.io/
     
    H264 is a video format.
    https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC
     
    The I-frames in H264 are reference (key) frames, from which other kind of frames (B/P frames) will be generated. The I-frame is basically the full frame, while the B/P frames are basically "patches" applied to I-frames to get the new picture.
    The "patches" being generally smaller than the I frame, you get one way to "compress" the video (upon various others used simultaneously).
    https://en.wikipedia.org/wiki/Inter_frame
  8. Like
    Myy got a reaction from manuti in The VPU driver   
    MPP/RKMPP is the RocKchip Media Process Platform.
    A set of libraries, made by Rockchip, to communicate with their VPU driver. The thing is done in such a way that the "driver" basically only handle a few things like memory management.
    The actual registers of the hardware are known by MPP and are setup by this library, then sent to the driver which almost blindly write the registers values into the hardware, or read them back and send them back to MPP.
    Which mean that, even if you have the sources of the Rockchip VPU driver, you need the sources of MPP to understand how the hardware is actually programmed, based on the format you want to decode/encode.
    This is the kind of setup which make you wonder, who's the real "driver" ?
    http://opensource.rock-chips.com/wiki_Mpp
     
    FFMPEG is one the most famous multimedia processing library and tool. This thing can combine audio/video from different sources and combine/convert them into a LOT of formats.
    It comes as a library AND as a binary, which is one of the swiss-army knife for Audio-Video processing.
    https://ffmpeg.org/
     
    MPV is a Media Player, fork of Mplayer2, which use FFMPEG as a backend. It currently have a RKMPP backend to decode video frames using the RKMPP libraries.
    https://mpv.io/
     
    H264 is a video format.
    https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC
     
    The I-frames in H264 are reference (key) frames, from which other kind of frames (B/P frames) will be generated. The I-frame is basically the full frame, while the B/P frames are basically "patches" applied to I-frames to get the new picture.
    The "patches" being generally smaller than the I frame, you get one way to "compress" the video (upon various others used simultaneously).
    https://en.wikipedia.org/wiki/Inter_frame
  9. Like
    Myy got a reaction from TonyMac32 in The VPU driver   
    After fighting to get FFMPEG compiled, MPV compiled (with Debian putting ffmpeg includes inside /usr/include/arm-what-ever-arch-hf/ and /usr/include/arm-what-ever-arch-hf/ having priority over /usr/include !) and then patching MPV to get the OpenGL display working correctly (stop using eglGetDisplay when you can use eglGetPlatformDisplayEXT !), I got the same error as you had...
     
    And then I realized that the error states that the buffer allocation failed...
     
    So I tried as root and it led to RKMPP failing to get the right frames in time. And then it crashed... badly.
     
    I'll retry with Gstreamer, since Rockchip seems to love gstreamer. And if that doesn't work, then the VPU is still in a shit state... But at least, they can communicate with it so I guess it's something...
  10. Like
    Myy reacted to TonyMac32 in The VPU driver   
    @Myy I missed your comment on the initial commit, I need to quite waiting until midnight to do the more interesting stuff. 
     
    I'm being presented with 5 options under the rockchip_mpp kconfig:  I've got MPP_VDEC_DEVICE, vpu decovder V1 and V2, vpu encoder V1 and V2. Are they all needed?
  11. Like
    Myy got a reaction from JMCC in RK3288 Media Script (TinkerBoard)   
    Be sure that ROCKCHIP_MPP is enabled in the kernel configuration. It's not automatically set up.
    The driver is available in "Device Drivers -> Staging drivers -> Rockcihp MPP".

    Generally you get some warning, like for the Realtek staging driver, telling you that the code isn't that great, etc...
  12. Like
    Myy got a reaction from TonyMac32 in The VPU driver   
    Okay, the driver is loading now... So now, I have to pull out a setup that can use "mpp service"... @JMCC Is your setup useable with MPP service ?
     
    I'll try to rewrite the patches and upload them, along with a complete build, in order to let people play with it, see if they can get something out of it.
     
    There's still a *BIG* fat warning : [    6.565010] Failed to attached device ff9a0000.video-codec to IOMMU_mapping
    Now... The nodes have been split in two and ff9a0000.video-codec is the Video Encoder. The Video decoder is at ff9a0400.video-codec so... maybe it's working fine ?
    It's still highly probable that it will just crash in a very bad way.
     
    Anyway, I'll need some testers that are used to the whole MPP stuff.
  13. Like
    Myy got a reaction from chwe in [PATCH] 5.0-rcX and UART issues   
    There's a few problems with the UART driver on 5.0-rc2 kernels, since proper checks are not done correctly and lead to a Null Pointer dereference.
     
    Here's a patch to avoid this issue :
     
    From 7e43ae8446b420907f00b43308ad0b99b6fe4e51 Mon Sep 17 00:00:00 2001 From: "Miouyouyou (Myy)" <myy@miouyouyou.fr> Date: Wed, 16 Jan 2019 23:58:52 +0100 Subject: [PATCH] drivers: tty: serial: Bail out if no UART is detected Before the 5.0, serial8250_register_8250_port consisted of one BIG if(uart && uart->port.type != PORT_8250_CIR) block, which prevented NULL dereference if uart, a pointer to an "uart_8250_port" detected through "serial8250_find_match_or_unused", were to be NULL. However, a recent patch added a few bits of code just after that, and that code manipulates the "uart" pointer without checking if it's NULL or not. This patch changes the mechanism and bail out early if no UART structure pointer is provided serial8250_find_match_or_unused. A goto is used instead of returning directly, since we're inside a mutex and must release it correctly. Signed-off-by: Miouyouyou (Myy) <myy@miouyouyou.fr> --- drivers/tty/serial/8250/8250_core.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c index 189ab1212..11120c2d9 100644 --- a/drivers/tty/serial/8250/8250_core.c +++ b/drivers/tty/serial/8250/8250_core.c @@ -981,7 +981,12 @@ int serial8250_register_8250_port(struct uart_8250_port *up) mutex_lock(&serial_mutex); uart = serial8250_find_match_or_unused(&up->port); - if (uart && uart->port.type != PORT_8250_CIR) { + if (!uart) { + printk(KERN_INFO "One UART port failed to register correctly\n"); + goto no_uart; + } + + if (uart->port.type != PORT_8250_CIR) { if (uart->port.dev) uart_remove_one_port(&serial8250_reg, &uart->port); @@ -1081,6 +1086,7 @@ int serial8250_register_8250_port(struct uart_8250_port *up) uart->overrun_backoff_time_ms = 0; } +no_uart: mutex_unlock(&serial_mutex); return ret; -- 2.16.4  
  14. Like
    Myy reacted to TonyMac32 in Official Asus Tinker Board Case   
    Thanks to ASUS, I got my hands on one of these after seeing what appeared to be a giant heat sink fin integrated into the top of the case.  This case may be of interest to non-Tinker owners as well, it is not designed like the equivalent Pi cases with a fixed aluminum stud touching the SoC.  Instead it has a small aluminum block that has an adhesive side, and a thermal pad side, and is clamped down onto the processor by putting the two halves together.  This allows some freedom on the location of the SoC relative to the lid.
     
    First off, same nice packaging the Tinker owners are familiar with:
                             
     
    The case itself is quite heavy, and a nice color/texture, although the finish is most likely not 100% on this one, as it's pre-production
     
    The reason for the weight becomes immediately obvious when pulling the two halves apart:

    All I can say about this is, if the thermal pad/adhesive aluminum block fit properly, there is a lot of thermal mass here, and I'm perfectly alright with ASUS calling this fanless.  The extrusion is very thick, over 8mm in places.  Now for the bottom, a comparatively much thinner stamped part, the embossing does it's work to strengthen the base adequately.
     
    Something important to notice in this picture:  The Tinker sits on aluminum studs, and does not bolt down.  The heat sink block holds it in place.  I have been told that the two additional holes you see here to the left side of the base are for a VESA mount adapter:
    https://www.asus.com/Destkop-Accessories/VivoPC_VESA_Mounting_Kit/
     
    I can't verify (no hardware), but the holes are 85mm apart and threaded.
     
    Board fits nicely:
                                     
     
    Now, putting it together only involves 1 thumb screw once you've gotten the aluminum block bit sorted out (a little bit of a balancing act, but not really a problem.  This would be my only feedback where I think a different option would have been better:  The thumbscrew is located at a position so as to be on center with the SoC.  This makes sure the whole stack is making contact, but it also creates a pivot point which rattles when you move the case around.  Not a problem for 90% of people, to be honest.  In my humble opinion, 2 thumb screws, one to each side, making it a bit more rigid once assembled.  Oh, I also pulled out some rubber feet and put them on it, none were provided in the box, and I like the grippy feet.
     

     
     
     
    My unofficial testing shows the case very easily outperforming the tiny heat sink thermally, so in that respect it wins.  Aesthetically it is a very nice looking product, of course I'd say that should be expected.  I'll follow with something a bit more empirical later on.
  15. Like
    Myy reacted to TonyMac32 in NanoPC T4   
    Yeah, VPU doesn't exist in mainline.  There are some patches for educational purposes out there, but nothing constituting a truly functional driver.  Mali needs patched in, similar to what @Myy does with RK3288.
  16. Like
    Myy got a reaction from DataMannen in Ramblings and progress with the RK3399   
    I've been able to boot a mainline kernel with a barely working DTS file that can, still, boot up to X11 and provide a working serial console.
    USB is "just broken" though, since the DTS file doesn't follow the schematics at all.
     
    https://gitlab.com/snippets/1792126
     
    Note that I'm currently using an external MMC file for the moment, since it's the easiest way for me. Replacing broken kernels on the eMMC is a pain, I can't get Gadget mode working with the DesignWare DWC3 connector on U-Boot at the moment (I just tried to enable the option, though, not tinker with the DTB and such...).
    So my only way to test and replace kernels quickly is to use a Micro SDCard to boot the system on the OrangePi, and use an USB MicroSD reader on my main PC to replace broken kernels/DTB files.
     
    So, tomorrow will be : Schematics to DTS time... Yay...
  17. Like
    Myy got a reaction from Seasalt in Ramblings and progress with the RK3399   
    I was offered this board to see what I can do with it. Just like the other boards I got (MiQi, Tinkerboard, ...)
     
    Concerning "plans", I won't have any until I at least get a way to install a Linux image with a Rockchip kernel that "kind of work" correctly, in an "automated fashion" (scripted and useable with rkdeveloptool and Windows tools, so that you can reflash it at any moment if things go wrong).
    Then I'll start mimicking their drivers on latest kernels and see if there's any major barrier, though I will have to deal with a few other issues before that.
     
    I still see that the VPU is neither documented anywhere on their schematics, so there's at least that. If they could at least document which channel the VPU uses with the DMA subsystem, it might help a bit.
     
    For the GPU side, given how fast the Panfrost project is progressing, it might be possible to overcome Mali binary drivers issues with these drivers. The Rockchip team was never able to provide Vulkan-ready binary drivers for their Mali-T7xx and Mali-T8xx chips, and the only one ARM provided with Vulkan support was with fbdev support only. There's of course drivers able to use DRM/KMS but you're "limited" to OpenGL ES 2.x / 3.x and you need an old GPL kernel driver that's starting to pile up patches to get it work with latest mainline kernels.
     
    Now, given how the NanoPC T4 4.4 kernel was able to provide : HDMI output, (kind of shaky but working) Ethernet, eMMC and SDCard support, there's chances that "Orange Pi" specific issues might be fewer than expected. What remains, in terms of connections, are : SATA ports, USB, USBC, Audio, Wifi and Bluetooth.
    Bluetooth might just be like the Tinkerboard : Wake up the Wifi/Bluetooth chip, flip a few GPIO and then find a way to send the local "binary blob firmware" to the chip.
     
    There's also the MIPI connectors, but I got nothing to connect to these ports. Same for the battery.
     
    Anyway, I'll be a bit busy this week but I might be able to advance a bit this week-end.
  18. Like
    Myy got a reaction from Seasalt in Ramblings and progress with the RK3399   
    I was offered this board to see what I can do with it. Just like the other boards I got (MiQi, Tinkerboard, ...)
     
    Concerning "plans", I won't have any until I at least get a way to install a Linux image with a Rockchip kernel that "kind of work" correctly, in an "automated fashion" (scripted and useable with rkdeveloptool and Windows tools, so that you can reflash it at any moment if things go wrong).
    Then I'll start mimicking their drivers on latest kernels and see if there's any major barrier, though I will have to deal with a few other issues before that.
     
    I still see that the VPU is neither documented anywhere on their schematics, so there's at least that. If they could at least document which channel the VPU uses with the DMA subsystem, it might help a bit.
     
    For the GPU side, given how fast the Panfrost project is progressing, it might be possible to overcome Mali binary drivers issues with these drivers. The Rockchip team was never able to provide Vulkan-ready binary drivers for their Mali-T7xx and Mali-T8xx chips, and the only one ARM provided with Vulkan support was with fbdev support only. There's of course drivers able to use DRM/KMS but you're "limited" to OpenGL ES 2.x / 3.x and you need an old GPL kernel driver that's starting to pile up patches to get it work with latest mainline kernels.
     
    Now, given how the NanoPC T4 4.4 kernel was able to provide : HDMI output, (kind of shaky but working) Ethernet, eMMC and SDCard support, there's chances that "Orange Pi" specific issues might be fewer than expected. What remains, in terms of connections, are : SATA ports, USB, USBC, Audio, Wifi and Bluetooth.
    Bluetooth might just be like the Tinkerboard : Wake up the Wifi/Bluetooth chip, flip a few GPIO and then find a way to send the local "binary blob firmware" to the chip.
     
    There's also the MIPI connectors, but I got nothing to connect to these ports. Same for the battery.
     
    Anyway, I'll be a bit busy this week but I might be able to advance a bit this week-end.
  19. Like
    Myy got a reaction from chwe in HDMI frequencies in the DTS file   
    I've adapted a set of patches from Urja Rannikko, which move the HDMI frequencies definition into the DTS file, with some preconfigured rates if none are defined in the DTS.
     
    The original patches set is here : https://www.spinics.net/lists/arm-kernel/msg673156.html
    The big patch I used as a basis is here : https://github.com/urjaman/arch-c201/blob/master/linux-c201/0020-RK3288-HDMI-clock-hacks-combined.patch
    I included these patches by splitting them again : https://github.com/Miouyouyou/RockMyy/commit/57ff073fffb5678e75959e566704376f6f52ac17
     
    These patches were suggested to me here : https://github.com/Miouyouyou/RockMyy/issues/3
     
    Anyway, after some quick tests, these patches remove the dreaded bar of purple pixels at the left of my HDMI screen, when plugged to Tinkerboard systems and MiQi systems. Note that these bars only appear on my screen when using "good" (enough) USB power supply.
    Still, with these patches, they are gone. However... I only tested these patches on my 60Hz 1080p screen, which is pretty much the de-facto standard screen.
    I'd like to see people test these patches on other HDMI configurations which are known to have some issues with Tinkerboard, MiQi and others RK3288 systems.
     
    So, yeah, if you'd like to test some kernel patches and are not afraid to see your screen go black after a reboot, have a try.
     
    Note : This is completely unrelated with the CEC issue.
  20. Like
    Myy got a reaction from chwe in HDMI frequencies in the DTS file   
    I've adapted a set of patches from Urja Rannikko, which move the HDMI frequencies definition into the DTS file, with some preconfigured rates if none are defined in the DTS.
     
    The original patches set is here : https://www.spinics.net/lists/arm-kernel/msg673156.html
    The big patch I used as a basis is here : https://github.com/urjaman/arch-c201/blob/master/linux-c201/0020-RK3288-HDMI-clock-hacks-combined.patch
    I included these patches by splitting them again : https://github.com/Miouyouyou/RockMyy/commit/57ff073fffb5678e75959e566704376f6f52ac17
     
    These patches were suggested to me here : https://github.com/Miouyouyou/RockMyy/issues/3
     
    Anyway, after some quick tests, these patches remove the dreaded bar of purple pixels at the left of my HDMI screen, when plugged to Tinkerboard systems and MiQi systems. Note that these bars only appear on my screen when using "good" (enough) USB power supply.
    Still, with these patches, they are gone. However... I only tested these patches on my 60Hz 1080p screen, which is pretty much the de-facto standard screen.
    I'd like to see people test these patches on other HDMI configurations which are known to have some issues with Tinkerboard, MiQi and others RK3288 systems.
     
    So, yeah, if you'd like to test some kernel patches and are not afraid to see your screen go black after a reboot, have a try.
     
    Note : This is completely unrelated with the CEC issue.
  21. Like
    Myy reacted to TonyMac32 in HDMI-Monitor bricked tinkers today (next 5.60)   
    Yes, but the Tinker moves it from 2 to 3 to keep common with what ASUS is doing.  I think the UART 2 might be blocking an IO range that periogerals could use, but pure speculation.  
     
     
  22. Like
    Myy reacted to jock in RK3288 Media Script (TinkerBoard)   
    Oldies but goodies: a made a quick demo with my smartphone (sorry for the bad quality) of Quake2 running on rk3288 using GL4ES. The game works really well, it is totally playable and there are no issues of any sort 
     
     
  23. Like
    Myy reacted to TonyMac32 in One (bsp) Kernel f RK3399/RK3328 and RK3288   
    That's the question we're working on.  I think we can handle all from one codebase, at least as long as there aren't too many Tinker Reboot workarounds on other boards (I have that "contained" so it doesn't break anything)
     
    From kernel to kernel the MAli drivers need tweaking, and while @Myy does excellent work with this, I thought it easier to keep Next on an an LTS kernel, then if people want bleeding edge they can compile a Dev image.
     
    Also, welcome back!
  24. Like
    Myy got a reaction from jock in RK3288 Media Script (TinkerBoard)   
    The Mali driver can use devfreq, and has various ways to be told how to vary the frequency of the GPU.
    Now, I've been informed recently that a patch is necessary on mainline kernels to avoid some Mali Devfreq related warnings and panics.
    A modified version of the patch is available here : https://github.com/Miouyouyou/RockMyy/blob/master/patches/Midgard/r19p0-01rel0/0010-GPU-Mali-Midgard-remove-rcu_read_lock-references.patch
    The original is here : https://github.com/mihailescu2m/linux/commit/bbe73c3c1143e5991bdcaee3afaecf5c31af0647
     
    That said, if you want to push the Mali GPU to higher limits, you can do something like this :
    cd /sys/class/misc/mali0/device/devfreq/devfreq0/ echo `cat max_freq` > min_freq echo 10 > polling_interval This will force the GPU to be at its highest clock rate constantly (supposedly, I have no way to actually verify that).
     
    Now, let's be clear, if you launch a GPU intensive task with these settings, while not having a beefy stable power supply, the board might just shut down or not provide any performance gain. Now that's mostly the case for USB power supplied board.
     
    Still, these settings provide good performances gain on some benchmarks, very little on others. Frequency alone won't help you overcome bad optimizations. Also sometimes performances issues become CPU bound as the GPU gets faster.
     
  25. Like
    Myy got a reaction from valant in Package list error due to filesystem corruption   
    What if you do :
    mv /var/lib/apt/lists/apt.armbian.com_dists_xenial_InRelease{,.bak} apt update ?
     
     
    If that fails miserably, just do :
    mv /var/lib/apt/lists/apt.armbian.com_dists_xenial_InRelease{.bak,}