+Scott
Hi Hans,
On 28 April 2015 at 17:29, Simon Glass sjg@chromium.org wrote:
On 24 April 2015 at 07:34, Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 24-04-15 14:42, Simon Glass wrote:
Hi Hans,
On 23 April 2015 at 10:15, Simon Glass sjg@chromium.org wrote:
Hi Hans,
On 23 April 2015 at 00:55, Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 22-04-15 19:20, Simon Glass wrote:
Hi Hans,
On 20 April 2015 at 12:10, Hans de Goede hdegoede@redhat.com wrote: > > > Hi, > > On 20-04-15 17:39, Simon Glass wrote: >> >> >> >> Hi Hans, >> >> On 20 April 2015 at 03:13, Hans de Goede hdegoede@redhat.com wrote: >>> >>> >>> >>> After syncing the sunxi dts files with the upstream kernel dm/fdt >>> sunxi >>> builds would no longer boot. >>> >>> The problem is that stdout-path is now set like this in the upstream >>> dts >>> files: stdout-path = "serial0:115200n8". The use of options in >>> of-paths, >>> either after an alias name, or after a full path, e.g. stdout-path = >>> "/soc@01c00000/serial@01c28000:115200", is standard of usage, but >>> something >>> which the u-boot dts code so far did not handle. >>> >>> This commit fixes this, adding support for both path formats. >>> >>> Signed-off-by: Hans de Goede hdegoede@redhat.com >>> --- >>> arch/arm/dts/sun7i-a20-pcduino3.dts | 2 +- >>> lib/libfdt/fdt_ro.c | 25 >>> ++++++++++++++++++++++--- >> >> >> >> >> I haven't looked. but is this change in dtc upstream or just in the >> kernel? > > > > > This is just a change in the dts files shipped with the kernel not in > dtc, > the dts files for sunxi used to not set stdout-path, and you patched > in > a stdout-path setting for u-boot:
In that case, can we change this in the fdt support /fdtdec code, instead of making a change to libfdt that will never go upstream?
If that doesn't work or is too painful, then we should take this patch.
Actually I started with fixing this the fdtdev level, but then I noticed that the kernel does this at the of_find_node_by_path level, so if we fix this for stdout-path only (which a fdtdec patch would do) then we may get bit by this again later.
Also fixing it at the fdtdec level means adding a strdup + error checking since then we need to pass a truncated (options removed) copy of the path to fdt_path_offset(), while with the current patch we can keep using read only access to the fdt.
So I've a slight preference for going this way. Why would libfdt upstream not take this patch ?
I'm not sure, but please go ahead and send it upstream. Thanks for the explanation, I'll pick this up.
Acked-by: Simon Glass sjg@chromium.org
Can I just check if you are OK to send this upstream? We don't need to wait for it to be accepted, just want to know it will be sent.
Yes I will submit this upstream.
Applied to u-boot-fdt, thanks!
It looks like this was rejected upstream. If so can you please create a patch for fdtdec.c (I assume) to move your code into there?
Regards, Simon