[PATCH] bootcount: zynqmp: Extend ZynqMP specific bootcount support

[Michal Simek]

On 1/30/25 11:36, Marek Vasut wrote:
> On 1/30/25 6:24 AM, Heiko Schocher wrote:
>> Hello Marek,
>>
>> On 30.01.25 02:37, Marek Vasut wrote:
>>> The PGGS area contains four registers, each of which can hold up to
>>> 32bit of data. Extend the boot counter to support storing boot count
>>> in either of the four registers with arbitrary mask to avoid limiting
>>> the boot counter only to the PGGS register 2 LSByte.
>>>
>>> Drop U_BOOT_DRVINFO() as that would instantiate the boot counter even
>>> if there is no DT node associated with it, that is undesired behavior.
>>>
>>> The boot counter configuration is implemented using three new DT properties:
>>> reg - PGGS register address, fallback to PGGS 2 at 0xffd80058
>>> u-boot,bootcount-reg-mask - Register mask, applied on PGGS register
>>> u-boot,bootcount-mask - Boot counter mask, applied on boot counter
>>> u-boot,bootcount-magic - Boot counter magic, applied on boot counter
>>>
>>> Example configuration of 16bit boot counter with 0xb0010000 magic in PGGS0:
>>>
>>> &amba {
>>>     bootcount at 0xffd80050 {
>>>         compatible = "u-boot,bootcount-zynqmp";
>>>         reg = <0 0xffd80050 0 0x4>;
>>>         u-boot,bootcount-magic = <0xb0010000>;
>>>         u-boot,bootcount-mask = <0xffff>;
>>>         u-boot,bootcount-reg-mask = <0xffffffff>;
>>>     };
>>> };
>>>
>>> Signed-off-by: Marek Vasut <marex at denx.de>
>>> ---
>>> Cc: Heiko Schocher <hs at denx.de>
>>> Cc: Michal Simek <michal.simek at amd.com>
>>> Cc: Tom Rini <trini at konsulko.com>
>>> Cc: Vasileios Amoiridis <vasileios.amoiridis at cern.ch>
>>> Cc: u-boot at lists.denx.de
>>> ---
>>>   drivers/bootcount/bootcount_zynqmp.c | 79 +++++++++++++++++++++++++---
>>>   1 file changed, 71 insertions(+), 8 deletions(-)
>>
>> Nitpick: Should there not be a change in a file where the new properties
>> and the compatible entry is documented?
> 
> Do we have one ? I don't see one with git grep, but I can write one.

DT binding is something what should be solved first because it is not in linux 
kernel or dt-schema. And I don't think it is going to be straight forward path.
Definitely I don't want to introduce u-boot specific binding which won't pass 
checks.

It means one thing is description for bootcount itself which is pretty much SoC 
independent and likely can just go to dt-schema to u-boot node itself.

The second is how to pass information about location. In this particular ZynqMP 
case I think ggs/pggs should be described via existing xlnx,zynqmp-nvmem-fw node 
and generic bootcount nvmem driver should just get pointer to that location 
which holds this value. That would solve description and pointer can be stored 
in /options/u-boot/ node ("u-boot,config" compatible string).

And get this to u-boot means to create new UCLASS_NVMEM which doesn't exist 
today and write nvmem driver at least for these new offsets.

Or ignore DT binding part and just extend driver and use 
SYS_BOOTCOUNT_ADDR/SYS_BOOTCOUNT_MAGIC/SYS_BOOTCOUNT_SINGLEWORD and only 
introduce MASK config option that can be changed to support your case.

Thanks,
Michal