Werner

Your best chance to know whats going on inside is this thing so go ahead and use it.

I do not have a a board with any RK SoC (yet) and very little experience with it. So not sure about the media stuff. Interesting to know though that there may be issues with Chromium but not with Firefox? @Igor Maybe either @JMCC or @NicoD can tell you more about media support on RK3399 in this case.

I guess that means Armbian is still missing some patches or whatever for H6. I tried to dig through the soures from LibreELEC but could not find something spectacular...

Of you have spare sd card I'd try to flash a fresh armbian on it, boot from it, mount your eMMC and change the password.

<smaeul> scanning bus dwc3@5200000 for devices... 2 USB Device(s) found <smaeul> wooo, got USB3 boot working on H6 :D patchset at https://github.com/smaeul/u-boot/commits/h6-dwc3 Just catched this on #linux-sunxi IRC channel. I do not have a H6 board to test this but maybe someone else wanna give it a shot.

This is quite a bunch of text so please forgive me if id did not read it very carefully Go for legacy 4.4 if in doubt. Has been proven to be more solid than newer ons. Did you check the media script for RK3399?

Check "Tested 3rd party hardware" at the download page of your board.

Wrong image. OrangePi One != OrangePi PC

Please attach the output of armbianmonitor -u

Self-built using the build script: https://github.com/armbian/build

I barely remember that at least for some boards the boot logo has been disabled to improve HDMI detection but could not find it in a rush. @Igor do I remember correctly?

We will see. I hope @martinayotte wants to start looking at 5.7 as soon as it is released (or already has ) and megi pushed the branch to stable as well. Will be helpful I hope to sort things out.

Did you check if the "wa" rises significantly while searching? This would mean the bottleneck is the sd card.

Do dev branch as well

Without your patch the behavior is different. Clocks down to 1488MHz at 80*C However there is also a thermal_zone0 root@orangepioneplus:/sys/class/thermal/thermal_zone0# ls available_policies k_d policy trip_point_0_hyst type cdev0 k_i power trip_point_0_temp uevent cdev0_trip_point k_po slope trip_point_0_type cdev0_weight k_pu subsystem trip_point_1_hyst emul_temp mode sustainable_power trip_point_1_temp integral_cutoff offset temp trip_point_1_type for i in trip*; do echo $i; cat $i; done trip_point_0_hyst 2000 trip_point_0_temp 80000 trip_point_0_type passive trip_point_1_hyst 0 trip_point_1_temp 100000 trip_point_1_type critical

Depends on the current draw and how long you want to protect them from power outtage. https://www.ebay.de/itm/USB-Li-Po-18650-5V-1A-Lithium-Battery-Protection-Boost-Step-up-Charger-Board/153077054028 In combination with a Samsung INR18650 makes a dirt cheap UPS.

Will do. Also thanks for the testing instructions. Building right now.... Edit: Had some issues with the first sd card. The board behaviour was strange. The 2nd one works though. Above 80*C 1320MHz above 75*C 1488MHz above 70*C 1632MHz. I could barely push it over 80°C so no clue what happens above. Need someone else to test. Mine has a heatsink glued on.

I have an OPi1+ but I am not very good at writing patches. If you provide the changes the way you think they should work I'll test them.

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

Interesting. This was activated upstream with some other stuff quite a while ago:https://github.com/ayufan-rock64/linux-kernel/pull/42/commits/4b09df95f536a6fecd244dbabd0c59b5aa4048b9

Thanks for your comment. In first place I was thinking about making this tool to merge patches automatically but now I think it is even better to have the patches broken down into files because when there are changes upstream it is easier to detect which one fails and you can faster deal with it. And due to the numbering of the files you know anyways which split-patch belongs to another and even keeps the sequence of merging.

Try using armbian-config to install to USB/SATA....

Burn the image to an sd card and use armbian-config afterwards to write the OS to eMMC

Just found via google. You can disable this "spam" with echo 2 >/proc/sys/abi/cp15_barrier About your actual issue, sorry no idea

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