[U-Boot] [PATCH] hikey: Allow environment to store in eMMC and increase bootdelay
trini at konsulko.com
Wed Feb 13 13:09:24 UTC 2019
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
Very interesting, thanks for the details!
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: not available
More information about the U-Boot