devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michal Simek <michal.simek@xilinx.com>
To: Mark Kettenis <mark.kettenis@xs4all.nl>,
	Michal Simek <michal.simek@xilinx.com>,
	robh@kernel.org
Cc: devicetree@vger.kernel.org, u-boot@lists.denx.de,
	trini@konsulko.com, loic.poulain@linaro.org
Subject: Re: u-boot DT configuration node
Date: Wed, 8 Apr 2020 08:57:06 +0200	[thread overview]
Message-ID: <c4c6da5b-dce4-fbe2-52a4-753fb283bcd8@xilinx.com> (raw)
In-Reply-To: <01615b4c8ab806fd@bloch.sibelius.xs4all.nl>

On 02. 04. 20 13:34, Mark Kettenis wrote:
>> From: Michal Simek <michal.simek@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@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@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



  reply	other threads:[~2020-04-08  6:57 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-01  9:23 u-boot DT configuration node Michal Simek
2020-04-01 18:09 ` Mark Kettenis
2020-04-02  6:05   ` Michal Simek
2020-04-02 11:34     ` Mark Kettenis
2020-04-08  6:57       ` Michal Simek [this message]
2020-04-27 12:06         ` Michal Simek
2020-04-28 13:23 ` Rob Herring
2020-04-28 13:50   ` Michal Simek
2020-04-29 14:55     ` Rob Herring
2020-04-30 11:13       ` Michal Simek
2020-05-14 18:07         ` Rob Herring
2020-05-14 18:46           ` Michal Simek
2020-05-18 15:55             ` Rob Herring
2020-05-18 16:05               ` Michal Simek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c4c6da5b-dce4-fbe2-52a4-753fb283bcd8@xilinx.com \
    --to=michal.simek@xilinx.com \
    --cc=devicetree@vger.kernel.org \
    --cc=loic.poulain@linaro.org \
    --cc=mark.kettenis@xs4all.nl \
    --cc=robh@kernel.org \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).