[flasher PATCH] Set a boot delay of 0 instead of -2

[flasher PATCH] Set a boot delay of 0 instead of -2

[James Thomas]

Using fdtput on 32-bit systems results in a delay of 2147483647, setting this
to 0 achieves the same goal

James Thomas (1):
  Set bootdelay to 0

 tegra-uboot-flasher | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

-- 
1.9.3

[flasher PATCH] Set bootdelay to 0

[James Thomas]

On 32-bit systems fdtput writes 0xfffffffe as 0x7fffffff, which takes
some time to complete.

Setting this to 0 accomplishes the same goal
---
 tegra-uboot-flasher | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tegra-uboot-flasher b/tegra-uboot-flasher
index b71f967..0121e7a 100755
--- a/tegra-uboot-flasher
+++ b/tegra-uboot-flasher
@@ -194,8 +194,8 @@ def func_flash():
         u_boot_dtb_runflash = os.path.join(workdir, 'u-boot-runflash.dtb')
         cp(u_boot_dtb, u_boot_dtb_runflash)
 
-        # 0xfffffffe==-2; never delay or interrupt
-        cmd = ['fdtput', '-p', '-t', 'i', u_boot_dtb_runflash, '/config', 'bootdelay', '0xfffffffe']
+        # Set a boot delay of 0 seconds
+        cmd = ['fdtput', '-p', '-t', 'i', u_boot_dtb_runflash, '/config', 'bootdelay', '0x0']
         run(workdir, cmd)
 
         bootcmd = ''
-- 
1.9.3

Re: [flasher PATCH] Set bootdelay to 0

[Stephen Warren]

On 11/26/2014 10:57 AM, James Thomas wrote:
> On 32-bit systems fdtput writes 0xfffffffe as 0x7fffffff, which takes
> some time to complete.
>
> Setting this to 0 accomplishes the same goal

A value of 0 doesn't mean the same thing. 0 means that bootdelay is 
enabled, just with an immediate timeout, whereas -2 means that bootdelay 
is disabled completely, so that boot can't be interrupted. The 
difference is that when bootdelay is 0, the user can still press a key 
before the boot delay check, and break into the boot process. This would 
make the flasher less reliable.

Can you explain why the correct value doesn't get into the DTB? It seems 
better to fix that bug in fdtput instead. Or perhaps there's a bug in 
the command-line arguments to fdtput that should be fixed?

BTW, you don't need to send a cover letter when you're only sending one 
patch. In fact, even with a multi-patch series, you can often get away 
without a cover letter assuming all the patch descriptions are complete, 
which they should be anwyay:-)

Re: [flasher PATCH] Set bootdelay to 0

[James Thomas]

On 01/12/14 18:05, Stephen Warren wrote:
> On 11/26/2014 10:57 AM, James Thomas wrote:
>> On 32-bit systems fdtput writes 0xfffffffe as 0x7fffffff, which takes
>> some time to complete.
>>
>> Setting this to 0 accomplishes the same goal
> 
> A value of 0 doesn't mean the same thing. 0 means that bootdelay is enabled,
> just with an immediate timeout, whereas -2 means that bootdelay is disabled
> completely, so that boot can't be interrupted. The difference is that when
> bootdelay is 0, the user can still press a key before the boot delay check, and
> break into the boot process. This would make the flasher less reliable.

Ah, right, that makes sense, thanks for the feedback
> 
> Can you explain why the correct value doesn't get into the DTB? It seems better
> to fix that bug in fdtput instead. Or perhaps there's a bug in the command-line
> arguments to fdtput that should be fixed?

Command-line argument should have been the first thing I checked, I think we
need to use -t x (hex) here instead of int. Now works correctly on 32-bit and
64-bit (i'll resubmit)

Thanks
James