| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <dec5ce6cbf73db8b6d72f59ccb87e477293adb5d.camel@ew.tq-group.com>
Date: Fri, 05 Jun 2020 09:57:08 +0200
From: Matthias Schiffer <matthias.schiffer@...tq-group.com>
To: Robin Gong <yibin.gong@....com>
Cc: "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>,
dl-linux-imx <linux-imx@....com>,
"kernel@...gutronix.de" <kernel@...gutronix.de>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"mark.rutland@....com" <mark.rutland@....com>,
"broonie@...nel.org" <broonie@...nel.org>,
"robh+dt@...nel.org" <robh+dt@...nel.org>,
"catalin.marinas@....com" <catalin.marinas@....com>,
"vkoul@...nel.org" <vkoul@...nel.org>,
"will.deacon@....com" <will.deacon@....com>,
"shawnguo@...nel.org" <shawnguo@...nel.org>,
"festevam@...il.com" <festevam@...il.com>,
"s.hauer@...gutronix.de" <s.hauer@...gutronix.de>,
"martin.fuzzey@...wbird.group" <martin.fuzzey@...wbird.group>,
"u.kleine-koenig@...gutronix.de" <u.kleine-koenig@...gutronix.de>,
"dan.j.williams@...el.com" <dan.j.williams@...el.com>,
Markus Niebel <Markus.Niebel@...group.com>
Subject: Re: (EXT) RE: [PATCH v8 00/13] add ecspi ERR009165 for i.mx6/7 soc
family
On Fri, 2020-06-05 at 02:45 +0000, Robin Gong wrote:
> On 2020/06/03 Matthias Schiffer <matthias.schiffer@...tq-group.com>
> wrote:
> > On Wed, 2020-06-03 at 09:50 +0000, Robin Gong wrote:
> > > On 2020/06/03 Matthias Schiffer <
> > > matthias.schiffer@...tq-group.com>
> > > wrote:
> > > > On Thu, 2020-05-21 at 04:34 +0800, Robin Gong wrote:
> > > > > There is ecspi ERR009165 on i.mx6/7 soc family, which cause
> > > > > FIFO
> > > > > transfer to be send twice in DMA mode. Please get more
> > > > > information
> > > > > from:
> > > > >
> >
> >
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> > > > > .
> > > > >
> > > >
> > > >
> >
> > nxp.com%2Fdocs%2Fen%2Ferrata%2FIMX6DQCE.pdf&data=02%7C01%7C
> > > > yibin.g
> > > > >
> > > >
> > > >
> >
> > ong%40nxp.com%7C4621358b9be04a79d2d508d80798835b%7C686ea1d3bc2b
> > > > 4c6fa92
> > > > >
> > > >
> > > >
> >
> > cd99c5c301635%7C0%7C1%7C637267698912634476&sdata=hR66H1hP%
> > > > 2Fqb6OXe
> > > > > w9wpXizY8DiNfZZ1KLwu3Kty87jc%3D&reserved=0. The
> > > > > workaround
> >
> > is
> > > > > adding new sdma ram script which works in XCH mode as PIO
> > > > > inside
> > > > > sdma instead of SMC mode, meanwhile, 'TX_THRESHOLD' should be
> > > > > 0.
> > > > > The issue
> > > >
> > > > should be exist on all legacy i.mx6/7 soc family before
> > > > i.mx6ul.
> > > > > NXP fix this design issue from i.mx6ul, so newer chips
> > > > > including
> > > > > i.mx6ul/ 6ull/6sll do not need this workaroud anymore. All
> > > > > other
> > > > > i.mx6/7/8 chips still need this workaroud. This patch set add
> > > > > new
> > > > > 'fsl,imx6ul-ecspi'
> > > > > for ecspi driver and 'ecspi_fixed' in sdma driver to choose
> > > > > if
> > > > > need errata or not.
> > > > > The first two reverted patches should be the same issue,
> > > > > though,
> > > > > it seems 'fixed' by changing to other shp script. Hope Sean
> > > > > or
> > > > > Sascha could have the chance to test this patch set if could
> > > > > fix
> > > > > their issues.
> > > > > Besides, enable sdma support for i.mx8mm/8mq and fix ecspi1
> > > > > not
> > > > > work on i.mx8mm because the event id is zero.
> > > > >
> > > > > PS:
> > > > > Please get sdma firmware from below linux-firmware and
> > > > > copy it
> > > > > to your local rootfs /lib/firmware/imx/sdma.
> > > >
> > > >
> > > > Hello Robin,
> > > >
> > > > we have tried out this series, and there seems to be an issue
> > > > with
> > > > the
> > > > PIO fallback. We are testing on an i.MX6Q board, and our kernel
> > > > is
> > > > a
> > > > mostly-unmodified 5.4, on which we backported all SDMA patches
> > > > from
> > > > next-20200602 (imx-sdma.c is identical to next-20200602
> > > > version),
> > > > and
> > > > then applied this whole series.
> > > >
> > > > We build the SDMA driver as a kernel module, which is loaded by
> > > > udev,
> > > > so the root filesystem is ready and the SDMA firmware can be
> > > > loaded.
> > > > The behaviour we're seeing is the following:
> > > >
> > > > 1. As long as the SDMA driver is not loaded, initializing
> > > > spi_imx
> > > > will
> > > > be deferred
> > > > 2. imx_sdma is loaded. The SDMA firmware is not yet loaded at
> > > > this
> > > > point
> > > > 3. spi_imx is initialized and an SPI-NOR flash is probed. To
> > > > load
> > > > the
> > > > BFPT, the driver will attempt to use DMA; this will fail with
> > > > EINVAL as
> > > > long as the SDMA firmware is not ready, so the fallback to PIO
> > > > happens
> > > > (4. SDMA firmware is ready, subsequent SPI transfers use DMA)
> > > >
> > > > The problem happens in step 3: Whenever the driver falls back
> > > > to
> > > > PIO,
> > > > the received data is corrupt. The behaviour is specific to the
> > > > fallback: When I disable DMA completely via spi_imx.use_dma, or
> > > > when
> > > > the timing is lucky and the SDMA firmware gets loaded before
> > > > the
> > > > flash
> > > > is probed, no corruption can be observed.
> > >
> > > Thanks Matthias, would you like post log?
> > >
> >
> > I have attached the following log files:
> > - pio.log: DMA disabled via module parameter
> > - dma.log: "lucky" timing, SDMA firmware loaded before SPI-NOR
> > probe
> > - fallback.log: DMA->PIO fallback
> >
> > The logs include some additional log messages:
> > - Return value of spi_imx_dma_transfer() before PIO fallback
> > - SPI-NOR SFPT dump
> >
> > It can be seen that the BFPT data is identical in pio.log and
> > dma.log,
> > and differs almost completely in fallback.log. The corrupted data
> > seems
> > to be random, or uninitialized memory; it differs with every boot.
>
> Would you please have a try with the attached patch? Thanks.
Thank you, this fixes the issue we're seeing.
Kind regards,
Matthias
View attachment "fixed.log" of type "text/x-log" (33368 bytes)
Powered by blists - more mailing lists