diff mbox

[flasher] Set bootdelay to 0

Message ID 1417024626-6616-2-git-send-email-james.thomas@codethink.co.uk
State Rejected, archived
Headers show

Commit Message

James Thomas Nov. 26, 2014, 5:57 p.m. UTC 
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(-)

Comments

Stephen Warren Dec. 1, 2014, 6:05 p.m. UTC | #1 
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:-)
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
James Thomas Dec. 4, 2014, 11:50 a.m. UTC | #2 
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



--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

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 = ''