Hello Simon,
On Nov 20, 2014 8:38 AM, "Simon Glass" <s...@chromium.org> wrote:
>
> Hi,
>
> On 20 November 2014 16:04, Hans de Goede <hdego...@redhat.com> wrote:
> > Hi Suriyan,
> >
> > On 11/20/2014 04:16 PM, Suriyan Ramasami wrote:
> >> Hello Simon,
> >> This mail is addressed to you as the FDT support was added by
> >> you. I am not sure who else to address it to.
>
> Just to be clear, I didn't add FDT support, this predates my
> involvement in U-Boot. I added CONFIG_OF_CONTROL etc. though. Han's
> solution sounds good to me.
>
Sorry about that. In no way was I accusing you :-) I stand corrected though.
> >>
> >> I find that if CONFIG_OF_LIBFDT is defined then the user is
> >> forced to provide a FDT blob. In most of the cases it makes sense.
> >> However, this removes the ability to boot older linux (non FDT).
> >> For example, I was looking at the Hardkernel Odroid kernels for
> >> the U2/U3, and they are 3.8 based. Of course newer kernels 3.17 work.
> >> For users to use the same boot loader for 3.8 and for 3.17, they
> >> cannot use the mainline uboot.
> >
> > I've hit the same problem myself recently, see the thread titled:
> >
> > "Booting non devicetree enabled kernels using u-boot build with
CONFIG_OF_LIBFDT"
> >
> >> I was wondering if teh third argument to bootz/bootm etc could
> >> also take the route of initrd (optional if - is specified) could be
> >> implemented.
> >>
> >> The fix seems to be trivial (or so I think), in file
> >> common/image-fdt.c, but wanted to know your comments on this. Also the
> >> command help (for bootz etc) states that if the 3rd argument is not
> >> passed, then the bd_info struct is passed, and I do not see it being
> >> passed in the code anywhere. In the absence of the third parameter, it
> >> just gives a "No fdt found" message.
> >
> > Thanks for working on a fix, as discussed in the earlier thread,
requiring
> > a third argument which is '-' will break old boot.scr files and the
likes,
> > so a better fix is to:
> >
> > 1) Always try to find an ftd (to keep things like appended ftd-s
working)
> > 2) If not found see if there is a third argument, if there is, treat
this
> > as a fatal error, abort the bootm (iow behave as before)
> > 3) If there is not a third argument warn and continue as before.
> >
> > If you could respin your patch to do this, then that would be great.
> >
Hello Hans/Simon,
I have been tracing the code paths and see that function
bootm_find_fdt() is the final fdt prep function.
To retain all its previous functionality, but introducing a warning
condition if no third argument is present, but go ahead and boot without
fdt should keep the peace.
The easiest way to achieve this is: (takes care of 2 and 3 above)
diff --git a/common/image-fdt.c b/common/image-fdt.c
index a39ae1b..1a02166 100644
--- a/common/image-fdt.c
+++ b/common/image-fdt.c
@@ -430,6 +430,10 @@ int boot_get_fdt(int flag, int argc, char * const
argv[], u
error:
*of_flat_tree = NULL;
*of_size = 0;
+ if (argc <= 2) {
+ debug("Continuing to boot without FDT\n");
+ return 0;
+ }
return 1;
}
For case 1, is this already handled in the code? I need some more
information on this. I did run a 3.17 zImage with an appended dtb and it
did boot up, but I am guessing that it is the linux kernel separating the
dtb out?
Thanks
- Suriyan
> > Regards,
> >
> > Hans
> >
> >
> >>
> >> diff --git a/common/image-fdt.c b/common/image-fdt.c
> >> index a39ae1b..e685700 100644
> >> --- a/common/image-fdt.c
> >> +++ b/common/image-fdt.c
> >> @@ -243,7 +243,10 @@ int boot_get_fdt(int flag, int argc, char * const
argv[], u
> >>
> >> if (argc > 2)
> >> select = argv[2];
> >> - if (select || genimg_has_config(images)) {
> >> + if (select && strcmp(select, "-") == 0) {
> >> + debug("## Skipping fdt\n");
> >> + return 0;
> >> + } else if (select || genimg_has_config(images)) {
> >> #if defined(CONFIG_FIT)
> >> if (select) {
> >> /*
> >>
> >> Regards
> >> - Suriyan
> >> _______________________________________________
> >> U-Boot mailing list
> >> U-Boot@lists.denx.de
> >> http://lists.denx.de/mailman/listinfo/u-boot
> >>
>
> Regards,
> Simon
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
