<feed xmlns='http://www.w3.org/2005/Atom'>
<title>u-boot.git/drivers/dfu, branch v2016.03</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/'/>
<entry>
<title>mmc: store hwpart in the block device</title>
<updated>2016-01-14T02:05:19+00:00</updated>
<author>
<name>Stephen Warren</name>
<email>swarren@nvidia.com</email>
</author>
<published>2015-12-07T18:38:49+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=873cc1d7775ed5de07e6722c7ff423080c2e8f71'/>
<id>873cc1d7775ed5de07e6722c7ff423080c2e8f71</id>
<content type='text'>
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 &lt;swarren@nvidia.com&gt;
Reviewed-by: Tom Rini &lt;trini@konsulko.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;swarren@nvidia.com&gt;
Reviewed-by: Tom Rini &lt;trini@konsulko.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>block: pass block dev not num to read/write/erase()</title>
<updated>2016-01-14T02:05:18+00:00</updated>
<author>
<name>Stephen Warren</name>
<email>swarren@nvidia.com</email>
</author>
<published>2015-12-07T18:38:48+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=7c4213f6a52f35ff6ba2d97aa4eb04cbfc963b86'/>
<id>7c4213f6a52f35ff6ba2d97aa4eb04cbfc963b86</id>
<content type='text'>
This will allow the implementation to make use of data in the block_dev
structure beyond the base device number. This will be useful so that eMMC
block devices can encompass the HW partition ID rather than treating this
out-of-band. Equally, the existence of the priv field is crying out for
this patch to exist.

Signed-off-by: Stephen Warren &lt;swarren@nvidia.com&gt;
Reviewed-by: Tom Rini &lt;trini@konsulko.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This will allow the implementation to make use of data in the block_dev
structure beyond the base device number. This will be useful so that eMMC
block devices can encompass the HW partition ID rather than treating this
out-of-band. Equally, the existence of the priv field is crying out for
this patch to exist.

Signed-off-by: Stephen Warren &lt;swarren@nvidia.com&gt;
Reviewed-by: Tom Rini &lt;trini@konsulko.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>dfu: dfu_sf: Pass duplicate devstr to parse_dev</title>
<updated>2015-11-03T16:29:33+00:00</updated>
<author>
<name>Vignesh R</name>
<email>vigneshr@ti.com</email>
</author>
<published>2015-10-20T09:52:00+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=30e3ea4c79dd35e97d04546bd39e2468c8ba63ef'/>
<id>30e3ea4c79dd35e97d04546bd39e2468c8ba63ef</id>
<content type='text'>
parse_dev() alters the string pointed by devstr parameter. Due to this
subsequent parsing of sf entities will fail, as string pointed by devstr
is no longer valid sf dev arguments.
Fix this by passing pointer to the copy of the string to parse_dev
instead of pointer to the actual devstr.

Signed-off-by: Vignesh R &lt;vigneshr@ti.com&gt;
Reviewed-by: Tom Rini &lt;trini@konsulko.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
parse_dev() alters the string pointed by devstr parameter. Due to this
subsequent parsing of sf entities will fail, as string pointed by devstr
is no longer valid sf dev arguments.
Fix this by passing pointer to the copy of the string to parse_dev
instead of pointer to the actual devstr.

Signed-off-by: Vignesh R &lt;vigneshr@ti.com&gt;
Reviewed-by: Tom Rini &lt;trini@konsulko.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>dfu: dfu_sf: Take the start address into account</title>
<updated>2015-10-19T21:05:13+00:00</updated>
<author>
<name>Fabio Estevam</name>
<email>fabio.estevam@freescale.com</email>
</author>
<published>2015-09-23T03:50:39+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=2727f3bfba1bc78ca517984c2c9e0c473aeedbf4'/>
<id>2727f3bfba1bc78ca517984c2c9e0c473aeedbf4</id>
<content type='text'>
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 &lt;fabio.estevam@freescale.com&gt;
Acked-by: Lukasz Majewski &lt;l.majewski@samsung.com&gt;
[trini: Use lldiv for the math]
Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;fabio.estevam@freescale.com&gt;
Acked-by: Lukasz Majewski &lt;l.majewski@samsung.com&gt;
[trini: Use lldiv for the math]
Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>dfu: dfu_sf: Use the erase sector size for erase operations</title>
<updated>2015-10-19T17:47:06+00:00</updated>
<author>
<name>Fabio Estevam</name>
<email>fabio.estevam@freescale.com</email>
</author>
<published>2015-09-22T03:55:00+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=f4c92582137a645ffc42346d7176ddd1462c2be0'/>
<id>f4c92582137a645ffc42346d7176ddd1462c2be0</id>
<content type='text'>
SPI NOR flashes need to erase the entire sector size and we cannot pass
any arbitrary length for the erase operation.

To illustrate the problem:

Copying data from PC to DFU device
Download    [=========================] 100%       478208 bytes
Download done.
state(7) = dfuMANIFEST, status(0) = No error condition is present
state(10) = dfuERROR, status(14) = Something went wrong, but the
device does not know what it was
Done!

In this case, the binary has 478208 bytes and the M25P32 SPI NOR
has an erase sector of 64kB.

478208  = 7 entire sectors of 64kiB + 19456 bytes.

Erasing the first seven 64 kB sectors works fine, but when trying
to erase the remainding 19456 causes problem and the board hangs.

Fix the issue by always erasing with the erase sector size.

Signed-off-by: Fabio Estevam &lt;fabio.estevam@freescale.com&gt;
Acked-by: Lukasz Majewski &lt;l.majewski@samsung.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
SPI NOR flashes need to erase the entire sector size and we cannot pass
any arbitrary length for the erase operation.

To illustrate the problem:

Copying data from PC to DFU device
Download    [=========================] 100%       478208 bytes
Download done.
state(7) = dfuMANIFEST, status(0) = No error condition is present
state(10) = dfuERROR, status(14) = Something went wrong, but the
device does not know what it was
Done!

In this case, the binary has 478208 bytes and the M25P32 SPI NOR
has an erase sector of 64kB.

478208  = 7 entire sectors of 64kiB + 19456 bytes.

Erasing the first seven 64 kB sectors works fine, but when trying
to erase the remainding 19456 causes problem and the board hangs.

Fix the issue by always erasing with the erase sector size.

Signed-off-by: Fabio Estevam &lt;fabio.estevam@freescale.com&gt;
Acked-by: Lukasz Majewski &lt;l.majewski@samsung.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>dfu: mmc: buffer file reads too</title>
<updated>2015-09-11T21:15:23+00:00</updated>
<author>
<name>Stephen Warren</name>
<email>swarren@nvidia.com</email>
</author>
<published>2015-09-05T04:03:47+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=411c5e57e8cf7dd83627a24b5cde73a0e662b1b0'/>
<id>411c5e57e8cf7dd83627a24b5cde73a0e662b1b0</id>
<content type='text'>
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 &lt;swarren@nvidia.com&gt;
Acked-by: Lukasz Majewski &lt;l.majewski@samsung.com&gt;
Tested-by: Lukasz Majewski &lt;l.majewski@samsung.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;swarren@nvidia.com&gt;
Acked-by: Lukasz Majewski &lt;l.majewski@samsung.com&gt;
Tested-by: Lukasz Majewski &lt;l.majewski@samsung.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>dfu: don't keep freeing/reallocating</title>
<updated>2015-09-11T21:15:23+00:00</updated>
<author>
<name>Stephen Warren</name>
<email>swarren@nvidia.com</email>
</author>
<published>2015-09-05T04:03:46+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=806bd245b1ab392245e6adc56522c3473edbc805'/>
<id>806bd245b1ab392245e6adc56522c3473edbc805</id>
<content type='text'>
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 &lt;swarren@nvidia.com&gt;
Acked-by: Lukasz Majewski &lt;l.majewski@samsung.com&gt;
Tested-by: Lukasz Majewski &lt;l.majewski@samsung.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;swarren@nvidia.com&gt;
Acked-by: Lukasz Majewski &lt;l.majewski@samsung.com&gt;
Tested-by: Lukasz Majewski &lt;l.majewski@samsung.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>dfu: tftp: Kconfig: Add Kconfig entry for dfu tftp feature</title>
<updated>2015-09-07T11:41:05+00:00</updated>
<author>
<name>Lukasz Majewski</name>
<email>l.majewski@majess.pl</email>
</author>
<published>2015-08-23T22:21:49+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=585a696e4eebab3b48004cf70e1077fb38287c60'/>
<id>585a696e4eebab3b48004cf70e1077fb38287c60</id>
<content type='text'>
The dfu tftp feature can be now enabled via Kconfig. This
commit provides necessary code for it.

Signed-off-by: Lukasz Majewski &lt;l.majewski@majess.pl&gt;
Acked-by: Joe Hershberger &lt;joe.hershberger@ni.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The dfu tftp feature can be now enabled via Kconfig. This
commit provides necessary code for it.

Signed-off-by: Lukasz Majewski &lt;l.majewski@majess.pl&gt;
Acked-by: Joe Hershberger &lt;joe.hershberger@ni.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>dfu: tftp: update: Add dfu_write_from_mem_addr() function</title>
<updated>2015-09-07T11:41:04+00:00</updated>
<author>
<name>Lukasz Majewski</name>
<email>l.majewski@majess.pl</email>
</author>
<published>2015-08-23T22:21:46+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=2092e4610485618ec7a676ff8e6d297ea9dca3d5'/>
<id>2092e4610485618ec7a676ff8e6d297ea9dca3d5</id>
<content type='text'>
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 &lt;l.majewski@majess.pl&gt;
Acked-by: Joe Hershberger &lt;joe.hershberger@ni.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;l.majewski@majess.pl&gt;
Acked-by: Joe Hershberger &lt;joe.hershberger@ni.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>dfu: tftp: update: Provide tftp support for the DFU subsystem</title>
<updated>2015-09-07T11:41:04+00:00</updated>
<author>
<name>Lukasz Majewski</name>
<email>l.majewski@majess.pl</email>
</author>
<published>2015-08-23T22:21:45+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=2d50d68a4ca1cce82899c9f0cfca17edf34bb254'/>
<id>2d50d68a4ca1cce82899c9f0cfca17edf34bb254</id>
<content type='text'>
This commit adds initial support for using tftp for downloading and
upgrading firmware on the device.

Signed-off-by: Lukasz Majewski &lt;l.majewski@majess.pl&gt;
Acked-by: Joe Hershberger &lt;joe.hershberger@ni.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This commit adds initial support for using tftp for downloading and
upgrading firmware on the device.

Signed-off-by: Lukasz Majewski &lt;l.majewski@majess.pl&gt;
Acked-by: Joe Hershberger &lt;joe.hershberger@ni.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
