[U-Boot] Problem with sf write on Arria 5.
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
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
Hi Marek,
Do "dcache off" and then update the flash again, it will work. That's the cache issue which we cannot track down.
Thank you for you quick support!
Maybe it's worth to invent a temporary solution? Because in other way users will face problems which are hard to find (I've been chasing this problem for 2 days). For example execute "dcache off" internally when sf write is called?
Best regards, Denis Bakhvalov
On Wed, 2016-03-30 at 13:46 +0000, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote:
Hi Marek,
Do "dcache off" and then update the flash again, it will work. That's the cache issue which we cannot track down.
Thank you for you quick support!
Maybe it's worth to invent a temporary solution? Because in other way users will face problems which are hard to find (I've been chasing this problem for 2 days). For example execute "dcache off" internally when sf write is called?
I believe we can turn of the dcache as default for socfpga while effort in progress to figure out the issue.
FYI, I was experimenting with L2 cache PL-310 registers but not successful. I am trying to understand any issue between L2 cache and the SDRAM. There is l2 cache sync after a flush but seems its not working fine. Adding delay works but that not deemed a correct solution (for USB case). Probably doing a virtual memory aliasing might understand where the data was stuck.
Thanks Chin Liang
Best regards, Denis Bakhvalov
On 03/30/2016 03:46 PM, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote:
Hi Marek,
Do "dcache off" and then update the flash again, it will work. That's the cache issue which we cannot track down.
Thank you for you quick support!
Maybe it's worth to invent a temporary solution? Because in other way users will face problems which are hard to find (I've been chasing this problem for 2 days). For example execute "dcache off" internally when sf write is called?
Such "temporary solution" will only root in place and noone will ever fix the real problem anymore. Moreover, the performance hit is really bad if you turn cache off.
On 03/30/2016 03:46 PM, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote:
Hi Marek,
Do "dcache off" and then update the flash again, it will work. That's the cache issue which we cannot track down.
Thank you for you quick support!
Maybe it's worth to invent a temporary solution?
Hi,
you mentioned you have problems with DRAM init on your AV, right ? Try this u-boot-socfpga/ddr branch [1] , see if it works for you and please let me know. The more testing the better.
[1] http://git.denx.de/?p=u-boot/u-boot-socfpga.git;a=shortlog;h=refs/heads/ddr
Best regards, Marek Vasut
Hi Marek,
you mentioned you have problems with DRAM init on your AV, right ? Try this u-boot-socfpga/ddr branch [1] , see if it works for you and please let me know. The more testing the better.
[1] http://git.denx.de/?p=u-boot/u-boot-socfpga.git;a=shortlog;h=refs/heads/ddr
Are you asking me to test problem with writing to the flash without "dcache off", right?
Best regards, Denis Bakhvalov
On 04/07/2016 09:32 AM, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote:
Hi Marek,
you mentioned you have problems with DRAM init on your AV, right ? Try this u-boot-socfpga/ddr branch [1] , see if it works for you and please let me know. The more testing the better.
[1] http://git.denx.de/?p=u-boot/u-boot-socfpga.git;a=shortlog;h=refs/heads/ddr
Are you asking me to test problem with writing to the flash without "dcache off", right?
Just check if the mainline SPL generated from this branch works on your platform please.
On 04/07/2016 02:05 PM, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote:
Just check if the mainline SPL generated from this branch works on your platform please.
Ok. I will test it but probably during the weekend. Because it requires me to merge my configuration to it. I will write back once I will have some results.
You can just apply the ddr: altera: patches on top, they should apply all the way back to at least 2015.10 cleanly. For a quick test, that's enough.
Hi Marek,
Just check if the mainline SPL generated from this branch works on your platform please.
I tested U-boot generated from the branch you specified: U-Boot 2016.03-11349-g5d09125-dirty (Apr 09 2016 - 00:42:24 +0200)
Works pretty well.
All needed functionality works for me. I tested: 1. Mounting ubi partition. 2. Booting kernel from ubi partition. 3. Fpga configuration. 4. Ethernet.
For two more weeks I will have access to the hardware so you can ask for another test if you wish. But in the end of April I will move to another project, so I'm afraid I will not be able to help then.
Best regards, Denis Bakhvalov
On 04/09/2016 01:07 AM, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote:
Hi Marek,
Hi!
Just check if the mainline SPL generated from this branch works on your platform please.
I tested U-boot generated from the branch you specified: U-Boot 2016.03-11349-g5d09125-dirty (Apr 09 2016 - 00:42:24 +0200)
Works pretty well.
Great, thanks.
All needed functionality works for me. I tested:
- Mounting ubi partition.
- Booting kernel from ubi partition.
- Fpga configuration.
- Ethernet.
For two more weeks I will have access to the hardware so you can ask for another test if you wish. But in the end of April I will move to another project, so I'm afraid I will not be able to help then.
Best regards, Denis Bakhvalov
participants (3)
-
Bakhvalov, Denis (Nokia - PL/Wroclaw) -
Chin Liang See -
Marek Vasut