Re: [U-Boot] [PATCH] Honor /memory/reg node in DTB files

Dear Deepak Saxena,

In message 4CFD863A.7070000@mentor.com you wrote:

commit 341764495180a712b9aaccfa0479b2ff7e44e35b Author: Deepak Saxena deepak_saxena@mentor.com Date: Mon Dec 6 15:52:07 2010 -0800

 Honor /memory/reg node in DTB files

 This patch adds code to the bootm path to check if a valid
 /memory/reg node exists in the DTB file and if so, it
 does not override it with the values in bi_memstart and
 bi_memsize. This is particularly useful in multi-core
 environments where the memory may be partitioned across
 a large number of nodes.

 While the same can be accomplished on certain boards (p1022ds
 and p1_p2_rdb) by using the bootm_low and bootm_size
 environment variables, that solution is not universal and
 requires adding code ft_board_setup() for any new board
 that wants to support AMP operation. Also, given that the
 DTB is already  used to partition board devices (see commit
 dc2e673 in the Linux kernel tree), it makes sense to
 allow memory to be partitioned the same way from a user
 configuration perspective.

 This patch allows for the user to override the DTB file parameters
 on the p1022ds and p1_p2_rdb boards by setting the bootm_low and
 bootm_size to something other than bi_memstart and bi_memsize.
 In the long-term, those env variables should be depecrated and
 removed and system implementors should provide the memory
 partitioning information in the DTB.

 Signed-off-by: Deepak Saxena <deepak_saxena@mentor.com>
 Signed-off-by: Hollis Blanchard <hollis_blanchard@mentor.com>

I am not sure this is a good idea.

So far we have a pretty clear definition of responsibilities. U-Boot does the low level initialization, including the sizing and testing of the system memory. U-Boot then passes its results to Linux in the (modified by U-Boot) device tree.

Your patch inverts this situation, at least for the memory.

I agree that there may be situations where you want an easy way to pass such information. But then let's handle this right.

If you define that the device tree is the "master" for information about the memory layout (and potentially other hardware specifics), then you should be consequent and pass make U-Boot process this information. We've discussed before that there are a number of cases where it would be nice if U-Boot itself could be configured usign a device tree. This appears to be another one.

What do you think?

Best regards,

Wolfgang Denk