From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marek Vasut <marex@denx.de>
Date: Wed, 30 Mar 2016 14:46:27 +0200
Subject: [U-Boot] Problem with sf write on Arria 5.
In-Reply-To: <BFEE4BD273371E48B6EB70F96CEC5B54040F0AF5@DEMUMBX007.nsn-intra.net>
References: <BFEE4BD273371E48B6EB70F96CEC5B54040F0AF5@DEMUMBX007.nsn-intra.net>
Message-ID: <56FBCAA3.8040106@denx.de>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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