Myy

The boot went : Tiut ! I guess that you get nothing after that ?

Ah, yeah, the boot.scr is the binary file and boot.cmd is the one used to generate it so comment the ramdisk line in the boot.cmd and regenarate the boot.scr... if the kernel doesn't boot of course.

Also try to comment the initrd line in the boot.scr if it doesn't boot, just to see if that changes anything...

I don't have my MiQi here so I can't paste the extlinux/extlinux.conf I'm using. Still, instead of copying zImage bluntly, you could do cp zImage /boot/Myy-Kernel and then configure your bootloader to boot Myy-Kernel instead of zImage

The only thing that *might* generate issues would be the initrd. But I don't think that it would cause the system to not boot and not print anything on the serial output. Now, since you got a working kernel, try to list the modules used by your system, just in case |`・ω・)ノ . Also try to use the rk3288-miniarm.dtb too, since we're sure that it works.

Did you try using the rk3288-tinker.dtb provided with my build, or a 4.14.x ready rk3288-miniarm.dtb ? If you use a 4.13 or lower version DTB, it might fail to boot due to Rockchip 32 bits DTS using 64 bits addressing now, in order to use LPAE on some 32 bits boards. LPAE provides the ability to use more than 4 GB of memory on 32 bits systems, through magic, memory windows and ugly hacks. Anyway, I tested my latest release (4.14.0-rc7) with glmark2 and the Rockchip's r14p0-wayland user-space binary drivers and it works. I'll try to install Rockchip xserver and test glmark2 on X11 this week, if I got the time. During these tests, I discovered the magic of chvt, which changes the current virtual terminal displayed on the screen, which is very useful when you have control on a machine with SSH access, but no USB keyboard plugged on the machine, and want to switch to a terminal from X11. So basically instead of trying to find a keyboard, plug it and hit CTRL+ALT+F1, you just have to type : sudo chvt 1 I also checked that using a shitty micro-USB cable will cause the MiQi to reboot instantly when doing 3D intensive work. Yay ! Remember kids, don't do drugs use bad micro-USB cables !

From what I'm seeing, it looks like you only have 4.13.9 kernels... At worst, you can add an extlinux/extlinux.conf and have U-boot uses that instead. You'll lose the clean update system and will have to edit your extlinux.conf by hand every time you want to add a boot option, though. I'll try to provide an example tomorrow.

Hmm... I remember that there's a ls and a cat command with U-Boot but their use are quite awkward. Something like ls mmc1:1 / or something like that. Anyway, I'll investigate this tomorrow. Meanwhile, if you can mount your MMC through USB, using the good old ums 0 mmc 1 command and paste the content of /your/mounted/mmc/boot/boot.scr and the content of ls -1 /your/mounted/mmc/boot

That's some interesting tidbits. Last time I tried, the wayland support was good when using weston and was utter garbage when testing with kwin and mutter, which need to be compiled and debugged intensively in order to understand the real issues. However glmark2-es2-drm worked, once I patched it. For example, kwin_wayland --drm can fail if logind and dbus are not started, while providing no useful error messages. Not counting that their graphic card detection system was a bit simplistic, the last time I checked.

Well, I pushed an update of the rc4 on the GotNoScreenToTest. Here's the prebuilt one. I should be able to buy a nice HDMI screen in November, and fully resume the MiQi kernel maintainance. Meanwhile, I don't know how to get to this resolultion AND I think that, if you can get the GLES drivers running correctly, you might be able to use something like kmscon in order to get a DRM/KMS/GL accelerated console that you can configure at the resolution you want, instead of relying on some obscure emulated framebuffer configuration.

Found the real culprit. It was the patch that... enable the VPU services... Some issues with IOMMU definitions made it bork the entire IOMMU group, which included the video output IOMMU. So when the DRM driver tried to use the Video Output, no video output was usable anymore and it bailed out. I'll perform some GLES tests tomorrow and if everything is working, I'll try the rc5 and release a rc5 !

I guess that no DRM + no Serial output == kernel panic somehow. However, that's a wild guess and it will be hard to check that up, since the system boots fine when enabling a serial console. Now, my MiQi reboots, however it's connected with a dreaded microUSB cable. So maybe it reboots because it just cannot go haywire with ~500mA. Anyway, I'll try to remove the patch that defines a new set of VOPB registers, see if that's not the real cause.

Ok, I also got an HDMI screen to test it on and, yeah, the DRM drivers fails extremely fast, printing : [ 1.429322] rockchip-drm display-subsystem: master bind failed: -12 [ 1.436413] rockchip-drm: probe of display-subsystem failed with error -12 I'll try to see what's wrong with the display subsystem since the update. Note that currently the kernel only boots if you use a serial connection.

Here's the prebuilt release not tested on a real screen : https://github.com/Miouyouyou/RockMyy-Build/tree/GotNoScreenToTest

Okay, turns out that I got no HDMI screen at the moment, so testing the new release on a real screen, and testing the OpenGL ES side is tricky. So, to test at least the DRM and X11 side, I'll need some testers (*stares at @TonyMac32 *). So here's the 4.14-rc4 RockMyy release. It has been put inside a specific branch (with a big typo) until I'm sure that things are working correctly. The prebuilt release, on RockMyy-Build, should follow soon.

Well, I've reworked most of the Tinkerboard patches. They will need to be tested though. Tomorrow, I'll get a screen to test the HDMI output and the GPU drivers, see if everything goes fine. If everything does go fine, I might push a release. Meanwhile, while hacky, you can boot the zImage and modules available on RockMyy-Build from an ARMbian system. Updates won't be automated tough. I don't remember how to edit the bootloader configuration though. I'm pretty sure the .txt and .scr files contain comments on what to edit and how to regenerate the boot configuration files. Anyway, I'm currently testing my releases on ARMbian distributions. My latest (4.13 era) tested kernel build is available through : https://github.com/Miouyouyou/RockMyy-Build Just do a : # git clone --depth 1 https://github.com/Miouyouyou/RockMyy-Build # cd RockMyy-Build # cp -r lib/* /lib/ # cp -r usr/* /usr/ Then for the zImage and DTB, you should look at the ARMbian documentation first, then copy the zImage and DTB accordingly.

@TonyMac32 Well, if by interdependent you mean Mali Utgard kernel driver code depending on Mali Midgard driver code, and vice-versa : No, they're not interdependant. Meanwhile, you might want to test my RockMyy 4.13 kernel and give it a try. At least you'll be able to check if everything is fine with the GPU. Now, concerning the userspace binary drivers, as long as the version of the userspace drivers is lower than the kernel driver version, everything should be fine. I can guarantee that GL ES + DRM drivers, using GBM to generate the framebuffer, work on MiQi hardware (RK3288) using 4.13 kernels, once the drivers integrated. WGL, I don't know what it is. Wayland GL ? Or Windows GL ? I haven't tried getting .Net working on ARM systems however. Anyway, I'll try to release a 4.14 with Mali Midgard drivers integrated this week, if everything goes fine. The 4.14-rc5 kernel seems to boot fine at least. I just need to check if the DRM subsystem has been fixed since the rc1 and, at least, split and rewrite the DTS patches.

First thing : Check if you have a /dev/mali0 node. If it is not present, the kernel-space drivers are not loaded and the user-space binary drivers will not work. Then : Check if your user have the rights to write into /dev/mali0. You can try the evil chmod 0666 /dev/mali0 as root and see if it resolves the issue as a user. Finally : Ensure that you're using the drivers correctly. Something like : LD_PRELOAD=/path/to/userspace/drivers/x11 ./your_gles2_app_using_x11 Or LD_PRELOAD=/path/to/userspace/drivers/wayland ./your_gles2_app_using_drm_kms

I haven't tried for the moment, given that the actual hardware still need a few drivers to be usable for daily tasks with mainline kernels. Still, I haven't checked but is the Hypervisor mode an ARMv7 thing or a Rockchip thing. If it's an ARMv7 thing, the reference manuals might contain some clues on what to do to use these features. When reviewing the patches, I'll try to check what could cause this message to appear, programming wise.

I asked the question, I got informed that I should not hardcore these numbers, but didn't get anything on a fool proof method to get the CPU temperature. I'll reiterate another day, with less typos and a better grammar. https://irclog.whitequark.org/linux-rockchip/2017-09-16 The discussion then diverted on potential future Vulkan support.

Well, after a quick test, it seems that the number after tsadc seems to determine the probe to check, but does not affect the numbering. Meaning that if you put tsadc 1 on the reserve_thermal and tsadc 0 on the cpu : - You won't be able to read the CPU temperature through thermal_zone1, even though it's enabled - but you'll be able to the CPU temperature through thermal_zone0, even though it's disabled and named reserve_thermal.

I don't know if that's the order, or the number associated with the tsadc entry ( thermal-sensors = <&tsadc 0>; ). I'll try to ask #linux-rockchip , see if they have a clue about this reserved area.

On my MiQi board, thermal_zone0 is disabled, thermal_zone1 is enabled and so is the 2. Which gives : root@miqi:~# cat /sys/class/thermal/thermal_zone0/mode disabled root@miqi:~# cat /sys/class/thermal/thermal_zone1/mode enabled root@miqi:~# cat /sys/class/thermal/thermal_zone2/mode enabled root@miqi:~# cat /sys/class/thermal/thermal_zone0/temp cat: /sys/class/thermal/thermal_zone0/temp: Invalid argument root@miqi:~# cat /sys/class/thermal/thermal_zone1/temp 45000 root@miqi:~# cat /sys/class/thermal/thermal_zone2/temp 44090 Since the temperature sensor used in the login message from Armbian works, I never tried to play too much with the temperature sensors. I could try to find why the first sensor is disabled though.

Alright, I think I got something working ! MPV using MPP seems to work and is able to read a 1080p WebM file and output a very fluid image ! However, I only tested this with 1m30s sample files so I'll have to test this more seriously. Still, having the VPU driver works on 4.13 kernels is nice ! Now, I'll need testers ! So here's a patched kernel build, including the VPU driver in it : https://github.com/Miouyouyou/RockMyy-Build/releases/tag/v4.13-VPU-Test This build include patches that makes logging VERY NOISY when playing files. If everything works nicely, I'll remove the noise. Here's the repository containing the patches applied : https://github.com/Miouyouyou/RockMyy/tree/VPU_Work_tests And here's the patch itself : https://github.com/Miouyouyou/RockMyy/blob/VPU_Work_tests/patches/kernel/v4.13/0012-Slight-butchering-to-test-the-VPU-driver.patch Here's the repository containing the working VPU code : https://github.com/Miouyouyou/rockchip-vcodec/tree/retry Testing the VPU Now, in order to test the VPU driver, you'll need something that work with it ! I tested it with MPP and MPV. So if you want to test it like I did, you'll have to recompile MPP and MPV, and also know how to download and use ARM Mali user-space binary drivers and make them work through the DRM interface. https://github.com/rockchip-linux/mpp https://github.com/LongChair/mpv https://github.com/rockchip-linux/libmali/ Have fun ! Whether everything works or you got a crash, don't hesitate to reply on this thread. If you something went wrong, please provide any crash message that might appear in dmesg !

Stock OS ? You mean ASUS Debian image ? Yeah, I guess you can give it a try. I got ready-to-use kernel files here : https://github.com/Miouyouyou/RockMyy-Build That said, my configuration and ARMbian kernel configuration might differ in some places. Also, I'm only testing my kernels on MiQi devices so I can't guarantee that everything will work on Tinkerboard systems.