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

[Neil Williams]

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.

-- 

Neil Williams
=============
neil.williams at linaro.org
http://www.linux.codehelp.co.uk/