14:57:22 #startmeeting Armbian Release planning 23.05 14:57:22 Meeting started Sat Apr 1 14:57:22 2023 UTC. The chair is Werner. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:57:22 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:57:27 #topic check-in 15:00:34 hey good afternoon 15:01:41 hi! 15:01:48 afternoon folks 15:02:54 hi 15:04:12 Hello 15:04:30 # topic late topics 15:04:37 #topic late topics 15:04:53 Agenda: https://docs.lane-fu.com/jsxcggG9RqGdoTVNIXhfqA?edit 15:05:00 Focus on making a list of supported boards and jump into bug fixing mode ASAP so release is possible by the end of May. 15:05:23 - focus in quality - less supported count and better (open download pages and forum so we are all seeing the same) 15:05:28 - focus in stabilizing build framework / CI (build fwrk team) 15:05:35 - introduce “Retired family” - working configurations (mvebu family, which else?) 15:05:38 If you want to have something noticeable you want to highlight out in the summary later feel free to use one of those "commands for everyone" explained here: https://wiki.debian.org/MeetBot 15:06:30 #topic FYI 15:06:36 #topic FYI 15:06:38 Stuff to know beforehand - MC presents meeting relevant news and rules of engagement: 15:06:45 note 1: IRC translator: If your English is poor, simply write in your native language. Start your sentence with -- at the beginning. 15:06:54 rule 1: When you get a voice, please be quick and concise (1-2 min) and make it clear when you stop. (“No more, I’m done”) 15:07:06 rule 2: If meeting is going out of desired agenda, MC will use “STOP STOP STOP”, wait to get attention and then proceed with the meeting agenda. Please stop chatting and listen. 15:07:15 rule 3: Please highlight important information appropriately by putting a keyword in front of your message: #info #action #idea #help check tips below. 15:07:41 #topic board maintainers 15:07:49 #topic board maintainers 15:08:09 MC is calling out on by forum section, starting with Allwinner. Open page: https://forum.armbian.com/forum/64-maintained-hardware/ and https://www.armbian.com/authors/ (sections maintainers) 15:08:37 #action what to move down to unsupported, what to keep 15:09:07 #topic Allwinner 15:09:17 schwar3kat via email "orangepi-r1, orangepi-r1plus-lts, orangepizeroplus All stable images were good when I last tested." 15:09:18 #topic board maintainers - Allwinner 15:09:27 #info schwar3kat via email "orangepi-r1, orangepi-r1plus-lts, orangepizeroplus All stable images were good when I last tested." 15:09:45 Nanopim1, Bananapim3, Bananapim64, Orangepizero2 (legacy doesn’t build), Bananapi, Orangepizeroplus, Tritium-h3, Tritium-h5, PINE A64-LTS, Nanopi Duo, Duo2 (doesn’t boot), Orangepi R1, Banana Pi Pro, Nanopi Neo Plus2, Orangepipc are in theory supported 15:10:00 do we have any Allwinner person around to tell us more about status? 15:10:33 OPi02 legacy would be critical due to lack of mainline stuff iirc 15:10:57 No, but I'm generally worried about armhf -- due to zImage hacks/de-hacks/etc 15:11:15 here we don't get to linux yet 15:11:32 its something related to assembling boot loader which is propriatery in this case 15:11:39 it worked at old system, fails at new 15:12:09 #action fix opizero2 15:12:53 and second thing - retire complete 32b allwinner? 15:12:57 is that too soon? 15:13:07 retire = fix sources 15:13:36 not sure I understand 15:13:45 do not upgrade kernels anymore 15:14:00 Boards like Opi0 are still widely used 15:14:12 I think it would be fine not to put any more effort into edge but keep them on lts 15:14:40 heisath said for mvebu to stop changing kernels 15:14:50 and keep it at 6.1.y 15:15:19 I'd keep current = 6.1.y for the foreseeable future anyway for all families if possible. it's LTS. 15:15:32 yes 15:15:35 Hm I guess keeping on 6.1 is fine since it is supported until end of 2026 15:15:45 gotta have a grotesquely good reason to bump current up from 6.1.y on any family 15:16:11 I can't imagine any reason to 15:16:13 ok 15:16:35 then this is clear, we do nothing in this regard, keeping CURRENT at 6.1 lts 15:16:40 #info nanopim1 has working images for both ubuntu and debian bookworm without any major issues 15:16:49 #agreed stop bumping armhf kernels further than 6.1.y 15:17:13 I'd say stop bumping _all_ 'current' kernels further than 6.1.y 15:17:22 ok. other thing is - pretty much unknown state on half of organges and nanopis 32bit 15:17:41 @rpardini until next LTS kernel? 15:17:47 rpardini: +1 15:17:53 +1 15:17:59 Orange pi One ... it probably works, but don't have maintainer 15:17:59 +1 15:18:25 It does, for server tasks at least since I have one running 15:18:52 #agreed Stop bumping _all_ 'current' kernels further than 6.1.y (at least during 2023) 15:19:22 ok 15:19:32 What would be the benefit of bumping further than 6.1.y on these little systems? 15:19:45 currently none 15:20:14 Having new kernel features that are not directly linked to hw like optimizations in various code or whatever 15:20:18 #idea Stop calling any and all vendor kernel "current" - case in point: odroidxu4. 15:20:20 #idea Rename "legacy" kernels which are actually "vendor" kernels to BRANCH=vendor (case in point rk3588-legacy) 15:20:23 I guess close do nobody needs those 15:20:40 #idea changing terminology of “Maintained Hardware” vs “Unmaintained (CSC/EOL/TVB) / Other” into “Armbian maintained” vs “Community maintained” or similar. 15:21:06 rpardini agreed 15:21:22 this makes it easier to solve the problem of Orangepi One, which probably works, but we don't know status 15:21:30 so it will go below 15:21:35 rpardini with "vendor" kernels we need a more families 15:21:37 Where it fits. Legacy armhf kernel is no vendor kernel for example 15:21:48 More like old-current ^^ 15:22:08 legacy armhf rk3288 is vendor kernel 15:22:12 to me "vendor" is any kernel that we can't rebase on top of mainline and get less than 1000 commit patches 15:22:23 *armhf aw kernel 15:22:25 Sorry for mixeup 15:22:42 ;) I forgot the current focus family, apologies 15:22:49 any other saga around Allwinner except we need to get more help to cleanup patch mess 15:22:51 IgorPec: To clarify, you are proposing dropping the (CSC/EOL/TVB) setails and simplifying down to either "Armbian" or "Community" Maintained? 15:22:59 s/setails/details. 15:22:59 TRS-80 meant to say: IgorPec: To clarify, you are proposing dropping the (CSC/EOL/TVB) details. and simplifying down to either "Armbian" or "Community" Maintained? 15:23:25 TRS-80 Renaming complicated definition "Unmaintained (CSC/EOL/TVB) / Other" into "Community maintained" 15:23:52 Simplification sounds good. 15:24:03 adeepv: I see. Amlogic will have 2 "vendor" kernels possibly (4.x and 5.4.y) 15:24:25 and "Maintained Hardware" -> "Maintained with Armbiab help" or similar 15:24:30 rpardini for s4 family for example out vendor kernel different from khadas vendor kernel... 15:24:33 agree. However "community maintained" still implies some sort of maintainership which might not be true. Therefore "status unknown" might be more realistic in some cases... 15:24:36 *our 15:24:54 Werner yes, but that maintainership is outside our domain and control 15:25:05 we don't know if its maintained or not, status unknown 15:25:12 but can be fully ok or completly broken 15:25:17 adeepv: I see no problem in "vendor-jethub" BRANCH, which is only enabled for jethub boards. 15:25:26 # topic Amlogic 15:25:32 rpardini amlogic should have no vendor kernels for anything older than s4 15:25:36 #topic board maintainers - amlogic 15:25:54 rpardini problem with deb-pkgs which builds for family and future updates 15:26:00 Okie so not much work from my side on amlogic the last few months, mostly reacting to Neil 15:26:38 current=6.1.y should be relatively stable 15:26:58 edge=6.2.y also decent, even more so sometimes 15:27:03 and most board should be ok with minor issues 15:27:09 #agree with current=6.1 15:27:19 why do we have a khadas kernel and an s4 kernel. And what about anything living in the media kernel (I thought there was some khadas in there) 15:27:19 there's a bit of mess with u-boot 15:27:50 s4 kernel ? 15:28:10 s4 is upcoming still ppl 15:28:24 we're future-planning ;-) 15:28:41 ok. give it it's own family if it's not on the mainline amlogic train 15:28:42 rpardini u-boot after 2022.04 has some bug with efi code which cause boot-loop with some amlogic boards 15:28:52 we gonna need some s4 kernel for VIM4/VIM1S.... and adeepv's gonna need some s4 kernel for his new stuff 15:29:14 #info possible another legacy kernel to support VIM4 15:29:19 tonymac32 amlogic has 4.9 and 5.4 kernels. all chipset from 4.9 are working in mainline kernel (as I know) 15:29:22 adeepv: true, 22.04+ and low-RAM (<1gb?) boards have some snafu 15:29:30 adeepv correct 15:29:43 just some exotic features are problem 15:30:09 rpardini i disabled all efi stuff in board configs for new versions of u-boot 15:30:26 yeah the main contention point in meson64 is the clock-phase conundrum 15:30:42 I'd say for current=6.1.y we keep as is, but keep moving with mainline for edge/6.2+ 15:31:06 tonymac32 But for the new s4 family each vendor will have its own fork of the amlogic 5.4 kernel 15:31:50 anyway I'd say we only plan for s4 for 23.08+ release 15:32:02 we might cooperate with khadas and in that case their kernel gets in 15:32:06 23.05 might have something, but not "regulated" 15:32:15 rpardini I looked at uboot 2019 code from amlogic, it turns out they use the same method I did for phase shifting: the phases are specified in dts 15:32:15 #idea split meson64 into gx, g12, and s4 families 15:32:22 I'd for sure call it BRANCH=vendor- and not "legacy" 15:32:32 yes, it can be called whatever 15:33:03 we just need to adjust scripting to follow the logic 15:33:08 tonymac32: that split does not cure any pain with the clock phase though, which is between different boards in SM1 family 15:33:55 any other Amlogic realated 15:33:58 yes but we're getting a lot of special cases on more recent boards, while older boards are just along for the ride and nearly maintenance free 15:34:18 oh Neil added the CM4 Amlogic module 15:34:35 just commemorating, no action needed. 15:34:54 action = at least maintainer that would boot it up 15:35:11 yeah, action = get samples from vendor and assign full maintainer 15:35:23 Neil did literally all himself, uboot, kernel, and Armbian stuff 15:35:24 this is in motion. waiting for reply 15:36:01 so in case someone listening and have a desire for BPI CM4 with a mother board ... PM 15:36:13 * rpardini raises hand "PM" 15:36:34 in case nothing other in the land of Meson ? 15:36:37 #topic development Marvell 15:36:45 #topic board maintainers - Marvell 15:37:19 Well, my 2c: I severely broke Marvell build with armbian-next. Should be fixed, with help from ManOfTheSea. Thanks for patience 15:37:20 me and Manofthesee are trying to give life to Ebin v42 ... callled Ultra 15:37:41 its broken without your breakage ;) 15:37:53 anyway. here we also have 32bit 15:38:01 yeah -- it might still be broken, but patch-wise and such, not build system. 15:38:21 where Heisath had an idea to formally retire a board 15:38:32 as there is nothing going on hw wise 15:38:41 no changes for months 15:39:06 its an old machine, things works and they will only break down with upgrade. 15:40:00 yeah but we'll wanna bump the family kernel and end up frakking up the stable board, won't we? 15:40:00 no other hardware in section #marvell 15:40:38 whole family is covering two devices 15:40:54 armada a380 in router and nas variant 15:41:00 well... yeah in this case some BIG COMMENTS in family file are enough 15:41:22 only we can break this hw ... is the point 15:41:46 yeah. if we stick current to 6.1.y for the next 12 months we should have a year of peace there 15:42:06 if/when 6.1.y is "too old" we move it to legacy, sans-current, and be done with it 15:42:11 the point is that nobody will be checking this anymore 15:42:35 Can we agree, in general, not to bump kernels on unmaintained hardware? 15:42:38 and in lets say 6 months someone will shop up crying "id doesn't" boot, fail after upgrade 15:42:54 it has to be entire family. in this case its possible 15:43:07 well lets then downgrade it to whatever we call "maintained on best effort community basis" 15:43:08 as both devices we want to retire 15:43:28 or EOS or whatever. Naming things == hell 15:43:36 what i am talking about here is. Kernel = 6.1.20 ... goodbye 15:43:57 frozen, kernels are not produced anymore. is this viable? 15:44:00 oh you mean KERNELBRANCH='tag:v6.1..20` ? 15:44:04 yes 15:44:10 no problem for me 15:44:14 +1 15:45:02 se we know what is the status ... build system can throw out some warning 15:45:04 eventual interested user/semi-developer can go, bump it manually, fix patches if needed and send PR if wants 6.1.329 in 12 years 15:45:12 yes, something like that 15:45:19 +1 15:45:39 so we get off from responsibility to KNOW its status at any time 15:45:50 #action froze mvebu 32 bit 15:45:59 #action froze mvebu 32 bit 15:46:06 #topic Rockchip 15:46:09 #topic board maintainers - Rockchip 15:46:14 Rockpi-s (i2s), Nanopi-r4s(network sometimes fails), Rock-5b (powering, mainline?), Rockpi 4a (not all models are covered), Rock64, Rockpi E(does not boot), Rock 3(?), Orangepi-r1, Renegade, RockPro64, Tinkerboard2(does not boot), Nanopineo3 15:46:15 32-bit rockchip 15:46:21 or 64 bit 15:46:26 32b start 15:46:54 Nanopi-r4s is unstable for me but since nobody else reports I guess its just my board 15:46:59 armhf rockchip is _also_ subject to my worry ref. zImage and such 15:47:32 rapardini: but this will be fixed soon, right? 15:47:57 #iforgot in Amlogic, there's algo armhf meson, which is in "unknown" state. 15:48:11 so we merged a PR "to see how it goes" 15:48:19 it needs... _seeing_ 15:48:21 hzyitc keep it updated 15:48:37 I mean, I can't _see_ it myself cos I don't have armhf boards 15:48:59 tl-dr: every board that boots zImage or uImage needs testing, period. 15:49:17 ok. like i said, lets focus to bugs hunting from today on 15:49:21 it is only tinkerboard 1 and tv box for rockchip. I believe I tested after we talked about the boot issue 15:49:29 not from next month on 15:49:36 if broken, fix we shall, and fast, but still needs testing... 15:50:01 yes, testing testing testing ... we need earlier due many changes in build assemly process 15:50:03 tonymac32: that was the 1st cycle of zImage problems, which I fixed with a hammer. @ hzyitc did further work 15:50:47 #idea send rpardini some armhf boards 15:51:06 not too many, mind you 15:51:21 rpardini can send you one allwinner 15:51:29 lets move on #rockchip 15:51:50 ok. 64bit but say 3399 only for now? 15:51:54 Jock is keeping 32b in good shape i would say 15:52:04 Paolo rocks 15:52:19 for 64bit ... speak up 15:52:37 TRS-80 how is adventure with PBPRO going? 15:52:39 well there has been progress with rockchip64 patches cleanup 15:52:50 but still, we have _evil_ patches in there 15:52:50 boards affected by switch of source configs to board configs need tested 15:53:29 I need to retract a few that got into non-rockchip64 boards because I was tired and got into a rythm 15:53:53 I think at least 2 "overwriting" patches, helios64 and smth else, and also bad/terrible patching of pinebookpro 15:54:29 I haven't gotten a replacement for my helios64 yet, so it is still production. no testing until the replacement arrives 15:54:57 lets look at family file super quick 15:55:19 anyone has radxa e25 15:55:24 TB2 not booting is new info to me, but it is also a csc 15:55:33 rockchip64: current = 5.15.y // edge = 6.1.y 15:55:42 that needs bumped 15:55:44 i saw that too, tb2 was working for me 15:55:50 current should be 6.1.y 15:55:53 tb2 works indeed 15:56:02 last time, but haven't tested after rpardini messed up the system ;) 15:56:10 pffft 15:56:30 well I wouldn't bump before we decide on those evil patches 15:56:39 not saying that 5.15.y is in good state, no 15:57:05 #action rockchip needs further patch cleaning 15:57:12 3399 specially I think 15:57:25 hmm, IIRC 5.15 has more issues than 6.1, we've been exclusively tuning on 6.1 15:57:37 also in 3399 territory: BRANCH=legacy is completely abandoned 4.x ? 15:57:46 oh, yes 15:57:51 that is in terrible state 15:57:54 tonymac32: that might very well be true. when I said tb2=works is on 6.1y 15:58:09 same, I ahven't built a 5.15 in forever 15:58:16 one solution would be to move to 5.10.y legacy 15:58:16 IgorPec: Apologies I was summoned to breakfast. PBP is working on recent images I tried, I can test more if needed, now that I have PBP onto eMMC. 15:58:47 TRS-80: can you update instructions on what are best ways to get it working on PBP download pages? 15:59:14 IgorPec: I can, but my recommentation would be 'install tow-boot to SPI' are you OK with that? 15:59:22 yes, i am ok with it 15:59:27 will do then 15:59:29 whatever works 15:59:31 #action TRS-80 adjusts setup instructions for pbp on download page 15:59:34 #idea lets have instructions for board on a Markdown heredoc _inside the board file_ 15:59:49 ew 16:00:05 keeping this updated is ... 16:00:13 ok 16:00:26 so no volonteer for sorting out legacy 3399 ? :) 16:00:31 if not, removing? 16:00:32 rpardini not a bad idea trs-80 tow-boot? really? 16:00:35 TRS-80: "install towboot to SPI" seems to be the generally accepted community solution, does nit? 16:00:56 rpardini: Yes, that's where I got the idea in fact. 16:01:06 this is good enough solution for PBP as nobody doesn't want to do it better 16:01:26 * tonymac32 shrugs it's knock-off u-boot with some cheap chrome paint so why not 16:01:32 In fact apparently you can even boot generic UEFI image this way on PBP(!). 16:01:44 just like with u-boot 16:01:52 Exactly. And that thing could even move pbp to arm64 generic image (plus some acpi=off and grub dtb injection) 16:01:53 tonymac32: They are trying to solve same problem we are just in a different way. 16:01:54 alternativly - if we know which u-boot works, then that 16:02:07 I can test it 16:02:25 pbp is also one of those - lets patch it up and forget about 16:02:26 tow-boot offeres 0 extra functionality of u-boot, just an interface 16:02:38 s/that thing/towboot, or some decent EFI capable bootloader in SPI/ 16:02:38 rpardini meant to say: Exactly. And towboot, or some decent EFI capable bootloader in SPI could even move pbp to arm64 generic image (plus some acpi=off and grub dtb injection) 16:02:53 but, if the vendor is blessing tow-boot, then it should be preferred and we then ignore bootloaders for the thing 16:02:57 pbp is not worth the time. that's the problem 16:03:14 i would rather see we enable Apple M1 and Snapdraggon 16:03:14 The problem on PBP is not 'which u-boot' but rather they stopped putting anything on SPI. And ex factory (Manjaro) image does not look as SD card. So 'anything on SPI' I think should work. I am willing to test. 16:03:16 yes and everyone I know how has it, has towboot in SPI. 16:03:37 It's worth my time because it's the only modern laptop/netbook I own. :) 16:03:51 it's a bit like Armbian's mainline uboot for Amlogic. I wish we had time/ppl to supply said towboot build, but we don't, so we go with the vendor 16:04:02 well, there are different hw revisions of Pinebooks and quality issues 16:04:06 which is impossible to fix 16:04:09 yeah 16:04:22 well yeah, I'd say write that in the Markdown board docs 16:04:30 ;-) 16:04:33 and again, towboot *is* u-boot. They seem to avoid that fact as much as possible in marketting 16:04:43 fixing dtb injection for Snapdraggon is better investment than 100+ fixing of PBP 16:04:54 lol yeah 16:05:02 dtb injection for Snapdraggon == gimme 16:05:05 So I can babysit on my own time, as I already been doing. Which I am going to keep doing regardless. Might as well try and bring what I learn to more people via Armbain. 16:05:18 if you guys wil laccept the patches 16:05:41 TRS-80: definitely do. I'd start by removing stuff we have that breaks stuff, instead of adding more, though. 16:05:45 TRS-80: we accept patches, but have to understand how much time was lost for this sh* and its still takin time 16:05:46 the tow-boot thing is purely "download from and flash to" instructions, yes? 16:05:58 ok, lets move on 16:06:19 well I had manjaro without anything flashed onto the spi and it booted micro sd card 16:06:39 #info wet wish to sort out 3399 legacy and bump it to 5.10.y 16:06:52 @Jason123 Talk to me after please, I would like more info. 16:06:56 if no more rockchip 16:06:57 #topic others 16:07:05 Jason123: great, go into Manjaro source's, find the towboot build, port it to Armbian, test it, submit PR 16:07:06 #topic board maintainers - others 16:07:09 tonymac32: I will FLUP with you as well. 16:07:12 (After) 16:07:27 Odroid XU4 16:07:34 works, its old 16:07:47 anything else? except a bunch of RISCV 16:07:51 ok, xu4: rename "BRANCH=current" to BRANCH="vendor" 16:07:52 manjaro uses uboot though 16:08:04 otherwise it looks like xu4 has a mainline kernel 16:08:09 right 16:08:27 what about upgrade? 16:08:30 Jason123: yeah whatever it is. steal it and PR and we'll think about it 16:08:32 it will fail 16:09:00 until we don't have a mechanism for easy upgrade and switching, changing the name = +troubles, no gain 16:09:02 it shouldn't fail, just not-upgrade 16:09:15 so, we better not touch 16:09:19 I can test ODROID-XU4, I still have one in production. I even have a spare in this case. 16:09:25 as its die out hw 16:09:32 xu4 works 16:09:43 yeah I just don't like the "current" there. I think its the only family where current is not really mainline-ish 16:09:44 this is hw from 2015 16:10:07 is the issue with the pinebook pro with armbian on emmc not booting into micro sd card? 16:10:11 i would agree on change once we would have automation behind 16:10:16 the odroid xu4 is not mainline? 16:10:17 I have a stack of XUF/MC1's 16:10:34 xu4 is mainline, just our kernel is not 16:10:41 as its attached to hardkernel branch 16:10:45 its close to 16:10:46 @Jason123 I can talk to you re: PBP after meeting, but now we are on to other topics. 16:11:02 this is a meeting? 16:11:03 right, we had some stability difficulties a couple years ago 16:11:15 @Jason123 yes 16:11:19 #action change branch when upgrade mechnism works 16:11:23 yeah, it's a vendor kernel. it's not "legacy" and it's not a mainline "current". it's a "vendor" kernel. 16:11:46 honestly did not know what I expected just thought this was a regular talk 16:11:48 killing upgrade is not an option here 16:11:56 rename = kill 16:12:09 I'd do this together with others, like rk3588, and yes we will have a kill upgrade, but we will in peace with our souls. 16:12:23 i would do when this is automagical 16:12:47 oh, automagical as in, rpardini automagically coded it into the system? :-D 16:13:09 as i agree with you that name is not appropriate, but this is old 32b kernel which we might perhaps rather retire 16:13:13 then code automagic 16:13:21 what about riscv stuff? 16:13:31 which goes under "others" 16:13:35 exactly my point. if I was suggesting to rename "current" to "actual" I'd agree we need automagical 16:13:36 make new kernel family available in the armbian-config somehow, users can switch or just never get new kernel updates if they don't choose 16:13:52 but no, I am suggesting DEMOTING a "current" to "vendor", so no automagic needed here IMHO 16:13:59 armbian-config is in terrible state due to lack of maint :( 16:14:38 I have checked with psychologist, and I've orders to not touch armbian-config, armbian-install, or any dialog-driven bash stuff for the next 10 years. 16:14:49 damn 16:14:56 :D 16:14:58 could change rk3588 to "vendor"when mainline becomes usable 16:15:14 todo for 2028 16:15:46 #info riscv sparks little interest. leave as is 16:15:59 rpi4 and uefi? 16:16:08 uefi with dtb injection 16:16:13 for 8cx 16:16:29 what can be done here? 16:16:35 rpi: we had fixes for esp flag in rpi3b (tested), and missing DTB since 6.1.y (fixed) 16:17:15 rpi: current = 6.1.y / edge = 6.2.y, both foundation kernels (I'd also change those to "vendor" to say the truth). 16:17:17 so rpi is fully functional? it would be nice to have - overlay support within armbian-config 16:17:46 #action also rpi kernel naming adjustement proposed 16:17:47 pi3b is supported by mainline? 16:17:56 rpi4b overlays need bigger treatment, I'd say in a larger "ovelays in general" effort 16:18:13 what is the prime issue here? 16:18:18 jason123: this is the Release meeting yes? 16:18:22 in overlay handling 16:18:32 it's inconsistent all around 16:18:46 each family does its own thing, prefixes, fixups, Makefile patching 16:19:19 understand. isn't overlay just adding a txt to config.txt or whatever that files is at rpi? 16:19:57 did not know this was a release meeting 16:19:59 #idea overlays stored in folder and copied to kernel sources for compilation instead of patched in. 16:20:01 yes with rpi overlays are prebuilt by foundation kernels and loaded magically together with dtb by rpi's bootloader 16:20:21 Now you know :) 16:20:25 yeah, and the txt file method doesn't work with extlinux, efi, etc 16:20:35 as i understand we "just" need to inplement mechanism specifically for rpi? 16:20:55 as no existing works 16:20:58 I refuse to do any work that is rpi-specific, though. 16:21:04 ok 16:21:04 rather do 20x more work, but useful for all. 16:21:13 i am just trying to understand 16:21:15 <3 rpardini 16:21:29 ok, what about Snapdraggon, apple' 16:21:34 what we can do here 16:21:42 separate overlay building from image building is an option, then have a package. in the case of rpi we don't need to build them, but could pacakge them 16:22:09 apple is a black hole, interesting but not valuable IMHO 16:22:11 overlays are packed with the image on rpi AFAIK 16:22:37 apple is ... well 16:22:41 I am extremely interested in both Snapdragon and Apple M1/M2. Send them to me and I will make them bend to the power of my `acpi=off` magic 16:23:03 it's the hardware version of ReactOS 16:23:04