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

Wolfgang Denk wd at denx.de
Tue Dec 7 07:52:34 CET 2010


Dear Deepak Saxena,

In message <4CFD863A.7070000 at mentor.com> you wrote:
> commit 341764495180a712b9aaccfa0479b2ff7e44e35b
> Author: Deepak Saxena <deepak_saxena at 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 at mentor.com>
>      Signed-off-by: Hollis Blanchard <hollis_blanchard at 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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
When all else fails, read the instructions.


More information about the U-Boot mailing list