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

Bakhvalov, Denis (Nokia - PL/Wroclaw) denis.bakhvalov at nokia.com
Wed Mar 30 13:14:22 CEST 2016


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.

All hints are welcome.

Best regards,
Denis Bakhvalov



More information about the U-Boot mailing list