On 13 January 2015 at 11:35, Stefan Roese s...@denx.de wrote:
Hi Wolfgang,
On 12.01.2015 22:10, Wolfgang Denk wrote:
Should we add a memset(buf, 0, sizeof(buf)) before the memcpy() to
prevent information from earlier activities to leak?
buf points to the new data to be written into the
On 22.04.2015 13:11, Jagan Teki wrote:
On 12.01.2015 22:10, Wolfgang Denk wrote:
Should we add a memset(buf, 0, sizeof(buf)) before the memcpy() to
prevent information from earlier activities to leak?
buf points to the new data to be written into the flash. We're
overwriting the first len
On 22 April 2015 at 16:45, Stefan Roese s...@denx.de wrote:
On 22.04.2015 13:11, Jagan Teki wrote:
On 12.01.2015 22:10, Wolfgang Denk wrote:
Should we add a memset(buf, 0, sizeof(buf)) before the memcpy() to
prevent information from earlier activities to leak?
buf points to the new
Hi Wolfgang,
On 01/12/2015 08:27 AM, Stefan Roese wrote:
Hi Wolfgang,
On 12.01.2015 08:17, Wolfgang Denk wrote:
The new code is even simpler and copies the source data into the temp
buffer and now uses the temp buffer to write the complete sector. So
only one SPI sector write is used now
Hi Stefan,
On 01/12/2015 08:56 AM, Stefan Roese wrote:
Hi Gerlando,
On 12.01.2015 08:51, Gerlando Falauto wrote:
thanks for the patch.
Please compare it with my v1 revision of the patch:
http://patchwork.ozlabs.org/patch/150468/
Back then, Simon suggested to use two separate SPI flash
Dear Stefan,
In message 54b37759.7040...@denx.de you wrote:
Should we add a memset(buf, 0, sizeof(buf)) before the memcpy() to
prevent information from earlier activities to leak?
buf points to the new data to be written into the flash. We're
overwriting the first len bytes of
Dear Gerlando Falauto,
In message 54b380c2.4050...@keymile.com you wrote:
That's right, and that's the whole point: cmp_buf points to the data
read from the flash sector before erasing it, because that's what we
want to keep (by re-writing it).
The first part, however, we overwrite with
Hi Wolfgang,
On 12.01.2015 22:10, Wolfgang Denk wrote:
Should we add a memset(buf, 0, sizeof(buf)) before the memcpy() to
prevent information from earlier activities to leak?
buf points to the new data to be written into the flash. We're
overwriting the first len bytes of cmp_buf with this
Dear Stefan,
In message 1420810762-10712-1-git-send-email...@denx.de you wrote:
The new code is even simpler and copies the source data into the temp
buffer and now uses the temp buffer to write the complete sector. So
only one SPI sector write is used now instead of 2 in the old version.
...
Hi Wolfgang,
On 12.01.2015 08:17, Wolfgang Denk wrote:
The new code is even simpler and copies the source data into the temp
buffer and now uses the temp buffer to write the complete sector. So
only one SPI sector write is used now instead of 2 in the old version.
...
if (len !=
Hi Stefan,
thanks for the patch.
Please compare it with my v1 revision of the patch:
http://patchwork.ozlabs.org/patch/150468/
Back then, Simon suggested to use two separate SPI flash operations to
avoid the memcpy() operation. I guess noone would have guessed about
QSPI devices at the time.
Hi Gerlando,
On 12.01.2015 08:51, Gerlando Falauto wrote:
thanks for the patch.
Please compare it with my v1 revision of the patch:
http://patchwork.ozlabs.org/patch/150468/
Back then, Simon suggested to use two separate SPI flash operations to
avoid the memcpy() operation.
This again could
On SoCFPGA, using sf update with an non-4byte aligned length leads
to a hangup (and reboot via watchdog). This is because of the unaligned
access in the cadence QSPI driver which is hard to prevent since the
data is written into a 4-byte wide FIFO. This patch fixes this problem
by changing the
13 matches
Mail list logo
