| 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
| ||
|
Date: Wed, 26 Feb 2020 10:54:31 +0100
From: "Behme Dirk (CM/ESO2)" <dirk.behme@...bosch.com>
To: Sergei Shtylyov <sergei.shtylyov@...entembedded.com>
CC: <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
Philipp Zabel <p.zabel@...gutronix.de>,
Mason Yang <masonccyang@...c.com.tw>,
<linux-spi@...r.kernel.org>,
Chris Brandt <chris.brandt@...esas.com>,
<linux-renesas-soc@...r.kernel.org>,
Geert Uytterhoeven <geert@...ux-m68k.org>
Subject: Re: [PATCH RFC 2/2] memory: add Renesas RPC-IF driver
Hi Sergei,
On 25.02.2020 21:41, Sergei Shtylyov wrote:
> On 02/25/2020 12:33 PM, Behme Dirk (CM/ESO2) wrote:
>
>>>>>> From d72b805cc461ab1e9747c973e9be84e7abb8f828 Mon Sep 17 00:00:00 2001
>>>>>> From: Dirk Behme <dirk.behme@...bosch.com>
>>>>>> Date: Tue, 4 Feb 2020 08:39:31 +0100
>>>>>> Subject: [PATCH] memory: renesas-rpc-if: Correct the STRTIM and some other
>>>>>> clean up
>>>>>>
>>>>>> This is required to make the driver work correctly in my M3 environment.
>>>>>>
>>>>>> Signed-off-by: Dirk Behme <dirk.behme@...bosch.com>
>>>>>> ---
>>>>>> drivers/memory/renesas-rpc-if.c | 42 ++++++++++++++++++++-------------
>>>>>> 1 file changed, 25 insertions(+), 17 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/memory/renesas-rpc-if.c b/drivers/memory/renesas-rpc-if.c
>>>>>> index 04be92b64bfa..f4356b066384 100644
>>>>>> --- a/drivers/memory/renesas-rpc-if.c
>>>>>> +++ b/drivers/memory/renesas-rpc-if.c
>>>>> [...]
>>>>>> @@ -513,19 +525,15 @@ ssize_t rpcif_dirmap_read(struct rpcif *rpc, u64 offs, size_t len, void *buf)
>>>>>> pm_runtime_get_sync(rpc->dev);
>>>>>>
>>>>>> regmap_update_bits(rpc->regmap, RPCIF_CMNCR, RPCIF_CMNCR_MD, 0);
>>>>>> - regmap_write(rpc->regmap, RPCIF_DRCR,
>>>>>> - RPCIF_DRCR_RBURST(32) | RPCIF_DRCR_RBE);
>>>>>> - regmap_write(rpc->regmap, RPCIF_DRCMR, rpc->command);
>>>>>> - regmap_write(rpc->regmap, RPCIF_DREAR,
>>>>>> - RPCIF_DREAR_EAV(offs >> 25) | RPCIF_DREAR_EAC(1));
>>>>>> - regmap_write(rpc->regmap, RPCIF_DROPR, rpc->option);
>>>>>> - regmap_write(rpc->regmap, RPCIF_DRENR,
>>>>>> - rpc->enable & ~RPCIF_SMENR_SPIDE(0xF));
>>>>>> - regmap_write(rpc->regmap, RPCIF_DRDMCR, rpc->dummy);
>>>>>> - regmap_write(rpc->regmap, RPCIF_DRDRENR, rpc->ddr);
>>>>>
>>>>> The driver somehow works only with this left in place (with 2 bytes eaten
>>>>> as before), otherwise all the flash reads all 0xff (via dirmap).
>>>>
>>>>
>>>> Do you boot from hyperflash?
>>>
>>> No, I have arewto say 'cpld write 30 1' in U-Boot before a boot a kernel.
>
> s/arewto/to/. :-)
>
>>> Normally, the V3x Starter Kit boards are wired for the QSPI flash chips.
>>>
>>>> The system I'm using for testing boots from hyperflash. So most probably all registers
>>>> I don't touch in the driver are put into a reasonable state by the boot code, already.
>>>> If you don't boot from hyperflash, that at least would explain our different behavior.
>>>
>>> Yes. Mind dumping the registers and sending to me?
>>
>> Using the attached debug patch (0001-memory-renesas-rpc-if-DEBUG-Dump-register-
>> content.patch) on a r8a7796 system booting from Hyperflash with above register
> dropping reverted (i.e. including touching these registers) I get
>>
>> Before:
>> RPCIF_DRCR: 0x00000000
>> RPCIF_DRCMR: 0x00a00000
>> RPCIF_DREAR: 0x00000000
>> RPCIF_DROPR: 0x00000000
>> RPCIF_DRENR: 0xa222d400
>> RPCIF_DRDMCR: 0x0000000e
>> RPCIF_DRDRENR: 0x00005101
>>
>> After:
>> RPCIF_DRCR: 0x001f0100
>> RPCIF_DRCMR: 0x00a00000
>> RPCIF_DREAR: 0x00010001
>> RPCIF_DROPR: 0x00000000
>> RPCIF_DRENR: 0xa202d400
>> RPCIF_DRDMCR: 0x0000000e
>> RPCIF_DRDRENR: 0x00005101
>>
>> Comparing that, just 3 registers are different between my working version ("Before") and the version which shows the 2-byte offset ("After"): RPCIF_DRCR, RPCIF_DREAR and RPCIF_DRENR. With try & error, at least in my setup, I was able to reduce this to just RPCIF_DRCR. Dropping the burst mode I was able to 'fix' the two byte offset issue.
>
> ACK! Thanks a lot for finding it! :-)
> That's what I get on the first dirmap read:
>
> Before:
> RPCIF_CMNCR: 0x81fff301
> RPCIF_DRCR: 0x00000000
> RPCIF_DRCMR: 0x00030000
> RPCIF_DREAR: 0x00000000
> RPCIF_DROPR: 0x00000000
> RPCIF_DRENR: 0x00004700
> RPCIF_DRDMCR: 0x00000000
> RPCIF_DRDRENR: 0x00000000
>
> After:
> RPCIF_CMNCR: 0x01fff301
> RPCIF_DRCR: 0x001f0100
> RPCIF_DRCMR: 0x00800000
> RPCIF_DREAR: 0x00000001
> RPCIF_DROPR: 0x00000000
> RPCIF_DRENR: 0xa202d400
> RPCIF_DRDMCR: 0x0000000e
> RPCIF_DRDRENR: 0x00005101
>
>> Do you like to give the attached 0001-memory-renesas-rpc-if-Don-t-use-burst-mode-on-read.patch a try in your setup?
>
> Works like charm! :-)
Good news, thanks! :)
> Unfortunately, the SPI dirmap and/or writes are still broken.
I'm unsure about which function we are talking for "SPI dirmap"?
Regarding writes, in rpcif_io_xfer() in RPCIF_DATA_IN we have an
additional place where burst mode is enabled:
if (!(smenr & RPCIF_SMENR_ADE(0xf)) && rpc->dirmap) {
...
regmap_write(rpc->regmap, RPCIF_DRCR,
RPCIF_DRCR_RBURST(32) | RPCIF_DRCR_RBE);
...
Maybe it's worth a try to replace this by just 0, as well:
regmap_write(rpc->regmap, RPCIF_DRCR, 0);
But of course, this is guessing, as I'm not sure if this
if (!(smenr & RPCIF_SMENR_ADE(0xf)) && rpc->dirmap) {
path is taken, at all?
Or even better, if you could adapt the "before / after" debug patch to
the path which are still not working for you and share it and the
results, we could compare it with my setup, too :)
Dirk
Powered by blists - more mailing lists