On 10.1.2017 18:52, Stephen Warren wrote:
On 01/10/2017 09:58 AM, Alexander Graf wrote:
On 01/10/2017 05:47 PM, Ryan Harkin wrote:
On 10 January 2017 at 16:35, Alexander Graf agraf@suse.de wrote:
On 01/10/2017 05:31 PM, york sun wrote:
On 01/10/2017 05:02 AM, Alexander Graf wrote:
On 01/10/2017 01:58 PM, Michal Simek wrote: > U-Boot configured via DTB can use the same DTB for booting the > kernel. > When OF_CONTROL is used fdtcontroladdr is setup and can be use for > boot. > > Signed-off-by: Michal Simek michal.simek@xilinx.com > --- > > Didn't check if there is any side effect or not but it looks weird > when > you have DT driver u-boot that you have to load dtb again. I agree, and I think it's very reasonable to try and use the same device tree for U-Boot and Linux.
Would this prevent the user loading a DTB into ram and using bootm to over-ride the built-in DTB?
I have a background task to refactor u-boot support for ARM Ltd boards. One of many options I was considering was to have a minimal DTB to configure the platform with only the nodes needed for u-boot. The ARM Ltd device trees fluctuate so much, I wouldn't be able to commit to one DTB that will work forever...
No, it's only meant as a fallback when no manual device tree is provided. In an ideal world however, device trees are static and complete, so you could just put a final dt into U-Boot and have it propagated all the way through.
Can the commit message be updated to reflect this? From the commit message, it sounds like the control FDT will always be used. Something like "arm: bootm: fall back to U-Boot's FDT blob when booting kernel" would sound a lot less scary.
Sure not a problem to change it. Plus there must be a solution for c&p dtb to location where can be resized.
Thanks, Michal