On 06/04/2018 08:35 PM, Jagan Teki wrote: > On Tue, Jun 5, 2018 at 12:02 AM, Marek Vasut <[email protected]> wrote: >> On 06/04/2018 08:03 PM, Jagan Teki wrote: >>> On Fri, May 25, 2018 at 1:28 AM, Marek Vasut <[email protected]> wrote: >>>> 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. >>>> >>>> Signed-off-by: Marek Vasut <[email protected]> >>>> Cc: Jagan Teki <[email protected]> >>>> Cc: Tom Rini <[email protected]> >>> >>> Reviewed-by: Jagan Teki <[email protected]> >>> >>> Applied to u-boot-spi/master >> >> So I presume you see it now ? > > Yes, I understand the issue, thanks.
Excellent -- Best regards, Marek Vasut _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
