[PATCH 00/21] Qualcomm generic board support

[ff]

> Le 4 déc. 2023 à 14:25, Sumit Garg <sumit.garg at linaro.org> a écrit :
> 
> On Mon, 4 Dec 2023 at 16:30, Daniel Thompson <daniel.thompson at linaro.org> wrote:
>> 
>>> On Mon, Dec 04, 2023 at 11:02:57AM +0530, Sumit Garg wrote:
>>> + Linux kernel DT bindings maintainers, EBBR ML
>>> 
>>> On Thu, 30 Nov 2023 at 20:05, Tom Rini <trini at konsulko.com> wrote:
>>>> On Thu, Nov 30, 2023 at 01:02:25PM +0530, Sumit Garg wrote:
>>>>> On Wed, 29 Nov 2023 at 22:06, Neil Armstrong <neil.armstrong at linaro.org> wrote:
>>>>>>> I've been thinking about and hacking on this for the last week or so,
>>>>>>> sorry for the delayed reply here.
>>>>>>> 
>>>>>>> The value is in preventing any of the existing bindings from regressing,
>>>>> 
>>>>> That is actually best addressed in Linux by checking the DTS against
>>>>> yaml DT bindings. We don't have that testing available in u-boot and
>>>>> only depend on careful reviews.
>>>> 
>>>> I would absolutely love for someone to make another attempt at updating
>>>> our kbuild infrastucture so that we can run the validation targets.
>>>> 
>>> 
>>> Given that EBBR requires [1] the platform (firmware/bootloader) and
>>> not OS to supply the devicetree, it becomes evident that
>>> firmware/bootloaders import DTS from Linux kernel (where it is
>>> maintained).
>>> 
>>> But currently u-boot doesn't have a proper way to validate those DTS
>>> against DT bindings (maintained in Linux kernel). Although there are
>>> Devicetree schema tools available here [2], there isn't a versioned
>>> release package of DT bindings which one should use to validate DTS
>>> files.
>> 
>> The kernel is regularly released in multiple forms (including git
>> tags and tarball). Why isn't the kernel itself sufficient to be a
>> versioned release of the DT bindings directory?
>> 
> 
> The Linux kernel may come in various forms (upstream vs stable vs
> vendor). It's difficult to decide from where the DT bindings should
> come from. Should they come from upstream or should they come from the
> kernel which is actually booted onto a particular device?
> 
Looks bad from organizing forward portability standpoint .

> IOW, as of now which kernel version should u-boot pick up for DT
> validation checks?
> 
> If we can have a separate release cadence for DT bindings then the
> platform (firmware/bootloader) can attest the DTB against that. Later
> one should be able to boot any kernel with the DTB provided by
> platform.
> 
That seems a very good step!
> -Sumit
> 
>> 
>> Daniel.
> _______________________________________________
> boot-architecture mailing list -- boot-architecture at lists.linaro.org
> To unsubscribe send an email to boot-architecture-leave at lists.linaro.org