All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Glass <sjg@chromium.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2 2/5] fdt: boot_get_fdt: really boot w/o FDT when "goto no_fdt"
Date: Sun, 21 Apr 2019 12:26:19 -0700	[thread overview]
Message-ID: <CAPnjgZ3aYAPxm300rxHLYQoEZx80YRo4k+HVhnHzxiZ=SooqgA@mail.gmail.com> (raw)
In-Reply-To: <20190401104537.29801-3-erosca@de.adit-jv.com>

On Mon, 1 Apr 2019 at 03:46, Eugeniu Rosca <erosca@de.adit-jv.com> wrote:
>
> The 'no_fdt' goto label was introduced by v2015.01 commit [0] and it
> had two review stages [1-2]. The *documented* purpose behind commit [0]
> is (excerpt from commit description):
>
> > allows both FDT and non-FDT kernels to boot by making the
> > third parameter to the bootm/bootz optional
>
> While [1] and [2] share the same goal, they have very different
> implementations:
>  - [1] was based on a very simple 'argc' check at function error out
>    with returning success to the caller if the third parameter was NOT
>    passed to bootm/bootz command. This approach had the downside of
>    returning success to the caller even in case of legitimate internal
>    errors, which should halt booting.
>  - [2] added the "no_fdt" label and several "goto no_fdt" statements.
>    This allowed to report the legitimate internal errors to the caller.
>
> IOW the major difference between [1] and [2] is:
>  - [1] boot w/o FDT if FDT address is not passed to boot{m,z,*}
>  - [2] give *freedom* to the developer to boot w/o FDT from any
>    (more or less) arbitrary point in the function flow (and here
>    comes the peculiar aspect, which looks to be a leftover from [1])
>    with the precondition that the 3rd argument (FDT address) is NOT
>    provided to boot{m,z,*}. In practice, this means that only a subset
>    of "goto no_fdt" end up booting w/o FDT while the other subset is
>    returning an error to the caller.
>
> This patch removes the peculiar behavior described above, such that
> "goto no_fdt" performs really what it tells to the developer.
>
> The motivation of this patch is to decrease the unneeded complexity
> and increase the readability of boot_get_fdt().
>
> [0] 48aead71c1ad ("fdt: Allow non-FDT kernels to boot when CONFIG_OF_LIBFDT is defined")
> [1] https://patchwork.ozlabs.org/patch/412923/
>     ("[U-Boot,v1] fdt: Allow non-FDT kernels to boot when CONFIG_OF_LIBFDT is defined")
> [2] https://patchwork.ozlabs.org/patch/415635/
>     ("[U-Boot,v2] fdt: Allow non-FDT kernels to boot when CONFIG_OF_LIBFDT is defined")
>
> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
> ---
> Changes in v2:
>  - NA
>  - Link v1: https://patchwork.ozlabs.org/patch/1071587/
> ---
>  common/image-fdt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

Reviewed-by: Simon Glass <sjg@chromium.org>

Can we create a test of the boot_get_fdt() behaviour?

We have test_fit and test_vboot as possible examples, although perhaps
a test that directly calls this function would be better?

Regards,
Simon



> diff --git a/common/image-fdt.c b/common/image-fdt.c
> index 1817ce6bce30..c335e7e2f220 100644
> --- a/common/image-fdt.c
> +++ b/common/image-fdt.c
> @@ -489,7 +489,7 @@ int boot_get_fdt(int flag, int argc, char * const argv[], uint8_t arch,
>  no_fdt:
>         ok_no_fdt = 1;
>  error:
> -       if (!select && ok_no_fdt) {
> +       if (ok_no_fdt) {
>                 debug("Continuing to boot without FDT\n");
>                 return 0;
>         }
> --
> 2.21.0
>

  reply	other threads:[~2019-04-21 19:26 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-01 10:45 [U-Boot] [PATCH v2 0/5] boot_get_fdt: clean up and use 'fdtaddr' as fallback for Android Eugeniu Rosca
2019-04-01 10:45 ` [U-Boot] [PATCH v2 1/5] fdt: boot_get_fdt: remove redundant zeroing out Eugeniu Rosca
2019-04-18  4:33   ` Simon Glass
2019-04-18 10:18     ` Eugeniu Rosca
2019-04-20  1:36       ` Simon Glass
2019-04-22  2:38       ` sjg at google.com
2019-04-25 17:00     ` Eugeniu Rosca
2019-04-01 10:45 ` [U-Boot] [PATCH v2 2/5] fdt: boot_get_fdt: really boot w/o FDT when "goto no_fdt" Eugeniu Rosca
2019-04-21 19:26   ` Simon Glass [this message]
2019-04-22  2:38   ` sjg at google.com
2019-04-25 17:04     ` Eugeniu Rosca
2019-04-01 10:45 ` [U-Boot] [PATCH v2 3/5] fdt: boot_get_fdt: simplify no_fdt handling (non-functional) Eugeniu Rosca
2019-04-21 19:26   ` Simon Glass
2019-04-22  2:38   ` sjg at google.com
2019-04-01 10:45 ` [U-Boot] [PATCH v2 4/5] fdt: boot_get_fdt: android: compress " Eugeniu Rosca
2019-04-21 19:26   ` Simon Glass
2019-04-22  2:38   ` sjg at google.com
2019-04-01 10:52 ` [U-Boot] [PATCH v2 5/5] fdt: boot_get_fdt: android: use ENV 'fdtaddr' as fallback Eugeniu Rosca
2019-04-01 15:26   ` Eugeniu Rosca
2019-04-21 19:26   ` Simon Glass
2019-04-22  2:38   ` sjg at google.com

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='CAPnjgZ3aYAPxm300rxHLYQoEZx80YRo4k+HVhnHzxiZ=SooqgA@mail.gmail.com' \
    --to=sjg@chromium.org \
    --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.