Re: [meta-xilinx] Is qspi-nor flash broken in meta-xilinx layer for zcu102-zynqmp?
When running the ubi-tests we see it crashing due to SPI timeout:
m25p80 spi0.0: SPI transfer timed out
m25p80 spi0.0: error -110 reading 5
error -110 reading SR
Has anyone experienced similar with the qspi-nor driver on latest rocko branch?
From: Martin Lund
Sent: Monday, April 30, 2018 11:54:13 AM
To: meta-xilinx@yoctoproject.org
Subject: Re: [meta-xilinx] Is qspi-nor flash broken in meta-xilinx layer for
zcu102-zynqmp?
Yeah, I see a lot of good stuff coming from you and Holden Sandlar trying to
fix/patch the qspi-nor driver but as you state Xilinx seems to pay little
attention to this driver. I've also applied your patches.
Surprisingly, we have just discovered that if we lower the spi-max-frequency
from 108 MHz (default in .dts) to e.g. 50 MHz our read/write problem goes away?
It seems the prebuilt xilinx petalinux images run successfully at 108 MHz so it
makes me wonder exactly what they are doing differently.
Also, running up UBI/UBIFS on the qspi-nor flash with the "has-io-mode" flag
and at 50 MHz it seems to work fine except when we run ubi-tests
("runubitests.sh /dev/ubi0") from mtd-utils we see it crashing when running the
*_paral tests which are sort of stress tests.
From: meta-xilinx-boun...@yoctoproject.org
<meta-xilinx-boun...@yoctoproject.org> on behalf of Mike Looijmans
<mike.looijm...@topic.nl>
Sent: Sunday, April 29, 2018 5:31:38 PM
To: meta-xilinx@yoctoproject.org
Subject: Re: [meta-xilinx] Is qspi-nor flash broken in meta-xilinx layer for
zcu102-zynqmp?
There were quite a few bugs in the QSPI support last year, I've sent
patches to fix the ones I found on the 'regular' Zynq to Xilinx. Since
the ZynqMP has a different controller than the Zynq, there may some
similar leftover bugs in there as well.
The QSPI driver still has not been submitted into Linux mainline, which
indicates the poor attention the driver has been receiving.
Side note: There's no point running both flash_erase and flashcp. The
flashcp command will also erase before writing (otherwise, you wouln't
need the command...). Either use flashcp, or use flash_erase followed by dd.
On 25-04-18 09:04, Martin Lund wrote:
> Hi,
>
> Is the qspi-nor flash feature broken in the meta-xilinx layer for
> zcu102-zynqmp ?
>
> We've been trying to test and verify the qspi-nor flash feature on a ZynqMP
> zcu102 rev 1.0 development board only to find out that basic reading/writing
> to the qspi-nor flash is failing.
>
> We are building and testing with core-image-minimal on latest rocko branch
> (commit 7935ef724c, stock/clean meta-xilinx, no petalinux) with the following
> patch/fix added to avoid the zynqmp_clk_get_periphial_rate error which
> prevents the u-boot SPL from booting:
> https://lists.yoctoproject.org/pipermail/meta-xilinx/2017-December/003464.html
>
> This is how we test and see the qspi-flash fail:
>
> root@zcu102-zynqmp:~# cat /proc/mtd
> dev:size erasesize name
> mtd0: 0010 2000 "qspi-fsbl-uboot"
> mtd1: 0050 2000 "qspi-linux"
> mtd2: 0002 2000 "qspi-device-tree"
> mtd3: 005e 2000 "qspi-rootfs"
>
> root@zcu102-zynqmp:~# flash_erase /dev/mtd3 0 0
> Erasing 8 Kibyte @ 2000 -- 0 % complete [ 103.966880] random: crng init done
> Erasing 8 Kibyte @ 5de000 -- 100 % complete
>
> root@zcu102-zynqmp:~# dd if=/dev/urandom of=./sample.bin bs=1024 count=4096
> 4096+0 records in
> 4096+0 records out
>
> root@zcu102-zynqmp:~# flashcp -v ./sample.bin /dev/mtd3
> Erasing blocks: 512/512 (100%)
> Writing data: 4096k/4096k (100%)
> Verifying data: 10k/4096k (0%)File does not seem to match flash data. First
> mismatch at 0x-0x2800
>
> Any ideas what might be wrong in the meta-xilinx layer that would make the
> qpsi-nor flash fail like that?
>
> Thanks.
>
> /Martin
>
--
Mike Looijmans
Kind regards,
Mike Looijmans
System Expert
TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com<http://www.topicproducts.com>
Please consider the environment before printing this e-mail
--
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx
--
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx
Re: [meta-xilinx] Is qspi-nor flash broken in meta-xilinx layer for zcu102-zynqmp?
With the Zynq 7 series you needed pin 8 free, because it was being used
to feed back the clock through the IO pad. Without that configured, it
would not work above 50MHz. In the pinmux config you had to enable this,
and it would be used when the clock divider was set to 2 (yielding
100MHz max.) Don't recall if the MPSoC had a similar hidden requirement.
I've run the QSPI on the ZynqMP at 150MHz (using 166MHz rated chips),
and it did work, but that was quite a while ago that I tested it. Should
still work on our boards though.
On 30-04-18 11:54, Martin Lund wrote:
Yeah, I see a lot of good stuff coming from you and Holden Sandlar
trying to fix/patch the qspi-nor driver but as you state Xilinx seems to
pay little attention to this driver. I've also applied your patches.
Surprisingly, we have just discovered that if we lower the
spi-max-frequency from 108 MHz (default in .dts) to e.g. 50 MHz our
read/write problem goes away?
It seems the prebuilt xilinx petalinux images run successfully at 108
MHz so it makes me wonder exactly what they are doing differently.
Also, running up UBI/UBIFS on the qspi-nor flash with the "has-io-mode"
flag and at 50 MHz it seems to work fine except when we run ubi-tests
("runubitests.sh /dev/ubi0") from mtd-utils we see it crashing when
running the *_paral tests which are sort of stress tests.
*From:* meta-xilinx-boun...@yoctoproject.org
<meta-xilinx-boun...@yoctoproject.org> on behalf of Mike Looijmans
<mike.looijm...@topic.nl>
*Sent:* Sunday, April 29, 2018 5:31:38 PM
*To:* meta-xilinx@yoctoproject.org
*Subject:* Re: [meta-xilinx] Is qspi-nor flash broken in meta-xilinx
layer for zcu102-zynqmp?
There were quite a few bugs in the QSPI support last year, I've sent
patches to fix the ones I found on the 'regular' Zynq to Xilinx. Since
the ZynqMP has a different controller than the Zynq, there may some
similar leftover bugs in there as well.
The QSPI driver still has not been submitted into Linux mainline, which
indicates the poor attention the driver has been receiving.
Side note: There's no point running both flash_erase and flashcp. The
flashcp command will also erase before writing (otherwise, you wouln't
need the command...). Either use flashcp, or use flash_erase followed by dd.
On 25-04-18 09:04, Martin Lund wrote:
Hi,
Is the qspi-nor flash feature broken in the meta-xilinx layer for zcu102-zynqmp
?
We've been trying to test and verify the qspi-nor flash feature on a ZynqMP
zcu102 rev 1.0 development board only to find out that basic reading/writing to
the qspi-nor flash is failing.
We are building and testing with core-image-minimal on latest rocko branch
(commit 7935ef724c, stock/clean meta-xilinx, no petalinux) with the following
patch/fix added to avoid the zynqmp_clk_get_periphial_rate error which prevents
the u-boot SPL from booting:
https://lists.yoctoproject.org/pipermail/meta-xilinx/2017-December/003464.html
This is how we test and see the qspi-flash fail:
root@zcu102-zynqmp:~# cat /proc/mtd
dev: size erasesize name
mtd0: 0010 2000 "qspi-fsbl-uboot"
mtd1: 0050 2000 "qspi-linux"
mtd2: 0002 2000 "qspi-device-tree"
mtd3: 005e 2000 "qspi-rootfs"
root@zcu102-zynqmp:~# flash_erase /dev/mtd3 0 0
Erasing 8 Kibyte @ 2000 -- 0 % complete [ 103.966880] random: crng init done
Erasing 8 Kibyte @ 5de000 -- 100 % complete
root@zcu102-zynqmp:~# dd if=/dev/urandom of=./sample.bin bs=1024 count=4096
4096+0 records in
4096+0 records out
root@zcu102-zynqmp:~# flashcp -v ./sample.bin /dev/mtd3
Erasing blocks: 512/512 (100%)
Writing data: 4096k/4096k (100%)
Verifying data: 10k/4096k (0%)File does not seem to match flash data. First
mismatch at 0x-0x2800
Any ideas what might be wrong in the meta-xilinx layer that would make the
qpsi-nor flash fail like that?
Thanks.
/Martin
--
Mike Looijmans
Kind regards,
Mike Looijmans
System Expert
TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com <http://www.topicproducts.com>
Please consider the environment before printing this e-mail
--
Kind regards,
Mike Looijmans
System Expert
TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com
Please consider the environment before printing this e-mail
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx
--
Mike Looijmans
--
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx
Re: [meta-xilinx] Is qspi-nor flash broken in meta-xilinx layer for zcu102-zynqmp?
(resending from right email)
Hi,
I've also seen a ton of issues myself with just getting QSPI working on the
ultrascale Zynq. We've been going back and forth with Xilinx support since
early December trying to get the QSPI on our board working (an example of
some of the changes is here
https://github.com/kratsg/meta-l1calo/pull/15/files ) but there seems to be
some compounding set of issues that more or less makes us unable to
actually get the board to use the QSPi correctly [still working on it...]
Giordon
On Mon, Apr 30, 2018 at 8:28 AM Martin Lund <m...@gomspace.com> wrote:
> Yeah, I see a lot of good stuff coming from you and Holden Sandlar trying
> to fix/patch the qspi-nor driver but as you state Xilinx seems to pay
> little attention to this driver. I've also applied your patches.
>
>
> Surprisingly, we have just discovered that if we lower the
> spi-max-frequency from 108 MHz (default in .dts) to e.g. 50 MHz our
> read/write problem goes away?
>
>
> It seems the prebuilt xilinx petalinux images run successfully at 108 MHz
> so it makes me wonder exactly what they are doing differently.
>
>
> Also, running up UBI/UBIFS on the qspi-nor flash with the "has-io-mode"
> flag and at 50 MHz it seems to work fine except when we run ubi-tests
> ("runubitests.sh /dev/ubi0") from mtd-utils we see it crashing when running
> the *_paral tests which are sort of stress tests.
>
>
>
>
>
> --
> *From:* meta-xilinx-boun...@yoctoproject.org <
> meta-xilinx-boun...@yoctoproject.org> on behalf of Mike Looijmans <
> mike.looijm...@topic.nl>
> *Sent:* Sunday, April 29, 2018 5:31:38 PM
> *To:* meta-xilinx@yoctoproject.org
> *Subject:* Re: [meta-xilinx] Is qspi-nor flash broken in meta-xilinx
> layer for zcu102-zynqmp?
>
> There were quite a few bugs in the QSPI support last year, I've sent
> patches to fix the ones I found on the 'regular' Zynq to Xilinx. Since
> the ZynqMP has a different controller than the Zynq, there may some
> similar leftover bugs in there as well.
>
> The QSPI driver still has not been submitted into Linux mainline, which
> indicates the poor attention the driver has been receiving.
>
> Side note: There's no point running both flash_erase and flashcp. The
> flashcp command will also erase before writing (otherwise, you wouln't
> need the command...). Either use flashcp, or use flash_erase followed by
> dd.
>
> On 25-04-18 09:04, Martin Lund wrote:
> > Hi,
> >
> > Is the qspi-nor flash feature broken in the meta-xilinx layer for
> zcu102-zynqmp ?
> >
> > We've been trying to test and verify the qspi-nor flash feature on a
> ZynqMP zcu102 rev 1.0 development board only to find out that basic
> reading/writing to the qspi-nor flash is failing.
> >
> > We are building and testing with core-image-minimal on latest rocko
> branch (commit 7935ef724c, stock/clean meta-xilinx, no petalinux) with the
> following patch/fix added to avoid the zynqmp_clk_get_periphial_rate error
> which prevents the u-boot SPL from booting:
> >
> https://lists.yoctoproject.org/pipermail/meta-xilinx/2017-December/003464.html
> >
> > This is how we test and see the qspi-flash fail:
> >
> > root@zcu102-zynqmp:~# cat /proc/mtd
> > dev:size erasesize name
> > mtd0: 0010 2000 "qspi-fsbl-uboot"
> > mtd1: 0050 2000 "qspi-linux"
> > mtd2: 0002 2000 "qspi-device-tree"
> > mtd3: 005e 2000 "qspi-rootfs"
> >
> > root@zcu102-zynqmp:~# flash_erase /dev/mtd3 0 0
> > Erasing 8 Kibyte @ 2000 -- 0 % complete [ 103.966880] random: crng
> init done
> > Erasing 8 Kibyte @ 5de000 -- 100 % complete
> >
> > root@zcu102-zynqmp:~# dd if=/dev/urandom of=./sample.bin bs=1024
> count=4096
> > 4096+0 records in
> > 4096+0 records out
> >
> > root@zcu102-zynqmp:~# flashcp -v ./sample.bin /dev/mtd3
> > Erasing blocks: 512/512 (100%)
> > Writing data: 4096k/4096k (100%)
> > Verifying data: 10k/4096k (0%)File does not seem to match flash data.
> First mismatch at 0x-0x2800
> >
> > Any ideas what might be wrong in the meta-xilinx layer that would make
> the qpsi-nor flash fail like that?
> >
> > Thanks.
> >
> > /Martin
> >
>
>
> --
> Mike Looijmans
>
>
> Kind regards,
>
> Mike Looijmans
> System Expert
>
> TOPIC Products
> Materiaalweg 4, NL-5681 RJ Best
> Postbus 440, NL-5680 AK Best
> Telefoon: +31 (0) 499 33 69 79 <+31%20499%20336%20979>
> E-mail: mike.looijm...@topicproducts.com
> Website: www.topicproducts.com
>
> Please consider the environment befo
Re: [meta-xilinx] Is qspi-nor flash broken in meta-xilinx layer for zcu102-zynqmp?
Yeah, I see a lot of good stuff coming from you and Holden Sandlar trying to
fix/patch the qspi-nor driver but as you state Xilinx seems to pay little
attention to this driver. I've also applied your patches.
Surprisingly, we have just discovered that if we lower the spi-max-frequency
from 108 MHz (default in .dts) to e.g. 50 MHz our read/write problem goes away?
It seems the prebuilt xilinx petalinux images run successfully at 108 MHz so it
makes me wonder exactly what they are doing differently.
Also, running up UBI/UBIFS on the qspi-nor flash with the "has-io-mode" flag
and at 50 MHz it seems to work fine except when we run ubi-tests
("runubitests.sh /dev/ubi0") from mtd-utils we see it crashing when running the
*_paral tests which are sort of stress tests.
From: meta-xilinx-boun...@yoctoproject.org
<meta-xilinx-boun...@yoctoproject.org> on behalf of Mike Looijmans
<mike.looijm...@topic.nl>
Sent: Sunday, April 29, 2018 5:31:38 PM
To: meta-xilinx@yoctoproject.org
Subject: Re: [meta-xilinx] Is qspi-nor flash broken in meta-xilinx layer for
zcu102-zynqmp?
There were quite a few bugs in the QSPI support last year, I've sent
patches to fix the ones I found on the 'regular' Zynq to Xilinx. Since
the ZynqMP has a different controller than the Zynq, there may some
similar leftover bugs in there as well.
The QSPI driver still has not been submitted into Linux mainline, which
indicates the poor attention the driver has been receiving.
Side note: There's no point running both flash_erase and flashcp. The
flashcp command will also erase before writing (otherwise, you wouln't
need the command...). Either use flashcp, or use flash_erase followed by dd.
On 25-04-18 09:04, Martin Lund wrote:
> Hi,
>
> Is the qspi-nor flash feature broken in the meta-xilinx layer for
> zcu102-zynqmp ?
>
> We've been trying to test and verify the qspi-nor flash feature on a ZynqMP
> zcu102 rev 1.0 development board only to find out that basic reading/writing
> to the qspi-nor flash is failing.
>
> We are building and testing with core-image-minimal on latest rocko branch
> (commit 7935ef724c, stock/clean meta-xilinx, no petalinux) with the following
> patch/fix added to avoid the zynqmp_clk_get_periphial_rate error which
> prevents the u-boot SPL from booting:
> https://lists.yoctoproject.org/pipermail/meta-xilinx/2017-December/003464.html
>
> This is how we test and see the qspi-flash fail:
>
> root@zcu102-zynqmp:~# cat /proc/mtd
> dev:size erasesize name
> mtd0: 0010 2000 "qspi-fsbl-uboot"
> mtd1: 0050 2000 "qspi-linux"
> mtd2: 0002 2000 "qspi-device-tree"
> mtd3: 005e 2000 "qspi-rootfs"
>
> root@zcu102-zynqmp:~# flash_erase /dev/mtd3 0 0
> Erasing 8 Kibyte @ 2000 -- 0 % complete [ 103.966880] random: crng init done
> Erasing 8 Kibyte @ 5de000 -- 100 % complete
>
> root@zcu102-zynqmp:~# dd if=/dev/urandom of=./sample.bin bs=1024 count=4096
> 4096+0 records in
> 4096+0 records out
>
> root@zcu102-zynqmp:~# flashcp -v ./sample.bin /dev/mtd3
> Erasing blocks: 512/512 (100%)
> Writing data: 4096k/4096k (100%)
> Verifying data: 10k/4096k (0%)File does not seem to match flash data. First
> mismatch at 0x-0x2800
>
> Any ideas what might be wrong in the meta-xilinx layer that would make the
> qpsi-nor flash fail like that?
>
> Thanks.
>
> /Martin
>
--
Mike Looijmans
Kind regards,
Mike Looijmans
System Expert
TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com<http://www.topicproducts.com>
Please consider the environment before printing this e-mail
--
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx
--
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx
Re: [meta-xilinx] Is qspi-nor flash broken in meta-xilinx layer for zcu102-zynqmp?
There were quite a few bugs in the QSPI support last year, I've sent patches to fix the ones I found on the 'regular' Zynq to Xilinx. Since the ZynqMP has a different controller than the Zynq, there may some similar leftover bugs in there as well. The QSPI driver still has not been submitted into Linux mainline, which indicates the poor attention the driver has been receiving. Side note: There's no point running both flash_erase and flashcp. The flashcp command will also erase before writing (otherwise, you wouln't need the command...). Either use flashcp, or use flash_erase followed by dd. On 25-04-18 09:04, Martin Lund wrote: Hi, Is the qspi-nor flash feature broken in the meta-xilinx layer for zcu102-zynqmp ? We've been trying to test and verify the qspi-nor flash feature on a ZynqMP zcu102 rev 1.0 development board only to find out that basic reading/writing to the qspi-nor flash is failing. We are building and testing with core-image-minimal on latest rocko branch (commit 7935ef724c, stock/clean meta-xilinx, no petalinux) with the following patch/fix added to avoid the zynqmp_clk_get_periphial_rate error which prevents the u-boot SPL from booting: https://lists.yoctoproject.org/pipermail/meta-xilinx/2017-December/003464.html This is how we test and see the qspi-flash fail: root@zcu102-zynqmp:~# cat /proc/mtd dev:size erasesize name mtd0: 0010 2000 "qspi-fsbl-uboot" mtd1: 0050 2000 "qspi-linux" mtd2: 0002 2000 "qspi-device-tree" mtd3: 005e 2000 "qspi-rootfs" root@zcu102-zynqmp:~# flash_erase /dev/mtd3 0 0 Erasing 8 Kibyte @ 2000 -- 0 % complete [ 103.966880] random: crng init done Erasing 8 Kibyte @ 5de000 -- 100 % complete root@zcu102-zynqmp:~# dd if=/dev/urandom of=./sample.bin bs=1024 count=4096 4096+0 records in 4096+0 records out root@zcu102-zynqmp:~# flashcp -v ./sample.bin /dev/mtd3 Erasing blocks: 512/512 (100%) Writing data: 4096k/4096k (100%) Verifying data: 10k/4096k (0%)File does not seem to match flash data. First mismatch at 0x-0x2800 Any ideas what might be wrong in the meta-xilinx layer that would make the qpsi-nor flash fail like that? Thanks. /Martin -- Mike Looijmans Kind regards, Mike Looijmans System Expert TOPIC Products Materiaalweg 4, NL-5681 RJ Best Postbus 440, NL-5680 AK Best Telefoon: +31 (0) 499 33 69 79 E-mail: mike.looijm...@topicproducts.com Website: www.topicproducts.com Please consider the environment before printing this e-mail -- ___ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
[meta-xilinx] Is qspi-nor flash broken in meta-xilinx layer for zcu102-zynqmp?
Hi, Is the qspi-nor flash feature broken in the meta-xilinx layer for zcu102-zynqmp ? We've been trying to test and verify the qspi-nor flash feature on a ZynqMP zcu102 rev 1.0 development board only to find out that basic reading/writing to the qspi-nor flash is failing. We are building and testing with core-image-minimal on latest rocko branch (commit 7935ef724c, stock/clean meta-xilinx, no petalinux) with the following patch/fix added to avoid the zynqmp_clk_get_periphial_rate error which prevents the u-boot SPL from booting: https://lists.yoctoproject.org/pipermail/meta-xilinx/2017-December/003464.html This is how we test and see the qspi-flash fail: root@zcu102-zynqmp:~# cat /proc/mtd dev:size erasesize name mtd0: 0010 2000 "qspi-fsbl-uboot" mtd1: 0050 2000 "qspi-linux" mtd2: 0002 2000 "qspi-device-tree" mtd3: 005e 2000 "qspi-rootfs" root@zcu102-zynqmp:~# flash_erase /dev/mtd3 0 0 Erasing 8 Kibyte @ 2000 -- 0 % complete [ 103.966880] random: crng init done Erasing 8 Kibyte @ 5de000 -- 100 % complete root@zcu102-zynqmp:~# dd if=/dev/urandom of=./sample.bin bs=1024 count=4096 4096+0 records in 4096+0 records out root@zcu102-zynqmp:~# flashcp -v ./sample.bin /dev/mtd3 Erasing blocks: 512/512 (100%) Writing data: 4096k/4096k (100%) Verifying data: 10k/4096k (0%)File does not seem to match flash data. First mismatch at 0x-0x2800 Any ideas what might be wrong in the meta-xilinx layer that would make the qpsi-nor flash fail like that? Thanks. /Martin -- ___ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
