Re: [U-Boot] Problem with attaching UBI partition

[Marek Vasut]

On 03/22/2016 02:18 PM, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote:
> Hi
> 
>>> It's I belive in socfpga_common.h and it should be migrated to
>>> socfpga_*_defconfig where it makes sense. Do you want to submit
>>> a patch for this ?
>>
>> I put it in my todo list.
>> Once I will finish with u-boot bringup I will submit the patch.
>> Currently I have Ethernet not working :(  
> 
> Patch was submitted:
> http://lists.denx.de/pipermail/u-boot/2016-March/249392.html

Thanks, next time please CC me on the patches, otherwise I might miss them.

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Problem with attaching UBI partition

[Bakhvalov, Denis (Nokia - PL/Wroclaw)]

Hi

> > It's I belive in socfpga_common.h and it should be migrated to
> > socfpga_*_defconfig where it makes sense. Do you want to submit
> > a patch for this ?
> 
> I put it in my todo list.
> Once I will finish with u-boot bringup I will submit the patch.
> Currently I have Ethernet not working :(  

Patch was submitted:
http://lists.denx.de/pipermail/u-boot/2016-March/249392.html

Best regards,
Denis Bakhvalov
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Problem with attaching UBI partition

[Marek Vasut]

On 03/04/2016 01:24 PM, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote:
> Hi Marek,

Hi,

>>> Currently I have Ethernet not working :(  
>>
>> OK. Do you use the same ethernet controller as ArriaV SoCDK? There are two.
> 
> Yes. I didn't changed that.
> It is gmac1: ethernet@ff702000.
> 
> I already started new topic for that problem here:
> http://lists.denx.de/pipermail/u-boot/2016-March/247290.html
> Let's continue discussion there. :)

OK

Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Problem with attaching UBI partition

[Bakhvalov, Denis (Nokia - PL/Wroclaw)]

Hi Marek,

> > Currently I have Ethernet not working :(  
>
> OK. Do you use the same ethernet controller as ArriaV SoCDK? There are two.

Yes. I didn't changed that.
It is gmac1: ethernet@ff702000.

I already started new topic for that problem here:
http://lists.denx.de/pipermail/u-boot/2016-March/247290.html
Let's continue discussion there. :)

Best regards,
Denis Bakhvalov

MBB Radio Platforms, RFSW


-Original Message-
From: EXT Marek Vasut [mailto:ma...@denx.de] 
Sent: Friday, March 04, 2016 13:20
To: Bakhvalov, Denis (Nokia - PL/Wroclaw) <denis.bakhva...@nokia.com>; EXT 
Jagan Teki <jt...@openedev.com>
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] Problem with attaching UBI partition

On 03/04/2016 10:03 AM, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote:
> Hi Marek,

Hi,

>> It's I belive in socfpga_common.h and it should be migrated to
>> socfpga_*_defconfig where it makes sense. Do you want to submit
>> a patch for this ?
> 
> I put it in my todo list.
> Once I will finish with u-boot bringup I will submit the patch.
> Currently I have Ethernet not working :(  

OK. Do you use the same ethernet controller as ArriaV SoCDK? There are two.

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Problem with attaching UBI partition

[Marek Vasut]

On 03/04/2016 10:03 AM, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote:
> Hi Marek,

Hi,

>> It's I belive in socfpga_common.h and it should be migrated to
>> socfpga_*_defconfig where it makes sense. Do you want to submit
>> a patch for this ?
> 
> I put it in my todo list.
> Once I will finish with u-boot bringup I will submit the patch.
> Currently I have Ethernet not working :(  

OK. Do you use the same ethernet controller as ArriaV SoCDK? There are two.

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Problem with attaching UBI partition

[Bakhvalov, Denis (Nokia - PL/Wroclaw)]

Hi Marek,

> It's I belive in socfpga_common.h and it should be migrated to
> socfpga_*_defconfig where it makes sense. Do you want to submit
> a patch for this ?

I put it in my todo list.
Once I will finish with u-boot bringup I will submit the patch.
Currently I have Ethernet not working :(  

Best regards,
Denis Bakhvalov
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Problem with attaching UBI partition

[Marek Vasut]

On 03/03/2016 12:51 PM, Stefan Roese wrote:
> Hi Chin Liang,
> 
> On 02.03.2016 13:24, Chin Liang See wrote:
>>> On 01.03.2016 14:38, Chin Liang See wrote:
 On Tue, 2016-03-01 at 08:23 +0100, Stefan Roese wrote:
> On 01.03.2016 07:53, Chin Liang See wrote:
>> On Mon, 2016-02-29 at 23:55 +0100, Marek Vasut wrote:
>>> On 02/24/2016 09:59 AM, Bakhvalov, Denis (Nokia - PL/Wroclaw)
>>> wrote:
 Hello Heiko,

> Which U-Boot version? Which board?

 This is U-Boot v2016.03-rc1. I have custom board with
 socfpga
 Arria5
 onboard.

> Where does this leading 0xff come from? There seems a
> problem
> with
> your spi nor flash driver?

 Yes, you're right. I have problems with the driver. As I
 mentioned
 in
 previous mail when I read the contents from the flash some
 data
 is
 corrupted.

 How to find out if the problem is because U-Boot has no
 support
 for
 my flash (Spansion S25FL512S NOR flash with SPI) or I have
 not
 proper
 configured SPI in U-Boot?
>>>
>>> I believe there is a problem with caches , which we still
>>> didn't
>>> identify. CCing Dinh and Chin, as they were the last ones
>>> looking
>>> into this problem.
>>>
>>> For now, try doing "dcache off" before using the QSPI NOR.
>>>
>>
>> We managed to get it work for socfpga. One of the issue dragged
>> me
>> long
>> is the CONFIG_SPI_FLASH_USE_4K_SECTORS. Need to ensure its not
>> defined
>> in the defconfig. Hope it helps
>
> This is not clear to me. You mean you were able to reproduce and
> solve this cache (S-bit) related issue by disabling
> CONFIG_SPI_FLASH_USE_4K_SECTORS? This option is disabled for all
> SoCFPGA board in mainline.
>
> Could you please explain in more details what exactly you did to
> solve this issue on SPI NOR?
>

 Nope, I am not replicating the issue. My board is having Micron
 instead
 of Spansion flash. In previously, CONFIG_SPI_FLASH_USE_4K_SECTORS
 is
 defined in socfpga as most serial NOR flash are supporting 4k sub
 sector. With that, it would be good to ensure the 4K is undefined.

 In this case, wonder any details on the failure? Intermittent?
>>>
>>> I think we are talking about different things here. I'm referring
>>> to Marek mentioning the cache problem (S-bit related) on current
>>> SoCFPGA U-Boot mainline. With caches enabled you can experience
>>> problems on QSPI and on USB (reported from Marek - I didn't test
>>> USB yet).
>>>
>>
>> For QSPI, wonder the issue is on the read or write?
> 
> I'm not 100% sure here if this never happens on read. But it definitely
> happens on write. saveeenv to SPI NOR causes serious problems here
> for example.
>  
>>> So do you have any updated on this cache / S-bit problem?
>>
>> I am still debugging this as I notice the hub is not able to detect the
>> mass storage. This is only for certain pen drive.
>>
>>> Or can you
>>> use QSPI NOR without any issues on current mainline U-Boot with
>>> caches enabled on your platforms?
>>>
>>
>> The issue I have is on USB only. For NOR, I can ubifsmount and
>> ubifsload with Micron NOR flash without issue. This is with dcache
>> enabled
> 
> Strange. I have Micron here on the SR1500 as well:
> 
> => sf probe 
> SF: Detected N25Q128 with page size 256 Bytes, erase size 64 KiB, total 16 MiB
> 
> Thanks,
> Stefan
> 

The testcase is that you write some 8 MiB or so of data into the SPI
NOR. Upon read-back, you will notice that the last two or so bytes of
some sectors were not written completely and are corrupted.

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Problem with attaching UBI partition

[Stefan Roese]

Hi Chin Liang,

On 02.03.2016 13:24, Chin Liang See wrote:
>> On 01.03.2016 14:38, Chin Liang See wrote:
>>> On Tue, 2016-03-01 at 08:23 +0100, Stefan Roese wrote:
 On 01.03.2016 07:53, Chin Liang See wrote:
> On Mon, 2016-02-29 at 23:55 +0100, Marek Vasut wrote:
>> On 02/24/2016 09:59 AM, Bakhvalov, Denis (Nokia - PL/Wroclaw)
>> wrote:
>>> Hello Heiko,
>>>
 Which U-Boot version? Which board?
>>>
>>> This is U-Boot v2016.03-rc1. I have custom board with
>>> socfpga
>>> Arria5
>>> onboard.
>>>
 Where does this leading 0xff come from? There seems a
 problem
 with
 your spi nor flash driver?
>>>
>>> Yes, you're right. I have problems with the driver. As I
>>> mentioned
>>> in
>>> previous mail when I read the contents from the flash some
>>> data
>>> is
>>> corrupted.
>>>
>>> How to find out if the problem is because U-Boot has no
>>> support
>>> for
>>> my flash (Spansion S25FL512S NOR flash with SPI) or I have
>>> not
>>> proper
>>> configured SPI in U-Boot?
>>
>> I believe there is a problem with caches , which we still
>> didn't
>> identify. CCing Dinh and Chin, as they were the last ones
>> looking
>> into this problem.
>>
>> For now, try doing "dcache off" before using the QSPI NOR.
>>
>
> We managed to get it work for socfpga. One of the issue dragged
> me
> long
> is the CONFIG_SPI_FLASH_USE_4K_SECTORS. Need to ensure its not
> defined
> in the defconfig. Hope it helps

 This is not clear to me. You mean you were able to reproduce and
 solve this cache (S-bit) related issue by disabling
 CONFIG_SPI_FLASH_USE_4K_SECTORS? This option is disabled for all
 SoCFPGA board in mainline.

 Could you please explain in more details what exactly you did to
 solve this issue on SPI NOR?

>>>
>>> Nope, I am not replicating the issue. My board is having Micron
>>> instead
>>> of Spansion flash. In previously, CONFIG_SPI_FLASH_USE_4K_SECTORS
>>> is
>>> defined in socfpga as most serial NOR flash are supporting 4k sub
>>> sector. With that, it would be good to ensure the 4K is undefined.
>>>
>>> In this case, wonder any details on the failure? Intermittent?
>>
>> I think we are talking about different things here. I'm referring
>> to Marek mentioning the cache problem (S-bit related) on current
>> SoCFPGA U-Boot mainline. With caches enabled you can experience
>> problems on QSPI and on USB (reported from Marek - I didn't test
>> USB yet).
>>
> 
> For QSPI, wonder the issue is on the read or write?

I'm not 100% sure here if this never happens on read. But it definitely
happens on write. saveeenv to SPI NOR causes serious problems here
for example.
 
>> So do you have any updated on this cache / S-bit problem?
> 
> I am still debugging this as I notice the hub is not able to detect the
> mass storage. This is only for certain pen drive.
> 
>> Or can you
>> use QSPI NOR without any issues on current mainline U-Boot with
>> caches enabled on your platforms?
>>
> 
> The issue I have is on USB only. For NOR, I can ubifsmount and
> ubifsload with Micron NOR flash without issue. This is with dcache
> enabled

Strange. I have Micron here on the SR1500 as well:

=> sf probe 
SF: Detected N25Q128 with page size 256 Bytes, erase size 64 KiB, total 16 MiB

Thanks,
Stefan

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Problem with attaching UBI partition

[Chin Liang See]

On Tue, 2016-03-01 at 16:35 +0100, Stefan Roese wrote:
> Hi!

Hi Stefan,

> 
> (adding Marek to Cc again)
> 
> On 01.03.2016 14:38, Chin Liang See wrote:
> > On Tue, 2016-03-01 at 08:23 +0100, Stefan Roese wrote:
> > > On 01.03.2016 07:53, Chin Liang See wrote:
> > > > On Mon, 2016-02-29 at 23:55 +0100, Marek Vasut wrote:
> > > > > On 02/24/2016 09:59 AM, Bakhvalov, Denis (Nokia - PL/Wroclaw)
> > > > > wrote:
> > > > > > Hello Heiko,
> > > > > > 
> > > > > > > Which U-Boot version? Which board?
> > > > > > 
> > > > > > This is U-Boot v2016.03-rc1. I have custom board with
> > > > > > socfpga
> > > > > > Arria5
> > > > > > onboard.
> > > > > > 
> > > > > > > Where does this leading 0xff come from? There seems a
> > > > > > > problem
> > > > > > > with
> > > > > > > your spi nor flash driver?
> > > > > > 
> > > > > > Yes, you're right. I have problems with the driver. As I
> > > > > > mentioned
> > > > > > in
> > > > > > previous mail when I read the contents from the flash some
> > > > > > data
> > > > > > is
> > > > > > corrupted.
> > > > > > 
> > > > > > How to find out if the problem is because U-Boot has no
> > > > > > support
> > > > > > for
> > > > > > my flash (Spansion S25FL512S NOR flash with SPI) or I have
> > > > > > not
> > > > > > proper
> > > > > > configured SPI in U-Boot?
> > > > > 
> > > > > I believe there is a problem with caches , which we still
> > > > > didn't
> > > > > identify. CCing Dinh and Chin, as they were the last ones
> > > > > looking
> > > > > into this problem.
> > > > > 
> > > > > For now, try doing "dcache off" before using the QSPI NOR.
> > > > > 
> > > > 
> > > > We managed to get it work for socfpga. One of the issue dragged
> > > > me
> > > > long
> > > > is the CONFIG_SPI_FLASH_USE_4K_SECTORS. Need to ensure its not
> > > > defined
> > > > in the defconfig. Hope it helps
> > > 
> > > This is not clear to me. You mean you were able to reproduce and
> > > solve this cache (S-bit) related issue by disabling
> > > CONFIG_SPI_FLASH_USE_4K_SECTORS? This option is disabled for all
> > > SoCFPGA board in mainline.
> > > 
> > > Could you please explain in more details what exactly you did to
> > > solve this issue on SPI NOR?
> > > 
> > 
> > Nope, I am not replicating the issue. My board is having Micron
> > instead
> > of Spansion flash. In previously, CONFIG_SPI_FLASH_USE_4K_SECTORS
> > is
> > defined in socfpga as most serial NOR flash are supporting 4k sub
> > sector. With that, it would be good to ensure the 4K is undefined.
> > 
> > In this case, wonder any details on the failure? Intermittent?
> 
> I think we are talking about different things here. I'm referring
> to Marek mentioning the cache problem (S-bit related) on current
> SoCFPGA U-Boot mainline. With caches enabled you can experience
> problems on QSPI and on USB (reported from Marek - I didn't test
> USB yet).
> 

For QSPI, wonder the issue is on the read or write?

> So do you have any updated on this cache / S-bit problem? 

I am still debugging this as I notice the hub is not able to detect the
mass storage. This is only for certain pen drive.

> Or can you
> use QSPI NOR without any issues on current mainline U-Boot with
> caches enabled on your platforms?
> 

The issue I have is on USB only. For NOR, I can ubifsmount and
ubifsload with Micron NOR flash without issue. This is with dcache
enabled

Thanks
Chin Liang



> Thanks,
> Stefan
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Problem with attaching UBI partition

[Jagan Teki]

Hi Denis,

On 1 March 2016 at 18:34, Bakhvalov, Denis (Nokia - PL/Wroclaw)
 wrote:
> Hi Marek,
>
>>Try enabling CONFIG_SPI_FLASH_BAR in your board config ;-)
>
> That solved my issue.
> Thank you very much.
> I removed workaround from the code.

Sorry, I couldn't understand the issue nor what you solved? because,
socfpga_arria5_defconfig by default have CONFIG_SPI_FLASH_BAR enabled
and even sf probe looks no warning for enabling the same. If you
haven't enable CONFIG_SPI_FLASH_BAR then spi_flash core will give
warning while doing 'sf probe'

+ SF: Detected S25FL512S_256K with page size 512 Bytes, erase size 256
KiB, total 64 MiB

this will show something like

SF: Detected S25FL512S_256K with page size 512 Bytes, erase size 256
KiB, total 64 MiB
SF: Warning - Only lower 16MiB accessible, Full access #define
CONFIG_SPI_FLASH_BAR

thanks!
-- 
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Problem with attaching UBI partition

[Stefan Roese]

Hi!

(adding Marek to Cc again)

On 01.03.2016 14:38, Chin Liang See wrote:

On Tue, 2016-03-01 at 08:23 +0100, Stefan Roese wrote:

On 01.03.2016 07:53, Chin Liang See wrote:

On Mon, 2016-02-29 at 23:55 +0100, Marek Vasut wrote:

On 02/24/2016 09:59 AM, Bakhvalov, Denis (Nokia - PL/Wroclaw)
wrote:

Hello Heiko,


Which U-Boot version? Which board?


This is U-Boot v2016.03-rc1. I have custom board with socfpga
Arria5
onboard.


Where does this leading 0xff come from? There seems a problem
with
your spi nor flash driver?


Yes, you're right. I have problems with the driver. As I
mentioned
in
previous mail when I read the contents from the flash some data
is
corrupted.

How to find out if the problem is because U-Boot has no support
for
my flash (Spansion S25FL512S NOR flash with SPI) or I have not
proper
configured SPI in U-Boot?


I believe there is a problem with caches , which we still didn't
identify. CCing Dinh and Chin, as they were the last ones looking
into this problem.

For now, try doing "dcache off" before using the QSPI NOR.



We managed to get it work for socfpga. One of the issue dragged me
long
is the CONFIG_SPI_FLASH_USE_4K_SECTORS. Need to ensure its not
defined
in the defconfig. Hope it helps


This is not clear to me. You mean you were able to reproduce and
solve this cache (S-bit) related issue by disabling
CONFIG_SPI_FLASH_USE_4K_SECTORS? This option is disabled for all
SoCFPGA board in mainline.

Could you please explain in more details what exactly you did to
solve this issue on SPI NOR?



Nope, I am not replicating the issue. My board is having Micron instead
of Spansion flash. In previously, CONFIG_SPI_FLASH_USE_4K_SECTORS is
defined in socfpga as most serial NOR flash are supporting 4k sub
sector. With that, it would be good to ensure the 4K is undefined.

In this case, wonder any details on the failure? Intermittent?


I think we are talking about different things here. I'm referring
to Marek mentioning the cache problem (S-bit related) on current
SoCFPGA U-Boot mainline. With caches enabled you can experience
problems on QSPI and on USB (reported from Marek - I didn't test
USB yet).

So do you have any updated on this cache / S-bit problem? Or can you
use QSPI NOR without any issues on current mainline U-Boot with
caches enabled on your platforms?

Thanks,
Stefan

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Problem with attaching UBI partition

[Marek Vasut]

On 03/01/2016 02:53 PM, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote:
> Hi Jagan,
> 
>> Sorry, I couldn't understand the issue nor what you solved? because,
>> socfpga_arria5_defconfig by default have CONFIG_SPI_FLASH_BAR enabled
>> and even sf probe looks no warning for enabling the same. If you
>> haven't enable CONFIG_SPI_FLASH_BAR then spi_flash core will give
>> warning while doing 'sf probe'
> 
> I can see that for 2016.03-rc1 CONFIG_SPI_FLASH_BAR is not present in 
> socfpga_arria5_defconfig.
> 
> Best regards,
> Denis Bakhvalov
> 

It's I belive in socfpga_common.h and it should be migrated to
socfpga_*_defconfig where it makes sense. Do you want to submit
a patch for this ?

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Problem with attaching UBI partition

[Marek Vasut]

On 03/01/2016 02:04 PM, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote:
> Hi Marek,
> 
>> Try enabling CONFIG_SPI_FLASH_BAR in your board config ;-)
> 
> That solved my issue.
> Thank you very much.
> I removed workaround from the code.
> 
> Best regards,
> Denis Bakhvalov
> 
Yay :-)

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Problem with attaching UBI partition

[Bakhvalov, Denis (Nokia - PL/Wroclaw)]

Hi Jagan,

> Sorry, I couldn't understand the issue nor what you solved? because,
> socfpga_arria5_defconfig by default have CONFIG_SPI_FLASH_BAR enabled
> and even sf probe looks no warning for enabling the same. If you
> haven't enable CONFIG_SPI_FLASH_BAR then spi_flash core will give
> warning while doing 'sf probe'

I can see that for 2016.03-rc1 CONFIG_SPI_FLASH_BAR is not present in 
socfpga_arria5_defconfig.

Best regards,
Denis Bakhvalov
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Problem with attaching UBI partition

[Chin Liang See]

On Tue, 2016-03-01 at 08:23 +0100, Stefan Roese wrote:
> On 01.03.2016 07:53, Chin Liang See wrote:
> > On Mon, 2016-02-29 at 23:55 +0100, Marek Vasut wrote:
> > > On 02/24/2016 09:59 AM, Bakhvalov, Denis (Nokia - PL/Wroclaw)
> > > wrote:
> > > > Hello Heiko,
> > > > 
> > > > > Which U-Boot version? Which board?
> > > > 
> > > > This is U-Boot v2016.03-rc1. I have custom board with socfpga
> > > > Arria5
> > > > onboard.
> > > > 
> > > > > Where does this leading 0xff come from? There seems a problem
> > > > > with
> > > > > your spi nor flash driver?
> > > > 
> > > > Yes, you're right. I have problems with the driver. As I
> > > > mentioned
> > > > in
> > > > previous mail when I read the contents from the flash some data
> > > > is
> > > > corrupted.
> > > > 
> > > > How to find out if the problem is because U-Boot has no support
> > > > for
> > > > my flash (Spansion S25FL512S NOR flash with SPI) or I have not
> > > > proper
> > > > configured SPI in U-Boot?
> > > 
> > > I believe there is a problem with caches , which we still didn't
> > > identify. CCing Dinh and Chin, as they were the last ones looking
> > > into this problem.
> > > 
> > > For now, try doing "dcache off" before using the QSPI NOR.
> > > 
> > 
> > We managed to get it work for socfpga. One of the issue dragged me
> > long
> > is the CONFIG_SPI_FLASH_USE_4K_SECTORS. Need to ensure its not
> > defined
> > in the defconfig. Hope it helps
> 
> This is not clear to me. You mean you were able to reproduce and
> solve this cache (S-bit) related issue by disabling
> CONFIG_SPI_FLASH_USE_4K_SECTORS? This option is disabled for all
> SoCFPGA board in mainline.
> 
> Could you please explain in more details what exactly you did to
> solve this issue on SPI NOR?
> 

Nope, I am not replicating the issue. My board is having Micron instead
of Spansion flash. In previously, CONFIG_SPI_FLASH_USE_4K_SECTORS is
defined in socfpga as most serial NOR flash are supporting 4k sub
sector. With that, it would be good to ensure the 4K is undefined.

In this case, wonder any details on the failure? Intermittent?

Thanks
Chin Liang

> Thanks,
> Stefan
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Problem with attaching UBI partition

[Bakhvalov, Denis (Nokia - PL/Wroclaw)]

Hi Marek,

>Try enabling CONFIG_SPI_FLASH_BAR in your board config ;-)

That solved my issue.
Thank you very much.
I removed workaround from the code.

Best regards,
Denis Bakhvalov
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Problem with attaching UBI partition

[Stefan Roese]

On 01.03.2016 07:53, Chin Liang See wrote:

On Mon, 2016-02-29 at 23:55 +0100, Marek Vasut wrote:

On 02/24/2016 09:59 AM, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote:

Hello Heiko,


Which U-Boot version? Which board?


This is U-Boot v2016.03-rc1. I have custom board with socfpga
Arria5
onboard.


Where does this leading 0xff come from? There seems a problem
with
your spi nor flash driver?


Yes, you're right. I have problems with the driver. As I mentioned
in
previous mail when I read the contents from the flash some data is
corrupted.

How to find out if the problem is because U-Boot has no support for
my flash (Spansion S25FL512S NOR flash with SPI) or I have not
proper
configured SPI in U-Boot?


I believe there is a problem with caches , which we still didn't
identify. CCing Dinh and Chin, as they were the last ones looking
into this problem.

For now, try doing "dcache off" before using the QSPI NOR.



We managed to get it work for socfpga. One of the issue dragged me long
is the CONFIG_SPI_FLASH_USE_4K_SECTORS. Need to ensure its not defined
in the defconfig. Hope it helps


This is not clear to me. You mean you were able to reproduce and
solve this cache (S-bit) related issue by disabling
CONFIG_SPI_FLASH_USE_4K_SECTORS? This option is disabled for all
SoCFPGA board in mainline.

Could you please explain in more details what exactly you did to
solve this issue on SPI NOR?

Thanks,
Stefan

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Problem with attaching UBI partition

[Chin Liang See]

On Mon, 2016-02-29 at 23:55 +0100, Marek Vasut wrote:
> On 02/24/2016 09:59 AM, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote:
> > Hello Heiko,
> > 
> > > Which U-Boot version? Which board?
> > 
> > This is U-Boot v2016.03-rc1. I have custom board with socfpga
> > Arria5
> > onboard.
> > 
> > > Where does this leading 0xff come from? There seems a problem
> > > with
> > > your spi nor flash driver?
> > 
> > Yes, you're right. I have problems with the driver. As I mentioned
> > in
> > previous mail when I read the contents from the flash some data is
> > corrupted.
> > 
> > How to find out if the problem is because U-Boot has no support for
> > my flash (Spansion S25FL512S NOR flash with SPI) or I have not
> > proper
> > configured SPI in U-Boot?
> 
> I believe there is a problem with caches , which we still didn't
> identify. CCing Dinh and Chin, as they were the last ones looking
> into this problem.
> 
> For now, try doing "dcache off" before using the QSPI NOR.
> 

We managed to get it work for socfpga. One of the issue dragged me long
is the CONFIG_SPI_FLASH_USE_4K_SECTORS. Need to ensure its not defined
in the defconfig. Hope it helps

Thanks
Chin Liang

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Problem with attaching UBI partition

[Marek Vasut]

On 02/24/2016 09:59 AM, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote:
> Hello Heiko,
> 
>> Which U-Boot version? Which board?
> 
> This is U-Boot v2016.03-rc1. I have custom board with socfpga Arria5
> onboard.
> 
>> Where does this leading 0xff come from? There seems a problem with
>> your spi nor flash driver?
> 
> Yes, you're right. I have problems with the driver. As I mentioned in
> previous mail when I read the contents from the flash some data is
> corrupted.
> 
> How to find out if the problem is because U-Boot has no support for
> my flash (Spansion S25FL512S NOR flash with SPI) or I have not proper
> configured SPI in U-Boot?

I believe there is a problem with caches , which we still didn't
identify. CCing Dinh and Chin, as they were the last ones looking
into this problem.

For now, try doing "dcache off" before using the QSPI NOR.

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Problem with attaching UBI partition

[Marek Vasut]

On 02/29/2016 05:44 PM, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote:
> Hi Jagan, Heiko,
> 
>> Did you enable CONFIG_SPI_FLASH_SPANSION on your config, becuase
>> S25FL512S is already been added u-boot. Pls- check the same and let me
>> know if you find any issues while detecting the flash.
> 
>> Whether the driver detecting flash or not with RDID, please define
>> DEBUG on drivers/mtd/spi/spi_flash.c
> 
> I had no problems with detecting the flash. It was detected like this:
> SF: Detected S25FL512S_256K with page size 512 Bytes, erase size 256 KiB, 
> total 64 MiB
> 
> Yes, I have CONFIG_SPI_FLASH_SPANSION enabled in 
> configs/socfpga_arria5_dbrrh_defconfig (dbrrh - is my custom board).
> 
> Actually, today I solved the problem, although in not very clean way, I think.
> 
> As I mentioned in previous mail I had problems with reading from the flash. 
> Some bytes were read incorrectly.
> I'm migrating from U-Boot 2013 to mainline U-Boot. And on previous version 
> there were no such issue.
> I found out that there was some workaround introduced in order to fix this.
> 
> So, I just apply some part of that workaround to mainline U-Boot and now it 
> works.
> 
> Here is the problem in more detail:
> 
> On previous version (2013):
> U-BOOT # sf read 0x1B00 0x0380 4
>  cadence_qspi_apb_indirect_read_setup. addr_value = 0x380
>  cadence_qspi_apb_indirect_read_setup. rd_reg = 0x80b
>  cadence_qspi_apb_indirect_read_setup. device size = 0x101003
> 
> U-BOOT # md 0x1B00 1
> 1b00: 55424923
> 
> But on mainline U-Boot(2016.03-rc1) I had:
> U-BOOT # sf read 0x1B00 0x0380 4
>  cadence_qspi_apb_indirect_read_setup. addr_value = 0x80
>  cadence_qspi_apb_indirect_read_setup. rd_reg = 0x0b
>  cadence_qspi_apb_indirect_read_setup. device size = 0x101002
> 
> U-BOOT # md 0x1B00 1
> 1b00: 554249ff
> 
> You can see the difference in the register values that were written in QSPI 
> registers.
> In case with mainline U-Boot I had address value not properly set.
> 
> Here is the workaround that I've made:
> 
> Index: drivers/mtd/spi/spi_flash.c
> ===
> --- drivers/mtd/spi/spi_flash.c   (revision 608)
> +++ drivers/mtd/spi/spi_flash.c   (revision 609)
> @@ -29,6 +29,17 @@
>   cmd[3] = addr >> 0;
>  }
>  
> +#ifdef CONFIG_DBRRH_WORKAROUND
> +static void spi_flash_addr32(u32 addr, u8 *cmd)
> +{
> + /* cmd[0] is actual command */
> + cmd[1] = (addr >> 24) & 0xFF;
> + cmd[2] = (addr >> 16) & 0xFF;
> + cmd[3] = (addr >> 8) & 0xFF;
> + cmd[4] = (addr >> 0) & 0xFF;
> +}
> +#endif
> +
>  static int read_sr(struct spi_flash *flash, u8 *rs)
>  {
>   int ret;
> @@ -510,8 +521,14 @@
>   else
>   read_len = remain_len;
>  
> +#ifdef CONFIG_DBRRH_WORKAROUND
> + spi_flash_addr32(read_addr, cmd);
> +#else
>   spi_flash_addr(read_addr, cmd);
> +#endif
>  
>   ret = spi_flash_read_common(flash, cmd, cmdsz, data, read_len);
>   if (ret < 0) {
>   debug("SF: read failed\n");
> 
> Index: drivers/spi/cadence_qspi_apb.c
> ===
> --- drivers/spi/cadence_qspi_apb.c(revision 608)
> +++ drivers/spi/cadence_qspi_apb.c(revision 609)
> @@ -30,6 +30,10 @@
>  #include 
>  #include "cadence_qspi.h"
>  
> +#ifdef CONFIG_DBRRH_WORKAROUND
> + #define CMD_OPTION_DUMMY_CYCLES 0x7F/* Dummy Cycles for 
> Read Command */
> +#endif
> +
> @@ -706,9 +710,25 @@
>  #endif
>  
>   /* Get address */
> +#ifdef CONFIG_DBRRH_WORKAROUND
> + addr_value = cadence_qspi_apb_cmd2addr([1], 4);
> +#else
>   addr_value = cadence_qspi_apb_cmd2addr([1], addr_bytes);
> +#endif
> 
> +#ifdef CONFIG_DBRRH_WORKAROUND
> + /* Setting Dummy Clock Cycle */
> + dummy_clk = (0x08 & CMD_OPTION_DUMMY_CYCLES);
> + if (dummy_clk) 
> + {
> + rd_reg |= (dummy_clk & CQSPI_REG_RD_INSTR_DUMMY_MASK)
> + << CQSPI_REG_RD_INSTR_DUMMY_LSB;
> + }
> +#else
> +
>   /* The remaining lenght is dummy bytes. */
>   dummy_bytes = cmdlen - addr_bytes - 1;
>   if (dummy_bytes) {
> @@ -731,7 +751,9 @@
>   rd_reg |= (dummy_clk & CQSPI_REG_RD_INSTR_DUMMY_MASK)
>   << CQSPI_REG_RD_INSTR_DUMMY_LSB;
>   }
> +#endif
> 
> 
> With this correction I can read contents of the flash properly.
> However, I'm a bit surprised that I was forced to make such correction like 
> storing 4 bytes of address (see spi_flash_addr32() above).
> On the other hand I haven't found any switch that could be turned on to fix 
> my problem in a clean and nice way.
> 
> With 24 bytes we can address only 16 MB. How cadence driver is supposed to 
> work for larger spaces?
> Is this 4th byte comes from somewhere else?
> 
> Jagan, Heiko, please 

Re: [U-Boot] Problem with attaching UBI partition

[Jagan Teki]

+ Marek

On 29 February 2016 at 22:14, Bakhvalov, Denis (Nokia - PL/Wroclaw)
 wrote:
> Hi Jagan, Heiko,
>
>> Did you enable CONFIG_SPI_FLASH_SPANSION on your config, becuase
>> S25FL512S is already been added u-boot. Pls- check the same and let me
>> know if you find any issues while detecting the flash.
>
>> Whether the driver detecting flash or not with RDID, please define
>> DEBUG on drivers/mtd/spi/spi_flash.c
>
> I had no problems with detecting the flash. It was detected like this:
> SF: Detected S25FL512S_256K with page size 512 Bytes, erase size 256 KiB, 
> total 64 MiB

So, the flash size is > 32MiB means, your config enabled BAR(Bank
address register) which means accessing flash more than 16MiB using
3-byte addressing support.

>
> Yes, I have CONFIG_SPI_FLASH_SPANSION enabled in 
> configs/socfpga_arria5_dbrrh_defconfig (dbrrh - is my custom board).
>
> Actually, today I solved the problem, although in not very clean way, I think.
>
> As I mentioned in previous mail I had problems with reading from the flash. 
> Some bytes were read incorrectly.
> I'm migrating from U-Boot 2013 to mainline U-Boot. And on previous version 
> there were no such issue.
> I found out that there was some workaround introduced in order to fix this.
>
> So, I just apply some part of that workaround to mainline U-Boot and now it 
> works.
>
> Here is the problem in more detail:
>
> On previous version (2013):
> U-BOOT # sf read 0x1B00 0x0380 4
>  cadence_qspi_apb_indirect_read_setup. addr_value = 0x380
>  cadence_qspi_apb_indirect_read_setup. rd_reg = 0x80b
>  cadence_qspi_apb_indirect_read_setup. device size = 0x101003
>
> U-BOOT # md 0x1B00 1
> 1b00: 55424923
>
> But on mainline U-Boot(2016.03-rc1) I had:
> U-BOOT # sf read 0x1B00 0x0380 4
>  cadence_qspi_apb_indirect_read_setup. addr_value = 0x80
>  cadence_qspi_apb_indirect_read_setup. rd_reg = 0x0b
>  cadence_qspi_apb_indirect_read_setup. device size = 0x101002
>
> U-BOOT # md 0x1B00 1
> 1b00: 554249ff
>
> You can see the difference in the register values that were written in QSPI 
> registers.
> In case with mainline U-Boot I had address value not properly set.
>
> Here is the workaround that I've made:
>
> Index: drivers/mtd/spi/spi_flash.c
> ===
> --- drivers/mtd/spi/spi_flash.c (revision 608)
> +++ drivers/mtd/spi/spi_flash.c (revision 609)
> @@ -29,6 +29,17 @@
> cmd[3] = addr >> 0;
>  }
>
> +#ifdef CONFIG_DBRRH_WORKAROUND
> +static void spi_flash_addr32(u32 addr, u8 *cmd)
> +{
> +   /* cmd[0] is actual command */
> +   cmd[1] = (addr >> 24) & 0xFF;
> +   cmd[2] = (addr >> 16) & 0xFF;
> +   cmd[3] = (addr >> 8) & 0xFF;
> +   cmd[4] = (addr >> 0) & 0xFF;
> +}
> +#endif
> +
>  static int read_sr(struct spi_flash *flash, u8 *rs)
>  {
> int ret;
> @@ -510,8 +521,14 @@
> else
> read_len = remain_len;
>
> +#ifdef CONFIG_DBRRH_WORKAROUND
> +   spi_flash_addr32(read_addr, cmd);
> +#else
> spi_flash_addr(read_addr, cmd);
> +#endif
>
> ret = spi_flash_read_common(flash, cmd, cmdsz, data, 
> read_len);
> if (ret < 0) {
> debug("SF: read failed\n");
>
> Index: drivers/spi/cadence_qspi_apb.c
> ===
> --- drivers/spi/cadence_qspi_apb.c  (revision 608)
> +++ drivers/spi/cadence_qspi_apb.c  (revision 609)
> @@ -30,6 +30,10 @@
>  #include 
>  #include "cadence_qspi.h"
>
> +#ifdef CONFIG_DBRRH_WORKAROUND
> +   #define CMD_OPTION_DUMMY_CYCLES 0x7F/* Dummy Cycles for 
> Read Command */
> +#endif
> +
> @@ -706,9 +710,25 @@
>  #endif
>
> /* Get address */
> +#ifdef CONFIG_DBRRH_WORKAROUND
> +   addr_value = cadence_qspi_apb_cmd2addr([1], 4);
> +#else
> addr_value = cadence_qspi_apb_cmd2addr([1], addr_bytes);
> +#endif
>
> +#ifdef CONFIG_DBRRH_WORKAROUND
> +   /* Setting Dummy Clock Cycle */
> +   dummy_clk = (0x08 & CMD_OPTION_DUMMY_CYCLES);
> +   if (dummy_clk)
> +   {
> +   rd_reg |= (dummy_clk & CQSPI_REG_RD_INSTR_DUMMY_MASK)
> +   << CQSPI_REG_RD_INSTR_DUMMY_LSB;
> +   }
> +#else
> +
> /* The remaining lenght is dummy bytes. */
> dummy_bytes = cmdlen - addr_bytes - 1;
> if (dummy_bytes) {
> @@ -731,7 +751,9 @@
> rd_reg |= (dummy_clk & CQSPI_REG_RD_INSTR_DUMMY_MASK)
> << CQSPI_REG_RD_INSTR_DUMMY_LSB;
> }
> +#endif
>
>
> With this correction I can read contents of the flash properly.
> However, I'm a bit surprised that I was forced to make such correction like 
> storing 4 bytes of address (see spi_flash_addr32() above).

Instead of 4-byte addressing, u-boot using only 3-byte addressing with
BAR support for accessing 

Re: [U-Boot] Problem with attaching UBI partition

[Bakhvalov, Denis (Nokia - PL/Wroclaw)]

Hi Jagan, Heiko,

> Did you enable CONFIG_SPI_FLASH_SPANSION on your config, becuase
> S25FL512S is already been added u-boot. Pls- check the same and let me
> know if you find any issues while detecting the flash.

> Whether the driver detecting flash or not with RDID, please define
> DEBUG on drivers/mtd/spi/spi_flash.c

I had no problems with detecting the flash. It was detected like this:
SF: Detected S25FL512S_256K with page size 512 Bytes, erase size 256 KiB, total 
64 MiB

Yes, I have CONFIG_SPI_FLASH_SPANSION enabled in 
configs/socfpga_arria5_dbrrh_defconfig (dbrrh - is my custom board).

Actually, today I solved the problem, although in not very clean way, I think.

As I mentioned in previous mail I had problems with reading from the flash. 
Some bytes were read incorrectly.
I'm migrating from U-Boot 2013 to mainline U-Boot. And on previous version 
there were no such issue.
I found out that there was some workaround introduced in order to fix this.

So, I just apply some part of that workaround to mainline U-Boot and now it 
works.

Here is the problem in more detail:

On previous version (2013):
U-BOOT # sf read 0x1B00 0x0380 4
 cadence_qspi_apb_indirect_read_setup. addr_value = 0x380
 cadence_qspi_apb_indirect_read_setup. rd_reg = 0x80b
 cadence_qspi_apb_indirect_read_setup. device size = 0x101003

U-BOOT # md 0x1B00 1
1b00: 55424923

But on mainline U-Boot(2016.03-rc1) I had:
U-BOOT # sf read 0x1B00 0x0380 4
 cadence_qspi_apb_indirect_read_setup. addr_value = 0x80
 cadence_qspi_apb_indirect_read_setup. rd_reg = 0x0b
 cadence_qspi_apb_indirect_read_setup. device size = 0x101002

U-BOOT # md 0x1B00 1
1b00: 554249ff

You can see the difference in the register values that were written in QSPI 
registers.
In case with mainline U-Boot I had address value not properly set.

Here is the workaround that I've made:

Index: drivers/mtd/spi/spi_flash.c
===
--- drivers/mtd/spi/spi_flash.c (revision 608)
+++ drivers/mtd/spi/spi_flash.c (revision 609)
@@ -29,6 +29,17 @@
cmd[3] = addr >> 0;
 }
 
+#ifdef CONFIG_DBRRH_WORKAROUND
+static void spi_flash_addr32(u32 addr, u8 *cmd)
+{
+   /* cmd[0] is actual command */
+   cmd[1] = (addr >> 24) & 0xFF;
+   cmd[2] = (addr >> 16) & 0xFF;
+   cmd[3] = (addr >> 8) & 0xFF;
+   cmd[4] = (addr >> 0) & 0xFF;
+}
+#endif
+
 static int read_sr(struct spi_flash *flash, u8 *rs)
 {
int ret;
@@ -510,8 +521,14 @@
else
read_len = remain_len;
 
+#ifdef CONFIG_DBRRH_WORKAROUND
+   spi_flash_addr32(read_addr, cmd);
+#else
spi_flash_addr(read_addr, cmd);
+#endif
 
ret = spi_flash_read_common(flash, cmd, cmdsz, data, read_len);
if (ret < 0) {
debug("SF: read failed\n");

Index: drivers/spi/cadence_qspi_apb.c
===
--- drivers/spi/cadence_qspi_apb.c  (revision 608)
+++ drivers/spi/cadence_qspi_apb.c  (revision 609)
@@ -30,6 +30,10 @@
 #include 
 #include "cadence_qspi.h"
 
+#ifdef CONFIG_DBRRH_WORKAROUND
+   #define CMD_OPTION_DUMMY_CYCLES 0x7F/* Dummy Cycles for 
Read Command */
+#endif
+
@@ -706,9 +710,25 @@
 #endif
 
/* Get address */
+#ifdef CONFIG_DBRRH_WORKAROUND
+   addr_value = cadence_qspi_apb_cmd2addr([1], 4);
+#else
addr_value = cadence_qspi_apb_cmd2addr([1], addr_bytes);
+#endif

+#ifdef CONFIG_DBRRH_WORKAROUND
+   /* Setting Dummy Clock Cycle */
+   dummy_clk = (0x08 & CMD_OPTION_DUMMY_CYCLES);
+   if (dummy_clk) 
+   {
+   rd_reg |= (dummy_clk & CQSPI_REG_RD_INSTR_DUMMY_MASK)
+   << CQSPI_REG_RD_INSTR_DUMMY_LSB;
+   }
+#else
+
/* The remaining lenght is dummy bytes. */
dummy_bytes = cmdlen - addr_bytes - 1;
if (dummy_bytes) {
@@ -731,7 +751,9 @@
rd_reg |= (dummy_clk & CQSPI_REG_RD_INSTR_DUMMY_MASK)
<< CQSPI_REG_RD_INSTR_DUMMY_LSB;
}
+#endif


With this correction I can read contents of the flash properly.
However, I'm a bit surprised that I was forced to make such correction like 
storing 4 bytes of address (see spi_flash_addr32() above).
On the other hand I haven't found any switch that could be turned on to fix my 
problem in a clean and nice way.

With 24 bytes we can address only 16 MB. How cadence driver is supposed to work 
for larger spaces?
Is this 4th byte comes from somewhere else?

Jagan, Heiko, please evaluate my correction.

Best regards,
Denis Bakhvalov
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Problem with attaching UBI partition

[Jagan Teki]

Hi Denis,

On 24 February 2016 at 14:29, Bakhvalov, Denis (Nokia - PL/Wroclaw)
 wrote:
> Hello Heiko,
>
>> Which U-Boot version? Which board?
>
> This is U-Boot v2016.03-rc1.
> I have custom board with socfpga Arria5 onboard.
>
>> Where does this leading 0xff come from? There seems a problem
>> with your spi nor flash driver?
>
> Yes, you're right. I have problems with the driver.
> As I mentioned in previous mail when I read the contents from the flash some 
> data is corrupted.
>
> How to find out if the problem is because U-Boot has no support for my flash 
> (Spansion S25FL512S NOR flash with SPI) or I have not proper configured SPI 
> in U-Boot?

Did you enable CONFIG_SPI_FLASH_SPANSION on your config, becuase
S25FL512S is already been added u-boot. Pls- check the same and let me
know if you find any issues while detecting the flash.

Whether the driver detecting flash or not with RDID, please define
DEBUG on drivers/mtd/spi/spi_flash.c

thanks!
-- 
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Problem with attaching UBI partition

[Heiko Schocher]

Hello Denis,

Am 24.02.2016 um 09:59 schrieb Bakhvalov, Denis (Nokia - PL/Wroclaw):

Hello Heiko,


Which U-Boot version? Which board?


This is U-Boot v2016.03-rc1.
I have custom board with socfpga Arria5 onboard.


Where does this leading 0xff come from? There seems a problem
with your spi nor flash driver?


Yes, you're right. I have problems with the driver.
As I mentioned in previous mail when I read the contents from the flash some 
data is corrupted.

How to find out if the problem is because U-Boot has no support for my flash 
(Spansion S25FL512S NOR flash with SPI) or I have not proper configured SPI in 
U-Boot?


Sorry, I have no such similiar HW ... You have to look into the flashs
datasheet and your RM for your SoC and find out whats the problem ...

added Jagan (SPI custodian) maybe he has an idea...

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Problem with attaching UBI partition

[Bakhvalov, Denis (Nokia - PL/Wroclaw)]

Hello Heiko,

> Which U-Boot version? Which board?

This is U-Boot v2016.03-rc1.
I have custom board with socfpga Arria5 onboard.

> Where does this leading 0xff come from? There seems a problem
> with your spi nor flash driver?

Yes, you're right. I have problems with the driver.
As I mentioned in previous mail when I read the contents from the flash some 
data is corrupted.

How to find out if the problem is because U-Boot has no support for my flash 
(Spansion S25FL512S NOR flash with SPI) or I have not proper configured SPI in 
U-Boot?

Best regards,
Denis Bakhvalov
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Problem with attaching UBI partition

[Heiko Schocher]

Hello Dennis,

Am 22.02.2016 um 15:17 schrieb Bakhvalov, Denis (Nokia - PL/Wroclaw):

Dear U-Boot support,

I have problems while running following commands in U-Boot:


Which U-Boot version? Which board?


U-Boot => sf probe 0 0 0
SF: Detected S25FL512S with page size 512, total: 67108864

U-Boot => mtdparts
device nor0 , # parts = 4
  #: namesizeoffset  mask_flags
  0: boot0x0010  0x  0
  1: bootenv 0x0008  0x0010  0
  2: SomeInfo0x0198  0x0018  0
  3: ubifspart   0x0250  0x01b0  0

U-Boot => ubi part ubifspart
mtd: Giving out device 1 to mtd=3
ubi0: attaching mtd1
UBI DBG gen (pid 1): sizeof(struct ubi_ainf_peb) 48
UBI DBG gen (pid 1): sizeof(struct ubi_wl_entry) 20
UBI DBG gen (pid 1): min_io_size  1
UBI DBG gen (pid 1): max_write_size   512
UBI DBG gen (pid 1): hdrs_min_io_size 1
UBI DBG gen (pid 1): ec_hdr_alsize64
UBI DBG gen (pid 1): vid_hdr_alsize   64
UBI DBG gen (pid 1): vid_hdr_offset   64
UBI DBG gen (pid 1): vid_hdr_aloffset 64
UBI DBG gen (pid 1): vid_hdr_shift0
UBI DBG gen (pid 1): leb_start128
UBI DBG gen (pid 1): max_erroneous16
UBI DBG gen (pid 1): process PEB 0
UBI DBG bld (pid 1): scan PEB 0
UBI DBG io (pid 1): read EC header from PEB 0
UBI DBG io (pid 1): read 64 bytes from PEB 0:0
ubi0 warning: ubi_io_read_ec_hdr: bad magic number at PEB 0: ff554249 instead 
of 55424923
Erase counter header dump:
 magic  0xff554249


Where does this leading 0xff come from? There seems a problem
with your spi nor flash driver?

I am currently on the EW 2016 in nuernberg, I could not look
deeper here... I think try to check your spi nor flash
driver...

bye,
Heiko

 version35
 ec 0
 vid_hdr_offset 16777216
 data_offset1073741824
 image_seq  -2142856561
 hdr_crc0xe046ed
erase counter header hexdump:
UBI DBG bld (pid 1): bad magic number at PEB 0: ff554249 instead of 55424923
UBI DBG io (pid 1): read VID header from PEB 0
UBI DBG io (pid 1): read 64 bytes from PEB 0:64
UBI DBG bld (pid 1): no VID header found at PEB 0, only 0xFF bytes
UBI DBG bld (pid 1): add to erase: PEB 0, EC -1

... // this warning goes for all PEBs from 1 to 147

ubi0: scanning is finished
UBI DBG gen (pid 1): max. sequence number:   0
ubi0 error: ubi_read_volume_table: the layout volume was not found
ubi0 error: ubi_attach_mtd_dev: failed to attach mtd1, error -22
UBI error: cannot attach mtd1
UBI error: cannot initialize UBI, error -22
UBI init error 22
UBI init error 22

For me it looks like this magic number is shifted one byte right, although I 
can't understand why.

Here is how I create UBI partition in Linux env:

Linux Env #> mtdinfo -a

mtd5
Name:   data
Type:   nor
Eraseblock size:262144 bytes, 256.0 KiB
Amount of eraseblocks:  148 (38797312 bytes, 37.0 MiB)
Minimum input/output unit size: 1 byte
Sub-page size:  1 byte
Character device major/minor:   90:10
Bad blocks are allowed: false
Device is writable: true

Linux Env #> ubiformat /dev/mtd5

ubiformat: mtd5 (nor), size 38797312 bytes (37.0 MiB), 148 eraseblocks of 
262144 bytes (256.0 KiB), min. I/O size 1 bytes
libscan: scanning eraseblock 147 -- 100 % complete
ubiformat: 148 eraseblocks are supposedly empty
ubiformat: formatting eraseblock 147 -- 100 % complete  797312

Linux Env #> ubiattach -m 5 /dev/ubi_ctrl

UBI: attaching mtd5 to ubi0
UBI: scanning is finished
UBI: attached mtd5 (name "part5", size 37 MiB) to ubi0
UBI: PEB size: 262144 bytes (256 KiB), LEB size: 262016 bytes
UBI: min./max. I/O unit sizes: 1/256, sub-page size 1
UBI: VID header offset: 64 (aligned 64), data offset: 128
UBI: good PEBs: 148, bad PEBs: 0, corrupted PEBs: 0
UBI: user volume: 0, internal volumes: 1, max. volumes count: 128
UBI: max/mean erase counter: 2/1, WL threshold: 4096, image sequence number: 
1371523162
UBI: available PEBs: 144, total reserved PEBs: 4, PEBs reserved for bad PEB 
handling: 0
UBI: background thread "ubi_bgt0d" started, PID 1003

Linux Env #> ubimkvol -N data -m /dev/ubi0

Linux Env #> mount -t ubifs ubi0:data /mnt

Linux Env #>  mount -t ubifs ubi0:data /mnt

UBIFS: default file-system created
UBIFS: background thread "ubifs_bgt0_0" started, PID 1010
UBIFS: mounted UBI device 0, volume 0, name "data"
UBIFS: LEB size: 262016 bytes (255 KiB), min./max. I/O unit sizes: 8 bytes/256 
bytes
UBIFS: FS size: 35110144 bytes (33 MiB, 134 LEBs), journal size 2096129 bytes 
(1 MiB, 7 LEBs)
UBIFS: reserved for root: 1658338 bytes (1619 KiB)
UBIFS: media format: w4/r0 (latest is w4/r0), UUID 
696FFD7B-1957-4ABD-9FDC-ED0EEB674D9D, small LPT model

It's perfectly working from Linux env, however U-Boot don't want to attach UBI 
partition.

Please help me identify the problem!

Best regards,
Denis 

Re: [U-Boot] Problem with attaching UBI partition

[Bakhvalov, Denis (Nokia - PL/Wroclaw)]

Hi,

I found that I have problem with reading flash contents:

When dumping the flash from Linux env:

$ cat /dev/mtd5 > /tmp/flash.bin

: 55424923 0100  0003

But when I dump the flash contents from U-Boot I see this:

=> sf read 0x1B00 0x01B0 0x1000
=> md 0x1B00

1b00: 494255ff 0123  

So, that's why I see this print:

ubi0 warning: ubi_io_read_ec_hdr: bad magic number at PEB 0: ff554249 instead 
of 55424923

I will investigate why data was read from flash incorrectly.

Best regards,
Denis Bakhvalov

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Problem with attaching UBI partition

[Bakhvalov, Denis (Nokia - PL/Wroclaw)]

Dear U-Boot support,

I have problems while running following commands in U-Boot:

U-Boot => sf probe 0 0 0
SF: Detected S25FL512S with page size 512, total: 67108864

U-Boot => mtdparts
device nor0 , # parts = 4
 #: namesizeoffset  mask_flags
 0: boot0x0010  0x  0
 1: bootenv 0x0008  0x0010  0
 2: SomeInfo0x0198  0x0018  0
 3: ubifspart   0x0250  0x01b0  0

U-Boot => ubi part ubifspart
mtd: Giving out device 1 to mtd=3
ubi0: attaching mtd1
UBI DBG gen (pid 1): sizeof(struct ubi_ainf_peb) 48
UBI DBG gen (pid 1): sizeof(struct ubi_wl_entry) 20
UBI DBG gen (pid 1): min_io_size  1
UBI DBG gen (pid 1): max_write_size   512
UBI DBG gen (pid 1): hdrs_min_io_size 1
UBI DBG gen (pid 1): ec_hdr_alsize64
UBI DBG gen (pid 1): vid_hdr_alsize   64
UBI DBG gen (pid 1): vid_hdr_offset   64
UBI DBG gen (pid 1): vid_hdr_aloffset 64
UBI DBG gen (pid 1): vid_hdr_shift0
UBI DBG gen (pid 1): leb_start128
UBI DBG gen (pid 1): max_erroneous16
UBI DBG gen (pid 1): process PEB 0
UBI DBG bld (pid 1): scan PEB 0
UBI DBG io (pid 1): read EC header from PEB 0
UBI DBG io (pid 1): read 64 bytes from PEB 0:0
ubi0 warning: ubi_io_read_ec_hdr: bad magic number at PEB 0: ff554249 instead 
of 55424923
Erase counter header dump:
magic  0xff554249
version35
ec 0
vid_hdr_offset 16777216
data_offset1073741824
image_seq  -2142856561
hdr_crc0xe046ed
erase counter header hexdump:
UBI DBG bld (pid 1): bad magic number at PEB 0: ff554249 instead of 55424923
UBI DBG io (pid 1): read VID header from PEB 0
UBI DBG io (pid 1): read 64 bytes from PEB 0:64
UBI DBG bld (pid 1): no VID header found at PEB 0, only 0xFF bytes
UBI DBG bld (pid 1): add to erase: PEB 0, EC -1

... // this warning goes for all PEBs from 1 to 147

ubi0: scanning is finished
UBI DBG gen (pid 1): max. sequence number:   0
ubi0 error: ubi_read_volume_table: the layout volume was not found
ubi0 error: ubi_attach_mtd_dev: failed to attach mtd1, error -22
UBI error: cannot attach mtd1
UBI error: cannot initialize UBI, error -22
UBI init error 22
UBI init error 22

For me it looks like this magic number is shifted one byte right, although I 
can't understand why.

Here is how I create UBI partition in Linux env:

Linux Env #> mtdinfo -a

mtd5
Name:   data
Type:   nor
Eraseblock size:262144 bytes, 256.0 KiB
Amount of eraseblocks:  148 (38797312 bytes, 37.0 MiB)
Minimum input/output unit size: 1 byte
Sub-page size:  1 byte
Character device major/minor:   90:10
Bad blocks are allowed: false
Device is writable: true

Linux Env #> ubiformat /dev/mtd5

ubiformat: mtd5 (nor), size 38797312 bytes (37.0 MiB), 148 eraseblocks of 
262144 bytes (256.0 KiB), min. I/O size 1 bytes
libscan: scanning eraseblock 147 -- 100 % complete
ubiformat: 148 eraseblocks are supposedly empty
ubiformat: formatting eraseblock 147 -- 100 % complete  797312

Linux Env #> ubiattach -m 5 /dev/ubi_ctrl

UBI: attaching mtd5 to ubi0
UBI: scanning is finished
UBI: attached mtd5 (name "part5", size 37 MiB) to ubi0
UBI: PEB size: 262144 bytes (256 KiB), LEB size: 262016 bytes
UBI: min./max. I/O unit sizes: 1/256, sub-page size 1
UBI: VID header offset: 64 (aligned 64), data offset: 128
UBI: good PEBs: 148, bad PEBs: 0, corrupted PEBs: 0
UBI: user volume: 0, internal volumes: 1, max. volumes count: 128
UBI: max/mean erase counter: 2/1, WL threshold: 4096, image sequence number: 
1371523162
UBI: available PEBs: 144, total reserved PEBs: 4, PEBs reserved for bad PEB 
handling: 0
UBI: background thread "ubi_bgt0d" started, PID 1003

Linux Env #> ubimkvol -N data -m /dev/ubi0

Linux Env #> mount -t ubifs ubi0:data /mnt

Linux Env #>  mount -t ubifs ubi0:data /mnt

UBIFS: default file-system created
UBIFS: background thread "ubifs_bgt0_0" started, PID 1010
UBIFS: mounted UBI device 0, volume 0, name "data"
UBIFS: LEB size: 262016 bytes (255 KiB), min./max. I/O unit sizes: 8 bytes/256 
bytes
UBIFS: FS size: 35110144 bytes (33 MiB, 134 LEBs), journal size 2096129 bytes 
(1 MiB, 7 LEBs)
UBIFS: reserved for root: 1658338 bytes (1619 KiB)
UBIFS: media format: w4/r0 (latest is w4/r0), UUID 
696FFD7B-1957-4ABD-9FDC-ED0EEB674D9D, small LPT model

It's perfectly working from Linux env, however U-Boot don't want to attach UBI 
partition.

Please help me identify the problem!

Best regards,
Denis Bakhvalov

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot