Myy

Members
  • Content Count

    316
  • Joined

  • Last visited

About Myy

  • Rank
    Embedded member

Contact Methods

  • Website URL
    https://miouyouyou.fr

Profile Information

  • Gender
    Not Telling
  • Interests
    https://www.patreon.com/Miouyouyou

Recent Profile Visitors

2405 profile views
  1. Ah, I didn't know it was already merged. So the actual patch should be accessed from here : https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/panfrost/panfrost_mmu.c?id=eb9d8ddbc107d02e489681f9dcbf93949e1a99a4 (Patch file : https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/patch/drivers/gpu/drm/panfrost/panfrost_mmu.c?id=eb9d8ddbc107d02e489681f9dcbf93949e1a99a4 )
  2. Ow. Let's see if anyone can run SuperTuxKart... Or a WebGL benchmark for a change ?
  3. Nice ! No more horrors in dmesg logs ?
  4. Do you have the entire dmesg that comes with it ? Maybe there's some message like a broken MMU or IOMMU. Or some other messages that might indicate that the problem is not directly within panfrost. Also, did you try this patch : https://github.com/jernejsk/LibreELEC.tv/blob/linux56/packages/linux/patches/amlogic/amlogic-0001-FROMLIST-drm-panfrost-Don-t-try-to-map-on-error-faul.patch This might just crash the driver earlier though. EDIT : The patch is actually mainlined. Here's the commit (and patch) : https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/panfrost/panfrost_mmu.c?id=eb9d8ddbc107d02e489681f9dcbf93949e1a99a4
  5. Looks like some memory unit not prepared correctly, based on the first faults. Did you try showing this to the folks at irc://#panfrost@irc.freenode.net ?
  6. I extracted the HDMI patch and added it to my repository. Tested it with my screen and it works... However, as I said, I got a very standard screen (1080p) So... now, the whole idea is how to make you test this patch. @TonyMac32 do you have some time this week to prepare a kernel with this patch ?
  7. Myy

    Mainline VPU

    Got it. It's this one : https://github.com/jernejsk/LibreELEC.tv/blob/updates/projects/Allwinner/patches/linux/0005-cedrus-improvements.patch#L706
  8. Myy

    Mainline VPU

    Ok, turns out that the kernel was unable to find the UUID I asked for the root partition, and was waiting "forever". So, it boots, but I still can't compile FFMPEG correctly. I'm trying to determine which patch added "num_entry_point_offsets" to "struct v4l2_ctrl_hevc_slice_params"
  9. Myy

    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.
  10. Hmm, I'll try to extract and test this patch, see if that doesn't generate issues with standard HDMI screens. Then see how to let you test it on your adapter. https://github.com/jernejsk/LibreELEC.tv/blob/updates/projects/Rockchip/patches/linux/default/linux-0006-experimental.patch#L610 I'm surprised by the outstanding amount of HDMI patches that LibreELEC.tv has for Rockchip. This might need an entire directory specific for HDMI patches at this point.
  11. Are you cross-compiling or compiling directly on the hardware ? In the second case, just set -march=, -mcpu= and -mtune= to native. Edit : Also forget about the FPU flags for ARMv8. Most ARMv8 processors are equipped with hardware FPU units.
  12. Greetings, Here's a quick and very dirty way to use the NVMe disk for the whole system, except the boot files and kernels which will be read from the SDCard. This method is UNSUPPORTED. Meaning that if you follow this procedure and your system broke, catched fire and start attacking you in your sleep, it's on you ! The reason I keep booting on the SDCard are : This makes boot issues easier to deal with since all the files are more easily accessible. It's easy to quickly read a SDCard from a PC using a SDCard reader USB dongle bought from the local store. Meanwhile mounting a NVMe<->USB readers are not that common. It's pretty much guaranteed that the bootloader knows how to boot a SDCard. The procedure is documented here : https://gist.github.com/Miouyouyou/e78f4caa9ce3fea72430dca57a00449b Here's a copy of its content : Moving most of the system (but not the kernel) onto the NVME disk This document describes how to make the system : boot on a SDCARD load the kernel from the SDCARD mount a NVMe partition as / use / for the whole system and applications In this document folder and directory mean the same thing. The whole idea is to be able to edit the boot files easily (kernel, boot configuration, ...) in case something goes wrong, while benefiting from NVMe read/write speeds for you daily application usage. The procedure described is not "THE BEST", just the one I used that worked in my case. Here are the steps I followed to do that : Prepare a SDCARD with an Armbian image, using Etcher. Install a NVMe M.2 disk on the rear side of the NanoPC T4. Put the SDCARD in the NanoPC T4 SDCARD slot. Boot Armbian and configure your first user. Note : The 'root' account password is 1234 on first boot Create a "Linux root (ARM 64)" partition (and maybe a swap partition if you want) on the NVMe disk. Note : Linux root (ARM 64) ID is B921B045-1DF0-41C3-AF44-4C6F280D3FAE Note : The disk can be accessed through /dev/nvme0n1 Note : I used cfdisk for that matter, but any decent partitioning software will do. Format the NVMe root partition using mkfs.ext4 For example, if you just made one partition, the device node will be : /dev/nvme0n1p1 and so the command will be : mkfs.ext4 /dev/nvme0n1p1 Mount your NVMe root partition on /mnt. For example, if you just made one partition, the device node will be : /dev/nvme0n1p1 and so the command will be : mount /dev/nvme0n1p1 /mnt Do a filesystem copy of / into /mnt, while ignoring special files created on boot-time : rsync -a -H --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} / /mnt Use blkid on your NVMe root partition to get its UUID. For example, if you just made one partition, the device node will be : /dev/nvme0n1p1. And so the command will be : blkid /dev/nvme0n1p1 In my case, the command output was : /dev/nvme0n1p1: UUID="cbe70e76-9690-4f69-ab6e-23b887531628" TYPE="ext4" PARTUUID="c4a2536b-5092-0b4b-8178-c4215a52ac4b" Edit /mnt/etc/fstab and replace the UUID part of the line about / by the UUID of your NVMe root partition, that you just got from the last command. The line in question is somewhat like this : UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 1 In my case, I modified it so that it looked like this : UUID=cbe70e76-9690-4f69-ab6e-23b887531628 / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 1 Do a copy of /boot/armbianEnv.txt like this : cp /boot/armbianEnv.txt /boot/armbianEnv.working Edit /boot/armbianEnv.txt and replace the UUID in the line rootdev=UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx by the UUID of your NVMe root partition. In my case, the line was modified like this : rootdev=UUID=cbe70e76-9690-4f69-ab6e-23b887531628 Reboot and see if it worked. If it didn't, you'll have to remove the SDCard from the NanoPC T4, read it from a Linux PC, mount the boot partition, delete boot/armbianEnv.txt and copy boot/armbianEnv.working over boot/armbianEnv.txt. Then you'll be able to retry the procedure from the point were we get the UUID of the NVMe partition (step 7). If it's working, though, it's not finished ! In order to make kernel upgrades possible, we'll have to link the NVMe root partition /boot folder to the SDCard root partition /boot folder. Use blkid on your SDCard root partition, in order to get its UUID. blkid /dev/mmcblk1p1 In my case the output was : /dev/mmcblk1p1: UUID="c5dcbfc7-886b-4c98-ac2a-4d26eec089e8" TYPE="ext4" PARTUUID="d808ef5d-01" Create a directory /sdcard : mkdir /sdcard Do a backup of your /etc/fstab : cp /etc/fstab /etc/working_fstab Add an entry to /etc/fstab to mount the content of the SDCard boot partition to /sdcard automatically. In my case the UUID of that partition was c5dcbfc7-886b-4c98-ac2a-4d26eec089e8 so the line added was : UUID=c5dcbfc7-886b-4c98-ac2a-4d26eec089e8 /sdcard ext4 defaults,noatime,nodiratime,commit=600,nodev,noexec 0 1 Adapt according to your configuration. Test your /etc/fstab configuration by doing : mount /sdcard If that doesn't work, check back your /etc/fstab. If you messed up, cp /etc/working_fstab /etc/fstab Backup the /boot directory : mv /boot /unused_boot Link your SDCard boot partition boot folder to /boot : ln -s /sdcard/boot /boot Reboot one last time And now you should be able to upgrade your kernel while booted on your NVMe disk, while still being able to access the upgrade kernel and boot configuration from the SDCard. This is very useful when a kernel upgrade broke your system. That way, you just have to remove the SDCard, read it from a Linux computer, replace the broken kernel or edit /etc/armbianEnv.txt to boot temporarily on the SDCARD in order to repair the issue. Improvements /sdcard should only be mounted when boot files have to be updated. This avoid softwares trying to access the SDCard for no reasons.
  13. Could you do this on the working part : cat /sys/devices/platform/display-subsystem/drm/card0/card0-HDMI-A-1/modes Also, by default, if you can connect the board via Ethernet to a DHCP server and then access tthat DHCP server (if you connect it directly to a box, check the box web UI, it generally has information about connected machines), you might be able to connect the Tinkerboard running a mainline kernel using : ssh root@ip_of_the_tinkerboard The default password is 1234
  14. Try to get a 4.4 kernel on this board and we'll try to analyze the HDMI (PLL) frequencies used by this kernel, and then see if we can replicate them on modern 5.x kernels. It seems that PLL configuration for HDMI resolutions other than 720p, 1080p, 1440p and 2160p are still not mainlined... However, I don't own any screen that differs from these resolutions, making it really hard to test.
  15. Hmm, there's no RAM leak visible on the logs... However, the panfrost driver is still spamming like crazy. Once the network drop happens, if you down and up the interface again, the system becomes unstable again ? Anyway, there seems to be three issues : * Panfrost spamming * Network drops * Potential memory leak leading to system crashes. I'll try to put up a network test and see if that also happen with 5.6 kernels.