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 <eaja...@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
