All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] BUG: bootz/bootm command mandates a fdt blob
Date: Thu, 20 Nov 2014 20:48:18 +0100	[thread overview]
Message-ID: <546E4582.8060301@redhat.com> (raw)
In-Reply-To: <CANoR_OC_FrLYPnyhzCWc0Nj9TNDMpotBxhc1JYmVGQRW=+PpGw@mail.gmail.com>

Hi,

On 11/20/2014 08:41 PM, Suriyan Ramasami wrote:
> Hello Simon,
> 
> On Nov 20, 2014 8:38 AM, "Simon Glass" <sjg@chromium.org> wrote:
>>
>> Hi,
>>
>> On 20 November 2014 16:04, Hans de Goede <hdegoede@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?

Yes it is, so your above patch should do the trick nicely, thanks for working on
this.

Can you re-send as a proper patch, with commit message, rather then inline in
a mail ? (Please use git send-email if possible).

Regards,

Hans

      reply	other threads:[~2014-11-20 19:48 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-20 15:16 [U-Boot] BUG: bootz/bootm command mandates a fdt blob Suriyan Ramasami
2014-11-20 16:04 ` Hans de Goede
2014-11-20 16:38   ` Simon Glass
2014-11-20 19:41     ` Suriyan Ramasami
2014-11-20 19:48       ` Hans de Goede [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=546E4582.8060301@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.