On Wed, 13 Feb 2019 at 12:47, Tom Rini trini@konsulko.com wrote:
On Wed, Feb 13, 2019 at 12:31:49PM +0000, Neil Williams wrote:
On Wed, 13 Feb 2019 at 12:24, Tom Rini trini@konsulko.com wrote:
On Wed, Feb 13, 2019 at 02:28:54PM +0530, Manivannan Sadhasivam wrote:
Current Hikey configuration allows us to store u-boot environment on uSD card. But this will be useless if uSD card is not inserted, hence use the onboard eMMC memory for storing environment at Boot1 partition. While we are at it, let's increase the boot delay to 10s also.
Signed-off-by: Manivannan Sadhasivam manivannan.sadhasivam@linaro.org
It's your board, but do you _really_ want 10s? We moved a whole bunch of boards down from 10s a long time ago as 2-3s isn't hard to break in to for users nor QA testing
Yes. 10 seconds is required. 2 or 3 seconds is not enough to break in for automated QA testing. We are aiming for maximum reliability here. 2 or 3 seconds causes ~25% failure rate. 5 seconds causes ~10% failure rate. 10 seconds removes this element. (Estimates based on about a million LAVA test jobs across 50 different types of devices across multiple instances in multiple locations.)
Interesting. Do you know why it's so hard to catch the boot?
The device gets busy, the serial connection server gets busy, the USB subsystem gets clogged, the host machine CPU gets busy ... there are a whole host of reasons why latencies can vary across automation labs. Each lab is trying to get maximal value out of all hardware and run as many simultaneous automated test jobs as possible. It is several orders of magnitude away from the developer with a board on the desk model. These labs are running thousands of test jobs per day on a few dozen devices, so there will be maybe a dozen simultaneous prompts to interrupt per server. We need to reduce the failure rate at each critical point until we get to a limit that warrants spending lots of money on more racks, more servers and more hardware. Currently, we have this failure rate down to less than 0.1% by requiring bootdelay=10 for all U-Boot devices, amongst other requirements.
So, for all U-Boot devices, our recommendation is bootdelay=10. This isn't a problem for most devices, as long as the device can correctly support saveenv. For the majority of boards, we don't need a specific value in the U-Boot build, admins simply make a permanent change to each device during the racking process. However, we are starting to do more bootloader recovery and testing, where a new U-Boot build gets deployed and then tested. This is where the build itself needs the 10 second bootdelay.
In nearly all test jobs, the boot is interrupted within ~5 seconds, often 2 or 3. However, to interrupt 100% of test jobs we really need bootdelay=10.