[U-Boot] Problem with sf write on Arria 5.

Marek Vasut marex at denx.de
Wed Mar 30 14:46:27 CEST 2016


On 03/30/2016 01:14 PM, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote:
> Dear U-Boot support,
>  
> I’m migrating to new U-Boot version from 2013 and now have problem with
> writing to the flash.
>  
> I have custom board with Altera Arria 5 SocFpga.
> U-Boot version: 2016.03-rc1
> My flash:
> SF: Detected S25FL512S_256K with page size 512 Bytes, erase size 256
> KiB, total 64 MiB
>  
> I’m rewriting the flash with the image that I downloaded from tftp.
> #> tftp 0x1B000000 flash.bin
> Then I’m trying to write it to the flash:
> #> sf erase …
> #> sf write …
> After that if I try to mount Ubi partition (this is read operation) I
> receive failures (usually checksum errors).
> So, the problem is that when I’m writing some data to flash and reading
> it back the data is corrupted.
> I’m almost sure that there is no issue with reading, because previously
> I was able to read big amount of data successfully (for example, reading
> OS image and booting it).
>  
> With previous version (2013) there is no such issue.
> With the same sequence of commands I was able to update entire flash.
>  
> I was able to reduce this problem to a smaller one.
> I’m checking consistency of write operation by writing zipped file (3 KB):
> #> tftp 0x1B000000 file.zip
> #> sf erase <flash_addr> <flash_offset>
> #> sf write <mem_addr1> <flash_addr> <flash_offset>
> #> sf read <mem_addr2> <flash_addr> <flash_offset>
> #> unzip <mem_addr2> <mem_addr3>
>  
> And sometimes I can see:
> Uncompressed size: 524288 = 0x80000 (success)
> but more often:
> Error: inflate() returned -3 (data was corrupted)
>  
> So, the problem appears to be occasional.
>  
> When I’m comparing the original data with the data that I’ve read from
> flash I can see the blocks of 256 bytes were not written (0xffffffff).
> For example:
> Original data:
> 1b000200: c62e214e 0e48a4c9 19038ec8 37531cfd    N!....H.......S7
> 1b000210: 8f1c7048 f60b861f e9482d5c 857404e8    Hp......\-H...t.
> 1b000220: ef3996c1 fd02b093 2ee8d1f6 679ab03d    ..9.........=..g
> 1b000230: e6c739f4 194eaec7 383ddca8 6f90a2ad    .9....N...=8...o
> … and so on until (1b000300)
> Stored data:
> 1f000200: ffffffff ffffffff ffffffff ffffffff    ................
> 1f000210: ffffffff ffffffff ffffffff ffffffff    ................
> 1f000220: ffffffff ffffffff ffffffff ffffffff    ................
> 1f000230: ffffffff ffffffff ffffffff ffffffff    ................
> … and so on until (1f000300)
>  
> I already checked difference in QSPI registers (base address:
> 0xFF705000) between two versions of U-Boot, but haven’t found any clue yet.
> If needed I can provide this diff.

Do "dcache off" and then update the flash again, it will work. That's
the cache issue which we cannot track down.

Best regards,
Marek Vasut


More information about the U-Boot mailing list