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

[Deepak Saxena]

On 12/07/2010 11:09 AM, Wolfgang Denk wrote:
> 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.

I won't argue with you on this front. Having U-Boot determine some board
information from the DT and determine other board information at
run-time is not consistent and confusing.

>> 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.

Thanks for clarifying that. You had stated "pass make U-Boot process
this information" and I read that as in passing the information to
the build ("make") process.

>> 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?

I'm not against U-Boot using this information, I'm just not sure how to
do this without adding quite a bit of complexity to the code base. We
would have to have U-Boot parse the memory nodes, validate them, check
for overlapping regions, check for holes, etc. I'm not arguing that it
is not doable, but wondering if adding this complexity is worth if the
scanning of memory and passing that information to the kernel works for
the majority of use cases. What I'm trying to do is support a special
use case, so what about  wrapping support for simply passing the memory
nodes from the DT to the kernel around a CONFIG option
(CONFIG_OF_MEMORY_PASSTHROUGH?) that can be enabled by system
implementers who need this and are running on fairly controlled
environments while the larger issue of how to use the DT is hashed out?

>> 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.

I completely understand your perspective here and agree with it. DT has
made the kernel easier to maintain across multiple similar platforms so
it makes sense to leverage the same technology in U-Boot.

>> 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.

Again, I understand this, though I am not 100% sure there is a way to do
this in a completely generic way off the top of my head. There are use
cases where we must rely on U-Boot to scan and determine memory size and
there are use cases where a system is designed and not changeable and
users need to be able to reconfigure system partitioning on the fly. Are
you open to the CONFIG option as a first step towards supporting the
later use case?

Thanks,
~Deepak