From mboxrd@z Thu Jan 1 00:00:00 1970 From: York Sun Date: Tue, 1 Sep 2015 22:04:17 -0500 Subject: [U-Boot] [PATCH 2/2] fdt_support: Don't panic if unable to perform stdout fixup In-Reply-To: References: <1441073150-15143-1-git-send-email-scottwood@freescale.com> <1441073484-15640-1-git-send-email-scottwood@freescale.com> <1441077387.4966.49.camel@freescale.com> Message-ID: <55E66731.7080800@freescale.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 09/01/2015 09:48 PM, Simon Glass wrote: > Hi Scott, > > On 31 August 2015 at 21:16, Scott Wood wrote: >> On Mon, 2015-08-31 at 21:13 -0600, Simon Glass wrote: >>> Hi Scott, >>> >>> On 31 August 2015 at 20:11, Scott Wood wrote: >>>> Currently, using fdt_fixup_stdout() on a device tree that is missing >>>> the relevant alias results in this: >>>> >>>> WARNING: could not set linux,stdout-path FDT_ERR_NOTFOUND. >>>> ERROR: /chosen node create failed >>>> - must RESET the board to recover. >>>> >>>> FDT creation failed! hanging...### ERROR ### Please RESET the board ### >>>> >>>> There is no reason for this to be a fatal error rather than a warning, >>>> and removing this allows for a smooth transition on a platform where >>>> the device tree currently lacks the correct aliases but will have them >>>> in the future. >>> >>> Why do we need this patch - what platform? >> >> LS2085A >> >>> >>>> >>>> Signed-off-by: Scott Wood >>>> Cc: Kumar Gala >>>> Cc: Simon Glass >>>> --- >>>> Resent with correct address for Simon Glass. >>>> >>>> common/fdt_support.c | 3 ++- >>>> 1 file changed, 2 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/common/fdt_support.c b/common/fdt_support.c >>>> index f86365e..6052c77 100644 >>>> --- a/common/fdt_support.c >>>> +++ b/common/fdt_support.c >>>> @@ -308,7 +308,8 @@ int fdt_chosen(void *fdt) >>>> } >>>> } >>>> >>>> - return fdt_fixup_stdout(fdt, nodeoffset); >>>> + fdt_fixup_stdout(fdt, nodeoffset); >>> >>> Will some platforms will not boot correctly with this failing? Should >>> we make your new feature a Kconfig options perhaps? I worry that it >>> will become the default behaviour and then it will be hard to remove >>> later. >> >> A warning will still be printed. I'm not sure how "### ERROR ### Please >> RESET the board ###" is more useful than trying to continue and possibly >> failing. > > Only that if it indicates a fatal error the board code can at least > find out about it and deal with it. Perhaps booting will just result > in a hang? > > I think ignoring errors is fine but here we make it impossible to > detect a failure. So I think that a Kconfig is the best idea, so we > can remove it later. How about a big warning instead? In general, having the message to reset the board doesn't help much if it is a fatal condition. We have to use external tool to recover the board. On the other side, if the error is not fatal, continue to boot may give the user a chance to reflash an update. York