Myy

The patch seems to have been backported in time for the 4.13.0 release and can now be omitted.

So the issue is now resolved in linux-next, which is one of the official git repository that pull the changes that will happen in the next version following the current Release or Release Candidate. I imported the patch and here it is : https://github.com/Miouyouyou/RockMyy/blob/master/patches/kernel/v4.13/0012-net-phy-Deal-with-unbound-phy-driver-in-phy_attached.patch The official patch being : https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=fcd03e362b1cd17de487953aac34f2d4574895cf

Let's make a topic dedicated to the latest issues with the latest Linux Release Candidate provided on the Linus Torvalds git repository. So, on the 4.13.0-rc6, I got a crash on boot on my MiQi devices due to some changes in the logging functions used by the STMMAC Ethernet driver. I reverted some of their changes by just commenting the new logging function. I'll try to get in touch with the person who wrote the commit that generated this issue, as he tends to roam in the #linux-rockchip IRC channel. Meanwhile, here's the patch : https://github.com/Miouyouyou/RockMyy/blob/master/patches/kernel/v4.13/0012-net-stmmac-Reverting-a-part-of-Use-the-right-logging.patch Here's the issue : https://github.com/Miouyouyou/RockMyy/issues/1 And here's the commit that generated that issue : https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c?id=fbca164776e438b639af592c522b8b0506b54dcc

Not until I can run Crysis on it. Also, the thing is, will my software (or the OS) be able to map more than 4GB without some additional TLB sorcery ? (￣〜￣　） Anyway, I guess I'll just rework my patch to set them to "okay" again, then, until I find a RK3288 board without any VPU chip integrated.

LPAE... If this "thing" is as well-done as it was on X86, that's clearly not a smart move. Managing tiny virtual special windows with a double dose of address translation just to map more than 4GB on systems where you should not need *that* much sounds pretty much useless. Anyway, the DTS files of Rockchip kernels actually set up the IOMMU to be "okay" directly from the DTSI file. It seems like that the VPU being absent is extremely exceptional on Rockchip 3288 systems. So, I actually did the same in my kernel now.

It should not be necessary. The Rockchip DRM package main purpose is to exploit DRI capabilities and the RGA 2D acceleration on Rockchip systems, but the RGA 2D acceleration was deemed inefficient for X11 purposes, and the DRI is not useful when testing DRM capabilities directly from a console.

The command to build most of the Rockchip repositories with a debian folder seems to be : dpkg-buildpackage -b -rfakeroot -us -uc That said, I would still highly recommend taking the .so library from their repository, put it in a folder, regenerate the appropriate links quickly and test GLES programs by invoking them like this : LD_LIBRARY_PATH=/path/to/the/library gles-program Installing the new OpenGL ES libraries in /usr/lib could generate serious issues. Testing DRM/KMS OpenGL ES programs, like glmark2, from a real console (CTRL+ALT+F1), or from weston (Wayland), will generally be easier than trying from X11.

Looking at Rockchip's code, I'm starting to wonder if the uart_rts0 GPIO was enabled at all when using their rfkill_bt driver. Maybe it was the reason ? However, in their DTS they initialize it with GPIOD_OUT_LOW, and I put GPIOD_OUT_HIGH in my code (since it's the value that's actually checked by the rfkill_bt driver). I don't know if I should put it to LOW again. The uart_rts0 GPIO don't have any "BT" prefix in their DTS but seems essential to get any communication working with the BT driver anyway.

So, in order to tackle this Tinkerboard issue, I'm trying to write a small Out-Of-Tree driver "bluetooth" driver that focus on enabling and disabling the right GPIO pins, using the RFKILL system as a control system. It does NOT do the UART/HCI communication part, as this should be delegated to BlueZ IMHO. Currently, the code needs to be double checked and then tested (in this order). The point of this driver is to be able to maintain it easily, and so has been heavily commented. Feel free to remove the comments if your own forks. The Makefile needs to be edited in order to use your own kernel tree path, and your own cross-compiler prefix. Once done, just type make to compile the module. This driver needs a different DTS section than the Rockchip one, in order to avoid conflicts, confusion and other issues with the Rockchip "rfkill-bt" driver. So, if anyone with a Tinkerboard has some time to spare, and have enough GPIO knowledge to be sure that the GPIO defined in the DTS and the code are the good one, etc...; Feel free to test my driver. If the driver seem to load correctly, check with the rfkill programs if you can unblock the "bt-gpio" device. Then, if you can, try this hacked HCI attach version or use the latest HCI attach tool provided by BlueZ to set up the device.

So, after understanding that half of the identifiers and function names in this VPU driver were very badly chosen, I found that the IOMMU DRM driver has already nothing to do with DRM at all. There's isn't a single DRM API call in this part of the driver. This part should have been called IOMMU DMA OPS because that's the only thing it's dealing with. Now, I found that some parts of the failing code were actual copy paste of IOMMU code in the kernel. However, trying to use the right kernel API proved to be quite difficult with Rockchip systems. To say the least, most of the new IOMMU DMA API don't work or will even crash the machine, with Null Pointer Dereference most of the time. I don't know if that's because the VPU IOMMU isn't initialized correctly or something. Playing with IOMMU Groups -- which seem to be "The Right Way" according to different LWN documents I found -- proved to be much worse. By default, the IOMMU Groups affected to the VPU IOMMU do not seem to have any IOMMU Domain preset, failing the iommu_get_domain_for_dev calls and most of all the new API calls. Trying to force a domain to these groups freeze the system... Now, my current plan is now to generate a toy version of the driver that concentrate on the biggest issues with the real driver : Write a little driver client that tries to pass a DMA Buffer allocated on the GPU through DRM, using PRIME File Descriptors, to the VPU; Try to map the content of the DMA Buffer, represented by that File Descriptor, in the VPU memory using the IOMMU and the DMA API; Then, whether that toy version fails or not, contact Mark Yao or "djkurtz", the Google guy who also worked on the Rockchip IOMMU, and see if they can provide at least some hints on how to perform these operations correctly using the Rockchip IOMMU API of mainline kernels. Once done correctly, I'll try to reimport the code in the driver and see if that resolves the situation. At the same time, I'm trying to find the real VPU documentation, that defines all the registers used by the VPU, what they're for, ... Currently trying to figure out these things from the non-working VPU driver is way to cumbersome. Like stated before, most of the identifiers (function names, variables) are badly chosen and barely reflect their use or real utility, if at all. The Wiki only provides the MPP documentation, that provides no informations about how to code a driver for the VPU itself, like which addresses should be written, which addresses should be read, ... There's some informations in the reference documents I got a while ago, but that's it. These documents refer to others documents named : VDPU_SWReg_Map.pdf and VEPU_SWReg_Map.pdf which should provide the VPU registers list and their uses. However I cannot find these documents.

Are you sure that's not a naming issue ? Like using mmcblk0 instead of mmcblk1 or something ? That's a common issue I have when switching between 4.4 and mainline kernels on my RK3288 boards.

Yeah, in the case of Rockchip 3288 boards, which are quite versatile, this is evil IMHO. Worst case, check if the board is the ASUS Tinky. Now I think that, for the best case, the definition should be done in the DTS files and, if needed, additional detection code should be added in the i2c drivers used. The static init seems to be only good if you're selling one special hardware which has all the things integrated and don't have any alternative (or the alternatives also have the same I2C hardware) like a TV + DVR recorder or some industrial thingy. See Method 1 and Method 2 for details : http://elixir.free-electrons.com/linux/latest/source/Documentation/i2c/instantiating-devices

I can give a look at the patches if you want. For the DTS, unless you've changed the DTSI, it should not have any impact on the MiQi.

Yeah... I still don't know why they nuked the "arm,mali-midgard" property. The TAMIL driver was never released (and might never be at this rate), so the only kernel driver for Mali Midgard GPU is the one provided by ARM, which use that property and seems to be compatible with ALL the Midgard chips, whether it's the first, second or third generation. The other two properties are really useful for user support, but dropping things and break the only driver existing for that hardware is dodgy. That said, that does not require too heavy changes and I posted my patch on the ARM Community, along the other ones, so the driver might incorporate these fixes in future releases, who knows. https://community.arm.com/graphics/b/blog/posts/unofficial-patches-for-the-mali-midgard-kernel-drivers-r19p0-on-linux-4-13-0-rcx

So, if you use the mainline DTSI files, you'll encounter an issue when loading the Mali Midgard GPL kernel module, since the main ARM kernel maintainers changed how the "compatible" properties of Midgard GPU nodes should be defined. Don't ask me why, they created an entire documentation stating that now the Mali Midgard GPU nodes have to harbour the chip series number, a vendor-specific statement, and drop the "arm,mali-midgard" property. The additions are nice, since they allow a quick detection of the chip number and the chip vendor using /sys nodes names. However, turns out that the Mali kernel driver used the dropped property to detect the GPU. So, I've patched the driver to detect T700 and T800 chips. I forgot the T600 ones, I'll update the patch on the next release. https://github.com/Miouyouyou/RockMyy/blob/master/patches/Midgard/r19p0-01rel0/0005-Added-the-new-compatible-list-mainly-used-by-Rockchi.patch The patch is quite simple : diff --git a/drivers/gpu/arm/midgard/mali_kbase_core_linux.c b/drivers/gpu/arm/midgard/mali_kbase_core_linux.c index 27dcd9c1..cc4932a4 100644 --- a/drivers/gpu/arm/midgard/mali_kbase_core_linux.c +++ b/drivers/gpu/arm/midgard/mali_kbase_core_linux.c @@ -4742,6 +4742,12 @@ static const struct dev_pm_ops kbase_pm_ops = { static const struct of_device_id kbase_dt_ids[] = { { .compatible = "arm,malit6xx" }, { .compatible = "arm,mali-midgard" }, + { .compatible = "arm,mali-t720" }, + { .compatible = "arm,mali-t760" }, + { .compatible = "arm,mali-t820" }, + { .compatible = "arm,mali-t830" }, + { .compatible = "arm,mali-t860" }, + { .compatible = "arm,mali-t880" }, { /* sentinel */ } }; MODULE_DEVICE_TABLE(of, kbase_dt_ids);

Indeed. That's the main reason why I'm using DRM/KMS OpenGL ES code with the latest Rockchip libmali (with GBM support) to test the 3D drivers. Now that glmark2 has incorporated my patches, it should be easy to compile and use on any board with working DRM and OpenGL drivers. You might want to give it a try. Compile it like this : ./waf configure --with-flavors=drm-glesv2 ./waf ./waf install # Not mandatory, you can execute the binary from its build folder Then LD_LIBRARY_PATH=/path/to/mali/drivers glmark2-es2-drm You'll certainly be limited to VSync, however the score on the crystal bunny and the (ugly) terrain should provide some good statistics on the GPU.

Nice catch ! This might prove useful, yeah. Reading this document, I still don't understand why they're dead focused on having technology specific buffers, where all those techs use DMA buffers in the end though. At least internally. I'm currently looking at DRM PRIME and trying to understand if you can, as a user-space application, allocate a DMA buffer, pass it to something else (user-space or kernel-space) so that it writes some bitmap in it and then display the bitmap on the screen using DRM calls. If that can be done, I'm throwing out the DRM/ION part of the VPU driver and let the user-space app/MPP do the buffers allocation.

Is it really resolved ? On the first commands it looked like it was setting up an ipv6 node, but on the successful one, it looks like it set up an ipv4 node. Is that all right ?

Could you provide the output of the following command too : zcat /proc/config.gz | grep -i fwmark Could be a missing kernel option.

Sometimes I'm really wondering if these two guys are working for Rockchip, or are just big Rockchip fans. （￣〜￣；） Anyway, I'll see if that can be done using the DRM PRIME technology, instead of playing with "Yo Moos Moos" everywhere. I thought that the whole FD thing would bring issues, but looking at the ION part and how the old ION API worked, it seems that the FD just points to DMA buffers anyway. So getting the *dmabuf from the fd roughly equates to dma_get_buf(fd). DMA Buffers can then be used by DRM Prime calls. I still need to understand what the vcodec_service expects from these "IOMMU" parts, though. That said if anyone knows any other ARM oriented VPU driver that integrates with the DRM drivers, let me know. I'll take a look at how they do things and if they use some standard API I neglected.

So... On the linux-rockchip IRC channel, stdint advised me that the DRM IOMMU code of this driver is unmaintainable and should be removed and rewritten. At the same time wzyy2 told me to try making this driver a bit more generic, since too much raw API are used, which is asking for bugs and crashes. Therefore, here I am, creating a branch named DRM_rewrite in my rockchip-vcodec repo, in order to start rewriting the DRM IOMMU code, which is not my specialization, but I'll give it a try. If anyone with knowledge about IOMMU workings wants to play with the code, it's here. I'm also documenting a few things in the Wiki associated with the repository.

Indeed, wzyy2 tend to prepackage the mali drivers in the rk-rootfs-build repository, but the one in the libmali repository seems to be updated more regularly. That said, if the drivers work, better not update them. Too bad for ARM, since their DDK was more up to date (obviously) and incorporated all the techs possible. That said, they often say they won't provide the drivers for any board and then release them anyway a year later. Now, it looks like the screenshot was eaten by a grue. (´・ω・`　) You might be interested by the new Rockchip wiki here. It has various information on how to compile or install certain Rockchip specific components on common distributions : http://opensource.rock-chips.com/ This might help you if you're stuck with few things.

Concerning OpenGL ES tests : You might need to download one of these drivers in a folder, create the various libGLESv1_CM.so{,.1} libGLESv2.so{,.2} libOpenCL.so{,.1} libEGL.so{,.1} links to the libmali you downloaded and then set LD_LIBRARY_PATH when testing OpenGL ES little programs. I might be missing a few file links... So, if you downloaded libmali-midgard-4th-r13p0-gbm.so in /tmp/test-mali for example, this should do the trick : cd /tmp/test-mali for link in libGLESv1_CM.so{,.1} libGLESv2.so{,.2} libOpenCL.so{,.1} libEGL.so{,.1}; do ln -s libmali-midgard-4th-r13p0.so $link; done LD_LIBRARY_PATH=/tmp/test-mali ./es2gears Change es2gears by the name of that the OpenGL ES program binary you want to test of course. Note that if /dev/mali0 is not read/writeable by your user, the OpenGL ES program might fail with a Mali Driver error message telling you that you do not have the right GPU. It's a permission issue in that case. If you don't have a /dev/mali0, it's a driver integration issue however. No Vulkan support for the moment, however. The ARM guys do not seem to have released any driver for the Firefly RK3399. (´・ω・`　)

Alright, if any amateur code sleuth wants to investigate this issue with me, I'm logging my findings here : https://github.com/Miouyouyou/rockchip-vcodec/issues/3

Alright, issue resolved, turns out that you have to compile MPP with the options -DHAVE_DRM=ON and -DRKPLATFORM=ON . The second option appears when you do cmake -L /path/to/mpp but not the first one, of course. If you miss the HAVE_DRM option, MPP will be compiled with ION support instead ! Unusable on Linux systems with DRM ! Isn't that nice ? Anyway, got it compiled correctly, launched the MPP decoder tests and BOOM ! https://ghostbin.com/paste/kuum8 Now, I'll have to figure out why it crashed like this...