Myy

  • Content Count

    364
  • Joined

  • Last visited

Reputation Activity

  1. Like
    Myy reacted to Werner in Patchfolder cleanup helper   
    The output for target files which are affected by multiple patches is now better.

  2. Like
    Myy got a reaction from Werner in Patchfolder cleanup helper   
    Interesting approach.
     
    I'd just like to mention that factorizing is required, if the patches apply to the same file AND the same blocks (functions, DTS, ...).
     
    If you create THAT big patch that add 50 entries to a single DTS file, and the mainline DTS file gets updated with the addition of, like, 3 entries out of the 50, then you won't be able to apply your big patch AND you'll need to rework it.
    Since you won't be able to apply it again, you can either pray that 3-way merging works, or you'll have to do a copy-paste of every missing entry from the patch, back to the DTS file AND regenerate a patch from there.
     
    Now, if you got 5 patches affecting "that same function" or "that same DTS block", then yes, merging is required.
     
    Anyway, this tool should greatly help in reducing the number of patches. Just don't do a blind factorization, it will back-fire very quickly.
  3. Like
    Myy reacted to Werner in Patchfolder cleanup helper   
    Ever since patchfolders were created for different branches and different board families it has become more and more a nightmare to maintain these folders and keep them clean.
     
    Instead of taking the approach to clear one or more of these folders by myself, last but not least due to lack of necessary skills, I was thinking maybe I can provide some tools that make such tasks a little easier for somebody else.
    Last but not least was (and still is) this a perfect opportunity to pratice with my quite new Python skills.
     
    https://github.com/EvilOlaf/refactorpatches
     
    What this script basically does is break down all patches in a certain folder and check which files are targeted by each individual diff (if you choose to split them up) and sort the output by the target file.
    This way it should be an easy thing to merge patches that affect the same file and therefore it is no longer necessary to take care about the order to apply them.
     
    Requirements from apt: patchutils, python3
    Requirements from Pypi: none but just make sure the prettytable.py is in the same folder as main refactor.py.
     
    I have tested this with random patch folders for kernel patches and for what it is expected to do at the current state it seems to just work as it should.
    There is still a ton of room for improvements.
     
    Let me know what do you think or if it is useful at all. Even if it is not I had fun coding and using Python
     

  4. Like
    Myy reacted to Kwiboo in Mainline VPU   
    No problems! :-)
     
     
    I can recommend you to look at https://github.com/Kwiboo/linux-rockchip/commits/linuxtv-rkvdec-work-in-progress that is the branch that will continue to see updates as I prepare ongoing work for upstream.
    With this updated branch (work rebased on top of media_tree master) and latest 4.2.2-rkvdec ffmpeg branch vp9, h264 (high 10 and high 422) and hevc (main 10) should be usable.
    There is still one bit not properly being configured for hevc so there are some videos that produce small artifacts while decoding.
     
    Hoping to have initial patchset with focus on rkvdec fixes and rkvdec/hantro support for h264 interlaced/field encoded on media mailing list before the weekend is over :-)
  5. Like
    Myy got a reaction from Werner in No HDMI signal on Tinkerboard Samsung TV   
    This might be due to the lack of some YUV configurations support in the Rockchip DRM drivers used in mainline kernels.
    I'll try some new HDMI patches next week, against mainline kernels, see if that resolve these kind of situations.
  6. Like
    Myy got a reaction from aaditya in Mainline VPU   
    Same thing here.
     
    As always, I think it will come down to :
     
    Generating a H264 sample frame Looking at the documentation about how to send this to the driver Get the result  
    But everytime I think about the 2 first steps, I'm like... "Ugh... do I really have to do this ?".
     
    If that's still the case with the 5.7, I'll try to build a test framework.
     
    Quite frankly, I looked at the FFMPEG patches and I still don't know how the FFMPEG select the right decoder in the first place.
    As with all big projects, there might be a few "magic tricks" here and there to do the whole auto-selection of each component with the least amount of code.
    And that's without counting the fact that "ffmpeg -hwaccels" list another kind of "hwaccels" so you won't know anything based on that output.
     
    I also heard there were a "libva" library built around V4L2 request system. I guess this might worth a try, if it still exists and is still developed.
  7. Like
    Myy reacted to mtr46 in RK3288 device tree overlays   
    The problem has been solved.
    I rewrote the DTS as follows:
     
    / {
        w1 {
            compatible = "w1-gpio";
            pinctrl-names = "default";
            pinctrl-0 = <&w1_gpio_pins>;
            gpios = <&gpio0 17 0>;
        };
    };
    &pinctrl {
        onewire {
            w1_gpio_pins: w1-gpio-pins {
                rockchip,pins = <0 17 0 &pcfg_pull_up>;
            };
        };
    };
     
    I am now able to use 1-wire.
     
    results:
    root@tinkerboard:/sys/bus/w1/devices# ll
    total 0
    drwxr-xr-x 2 root root 0 Apr 23 19:49 .
    drwxr-xr-x 4 root root 0 Apr 23 19:49 ..
    lrwxrwxrwx 1 root root 0 Apr 23 19:50 28-031590341bff -> ../../../devices/w1_bus_master1/28-031590341bff
    lrwxrwxrwx 1 root root 0 Apr 23 19:50 28-0416505667ff -> ../../../devices/w1_bus_master1/28-0416505667ff
    lrwxrwxrwx 1 root root 0 Apr 23 19:49 w1_bus_master1 -> ../../../devices/w1_bus_master1
    root@tinkerboard:/sys/bus/w1/devices# cat 28-031590341bff/w1_slave
    61 01 4b 46 7f ff 0c 10 57 : crc=57 YES
    61 01 4b 46 7f ff 0c 10 57 t=22062
     
    Regards,
     
  8. Like
    Myy got a reaction from chwe in Mainline VPU   
    So, I tried to adapt @Kwiboo and @jernej patches on my 5.6 branch, but this made the kernel fail to boot for no visible reason.

    Since I were able to boot it without the VPU patches, I'm convinced that it's their readaptation that broke something.

    The patches applied are here : https://github.com/Miouyouyou/RockMyy64

    If someone wants to play with them and determine which one break the boot process.



     
  9. Like
    Myy reacted to jernej in Unable to make Panfrost work on H6   
    @Myy small advice - make links to https://github.com/LibreELEC/LibreELEC.tv because I often delete branches which were already merged. linux56 branch will be removed soon.
  10. Like
    Myy reacted to Werner in Unable to make Panfrost work on H6   
    Sure thing.
     
     


  11. Like
    Myy reacted to Werner in Unable to make Panfrost work on H6   
    Holy shit. It is running!

  12. Like
    Myy got a reaction from aaditya in Mainline VPU   
    So, I tried to adapt @Kwiboo and @jernej patches on my 5.6 branch, but this made the kernel fail to boot for no visible reason.

    Since I were able to boot it without the VPU patches, I'm convinced that it's their readaptation that broke something.

    The patches applied are here : https://github.com/Miouyouyou/RockMyy64

    If someone wants to play with them and determine which one break the boot process.



     
  13. Like
    Myy reacted to Igor in Armbian v20.05 (Kagu) Planning Thread   
    For those who couldn't made it, meeting logs: https://freenode.irclog.whitequark.org/armbian/2020-04-04 Meeting summary goes directly into Jira issues/bugs and the actual work. 
     
    Thank you all for attending the meeting!
  14. Like
    Myy got a reaction from chwe in RK3399 : Crashs dumps   
    In order to enumerate the major issues that are *still* valid now, I'm creating a 'crash dump' thread.
    The idea is simple, if your RK3399 board crashed recently, you just :
     
    Write what happened during the crash; Provide the link you got from sudo armbianmonitor -u , after the crash happened; Provide the content of /var/log/kern.log (if this file is present on your system) (attach it or copy the content on pastebin and link it here).  
    No discussion here.
    Feel free to create a new dedicated thread afterwards to talk about the problem you encountered.
     
    Minor issues are welcome too, if they trigger a BUG message in your logs. Just state that it's a minor issue.
  15. Like
    Myy reacted to Kwiboo in Armbian v20.05 (Kagu) Planning Thread   
    Yes, I have had VPU working on 5.4 kernel since the new year started, my test images from 31 dec / 1 jan at http://kwiboo.libreelec.tv/test/ should "work", at least for MPEG-2, H264 and VP8 codecs on RK3288, RK3328 and RK3399.
    The VPU patchset used in LibreELEC has not been touched/rebased for 5.5/5.6 yet, but I am hoping to get some time to work on that later this weekend and next week.
  16. Like
    Myy reacted to Werner in Armbian v20.05 (Kagu) Planning Thread   
  17. Like
    Myy reacted to Igor in Armbian v20.05 (Kagu) Planning Thread   
    Our next release date is coming and perhaps its time to discuss what to push into 20.05, what not, resolve open questions and distract from most used keyword for past few weeks.
     
    @Myy @TonyMac32 @balbes150 @piter75 @sfx2000 @ebin-dev @count-doku @chwe @ning @lanefu @gprovost @aprayoga @5kft
    @JMCC @Werner @karabek @martinayotte @tkaiser @selfbg @Siraj ... to name just a few which might find this move useful  
     
    I am preparing a meeting on IRC in Saturday at 1 pm GMT - this is reasonable good timing for US / EU folks. The idea behind this meeting is that (ideally) everyone, who will be present, quickly present (in alphabetical nick order) what they are working (not working on anything is equally legit) on followed by a discussion. If a feature, project or a fix can be pushed into this release. Plus answer and decide on other open questions. You are welcome to expand this with a PR/change document directly. This way we could - on a long run - improve all project parameters.

    As my example -  what I am currently working and IMHO could be implemented by 20.05:
     
    - setting up auto test facility, software and hardware which is a great support tool for making releases. It is already helping me finding bugs.
    - merging mainstream kernel config in the non-hardware areas could go into this release
    - firmware split up with @ning
     
    ... more Jira's during a week.
     
    Ideally it would be that prior to this meeting you write into Jira what you are working and join discussion about your task/project/idea with a link - who does not have access shall PM to @lanefu or @Igor - reviewing and prioritising goes faster and better with Jira.
     
    Welcome!
  18. Like
    Myy reacted to Meier in Infrequent RockPro64 freeze (kernel NULL pointer)   
    The boot failure is no longer an issue currently, after updating to Armbian Ubuntu 18.04 and using overlayroot, but the nvme spinlock keeps happening frequently. I noticed that it is mostly during intense writing to the SSD, which heats up, the system freezes and never comes back up. Strangely enough, the SSD is then still under constant load and does not cool down.
     
    I ran a dedicted stresstest with the tool stressdisk with the following script (it includes our own fancontrol tool):
    #!/bin/bash apt update -y apt install -y tmux unzip smartmontools mkdir src && cd $_ wget https://github.com/ncw/stressdisk/releases/download/v1.0.12/stressdisk_1.0.12_linux_arm64.zip unzip stressdisk_1.0.12_linux_arm64.zip chmod +x stressdisk mv stressdisk /usr/sbin wget https://github.com/digitalbitbox/bitbox-base/releases/download/wip/bbbfancontrol.tar.gz tar xvf bbbfancontrol.tar.gz chmod +x bbbfancontrol mv bbbfancontrol /usr/sbin/ echo "/dev/nvme0n1p1 /mnt/ssd ext4 rw,nosuid,dev,noexec,noatime,nodiratime,auto,nouser,async,nofail 0 2" >> /etc/fstab mount -a mkdir -p /mnt/ssd/stressdisk tmux new-session -d 'watch smartctl -a /dev/nvme0n1' tmux split-window -h 'stressdisk cycle /mnt/ssd/stressdisk' tmux split-window -v 'htop' tmux split-window -v 'bbbfancontrol -v' tmux -2 attach-session -d Using the RockPro64 with Armbian and writing heavily on a Samsung SSD (connected with an PCIe M.2 adapter), I am able to consistently freeze the system within minutes. See video here:
     
    Jul 18 08:35:24 rockpro64 kernel: Unhandled fault: synchronous external abort (0x96000210) at 0xffffff8009cc801c Jul 18 08:35:24 rockpro64 kernel: Internal error: : 96000210 [#1] SMP Jul 18 08:35:24 rockpro64 kernel: Modules linked in: af_packet lz4hc lz4hc_compress zlib snd_soc_rockchip_hdmi_dp lzo rk_vcodec zram ip_tables x_tables autofs4 phy_rockchip_pcie Jul 18 08:35:24 rockpro64 kernel: CPU: 3 PID: 261 Comm: nvme Not tainted 4.4.182-rockchip64 #1 Jul 18 08:35:24 rockpro64 kernel: Hardware name: Pine64 RockPro64 (DT) Jul 18 08:35:24 rockpro64 kernel: task: ffffffc0e4e13800 task.stack: ffffffc0dfb9c000 Jul 18 08:35:24 rockpro64 kernel: PC is at nvme_kthread+0xac/0x1d8 Jul 18 08:35:24 rockpro64 kernel: LR is at nvme_kthread+0x78/0x1d8 Jul 18 08:35:24 rockpro64 kernel: pc : [<ffffff80087564cc>] lr : [<ffffff8008756498>] pstate: 20000145 Jul 18 08:35:24 rockpro64 kernel: sp : ffffffc0dfb9fd60 Jul 18 08:35:24 rockpro64 kernel: x29: ffffffc0dfb9fd60 x28: ffffffc0df92ed00 Jul 18 08:35:24 rockpro64 kernel: x27: 0000000002080020 x26: ffffffc0ebaa0228 Jul 18 08:35:24 rockpro64 kernel: x25: ffffff80091ff0f0 x24: ffffff80091ff0f0 Jul 18 08:35:24 rockpro64 kernel: x23: ffffff8008755310 x22: ffffff80091ff0d8 Jul 18 08:35:24 rockpro64 kernel: x21: 0000000000000007 x20: ffffff8009cc801c Jul 18 08:35:24 rockpro64 kernel: x19: ffffffc0ebd1d400 x18: 0000000000000000 ... ... Jul 18 08:35:24 rockpro64 kernel: Unhandled fault: synchronous external abort (0x96000210) at 0xffffff8009cc8000 Jul 18 08:35:24 rockpro64 kernel: Bad mode in Error handler detected, code 0xbf000002 -- SError Jul 18 08:35:24 rockpro64 kernel: BUG: spinlock lockup suspected on CPU#3, nvme/261 Jul 18 08:35:24 rockpro64 kernel: lock: 0xffffff8009141870, .magic: dead4ead, .owner: nvme/261, .owner_cpu: 3 Jul 18 08:35:24 rockpro64 kernel: CPU: 3 PID: 261 Comm: nvme Not tainted 4.4.182-rockchip64 #1 Jul 18 08:35:24 rockpro64 kernel: Hardware name: Pine64 RockPro64 (DT) Jul 18 08:35:24 rockpro64 kernel: Call trace: Jul 18 08:35:24 rockpro64 kernel: [<ffffff80080882b0>] dump_backtrace+0x0/0x1bc Jul 18 08:35:24 rockpro64 kernel: [<ffffff8008088490>] show_stack+0x24/0x30 Jul 18 08:35:24 rockpro64 kernel: [<ffffff8008587fec>] dump_stack+0x98/0xc0 Jul 18 08:35:24 rockpro64 kernel: [<ffffff8008106164>] spin_dump+0x84/0xa4 Jul 18 08:35:24 rockpro64 kernel: [<ffffff8008106300>] do_raw_spin_lock+0xdc/0x164 ... ... https://pastebin.com/1UeCiHDW
     
    Using the smartmontools and physical temperature measurements, we can observe that the first chip on the Samsung 970 EVO (1TB) SSD gets up to 95 degrees celsius hot before crashing. With the exact same image, board and adapter I tried other M.2 SSDs as well. Interestingly, the chip on a Samsung 970 EVO (500 GB) got up to 107 degrees celsius, but did not crash.
     
    Other SSD got not as hot and had no issues with stress tests:
    * Intel 660p (512 GB and 1 TB): ~80 degrees celsius, physical measurement only
    * Crucial P1 (512 GB and 1 TB): ~75 degrees celsius, physical measurement only
    * Western Digital Black (500 GB): ~70 degrees celsius, physical measurement only
     
    So this issue might be related to that specific SSD. I'm still surprised that the Samsung SSD do not throttle at all, IMHO they never should get that hot in the first place.
  19. Like
    Myy reacted to gounthar in Ramblings and progress with the RK3399   
    Thanks for these commands. They helped me getting my board out of a strange mode where it only displayed hw 0 0 0 0 0 0 0 0 0 0 and powerOn "someNumbers". Before that, I could not get into MASKROM mode anymore, nor in LOADER mode... It appeared kind of bricked to me.
    By the way, I read there that one could get into MASKROM mode from software by zeroing part of the boot partition.
    That's what got me into that "almost bricked" mode.
    If anyone has the correct sequence of commands that could do it, I will use it from now on.
  20. Like
    Myy got a reaction from gounthar in Ramblings and progress with the RK3399   
    Alright, turns out that the
    /path/to/your/rkdeveloptool rd # Reboot step in my procedures wasn't rebooting the board anyway.
    So, basically, when in Maskrom mode (the mode you are in when the serial console is quiet, or when you keep the "Recovery" button pushed with the Right U-Boot), all writes are "as-is".
    If you reboot (unplug and plug the power cable back again) with a Loader, a Firmware and the Trust image, you'll get into a special "rockusb" mode that offset everything by 0x2000 sectors (0x2000 * 512 bytes).
     
    Since I'm not interested in that special rockusb mode, here's the "right" process for installing a U-Boot and Trust.img when you are in "quiet" mode :
     
    /path/to/your/rkdeveloptool db /path/to/RK3399MiniLoaderAll_V1.05_DDR600MHz.bin # Write the Bootloader /path/to/your/rkdeveloptool ul /path/to/RK3399MiniLoaderAll_V1.05_DDR600MHz.bin # Which is also their firmware /path/to/your/rkdeveloptool wl 0x4000 /path/to/uboot.img # Write the U-Boot image /path/to/your/rkdeveloptool wl 0x6000 /path/to/trust.img # Write the Trust bits # "Turn it off and on again" by unpluging and plugging the power cable back (Either the USB-C cable or the power plug) # Rebooting through the little button generate "Tinkerboard"-esque issues with the eMMC, which won't be properly power up anymore.  
    Now, if you already have an eMMC image, you can do this instead :
     
    /path/to/your/rkdeveloptool db /path/to/RK3399MiniLoaderAll_V1.05_DDR600MHz.bin # Write the Bootloader /path/to/your/rkdeveloptool ul /path/to/RK3399MiniLoaderAll_V1.05_DDR600MHz.bin # Which is also their firmware /path/to/your/rkdeveloptool wl 0 /path/to/eMMC.img # This will be STUPIDLY slow. You'll have to wait betweens 10 and 30 minutes. # Unplug and plug the power cable back again, after the command finishes.  
    I tested successfully these last steps and, therefore, have been able to directly flash my semi-working Armbian installation based on the Firefly RK3399 image.
     
    So, the current step now is "Getting a Rockchip kernel working correctly with this board".
  21. Like
    Myy reacted to jernej in The VPU driver   
    There is also VP9 decoding IP core , which is present in Allwinner H6, NXP i.MX8 and I think Rockchip has it too. It may be connected to Hantro and Google, but I'm unsure who is the original author.
  22. Like
    Myy reacted to JMCC in The VPU driver   
    Correct me if I'm wrong, but I understand that the new V4L2 driver only supports HW decoding, not encoding, right?
     
    In that case, IMO the usefulness of an standalone FFmpeg is very limited.  What I mean is that you won't get a noticeable benefit in transcoding with FFmpeg if you only accelerate the decoding. Not to mention possible colorspace conversion limitations etc (I think I bumped into some of those with the "old" RKMPP FFmpeg implementation).
     
    On the other hand, I see the real usefulness of that when FFmpeg is used as part of media players such as MPV or Kodi. And, in those cases, I always found it easier and more efficient to compile its own version of FFmpeg with the app, than link it against the system libs.
     
    So my opinion is that it is better to leave alone the system FFmpeg debs,  and compile the new version on a separate directory; that way it will not break other FFmpeg-dependent apps, such as video editors etc.. And let the media players use their own FFmpeg (after all that is what they normally recommend in their compilation instructions), and apply the patch there when necessary.
  23. Like
    Myy got a reaction from JMCC in The VPU driver   
    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.
  24. Like
    Myy got a reaction from JMCC in The VPU driver   
    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.
  25. Like
    Myy got a reaction from TonyMac32 in The VPU driver   
    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.