README: document CONFIG_ENV_IS_IN_MMC

Describe the meaning of CONFIG_ENV_IS_IN_MMC, and all related defines that
must or can be set when using that option.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
v3:
* Mention that env size/offset are in bytes.
* Fix typo; s/CONFIG_ENV_OFFSET/CONFIG_ENV_SIZE/ in one place.
v2: New patch.
mmc: report capacity for the selected partition

Enhance the MMC core to calculate the size of each MMC partition, and
update mmc->capacity whenever a partition is selected. This causes:

mmc dev 0 1 ; mmcinfo

... to report the size of the currently selected partition, rather than
always reporting the size of the user partition.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
v3: No change.
v2: No change.
env_mmc: allow negative CONFIG_ENV_OFFSET

A negative value of CONFIG_ENV_OFFSET is treated as a backwards offset
from the end of the eMMC device/partition, rather than a forwards offset
from the start.

This is useful when a single board may be stuffed with different eMMC
devices, each of which has a different capacity, and you always want the
environment to be stored at the very end of the device (or eMMC boot
partition for example).

One example of this case is NVIDIA's Ventana reference board.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
v3: No change.
v2: Also update README to describe the change.
ARM: tegra: make use of negative ENV_OFFSET on NVIDIA boards

Use a negative value of CONFIG_ENV_OFFSET for all NVIDIA reference boards
that store the U-Boot environment in the 2nd eMMC boot partition. This
makes U-Boot agnostic to the size of the eMMC boot partition, which can
vary depending on which eMMC device was actually stuffed into the board.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
v3: No change.
v2: No change.
ext4: assign get_fs()->dev_desc before using it

Commit 50ce4c0 "fs/ext4: Support device block sizes != 512 bytes"
modified ext4fs_set_blk_dev() to calculate total_sect based on
get_fs()->dev_desc->log2blksz rather than SECTOR_SIZE. However, this
value wasn't yet assigned. Move the assignment earlier so the code
doesn't crash or hang.

Cc: Egbert Eich <eich@suse.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
ARM: tegra: only enable SCU on Tegra20

The non-SPL build of U-Boot on Tegra only runs on a single CPU, and
hence there is no need to enable the SCU when running U-Boot. If an
SMP OS is booted, and it needs the SCU enabled, it will enable the SCU
itself. U-Boot doing so is redundant.

The one exception is Tegra20, where an enabled SCU is required for some
aspects of PCIe to work correctly.

Some Tegra SoCs contain CPUs without a software-controlled SCU. In this
case, attempting to turn it on actively causes problems. This is the case
for Tegra114. For example, when running Linux, the first (or at least
some very early) user-space process will trigger the following kernel
message:

Unhandled fault: imprecise external abort (0x406) at 0x00000000

This is typically accompanied by that process receving a fatal signal,
and exiting. Since this process is usually pid 1, this causes total
system boot failure.

Signed-off-by: Tom Warren <twarren@nvidia.com>
[swarren, fleshed out description, ported to upstream chipid APIs]
Signed-off-by: Stephen Warren <swarren@nvidia.com>