On Mon, 23 May 2022 at 01:22, Konrad Dybcio <konrad.dybcio@xxxxxxxxxxxxxx> wrote: > > Hi, > > removing these properties will not bring almost any benefit (other than making > some checks happy any saving some <200 LoC) and will make the lives of almost > all people doing independent development for linux-on-msm harder. There are > almost unironically like 3 people outside Linaro and QUIC who have > non-vendor-fused development boards AND the sources to rebuild the > bootloader on their own. Making it harder to boot is only going to > discourage people from developing on these devices, which is already not > that pleasant, especially with newer platforms where you have to fight with > the oh-so-bright ideas of Android boot chain.. > > This only concerns devices released before sm8350, as the new ones will not > even boot with these properties present (or at least SONY Sagami, but I > doubt it's an isolated case), so other than completing support for older > devices, it won't be an issue going forward, anyway. But there are give > or take 50 locked down devices in mainline right now, and many more waiting > to be upstreamed in various downstream close-to-mainline trees that should > not be disregarded just because Qualcomm is far from the best at making > their BSP software stack clean. > > One solution is to chainload another, (n+1)-stage bootloader, but this is > not ideal, as: > > 1) the stock bootloader can boot Linux just fine on most devices (except > for single exceptions, where beloved OEMs didn't implement arm64 booting or > something) > > 2) the boot chain on MSM is already 3- or 4- stage and adding to that will > only create an unnecessary mess > > 3) the job of kernel people is not to break userspace. If the > device can not even exit bootloader after a kernel upgrade, it's a big > failure. > > If you *really really really* want these either gone or documented, we can > for example use them in the SOCID driver, read the values from DTB and > compare against what SMEM has to say and for example print a warning when > there are inconsistencies or use it as a fallback when it fails for any > reason, such as using a newer SoC on an older kernel, without updates > for SOCID read (which are sometimes necessary, which was the case for 8450 > recently, iirc). > > My stance is to just leave them as is, as moving them anywhere, or removing > them at all will cause unnecessary mess and waste time that could have been > spent on more glaring issues.. I couldn't have put it better myself. I suggest we document these properties, if that is the blocker, and keep them. A lot has changed in the last 7 years, we now have dozens of devices booting upstream kernel using these properties. And fwiw, I have not used dtbTool before, if anything I'd rather explore dtb overlays. Regards, Amit Pundir > > Konrad
