From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH RFC OSSTEST 14/19] Osstest/Debian: Support for loading an FDT from u-boot script Date: Fri, 10 Oct 2014 15:37:03 +0100 Message-ID: <1412951823.27111.36.camel@citrix.com> References: <1412942404.27111.12.camel@citrix.com> <1412942554-752-14-git-send-email-ian.campbell@citrix.com> <21559.60749.678505.689257@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <21559.60749.678505.689257@mariner.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Jackson Cc: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On Fri, 2014-10-10 at 15:29 +0100, Ian Jackson wrote: > I confess I don't really understand some of this. `Platforms which do > not provide an fdt' are ones where ${fdt_addr} is empty ? Yes. Midway (marilith) provides a dtb in the firmware, and it is located at $fdt_addr. This is how device tree is supposed to work, but is actually vanishingly rare on ARM+u-boot in real life (I've never seen another such platform...) In practice most ARM+u-boot platforms require you to load the dtb from somewhere by hand, and provide fdt_addr_r as the place you should put it. (EFI on arm64 is a bit better here...) > And on > those platforms `fdt addr \${fdt_addr}' is a no-op ? fdt_addr is set by the new code on those platforms. > You might find the code clearer (less toothpick-counting) if you used > <<'delim' for some of it, at one or other of the levels. You mean as opposed to <