qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] MTD timeout on bootup


From: James Hanley
Subject: Re: [Qemu-devel] MTD timeout on bootup
Date: Wed, 5 Apr 2017 12:36:59 -0400

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 <
address@hidden> wrote:

> > -----Original Message-----
> > From: James Hanley [mailto:address@hidden
> > Sent: Friday, 31 March 2017 8:29 AM
> > To: Alistair Francis <address@hidden>; Peter Crosthwaite
> > <address@hidden>; qemu-devel <address@hidden>
> > 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 <address@hidden>
> > 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.
>
>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]