Re: Removal of qcom,board-id and qcom,msm-id

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 20/05/2022 03:39, Dmitry Baryshkov wrote:
> 
>>
>> 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.
> 

I entirely missed one part - Stephen's patches from 2015 were actually
applied and since 2015 we expect all boards to follow convention:

compatible =
"qcom,<SoC>[-<soc_version>][-<foundry_id>]-<board>[/<subtype>][-<board_version>]"

The patchset was accepted, although in the thread I do not see "Applied"
message.

Stephen,
can you or anyone else confirm that the dtbTool Qualcomm uses (and/or
bootloader) are adjusted as well to these new compatibles?

If yes, we can simply remove board-id and msm-id properties from new
boards, because 7 years was enough to switch to these new tools...

Best regards,
Krzysztof



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux