+Scott Hi Hans,
On 28 April 2015 at 17:29, Simon Glass <[email protected]> wrote: > > On 24 April 2015 at 07:34, Hans de Goede <[email protected]> wrote: > > Hi, > > > > > > On 24-04-15 14:42, Simon Glass wrote: > >> > >> Hi Hans, > >> > >> On 23 April 2015 at 10:15, Simon Glass <[email protected]> wrote: > >>> > >>> Hi Hans, > >>> > >>> On 23 April 2015 at 00:55, Hans de Goede <[email protected]> wrote: > >>>> > >>>> Hi, > >>>> > >>>> > >>>> On 22-04-15 19:20, Simon Glass wrote: > >>>>> > >>>>> > >>>>> Hi Hans, > >>>>> > >>>>> On 20 April 2015 at 12:10, Hans de Goede <[email protected]> wrote: > >>>>>> > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> On 20-04-15 17:39, Simon Glass wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Hi Hans, > >>>>>>> > >>>>>>> On 20 April 2015 at 03:13, Hans de Goede <[email protected]> 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 <[email protected]> > >>>>>>>> --- > >>>>>>>> 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 <[email protected]> > >>> > >> > >> 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 _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
