[U-Boot] [PATCH] hikey: Allow environment to store in eMMC and increase bootdelay

[Tom Rini]

On Wed, Feb 13, 2019 at 01:02:48PM +0000, Neil Williams wrote:
> On Wed, 13 Feb 2019 at 12:47, Tom Rini <trini at 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 at 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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190213/f9d2e89d/attachment.sig>