On 19/08/20 6:15 pm, Heiner Kallweit wrote:

On 19.08.2020 00:44, Chris Packham wrote:

quoted

Hi Again,

On 17/08/20 9:09 am, Chris Packham wrote:

quoted

On 14/08/20 6:19 pm, Heiner Kallweit wrote:

quoted

On 14.08.2020 04:48, Chris Packham wrote:

quoted

Hi,

I'm seeing a problem with accessing spi-nor after upgrading a T2081
based system to linux v5.7.15

For this board u-boot and the u-boot environment live on spi-nor.

When I use fw_setenv from userspace I get the following kernel logs

# fw_setenv foo=1
fsl_espi ffe110000.spi: Transfer done but SPIE_DON isn't set!
fsl_espi ffe110000.spi: Transfer done but SPIE_DON isn't set!
fsl_espi ffe110000.spi: Transfer done but SPIE_DON isn't set!
fsl_espi ffe110000.spi: Transfer done but SPIE_DON isn't set!
fsl_espi ffe110000.spi: Transfer done but SPIE_DON isn't set!
fsl_espi ffe110000.spi: Transfer done but SPIE_DON isn't set!
fsl_espi ffe110000.spi: Transfer done but SPIE_DON isn't set!
fsl_espi ffe110000.spi: Transfer done but SPIE_DON isn't set!
fsl_espi ffe110000.spi: Transfer done but SPIE_DON isn't set!
fsl_espi ffe110000.spi: Transfer done but SPIE_DON isn't set!
fsl_espi ffe110000.spi: Transfer done but SPIE_DON isn't set!
fsl_espi ffe110000.spi: Transfer done but SPIE_DON isn't set!
fsl_espi ffe110000.spi: Transfer done but SPIE_DON isn't set!
fsl_espi ffe110000.spi: Transfer done but SPIE_DON isn't set!
fsl_espi ffe110000.spi: Transfer done but rx/tx fifo's aren't empty!
fsl_espi ffe110000.spi: SPIE_RXCNT = 1, SPIE_TXCNT = 32
fsl_espi ffe110000.spi: Transfer done but rx/tx fifo's aren't empty!
fsl_espi ffe110000.spi: SPIE_RXCNT = 1, SPIE_TXCNT = 32
fsl_espi ffe110000.spi: Transfer done but rx/tx fifo's aren't empty!
fsl_espi ffe110000.spi: SPIE_RXCNT = 1, SPIE_TXCNT = 32
...

This error reporting doesn't exist yet in 4.4. So you may have an issue
under 4.4 too, it's just not reported.
Did you verify that under 4.4 fw_setenv actually has an effect?

Just double checked and yes under 4.4 the setting does get saved.

quoted

quoted

If I run fw_printenv (before getting it into a bad state) it is able to
display the content of the boards u-boot environment.

This might indicate an issue with spi being locked. I've seen related
questions, just use the search engine of your choice and check for
fw_setenv and locked.

I'm running a version of fw_setenv which includes
https://gitlab.denx.de/u-boot/u-boot/-/commit/db820159 so it shouldn't
be locking things unnecessarily.

quoted

quoted

If been unsuccessful in producing a setup for bisecting the issue. I do
know the issue doesn't occur on the old 4.4.x based kernel but that's
probably not much help.

Any pointers on what the issue (and/or solution) might be.

I finally managed to get our board running with a vanilla kernel. With
corenet64_smp_defconfig I occasionally see

    fsl_espi ffe110000.spi: Transfer done but SPIE_DON isn't set!

other than the message things seem to be working.

With a custom defconfig I see

    fsl_espi ffe110000.spi: Transfer done but SPIE_DON isn't set!
    fsl_espi ffe110000.spi: Transfer done but rx/tx fifo's aren't empty!
    fsl_espi ffe110000.spi: SPIE_RXCNT = 1, SPIE_TXCNT = 32
    ...

and access to the spi-nor does not work until the board is reset.

I'll try and pick apart the differences between the two defconfigs.

I now think my earlier testing is invalid. I have seen the problem with 
either defconfig if I try hard enough. I had convinced myself that the 
problem was CONFIG_PREEMPT but that was before I found boot-to-boot 
differences with the same kernel.

It's possible that I'm chasing multiple issues with the same symptom.

The error I'm most concerned with is in the sequence
1. boot with old image
2. write environment
3. boot with new image
4. write environment
5. write fails and environment is corrupted

After I recover the system things sometimes seem fine. Until I repeat 
the sequence above.

Also relevant may be:
- Which dts are you using?

Custom but based heavily on the t2080rdb.

- What's the spi-nor type, and at which frequency are you operating it?

The board has several alternate parts for the spi-nor so the dts just 
specifies compatible = "jedec,spi-nor" the actual chip detected on the 
board I have is "n25q032a (4096 Kbytes)". The dts sets spi-max-frequency 
= <10000000> I haven't measured the actual frequency on the bus.

- Does the issue still happen if you lower the frequency?

I did play around with the frequency initially but I should probably 
give that another go now that I have a better reproduction method.