> 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. Cheers, Mark
