ARM: tegra: enable DFU too

Enable DFU protocol support (via the "dfu" command) on Tegra boards where
USB device/gadget mode is enabled.

Note that for DFU to operate correctly on Tegra, we still need some DFU
fixes/enhancements that are going through the DFU -> USB trees. However,
the code builds just fine without those changes, and applying this patch
now will allow both sets of patches to meet in the main U-Boot tree much
more quickly.

In order to run test/dfu/dfu_gadget_test.sh, you would need to add the
following to the board configuration:

CONFIG_EXT4_WRITE
CONFIG_CMD_EXT4_WRITE

However, I haven't enabled those here, since I believe the main use-case
for DFU on Tegra is raw flash writing, rather than filesystem access, so
we don't need the additional code-size hit. However, I could be persuaded
otherwise! We should probably add a separate test script for raw flash
access.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>
LOCAL: enable ext4 write for DFU testing

Signed-off-by: Stephen Warren <swarren@nvidia.com>
LOCAL: test: dfu: reduce max test binary size

Tegra's DFU buffer is smaller than 8M. Remove that test case since we
know it will fail.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
net: BOOTP retry timeout improvements

Currently, the BOOTP code sends out its initial request as soon as the
Ethernet driver indicates "link up". If this packet is lost or not
replied to for some reason, the code waits for a 1s timeout before
retrying. For some reason, such early packets are often lost on my
system, so this causes an annoying delay.

To optimize this, modify the BOOTP code to have very short timeouts for
the first packet transmitted, but gradually increase the timeout each
time a timeout occurs. This way, if the first packet is lost, the second
packet is transmitted quite quickly and hence the overall delay is low.
However, if there's still no response, we don't keep spewing out packets
at an insane speed.

It's arguably more correct to try and find out why the first packet is
lost. However, it seems to disappear inside my Ethenet chip; the TX chip
indicates no error during TX (not that it has much in the way of
reporting...), yet wireshark on the RX side doesn't see any packet.
FWIW, I'm using an ASIX USB Ethernet adapter. Perhaps "link up" is
reported too early or based on the wrong condition in HW, and we should
add some fixed extra delay into the driver. However, this would slow down
every link up event even if it ends up not being needed in some cases.
Having BOOTP retry quickly applies the fix/WAR to every possible
Ethernet device, and is quite simple to implement, so seems a better
solution.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
ARM: tegra: Disable VPR

(Note: Alex Courbot has sent this upstream)

On Tegra114 and Tegra124 platforms, certain display-related registers cannot
be accessed unless the VPR registers are programmed.  For bootloader, we
probably don't care about VPR, so we disable it (which counts as programming
it, and allows those display-related registers to be accessed.

This patch is based on the commit 5f499646c83ba08079f3fdff6591f638a0ce4c0c
in Chromium OS U-Boot project.

Signed-off-by: Andrew Chew <achew@nvidia.com>
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Signed-off-by: Bryan Wu <pengw@nvidia.com>
[acourbot: ensure write went through, vpr.c style changes]
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Cc: Tom Warren <TWarren@nvidia.com>
Cc: Stephen Warren <swarren@nvidia.com>
Cc: Terje Bergstrom <tbergstrom@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
ARM: tegra: Use mem size from MC rather than ODMDATA

In at least Tegra124, the Tegra memory controller (MC) has a register
that controls the memory size. Read this to determine the memory size
rather than requiring this to be redundantly encoded into the ODMDATA.
This way, changes to the BCT (i.e. MC configuration) automatically
updated SW's view of the memory size, without requiring manual changes
to the ODMDATA.

Future work potentially required:
* Clip the memory size to architectural limits; U-Boot probably doesn't
  and won't support either LPAE or Tegra's "swiss cheese" memory layout,
  at least one of which would be required for >2GB RAM.
* Subtract out any carveout required by firmware on future SoCs.

Based-on-work-by: Tom Warren <twarren@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
Note: this patch depends on Bryan's/Alex's "ARM: tegra: Disable VPR",
since that introduces mc.h, which this patch relies on.