Home
last modified time | relevance | path

Searched hist:"0 df07db408d11cfb65506d894225c26d5d6b4928" (Results 1 – 1 of 1) sorted by relevance

/rk3399_rockchip-uboot/drivers/mtd/spi/
H A Dspi_flash.c0df07db408d11cfb65506d894225c26d5d6b4928 Thu May 24 19:58:40 UTC 2018 Marek Vasut <marex@denx.de> UPSTREAM: sf: Set current flash bank to 0 in clean_bar()

The clean_bar() function resets the SPI NOR BAR register to 0, but
does not set the flash->curr_bar to 0 , therefore those two can get
out of sync, which could ultimatelly result in corrupted flash content.

The simplest test case is this:

=> mw 0x10000000 0x1234abcd 0x4000
=> sf probe
=> sf erase 0x1000000 0x10000
=> sf write 0x10000000 0x1000000 0x10000

=> sf probe ; sf read 0x12000000 0 0x10000 ; md 0x12000000

That is, erase a sector above the 16 MiB boundary and write it with
random pre-configured data. What will actually happen without this
patch is the sector will be erased, but the data will be written to
BAR 0 offset 0x0 in the flash.

This is because the erase command will call write_bar()+clean_bar(),
which will leave flash->bank_curr = 1 while the hardware BAR registers
will be set to 0 through clean_bar(). The subsequent write will also
trigger write_bar()+clean_bar(), but write_bar checks if the target
bank == flash->bank_curr and if so, does NOT reconfigure the BAR in
the SPI NOR. Since flash->bank_curr is still 1 and out of sync with
the HW, the condition matches, BAR programming is skipped and write
ends up at address 0x0, thus corrupting flash content.

Change-Id: Ib8ec33a2b890ee7f1566846172c51254b0388964
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Tom Rini <trini@konsulko.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>
Signed-off-by: Jon Lin <jon.lin@rock-chips.com>
(cherry picked from commit 8ff4130debcc09594b550209c44abf6c7e3ee595)