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@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 <ma...@denx.de>
---
Cc: Heiko Schocher <h...@denx.de>
Cc: Michal Simek <michal.si...@amd.com>
Cc: Tom Rini <tr...@konsulko.com>
Cc: Vasileios Amoiridis <vasileios.amoiri...@cern.ch>
Cc: u-boot@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
