Description

This PR follows the discussion of the previous PR about introducing LibreELEC patches into rockchip64 family patch tree.

There is no Jira reference number yet, since this is yet a proposal. If there is general consensus, a ticket will be opened and linked here.

As like as @AdamLantos did, I first let LibreELEC patches apply and then armbian ones, so if an armbian patch clashes, I remove it and keep the libreelec variant. This is so because LibreELEC patches usually are already queued for being upstreamed into mainline kernel and then downloaded from https://patchwork.kernel.org

This time, following the requests coming from the previous PR, LibreELEC patches have been splitted from mailbox format into single patches. It should be easier to review and change them in case a patch is mainstreamed.

A small readme.txt file in libreelec series directory has been created with a minimal documentation about where the patches come from, the technique used to split the mailbox format and, obviously, give credits to the original authors.

Also patchsets have been separated using the same patch series logic which is already used for sunxi families, so librelec and amrbian patches stay in their own directories.

Since patch series application logic does not remove existing files if a patch wants to create a file from scratch, as "basic" patch logic do, I reworked the existing patches that were leveraging that behaviour to keep the final result exactly as it was before. This is so for:

• helios64 board file
• nanopi-r4s board file
• roc-pc-plus board file
• YT-85xx motorcomm driver

All other patches have been adapted, so at the current moment all of them apply clean and all of them have been ported to the new structure. Duplicate ones, as already stated, have been removed.

TODO: I still have to review the device tree overlays for correctness

How Has This Been Tested?

• [x] All patches apply cleanly
• [x] Built image and tested on rk3318 board
• [ ] Built image and tested on rk3328 board
• [ ] Built image and tested on rk3399 board

Checklist:

• [x] My code follows the style guidelines of this project
• [x] I have performed a self-review of my own code
• [x] I have commented my code, particularly in hard-to-understand areas
• [ ] I have made corresponding changes to the documentation
• [x] My changes generate no new warnings
• [x] Any dependent changes have been merged and published in downstream modules

View the full article

not necessary - not even desired by most of the helios64 users