On 10 January 2017 at 16:58, Alexander Graf agraf@suse.de 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.
Thanks for confirmation.
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.
I look forward to living in this ideal world the EDK2 and kernel communities promised me several years ago ;-)
Alex