When dfu_fill_entity fail, need to free dfu to avoid memory leak.
Reported by Coverity:
"
Resource leak (RESOURCE_LEAK)
leaked_storage: Variable dfu going out of scope leaks the storage
it points to.
"
Signed-off-by: Peng Fan <van.freenix@gmail.com>
Cc: "Łukasz Majewski" <l.majewski@samsung.com>
Cc: Marek Vasut <marex@denx.de>
When writing to files in a filesystem on MMC, dfu_mmc.c buffers up the
entire file content until the end of the transaction, at which point the
file is written in one go. This allows writing files larger than the USB
transfer size (CONFIG_SYS_DFU_DATA_BUF_SIZE); the maximum written file
size is CONFIG_SYS_DFU_MAX_FILE_SIZE (the size of the temporary buffer).
The current file reading code does not do any buffering, and so limits
the maximum read file size to the USB transfer size. Enhance the code to
do the same kind of buffering as the write path, so the same file size
limits apply.
Remove the size checking code from dfu_read() since all read paths now
support larger files than the USB transfer buffer.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Lukasz Majewski <l.majewski@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
DFU currently allocates buffer memory at the start of each data transfer
operation and frees it at the end. Especially since memalign() is used to
allocate the buffer, and various other allocations happen during the
transfer, this can expose the code to heap fragmentation, which prevents
the allocation from succeeding on subsequent transfers.
Fix the code to allocate the buffer once when DFU mode is initialized,
and free the buffer once when DFU mode is exited, to reduce the exposure
to heap fragmentation.
The failure mode is:
// Internally to memalign(), this allocates a lot more than s to guarantee
// that alignment can occur, then returns chunks of memory at the start/
// end of the allocated buffer to the heap.
p = memalign(a, s);
// Various other malloc()s occur here, some of which allocate the RAM
// immediately before/after "p".
//
// DFU transfer is complete, so buffer is released.
free(p);
// By chance, no other malloc()/free() here, in DFU at least.
//
// A new DFU transfer starts, so the buffer is allocated again.
// In theory this should succeed since we just free()d a buffer of the
// same size. However, this fails because memalign() internally attempts
// to allocate much more than "s", yet free(p) above only free()d a
// little more than "s".
p = memalign(a, s);
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 function allows writing via DFU data stored from fixed buffer address
(like e.g. loadaddr env variable).
Such predefined buffers are used in the update_tftp() code. In fact this
function is a wrapper on the dfu_write() and dfu_flush().
Signed-off-by: Lukasz Majewski <l.majewski@majess.pl>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
After extension of the dfu_get_buf() to also setup (implicitly) the dfu_buf_size
variable it is not needed to set dfu_buf_size to CONFIG_SYS_DFU_DATA_BUF_SIZE.
This variable is set in the dfu_get_buf() by not only considering
CONFIG_SYS_DFU_DATA_BUF but more importantly the "dfu_bufsiz" env variable.
Therefore, dfu_get_buf() should be used for initialization.
Signed-off-by: Lukasz Majewski <l.majewski@majess.pl>
Reviewed-by: Przemyslaw Marczak <p.marczak@samsung.com>
Use %p to print pointers.
The max value of (i_buf - i_buf_start) should be dfu_buf_size, which is
an unsigned long, so cast the pointer difference to that type to print.
Change-Id: Iee242df9f8eb091aecfe0cea4c282b28b547acfe
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
This common call can be used for setting proper entities based
on dfu command arguments.
The config: CONFIG_SET_DFU_ALT_INFO, was used only for few configs,
and now it is common.
The board file should implement:
- set_dfu_alt_info() function
Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
[Test HW: Odroid U3 (Exynos 4412)]
In function dfu_get_buf(), the size of allocated buffer could
be defined by the env variable. The size from this variable
was passed for memalign() without checking its value.
And the the memalign will return non null pointer for size 0.
This could possibly cause data abort, so now the value of var
is checked before use. And if this variable is set to 0 then
the default size will be used.
This commit also changes the base passed to simple_strtoul()
to 0. Now decimal and hex values can be used for the variable
dfu_bufsiz.
Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
[TestHW: Exynos4412-Trats2]
In order to add detach functions for fastboot, make the DFU detach related
functions common so they can be shared.
Signed-off-by: Rob Herring <robh@kernel.org>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
[TestHW: Exynos4412-Trats2]
U-Boot has never cared about the type when we get max/min of two
values, but Linux Kernel does. This commit gets min, max, min3, max3
macros synced with the kernel introducing type checks.
Many of references of those macros must be fixed to suppress warnings.
We have two options:
- Use min, max, min3, max3 only when the arguments have the same type
(or add casts to the arguments)
- Use min_t/max_t instead with the appropriate type for the first
argument
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: Pavel Machek <pavel@denx.de>
Acked-by: Lukasz Majewski <l.majewski@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
[trini: Fixup arch/blackfin/lib/string.c]
Signed-off-by: Tom Rini <trini@ti.com>
Recently the ext4 file system imposed passing absolute path with its file
name parameter.
As a result dfu_alt_info env variable has been modified to provide absolute
path when ext4 file system is accessed (e.g. /uImage ext4 0 2;).
Unfortunately, lthor flashing program provides plain file name (like uImage)
and hence those two file names do not match anymore.
Presented commit also allows lthor to write files to sub directories (like
/boot/bin/uImage).
Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Reviewed-by: Marek Vasut <marex@denx.de>
This commit provides distinction between DFU device detach and reset.
The -R behavior is preserved with proper handling of the dfu-util's -e
switch, which detach the DFU device.
By running dfu-util -e; one can force device to finish the execution of
dfu command on target and execute some other scripted commands.
Moreover, some naming has been changed - the dfu_reset() method now is known
as dfu_detach(). New name better reflects the purpose of the code.
It was also necessary to increase the number of usb_gadget_handle_interrupts()
calls since we also must wait for detection of the USB reset event.
Example usage:
1. -e (detach) switch
dfu-util -a0 -D file1.bin;dfu-util -a3 -D uImage;dfu-util -e
access to u-boot prompt.
2. -R (reset) switch
dfu-util -a0 -D file1.bin;dfu-util -R -a3 -D uImage
target board reset
Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
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>
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>
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>
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>
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>
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>
Patch (SHA1: bd694244db)
dfu: Introduction of the "dfu_hash_algo" env variable for checksum method
setting
already introduced more generic handling of the crc32 calculation.
Up till now the CRC32 of received data was calculated unconditionally.
This patch changes this and from now - by default the crc32 is NOT
calculated anymore.
Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Cc: Marek Vasut <marex@denx.de>
Up till now the CRC32 of received data was calculated unconditionally.
The standard crc32 implementation causes long delay when large images
were uploaded.
The "dfu_hash_algo" environment variable gives the opportunity to
disable on demand the hash (crc32) calculation.
It can be done without the need to recompile the u-boot binary.
By default the crc32 is calculated, which means that legacy behavior
has been preserved.
Tests results:
400 MiB ums.img file
With crc32 calculation: 65 sec [avg 6.29 MB/s]
Without crc32 calculation: 25 sec [avg 16.17 MB/s]
Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Cc: Marek Vasut <marex@denx.de>
Before dfu write and flush operations separation,
dfu write data was flushed by host download request
with len of zero size.
Since above change manually calling dfu write with zero
size has non sense (e.g. in THOR). This should be done by
flush operation.
So now dfu_write_buffer_drain() is called in dfu_flush().
If there is any raw data to flush (like it can be in thor)
then it will be physically written to medium.
Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Marek Vasut <marex@denx.de>
This patch remove always false (since we tested ret = 0) ternary operator
with ret value returned.
Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
on nand flash using ubi, after the download of the new image into
the flash, the "rest" of the nand sectors get erased while flushing
the medium. With current u-boot version dfu-util may show:
Starting download: [##################################################] finished!
state(7) = dfuMANIFEST, status(0) = No error condition is present
unable to read DFU status
as get_status is not answered while erasing sectors, if erasing
needs some time.
So do the following changes to prevent this:
- introduce dfuManifest state
According to dfu specification
( http://www.usb.org/developers/devclass_docs/usbdfu10.pdf ) section 7:
"the device enters the dfuMANIFEST-SYNC state and awaits the solicitation
of the status report by the host. Upon receipt of the anticipated
DFU_GETSTATUS, the device enters the dfuMANIFEST state, where it
completes its reprogramming operations."
- when stepping into dfuManifest state, sending a PollTimeout
DFU_MANIFEST_POLL_TIMEOUT in ms, to the host, so the host
(dfu-util) waits the PollTimeout before sending a get_status again.
Signed-off-by: Heiko Schocher <hs@denx.de>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Pantelis Antoniou <panto@antoniou-consulting.com>
move the flushing code into an extra function dfu_flush(),
so it can be used from other code.
Signed-off-by: Heiko Schocher <hs@denx.de>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Pantelis Antoniou <panto@antoniou-consulting.com>
Thanks to this multiple call of function dfu_config_entities()
gives continuous dfu alt numbering until call dfu_free_entities().
This allows to store dfu entities in multiple variables.
Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com>
Acked-by: Łukasz Majewski <l.majewski@samsung.com>
Tested-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
The method for exporting size of allocated buffer is provided.
It is afterwards used by USB's dfu function code.
Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
After dfu buffer is initialized, the buffer should be all available,
while not 0. Initialize its value to min(dfu_buf_size, dfu->r_left).
Signed-off-by: Bo Shen <voice.shen@atmel.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
Acked-by: Lukasz Majewski <l.majewski@samsung.com>
Define the dfu_get_buf() and dfu_free_buf() as global functions.
They are necessary for zero copy buffer management, when DFU backend is
used for storing data.
Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
New function - dfu_get_alt() - has been added to dfu core. If present, it
returns alt setting's number corresponding to passed name.
Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
This commit unifies board-specific USB initialization implementations
under one symbol (usb_board_init), declaration of which is available in
usb.h.
New API allows selective initialization of USB controllers whenever needed.
Signed-off-by: Mateusz Zalega <m.zalega@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Lukasz Majewski <l.majewski@samsung.com>
DFU spec mentions it as a method to upgrade firmware (software stored
in writable non-volatile memory). It also says other potential uses of
DFU is beyond scope of the spec.
Here such a beyond the scope use is being attempted - directly pumping
binary images from host via USB to RAM. This facility is a developer
centric one in that it gives advantage over upgrading non-volatile
memory for testing new images every time during development and/or
testing.
Directly putting image onto RAM would speed up upgrade process. This and
convenience was the initial thoughts that led to doing this, speed
improvement over MMC was only 1 second though - 6 sec on RAM as opposed
to 7 sec on MMC in beagle bone, perhaps enabling cache and/or optimizing
DFU framework to avoid multiple copy for ram (if worth) may help, and
on other platforms and other boot media like NAND maybe improvement
would be higher.
And for a platform that doesn't yet have proper DFU suppport for
non-volatile media's, DFU to RAM can be used.
Another minor advantage would be to increase life of mmc/nand as it
would be less used during development/testing.
usage: <image name> ram <start address> <size>
eg. kernel ram 0x81000000 0x1000000
Downloading images to RAM using DFU is not something new, this is
acheived in openmoko also.
DFU on RAM can be used for extracting RAM contents to host using dfu
upload. Perhaps this can be extended to io for squeezing out register
dump through usb, if it is worth.
Signed-off-by: Afzal Mohammed <afzal.mohd.ma@gmail.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Marek Vasut <marex@denx.de>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Pantelis Antoniou <panto@antoniou-consulting.com>
Cc: Gerhard Sittig <gsi@denx.de>
Acked-by: Marek Vasut <marex@denx.de>
Acked-by: Lukasz Majewski <l.majewski@samsung.com>
Acked-by: Heiko Schocher <hs@denx.de>
New dfu_init_env_entities() function has been extracted from cmd_dfu.c and
stored at dfu core.
This is a dfu centric code, so it shall be processed in the core.
Change-Id: I756c5de922fa31399d8804eaadc004ee98844ec2
Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Tested-by: Heiko Schocher <hs@denx.de>
This patch extends dfu code to support transmission with -R switch
specified at dfu-util.
When -R is specified, the extra USB_REQ_DFU_DETACH request is sent after
successful data transmission. Then dfu resources are released and reset
command is issued.
Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
For the first eMMC read of data for upload, use the "large" dfu_buf (now
configurable) instead of usb request buffer allocated at composite layer
(which is 4KiB) [*].
For eMMC the whole file is read, which usually is larger than the buffer [*]
provided with usb request.
Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Cc: Tom Rini <trini@ti.com>
Cc: Pantelis Antoniou <panto@antoniou-consulting.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Heiko Schocher <hs@denx.de>
Dfu transfer uses a buffer before writing data to the
raw storage device. Make the size (in bytes) of this buffer
configurable through environment variable "dfu_bufsiz".
Defaut value is configurable through CONFIG_SYS_DFU_DATA_BUF_SIZE
Signed-off-by: Heiko Schocher <hs@denx.de>
Cc: Pantelis Antoniou <panto@antoniou-consulting.com>
Cc: Tom Rini <trini@ti.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Wolfgang Denk <wd@denx.de>
Acked-by: Tom Rini <trini@ti.com>
Support for NAND storage devices to work with the DFU framework.
Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>
Signed-off-by: Tom Rini <trini@ti.com>
Acked-by: Scott Wood <scottwood@freescale.com>
Previously we didn't support upload/download larger than available
memory. This is pretty bad when you have to update your root filesystem
for example.
This patch removes that limitation (and the crashes when you transfered
any file larger than 4MB) by making raw image writes be done in chunks
and making file maximum size be configurable.
The sequence number is a 16 bit counter; make sure we handle rollover
correctly. This fixes the wrong transfers for large (> 256MB) images.
Also utilize a variable to handle initialization, so that we don't rely
on just the counter sent by the host.
Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>
Signed-off-by: Tom Rini <trini@ti.com>
New, separate driver at ./drivers/dfu has been added. It allows platform
and storage independent operation of DFU.
It has been extended to use new MMC level of command abstraction.
Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Marek Vasut <marex@denx.de>
Peng Fan