From 72b338aa2cd4afff8e92ab28199bc2db073cfea7 Mon Sep 17 00:00:00 2001 From: Simon Glass Date: Sat, 30 Jul 2022 15:52:07 -0600 Subject: dm: core: Add a note about how livetree updates work The unflattening algorithm results in a single block of memory being allocated for the whole tree. When writing new properties, these are allocated new memory outside that block. When the block is freed, the allocated properties remain. Document how this works and the potential memory leak, as well as mentioning that updating the livetree is actually supported now. Signed-off-by: Simon Glass --- doc/develop/driver-model/livetree.rst | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) (limited to 'doc/develop/driver-model') diff --git a/doc/develop/driver-model/livetree.rst b/doc/develop/driver-model/livetree.rst index 9f654f3b894..fb2969259d0 100644 --- a/doc/develop/driver-model/livetree.rst +++ b/doc/develop/driver-model/livetree.rst @@ -211,9 +211,18 @@ using it in new code. Modifying the livetree ---------------------- -This is not currently supported. Once implemented it should provide a much -more efficient implementation for modification of the device tree than using -the flat tree. +This is supported in a limited way, with ofnode_write_prop() and related +functions. + +The unflattening algorithm results in a single block of memory being +allocated for the whole tree. When writing new properties, these are +allocated new memory outside that block. When the block is freed, the +allocated properties remain. This can result in a memory leak. + +The solution to this leak would be to add a flag for properties (and nodes when +support is provided for adding those) that indicates that they should be +freed. Then the tree can be scanned for these 'separately allocated' nodes and +properties before freeing the memory block. Internal implementation @@ -281,6 +290,6 @@ Live tree support was introduced in U-Boot 2017.07. There is still quite a bit of work to do to flesh this out: - tests for all access functions -- support for livetree modification +- more support for livetree modification - addition of more access functions as needed - support for livetree in SPL and before relocation (if desired) -- cgit v1.2.3 From 331048471dee5c1d9cede54382256e6cfaee2370 Mon Sep 17 00:00:00 2001 From: Simon Glass Date: Sat, 30 Jul 2022 15:52:08 -0600 Subject: dm: core: Introduce support for multiple trees At present ofnode only works with a single device tree, for the most part. This is the control FDT used by U-Boot. When booting an OS we may obtain a different device tree and want to modify it. Add some initial support for this into the ofnode API. Note that we don't permit aliases in this other device tree, since the of_access implementation maintains a list of aliases collected at start-up. Also, we don't need aliases to do fixups in the other FDT. So make sure that flat tree and live tree processing are consistent in this area. Signed-off-by: Simon Glass --- doc/develop/driver-model/livetree.rst | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) (limited to 'doc/develop/driver-model') diff --git a/doc/develop/driver-model/livetree.rst b/doc/develop/driver-model/livetree.rst index fb2969259d0..c29f29b205b 100644 --- a/doc/develop/driver-model/livetree.rst +++ b/doc/develop/driver-model/livetree.rst @@ -225,6 +225,23 @@ freed. Then the tree can be scanned for these 'separately allocated' nodes and properties before freeing the memory block. +Multiple livetrees +------------------ + +The livetree implementation was originally designed for use with the control +FDT. This means that the FDT fix-ups (ft_board_setup() and the like, must use +a flat tree. + +It would be helpful to use livetree for fixups, since adding a lot of nodes and +properties would involve less memory copying and be more efficient. As a step +towards this, an `oftree` type has been introduced. It is normally set to +oftree_default() but can be set to other values. Eventually this should allow +the use of FDT fixups using the ofnode interface, instead of the low-level +libfdt one. + +See dm_test_ofnode_root() for some examples. + + Internal implementation ----------------------- -- cgit v1.2.3 From 7b1dfc9fd7e2efed345c3fe9a2412b5300ac285e Mon Sep 17 00:00:00 2001 From: Simon Glass Date: Sat, 30 Jul 2022 15:52:12 -0600 Subject: dm: core: Prepare for updating the device tree with ofnode Add some documentation and a new flag so that we can safely enabled using the ofnode interface to write to the device tree. Signed-off-by: Simon Glass --- doc/develop/driver-model/livetree.rst | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) (limited to 'doc/develop/driver-model') diff --git a/doc/develop/driver-model/livetree.rst b/doc/develop/driver-model/livetree.rst index c29f29b205b..faf3eb5b5f0 100644 --- a/doc/develop/driver-model/livetree.rst +++ b/doc/develop/driver-model/livetree.rst @@ -224,6 +224,32 @@ support is provided for adding those) that indicates that they should be freed. Then the tree can be scanned for these 'separately allocated' nodes and properties before freeing the memory block. +The ofnode_write\_...() functions also support writing to the flat tree. Care +should be taken however, since this can change the position of node names and +properties in the flat tree, thus affecting the live tree. Generally this does +not matter, since when we fire up the live tree we don't ever use the flat tree +again. But in the case of tests, this can cause a problem. + +The sandbox tests typically run with OF_LIVE enabled but with the actual live +tree either present or absent. This is to make sure that the flat tree functions +work correctly even with OF_LIVE is enabled. But if a test modifies the flat +device tree, then the live tree can become invalid. Any live tree tests that run +after that point will use a corrupted tree, e.g. with an incorrect property name +or worse. To deal with this we use a flag UT_TESTF_LIVE_OR_FLAT then ensures +that tests which write to the flat tree are not run if OF_LIVE is enabled. Only +the live tree version of the test is run, when OF_LIVE is enabled, with +sandbox_flattree running the flat tree version. + +This is of course a work-around, even if a reasonable one. One solution to this +problem would be to make a copy of the flat tree before the test and restore it +afterwards, in the same memory location, so that the live tree pointers work +again. Another would be to regenerate the live tree if a test modified the flat +tree. + +Neither of these solutions is currently implemented, since the situation that +causes the problem can only occur in sandbox tests, is somewhat esoteric and +the UT_TESTF_LIVE_OR_FLAT flag deals with it in a reasonable way. + Multiple livetrees ------------------ -- cgit v1.2.3