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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
