Myy

In armbianmonitor, both eth0 and wlan0 appear to be down, so how do you connect to the Internet ? Ethernet cable or wireless ? 5: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000 link/ether 0c:9d:92:0c:b0:ce brd ff:ff:ff:ff:ff:ff 6: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000 link/ether d0:c5:d3:5a:af:db brd ff:ff:ff:ff:ff:ff When the problem occurs, if you do (replace eth0 by wlan0 if you're connected through WiFi) : ip link set eth0 down ip link set eth0 up Can you ping 1.1.1.1 ? Also, what's the temperature of the CPU when the problem occurs ?

Can you take a photo of the issue ? Also, I'd highly recommend to try getting a SSH access on the board and provide some logs (dmesg at least). That said, if you could avoid using the HDMI-to-VGA adapter, or at least try a few minutes with a direct HDMI connection, that could help determine if that's the adapter causing some issues (or the Rockchip driver not able to deal with the adapter configuration). Also, understand that the only Mali Midgard user-space vulkan driver for RK3288 boards, that works on Linux, is tailored towards the fbdev display API, which might require some very specific kernel configurations (or a very old kernel).

That said, if it doesn't crash with other SSD, maybe try to cool it down a little and see if it solves the issue ? Also, does it generate the *same* problem inside a standard PC/Laptop ? EDIT : Also, did you try to check for firmware upgrades for this specific drive ? Maybe it could enable "throttling" automatically and avoid the boiling mess. Okay, there's no firmwares for this one. Anyway, if anybody else could try this (with a spare disk that isn't useful to you... At this temperature, the disk *might* suffer heavy damage), we could maybe put a warning on every board that supports NVMe about such issues. I was thinking that you could share these informations with the Samsung Community, but their forums seem kind-of dead.

What does grep nvme_kthread /boot/System.map* returns ? Same thing for grep 0xffffff8009c /boot/System.map* ? EDIT : Apparently the key words here are : Unhandled fault: synchronous external abort It seems to be related to something that "went wrong" from an operation not executed directly by the CPU. https://stackoverflow.com/questions/27507013/synchronous-external-abort-on-arm https://community.nxp.com/thread/496662 I don't know if that's the disk firing an abort request due to the very high temperature, or simply the disk boiling so much that PCIe operations are not done correctly anymore.

That firmware seems to be part of Closed McBlobby family : https://patchwork.kernel.org/patch/9225567/ However, a more legit source for this firmware would be : https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/rockchip Give the find / command a try and, if possible, try it on a NVMe drive.

The first error *might* be related to the firmware file not present, as printed just below the oops message. For this one, you could try this : The methodology is taken from here : https://forum.pine64.org/showthread.php?tid=6510 Now the spinlock seems to be NVMe related... When you boot correctly, does something like find / generates a freeze ? EDIT : Didn't read the whole thread correctly... With overlayroot enabled, are you also testing with stress -i 4 -d 4 ?

Interesting find. They seem to talk about filling up a "form" to get more informations, but I can't find that form. Do you know if the hardware decoder documentation is still available on this site ?

Yeah, just retried with his latest patches (both kernel and FFmpeg using some new flag M2M_HOLD_CAPTURE_BUF WIP) and it's better, but blocks are still flickering a little. However, most of the issues are gone so, I guess that between mid-June~July H264 support will be top notch. VP8 support has been added to the driver, but either his FFmpeg is not able to decode this format, or MPV refuses to use this hardware decoder ("codec vp8 is not on whitelist" error).

Alright, I understand that downloading some precompiled binary by who-knows-who, and tinkering here and there to get it working, sounds shady and fucking annoying. So, instead, I made a script that allows you to download a fresh official FFmpeg, apply @Kwiboo and @jernej patches against it to get V4L2 Request API support, and compile the whole thing (binary and dynamic libraries). Now, this *won't* install the patched FFmpeg, for reasons stated above. https://github.com/Miouyouyou/FFmpeg-V4L2-Request I didn't apply bbrezillon patches, since I haven't tested his latest modifications and, ATM, there were issues here and there. I'd love some good H264 support, but you'll have to wait a bit.

Trying to compile FFMPEG statically worked... Trying to compile MPV, though, was a disaster since it wants *every potential library* as a statically linked library when trying to link against FFMPEG... Which makes no sense to me, if you link against a statically linked FFMPEG, why would need a static libdrm and libudev ? Still, throwing "-Wl,-Bstatic" before "-ludev" result in ldd not finding the right libraries and I don't see how to resolve the problem in a "nice" way (meaning not hacking through the configure script). So, anyway, I decided to provide the dynamically linked FFMPEG and mpv instead. You'll need the following libraries to use the provided libraries : ld-linux-armhf.so.3 (Available on any ARM debian system) libc.so.6 (GlibC - installed by default) libdrm.so.2 (libdrm2) libm.so.6 (GlibC - installed by default) libpthread.so.0 (GlibC - installed by default) libudev.so.1 (libudev1) libva-drm.so.2 (libva-drm2) libva.so.2 (libva2) libva-x11.so.2 (libva-x11-2) libvdpau.so.1 (libvdpau1) libX11.so.6 (libx11-6) libxcb-shape.so.0 (libxcb-shape0) libxcb.so.1 (libxcb1) libxcb-xfixes.so.0 (libxcb-xfixes0) libz.so.1 (zlib1g) So, basically : apt install libdrm2 libudev1 libva-drm2 libva2 libva-x11-2 libvdpau1 libx11-6 libxcb-shape0 libxcb1 libxcb-xfixes0 zlib1g Or maybe just apt install libdrm2 libudev1 libva2 libva-x11-2 libvdpau1 libx11-6 libxcb1 zlib1g For mpv, you'll need : ld-linux-armhf.so.3 (Available on any ARM debian system) libass.so.9 (libass9) libc.so.6 (GlibC) libdl.so.2 (Available on any ARM debian system) libdrm.so.2 (libdrm2) libEGL.so.1 (libegl1) libgbm.so.1 (libgbm1) libjpeg.so.8 (libjpeg1) libluajit-5.1.so.2 (libluajit-5.1-2) libm.so.6 (GlibC) libpthread.so.0 (GlibC) librt.so.1 (GlibC) libz.so.1(zlib1g) So basically : apt install libass9 libdrm2 libegl1 libgbm1 libjpeg1 libluajit-5.1-2 zlib1g ffmpeg-mpv-dyn.tar.xz ffmpeg-includes.tar.xz

Ah, indeed, I forgot about statically linking some media players, like MPV, against patched FFmpeg. I'll use that for MPEG-2 support. And, yeah, Chromium and Firefox bundle their own FFmpeg, so they'll need to be patched independently once H.264, VP8 or MPEG-4 full support hit the kernel.

VPU patches re-ordered, remade and tested against 5.1 release kernel, with the usual patches combined. I retested the H264 driver with a slight fix and it's better, but there's still a few blocks not placed correctly here and there. This might be resolved this month, though. Anyway, it's MPEG-2 decoding only for the moment. Note to @TonyMac32, if you want to import these patches, the actual kernel patch list I'm using is there : https://github.com/Miouyouyou/RockMyy/blob/master/GetPatchAndCompileKernel.sh#L57 Now, what remains is FFmpeg. I don't remember if Ubuntu is still using libav, or went back to FFmpeg. I remember that the projects forked for some weird reasons and Debian went with libav... So, basically, do I create a package, or just a tarball with the libraries. With just the tarball, you'll have to extract them somewhere and run LD_LIBRARY_PATH=/path/to/ffmpeg/libs to use them with mpv and such. With the Debian package, you get the advantages (automatic dependencies handling) along with all the troubles (packages conflicts). I still have to test bootlin libva too, since it seems to go well with VLC.

Here's a first draft of the patches I pulled from bbrezillon tree : https://github.com/Miouyouyou/RockMyy/tree/SplittingPatchesForVPU/patches/kernel/v5.1/VPU These are applied against mainline v5.1-rc5 kernels, and have been tested with Kwiboo's FFMPEG and a standard MPV. I'll try to test them, and adapt them, against v5.1 releases tomorrow. Then I'll re-arrange them and do a release of RockMyy. I'll then generate a FFmpeg package with Kwiboo's patch, using Kwiboo's tree, since bbrezillon's one doesn't integrate udev /dev/video node detection. And *then* I'll give the whole thing to test to @TonyMac32, who loves testing random VPU patches for Tinkerboards.

... May I know since when people working on RK3288 VPU knew this ? Did someone try to port the iMX VPU and found "Hey... this looks similar !" ? And, I know it's bad. If you got a mail from iMX, I'll remove the PDF @Igor. However, for the record, here's the VPU registers documentation : out.pdf

... So, just to see what are the latest LKML gossips, I went to LKML.org. Besides the common people throwing a tantrum because they provided their work under a license and want to rescind it, for whatever reasons, I saw this : Hardware-accelerated video decoders used through a firmware instead of hardware registers I skimmed that thread, by curiosity. Basically, Paul Kocialkowski and Nicolas Dufresne are talking about current developments in the Video decoders, and how to deal with angry closed blobs coming from nowhere. But then, Nicolas then threw this, out of nowhere : ... !!? Ok, let's search on the web for "Hantro G1". Maybe I'll find the Reference Manual for this chip. And I stumbled on this : https://github.com/linux4sam/gst1-hantro-g1 (Gstreamer implementation) https://github.com/linux4sam/g1_decoder Oookay... Maybe this doesn't work on RK3288 boards. I'll have to check. Still, they *REALLY* look similar : https://github.com/linux4sam/g1_decoder/blob/master/software/source/common/8170enum.h#L38 https://github.com/Miouyouyou/Mainline-VPU-V4L2-Edition/blob/master/rk3288_vpu_regs.h#L155 ROCKCHIP ! What the FUCK !? Why did you ask Google to develop a driver for your VPU, while the company already had all the documentation about your chip !? By the way, the chip in itself, is able to decode a good lot of formats : http://www.verisilicon.com/IPPortfolio_14_58_2_HantroG1.html

Instead of doing a proper packaging job, I decided to test the H264 decoder because... Hey, H264 ! If it works, it means we can actually use RK3288 boards to watch YouTube, Netflix and Twitch.tv, boosting productivity by 10x ! But, nah... the H264 is still a Work In Progress. While the basics work (Sending the V4L2 request, Getting an image back), I tried with a video that was lying on my PC HDD, their FFMPEG and mpv and... I got some weird blocks interlacing with frames replacing each other... It's not ready. But there's clear progress made. Still, the kernel from bbrazillon can be used for MPEG-2 decoding too, since it integrates Kwiboo's work, so I'll use this base, strip the changes to the bare minimum required by the V4L2 decoders, generate a patch, integrate it into my main build script and let everyone have fun with this. Then I'll retry with RK3399 boards.

Nice ! However, since Kwiboo actually patched FFMPEG to add V4L2 request support, the FFMPEG might actually be neeed to. I'll try to run the standard Debian packaging sequence you pasted.

V4L2, with the right kernel headers, is enough. In this version RKMPP isn't needed. Now, there's also a libva driver being developed. I didn't test it, though. It seems to be used in combination with VLC. I'll test it if I can get the H264 decoder working.

Interesting. I'll take a look at their work.

Anyway, I'll get some sleep and, tomorrow, I'll see if I can retest this on RK3399 devices like a NanoPC-T4 (and maybe the Orange Pi 3399... though my last try with the Orange PI and mainline kernels was terrible).

Nice ! I'll take a look at this branch and try to extract the minimal set, in order to test it on mainline kernels. Now, I guess that for H264, I'll need to port this : https://github.com/Miouyouyou/Mainline-Rockchip-VPU/blob/dev/based_on/rk3288_vpu_hw_h264d.c ? Is there test code available for RK3288 or RK3399 ? Or is it too soon ? Meanwhile, @JMCC , do you feel like trying to create a script, that automatically build FFMPEG + MPV with V4L2 Request support ? Or shall I ?

So : Here's the build script : https://github.com/Miouyouyou/RockMyy/tree/VPU-V4L2-5.x The FFMPEG version I used can be retrieved like this : Then, you'll have to apply this patch : https://github.com/Miouyouyou/RockMyy/blob/VPU-V4L2-5.x/0001-Patch-applied-to-compile-against-a-specific-Kwiboo-s.patch Then, you'll to compile FFmpeg... The part I love the best. It will take roughly 1 hour on a Tinkerboard. Just do something else, or find a way to cross-compile : *ALL* the options are *REQUIRED* if you want to build a shared library, with V4L2 Request support. Then, you need a media player and a MPEG-2 sample. For the sample, here it is : https://samplemedia.linaro.org/MPEG2/big_buck_bunny_480p_MPEG2_MP2_25fps_1800K.MPG For the media player, I used MPV (I took the 0.29.1 release). Compile it against your version of FFMPEG and, before installing it, get into the build directory and try it with the following command : You might want this patch to use the GLES renderer with MPV : https://gist.github.com/Miouyouyou/b9273ee3d949db3e1eb12f6bf99c1101

Okay, I got it working with MPEG-2 ... Well, at least the logs are coherent this time. You just have to be *sure* that FFMPEG *IS* compiled with v4l2_request enabled AND the option is also enabled in the kernel... I'll release the compilation script in a few minutes, along with the patch I applied to Kwiboo's FFMPEG branch, and then extract the minimum set of patch and apply them to mainline kernel in a few days. Note that this only for MPEG-2 H264 will take some time. I don't know if the RK3288 decoder supported VP8.

Ah, yeah, it happens with the "Default theme" when you click on the main tabs ("Giveaways", "Applications", ...)

Yeah, these little beasts are fast for MPEG-2... Too bad that the web is all about H264 and VP8 (´・ω・`　)