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? Thanks, Michal
