On 1/10/23 16:37, Heinrich Schuchardt wrote:
On 1/10/23 23:32, Heinrich Schuchardt wrote:
On 1/9/23 22:55, Eddie James wrote:
Use the sandbox TPM driver to measure some boot images in a unit test case.
$ ./u-boot -T -c "ut measurement" Running 1 measurement tests Test: measure: measurement.c Failures: 0
Signed-off-by: Eddie James eajames@linux.ibm.com
arch/sandbox/dts/test.dts | 12 +++++++ configs/sandbox_defconfig | 1 + include/test/suites.h | 1 + test/boot/Makefile | 1 + test/boot/measurement.c | 66 +++++++++++++++++++++++++++++++++++++++ test/cmd_ut.c | 2 ++ 6 files changed, 83 insertions(+) create mode 100644 test/boot/measurement.c
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts index dffe10adbf..ad90bf0541 100644 --- a/arch/sandbox/dts/test.dts +++ b/arch/sandbox/dts/test.dts @@ -66,6 +66,17 @@ osd0 = "/osd"; };
+ reserved-memory { + #address-cells = <1>; + #size-cells = <1>; + ranges;
+ event_log: tcg_event_log@d0e000 { + no-map;
Isn't no-map misplaced? Shouldn't it be a reserved-memory property?
The placement is correct. But I still wonder why we should have this area as no-map.
If the memory region is not mapped, Linux can never access it as described in Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml.
I read the documentation as meaning that Linux won't map it as part of it's standard mappings. It's still available for a device driver (TPM driver in this case). I believe no-map is appropriate here since we don't want anything except the TPM driver to access that memory.
Thanks,
Eddie
Please, document all changes to the device-tree semantics via patches for the Linux kernels documentation and provide a full example.
Best regards
Heinrich