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

Dear Hollis,

In message 4CFE7FA8.2030701@mentor.com you wrote:

On 12/06/2010 10:52 PM, Wolfgang Denk wrote:

...

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.

I *think* what you're suggesting is basically providing u-boot with a single device tree, even when it will load multiple operating systems. The tree would then look something like this:

To be honest - I have not spent thoughts yet how this can be implemented. I would expect that there might be some common part, but there will eventually also be per-core configurations.

 cpus
     ...
 memory
     reg = <0 20000000>
 soc
     ...
 partitions
     partition@0
         memory
             reg = <0 10000000>
     partition@1
         memory
             reg = <10000000 10000000>

U-boot would then be responsible for constructing multiple device trees (one for each partition) itself, based on the additional information found in the "partitions" node.

Is that correct?

I did not think about that. I did not think about how to boot an OS and how to provide a DT to these.

My concerns are still on a lower level. Memory initialization is a very basic task of the boot loader. We are discussiong to move the description of this resource out of U-Boot (where it was traditionally statically coinfigured at compile time, with the exception of auti-sizing). When doing so, we should not let U-Boot live in a different world, or let it operate on a different set of information. If the description of a resource is in the DT, then U-Boot has to use this information (from the DT) for all operations that deal with this resource.

Just passing such information to the OS, behind U-Boot's back and with U-Boot having an independt (and probably different) view makes no sense to me.

There are a number of features (persistent RAM, shared log buffer, shared video buffers, ...) where U-Boot and Linux need to have exactly the same understanding about available and usable memory. I just want to make sure that future extensions will allow to keep these features instead of breaking them.

Best regards,

Wolfgang Denk