[Qemu-devel] MTD timeout on bootup

[Qemu-devel] MTD timeout on bootup

[James Hanley]

When trying to bootup a pristine zync image from the zc702 tarball, it
would always fail with the MTD detection of the serial flash device type
command over the SPI.  I believe this section of code may have the logic
flipped.  Once I changed it to the following, I was able to detect the
flash type when booting the pristine image from Xilinx.
-Jim


>From baaaacca370c13526fd2b8c7b33c7d9e8a6d7b8d Mon Sep 17 00:00:00 2001
From: Jim Hanley <Jim.Hanley@LandisGyr.com>
Date: Thu, 23 Mar 2017 10:29:34 -0400
Subject: [PATCH] MTD writes from the SPI were never being dequeue...
Signed-off-by:

---
 hw/ssi/xilinx_spips.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/ssi/xilinx_spips.c b/hw/ssi/xilinx_spips.c
index da8adfa..a3af1f7 100644
--- a/hw/ssi/xilinx_spips.c
+++ b/hw/ssi/xilinx_spips.c
@@ -482,8 +482,8 @@ static void xilinx_spips_write(void *opaque, hwaddr
addr,
     s->regs[addr] = (s->regs[addr] & ~mask) | (value & mask);
 no_reg_update:
     xilinx_spips_update_cs_lines(s);
-    if ((man_start_com && s->regs[R_CONFIG] & MAN_START_EN) ||
-            (fifo8_is_empty(&s->tx_fifo) && s->regs[R_CONFIG] &
MAN_START_EN)) {
+    if (!((man_start_com && s->regs[R_CONFIG] & MAN_START_EN) ||
+            (fifo8_is_empty(&s->tx_fifo) && s->regs[R_CONFIG] &
MAN_START_EN))) {
         xilinx_spips_flush_txfifo(s);
     }
     xilinx_spips_update_cs_lines(s);
-- 
2.7.4

Re: [Qemu-devel] MTD timeout on bootup

[Alistair Francis]

> -----Original Message-----
> From: James Hanley [mailto:jhanley@dgtlrift.com]
> Sent: Friday, 31 March 2017 8:29 AM
> To: Alistair Francis <alistai@xilinx.com>; Peter Crosthwaite
> <crosthwaite.peter@gmail.com>; qemu-devel <qemu-devel@nongnu.org>
> Subject: MTD timeout on bootup
>
> When trying to bootup a pristine zync image from the zc702 tarball, it would always
> fail with the MTD detection of the serial flash device type command over the SPI.  I
> believe this section of code may have the logic flipped.  Once I changed it to the
> following, I was able to detect the flash type when booting the pristine image from
> Xilinx.

Hey Jim,

First off, thanks for the patch.

In the future do you mind following the guidelines here:
http://wiki.qemu-project.org/Contribute/SubmitAPatch

If you use git format-patch and git send-email to generate the patch and send the result
to the mailing list it is much easier for people to review and apply.

Looking at the Xilinx Zynq-700 TRM (page 1754) I see that the Man_start_com bit
specifies to manually start the transmission of data, so it looks like the logic already in
the QEMU model is correct. What issue are you seeing that this fixes? Maybe the logic
somewhere else is incorrect.

PS: Sorry about the footer, I had to reply from my corporate email account.

Thanks,

Alistair

> -Jim
>
>
> From baaaacca370c13526fd2b8c7b33c7d9e8a6d7b8d Mon Sep 17 00:00:00 2001
> From: Jim Hanley <Jim.Hanley@LandisGyr.com>
> Date: Thu, 23 Mar 2017 10:29:34 -0400
> Subject: [PATCH] MTD writes from the SPI were never being dequeue...
> Signed-off-by:
>
> ---
>  hw/ssi/xilinx_spips.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/hw/ssi/xilinx_spips.c b/hw/ssi/xilinx_spips.c
> index da8adfa..a3af1f7 100644
> --- a/hw/ssi/xilinx_spips.c
> +++ b/hw/ssi/xilinx_spips.c
> @@ -482,8 +482,8 @@ static void xilinx_spips_write(void *opaque, hwaddr addr,
>      s->regs[addr] = (s->regs[addr] & ~mask) | (value & mask);
>  no_reg_update:
>      xilinx_spips_update_cs_lines(s);
> -    if ((man_start_com && s->regs[R_CONFIG] & MAN_START_EN) ||
> -            (fifo8_is_empty(&s->tx_fifo) && s->regs[R_CONFIG] & MAN_START_EN)) {
> +    if (!((man_start_com && s->regs[R_CONFIG] & MAN_START_EN) ||
> +            (fifo8_is_empty(&s->tx_fifo) && s->regs[R_CONFIG] & MAN_START_EN))) {
>          xilinx_spips_flush_txfifo(s);
>      }
>      xilinx_spips_update_cs_lines(s);
> --
> 2.7.4



This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.

Re: [Qemu-devel] MTD timeout on bootup

[James Hanley]

Thanks Alistair.
Regarding the issue - when I tried to use any of the pre-built images off
of http://www.wiki.xilinx.com/Zynq+Releases none would detect the MTD
device in QEMU - they all had a timeout error.  Single-stepping through
QEMU with GDB as it booted up any of the kernels from Xilinx, I couldn't
see how the SPI queue could be emptied from the fifo otherwise.  It wasn't
until I made the change in the patch flipping the logic that it would
detect the MTD device.

Taking a step back, I was really interested in understanding a working
reference implementation for interaction between SPI and serial flash in
QEMU for myself as I'm attempting to implement the Atmel SAM4C family of
MCUs - so my knowledge of Zynq is limited, and I was really just looking
for an ARM based reference model to use.

As far as patch submitting, I know this is out of scope of this thread, but
"git send-email" seems to fail with Google Mail for GSuite domains.  Google
keeps blocking it with an error that the app is a "less secure app"...
anybody else know the resolution to this?

On Mon, Apr 3, 2017 at 1:32 PM, Alistair Francis <
alistair.francis@xilinx.com> wrote:

> > -----Original Message-----
> > From: James Hanley [mailto:jhanley@dgtlrift.com]
> > Sent: Friday, 31 March 2017 8:29 AM
> > To: Alistair Francis <alistai@xilinx.com>; Peter Crosthwaite
> > <crosthwaite.peter@gmail.com>; qemu-devel <qemu-devel@nongnu.org>
> > Subject: MTD timeout on bootup
> >
> > When trying to bootup a pristine zync image from the zc702 tarball, it
> would always
> > fail with the MTD detection of the serial flash device type command over
> the SPI.  I
> > believe this section of code may have the logic flipped.  Once I changed
> it to the
> > following, I was able to detect the flash type when booting the pristine
> image from
> > Xilinx.
>
> Hey Jim,
>
> First off, thanks for the patch.
>
> In the future do you mind following the guidelines here:
> http://wiki.qemu-project.org/Contribute/SubmitAPatch
>
> If you use git format-patch and git send-email to generate the patch and
> send the result
> to the mailing list it is much easier for people to review and apply.
>
> Looking at the Xilinx Zynq-700 TRM (page 1754) I see that the
> Man_start_com bit
> specifies to manually start the transmission of data, so it looks like the
> logic already in
> the QEMU model is correct. What issue are you seeing that this fixes?
> Maybe the logic
> somewhere else is incorrect.
>
> PS: Sorry about the footer, I had to reply from my corporate email account.
>
> Thanks,
>
> Alistair
>
> > -Jim
> >
> >
> > From baaaacca370c13526fd2b8c7b33c7d9e8a6d7b8d Mon Sep 17 00:00:00 2001
> > From: Jim Hanley <Jim.Hanley@LandisGyr.com>
> > Date: Thu, 23 Mar 2017 10:29:34 -0400
> > Subject: [PATCH] MTD writes from the SPI were never being dequeue...
> > Signed-off-by:
> >
> > ---
> >  hw/ssi/xilinx_spips.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/hw/ssi/xilinx_spips.c b/hw/ssi/xilinx_spips.c
> > index da8adfa..a3af1f7 100644
> > --- a/hw/ssi/xilinx_spips.c
> > +++ b/hw/ssi/xilinx_spips.c
> > @@ -482,8 +482,8 @@ static void xilinx_spips_write(void *opaque, hwaddr
> addr,
> >      s->regs[addr] = (s->regs[addr] & ~mask) | (value & mask);
> >  no_reg_update:
> >      xilinx_spips_update_cs_lines(s);
> > -    if ((man_start_com && s->regs[R_CONFIG] & MAN_START_EN) ||
> > -            (fifo8_is_empty(&s->tx_fifo) && s->regs[R_CONFIG] &
> MAN_START_EN)) {
> > +    if (!((man_start_com && s->regs[R_CONFIG] & MAN_START_EN) ||
> > +            (fifo8_is_empty(&s->tx_fifo) && s->regs[R_CONFIG] &
> MAN_START_EN))) {
> >          xilinx_spips_flush_txfifo(s);
> >      }
> >      xilinx_spips_update_cs_lines(s);
> > --
> > 2.7.4
>
>
>
> This email and any attachments are intended for the sole use of the named
> recipient(s) and contain(s) confidential information that may be
> proprietary, privileged or copyrighted under applicable law. If you are not
> the intended recipient, do not read, copy, or forward this email message or
> any attachments. Delete this email message and any attachments immediately.
>
>