Skip to contentSkip to conversation

fdt: allow bootdelay to be specified via device tree

PATCH In review Stephen Warren 5 participants 7 messages May 14, 2013 – Jun 5, 2013

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 fdt: allow bootdelay to be specified via device tree

From: Stephen Warren <[email protected]>

This can be useful to force bootcmd to execute as soon as U-Boot has started.

My use-case is: An SoC-specific tool pushes U-Boot into RAM, along with an image to be written to device boot flash, with the DT config property "bootcmd" set to contain a command to write that image to flash. In this scenario, we don't want to allow any stale bootdelay value taken from the current flash content to affect how long it takes before the flashing process starts.

---
 common/main.c |    5 +++++
 1 file changed, 5 insertions(+)
common/main.c +5 -0
index 953ef29..6bfd9f0 100644
@@ -429,6 +429,11 @@ void main_loop (void)
 	s = getenv ("bootdelay");
 	bootdelay = s ? (int)simple_strtol(s, NULL, 10) : CONFIG_BOOTDELAY;
 
+#ifdef CONFIG_OF_CONTROL
+	bootdelay = fdtdec_get_config_int(gd->fdt_blob, "bootdelay",
+			bootdelay);
+#endif
+
 	debug ("### main_loop entered: bootdelay=%d\n\n", bootdelay);
 
 #if defined(CONFIG_MENU_SHOW)
Signature · 1 line
1.7.10.4
#1 lore raw

PATCH 1/1 fdt: allow bootdelay to be specified via device tree

Hi Stephen,

Quoted 5 lines · Stephen Warren

From: Stephen Warren <[email protected]>

This can be useful to force bootcmd to execute as soon as U-Boot has started.

Quoted 8 lines

My use-case is: An SoC-specific tool pushes U-Boot into RAM, along with an image to be written to device boot flash, with the DT config property "bootcmd" set to contain a command to write that image to flash. In this scenario, we don't want to allow any stale bootdelay value taken from the current flash content to affect how long it takes before the flashing process starts.

Nice idea.

Regards,
Simon

#2 lore raw

PATCH 1/1 fdt: allow bootdelay to be specified via device tree

In reply to Stephen Warren
Quoted 11 lines · Stephen Warren

From: Stephen Warren <[email protected]>

This can be useful to force bootcmd to execute as soon as U-Boot has started.

My use-case is: An SoC-specific tool pushes U-Boot into RAM, along with an image to be written to device boot flash, with the DT config property "bootcmd" set to contain a command to write that image to flash. In this scenario, we don't want to allow any stale bootdelay value taken from the current flash content to affect how long it takes before the flashing process starts.

Jerry, does this patch look OK, or do you have comments on it? Thanks.

#3 lore raw

PATCH 1/1 fdt: allow bootdelay to be specified via device tree

Hi Stephen,

Quoted 6 lines · Stephen Warren
Quoted 5 lines · Stephen Warren

From: Stephen Warren <[email protected]>

This can be useful to force bootcmd to execute as soon as U-Boot has started.

Quoted 8 lines
Quoted 6 lines

My use-case is: An SoC-specific tool pushes U-Boot into RAM, along with an image to be written to device boot flash, with the DT config property "bootcmd" set to contain a command to write that image to flash. In this scenario, we don't want to allow any stale bootdelay value taken from the current flash content to affect how long it takes before the flashing process starts.

Jerry, does this patch look OK, or do you have comments on it? Thanks.

I'm good with the patch.

Thanks,
gvb

#4 lore raw

PATCH 1/1 fdt: allow bootdelay to be specified via device tree

Quoted 16 lines · Gerald Van Baren

Hi Stephen,

Quoted 13 lines · Stephen Warren
Quoted 11 lines · Stephen Warren

From: Stephen Warren <[email protected]>

This can be useful to force bootcmd to execute as soon as U-Boot has started.

My use-case is: An SoC-specific tool pushes U-Boot into RAM, along with an image to be written to device boot flash, with the DT config property "bootcmd" set to contain a command to write that image to flash. In this scenario, we don't want to allow any stale bootdelay value taken from the current flash content to affect how long it takes before the flashing process starts.

Quoted 5 lines
Quoted 1 line

Jerry, does this patch look OK, or do you have comments on it? Thanks.

I'm good with the patch.

Oh, I'm not sure who you're expecting to apply this then; I assume since it was a DT-related feature it'd be applied to your DT tree. Are you expecting Tom Rini to apply it to the main U-Boot repo?

#5 lore raw

PATCH 1/1 fdt: allow bootdelay to be specified via device tree

Quoted 19 lines · Stephen Warren
Quoted 18 lines · Gerald Van Baren

Hi Stephen,

Quoted 14 lines · Stephen Warren
Quoted 11 lines · Stephen Warren

From: Stephen Warren <[email protected]>

This can be useful to force bootcmd to execute as soon as U-Boot has started.

My use-case is: An SoC-specific tool pushes U-Boot into RAM, along with an image to be written to device boot flash, with the DT config property "bootcmd" set to contain a command to write that image to flash. In this scenario, we don't want to allow any stale bootdelay value taken from the current flash content to affect how long it takes before the flashing process starts.

Jerry, does this patch look OK, or do you have comments on it? Thanks.

Quoted 7 lines
Quoted 3 lines

I'm good with the patch.

Oh, I'm not sure who you're expecting to apply this then; I assume since it was a DT-related feature it'd be applied to your DT tree. Are you expecting Tom Rini to apply it to the main U-Boot repo?

Ahh, one of those fuzzy gray areas... the patch is to main.c, I mostly focus on files in the libfdt subdirectory. I can apply it via the FDT repo.

Tom Rini, do you have any preference?

The merge window closed May 11 and the original patch was emailed on May 14... is it a candidate to go into the July 15 release? It is a simple patch arguably fixing a bug, but it did miss the window.

Thanks,
gvb

#6 lore raw
In reply to Stephen Warren
Quoted 12 lines · Stephen Warren

From: Stephen Warren <[email protected]>

This can be useful to force bootcmd to execute as soon as U-Boot has started.

My use-case is: An SoC-specific tool pushes U-Boot into RAM, along with an image to be written to device boot flash, with the DT config property "bootcmd" set to contain a command to write that image to flash. In this scenario, we don't want to allow any stale bootdelay value taken from the current flash content to affect how long it takes before the flashing process starts.

Quoted 3 lines

Applied to u-boot/master, thanks!

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130605/7077863d/attachment.pgp>