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

[Wolfgang Denk]

Dear Deepak,

In message <4CFE775C.6050001 at mentor.com> you wrote:
>
> I am a big fan of having consistent and clear definitions of 
> responsibilities; however, I think the model of having U-Boot
> handle the creation of memory nodes in the DTB does not scale
> cleanly to users configuring, deploying, and managing complicated
> AMP environments.

I agree with you, but I think this is just one part (and eventually a
minor part) of the issue.  I would not protest if you say thatthe whol
(static, compile time) configuration of U-Boot does not scale well for
such requirements.

So far we usually had pretty static board configurations, and a static
compile time description was all we needed.  Some developers consider
even simple extensions like auto-sizing the available RAM as
unnecessary luxury that just inreases the boot time and memory
footprint.

When it comes to more complicated setups we should provide means for a
more dynamic configuration - this has been discussed before, and there
was a general agreement that the device tree would be a usable way to
implement such a description of the hardware.

So what I'm proposing is not an opposite to what you have in mind, it
just takes it one step further, and makes the whole system consistent
again.

Waht I don't like is the tunneling of information through U-Boot,
while U-Boot actually needs and uses this very information as well.

> While we could provide a method to provide this information at build
> time to make U-Boot, this forces a static memory partitioning on the 
> system and does not mesh well with use cases where developers may

This is NOT what I suggested.

> The bootm_low and bootm_size variables are an attempt to get around
> this by overriding what U-Boot knows about the system but I think
> those also don't scale well when we start dealing with large numbers
> of cores (32+) with independent OS instances on them for some of the 
> same reasons. I think it is far simpler to have some custom scripts to 
> spit out new DTB files that uBoot is configured to load every time it 
> boots than to have to change a bunch of environment variables on boot.

Again, there is no conflict between your statement and what I
suggested.

> In the multi-node environments, we can't simply tell U-Boot to process 
> the DTB to determine how much memory is in the system as there is one 
> DTB per AMP node. One idea that comes to mind but that I think is not

Please explain: you can use the DT to tell Linux (or other OS) how
much memory they shoulduse, but you cannot use the same mechanism to
pass the same information to U-Boot?

> the right way to go due to complexity is to have the concept of
> nested DTBs that can define multiple operational "machines" and
> U-Boot knows how to read this and send the right sub-DTB to the
> right kernel image.

This is a technical details that can and should be discussed when we
have an agreement about the basic mechanism.

> I'm new to U-Boot development so would like to hear about the other use 
> cases you mentioned (pointer to email threads are OK) so I can have a 
> better understanding of the overall issues.

There are many board vendors who shipt boards with different
configurations - with or without NAND flash; with or without other
peripherals like CAN contollers, LCD, etc.; with different LCD sizes
and types, in portrait or landscape orientation, etc.  Some of these
features can be determined by probing the hardware, others (like the
orientation of a LCD) cannot.  It is sometimes a maintenance nightmare
to provide tens of different configurations of U-Boot for a single
product.  Being able to cinfigure available hardware through the DT,
and using a single common binary image of U-Boot for such systems
would be a great benefit.

> Thinking about this at a higher level, I think the question is where
> is the delineation between board bringup/configuration and run time
> configuration management? Scanning memory and determining how much 
> exists and programming the memory controller is a board-bring up and 
> configuration task that a bootloader has traditionally done. 

And probaly one it still has to do, as there are good chances that you
don't know the actual memory size in advance - like on systems that
come in several configruations but use a common U-Boot image, or
systems where the user can plug in DIMMs of different size.

> Partitioning for AMP operation is about managing what and how is running
> on top of the bootloader. How much knowledge should the bootloader have
> about this? The approach of providing the memory partitioning in the DTB 
> basically removes any of this knowledge from U-Boot, while the

I see many use cases where this is simply not possible, because you
need need the help of the bootloader to determine parameters that are
not known in advance, and that thus cannot be encoded in the DT.
Memory size if a very typical example for such a parameter.  It may be
OK for the use case you have currently in mind to use a fixed size,
but this covers just a few systems and is not flexible enough for
general use.

> other approaches (bootm, build-time configuration) make U-Boot very 
> aware and tied to what might be running above and reduce flexibility
> to easily change that.

Again, this was NOT what I suggested.

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
A memorandum is written not to inform the reader, but to protect  the
writer.                                               -- Dean Acheson