Hi Hans, On 23 April 2015 at 10:15, Simon Glass <s...@chromium.org> wrote: > Hi Hans, > > On 23 April 2015 at 00:55, Hans de Goede <hdego...@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 <hdego...@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 <hdego...@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 <hdego...@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 <s...@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. Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
