[PATCH 0/3] cmd: pxe: support INITRD and FDT selection with FIT
Since the commit d5ba6188dfbf ("cmd: pxe_utils: Check fdtcontroladdr in label_boot") the FDT or the FDTDIR label is required in extlinux.conf and the fallback done by bootm command when only the device tree is present in this command parameters is no more performed when FIT is used for kernel.
The next file "extlinux.conf" no more selects the device tree in FIT but use the pxe fallback with the device tree of U-Boot.
menu title Select the boot mode DEFAULT test LABEL test KERNEL /fitImage
This serie restores the possibility to use a FIT in extlinux.conf by using FDT label with the same string.
menu title Select the boot mode DEFAULT test LABEL test KERNEL /fitImage FDT /fitImage
even when a specific FIT config is used:
menu title Select the boot mode DEFAULT test LABEL test KERNEL /fitImage#config FDT /fitImage#config
The last commit of the series is only a minor improvement.
Patrick Delaunay (3): cmd: pxe: reorder kernel treatment in label_boot cmd: pxe: support INITRD and FDT selection with FIT cmd: pxe: use strdup to copy config
boot/pxe_utils.c | 69 +++++++++++++++++++++++++-------------------- doc/README.pxe | 8 ++++++ include/pxe_utils.h | 2 ++ 3 files changed, 49 insertions(+), 30 deletions(-)
Reorder kernel treatment in label_boot at the beginning of the function.
This patch doesn't change the pxe command behavior, it is only a preliminary step for next patch, build kernel_addr before parsing the label initrd and fdt to build the next bootm arguments.
Signed-off-by: Patrick Delaunay patrick.delaunay@foss.st.com ---
boot/pxe_utils.c | 49 ++++++++++++++++++++++++------------------------ 1 file changed, 24 insertions(+), 25 deletions(-)
diff --git a/boot/pxe_utils.c b/boot/pxe_utils.c index d5c215ae2c1d..844ab72252bf 100644 --- a/boot/pxe_utils.c +++ b/boot/pxe_utils.c @@ -522,6 +522,27 @@ static int label_boot(struct pxe_context *ctx, struct pxe_label *label) return 1; }
+ if (get_relfile_envaddr(ctx, label->kernel, "kernel_addr_r", + NULL) < 0) { + printf("Skipping %s for failure retrieving kernel\n", + label->name); + return 1; + } + + kernel_addr = env_get("kernel_addr_r"); + /* for FIT, append the configuration identifier */ + if (label->config) { + int len = strlen(kernel_addr) + strlen(label->config) + 1; + + fit_addr = malloc(len); + if (!fit_addr) { + printf("malloc fail (FIT address)\n"); + return 1; + } + snprintf(fit_addr, len, "%s%s", kernel_addr, label->config); + kernel_addr = fit_addr; + } + if (label->initrd) { ulong size;
@@ -529,21 +550,14 @@ static int label_boot(struct pxe_context *ctx, struct pxe_label *label) &size) < 0) { printf("Skipping %s for failure retrieving initrd\n", label->name); - return 1; + goto cleanup; }
initrd_addr_str = env_get("ramdisk_addr_r"); size = snprintf(initrd_str, sizeof(initrd_str), "%s:%lx", initrd_addr_str, size); if (size >= sizeof(initrd_str)) - return 1; - } - - if (get_relfile_envaddr(ctx, label->kernel, "kernel_addr_r", - NULL) < 0) { - printf("Skipping %s for failure retrieving kernel\n", - label->name); - return 1; + goto cleanup; }
if (label->ipappend & 0x1) { @@ -573,7 +587,7 @@ static int label_boot(struct pxe_context *ctx, struct pxe_label *label) strlen(label->append ?: ""), strlen(ip_str), strlen(mac_str), sizeof(bootargs)); - return 1; + goto cleanup; }
if (label->append) @@ -588,21 +602,6 @@ static int label_boot(struct pxe_context *ctx, struct pxe_label *label) printf("append: %s\n", finalbootargs); }
- kernel_addr = env_get("kernel_addr_r"); - - /* for FIT, append the configuration identifier */ - if (label->config) { - int len = strlen(kernel_addr) + strlen(label->config) + 1; - - fit_addr = malloc(len); - if (!fit_addr) { - printf("malloc fail (FIT address)\n"); - return 1; - } - snprintf(fit_addr, len, "%s%s", kernel_addr, label->config); - kernel_addr = fit_addr; - } - /* * fdt usage is optional: * It handles the following scenarios.
On 28/10/2022 11:01, Patrick Delaunay wrote:
Reorder kernel treatment in label_boot at the beginning of the function.
This patch doesn't change the pxe command behavior, it is only a preliminary step for next patch, build kernel_addr before parsing the label initrd and fdt to build the next bootm arguments.
Signed-off-by: Patrick Delaunay patrick.delaunay@foss.st.com
boot/pxe_utils.c | 49 ++++++++++++++++++++++++------------------------ 1 file changed, 24 insertions(+), 25 deletions(-)
diff --git a/boot/pxe_utils.c b/boot/pxe_utils.c index d5c215ae2c1d..844ab72252bf 100644 --- a/boot/pxe_utils.c +++ b/boot/pxe_utils.c @@ -522,6 +522,27 @@ static int label_boot(struct pxe_context *ctx, struct pxe_label *label) return 1; }
- if (get_relfile_envaddr(ctx, label->kernel, "kernel_addr_r",
NULL) < 0) {printf("Skipping %s for failure retrieving kernel\n",label->name);return 1;- }
- kernel_addr = env_get("kernel_addr_r");
- /* for FIT, append the configuration identifier */
- if (label->config) {
int len = strlen(kernel_addr) + strlen(label->config) + 1;fit_addr = malloc(len);if (!fit_addr) {printf("malloc fail (FIT address)\n");return 1;}snprintf(fit_addr, len, "%s%s", kernel_addr, label->config);kernel_addr = fit_addr;- }
- if (label->initrd) { ulong size;
@@ -529,21 +550,14 @@ static int label_boot(struct pxe_context *ctx, struct pxe_label *label) &size) < 0) { printf("Skipping %s for failure retrieving initrd\n", label->name);
return 1;
goto cleanup;}
initrd_addr_str = env_get("ramdisk_addr_r"); size = snprintf(initrd_str, sizeof(initrd_str), "%s:%lx", initrd_addr_str, size); if (size >= sizeof(initrd_str))
return 1;- }
- if (get_relfile_envaddr(ctx, label->kernel, "kernel_addr_r",
NULL) < 0) {printf("Skipping %s for failure retrieving kernel\n",label->name);return 1;
goto cleanup;}
if (label->ipappend & 0x1) {
@@ -573,7 +587,7 @@ static int label_boot(struct pxe_context *ctx, struct pxe_label *label) strlen(label->append ?: ""), strlen(ip_str), strlen(mac_str), sizeof(bootargs));
return 1;
goto cleanup;}
if (label->append)
@@ -588,21 +602,6 @@ static int label_boot(struct pxe_context *ctx, struct pxe_label *label) printf("append: %s\n", finalbootargs); }
- kernel_addr = env_get("kernel_addr_r");
- /* for FIT, append the configuration identifier */
- if (label->config) {
int len = strlen(kernel_addr) + strlen(label->config) + 1;fit_addr = malloc(len);if (!fit_addr) {printf("malloc fail (FIT address)\n");return 1;}snprintf(fit_addr, len, "%s%s", kernel_addr, label->config);kernel_addr = fit_addr;- }
- /*
- fdt usage is optional:
- It handles the following scenarios.
Reviewed-by: Neil Armstrong neil.armstrong@linaro.org
On Fri, Oct 28, 2022 at 11:01:18AM +0200, Patrick Delaunay wrote:
Reorder kernel treatment in label_boot at the beginning of the function.
This patch doesn't change the pxe command behavior, it is only a preliminary step for next patch, build kernel_addr before parsing the label initrd and fdt to build the next bootm arguments.
Signed-off-by: Patrick Delaunay patrick.delaunay@foss.st.com Reviewed-by: Neil Armstrong neil.armstrong@linaro.org
Applied to u-boot/next, thanks!
Since the commit d5ba6188dfbf ("cmd: pxe_utils: Check fdtcontroladdr in label_boot") the FDT or the FDTDIR label is required in extlinux.conf and the fallback done by bootm command when only the device tree present in this command parameters is no more performed when FIT is used for kernel.
When the label FDT or FDTDIR are absent or if the device tree file is absent, the PXE command in U-Boot uses the default U-Boot device tree selected by fdtcontroladdr = gd->fdt_blob, it is the "Scenario 3".
With this scenario the bootm FIP fallback is no more possible with the extlinux.conf when only "kernel" label is present and is a FIP:
kernel <path>#<conf>[#<extra-conf[#...]]
As the U-Boot FDT is always provided in the third bootm argument, the device tree found in FIP is not used as fallback, it was done previously in boot_get_fdt().
This patch adds a new field kernel_label to save the full kernel label. The FDT bootm parameters use the kernel address (to avoid to load a second time the same FIP) and the config when this full label is reused for "fdt" or "initrd" label.
This FIP support in extlinux.conf is restored when the "FDT" label can be found and select the same FIP (identical file and configuration):
kernel <path>#<conf>[#<extra-conf[#...]] fdt <path>#<conf>[#<extra-conf[#...]]
The patch add also this possibility for initrd.
initrd <path>#<conf>[#<extra-conf[#...]]
Signed-off-by: Patrick Delaunay patrick.delaunay@foss.st.com ---
boot/pxe_utils.c | 17 ++++++++++++++--- doc/README.pxe | 8 ++++++++ include/pxe_utils.h | 2 ++ 3 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/boot/pxe_utils.c b/boot/pxe_utils.c index 844ab72252bf..756b201eda91 100644 --- a/boot/pxe_utils.c +++ b/boot/pxe_utils.c @@ -259,6 +259,7 @@ static struct pxe_label *label_create(void) static void label_destroy(struct pxe_label *label) { free(label->name); + free(label->kernel_label); free(label->kernel); free(label->config); free(label->append); @@ -543,9 +544,11 @@ static int label_boot(struct pxe_context *ctx, struct pxe_label *label) kernel_addr = fit_addr; }
- if (label->initrd) { + /* For FIT, the label can be identical to kernel one */ + if (label->initrd && !strcmp(label->kernel_label, label->initrd)) { + initrd_addr_str = kernel_addr; + } else if (label->initrd) { ulong size; - if (get_relfile_envaddr(ctx, label->initrd, "ramdisk_addr_r", &size) < 0) { printf("Skipping %s for failure retrieving initrd\n", @@ -623,8 +626,11 @@ static int label_boot(struct pxe_context *ctx, struct pxe_label *label) */ bootm_argv[3] = env_get("fdt_addr_r");
+ /* For FIT, the label can be identical to kernel one */ + if (label->fdt && !strcmp(label->kernel_label, label->fdt)) { + bootm_argv[3] = kernel_addr; /* if fdt label is defined then get fdt from server */ - if (bootm_argv[3]) { + } else if (bootm_argv[3]) { char *fdtfile = NULL; char *fdtfilefree = NULL;
@@ -1165,6 +1171,11 @@ static int parse_label_kernel(char **c, struct pxe_label *label) if (err < 0) return err;
+ /* copy the kernel label to compare with FDT / INITRD when FIT is used */ + label->kernel_label = strdup(label->kernel); + if (!label->kernel_label) + return -ENOMEM; + s = strstr(label->kernel, "#"); if (!s) return 1; diff --git a/doc/README.pxe b/doc/README.pxe index d14d2bdcc9b0..172201093d02 100644 --- a/doc/README.pxe +++ b/doc/README.pxe @@ -179,11 +179,19 @@ initrd <path> - if this label is chosen, use tftp to retrieve the initrd at <path>. it will be stored at the address indicated in the initrd_addr_r environment variable, and that address will be passed to bootm. + For FIT image, the initrd can be provided with the same value than + kernel, including configuration: + <path>#<conf>[#<extra-conf[#...]] + In this case, kernel_addr_r is passed to bootm.
fdt <path> - if this label is chosen, use tftp to retrieve the fdt blob at <path>. it will be stored at the address indicated in the fdt_addr_r environment variable, and that address will be passed to bootm. + For FIT image, the device tree can be provided with the same value + than kernel, including configuration: + <path>#<conf>[#<extra-conf[#...]] + In this case, kernel_addr_r is passed to bootm.
devicetree <path> - if this label is chosen, use tftp to retrieve the fdt blob at <path>. it will be stored at the address indicated in diff --git a/include/pxe_utils.h b/include/pxe_utils.h index 4a73b2aace34..1e5e8424f53f 100644 --- a/include/pxe_utils.h +++ b/include/pxe_utils.h @@ -28,6 +28,7 @@ * Create these with the 'label_create' function given below. * * name - the name of the menu as given on the 'menu label' line. + * kernel_label - the kernel label, including FIT config if present. * kernel - the path to the kernel file to use for this label. * append - kernel command line to use when booting this label * initrd - path to the initrd to use for this label. @@ -40,6 +41,7 @@ struct pxe_label { char num[4]; char *name; char *menu; + char *kernel_label; char *kernel; char *config; char *append;
Hi Patrick,
On 28/10/2022 11:01, Patrick Delaunay wrote:
Since the commit d5ba6188dfbf ("cmd: pxe_utils: Check fdtcontroladdr in label_boot") the FDT or the FDTDIR label is required in extlinux.conf and the fallback done by bootm command when only the device tree present in this command parameters is no more performed when FIT is used for kernel.
When the label FDT or FDTDIR are absent or if the device tree file is absent, the PXE command in U-Boot uses the default U-Boot device tree selected by fdtcontroladdr = gd->fdt_blob, it is the "Scenario 3".
With this scenario the bootm FIP fallback is no more possible with the extlinux.conf when only "kernel" label is present and is a FIP:
kernel <path>#<conf>[#<extra-conf[#...]]
As the U-Boot FDT is always provided in the third bootm argument, the device tree found in FIP is not used as fallback, it was done previously in boot_get_fdt().
This patch adds a new field kernel_label to save the full kernel label. The FDT bootm parameters use the kernel address (to avoid to load a second time the same FIP) and the config when this full label is reused for "fdt" or "initrd" label.
This FIP support in extlinux.conf is restored when the "FDT" label can be found and select the same FIP (identical file and configuration):
kernel <path>#<conf>[#<extra-conf[#...]] fdt <path>#<conf>[#<extra-conf[#...]]
The patch add also this possibility for initrd.
initrd <path>#<conf>[#<extra-conf[#...]]
Thanks for providing this solution, indeed it solves the original issue and permits specifying different DT and INITRD configs which is neat.
I haven't tested it yet, but so far:
Reviewed-by: Neil Armstrong neil.armstrong@linaro.org
Signed-off-by: Patrick Delaunay patrick.delaunay@foss.st.com
boot/pxe_utils.c | 17 ++++++++++++++--- doc/README.pxe | 8 ++++++++ include/pxe_utils.h | 2 ++ 3 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/boot/pxe_utils.c b/boot/pxe_utils.c index 844ab72252bf..756b201eda91 100644 --- a/boot/pxe_utils.c +++ b/boot/pxe_utils.c @@ -259,6 +259,7 @@ static struct pxe_label *label_create(void) static void label_destroy(struct pxe_label *label) { free(label->name);
- free(label->kernel_label); free(label->kernel); free(label->config); free(label->append);
@@ -543,9 +544,11 @@ static int label_boot(struct pxe_context *ctx, struct pxe_label *label) kernel_addr = fit_addr; }
- if (label->initrd) {
- /* For FIT, the label can be identical to kernel one */
- if (label->initrd && !strcmp(label->kernel_label, label->initrd)) {
initrd_addr_str = kernel_addr;- } else if (label->initrd) { ulong size;
- if (get_relfile_envaddr(ctx, label->initrd, "ramdisk_addr_r", &size) < 0) { printf("Skipping %s for failure retrieving initrd\n",
@@ -623,8 +626,11 @@ static int label_boot(struct pxe_context *ctx, struct pxe_label *label) */ bootm_argv[3] = env_get("fdt_addr_r");
- /* For FIT, the label can be identical to kernel one */
- if (label->fdt && !strcmp(label->kernel_label, label->fdt)) {
bootm_argv[3] = kernel_addr;
- if (bootm_argv[3]) {
- } else if (bootm_argv[3]) { char *fdtfile = NULL; char *fdtfilefree = NULL;
@@ -1165,6 +1171,11 @@ static int parse_label_kernel(char **c, struct pxe_label *label) if (err < 0) return err;
- /* copy the kernel label to compare with FDT / INITRD when FIT is used */
- label->kernel_label = strdup(label->kernel);
- if (!label->kernel_label)
return -ENOMEM;- s = strstr(label->kernel, "#"); if (!s) return 1;
diff --git a/doc/README.pxe b/doc/README.pxe index d14d2bdcc9b0..172201093d02 100644 --- a/doc/README.pxe +++ b/doc/README.pxe @@ -179,11 +179,19 @@ initrd <path> - if this label is chosen, use tftp to retrieve the initrd at <path>. it will be stored at the address indicated in the initrd_addr_r environment variable, and that address will be passed to bootm.
For FIT image, the initrd can be provided with the same value thankernel, including configuration:<path>#<conf>[#<extra-conf[#...]]In this case, kernel_addr_r is passed to bootm.fdt <path> - if this label is chosen, use tftp to retrieve the fdt blob at <path>. it will be stored at the address indicated in the fdt_addr_r environment variable, and that address will be passed to bootm.
For FIT image, the device tree can be provided with the same valuethan kernel, including configuration:<path>#<conf>[#<extra-conf[#...]]In this case, kernel_addr_r is passed to bootm.devicetree <path> - if this label is chosen, use tftp to retrieve the fdt blob at <path>. it will be stored at the address indicated in
diff --git a/include/pxe_utils.h b/include/pxe_utils.h index 4a73b2aace34..1e5e8424f53f 100644 --- a/include/pxe_utils.h +++ b/include/pxe_utils.h @@ -28,6 +28,7 @@
- Create these with the 'label_create' function given below.
- name - the name of the menu as given on the 'menu label' line.
- kernel_label - the kernel label, including FIT config if present.
- kernel - the path to the kernel file to use for this label.
- append - kernel command line to use when booting this label
- initrd - path to the initrd to use for this label.
@@ -40,6 +41,7 @@ struct pxe_label { char num[4]; char *name; char *menu;
- char *kernel_label; char *kernel; char *config; char *append;
On Fri, Oct 28, 2022 at 11:01:19AM +0200, Patrick Delaunay wrote:
Since the commit d5ba6188dfbf ("cmd: pxe_utils: Check fdtcontroladdr in label_boot") the FDT or the FDTDIR label is required in extlinux.conf and the fallback done by bootm command when only the device tree present in this command parameters is no more performed when FIT is used for kernel.
When the label FDT or FDTDIR are absent or if the device tree file is absent, the PXE command in U-Boot uses the default U-Boot device tree selected by fdtcontroladdr = gd->fdt_blob, it is the "Scenario 3".
With this scenario the bootm FIP fallback is no more possible with the extlinux.conf when only "kernel" label is present and is a FIP:
kernel <path>#<conf>[#<extra-conf[#...]]
As the U-Boot FDT is always provided in the third bootm argument, the device tree found in FIP is not used as fallback, it was done previously in boot_get_fdt().
This patch adds a new field kernel_label to save the full kernel label. The FDT bootm parameters use the kernel address (to avoid to load a second time the same FIP) and the config when this full label is reused for "fdt" or "initrd" label.
This FIP support in extlinux.conf is restored when the "FDT" label can be found and select the same FIP (identical file and configuration):
kernel <path>#<conf>[#<extra-conf[#...]] fdt <path>#<conf>[#<extra-conf[#...]]
The patch add also this possibility for initrd.
initrd <path>#<conf>[#<extra-conf[#...]]
Signed-off-by: Patrick Delaunay patrick.delaunay@foss.st.com Reviewed-by: Neil Armstrong neil.armstrong@linaro.org
Applied to u-boot/next, thanks!
Replace malloc and strcpy by strdup in function parse_label_kernel.
Signed-off-by: Patrick Delaunay patrick.delaunay@foss.st.com ---
boot/pxe_utils.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/boot/pxe_utils.c b/boot/pxe_utils.c index 756b201eda91..84e63c5cb85f 100644 --- a/boot/pxe_utils.c +++ b/boot/pxe_utils.c @@ -1180,11 +1180,10 @@ static int parse_label_kernel(char **c, struct pxe_label *label) if (!s) return 1;
- label->config = malloc(strlen(s) + 1); + label->config = strdup(s); if (!label->config) return -ENOMEM;
- strcpy(label->config, s); *s = 0;
return 1;
On 28/10/2022 11:01, Patrick Delaunay wrote:
Replace malloc and strcpy by strdup in function parse_label_kernel.
Signed-off-by: Patrick Delaunay patrick.delaunay@foss.st.com
boot/pxe_utils.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/boot/pxe_utils.c b/boot/pxe_utils.c index 756b201eda91..84e63c5cb85f 100644 --- a/boot/pxe_utils.c +++ b/boot/pxe_utils.c @@ -1180,11 +1180,10 @@ static int parse_label_kernel(char **c, struct pxe_label *label) if (!s) return 1;
- label->config = malloc(strlen(s) + 1);
- label->config = strdup(s); if (!label->config) return -ENOMEM;
strcpy(label->config, s); *s = 0;
return 1;
Reviewed-by: Neil Armstrong neil.armstrong@linaro.org
On Fri, Oct 28, 2022 at 11:01:20AM +0200, Patrick Delaunay wrote:
Replace malloc and strcpy by strdup in function parse_label_kernel.
Signed-off-by: Patrick Delaunay patrick.delaunay@foss.st.com Reviewed-by: Neil Armstrong neil.armstrong@linaro.org
Applied to u-boot/next, thanks!
Hi Tom,
On 12/12/22 22:34, Tom Rini wrote:
On Fri, Oct 28, 2022 at 11:01:20AM +0200, Patrick Delaunay wrote:
Replace malloc and strcpy by strdup in function parse_label_kernel.
Signed-off-by: Patrick Delaunay patrick.delaunay@foss.st.com Reviewed-by: Neil Armstrong neil.armstrong@linaro.org
Applied to u-boot/next, thanks!
I believe this was a mistake?
This introduces a pretty bad regression as existing extlinux.conf won't boot anymore. Distros will need to have different extlinux depending on which U-Boot version is running on the system.
Was the merge done with this information in mind?
Cheers, Quentin
On Tue, Dec 13, 2022 at 10:03:17AM +0100, Quentin Schulz wrote:
Hi Tom,
On 12/12/22 22:34, Tom Rini wrote:
On Fri, Oct 28, 2022 at 11:01:20AM +0200, Patrick Delaunay wrote:
Replace malloc and strcpy by strdup in function parse_label_kernel.
Signed-off-by: Patrick Delaunay patrick.delaunay@foss.st.com Reviewed-by: Neil Armstrong neil.armstrong@linaro.org
Applied to u-boot/next, thanks!
I believe this was a mistake?
This introduces a pretty bad regression as existing extlinux.conf won't boot anymore. Distros will need to have different extlinux depending on which U-Boot version is running on the system.
Was the merge done with this information in mind?
No, I was unware of that, sigh. I'll go push through a revert to next shortly..
Hi Patrick,
Thanks for looking at it.
On 10/28/22 11:01, Patrick Delaunay wrote:
Since the commit d5ba6188dfbf ("cmd: pxe_utils: Check fdtcontroladdr in label_boot") the FDT or the FDTDIR label is required in extlinux.conf and the fallback done by bootm command when only the device tree is present in this command parameters is no more performed when FIT is used for kernel.
The next file "extlinux.conf" no more selects the device tree in FIT but use the pxe fallback with the device tree of U-Boot.
menu title Select the boot mode DEFAULT test LABEL test KERNEL /fitImage
This serie restores the possibility to use a FIT in extlinux.conf by using FDT label with the same string.
menu title Select the boot mode DEFAULT test LABEL test KERNEL /fitImage FDT /fitImage
even when a specific FIT config is used:
menu title Select the boot mode DEFAULT test LABEL test KERNEL /fitImage#config FDT /fitImage#config
The last commit of the series is only a minor improvement.
I tested this on my Puma RK3399 and it does work again, thanks.
However, I'm not sure this is what we should go for?
My worry is the following: What happens for old releases (pre-v2022.04) where KERNEL worked just fine without the FDT to load the fdt from the fitimage conf specified in KERNEL field? Would we now need to keep an extlinux.conf for pre-2022.04 releases where FDT wouldn't be set and one for 2023.01 and later where FDT would be mentioned? That does not seem like a good thing for distros.
I unfortunately cannot answer the question myself without spending significant effort patching v2022.01 to get it to work on our Puma module. Does anyone have access to a board to quickly check an extlinux.conf with KERNEL and FDT set to /fitImage on a v2022.01 release?
Is there really no other way than adding this new requirement? (Nothing against it if it does not break older releases with the "new" extlinux.conf though).
Cheers, Quentin
Hi,
On 21/11/2022 13:23, Quentin Schulz wrote:
Hi Patrick,
Thanks for looking at it.
On 10/28/22 11:01, Patrick Delaunay wrote:
Since the commit d5ba6188dfbf ("cmd: pxe_utils: Check fdtcontroladdr in label_boot") the FDT or the FDTDIR label is required in extlinux.conf and the fallback done by bootm command when only the device tree is present in this command parameters is no more performed when FIT is used for kernel.
The next file "extlinux.conf" no more selects the device tree in FIT but use the pxe fallback with the device tree of U-Boot.
menu title Select the boot mode DEFAULT test LABEL test KERNEL /fitImage
This serie restores the possibility to use a FIT in extlinux.conf by using FDT label with the same string.
menu title Select the boot mode DEFAULT test LABEL test KERNEL /fitImage FDT /fitImage
even when a specific FIT config is used:
menu title Select the boot mode DEFAULT test LABEL test KERNEL /fitImage#config FDT /fitImage#config
The last commit of the series is only a minor improvement.
I tested this on my Puma RK3399 and it does work again, thanks.
However, I'm not sure this is what we should go for?
My worry is the following: What happens for old releases (pre-v2022.04) where KERNEL worked just fine without the FDT to load the fdt from the fitimage conf specified in KERNEL field? Would we now need to keep an extlinux.conf for pre-2022.04 releases where FDT wouldn't be set and one for 2023.01 and later where FDT would be mentioned? That does not seem like a good thing for distros.
I unfortunately cannot answer the question myself without spending significant effort patching v2022.01 to get it to work on our Puma module. Does anyone have access to a board to quickly check an extlinux.conf with KERNEL and FDT set to /fitImage on a v2022.01 release?
I'm building kirkstone images with meta-meson having v2022.01, I'll test with FDT set to /fitImage to see if it breaks.
Neil
Is there really no other way than adding this new requirement? (Nothing against it if it does not break older releases with the "new" extlinux.conf though).
Cheers, Quentin
On 22/11/2022 20:11, Neil Armstrong wrote:
Hi,
On 21/11/2022 13:23, Quentin Schulz wrote:
Hi Patrick,
Thanks for looking at it.
On 10/28/22 11:01, Patrick Delaunay wrote:
Since the commit d5ba6188dfbf ("cmd: pxe_utils: Check fdtcontroladdr in label_boot") the FDT or the FDTDIR label is required in extlinux.conf and the fallback done by bootm command when only the device tree is present in this command parameters is no more performed when FIT is used for kernel.
The next file "extlinux.conf" no more selects the device tree in FIT but use the pxe fallback with the device tree of U-Boot.
menu title Select the boot mode DEFAULT test LABEL test KERNEL /fitImage
This serie restores the possibility to use a FIT in extlinux.conf by using FDT label with the same string.
menu title Select the boot mode DEFAULT test LABEL test KERNEL /fitImage FDT /fitImage
even when a specific FIT config is used:
menu title Select the boot mode DEFAULT test LABEL test KERNEL /fitImage#config FDT /fitImage#config
The last commit of the series is only a minor improvement.
I tested this on my Puma RK3399 and it does work again, thanks.
However, I'm not sure this is what we should go for?
My worry is the following: What happens for old releases (pre-v2022.04) where KERNEL worked just fine without the FDT to load the fdt from the fitimage conf specified in KERNEL field? Would we now need to keep an extlinux.conf for pre-2022.04 releases where FDT wouldn't be set and one for 2023.01 and later where FDT would be mentioned? That does not seem like a good thing for distros.
I unfortunately cannot answer the question myself without spending significant effort patching v2022.01 to get it to work on our Puma module. Does anyone have access to a board to quickly check an extlinux.conf with KERNEL and FDT set to /fitImage on a v2022.01 release?
I'm building kirkstone images with meta-meson having v2022.01, I'll test with FDT set to /fitImage to see if it breaks.
It breaks: Found /extlinux/extlinux.conf Retrieving file: /extlinux/extlinux.conf 1: Yocto Retrieving file: /fitImage append: root=PARTUUID=3ebc0005-02 rootwait console=ttyAML0,115200 Retrieving file: /fitImage Bad Linux ARM64 Image magic! SCRIPT FAILED: continuing...
Neil
Is there really no other way than adding this new requirement? (Nothing against it if it does not break older releases with the "new" extlinux.conf though).
Cheers, Quentin
Hi,
On 11/22/22 20:43, Neil Armstrong wrote:
On 22/11/2022 20:11, Neil Armstrong wrote:
Hi,
On 21/11/2022 13:23, Quentin Schulz wrote:
Hi Patrick,
Thanks for looking at it.
On 10/28/22 11:01, Patrick Delaunay wrote:
Since the commit d5ba6188dfbf ("cmd: pxe_utils: Check fdtcontroladdr in label_boot") the FDT or the FDTDIR label is required in extlinux.conf and the fallback done by bootm command when only the device tree is present in this command parameters is no more performed when FIT is used for kernel.
The next file "extlinux.conf" no more selects the device tree in FIT but use the pxe fallback with the device tree of U-Boot.
menu title Select the boot mode DEFAULT test LABEL test KERNEL /fitImage
This serie restores the possibility to use a FIT in extlinux.conf by using FDT label with the same string.
menu title Select the boot mode DEFAULT test LABEL test KERNEL /fitImage FDT /fitImage
even when a specific FIT config is used:
menu title Select the boot mode DEFAULT test LABEL test KERNEL /fitImage#config FDT /fitImage#config
The last commit of the series is only a minor improvement.
I tested this on my Puma RK3399 and it does work again, thanks.
However, I'm not sure this is what we should go for?
My worry is the following: What happens for old releases (pre-v2022.04) where KERNEL worked just fine without the FDT to load the fdt from the fitimage conf specified in KERNEL field? Would we now need to keep an extlinux.conf for pre-2022.04 releases where FDT wouldn't be set and one for 2023.01 and later where FDT would be mentioned? That does not seem like a good thing for distros.
I unfortunately cannot answer the question myself without spending significant effort patching v2022.01 to get it to work on our Puma module. Does anyone have access to a board to quickly check an extlinux.conf with KERNEL and FDT set to /fitImage on a v2022.01 release?
I'm building kirkstone images with meta-meson having v2022.01, I'll test with FDT set to /fitImage to see if it breaks.
It breaks: Found /extlinux/extlinux.conf Retrieving file: /extlinux/extlinux.conf 1: Yocto Retrieving file: /fitImage append: root=PARTUUID=3ebc0005-02 rootwait console=ttyAML0,115200 Retrieving file: /fitImage Bad Linux ARM64 Image magic! SCRIPT FAILED: continuing...
Can you share the extlinux file used for your test ?do you have my patch ?
because I test the config on my board (STM32MP15x / armv7) the 2 cases :
DEFAULT test LABEL test KERNEL /fitImage FDT /fitImage
And
DEFAULT test LABEL test KERNEL /fitImage#config FDT /fitImage#config
and normally the file is retrieved one time => "/fitImage"
and in the trace it is retrieving 2 times = "Retrieving file: /fitImage" and it is stange
I know I have limitation for mixed config:
DEFAULT test LABEL test KERNEL /fitImage FDT /fitImag#config
Do you have this type of extlinux.conf ?
Neil
Is there really no other way than adding this new requirement? (Nothing against it if it does not break older releases with the "new" extlinux.conf though).
The commit d5ba6188dfbf ("cmd: pxe_utils: Check fdtcontroladdr in label_boot") aready break the extlinux.conf support.....
=> FTD or FDTDIR is now mandatory so potentially, some working extlinux.conf is ot more working
since v2022.01-rc2
For example:
menu title Select the boot mode DEFAULT test LABEL test KERNEL /fitImage
But this issue is not linked to this serie,
I just try to correct the regression
- keep the new behavior (usefull when FIT is not used)
- add a way to have a functional extlinux.conf for FIT
(even if extlinux.conf files need to be modified and it is difficult for 'distros')
Cheers, Quentin
I don't found a other solution / better solution for v202.01 => v2023.01...
Regards
Patrick
On 13/12/2022 15:31, Patrick DELAUNAY wrote:
Hi,
On 11/22/22 20:43, Neil Armstrong wrote:
On 22/11/2022 20:11, Neil Armstrong wrote:
Hi,
On 21/11/2022 13:23, Quentin Schulz wrote:
Hi Patrick,
Thanks for looking at it.
On 10/28/22 11:01, Patrick Delaunay wrote:
Since the commit d5ba6188dfbf ("cmd: pxe_utils: Check fdtcontroladdr in label_boot") the FDT or the FDTDIR label is required in extlinux.conf and the fallback done by bootm command when only the device tree is present in this command parameters is no more performed when FIT is used for kernel.
The next file "extlinux.conf" no more selects the device tree in FIT but use the pxe fallback with the device tree of U-Boot.
menu title Select the boot mode DEFAULT test LABEL test KERNEL /fitImage
This serie restores the possibility to use a FIT in extlinux.conf by using FDT label with the same string.
menu title Select the boot mode DEFAULT test LABEL test KERNEL /fitImage FDT /fitImage
even when a specific FIT config is used:
menu title Select the boot mode DEFAULT test LABEL test KERNEL /fitImage#config FDT /fitImage#config
The last commit of the series is only a minor improvement.
I tested this on my Puma RK3399 and it does work again, thanks.
However, I'm not sure this is what we should go for?
My worry is the following: What happens for old releases (pre-v2022.04) where KERNEL worked just fine without the FDT to load the fdt from the fitimage conf specified in KERNEL field? Would we now need to keep an extlinux.conf for pre-2022.04 releases where FDT wouldn't be set and one for 2023.01 and later where FDT would be mentioned? That does not seem like a good thing for distros.
I unfortunately cannot answer the question myself without spending significant effort patching v2022.01 to get it to work on our Puma module. Does anyone have access to a board to quickly check an extlinux.conf with KERNEL and FDT set to /fitImage on a v2022.01 release?
I'm building kirkstone images with meta-meson having v2022.01, I'll test with FDT set to /fitImage to see if it breaks.
It breaks: Found /extlinux/extlinux.conf Retrieving file: /extlinux/extlinux.conf 1: Yocto Retrieving file: /fitImage append: root=PARTUUID=3ebc0005-02 rootwait console=ttyAML0,115200 Retrieving file: /fitImage Bad Linux ARM64 Image magic! SCRIPT FAILED: continuing...
Can you share the extlinux file used for your test ?do you have my patch ?
It was explicitly without your patch as Quentin asked, he hoped addingh "FDT /fitImage" would not break u-boot pre d5ba6188dfbf, but no.
because I test the config on my board (STM32MP15x / armv7) the 2 cases :
DEFAULT test LABEL test KERNEL /fitImage FDT /fitImage
And
DEFAULT test LABEL test KERNEL /fitImage#config FDT /fitImage#config
and normally the file is retrieved one time => "/fitImage"
and in the trace it is retrieving 2 times = "Retrieving file: /fitImage" and it is stange
I know I have limitation for mixed config:
DEFAULT test LABEL test KERNEL /fitImage FDT /fitImag#config
Do you have this type of extlinux.conf ?
Neil
Is there really no other way than adding this new requirement? (Nothing against it if it does not break older releases with the "new" extlinux.conf though).
The commit d5ba6188dfbf ("cmd: pxe_utils: Check fdtcontroladdr in label_boot") aready break the extlinux.conf support.....
=> FTD or FDTDIR is now mandatory so potentially, some working extlinux.conf is ot more working
since v2022.01-rc2
For example:
menu title Select the boot mode DEFAULT test LABEL test KERNEL /fitImage
But this issue is not linked to this serie,
I just try to correct the regression
keep the new behavior (usefull when FIT is not used)
add a way to have a functional extlinux.conf for FIT
(even if extlinux.conf files need to be modified and it is difficult for 'distros')
Cheers, Quentin
I don't found a other solution / better solution for v202.01 => v2023.01...
Regards
Patrick
Hi Patrick,
On 12/13/22 15:34, neil.armstrong@linaro.org wrote:
On 13/12/2022 15:31, Patrick DELAUNAY wrote:
Hi,
On 11/22/22 20:43, Neil Armstrong wrote:
On 22/11/2022 20:11, Neil Armstrong wrote:
Hi,
On 21/11/2022 13:23, Quentin Schulz wrote:
Hi Patrick,
Thanks for looking at it.
On 10/28/22 11:01, Patrick Delaunay wrote:
Since the commit d5ba6188dfbf ("cmd: pxe_utils: Check fdtcontroladdr in label_boot") the FDT or the FDTDIR label is required in extlinux.conf and the fallback done by bootm command when only the device tree is present in this command parameters is no more performed when FIT is used for kernel.
The next file "extlinux.conf" no more selects the device tree in FIT but use the pxe fallback with the device tree of U-Boot.
menu title Select the boot mode DEFAULT test LABEL test KERNEL /fitImage
This serie restores the possibility to use a FIT in extlinux.conf by using FDT label with the same string.
menu title Select the boot mode DEFAULT test LABEL test KERNEL /fitImage FDT /fitImage
even when a specific FIT config is used:
menu title Select the boot mode DEFAULT test LABEL test KERNEL /fitImage#config FDT /fitImage#config
The last commit of the series is only a minor improvement.
I tested this on my Puma RK3399 and it does work again, thanks.
However, I'm not sure this is what we should go for?
My worry is the following: What happens for old releases (pre-v2022.04) where KERNEL worked just fine without the FDT to load the fdt from the fitimage conf specified in KERNEL field? Would we now need to keep an extlinux.conf for pre-2022.04 releases where FDT wouldn't be set and one for 2023.01 and later where FDT would be mentioned? That does not seem like a good thing for distros.
I unfortunately cannot answer the question myself without spending significant effort patching v2022.01 to get it to work on our Puma module. Does anyone have access to a board to quickly check an extlinux.conf with KERNEL and FDT set to /fitImage on a v2022.01 release?
I'm building kirkstone images with meta-meson having v2022.01, I'll test with FDT set to /fitImage to see if it breaks.
It breaks: Found /extlinux/extlinux.conf Retrieving file: /extlinux/extlinux.conf 1: Yocto Retrieving file: /fitImage append: root=PARTUUID=3ebc0005-02 rootwait console=ttyAML0,115200 Retrieving file: /fitImage Bad Linux ARM64 Image magic! SCRIPT FAILED: continuing...
Can you share the extlinux file used for your test ?do you have my patch ?
It was explicitly without your patch as Quentin asked, he hoped addingh "FDT /fitImage" would not break u-boot pre d5ba6188dfbf, but no.
Your implementation requires changes in extlinux.conf (which could be fine, I'm not arguing about this specifically). I however think we need those required changes to be backward compatible with older U-Boot.
This means, a new extlinux.conf that works on newer U-Boot should also work on older U-Boot without your patch.
Otherwise, we would have the following:
U-Boot \ extlinux.conf || old | new ==================================== old || OK | NOK new || NOK | OK
What I am hoping for is: U-Boot \ extlinux.conf || old | new ==================================== old || OK | OK new || NOK | OK
or even fix the support for new U-Boot with old extlinux.conf (but that seems not possible because how d5ba6188dfbf ("cmd: pxe_utils: Check fdtcontroladdr in label_boot") works?).
This would give an easy migration path to any creator of this extlinux.conf file by just migrating to the new format while not requiring it to care about the version of U-Boot being used.
Cheers, Quentin
On 12/13/22 15:48, Quentin Schulz wrote:
Hi Patrick,
On 12/13/22 15:34, neil.armstrong@linaro.org wrote:
On 13/12/2022 15:31, Patrick DELAUNAY wrote:
Hi,
On 11/22/22 20:43, Neil Armstrong wrote:
On 22/11/2022 20:11, Neil Armstrong wrote:
Hi,
On 21/11/2022 13:23, Quentin Schulz wrote:
Hi Patrick,
Thanks for looking at it.
On 10/28/22 11:01, Patrick Delaunay wrote: > > Since the commit d5ba6188dfbf ("cmd: pxe_utils: Check > fdtcontroladdr > in label_boot") the FDT or the FDTDIR label is required in > extlinux.conf > and the fallback done by bootm command when only the device tree > is present > in this command parameters is no more performed when FIT is used > for > kernel. > > The next file "extlinux.conf" no more selects the device tree in > FIT > but use the pxe fallback with the device tree of U-Boot. > > menu title Select the boot mode > DEFAULT test > LABEL test > KERNEL /fitImage > > This serie restores the possibility to use a FIT in extlinux.conf > by using FDT label with the same string. > > menu title Select the boot mode > DEFAULT test > LABEL test > KERNEL /fitImage > FDT /fitImage > > even when a specific FIT config is used: > > menu title Select the boot mode > DEFAULT test > LABEL test > KERNEL /fitImage#config > FDT /fitImage#config > > The last commit of the series is only a minor improvement. >
I tested this on my Puma RK3399 and it does work again, thanks.
However, I'm not sure this is what we should go for?
My worry is the following: What happens for old releases (pre-v2022.04) where KERNEL worked just fine without the FDT to load the fdt from the fitimage conf specified in KERNEL field? Would we now need to keep an extlinux.conf for pre-2022.04 releases where FDT wouldn't be set and one for 2023.01 and later where FDT would be mentioned? That does not seem like a good thing for distros.
I unfortunately cannot answer the question myself without spending significant effort patching v2022.01 to get it to work on our Puma module. Does anyone have access to a board to quickly check an extlinux.conf with KERNEL and FDT set to /fitImage on a v2022.01 release?
I'm building kirkstone images with meta-meson having v2022.01, I'll test with FDT set to /fitImage to see if it breaks.
It breaks: Found /extlinux/extlinux.conf Retrieving file: /extlinux/extlinux.conf 1: Yocto Retrieving file: /fitImage append: root=PARTUUID=3ebc0005-02 rootwait console=ttyAML0,115200 Retrieving file: /fitImage Bad Linux ARM64 Image magic! SCRIPT FAILED: continuing...
Can you share the extlinux file used for your test ?do you have my patch ?
It was explicitly without your patch as Quentin asked, he hoped addingh "FDT /fitImage" would not break u-boot pre d5ba6188dfbf, but no.
Your implementation requires changes in extlinux.conf (which could be fine, I'm not arguing about this specifically). I however think we need those required changes to be backward compatible with older U-Boot.
This means, a new extlinux.conf that works on newer U-Boot should also work on older U-Boot without your patch.
Otherwise, we would have the following:
U-Boot \ extlinux.conf || old | new
old || OK | NOK new || NOK | OK
What I am hoping for is: U-Boot \ extlinux.conf || old | new ==================================== old || OK | OK new || NOK | OK
or even fix the support for new U-Boot with old extlinux.conf (but that seems not possible because how d5ba6188dfbf ("cmd: pxe_utils: Check fdtcontroladdr in label_boot") works?).
Yes but I don't see any possible solution to solve all the combination with d5ba6188dfbf and without or without FIT:
the old extlinux.conf with FIT are already no more working as expected with current U-Boot (1)
when FDT and FDTDIR are absent
extlinux.conf || kernel = uImage | kernel= FIT | kernel = FIT
|| FDT absent | FDT absent | FDT = FIT (my proposal)
============================================================================================
U-Boot <= v2022.01-rc2 || KO | OK using DT in FIT | not supported
U-Boot >= 2022.01-rc3 || OK (1) | OK(2)using U-Boot DT | not supported
next with my proposal || OK (1) | OK(2)using U-Boot DT | OK (using DT in FIT)
(1) with d5ba6188dfbf
(2) Risk to have unaligned DT between U-Boot (old) and kernel (new)
=> U-Boot behavior change with 2022.01-rc3(1)
This would give an easy migration path to any creator of this extlinux.conf file by just migrating to the new format while not requiring it to care about the version of U-Boot being used.
I agree, it is better to be backward compatible.
So I search a solution to keep the new feature introduced by d5ba6188dfbf ("cmd: pxe_utils: Check fdtcontroladdr in label_boot") but only when FIT is not used and fallback to previous behavior for FIT....
but it is too complicated: pxe utils need to load the "kernel_addr" and verify if it is a FIT before to check if "fdtcontroladdr" is provided, but I can test an solution if you have a proposal.
Moreover I assumed the FIT feature is not largely used in generated extlinux.conf file as the regression introduced by 2022.01-rc2wasn't detected until now.
Cheers, Quentin
regards
Patrick
Hi Patrick,
On 1/3/23 17:10, Patrick DELAUNAY wrote:
On 12/13/22 15:48, Quentin Schulz wrote:
Hi Patrick,
On 12/13/22 15:34, neil.armstrong@linaro.org wrote:
On 13/12/2022 15:31, Patrick DELAUNAY wrote:
Hi,
On 11/22/22 20:43, Neil Armstrong wrote:
On 22/11/2022 20:11, Neil Armstrong wrote:
Hi,
On 21/11/2022 13:23, Quentin Schulz wrote: > Hi Patrick, > > Thanks for looking at it. > > On 10/28/22 11:01, Patrick Delaunay wrote: >> >> Since the commit d5ba6188dfbf ("cmd: pxe_utils: Check >> fdtcontroladdr >> in label_boot") the FDT or the FDTDIR label is required in >> extlinux.conf >> and the fallback done by bootm command when only the device tree >> is present >> in this command parameters is no more performed when FIT is used >> for >> kernel. >> >> The next file "extlinux.conf" no more selects the device tree in >> FIT >> but use the pxe fallback with the device tree of U-Boot. >> >> menu title Select the boot mode >> DEFAULT test >> LABEL test >> KERNEL /fitImage >> >> This serie restores the possibility to use a FIT in extlinux.conf >> by using FDT label with the same string. >> >> menu title Select the boot mode >> DEFAULT test >> LABEL test >> KERNEL /fitImage >> FDT /fitImage >> >> even when a specific FIT config is used: >> >> menu title Select the boot mode >> DEFAULT test >> LABEL test >> KERNEL /fitImage#config >> FDT /fitImage#config >> >> The last commit of the series is only a minor improvement. >> > > I tested this on my Puma RK3399 and it does work again, thanks. > > However, I'm not sure this is what we should go for? > > My worry is the following: > What happens for old releases (pre-v2022.04) where KERNEL worked > just fine without the FDT to load the fdt from the fitimage conf > specified in KERNEL field? Would we now need to keep an > extlinux.conf for pre-2022.04 releases where FDT wouldn't be set > and one for 2023.01 and later where FDT would be mentioned? That > does not seem like a good thing for distros. > > I unfortunately cannot answer the question myself without > spending significant effort patching v2022.01 to get it to work > on our Puma module. Does anyone have access to a board to quickly > check an extlinux.conf with KERNEL and FDT set to /fitImage on a > v2022.01 release?
I'm building kirkstone images with meta-meson having v2022.01, I'll test with FDT set to /fitImage to see if it breaks.
It breaks: Found /extlinux/extlinux.conf Retrieving file: /extlinux/extlinux.conf 1: Yocto Retrieving file: /fitImage append: root=PARTUUID=3ebc0005-02 rootwait console=ttyAML0,115200 Retrieving file: /fitImage Bad Linux ARM64 Image magic! SCRIPT FAILED: continuing...
Can you share the extlinux file used for your test ?do you have my patch ?
It was explicitly without your patch as Quentin asked, he hoped addingh "FDT /fitImage" would not break u-boot pre d5ba6188dfbf, but no.
Your implementation requires changes in extlinux.conf (which could be fine, I'm not arguing about this specifically). I however think we need those required changes to be backward compatible with older U-Boot.
This means, a new extlinux.conf that works on newer U-Boot should also work on older U-Boot without your patch.
Otherwise, we would have the following:
U-Boot \ extlinux.conf || old | new
old || OK | NOK new || NOK | OK
What I am hoping for is: U-Boot \ extlinux.conf || old | new ==================================== old || OK | OK new || NOK | OK
or even fix the support for new U-Boot with old extlinux.conf (but that seems not possible because how d5ba6188dfbf ("cmd: pxe_utils: Check fdtcontroladdr in label_boot") works?).
Yes but I don't see any possible solution to solve all the combination with d5ba6188dfbf and without or without FIT:
the old extlinux.conf with FIT are already no more working as expected with current U-Boot (1)
when FDT and FDTDIR are absent
extlinux.conf || kernel = uImage | kernel= FIT | kernel = FIT
|| FDT absent | FDT absent | FDT = FIT (my proposal)
============================================================================================
U-Boot <= v2022.01-rc2 || KO | OK using DT in FIT | not supported
U-Boot >= 2022.01-rc3 || OK (1) | OK(2)using U-Boot DT | not supported
next with my proposal || OK (1) | OK(2)using U-Boot DT | OK (using DT in FIT)
(1) with d5ba6188dfbf
(2) Risk to have unaligned DT between U-Boot (old) and kernel (new)
=> U-Boot behavior change with 2022.01-rc3(1)
This would give an easy migration path to any creator of this extlinux.conf file by just migrating to the new format while not requiring it to care about the version of U-Boot being used.
I agree, it is better to be backward compatible.
So I search a solution to keep the new feature introduced by d5ba6188dfbf ("cmd: pxe_utils: Check fdtcontroladdr in label_boot") but only when FIT is not used and fallback to previous behavior for FIT....
but it is too complicated: pxe utils need to load the "kernel_addr" and verify if it is a FIT before to check if "fdtcontroladdr" is provided, but I can test an solution if you have a proposal.
Moreover I assumed the FIT feature is not largely used in generated extlinux.conf file as the regression introduced by 2022.01-rc2wasn't detected until now.
It's the default in Yocto when you're building fit images :) U-Boot 2022.01 is only in Yocto since Kirkstone and it's only the default version, which is rarely used. Vendors also have a tendency to stay way behind and not upgrade U-Boot (we've done this, trying to fix it right now, you probably saw the number of patches I sent to fix our poor Puma module in the last year :) ).
Anyways, I think we've something we can work with now: https://lore.kernel.org/u-boot/20221214064518.753432-1-marex@denx.de/
We need to take this one and then apply https://lore.kernel.org/u-boot/20221217174113.7459-1-marex@denx.de/ again.
I'll ask Marek to make this a v3 all together and mark it urgent for next release so Tom knows he should merge it ASAP. Don't hesitate to provide feedback on those patches because I expect those to be merged quite fast.
Cheers, Quentin
participants (6)
-
Neil Armstrong -
neil.armstrong＠linaro.org
-
Patrick DELAUNAY -
Patrick Delaunay
-
Quentin Schulz -
Tom Rini