Dear Deepak,
In message 4CFE775C.6050001@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