3517de6d | 22-Apr-2016 |
Stephen Warren <swarren@nvidia.com> |
dfu: ram: fix number base of RAM entity parameters
U-Boot typically interprets unprefixed numbers as base 16, and DFU RAM entity parsing has historically done so. Reverse the change to default to ba
dfu: ram: fix number base of RAM entity parameters
U-Boot typically interprets unprefixed numbers as base 16, and DFU RAM entity parsing has historically done so. Reverse the change to default to base 10, so that values in previously working command-lines aren't mis-parsed, causing RAM corruption, crashes, hangs, etc.
Fixes: 6aeb877afef0 ("drivers: dfu: ram: fix a crash with dfu ram with invalid dfu_alt_info env")
Cc: Mugunthan V N <mugunthanvnm@ti.com> Cc: Tom Rini <trini@konsulko.com> Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Mugunthan V N <mugunthanvnm@ti.com> Tested-by: Mugunthan V N <mugunthanvnm@ti.com> [Test HW: AM335x BBB]
show more ...
|
873cc1d7 | 07-Dec-2015 |
Stephen Warren <swarren@nvidia.com> |
mmc: store hwpart in the block device
This will allow us to have multiple block device structs each referring to the same eMMC device, yet different HW partitions.
For now, there is still a single
mmc: store hwpart in the block device
This will allow us to have multiple block device structs each referring to the same eMMC device, yet different HW partitions.
For now, there is still a single block device per eMMC device. As before, this block device always accesses whichever HW partition was most recently selected. Clients wishing to make use of multiple block devices referring to different HW partitions can simply take a copy of this block device once it points at the correct HW partition, and use each one as they wish. This feature will be used by the next patch.
In the future, perhaps get_device() could be enhanced to return a dynamically allocated block device struct, to avoid the client needing to copy it in order to maintain multiple block devices. However, this would require all users to be updated to free those block device structs at some point, which is rather a large change.
Most callers of mmc_switch_part() wish to permanently switch the default MMC block device's HW partition. Enhance mmc_switch_part() so that it does this. This removes the need for callers to do this. However, common/env_mmc.c needs to save and restore the current HW partition. Make it do this more explicitly.
Replace use of mmc_switch_part() with mmc_select_hwpart() in order to remove duplicate code that skips the call if that HW partition is already selected.
Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Tom Rini <trini@konsulko.com>
show more ...
|
2727f3bf | 22-Sep-2015 |
Fabio Estevam <fabio.estevam@freescale.com> |
dfu: dfu_sf: Take the start address into account
The dfu_alt_info_spl variable allows passing a starting point for the binary to be flashed in the SPI NOR.
For example, if we have 'dfu_alt_info_spl
dfu: dfu_sf: Take the start address into account
The dfu_alt_info_spl variable allows passing a starting point for the binary to be flashed in the SPI NOR.
For example, if we have 'dfu_alt_info_spl=spl raw 0x400', this means that we want to flash the binary starting at address 0x400.
In order to do so we need to erase the entire sector and write to the the subsequent SPI NOR sectors taking such start address into account for the address calculations.
Tested by succesfully writing SPL binary into 0x400 offset and the u-boot.img at offset 64 kiB of a SPL NOR.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Acked-by: Lukasz Majewski <l.majewski@samsung.com> [trini: Use lldiv for the math] Signed-off-by: Tom Rini <trini@konsulko.com>
show more ...
|
411c5e57 | 04-Sep-2015 |
Stephen Warren <swarren@nvidia.com> |
dfu: mmc: buffer file reads too
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
dfu: mmc: buffer file reads too
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>
show more ...
|
2092e461 | 23-Aug-2015 |
Lukasz Majewski <l.majewski@majess.pl> |
dfu: tftp: update: Add dfu_write_from_mem_addr() function
This function allows writing via DFU data stored from fixed buffer address (like e.g. loadaddr env variable).
Such predefined buffers are u
dfu: tftp: update: Add dfu_write_from_mem_addr() function
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>
show more ...
|