APPLIED: fs: implement size/fatsize/ext4size

These commands may be used to determine the size of a file without
actually reading the whole file content into memory. This may be used
to determine if the file will fit into the memory buffer that will
contain it. In particular, the DFU code will use it for this purpose
in the next commit.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Lukasz Majewski <l.majewski@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
---
v2: New patch
APPLIED: dfu: fix some issues with reads/uploads

DFU read support appears to rely upon dfu->read_medium() updating the
passed-by-reference len parameter to indicate the remaining size
available for reading.

dfu_read_medium_mmc() never does this, and the implementation of
dfu_read_medium_nand() will only work if called just once; it hard-codes
the value to the total size of the NAND device irrespective of read
offset.

I believe that overloading dfu->read_medium() is confusing. As such,
this patch introduces a new function dfu->get_medium_size() which can
be used to explicitly find out the medium size, and nothing else.
dfu_read() is modified to use this function to set the initial value for
dfu->r_left, rather than attempting to use the side-effects of
dfu->read_medium() for this purpose.

Due to this change, dfu_read() must initially set dfu->b_left to 0, since
no data has been read.

dfu_read_buffer_fill() must also be modified not to adjust dfu->r_left
when simply copying data from dfu->i_buf_start to the upload request
buffer. r_left represents the amount of data left to be read from HW.
That value is not affected by the memcpy(), but only by calls to
dfu->read_medium().

After this change, I can read from either a 4MB or 1.5MB chunk of a 4MB
eMMC boot partion with CONFIG_SYS_DFU_DATA_BUF_SIZE==1MB. Without this
change, attempting to do that would result in DFU read returning no data
at all due to r_left never being set.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Lukasz Majewski <l.majewski@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
---
v2:
* Fix dfu_get_medium_size_mmc() to handle DFU_FS_FAT/EXT5 layouts too,
  by calling the recently introduced "size" command.
APPLIED: dfu: add write error handling

Fix calls to dfu_write() and dfu_flush() to detect errors in the I/O
itself. This could happen due to problems with the storage medium, or
simply when trying to write a FAT/ext file that is larger than the buffer
dfu_mmc.c maintains for this purpose.

Signal the error by switching the DFU state/status. This will be picked
up by the DFU client when it sends the next DFU request. Note that errors
can't simply be returned from e.g. dnload_request_complete(), since that
function has no way to pass errors back to the DFU client; a call to
dnload_request_complete() simply means that a USB OUT completed.

This error state/status needs to be cleared when the next DFU client
connects. While there is a DFU_CLRSTATUS request, no DFU client seems to
send this. Hence, clear this when selecting the USB alternate setting on
the USB interface.

Finally, dfu.c relies on a call to dfu_flush() to clear up the internal
state of the write transaction. Now that errors in dfu_write() are
detected, dfu_flush() may no longer be called for every transaction.
Separate out the cleanup code into a new function, and call it whenever
dfu_write() fails, as well as from any call to dfu_flush().

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Lukasz Majewski <l.majewski@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
---
This probably depends on "dfu: fix some issues with reads/uploads",
for context if nothing else.
APPLIED: dfu: defer parsing of device string to IO backend

Devices are not all identified by a single integer. To support
this, defer the parsing of the device string to the IO backed, so that
it can apply the appropriate rules.

SPI devices are specified as controller:chip_select. SPI/SF support will
be added soon.

MMC devices can also be specified as controller[.hwpart][:partition] in
many commands, although we don't support that syntax in DFU.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
APPLIED: dfu: allow backend to specify a maximum buffer size

CONFIG_SYS_DFU_DATA_BUF_SIZE may be large to allow for FAT/ext layouts
to transfer large files. However, this means that individual write
operations will take a long time. Allow backends to specify a maximum
buffer size, so that each write operation is limited to a smaller data
block. This prevents the DFU protocol from timing out when e.g. writing
to SPI flash. I would guess that NAND might benefit from setting this
value too, but I can't test that.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
APPLIED: dfu: add free_entity() to struct dfu_entity

This allows the backend to free any resources allocated during the
relevant dfu_fill_entity_*() call. This will soon be used by the
SF backend.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
APPLIED: dfu: add SF backend

This allows SPI Flash to be programmed using DFU.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
APPLIED???: test:dfu: Add test scripts for testing DFU regression

This commit adds test scripts for testing if any commit has introduced
regression to the DFU subsystem.

It uses md5 to test if sent and received file is correct.
The test detailed description is available at README file.

Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
APPLIED (probably with minor edits): test: dfu: script enhancements

Various misc enhancements to dfu_gadget_test.sh:

* After every write (download), perform a write to a different file
  with different data. This ensures that the DFU buffer's content is
  replaced, so that if the read (upload) succeeds, we know that the
  correct data was actually read from the storage device, rather than
  simply being left over in the DFU buffer. This requires two alt
  setting names to be passed to the script, and a dummy data file to
  be generated by dfu_gadget_test_init.sh.

* Fix the assumption that dfu_gadget_test.sh is run from the directory
  that contains it, by cd'ing to that directory before invoking
  ./dfu_gadget_test_init.sh.

* Use $DIR$RCV_DIR consistently, rather than using plain $RCV_DIR in
  some places.

* Add 959, 961 test file sizes, to be consistent with having one
  more than and one less than all the other "round" sizes 64, 128, and
  4096.

* Remove references to $BKP_DIR from dfu_gadget_test_init.sh, since it
  isn't used.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
v2: Rebased on top of V3 of "test:dfu: Add test scripts for testing DFU
    regression".
APPLIED: test: dfu: cleanup before execution

Call cleanup() before running tests too. If a previous test was CTRL-C'd
some stale files may have been left around. dfu-util refuses to receive
a file to a filename that already exists, which results in false test
failures if the files aren't cleaned up first.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
APPLIED: test: dfu: add some more test cases

On Tegra, the DFU buffer size is 1M. Consequently, the 8M test always
fails. Add tests for the 1M size, and one byte less as a corner case,
so that some large tests are executed and expected to pass.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
APPLIED: dfu: fix readback buffer overflow test

The buffer is too small if it's < size to read, not if it's <= the size.
This fixes the 1MB test case on Tegra, which has a 1MB buffer.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
APPLIED: git-mailrc: add a kconfig alias

It's easier to Cc Masahiro on Kconfig-related changes with a git-mailrc
alias.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
pxe: clear Bootfile before returning

When "pxe boot" downloads the initrd/kernel/DTB, netboot_common() saves
the downloaded filename to global variable BootFile. If the boot
operation is aborted, this global state is not cleared. If "dhcp" is
executed later without any arguments, BootFile is not cleared, and when
the DHCP response is received, BootpCopyNetParams() writes the value into
environment variable bootfile.

This causes the following scenario:

* Boot script executes dhcp; pxe get; pxe boot

* User CTRL-C's the PXE menu, which causes the first menu item to be
  booted, which causes some file to be downloaded.

  (This boot-on-CTRL-C behaviour is arguably a bug too, but it's a
  separate bug and the bug this patch fixes would still exist if the user
  simply waited to press CTRL-C until "pxe boot" started downloading
  files)

* User CTRL-C's the file downloads, but the filename is still written to
  the bootfile environment variable.

* User re-runs the boot command, which in my case executes "dhcp; pxe get;
  pxe boot" again, and "dhcp" picks up the saved bootfile environment
  variable and proceeds to download a file that it shouldn't.

To solve this, modify the implementation of "pxe get" to clear BootFile
if the whole boot operation fails, which avoids this whole mess.

An alternative would be to modify netboot_common() such that the no-
arguments case explicitly clears the global variable BootFile. However,
that would prevent the following command sequences from working:

$ dhcp filename # downloads "filename"
$ dhcp          # downloads $bootfile, i.e. "filename"

or:
$ setenv bootfile filename
$ dhcp          # downloads $bootfile, i.e. "filename"

... and I assume someone relies on U-Boot working that way.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
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>
Acked-by: Joe Hershberger <joe.hershberger@ni.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>
lib: lmb: fix overflow in __lmb_alloc_base w/ large RAM

If a 32-bit system has 2GB of RAM, and the base address of that RAM is
2GB, then start+size will overflow a 32-bit value (to a value of 0).

__lmb_alloc_base is affected by this; it calculates the minimum of
(start+size of RAM) and max_addr. However, when start+size is 0, it
is always less than max_addr, which causes the value of max_addr not
to be taken into account when restricting the allocation's location.

Fix this by calculating start+size separately, and if that calculation
underflows, using -1 (interpreted as the max unsigned value) as the
value instead, and then taking the min of that and max_addr. Now that
start+size doesn't overflow, it's typically large, and max_addr
dominates the min() call, and is taken into account.

The user-visible symptom of this bug is that CONFIG_BOOTMAP_SZ is ignored
on Tegra124 systems with 2GB of RAM, which in turn causes the DT to be
relocated at the very end of RAM, which the ARM Linux kernel doesn't map
during early boot, and which causes boot failures. With this fix,
CONFIG_BOOTMAP_SZ correctly restricts the relocated DT to a much lower
address, and everything works.

Signed-off-by: Stephen Warren <swarren@nvidia.com>