On Fri, 20 May 2022 at 01:12, Stephen Boyd <sboyd@xxxxxxxxxx> wrote: > > Quoting Dmitry Baryshkov (2022-05-19 05:46:53) > > On 19/05/2022 14:53, Krzysztof Kozlowski wrote: > > > On 19/05/2022 13:39, Dmitry Baryshkov wrote: > > >> On 19/05/2022 13:44, Krzysztof Kozlowski wrote: > > >>> Hi, > > >>> > > >>> There was an old effort of removal of qcom,board-id and qcom,msm-id > > >>> properties from Qualcomm SoC-based boards like [1]. > > >>> > > >>> First approach was to document them, which (obviously) was not well > > >>> received [2] [3] [4]. > > >>> > > >>> The solution from Stephen was to encode these in the board compatible, > > >>> so bootloader can extract that information. That seemed to receive > > >>> positive comments, at least from Rob. [5] > > >>> > > >>> It was 2015... ~7 years later we are still things doing the same way, > > >>> still with undocumented properties: qcom,board-id and qcom,msm-id. > > >>> > > >>> > > >>> I would like to revive that topic, but before I start doing something > > >>> pointless - any guidance on last patch from Stephen [5]? Was it ok? Some > > >>> early NAKs? > > >> > > >> I do not quite fancy the idea of using extra tools to process dtb files. > > >> At this moment it is possible to concatenate several kernel-generated > > >> dtb files together. AOSP developers use this to have an image that boots > > >> on both RB3 and RB5 boards. > > >> > > >> I think that changing compat strings only makes sense if Qualcomm would > > >> use such compat strings in future. Otherwise we end up in a position > > >> where we have custom bootloaders for the RB3/RB5/etc, but the majority > > >> of the board requires extra processing steps. > > > > > > This was discussed in [2] [3] and [4] (previous links) and did not pass. > > > > > > Do you have any new arguments for above objections from Arnd, Olof and > > > Rob? I don't think patch will get accepted if previous concerns during > > > review are not addressed... > > > > I'm not sure if the patches to the dtbTool have landed or not. > > Anyway, as I said, I don't think post-processing the dtb is good way to > > go. It makes extremely hard to check that the dtb, used by the kernel or > > being a part of the boot.img, corresponds to this or that compiled dtb. > > One option would be to work it into upstream DTC :P Then the properties > could be injected during the compilation stage. Note that DTC already > injects properties like linux,phandle so I'm not really following how > dtbTool mucking with the DTB is any different. See, after running make dtbs you get a set of artifacts, Image.gz and set of dtbs (yes, extended with phandle/linux,phandle). Then one generates a boot.img. Now without the dtbTool step you can dissect the boot.img and verify that dtbs match what you've generated/provided/etc. If one employs dtbTool, there no simple way to match dtbs from boot.img with dtbs from kernel build process. This might be required e.g. to check what the user has been testing, etc. > Can you elaborate on what > is extremely hard? Would working dtbTool into the kernel build process > alleviate any issues? >From my point of view, yet, it will. So will e.g. using any preprocessor magic to generate such properties during the dts->dtb process. > > I vaguely recall that the properties had to be extracted during the > boot.img creation process to create a table of contents header. But > after some time the bootloader started scanning the DTBs directly for > the vendor properties and thus the header was deprecated/removed. If the > bootloader is doing the scanning then I'm not sure what is preventing > the properties from being documented and allowed. I think the main > rejection was that the properties were added purely to be extracted > during post processing and placed into the table of contents header, > i.e. they weren't actually used by the kernel or the bootloader. If they > are now used by the bootloader it sounds OK to me if they're kept > around. Yes, as far as I understand, they are used by the bootloader directly. -- With best wishes Dmitry
