Add crc32 verification of the flash image

Verify the CRC32 of the flash image at two points in time:

1) Before starting the flashing process, to validate the download of the
   image into Tegra's RAM.

2) After writing the image to flash, read it back into RAM, in order to
   validate that it was correctly written to flash.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Increase padding between U-Boot binary and flash image

The flasher currently places the flash image in RAM almost directly above
the initial U-Boot binary location, with just a little padding/alignment
in between. This is also where U-Boot's BSS is located, prior to U-Boot
relocating itself to the top of RAM. Hence, if U-Boot touches its BSS, it
will corrupt the flash image. Increase the padding between U-Boot/DT and
the flash image to avoid this. U-Boot's BSS is roughly 300K at present.
Make the pad size 1M to allow plenty of room for growth.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Allow overriding environment variables during flashing

The flashing process resets the U-Boot environment to the built-in
default. Allow the user to specify some non-default values to be set
before saving the environment. This can be useful e.g. to set up the
default boot target:

./tegra-uboot-flasher flash --env boot_targets dhcp beaver

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Provide progress messages

Print messages to the U-Boot console while executing the flashing
process. For NAND and SPI at least, IO operations can be quite slow,
and it's useful to know the U-Boot is executing what may be a long-
running operation.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>