On Tue, 24 May 2022 at 00:50, Bjorn Andersson <bjorn.andersson@xxxxxxxxxx> wrote: > > On Mon 23 May 02:21 CDT 2022, Krzysztof Kozlowski wrote: > > > On 22/05/2022 21:51, Konrad Dybcio wrote: > > I actually wonder why do you need these properties for community work on > > such boards? You ship kernel with one concatenated DTB and the > > bootloader does not need the board-id/msm-id fields, doesn't it? You know, this reminds me of an old argument dating 2005-7: why do we need to support multi-platform kernels, while we can boot a good plain single-mach (or a single-board) kernel on a particular board. Supporting msm-id/board-id/pmic-id gives us flexibility. Dropping them would remove flexibility. > > Not mentioning that in the past bootloader was actually not using these > > properties at all, because it was the dtbTool who was parsing them. So > > in any case either your device works fine without these properties or > > you have to use dtbTool, right? I think it was supposed to be done in an opposite way: to let dtbTool process compat strings and generate the properties in question. > > > > > > 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. > > > > The job of kernel people is to follow bindings and since they were > > introduced 7 years ago, I would say there was plenty of time for that. > > > > We're following the bindings and don't pick board-id or msm-id unless > there's a particular reason for it - which typically is that the > downstream bootloader requires it - we don't use the properties on the > kernel side. Or unless we have another reason (like handling a single RB3+RB5 image). I suspect PmOS might also like shipping a single image for some/all of the supported devices. Or we might use that for the qcom-armv8a OE machine. > > > If the dtbTool support for the bindings is there, then there is no > > breakage, because you had to use dtbTool before so you have to use now. > > > > Among all the platforms I maintain, MSM8916 (db410c) is the only one > where I use dtbTool - because it refuses to accept the concatenated > dtb. It's strange, I have been using concatenated dtb with db410c for ages. -- With best wishes Dmitry
