Received-SPF: pass (google.com: domain of linux-kernel+bounces-156490-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Message-ID: <d4dc3f45-5bae-44a8-8169-58077f8b7966@tuxon.dev>
Date: Wed, 24 Apr 2024 10:32:02 +0300
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH 0/1] Timeout error with Microchip OTPC driver on
 SAM9X60
Content-Language: en-US
To: Alexander Dahl <ada@thorsis.com>
Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
 Nicolas Ferre <nicolas.ferre@microchip.com>
References: <20240412140802.1571935-1-ada@thorsis.com>
From: claudiu beznea <claudiu.beznea@tuxon.dev>
In-Reply-To: <20240412140802.1571935-1-ada@thorsis.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Hi, Alexander,

On 12.04.2024 17:08, Alexander Dahl wrote:
> Hei hei,
> 
> on a custom sam9x60 based board we want to access a unique ID of the
> SoC.  Microchip sam-ba has a command 'readuniqueid' which returns the
> content of the OTPC Product UID x Register in that case.
> 
> (On a different board with a SAMA5D2 we use the Serial Number x Register
> exposed through the atmel soc driver, which is not present in the
> SAM9X60 series.)
> 
> There is a driver for the OTPC of the SAMA7G5 and after comparing
> register layouts it seems that one is almost identical to the one used
> by SAM9X60.  So I thought just adapting the driver for SAM9X60 should be
> easy.  (At least as a start, the driver has no support for that UID
> register, but I suppose it would be the right place to implement it.)
> 
> However it does not work.  I used the patch attached with
> additional debug messages on a SAM9X60-Curiosity board.  (That patch is
> not meant for inclusion, just for showing what I've tried.)
> 
> On probe the function mchp_otpc_init_packets_list() returns with
> ETIMEDOUT, which it can only do if mchp_otpc_prepare_read() returns with
> timeout and that can only happen if read_poll_timeout() times out on
> reading the Status Register.  Poking that register with `devmem
> 0xeff0000c 32` gives 0x00000040 which means "A packet read is on-going".


Would it be possible that the OTP memory is not properly initialized and
the algorithm to initialized the packet list to confuse the hardware?

I see in the datasheet the following: "The initial value of the OTP memory
is ‘0’ but the memory may contain some “defective” bits already set to the
value ‘1’."

Otherwise, from the top of my mind I don't have any idea on what might happen.

Thank you,
Claudiu Beznea

> 
> Kinda stuck here.  Any ideas?
> 
> Greets and have a nice weekend everyone
> Alex
> 
> Alexander Dahl (1):
>   nvmem: microchip-otpc: Add support for SAM9X60
> 
>  .../dts/microchip/at91-sam9x60_curiosity.dts     |  4 ++++
>  arch/arm/boot/dts/microchip/sam9x60.dtsi         |  7 +++++++
>  drivers/nvmem/microchip-otpc.c                   | 16 +++++++++++++---
>  3 files changed, 24 insertions(+), 3 deletions(-)
> 
> 
> base-commit: fec50db7033ea478773b159e0e2efb135270e3b7