All of lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas-5wv7dgnIgG8@public.gmane.org>
To: Leif Lindholm <leif.lindholm-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Roy Franz <roy.franz-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	"linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	"msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org"
	<msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Subject: Re: EFI_STUB fails to boot non-EFI on arm64
Date: Tue, 8 Jul 2014 10:21:00 +0100	[thread overview]
Message-ID: <20140708092100.GA21320@arm.com> (raw)
In-Reply-To: <20140523150331.GS4179-t77nlHhSwNqAroYi2ySoxKxOck334EZe@public.gmane.org>

I forgot about this thread. I think we need it sorted in some way.

On Fri, May 23, 2014 at 04:03:31PM +0100, Leif Lindholm wrote:
> On Fri, May 23, 2014 at 02:47:20PM +0100, Catalin Marinas wrote:
> > Can we add another of detecting whether it's an EFI application and
> > avoid calling efi_init()? I can see x86 sets some efi_loader_signature
> > string in exit_boot() and checks against it later when calling
> > efi_init().

So, to be in line with 32-bit arm, the only way to tell the uncompressed
kernel image that it was started as an EFI application is via FDT.

> My view is that this should be fixed in fdt_find_uefi_params(). A
> single info message that we can't find evidence of UEFI should be
> printed in the non-error case.
[...]
> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> index cd36deb..4bb42e1e 100644
> --- a/drivers/firmware/efi/efi.c
> +++ b/drivers/firmware/efi/efi.c
> @@ -366,11 +366,8 @@ static int __init fdt_find_uefi_params(unsigned long node, const char *uname,
>  
>  	for (i = 0; i < ARRAY_SIZE(dt_params); i++) {
>  		prop = of_get_flat_dt_prop(node, dt_params[i].propname, &len);
> -		if (!prop) {
> -			pr_err("Can't find %s in device tree!\n",
> -			       dt_params[i].name);
> -			return 0;
> -		}
> +		if (!prop)
> +			goto fail;
>  		dest = info->params + dt_params[i].offset;
>  
>  		val = of_read_number(prop, len / sizeof(u32));
> @@ -385,6 +382,14 @@ static int __init fdt_find_uefi_params(unsigned long node, const char *uname,
>  				dt_params[i].size * 2, val);
>  	}
>  	return 1;
> +
> +	fail:
> +	if (i == 0)
> +		pr_info("  UEFI not found.\n");
> +	else
> +		pr_err("Can't find %s in device tree!\n", dt_params[i].name);
> +
> +	return 0;

I'm ok with the idea but I don't particularly like the implementation.
Does this look any better (functionally the same as yours)?

diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index eff1a2f22f09..dc79346689e6 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -346,6 +346,7 @@ static __initdata struct {
 
 struct param_info {
 	int verbose;
+	int found;
 	void *params;
 };
 
@@ -362,16 +363,12 @@ static int __init fdt_find_uefi_params(unsigned long node, const char *uname,
 	    (strcmp(uname, "chosen") != 0 && strcmp(uname, "chosen@0") != 0))
 		return 0;
 
-	pr_info("Getting parameters from FDT:\n");
-
 	for (i = 0; i < ARRAY_SIZE(dt_params); i++) {
 		prop = of_get_flat_dt_prop(node, dt_params[i].propname, &len);
-		if (!prop) {
-			pr_err("Can't find %s in device tree!\n",
-			       dt_params[i].name);
+		if (!prop)
 			return 0;
-		}
 		dest = info->params + dt_params[i].offset;
+		info->found++;
 
 		val = of_read_number(prop, len / sizeof(u32));
 
@@ -390,10 +387,21 @@ static int __init fdt_find_uefi_params(unsigned long node, const char *uname,
 int __init efi_get_fdt_params(struct efi_fdt_params *params, int verbose)
 {
 	struct param_info info;
+	int ret;
+
+	pr_info("Getting EFI parameters from FDT:\n");
 
 	info.verbose = verbose;
+	info.found = 0;
 	info.params = params;
 
-	return of_scan_flat_dt(fdt_find_uefi_params, &info);
+	ret = of_scan_flat_dt(fdt_find_uefi_params, &info);
+	if (!info.found)
+		pr_info("UEFI not found.\n");
+	else if (!ret)
+		pr_err("Can't find '%s' in device tree!\n",
+		       dt_params[info.found].name);
+
+	return ret;
 }
 #endif /* CONFIG_EFI_PARAMS_FROM_FDT */

WARNING: multiple messages have this Message-ID (diff)
From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: EFI_STUB fails to boot non-EFI on arm64
Date: Tue, 8 Jul 2014 10:21:00 +0100	[thread overview]
Message-ID: <20140708092100.GA21320@arm.com> (raw)
In-Reply-To: <20140523150331.GS4179@bivouac.eciton.net>

I forgot about this thread. I think we need it sorted in some way.

On Fri, May 23, 2014 at 04:03:31PM +0100, Leif Lindholm wrote:
> On Fri, May 23, 2014 at 02:47:20PM +0100, Catalin Marinas wrote:
> > Can we add another of detecting whether it's an EFI application and
> > avoid calling efi_init()? I can see x86 sets some efi_loader_signature
> > string in exit_boot() and checks against it later when calling
> > efi_init().

So, to be in line with 32-bit arm, the only way to tell the uncompressed
kernel image that it was started as an EFI application is via FDT.

> My view is that this should be fixed in fdt_find_uefi_params(). A
> single info message that we can't find evidence of UEFI should be
> printed in the non-error case.
[...]
> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> index cd36deb..4bb42e1e 100644
> --- a/drivers/firmware/efi/efi.c
> +++ b/drivers/firmware/efi/efi.c
> @@ -366,11 +366,8 @@ static int __init fdt_find_uefi_params(unsigned long node, const char *uname,
>  
>  	for (i = 0; i < ARRAY_SIZE(dt_params); i++) {
>  		prop = of_get_flat_dt_prop(node, dt_params[i].propname, &len);
> -		if (!prop) {
> -			pr_err("Can't find %s in device tree!\n",
> -			       dt_params[i].name);
> -			return 0;
> -		}
> +		if (!prop)
> +			goto fail;
>  		dest = info->params + dt_params[i].offset;
>  
>  		val = of_read_number(prop, len / sizeof(u32));
> @@ -385,6 +382,14 @@ static int __init fdt_find_uefi_params(unsigned long node, const char *uname,
>  				dt_params[i].size * 2, val);
>  	}
>  	return 1;
> +
> +	fail:
> +	if (i == 0)
> +		pr_info("  UEFI not found.\n");
> +	else
> +		pr_err("Can't find %s in device tree!\n", dt_params[i].name);
> +
> +	return 0;

I'm ok with the idea but I don't particularly like the implementation.
Does this look any better (functionally the same as yours)?

diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index eff1a2f22f09..dc79346689e6 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -346,6 +346,7 @@ static __initdata struct {
 
 struct param_info {
 	int verbose;
+	int found;
 	void *params;
 };
 
@@ -362,16 +363,12 @@ static int __init fdt_find_uefi_params(unsigned long node, const char *uname,
 	    (strcmp(uname, "chosen") != 0 && strcmp(uname, "chosen at 0") != 0))
 		return 0;
 
-	pr_info("Getting parameters from FDT:\n");
-
 	for (i = 0; i < ARRAY_SIZE(dt_params); i++) {
 		prop = of_get_flat_dt_prop(node, dt_params[i].propname, &len);
-		if (!prop) {
-			pr_err("Can't find %s in device tree!\n",
-			       dt_params[i].name);
+		if (!prop)
 			return 0;
-		}
 		dest = info->params + dt_params[i].offset;
+		info->found++;
 
 		val = of_read_number(prop, len / sizeof(u32));
 
@@ -390,10 +387,21 @@ static int __init fdt_find_uefi_params(unsigned long node, const char *uname,
 int __init efi_get_fdt_params(struct efi_fdt_params *params, int verbose)
 {
 	struct param_info info;
+	int ret;
+
+	pr_info("Getting EFI parameters from FDT:\n");
 
 	info.verbose = verbose;
+	info.found = 0;
 	info.params = params;
 
-	return of_scan_flat_dt(fdt_find_uefi_params, &info);
+	ret = of_scan_flat_dt(fdt_find_uefi_params, &info);
+	if (!info.found)
+		pr_info("UEFI not found.\n");
+	else if (!ret)
+		pr_err("Can't find '%s' in device tree!\n",
+		       dt_params[info.found].name);
+
+	return ret;
 }
 #endif /* CONFIG_EFI_PARAMS_FROM_FDT */

  parent reply	other threads:[~2014-07-08  9:21 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-23  9:45 EFI_STUB fails to boot non-EFI on arm64 Catalin Marinas
2014-05-23  9:45 ` Catalin Marinas
     [not found] ` <20140523094513.GC9252-5wv7dgnIgG8@public.gmane.org>
2014-05-23 13:16   ` Leif Lindholm
2014-05-23 13:16     ` Leif Lindholm
     [not found]     ` <20140523131656.GR4179-t77nlHhSwNqAroYi2ySoxKxOck334EZe@public.gmane.org>
2014-05-23 13:24       ` Matt Fleming
2014-05-23 13:24         ` Matt Fleming
2014-05-23 13:47       ` Catalin Marinas
2014-05-23 13:47         ` Catalin Marinas
     [not found]         ` <20140523134720.GA9256-5wv7dgnIgG8@public.gmane.org>
2014-05-23 15:03           ` Leif Lindholm
2014-05-23 15:03             ` Leif Lindholm
     [not found]             ` <20140523150331.GS4179-t77nlHhSwNqAroYi2ySoxKxOck334EZe@public.gmane.org>
2014-05-23 15:17               ` Ard Biesheuvel
2014-05-23 15:17                 ` Ard Biesheuvel
     [not found]                 ` <CAKv+Gu-4ExoNfGVJzUK4v06XD5V3nYfRetoefY0RuFsN1CUOzg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-05-23 15:45                   ` Leif Lindholm
2014-05-23 15:45                     ` Leif Lindholm
     [not found]                     ` <20140523154551.GT4179-t77nlHhSwNqAroYi2ySoxKxOck334EZe@public.gmane.org>
2014-05-23 18:03                       ` Roy Franz
2014-05-23 18:03                         ` Roy Franz
2014-05-23 19:43                       ` Ard Biesheuvel
2014-05-23 19:43                         ` Ard Biesheuvel
2014-05-28 15:59               ` Will Deacon
2014-05-28 15:59                 ` Will Deacon
     [not found]                 ` <20140528155931.GA20523-5wv7dgnIgG8@public.gmane.org>
2014-05-28 18:05                   ` Leif Lindholm
2014-05-28 18:05                     ` Leif Lindholm
     [not found]                     ` <20140528180525.GU4179-t77nlHhSwNqAroYi2ySoxKxOck334EZe@public.gmane.org>
2014-05-28 18:40                       ` Will Deacon
2014-05-28 18:40                         ` Will Deacon
     [not found]                         ` <20140528184043.GB20523-5wv7dgnIgG8@public.gmane.org>
2014-05-28 20:42                           ` Leif Lindholm
2014-05-28 20:42                             ` Leif Lindholm
2014-07-08  9:21               ` Catalin Marinas [this message]
2014-07-08  9:21                 ` Catalin Marinas
     [not found]                 ` <20140708092100.GA21320-5wv7dgnIgG8@public.gmane.org>
2014-07-08 11:09                   ` Leif Lindholm
2014-07-08 11:09                     ` Leif Lindholm

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=20140708092100.GA21320@arm.com \
    --to=catalin.marinas-5wv7dgnigg8@public.gmane.org \
    --cc=leif.lindholm-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=roy.franz-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    /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.