lanefu changed the topic of #armbian-rockchip to: Armbian - Linux for ARM development boards | Rockchip SoC | www.armbian.com | This channel is relayed to the equivalent Discord channel | this channel is logged
<Armbian-Discord>
<rpardini> I think you can set the overlay prefix in armbianEnv ?
<Armbian-Discord>
<Tonymac32> Overlays are not a natural occurrence in Linux but are added by others/vendors. Who's individual project has a different prefix than Armbian, and why should we accommodate it?
<Armbian-Discord>
<Tonymac32> I don't know if there are set rules for what Armbian does as I disagree with patches being used to add/modify them anyway
<Armbian-Discord>
<c0rnelius> bit of a shit attitude. as that is what patches do.
<Armbian-Discord>
<c0rnelius> Not sure what it is with Armbian devs. Almost feels like an intentional goal to sabotage progress under the guise or opinion of..well I don't agree. The I don't agree is never really fleshed out... So it just looks like a dick move for no reason.
<Armbian-Discord>
<Tonymac32> overlay patches are a complete cluster in our build system, I would have assumed you had some idea
<Armbian-Discord>
<Tonymac32> The way they are managed, tracked, maintained, sorted, and identified is crap
<Armbian-Discord>
<Tonymac32> It needs reworked
<Armbian-Discord>
<c0rnelius> Most of the vendor overlays are specific to the kernel revision.
<Armbian-Discord>
<Tonymac32> which is a failure on their part
<Armbian-Discord>
<Tonymac32> but should be manageable
<Armbian-Discord>
<c0rnelius> Adding them to the vendor kernel build which armbian is already providing isn't a chore really.
<Armbian-Discord>
<Tonymac32> maintaining a vendor kernel is already a chore, I burnt out on it
<Armbian-Discord>
<Tonymac32> it's why I haven't done anything with RK3588, it's useless until a real kernel runs on it
<Armbian-Discord>
<Tonymac32> which I need to test mainline again
<Armbian-Discord>
<Tonymac32> speaking of
<Armbian-Discord>
<c0rnelius> Sure but it honestly doesn't take much you're just pulling the source from the given GitHub.
<Armbian-Discord>
<Tonymac32> and watching for build failures, and fixing them
<Armbian-Discord>
<Tonymac32> etc
<Armbian-Discord>
<c0rnelius> Well yes that's given.
<Armbian-Discord>
<Tonymac32> you're not wrong, but this is a death of a thousand cuts in this project
<Armbian-Discord>
<c0rnelius> Agree
<Armbian-Discord>
<c0rnelius> Overlays is the least of all of our problems.
<Armbian-Discord>
<c0rnelius> Just saying
<Armbian-Discord>
<Tonymac32> lol not necessarily, they are a pain in the neck with the way we handle them, and they bring complaints. Now I saw a PR on this topic earlier, so someone is taking initiative
<Armbian-Discord>
<Tonymac32> on the rk3588 missing overlays
<Armbian-Discord>
<EfeCTN> Yes it's easy to fix it but default overlay prefix seems wrong to me
<Armbian-Discord>
<IgorPec> if we need to adjust - mainline is the right way when it comes to naming convention, but yes, we can see many vendor / proprietary ways in downstream kernels. Especially in this Frankenstein type of 😉
<Armbian-Discord>
<rpardini> Yep -- we can define OVERLAY_PREFIX= to something more sane. That family, on legacy, is exclusive to that vendor kernel, so should match what the vendor kernel is doing... Also, take a look at config/bootscripts/boot-rockchip64-vendor.cmd -- which is a hack I did to be less stupid about prefix etc when using vendor kernels.
<Armbian-Discord>
<rpardini> Yep, but that's not a vendor kernel...
<Armbian-Discord>
<rpardini> (I am not defending the current mess -- it sucks)
<Armbian-Discord>
<rpardini> especially in rockchip64, where there's overlays and fixups. which ties any chance of overlays working to bootscript-based boot