On 08. 04. 20 8:57, Michal Simek wrote: > On 02. 04. 20 13:34, Mark Kettenis wrote: >>> From: Michal Simek <michal.simek@xxxxxxxxxx> >>> Date: Thu, 2 Apr 2020 08:05:36 +0200 >>> >>> On 01. 04. 20 20:09, Mark Kettenis wrote: >>>>> From: Michal Simek <michal.simek@xxxxxxxxxx> >>>>> 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@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
