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

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

[Bakhvalov, Denis]

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

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

[Marek Vasut]

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

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

[Bakhvalov, Denis]

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

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

[Chin Liang See]

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

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

[Marek Vasut]

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.

-- 
Best regards,
Marek Vasut

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

[Marek Vasut]

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

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

[Bakhvalov, Denis]

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

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

[Marek Vasut]

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.

-- 
Best regards,
Marek Vasut

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

[Bakhvalov, Denis]

> 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.

Best regards,
Denis Bakhvalov

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

[Marek Vasut]

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.

-- 
Best regards,
Marek Vasut

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

[Bakhvalov, Denis]

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

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

[Marek Vasut]

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:
> 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
> 


-- 
Best regards,
Marek Vasut