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

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 --- configs/hikey_defconfig | 5 ++--- include/configs/hikey.h | 4 +++- 2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/configs/hikey_defconfig b/configs/hikey_defconfig index e9a9857322b..659c0e3f8ae 100644 --- a/configs/hikey_defconfig +++ b/configs/hikey_defconfig @@ -15,9 +15,8 @@ CONFIG_CMD_MMC=y CONFIG_CMD_USB=y CONFIG_CMD_CACHE=y CONFIG_DEFAULT_DEVICE_TREE="hi6220-hikey" -CONFIG_ENV_IS_IN_FAT=y -CONFIG_ENV_FAT_INTERFACE="mmc" -CONFIG_ENV_FAT_DEVICE_AND_PART="1:1" +CONFIG_ENV_IS_IN_MMC=y +CONFIG_BOOTDELAY=10 CONFIG_DM_MMC=y CONFIG_MMC_DW=y CONFIG_MMC_DW_K3=y diff --git a/include/configs/hikey.h b/include/configs/hikey.h index 003cd75baf8..60c6bde16ea 100644 --- a/include/configs/hikey.h +++ b/include/configs/hikey.h @@ -81,8 +81,10 @@ "initrd_high=0xffffffffffffffff\0" \ BOOTENV
-/* Preserve environment on sd card */ +/* Preserve environment on eMMC */ #define CONFIG_ENV_SIZE 0x1000 +#define CONFIG_SYS_MMC_ENV_DEV 0 /* Use eMMC */ +#define CONFIG_SYS_MMC_ENV_PART 2 /* Use Boot1 partition */
/* Monitor Command Prompt */ #define CONFIG_SYS_CBSIZE 512 /* Console I/O Buffer Size */

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.

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.)
-- Tom

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?

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.

On Wed, Feb 13, 2019 at 01:02:48PM +0000, Neil Williams wrote:
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.
Very interesting, thanks for the details!

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
Applied to u-boot/master, thanks!
participants (3)
-
Manivannan Sadhasivam
-
Neil Williams
-
Tom Rini