Rpi3: Use of USB keyboard to stop u-boot countdown about build

[jbech-linaro]

And I read this as you have the keyboard connected to the PI itself? I.e, no UART involved here?

[msa2]

Yes, plain standard USB Keyboard connected to RPI3 USB port.

[igoropaniuk]

Hi @msa2,
I've never faced the issue you described when I used my RPi3+USB keyboard setup ("usb start" in CONFIG_PREBOOT works for me out of the box)

When using default u-boot configuration (without manually specifying preboot var in uboot.env.txt), have you seen scanning bus for devices... USB enumeration line in u-boot log before Press any key to stop message?

[msa2]

Ok, maybe I pulled some intermediate version at some point. I'm not constantly updating to the latest, because I need some stability for my own tests.

What is the role of ./build/rpi3/firmware/uboot.env.txt (my version does on mention preboot) -- how is CONFIG_PREBOOT merged with uboot.env.txt?

If this problem does not appear for others, it must be something in my specific version and setup (and as I said, I found a "work around").

[igoropaniuk]

@msa2,

I was wrong. I just checked my RPi3 setup once more - I have the same issue with a keyboard, seems that I was confused and all memories mixed up after I've been playing with Hikey and TI board setups for the last two days :) .

It seems, that uboot.env just replaces the whole U-boot default env, even variables, that are not defined in this uboot.env.

If you try to use env default preboot, it will create a new variable preboot with a value, which is defined by CONFIG_PREBOOT

U-Boot> printenv
# No preboot here
U-Boot> env default preboot
U-Boot> printenv
...
preboot=usb start
...

Pretty interesting, before this case I thought that default and custom environments are merged :)

[igoropaniuk]

@msa2 so the only way to fix it - is to do what you did, just add needed vars to uboot.env.txt and generate new uboot.env

[msa2]

I think there is u-boot modification/addition, which reads the environment variables from a text file, if one with specific name uEnv.txt exists (actually haven't checked whether it is already supported)

Adding this feature might be better approach than generating uboot.env at build time.

[igoropaniuk]

@msa2
right, you can use a chain of fatload/import commands. I think I'll prepare PR to switch to this approach in near future

You can just add this lines to CONFIG_EXTRA_ENV_SETTINGS/CONFIG_BOOTCOMMAND defines in rpi.h configuration file and it should work (I haven't tested it), just an example from another platform:

#define CONFIG_EXTRA_ENV_SETTINGS \
	"loadaddr=0x80200000\0" \
	"bootenv=uEnv.txt\0" \
	"mmcdev=0\0" \
	"loadbootenv=fatload mmc ${mmcdev} ${loadaddr} ${bootenv}\0" \
	"importbootenv=env import -t $loadaddr $filesize\0" \
	

#define CONFIG_BOOTCOMMAND \
	"mmc dev ${mmcdev}; if mmc rescan; then " \
		"if run loadbootenv; then " \
			"run importbootenv;" \
		"fi;" \
	"fi;" \

In this case env definitions in uEnv.txt will be just added to your default configuration.

[jbech-linaro]

I'm adding this as a "known issue" in the changelog, when we're about to make the 2.4.0 release (today). I've just tested RPi3 running latest (according to the manifest ... non-stable) and it seems to work fine otherwise. I've been using the UART (and I've tested using NFS).

[igoropaniuk]

@msa2

May we close this issue, as fix has been already provided (48ade15)?

[msa2]

yes