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>
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>
Before this patch it was only possible to access the default eMMC HW
partition. By partition selection I mean the access to eMMC via the
ext_csd[179] register programming.
It sometimes happens that it is necessary to write to other partitions.
This patch adds extra attribute to "raw" sub type of the dfu_alt_info
environment variable (e.g. boot-mmc.bin raw 0x0 0x200 mmcpart 1;)
It saves the original boot value and restores it after storing the file.
Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Previously offsets handled by dfu_fill_entity_mmc(), defined in boards'
CONFIG_DFU_ALT were treated as hexadecimal regardless of their prefix,
which sometimes led to confusion. This patch forces usage of explicit
numerical base prefixes.
Signed-off-by: Mateusz Zalega <m.zalega@samsung.com>
Acked-by: Lukasz Majewski <l.majewski@samsung.com>
Cc: Tom Rini <trini@ti.com>
Cc: Minkyu Kang <mk7.kang@samsung.com>
When user attempted to perform a raw write using DFU (vide
dfu_fill_entity_mmc) with MMC interface not initialized before,
get_mmc_blk_size() reported invalid (zero) block size - it wasn't
possible to write ie. a new u-boot image.
This commit fixes that by initializing MMC device before use in
dfu_fill_entity_mmc().
While fixing initialization sequence, I had to change about half of
dfu_fill_entity_mmc's body, so I refactored it on the way to make it,
IMHO, considerably more comprehensible.
Being left as dead code, get_mmc_blk_size() was removed.
Tested on Samsung Goni.
Signed-off-by: Mateusz Zalega <m.zalega@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Acked-by: Lukasz Majewski <l.majewski@samsung.com>
Acked-by: Tom Rini <trini@ti.com>
Cc: Minkyu Kang <mk7.kang@samsung.com>
For some time we have been using the run_command() with properly crafted
string. Such approach turned to be unreliable and error prone.
Switch to "native" mmc subsystem API would allow better type checking and
shall improve speed.
Also, it seems that this API is changing less often than u-boot commands.
The approach similar to env operations on the eMMC has been reused.
Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
The commit:
"EXT4: Fix number base handling of "ext4write" command"
SHA1: f7740f7712
Cleaned up the ext4write command format.
This commit shall be regarded as a follow up, since the DFU subsystem is
using those commands for its normal operation.
Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
MMC and NAND independently defines same enumerators for read/write.
Unify them by defining enum in dfu header. RAM support that is being
added newly also can make use of it.
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>
Acked-by: Lukasz Majewski <l.majewski@samsung.com>
Acked-by: Marek Vasut <marex@denx.de>
Acked-by: Heiko Schocher <hs@denx.de>
In the following commit:
"dfu: Support larger than memory transfers."
SHA1: ea2453d56b
The ext4{read|write} command formatting has been changed. It removed
a write mandatory [sizebytes] parameter.
It extents DFU_FS_EXT4 case at mmc_file_op to provide mandatory
parameter for DFU write.
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>
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>
Following commit:
"cmd_ext4: BREAK and correct ext4write parameter order"
SHA1:0171d52c410cbaa9290b1b214e695697c835bfe5
introduced cleanup of ext4write semantics to be consistent with other
filesystem's writing commands (e.g. fatwrite).
This commit provides correct ext4write command generation at DFU eMMC
code.
Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Dealing with raw block numbers with the dfu is very annoying.
Introduce a partition method.
Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>
The "filesize" environment variable shall be read only when relevant
file is read.
Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Support for ext4 file system handling at DFU.
Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Support for MMC storage devices to work with DFU framework.
Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Marek Vasut <marex@denx.de>
