Myy

Well, I was able to compile an official U-Boot image, pack it in a "Rockchip" way and load it with rkdeveloptool. To compile U-Boot, you'll need the arm-trusted-firmware. To compile the arm-trusted-firmware for RK3399, you'll need the arm-none-eabi- toolset. Unpack the toolset somewhere, set your PATH to /path/to/toolset/bin/ Check that arm-none-eabi-gcc can run. Then, compile the ARM Trusted Firmware : git clone https://github.com/ARM-software/arm-trusted-firmware.git --depth 1 cd arm-trusted-firmware make realclean make CROSS_COMPILE=aarch64-unknown-linux-gnu- PLAT=rk3399 bl31 cp arm-trusted-firmware/build/rk3399/release/bl31/bl31.elf /tmp Then, compile U-Boot : git clone https://github.com/u-boot/u-boot --depth 1 cd u-boot/ export CROSS_COMPILE=aarch64-unknown-linux-gnu- # Set this to your ARM64 GCC toolset prefix. Set nothing if you're compiling on an ARM64 machine. export PLAT=rk3399 export ARCH=arm64 make firefly-rk3399_defconfig make -j16 # N virtual cores. AMD Ryzen here. cp /tmp/bl31.elf . make u-boot.itb cp u-boot-dtb.bin /tmp Then get the "Rockchip tools" : git clone https://github.com/rockchip-linux/rkbin.git --depth 1 cd rkbin/tools ./loaderimage --pack --uboot /tmp/u-boot-dtb.bin /tmp/uboot.img Then get Rkdeveloptool : git clone https://github.com/rockchip-linux/rkdeveloptool --depth 1 cd rkdeveloptool autoreconf -i ./configure make cp rkdeveloptool /path/to/your/local/bin Then get RKTool_Linux.tar.gz from Orange Pi : https://mega.nz/#F!K1BQFQjL!W9rYedaoGpV4y8vHfrGEfQ!ekYA0AwR Extract it. Extract the Linux_rockdev_2015-06-17_for_RK3399.zip archive contained in it Copy the RK3399MiniLoaderAll_V1.05_DDR600MHz.bin contained in it to some place Then do : /path/to/your/rkdeveloptool db /path/to/RK3399MiniLoaderAll_V1.05_DDR600MHz.bin /paht/to/your/rkdeveloptool ul /path/to/RK3399MiniLoaderAll_V1.05_DDR600MHz.bin /path/to/your/rkdeveloptool rd /path/to/your/rkdeveloptool wl 0x2000 /tmp/uboot.img Wait for a bit and you'll get your new U-boot ! ... YAY ... At least you can configure this one...

Well, it seems that you can also load the same .bin as the firmware with : ./rkdeveloptool ul /path/where/you/unpacked/Linux_rockdev/rockdev/RK3399MiniLoaderAll_V1.05_DDR666MHz.bin And that gives you back the reboot the button... So much wonders... It still doesn't boot anything useful, but at least you get messages printed on the serial line and that's recomforting... for 10 seconds.

Ok, I was able to get a bootloader back, without shortcuting because shortcuting sucks, with one of their RK3399MiniLoader image. I wonder why the official Rockchip loader didn't work... Whatever, the command is : ./rkdeveloptool db /path/where/you/unpacked/Linux_rockdev/rockdev/RK3399MiniLoaderAll_V1.05_DDR666MHz.bin Anyway, there's enough emotions for today. I guess that the next logicial step should be : trying to understand how to compile a U-Boot and Miniloader for that board, so that I can have a configurable U-Boot... Their images date from the 17th June 2015...

Yeah, after trying to play with the "upgrade tool" for Linux provided by Orange Pi, I got the quiet Maskroom issue... And yeah, shortcuting pins doesn't do anything... First these pins are not at the back of the board, like the documentation says, they're near the upper left of the eMMC chip, but they're useless. Now, I guess I should buy some kind of shortcuter that I can lie on a board. Because rebooting while shortcuting two pins *that* close to each other is pretty difficult.

I got my hands on an Orange Pi 3399 and I'm also fighting against U-Boot. However, I backed up a few things before blowing everything up and being stucked on RockUSB. 1. I got the previous cmdline that was used to boot the Android image that was on the board earlycon=uart8250,mmio32,0xff1a0000 swiotlb=1 androidboot.baseband=N/A androidboot.selinux=permissive androidboot.hardware=rk30board androidboot.console=ttyFIQ0 init=/init mtdparts=rk29xxnand:0x00002000@0x00002000(uboot),0x00002000@0x00004000(trust),0x00002000@0x00006000(misc),0x00008000@0x00008000(resource),0x0000C000@0x00010000(kernel),0x00010000@0x0001C000(boot),0x00018000@0x0002C000(recovery),0x00038000@0x00044000(backup),0x00040000@0x0007C000(cache),0x00600000@0x000BC000(system),0x00008000@0x006BC000(metadata),0x00002000@0x006C4000(baseparamer),0x00000400@0x006C6000(frp),-@0x006C6400(userdata) storagemedia=emmc loader.timestamp=2017-08-23_15:15:41 hdmi.vic=-1 androidboot.mode=emmc 2. I got the previous parameters.txt FIRMWARE_VER: 6.0.1 MACHINE_MODEL: RK3399 MACHINE_ID: 007 MANUFACTURER: RK3399 MAGIC: 0x5041524B ATAG: 0x00200800 MACHINE: 3399 CHECK_MASK: 0x80 PWR_HLD: 0,0,A,0,1 #KERNEL_IMG: 0x00280000 #FDT_NAME: rk-kernel.dtb #RECOVER_KEY: 1,1,0,20,0 #in section; per section 512(0x200) bytes CMDLINE: androidboot.baseband=N/A androidboot.selinux=permissive androidboot.hardware=rk30board androidboot.console=ttyFIQ0 init=/init mtdparts=rk29xxnand:0x00002000@0x00002000(uboot),0x00002000@0x00004000(trust),0x00002000@0x00006000(misc),0x00008000@0x00008000(resource),0x0000C000@0x00010000(kernel),0x00010000@0x0001C000(boot),0x00018000@0x0002C000(recovery),0x00038000@0x00044000(backup),0x00040000@0x0007C000(cache),0x00600000@0x000BC000(system),0x00008000@0x006BC000(metadata),0x00002000@0x006C4000(baseparamer),0x00000400@0x006C6000(frp),-@0x006C6400(userdata) 3. I thrashed my partitions so I'm trying to recover them little by little. I've been able to advance a little bit by downloading the RKTool_Linux.zip archive, and flashing the u-boot.img image at 0x2000 and the trust.img image at 0x4000 with rkdeveloptool. Yeah, I just used the archive for the .img . ./rkdeveloptool wl 0x2000 Linux_Pack_Firmware/rockdev/uboot.img ./rkdeveloptool wl 0x4000 Linux_Pack_Firmware/rockdev/trust.img However, now I still have to understand how uboot is configured. Currently U-Boot is configured to boot in 0 second. I'd like to put it to ~5 seconds, and then try to mount the whole eMMC through USB to install something in it ASAP. I always hate the whole U-Boot ordeal on Rockchip systems.

Yeah, the dreaded purple line appeared on my screen too. I jumped the gun. It only disappear on the second reboot, whether the patch is applied or not. If you can try with the HDMI frequencies defined in the DTS file and see it it doesn't break everything, I'd like to get some feedback, indeed. Be careful though, you might have to SSH or Serial back on your machine to replace the current DTS file, if the frequencies generate blackout issues with the screen.

I've adapted a set of patches from Urja Rannikko, which move the HDMI frequencies definition into the DTS file, with some preconfigured rates if none are defined in the DTS. The original patches set is here : https://www.spinics.net/lists/arm-kernel/msg673156.html The big patch I used as a basis is here : https://github.com/urjaman/arch-c201/blob/master/linux-c201/0020-RK3288-HDMI-clock-hacks-combined.patch I included these patches by splitting them again : https://github.com/Miouyouyou/RockMyy/commit/57ff073fffb5678e75959e566704376f6f52ac17 These patches were suggested to me here : https://github.com/Miouyouyou/RockMyy/issues/3 Anyway, after some quick tests, these patches remove the dreaded bar of purple pixels at the left of my HDMI screen, when plugged to Tinkerboard systems and MiQi systems. Note that these bars only appear on my screen when using "good" (enough) USB power supply. Still, with these patches, they are gone. However... I only tested these patches on my 60Hz 1080p screen, which is pretty much the de-facto standard screen. I'd like to see people test these patches on other HDMI configurations which are known to have some issues with Tinkerboard, MiQi and others RK3288 systems. So, yeah, if you'd like to test some kernel patches and are not afraid to see your screen go black after a reboot, have a try. Note : This is completely unrelated with the CEC issue.

@naseeb From the logs, it is clear that your user-space drivers are more recent that the kernel drivers. The Mali Midgard proprietary drivers are split into two parts : - The kernel driver, under GPL license, which must be added to the kernel or modified to be compiled as an OOT module. - The user-space binary driver, which is a proprietary set of libraries that provide the OpenGL/OpenCL functions. These might be replaced by https://gitlab.freedesktop.org/panfrost in some distant future. Now, getting a new kernel (4.4 -> 4.14) does not ensure you that you'll get newer drivers. You'll get newer drivers, only if the archive containing newer drivers were included in the kernel. Still, IIRC, the linux kernel 4.14 and 4.18-dev provided by Armbian should include more recent Mali Midgard kernel drivers that should allow you to use the provided libraries. However, if you switch from a 4.4 to a 4.14, you'll lose the VPU support at the moment. Concerning the NV12 support, I would suggest you try this, to test the support for this format : https://github.com/robclark/kmscube I guess that Mali drivers supports this format since Mali-400 GPU supported it : https://community.arm.com/graphics/f/discussions/6178/mali-400-dumb-questions

Just let a few ones intact, just in case (´・ω・`　)

Ah, good to know.

Logging through the serial console is configured through systemd and boot parameters... But, yeah, one of the default behaviour is to output the kernel messages through the serial console ONLY IF no screen is available. So I guess that HDMI CEC support is broken ? Does the freeze happen with other screens too ? The default UART for debugging purposes on RK3288 is the UART2 (/dev/ttyS1). It might be changed though. The RK3288 Datasheet name UART2 "uart2dbg". UART3 is for plugging GPS systems (which is not used very often, I concur). Just for information : 1. When the HDMI cable is plugged, do you have any SSH access ? If you wait for 5 minutes, is it still frozen ? 2. If you start without an HDMI cable, get a serial console and *then* plug the HDMI screen, what happens ? Do you have any crash or freeze message ? I remember some bug a long time ago, about 4.14 kernels... That would make the system unbootable if you plugged the HDMI cable before booting : https://github.com/Miouyouyou/RockMyy-Build/issues/1 I don't remember how I was able to get a log for this though...

Also, be sure to use a recent version of glmark2. Compile the GIT version if you can. sudo apt install libjpeg-dev libpng-dev pkg-config libudev-dev libdrm-dev libegl1-mesa-dev libgles2-mesa-dev libgbm-dev git clone --depth 1 https://github.com/glmark2/glmark2 cd glmark2 ./waf configure --with-flavors=drm-glesv2 ./waf Then you should have a binary ready (find -name "glmark2-es2-drm") You could install it too, but it might clashes with your current installation. ./waf install

@naseeb Hmm, it's weird that the driver doesn't try to access /dev/mali0 at all. It doesn't even try to find DRM devices too. Could you try the DRM version of glmark2 in a terminal (CTRL+ALT+F1 or chvt 1 from an SSH session) and see if it works better ? Also try the --debug flag.

So, I'm still trying to get this "thing" working on mainline kernels and my last issue is that the setup is done, I launch a decode pass, the IRQ handler is triggered but the output buffer remains untouched. However, the thing I don't have any error messages. I see that some VPU registers changed after the (failed) decode pass, but most of the changed registers are completely undocumented. And by "undocumented", I mean, even RKMPP and the Chromium V4L2 do not document these registers. Meanwhile, I saw that the old drivers use the IOMMU DMA API, so I tried to enable the IOMMU_DMA API on Rockchip systems but that led to the Video Output MMU breaking, along with the DRM drivers firing BUG_ON after BUG_ON. I was still able to boot the system by unplugging the screen, but the VPU driver issue remained identical. Loads, runs, trigger the IRQ, no output. I've even setup an IOMMU Fault handler, just in case, but it's never called. I'm currently trying to look at how to setup a DMA fault handler, maybe that's the issue here. Meanwhile, I tried to disable an old patch I kept around in my kernels and... that led to the VPU MMU clocks not starting anymore... Yay... As a last resort, I'm asking for various hints on the Rockchip Linux and IOMMU Linux Mailing lists. Still... I don't expect much. So I'm close but still not there. Maybe it's a simple bug in the code that I'm not seeing.

The principal major feature not implemented in mainline kernels is the VPU driver. I'll try to give H264 decoding on mainline kernels a shot today. Still, there's a few bugs here and there in the mainline kernels that impact various RK3288 boards, notably USB hotplug, HDMI audio and MMC detection on some systems. There's also some minor warnings regarding framebuffer initialization with some screens that a bug reporter named samsonluk is trying to pinpoint.

If you can get a serial console working, this might help us troubleshooting your current issue.

Could you connect a serial console to your Tinkerboard S and provide the output of the serial console ?

The Mali driver can use devfreq, and has various ways to be told how to vary the frequency of the GPU. Now, I've been informed recently that a patch is necessary on mainline kernels to avoid some Mali Devfreq related warnings and panics. A modified version of the patch is available here : https://github.com/Miouyouyou/RockMyy/blob/master/patches/Midgard/r19p0-01rel0/0010-GPU-Mali-Midgard-remove-rcu_read_lock-references.patch The original is here : https://github.com/mihailescu2m/linux/commit/bbe73c3c1143e5991bdcaee3afaecf5c31af0647 That said, if you want to push the Mali GPU to higher limits, you can do something like this : cd /sys/class/misc/mali0/device/devfreq/devfreq0/ echo `cat max_freq` > min_freq echo 10 > polling_interval This will force the GPU to be at its highest clock rate constantly (supposedly, I have no way to actually verify that). Now, let's be clear, if you launch a GPU intensive task with these settings, while not having a beefy stable power supply, the board might just shut down or not provide any performance gain. Now that's mostly the case for USB power supplied board. Still, these settings provide good performances gain on some benchmarks, very little on others. Frequency alone won't help you overcome bad optimizations. Also sometimes performances issues become CPU bound as the GPU gets faster.

And if you do sudo ifconfig wlan0 up ? Is NetworkManager able to bring up the interface through nmtui ?

What if you do : mv /var/lib/apt/lists/apt.armbian.com_dists_xenial_InRelease{,.bak} apt update ? If that fails miserably, just do : mv /var/lib/apt/lists/apt.armbian.com_dists_xenial_InRelease{.bak,}

`/lib/firmware/rtlwifi` only contain the firmware themselves. Though, you could test if a new firmware gets you a better connection. For that, be sure that the name of the new firmware is equivalent to the old one. Try `dmesg | grep -i bin` to get a clue of which firmwares are loaded by the kernel.

@JMCC I was aware of the Ayaka's fork but not of HermanChen's one. Thanks. Still, there are things that either really require extensive H264 knowledge, or things were named... in a very weird way. For example, the register where to store the input buffer address, containing the encoded H264 frame, is named rlc_vlc_st_adr in MPP code. Thanks to the Chromium team code who named it VDPU_REG_ADDR_STR I was able to quickly understand what it does. Still, is that standard H264 naming scheme ? When you're a H264 decoder developer, you don't talk about the raw encoded frame bitstream but about the "RLC VLC source" ?

I'm currently watching a conversation between Tomasz Figa (Member of the Chromium team) and a developer named Baruch Siach about how to port the V4L2 driver to the mainline kernel. Meanwhile, now that I got a roughly good idea on how DMA and IOMMU interoperate, and a documentation of the VPU registers (that was not easy due to the split of the drivers informations between the Rockchip VPU driver and their MPP codebase), I'm currently : trying to get a patched version of MPP working on 4.4 kernel working on a spare MiQi, using @JMCC scripts; get a snapshot of a H264 frame sent to the VPU, with all the VPU registers parameters, with that patched MPP; reproduce this in my last driver and see how it fares. Now, I had to a few troubles, between the fact that my current job takes (too much) time, a few bugs had to be dealt with, I had to buy a second screen because using my main screen and unplugging the HDMI output of my Radeon Vega is a NO-NO due to some vega driver bug (I have to report this bug...)... And I still need to get a few things setup to make the whole Tinkerboard/MiQi/RK3399 juggling painless. The reason I have to peek MPP memory buffers instead of producing a H264 naked frame by myself is that : I currently don't know how to produce a H264 by myself (there's a few tutorials here and there...), and there's a lot of parameters in this standard that require a very good understanding of how video work in general, and some extensive knowledge of the norm. I mean, just computing the dimensions of a frame requires some special math that is not intuitive. Still, if I can send a frame to VPU and have it decoded, than I will be able to focus on trying to get with working with the V4L2 API, which seems to be setup for GPU<->VPU communication, reusing the code Tomasz Figa wrote for the Chromium team.

Okay, I've been able to boot an Armbian and I'm now trying to get a mainline kernel working. I've been able to get a seemingly working HDMI output, but I got no Ethernet and the logs were spammed about some iio.device and dwmc3 devices badly configured, in my port of @hjc DTSI and DTS. Also getting to X11 takes at least 30 seconds. Anyway here are the issues I encountered https://github.com/Miouyouyou/RockMyy64/issues I'll play with the RK3399 again next week. Meanwhile, I guess I'll take a tour of all the others repositories mentioned, see if at least I could solve a few issues. Also, since my repository also generates fragmentation, I guess I should add in the README that, yes, you can take, and modify, my patches and do whatever you want with them.

Ah, EOVERFLOW... You might need that kind of patch applied to the Mali drivers : https://github.com/Miouyouyou/RockMyy/blob/master/patches/Midgard/r19p0-01rel0/0009-GPU-ARM-Midgard-Adapt-to-the-new-mmap-call-checks.patch They might have imported Linus Torvalds patch to mmap into the 4.14 series.