On Wed, Feb 13, 2019 at 01:02:48PM +0000, Neil Williams wrote: > On Wed, 13 Feb 2019 at 12:47, Tom Rini <tr...@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 <tr...@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.sadhasi...@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.
Very interesting, thanks for the details! -- Tom
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
