[meta-xilinx] Is qspi-nor flash broken in meta-xilinx layer for zcu102-zynqmp?
Giordon Stark
kratsg at gmail.com
Mon Apr 30 06:35:47 PDT 2018
(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 <malu at 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-bounces at yoctoproject.org <
> meta-xilinx-bounces at yoctoproject.org> on behalf of Mike Looijmans <
> mike.looijmans at topic.nl>
> *Sent:* Sunday, April 29, 2018 5:31:38 PM
> *To:* meta-xilinx at 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 at zcu102-zynqmp:~# cat /proc/mtd
> > dev: size erasesize name
> > mtd0: 00100000 00002000 "qspi-fsbl-uboot"
> > mtd1: 00500000 00002000 "qspi-linux"
> > mtd2: 00020000 00002000 "qspi-device-tree"
> > mtd3: 005e0000 00002000 "qspi-rootfs"
> >
> > root at 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 at zcu102-zynqmp:~# dd if=/dev/urandom of=./sample.bin bs=1024
> count=4096
> > 4096+0 records in
> > 4096+0 records out
> >
> > root at 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 0x00000000-0x00002800
> >
> > 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.looijmans at topicproducts.com
> Website: www.topicproducts.com
>
> Please consider the environment before printing this e-mail
>
>
>
> --
> _______________________________________________
> meta-xilinx mailing list
> meta-xilinx at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-xilinx
> --
> _______________________________________________
> meta-xilinx mailing list
> meta-xilinx at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-xilinx
>
--
Giordon Stark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-xilinx/attachments/20180430/acb78496/attachment-0001.html>
More information about the meta-xilinx
mailing list