• Content Count

  • Joined

  • Last visited

About Myy

  • Rank
    Elite member

Contact Methods

  • Website URL

Profile Information

  • Gender
    Not Telling
  • Interests

Recent Profile Visitors

2216 profile views
  1. 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.
  2. What does grep nvme_kthread /boot/* returns ? Same thing for grep 0xffffff8009c /boot/* ? 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. 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.
  3. That firmware seems to be part of Closed McBlobby family : However, a more legit source for this firmware would be : Give the find / command a try and, if possible, try it on a NVMe drive.
  4. 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 : 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 ?
  5. 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 ?
  6. 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).
  7. 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. 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.
  8. 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 : (Available on any ARM debian system) (GlibC - installed by default) (libdrm2) (GlibC - installed by default) (GlibC - installed by default) (libudev1) (libva-drm2) (libva2) (libva-x11-2) (libvdpau1) (libx11-6) (libxcb-shape0) (libxcb1) (libxcb-xfixes0) (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 : (Available on any ARM debian system) (libass9) (GlibC) (Available on any ARM debian system) (libdrm2) (libegl1) (libgbm1) (libjpeg1) (libluajit-5.1-2) (GlibC) (GlibC) (GlibC) So basically : apt install libass9 libdrm2 libegl1 libgbm1 libjpeg1 libluajit-5.1-2 zlib1g ffmpeg-mpv-dyn.tar.xz ffmpeg-includes.tar.xz
  9. 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.
  10. 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 : 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.
  11. Here's a first draft of the patches I pulled from bbrezillon tree : 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.
  12. ... 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
  13. ... So, just to see what are the latest LKML gossips, I went to 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 : (Gstreamer implementation) Oookay... Maybe this doesn't work on RK3288 boards. I'll have to check. Still, they *REALLY* look similar : 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 :
  14. 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, 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.
  15. 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.