Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20210922091007.5516-1-wsa+renesas@sang-engineering.com> <163282533892.34438.1878675609177525004.b4-ty@canonical.com>
In-Reply-To: <163282533892.34438.1878675609177525004.b4-ty@canonical.com>
From:   Geert Uytterhoeven <geert@linux-m68k.org>
Date:   Mon, 7 Mar 2022 17:44:19 +0100
Message-ID: <CAMuHMdUqQLo7=NFaNEukqniTJbx-mSZv7eQNB9eCT=L28y3u=A@mail.gmail.com>
Subject: Re: [RFC PATCH] memory: renesas-rpc-if: Correct QSPI data transfer in
 Manual mode
To:     Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>,
        Wolfram Sang <wsa+renesas@sang-engineering.com>
Cc:     Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
        Duc Nguyen <duc.nguyen.ub@renesas.com>,
        Sergey Shtylyov <s.shtylyov@omp.ru>,
        "Lad, Prabhakar" <prabhakar.mahadev-lad.rj@bp.renesas.com>,
        Andrew Gabbasov <andrew_gabbasov@mentor.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi Krzysztof and Wolfram,

CC Sergey, Prabhakar, Andrew,

On Tue, Sep 28, 2021 at 12:36 PM Krzysztof Kozlowski
<krzysztof.kozlowski@canonical.com> wrote:
> On Wed, 22 Sep 2021 11:10:06 +0200, Wolfram Sang wrote:
> > This patch fixes 2 problems:
> > [1] The output warning logs and data loss when performing
> > mount/umount then remount the device with jffs2 format.
> > [2] The access width of SMWDR[0:1]/SMRDR[0:1] register is wrong.
> >
> > This is the sample warning logs when performing mount/umount then
> > remount the device with jffs2 format:
> > jffs2: jffs2_scan_inode_node(): CRC failed on node at 0x031c51d4:
> > Read 0x00034e00, calculated 0xadb272a7
> >
> > [...]
>
> Applied, thanks!
>
> [1/1] memory: renesas-rpc-if: Correct QSPI data transfer in Manual mode
>       commit: fff53a551db50f5edecaa0b29a64056ab8d2bbca

While trying to enable support for RPC on Salvator-X(S)[*], I
discovered HyperFLASH detection is broken:

    rpc-if-hyperflash rpc-if-hyperflash: probing of hyperbus device failed

Reverting all commits to the RPC driver since Sergey's original
commit 5de15b610f785f0e ("mtd: hyperbus: add Renesas RPC-IF driver")
fixed probing:

    rpc-if-hyperflash: Found 1 x16 devices at 0x0 in 16-bit bank.
Manufacturer ID 0x000001 Chip ID 0x007000
    Amd/Fujitsu Extended Query Table at 0x0040
      Amd/Fujitsu Extended Query version 1.5.
    rpc-if-hyperflash: CFI contains unrecognised boot bank location
(0). Assuming bottom.
    number of CFI chips: 1
    10 fixed-partitions partitions found on MTD device rpc-if-hyperflash
    Creating 10 MTD partitions on "rpc-if-hyperflash":
    0x000000000000-0x000000040000 : "bootparam"
    [...]

However, there's still something wrong, as all HyperFLASH contents read
back as zeros, while the FLASH contains the full boot loader stack.
Bisecting the reverts pointed to this patch, and just reverting this
patch (small whitespace conflict) fixes probing, too. Still, all zeros.

Summary: needs more investigation ;-)

Wolfram: which platform did you use for QSPI testing, so I don't
break that again?

[*] Firmware compiled with RCAR_RPC_HYPERFLASH_LOCKED=0 of course.
    Without that (e.g. old H3 R-Car ES1.0), it crashes with an
    Asynchronous SError Interrupt during driver initialization.


Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds