u-boot DT configuration node

[Michal Simek]

On 08. 04. 20 8:57, Michal Simek wrote:
> On 02. 04. 20 13:34, Mark Kettenis wrote:
>>> From: Michal Simek <michal.simek at xilinx.com>
>>> Date: Thu, 2 Apr 2020 08:05:36 +0200
>>>
>>> On 01. 04. 20 20:09, Mark Kettenis wrote:
>>>>> From: Michal Simek <michal.simek at xilinx.com>
>>>>> Date: Wed, 1 Apr 2020 11:23:13 +0200
>>>>>
>>>>> Hi Rob and others,
>>>>>
>>>>> for couple of years already u-boot is using config node in root DT for
>>>>> u-boot configuration.
>>>>>
>>>>> Here is one example in u-boot source code.
>>>>> https://gitlab.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/exynos5250-spring.dts#L47
>>>>>
>>>>> And here is dt binding description
>>>>> https://gitlab.denx.de/u-boot/u-boot/-/blob/master/doc/device-tree-bindings/config.txt
>>>>>
>>>>> I was checking dt binding specification and there no such a thing
>>>>> described there. It means I expect this is more adhoc u-boot solution.
>>>>> We have reached the point where could be beneficial to put some u-boot
>>>>> specific configurations to DT.
>>>>>
>>>>> Actually I have done similar thing some time ago too by using chosen
>>>>> node and add xilinx specific property there to point to eeprom.
>>>>> https://gitlab.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/zynqmp-zcu102-revA.dts#L39
>>>>>
>>>>> I think it is a time to discuss it and do it properly.
>>>>>
>>>>> First of all my question is where we could list SW prefixes to make sure
>>>>> that they are listed and everybody is aware about it. We have
>>>>> vendor-prefixes and we should have a way to record also prefixes for sw
>>>>> projects. U-Boot is using u-boot. Xen has file in the kernel with using
>>>>> xen prefix. At least these two should be listed.
>>>>
>>>> OpenBSD is using "openbsd," as a prefix.  I've always thought it would
>>>> be good to have it listed in the list of vendor prefixes there.  In an
>>>> open source world it shouldn't matter whether an entity sells
>>>> something or not.  And in fact "inux," is already there.  And so is
>>>> "qemu,".
>>>
>>> Good we have more.
>>>
>>>
>>>>
>>>>> Next my question is what is the recommended way to pass sw specific
>>>>> parameters via DT? I think using chosen node is more appropriate then
>>>>> adhoc config node. Or is there a better way how this should be done?
>>>>
>>>> On OpenBSD we do indeed use the the chosen node to pass information
>>>> between the bootloader and the kernel.
>>>
>>> Can you please point me to any example or description what you are
>>> adding there?
>>
>> Here is an example of what the chosen node looks like:
>>
>>     Node 0x2220
>>             name: 'chosen'
>>             openbsd,uefi-mmap-desc-ver: 00000001
>>             openbsd,uefi-mmap-desc-size: 00000030
>>             openbsd,uefi-mmap-size: 00000540
>>             openbsd,uefi-mmap-start: 00000081.fbe37df8
>>             openbsd,uefi-system-table: 00000081.ff910018
>>             openbsd,bootduid: 1b33bbab.1613122f
>>             bootargs: 'sd0a:/bsd'
>>             stdout-path: '/smb/serial at e1010000'
>>
>> The openbsd,uefi-* proprties are effectively the same those already
>> documented for linux and xen.  The openbsd,bootduid contains the
>> unique idea of the boot disk such that the kernel can find it and use
>> it as its root disk.  There is also an openbsd,bootmac property to
>> support netbooting, and openbsd,sr-bootuuid and openbsd,sr-bootkey
>> properties to support booting from software raid with full disk
>> encryption.  The actual key is zeroed out as soon as possible by the
>> kernel.
>>
>> This all is pretty much a private interface between the boot loader
>> and the kernel though.
>>
>> For booting on arm64 systems that use ACPI instead of a device tree,
>> the bootloader creates its own minimal device tree that contains a few
>> specific nodes that use compatible properties wuth an "openbsd,"
>> prefix.  But once again that is a private interface between bootloader
>> and kernel.
> 
> Rob: any comment?

Rob: Another reminder?

Thanks,
Michal