Myy

Applied the patch, left the rk3288 with 5 hours of this:
 
it worked without an itch, dmesg was clean.

Sooo, I tried to fix the issue, using a 5.8-rc3 kernel... While the frequencies are back, there's some heavy glitches with Panfrost drivers and I don't know if that's due to kernel changes (entirely plausible) or if that's due to the patch.
I'll try test a 5.8-rc3 kernel without this patch, just to check who's the culprit.
 
Meanwhile, here's a patch that brings 500Mhz frequencies back for Mali GPU on RK3288 boards : https://gist.github.com/Miouyouyou/0dad9c4a321349166bbc9d49ffec315a
From 73258d32daf3a661281bb5c77c5e2e06c7ff714e Mon Sep 17 00:00:00 2001 From: "Miouyouyou (Myy)" <myy@miouyouyou.fr> Date: Fri, 3 Jul 2020 02:02:18 +0200 Subject: [PATCH] arm: dtsi: rk3288: add GPU 500 Mhz OPP again Undoing the very bizarre mainline kernel patch, 75481833c6dbab4c29d15452f6b4337c16f5407b which main purpose is to sync some 3.14 kernels hacks to mainline kernels, for reasons that only matter for a few Chromebooks, and shove it down the throat of every RK3288 user. If you need to avoid the GPU going to 500 Mhz on Chromebooks, remove the OPP entry inside the DTS that actually matters to RK3288 Chromebooks. Meanwhile, the 600 Mhz operating point can prove to be unstable on some RK3288 boards, while 500 Mhz works fine. https://forum.armbian.com/topic/13515-panfrost-on-rk3288-and-gpu-on-600mhz-problems/ Signed-off-by: Miouyouyou (Myy) <myy@miouyouyou.fr> --- arch/arm/boot/dts/rk3288.dtsi | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi index a66412547..ef7457f79 100644 --- a/arch/arm/boot/dts/rk3288.dtsi +++ b/arch/arm/boot/dts/rk3288.dtsi @@ -1312,6 +1312,10 @@ opp-400000000 { opp-hz = /bits/ 64 <400000000>; opp-microvolt = <1100000>; }; + opp-500000000 { + opp-hz = /bits/ 64 <500000000>; + opp-microvolt = <1200000>; + }; opp-600000000 { opp-hz = /bits/ 64 <600000000>; opp-microvolt = <1250000>; -- 2.27.0  

https://github.com/rockchip-linux/kernel/blob/develop-4.4/arch/arm/boot/dts/rk3288cg-opp.dtsi
 
is the vendor opps for the rk3288-C (Tinker/chromebook version)
 
If it isn't a "C", then it wouldn't have 600 MHz Mali or faster than 1.6 GHz CPU according to Rockchip (I don't know about the "W")
 
@Myy  Wow, that patch is garbage, I didn't even notice that.  It's worse than you are summarizing:
 
"NPLL is necessary for 500 MHz, ancient krusty kernel suxors and doesn't have this OPP, so in case someone hypothetically someday maybe in theory thinks about possibly re-purposing the NPLL like the ancient kernel did, make mainline suck too for everyone."
 
Yikes.
 
I don't see any reason to not reintroduce that OPP for Armbian use, as far as I know this purely hypothetical situation has not taken place.

The output for target files which are affected by multiple patches is now better.

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.

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
 

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 :-)

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.

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.

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,
 

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.



 

@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.

Sure thing.
 
 

Holy shit. It is running!

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.



 

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!

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.

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.

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!

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.

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.

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".

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.

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.