From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Jackson Subject: Re: [PATCH RFC OSSTEST 14/19] Osstest/Debian: Support for loading an FDT from u-boot script Date: Fri, 10 Oct 2014 15:29:33 +0100 Message-ID: <21559.60749.678505.689257@mariner.uk.xensource.com> References: <1412942404.27111.12.camel@citrix.com> <1412942554-752-14-git-send-email-ian.campbell@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1412942554-752-14-git-send-email-ian.campbell@citrix.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 Campbell Cc: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org Ian Campbell writes ("[PATCH RFC OSSTEST 14/19] Osstest/Debian: Support for loading an FDT from u-boot script"): > The currently supported platform provides an FDT preloaded at > 0x1000. Replace this with ${fdt_addr} (which the current platform > exposes) and for platforms which do not provide an fdt arrange to > load the relevant file as named in the ${fdtfile} (which is > conventionally provided by u-boot for platforms which need this). You should mention the extra `echo's in the commit message. You have two copies of the same dtb-loading code. (You had two copies of the `scsi scan' and `mw.l' previously, but this is now worse because it's bigger.) I confess I don't really understand some of this. `Platforms which do not provide an fdt' are ones where ${fdt_addr} is empty ? And on those platforms `fdt addr \${fdt_addr}' is a no-op ? You might find the code clearer (less toothpick-counting) if you used <<'delim' for some of it, at one or other of the levels. Thanks, Ian.