load environment variables from uEnv.txt at preboot

[jeremyherbert]

Hi,

When using a uEnv.txt file, the environment variables are loaded too late to influence some of the behaviour of u-boot. In my case, I wanted to be able to set "bootdelay" using uEnv.txt rather than recompiling u-boot. This pull request fixes that.

I've tested this on a Digilent Zybo, and it also does not cause problems if there is no uEnv.txt file present.

Questions, comments and suggestions are welcome.

Thanks,
Jeremy

[michalsimek]

Hi,
idea to use preboot to try to load variable from SD card is good but implementation is not the best.

When I apply this patch everybody will see message about loading file from SD which ends up in questions why it is failing.
Board: Xilinx Zynq
Net: Gem.e000b000
reading uEnv.txt
** Unable to read file uEnv.txt **
Hit any key to stop autoboot: 0
zynq-uboot>

Also message on systems without MMC looks weird
** Bad device mmc 0 **
Hit any key to stop autoboot: 0

Please check if there is better way how to do it but I can't apply this patch with the current implementation.

[jeremyherbert]

Hi Michal,

Sorry, didn't think about that. Will look for a fix.

[jeremyherbert]

Hi Michal,

I fixed up the error showing up, but this problem is not entirely my doing. If you boot without an uEnv.txt with the vanilla xilinx master version, you will still get uEnv.txt errors:

...
In:    serial
Out:   serial
Err:   serial
Board:.Xilinx Zynq
Net:   Gem.e000b000
Hit any key to stop autoboot:  0 
Device: zynq_sdhci
Manufacturer ID: 3
OEM: 5344
Name: SU08G 
Tran Speed: 50000000
Rd Block Len: 512
SD version 3.0
High Capacity: Yes
Capacity: 7.4 GiB
Bus Width: 4-bit
reading uEnv.txt
** Unable to read file uEnv.txt **
Copying Linux from SD to RAM...
reading uImage
3453832 bytes read in 304 ms (10.8 MiB/s)
...

This is fairly clear if you take a look at the surrounding code in zynq-common.h. As I now recall, this is why I did not fix the error, as I thought it was present in the other case on purpose, and I wanted to be consistent with the code that was already there.

I'd be happy to fix this error message too, but I think that should probably come under a different pull request as it is really a different problem. What do you think?

Thanks,
Jeremy

[michalsimek]

ok - this is better now. Can you please squash that two patches together and send it to git@xilinx.com
with proper description? Or of course add it here - but really I want to have just one patch not two.
Thanks,
Michal

[jeremyherbert]

Commits squashed here.

Thanks,
Jeremy

[michalsimek]

merged with small changes of commit message.