On 10/13/23 13:58, Krzysztof Kozlowski wrote:
On 13/10/2023 13:51, Michal Simek wrote:
On 10/13/23 13:46, Krzysztof Kozlowski wrote:
On 13/10/2023 13:22, Michal Simek wrote:
+
+required:
+ - compatible
required: block goes after patternProperties: block
+
+patternProperties:
+ "^soc_revision@0$":
Why do you define individual memory cells? Is this part of a binding?
IOW, OS/Linux requires this?
nvmem has in kernel interface where you can reference to nodes. nvmem_cell_get()
calls. It means you should be able to describe internal layout that's why names
are used. And address in name is there because of reg property is used to
describe base offset and size.
That's not really what I am asking. Why internal layout of memory must
be part of the bindings?
It doesn't need to be but offsets are hardcoded inside the driver itself and
they can't be different.
Hm, where? I opened drivers/nvmem/zynqmp_nvmem.c and I do not see any
hard-coded offsets.
Current driver supports only soc revision from offset 0.
But if you look at 5/5 you need to define offsets where information is present.
+#define SOC_VERSION_OFFSET 0x0
+#define EFUSE_START_OFFSET 0xC
+#define EFUSE_END_OFFSET 0xFC
+#define EFUSE_PUF_START_OFFSET 0x100
+#define EFUSE_PUF_MID_OFFSET 0x140
+#define EFUSE_PUF_END_OFFSET 0x17F
On different nvmem locations like MAC location in
eeprom this can vary across boards but in this case location has to be only like
this.
I am fine if they don't need to be actually check but there is no any other way
how they can be composed. And also others are not valid that's why not to
describe only valid one.
OK, that would be valid (if I find anywhere the offsets) and answers my
questions but I wish it was documented somewhere. Because now you are
making it a binding, so it cannot change (e.g. for different devices
with same hardware but different firmware or manufacturing process, for
future hardware sharing this binding).
ZynqMP firmware with xlnx,zynqmp-nvmem-fw compatible string is using this map.
If there is different firmware likely xlnx,zynqmp-nvmem-fw compatible string
can't be used.
In any case the binding should have only items which are really fixed
and OS depends on them. Neither this nor next commit answers this.
Actually 5/5 has this in commit message
0 - SOC version(read only)
0xC - 0xFC -ZynqMP specific purpose efuses
0x100 - 0x17F - Physical Unclonable Function(PUF)
efuses repurposed as user efuses
Thanks,
Michal
