[U-Boot] [RFC PATCH] arm: bootm: Boot kernel with U-Boot's FDT blob

[U-Boot] [RFC PATCH] arm: bootm: Boot kernel with U-Boot's FDT blob

[Michal Simek]

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.

---
 arch/arm/lib/bootm.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index 43cc83ec95b6..9740045b0094 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -245,6 +245,20 @@ static void boot_prep_linux(bootm_headers_t *images)
 		}
 		setup_board_tags(&params);
 		setup_end_tag(gd->bd);
+	} else if (IS_ENABLED(CONFIG_OF_CONTROL)) {
+#ifdef CONFIG_OF_LIBFDT
+		images->ft_addr = (char *)getenv_hex("fdtcontroladdr", 0);
+		if (!images->ft_addr) {
+			printf("FDT address failed! hanging...");
+			hang();
+		}
+
+		debug("using: U-Boot's FDT\n");
+		if (image_setup_linux(images)) {
+			printf("FDT creation failed! hanging...");
+			hang();
+		}
+#endif
 	} else {
 		printf("FDT and ATAGS support not compiled in - hanging\n");
 		hang();
-- 
1.9.1

[U-Boot] [RFC PATCH] arm: bootm: Boot kernel with U-Boot's FDT blob

[Alexander Graf]

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.

I'm not sure it's a great idea to check for the builtin device tree 
after ATAGs though. Shouldn't we prefer the built-in one over ATAGs?


Alex

>
> ---
>   arch/arm/lib/bootm.c | 14 ++++++++++++++
>   1 file changed, 14 insertions(+)
>
> diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
> index 43cc83ec95b6..9740045b0094 100644
> --- a/arch/arm/lib/bootm.c
> +++ b/arch/arm/lib/bootm.c
> @@ -245,6 +245,20 @@ static void boot_prep_linux(bootm_headers_t *images)
>   		}
>   		setup_board_tags(&params);
>   		setup_end_tag(gd->bd);
> +	} else if (IS_ENABLED(CONFIG_OF_CONTROL)) {
> +#ifdef CONFIG_OF_LIBFDT
> +		images->ft_addr = (char *)getenv_hex("fdtcontroladdr", 0);
> +		if (!images->ft_addr) {
> +			printf("FDT address failed! hanging...");
> +			hang();
> +		}
> +
> +		debug("using: U-Boot's FDT\n");
> +		if (image_setup_linux(images)) {
> +			printf("FDT creation failed! hanging...");
> +			hang();
> +		}
> +#endif
>   	} else {
>   		printf("FDT and ATAGS support not compiled in - hanging\n");
>   		hang();

[U-Boot] [RFC PATCH] arm: bootm: Boot kernel with U-Boot's FDT blob

[Michal Simek]

On 10.1.2017 14:02, 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.
> 
> I'm not sure it's a great idea to check for the builtin device tree
> after ATAGs though. Shouldn't we prefer the built-in one over ATAGs?

No problem to do it. The reason why I have done it in this way was not
to change behavior for existing platforms.

u-boot is also doing some automatic updates which can require fdt resize
but I didn't check if resize can be done in that space where build-in
dtb is.

Thanks,
Michal

[U-Boot] [RFC PATCH] arm: bootm: Boot kernel with U-Boot's FDT blob

[Alexander Graf]

On 01/10/2017 02:05 PM, Michal Simek wrote:
> On 10.1.2017 14:02, 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.
>>
>> I'm not sure it's a great idea to check for the builtin device tree
>> after ATAGs though. Shouldn't we prefer the built-in one over ATAGs?
> No problem to do it. The reason why I have done it in this way was not
> to change behavior for existing platforms.
>
> u-boot is also doing some automatic updates which can require fdt resize
> but I didn't check if resize can be done in that space where build-in
> dtb is.

Good point. It probably makes sense to copy it out, as we do in the EFI 
boot path (see the copy_fdt() call):

   https://github.com/trini/u-boot/blob/master/cmd/bootefi.c#L173

I also agree on the default behavior change problem. But in the patch as 
is, won't most boards just fall back to ATAG boot?


Alex

[U-Boot] [RFC PATCH] arm: bootm: Boot kernel with U-Boot's FDT blob

[Michal Simek]

On 10.1.2017 14:08, Alexander Graf wrote:
> On 01/10/2017 02:05 PM, Michal Simek wrote:
>> On 10.1.2017 14:02, 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.
>>>
>>> I'm not sure it's a great idea to check for the builtin device tree
>>> after ATAGs though. Shouldn't we prefer the built-in one over ATAGs?
>> No problem to do it. The reason why I have done it in this way was not
>> to change behavior for existing platforms.
>>
>> u-boot is also doing some automatic updates which can require fdt resize
>> but I didn't check if resize can be done in that space where build-in
>> dtb is.
> 
> Good point. It probably makes sense to copy it out, as we do in the EFI
> boot path (see the copy_fdt() call):
> 
>   https://github.com/trini/u-boot/blob/master/cmd/bootefi.c#L173
> 
> I also agree on the default behavior change problem. But in the patch as
> is, won't most boards just fall back to ATAG boot?

Only that one which has it enabled.
I expect most of boards with has OF_CONTROL enabled are not using ATAG.

Thanks,
Michal

[U-Boot] [RFC PATCH] arm: bootm: Boot kernel with U-Boot's FDT blob

[york sun]

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

Size is a concern. U-Boot only uses a small portion of the device tree. 
If the complete device tree is embedded into U-Boot, the size increases 
quite a bit.

York

[U-Boot] [RFC PATCH] arm: bootm: Boot kernel with U-Boot's FDT blob

[Alexander Graf]

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.
>>
> Size is a concern. U-Boot only uses a small portion of the device tree.
> If the complete device tree is embedded into U-Boot, the size increases
> quite a bit.

Is size really a concern? At the end of the day we only care about the 
full dt for non-SPL U-Boot which is reasonably big anyway. And if it's a 
real problem, we can always compress.


Alex

[U-Boot] [RFC PATCH] arm: bootm: Boot kernel with U-Boot's FDT blob

[york sun]

On 01/10/2017 08:35 AM, Alexander Graf 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.
>>>
>> Size is a concern. U-Boot only uses a small portion of the device tree.
>> If the complete device tree is embedded into U-Boot, the size increases
>> quite a bit.
>
> Is size really a concern? At the end of the day we only care about the
> full dt for non-SPL U-Boot which is reasonably big anyway. And if it's a
> real problem, we can always compress.
>

Are we sure DT will never be used for SPL?

Size is an issue for MPC85xx. The reset vector is at the very end, so 
the image is fixed at 768KB for most targets (maybe some still use 
512KB). There is limited room for additional stuff. We surely can 
increase the image size to 1MB to make room. So it is a concern but not 
a huge concern.

The device tree is maintained under kernel, keeping it updated for 
U-Boot will be a challenge, won't it?

York

[U-Boot] [RFC PATCH] arm: bootm: Boot kernel with U-Boot's FDT blob

[Ryan Harkin]

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


>> Size is a concern. U-Boot only uses a small portion of the device tree.
>> If the complete device tree is embedded into U-Boot, the size increases
>> quite a bit.
>
>
> Is size really a concern? At the end of the day we only care about the full
> dt for non-SPL U-Boot which is reasonably big anyway. And if it's a real
> problem, we can always compress.
>
>
> Alex
>
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [RFC PATCH] arm: bootm: Boot kernel with U-Boot's FDT blob

[Alexander Graf]

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.

Alex

[U-Boot] [RFC PATCH] arm: bootm: Boot kernel with U-Boot's FDT blob

[Alexander Graf]

On 01/10/2017 05:42 PM, york sun wrote:
> On 01/10/2017 08:35 AM, Alexander Graf 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.
>>>>
>>> Size is a concern. U-Boot only uses a small portion of the device tree.
>>> If the complete device tree is embedded into U-Boot, the size increases
>>> quite a bit.
>> Is size really a concern? At the end of the day we only care about the
>> full dt for non-SPL U-Boot which is reasonably big anyway. And if it's a
>> real problem, we can always compress.
>>
> Are we sure DT will never be used for SPL?

It is used for SPL today already (see firefly), but SPL can used a 
trimmed down version of device tree that only contains devices u-boot 
cares about.

> Size is an issue for MPC85xx. The reset vector is at the very end, so
> the image is fixed at 768KB for most targets (maybe some still use
> 512KB). There is limited room for additional stuff. We surely can
> increase the image size to 1MB to make room. So it is a concern but not
> a huge concern.
>
> The device tree is maintained under kernel, keeping it updated for
> U-Boot will be a challenge, won't it?

I hope it won't stay in the kernel tree forever. There have been 
discussions to move it into a separate tree for a while. On non-embedded 
devices (SPARC systems, POWER servers) device trees are *much* more 
stable than in the embedded Linux dominated world. Maybe it'll mature 
one day :).


Alex

[U-Boot] [RFC PATCH] arm: bootm: Boot kernel with U-Boot's FDT blob

[Ryan Harkin]

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
>

[U-Boot] [RFC PATCH] arm: bootm: Boot kernel with U-Boot's FDT blob

[Stephen Warren]

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.

[U-Boot] [RFC PATCH] arm: bootm: Boot kernel with U-Boot's FDT blob

[Michal Simek]

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

[U-Boot] [RFC PATCH] arm: bootm: Boot kernel with U-Boot's FDT blob

[Mark Rutland]

On Tue, Jan 10, 2017 at 05:17:07PM +0000, Ryan Harkin wrote:
> On 10 January 2017 at 16:58, Alexander Graf <agraf@suse.de> wrote:
> > On 01/10/2017 05:47 PM, Ryan Harkin wrote:

> >> 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 ;-)

To be fair, the *upstream* DTs for ARM Ltd platforms are relatively
stable. I must assume you're talking about random platform trees from
elsewhere, which it's not fair to blame the EDK2 or Linux communities
for. ;)

Looking at the git log for arch/arm64/boot/dts/arm, most updates are
simply adding new descriptions, so a DTB from a year ago should work
just fine with mainline (modulo the Juno PCI window issue, which was a
DTB bug). Upgrading kernel shouldn't require a DTB upgrade to see
equivalent functionality.

It's certainly not great that those aren't in a separate canonical repo,
but in terms of stability we are largely there, random *not upstream*
platform trees notwithstanding. We'll never get complete from day one,
so some updates over time are a fact of life, but we are in the position
to ship something that continues to work...

Thanks,
Mark.

[U-Boot] [RFC PATCH] arm: bootm: Boot kernel with U-Boot's FDT blob

[Jon Medhurst]

On Tue, 2017-01-10 at 18:34 +0000, Mark Rutland wrote:
> Looking at the git log for arch/arm64/boot/dts/arm, most updates are
> simply adding new descriptions, so a DTB from a year ago should work
> just fine with mainline (modulo the Juno PCI window issue, which was a
> DTB bug). Upgrading kernel shouldn't require a DTB upgrade to see
> equivalent functionality.

But if you want the new functionality in the kernel, why should you be
forced to wait for the bootloader to catch up (or do that work yourself)
then upgrade to that new bootloader version??And what about the poor
devs working on that new functionality, they're going to need to use not
upstream device-trees. Then there's all the firmware and system
configuration stuff that's in device-tree.

Basically, in the real world, devive-tree is a system configuration file
you need to hack to get all the pieces you're lumbered with to work
together and if you don't have control of it's contents you're stuffed.

(Well, we're stuffed anyway with the umpteen layers of
OSes/firmware/hypervisors all struggling for control of every computer
system.)

-- 
Tixy

[U-Boot] [RFC PATCH] arm: bootm: Boot kernel with U-Boot's FDT blob

[Lokesh Vutla]

On Tuesday 10 January 2017 06:28 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.
> 
> ---
>  arch/arm/lib/bootm.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
> index 43cc83ec95b6..9740045b0094 100644
> --- a/arch/arm/lib/bootm.c
> +++ b/arch/arm/lib/bootm.c
> @@ -245,6 +245,20 @@ static void boot_prep_linux(bootm_headers_t *images)
>  		}
>  		setup_board_tags(&params);
>  		setup_end_tag(gd->bd);
> +	} else if (IS_ENABLED(CONFIG_OF_CONTROL)) {
> +#ifdef CONFIG_OF_LIBFDT
> +		images->ft_addr = (char *)getenv_hex("fdtcontroladdr", 0);

If your intent is to use U-Boot's fdt as fallback, why can't we just use
gd->fdt_blob instead of getting from env?

IMO, this is not the right place to get the fallback fdt. Instead it
should fallback at bootm_get_fdt() so that other parameters like
images->ft_length is also updated. Can you try the following diff?

diff --git a/common/image-fdt.c b/common/image-fdt.c
index e7540be8d6..f8714b3702 100644
--- a/common/image-fdt.c
+++ b/common/image-fdt.c
@@ -238,7 +238,6 @@ int boot_get_fdt(int flag, int argc, char * const
argv[], uint8_t arch,
 	int		fdt_noffset;
 #endif
 	const char *select = NULL;
-	int		ok_no_fdt = 0;

 	*of_flat_tree = NULL;
 	*of_size = 0;
@@ -311,7 +310,7 @@ int boot_get_fdt(int flag, int argc, char * const
argv[], uint8_t arch,
 			       fdt_addr);
 			fdt_hdr = image_get_fdt(fdt_addr);
 			if (!fdt_hdr)
-				goto no_fdt;
+				goto fallback_fdt;

 			/*
 			 * move image data to the load address,
@@ -381,7 +380,7 @@ int boot_get_fdt(int flag, int argc, char * const
argv[], uint8_t arch,
 			break;
 		default:
 			puts("ERROR: Did not find a cmdline Flattened Device Tree\n");
-			goto no_fdt;
+			goto fallback_fdt;
 		}

 		printf("   Booting using the fdt blob at %#08lx\n", fdt_addr);
@@ -415,11 +414,17 @@ int boot_get_fdt(int flag, int argc, char * const
argv[], uint8_t arch,
 			}
 		} else {
 			debug("## No Flattened Device Tree\n");
-			goto no_fdt;
+			goto fallback_fdt;
 		}
 	} else {
 		debug("## No Flattened Device Tree\n");
-		goto no_fdt;
+		goto fallback_fdt;
+	}
+
+fallback_fdt:
+	if (!fdt_blob) {
+		printf("## Using U-boot's fdt to boot kernel\n");
+		fdt_blob = (char *)gd->fdt_blob;
 	}

 	*of_flat_tree = fdt_blob;
@@ -429,12 +434,10 @@ int boot_get_fdt(int flag, int argc, char * const
argv[], uint8_t arch,

 	return 0;

-no_fdt:
-	ok_no_fdt = 1;
 error:
 	*of_flat_tree = NULL;
 	*of_size = 0;
-	if (!select && ok_no_fdt) {
+	if (!select) {
 		debug("Continuing to boot without FDT\n");
 		return 0;
 	}

Thanks and regards,
Lokesh

[U-Boot] [RFC PATCH] arm: bootm: Boot kernel with U-Boot's FDT blob

[Michal Simek]

On 11.1.2017 06:19, Lokesh Vutla wrote:
> 
> 
> On Tuesday 10 January 2017 06:28 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.
>>
>> ---
>>  arch/arm/lib/bootm.c | 14 ++++++++++++++
>>  1 file changed, 14 insertions(+)
>>
>> diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
>> index 43cc83ec95b6..9740045b0094 100644
>> --- a/arch/arm/lib/bootm.c
>> +++ b/arch/arm/lib/bootm.c
>> @@ -245,6 +245,20 @@ static void boot_prep_linux(bootm_headers_t *images)
>>  		}
>>  		setup_board_tags(&params);
>>  		setup_end_tag(gd->bd);
>> +	} else if (IS_ENABLED(CONFIG_OF_CONTROL)) {
>> +#ifdef CONFIG_OF_LIBFDT
>> +		images->ft_addr = (char *)getenv_hex("fdtcontroladdr", 0);
> 
> If your intent is to use U-Boot's fdt as fallback, why can't we just use
> gd->fdt_blob instead of getting from env?

Not an issue to use gd->fdt_block instead but I expect we should copy it
to the different location too.

> 
> IMO, this is not the right place to get the fallback fdt. Instead it
> should fallback at bootm_get_fdt() so that other parameters like
> images->ft_length is also updated. Can you try the following diff?

Not a problem to move it to this position.

I have tried it and system is not booting.

> 
> diff --git a/common/image-fdt.c b/common/image-fdt.c
> index e7540be8d6..f8714b3702 100644
> --- a/common/image-fdt.c
> +++ b/common/image-fdt.c
> @@ -238,7 +238,6 @@ int boot_get_fdt(int flag, int argc, char * const
> argv[], uint8_t arch,
>  	int		fdt_noffset;
>  #endif
>  	const char *select = NULL;
> -	int		ok_no_fdt = 0;
> 
>  	*of_flat_tree = NULL;
>  	*of_size = 0;
> @@ -311,7 +310,7 @@ int boot_get_fdt(int flag, int argc, char * const
> argv[], uint8_t arch,
>  			       fdt_addr);
>  			fdt_hdr = image_get_fdt(fdt_addr);
>  			if (!fdt_hdr)
> -				goto no_fdt;
> +				goto fallback_fdt;
> 
>  			/*
>  			 * move image data to the load address,
> @@ -381,7 +380,7 @@ int boot_get_fdt(int flag, int argc, char * const
> argv[], uint8_t arch,
>  			break;
>  		default:
>  			puts("ERROR: Did not find a cmdline Flattened Device Tree\n");


This probably requires some code around not to show this error message
because it should be valid boot option.

> -			goto no_fdt;
> +			goto fallback_fdt;
>  		}
> 
>  		printf("   Booting using the fdt blob at %#08lx\n", fdt_addr);
> @@ -415,11 +414,17 @@ int boot_get_fdt(int flag, int argc, char * const
> argv[], uint8_t arch,
>  			}
>  		} else {
>  			debug("## No Flattened Device Tree\n");
> -			goto no_fdt;
> +			goto fallback_fdt;
>  		}
>  	} else {
>  		debug("## No Flattened Device Tree\n");
> -		goto no_fdt;
> +		goto fallback_fdt;
> +	}
> +
> +fallback_fdt:
> +	if (!fdt_blob) {
> +		printf("## Using U-boot's fdt to boot kernel\n");
> +		fdt_blob = (char *)gd->fdt_blob;
>  	}
> 
>  	*of_flat_tree = fdt_blob;
> @@ -429,12 +434,10 @@ int boot_get_fdt(int flag, int argc, char * const
> argv[], uint8_t arch,
> 
>  	return 0;
> 
> -no_fdt:
> -	ok_no_fdt = 1;
>  error:
>  	*of_flat_tree = NULL;
>  	*of_size = 0;
> -	if (!select && ok_no_fdt) {
> +	if (!select) {
>  		debug("Continuing to boot without FDT\n");
>  		return 0;
>  	}
> 
> Thanks and regards,
> Lokesh
> 

Thanks,
Michal

[U-Boot] [RFC PATCH] arm: bootm: Boot kernel with U-Boot's FDT blob

[Lokesh Vutla]

On Wednesday 11 January 2017 12:50 PM, Michal Simek wrote:
> On 11.1.2017 06:19, Lokesh Vutla wrote:
>>
>>
>> On Tuesday 10 January 2017 06:28 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.
>>>
>>> ---
>>>  arch/arm/lib/bootm.c | 14 ++++++++++++++
>>>  1 file changed, 14 insertions(+)
>>>
>>> diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
>>> index 43cc83ec95b6..9740045b0094 100644
>>> --- a/arch/arm/lib/bootm.c
>>> +++ b/arch/arm/lib/bootm.c
>>> @@ -245,6 +245,20 @@ static void boot_prep_linux(bootm_headers_t *images)
>>>  		}
>>>  		setup_board_tags(&params);
>>>  		setup_end_tag(gd->bd);
>>> +	} else if (IS_ENABLED(CONFIG_OF_CONTROL)) {
>>> +#ifdef CONFIG_OF_LIBFDT
>>> +		images->ft_addr = (char *)getenv_hex("fdtcontroladdr", 0);
>>
>> If your intent is to use U-Boot's fdt as fallback, why can't we just use
>> gd->fdt_blob instead of getting from env?
> 
> Not an issue to use gd->fdt_block instead but I expect we should copy it
> to the different location too.
> 
>>
>> IMO, this is not the right place to get the fallback fdt. Instead it
>> should fallback at bootm_get_fdt() so that other parameters like
>> images->ft_length is also updated. Can you try the following diff?
> 
> Not a problem to move it to this position.
> 
> I have tried it and system is not booting.

Hmm.. not sure if I am missing something. I am able to boot with this
change and not loading any dtb: http://pastebin.ubuntu.com/23780811/

Thanks and regards,
Lokesh

> 
>>
>> diff --git a/common/image-fdt.c b/common/image-fdt.c
>> index e7540be8d6..f8714b3702 100644
>> --- a/common/image-fdt.c
>> +++ b/common/image-fdt.c
>> @@ -238,7 +238,6 @@ int boot_get_fdt(int flag, int argc, char * const
>> argv[], uint8_t arch,
>>  	int		fdt_noffset;
>>  #endif
>>  	const char *select = NULL;
>> -	int		ok_no_fdt = 0;
>>
>>  	*of_flat_tree = NULL;
>>  	*of_size = 0;
>> @@ -311,7 +310,7 @@ int boot_get_fdt(int flag, int argc, char * const
>> argv[], uint8_t arch,
>>  			       fdt_addr);
>>  			fdt_hdr = image_get_fdt(fdt_addr);
>>  			if (!fdt_hdr)
>> -				goto no_fdt;
>> +				goto fallback_fdt;
>>
>>  			/*
>>  			 * move image data to the load address,
>> @@ -381,7 +380,7 @@ int boot_get_fdt(int flag, int argc, char * const
>> argv[], uint8_t arch,
>>  			break;
>>  		default:
>>  			puts("ERROR: Did not find a cmdline Flattened Device Tree\n");
> 
> 
> This probably requires some code around not to show this error message
> because it should be valid boot option.
> 
>> -			goto no_fdt;
>> +			goto fallback_fdt;
>>  		}
>>
>>  		printf("   Booting using the fdt blob at %#08lx\n", fdt_addr);
>> @@ -415,11 +414,17 @@ int boot_get_fdt(int flag, int argc, char * const
>> argv[], uint8_t arch,
>>  			}
>>  		} else {
>>  			debug("## No Flattened Device Tree\n");
>> -			goto no_fdt;
>> +			goto fallback_fdt;
>>  		}
>>  	} else {
>>  		debug("## No Flattened Device Tree\n");
>> -		goto no_fdt;
>> +		goto fallback_fdt;
>> +	}
>> +
>> +fallback_fdt:
>> +	if (!fdt_blob) {
>> +		printf("## Using U-boot's fdt to boot kernel\n");
>> +		fdt_blob = (char *)gd->fdt_blob;
>>  	}
>>
>>  	*of_flat_tree = fdt_blob;
>> @@ -429,12 +434,10 @@ int boot_get_fdt(int flag, int argc, char * const
>> argv[], uint8_t arch,
>>
>>  	return 0;
>>
>> -no_fdt:
>> -	ok_no_fdt = 1;
>>  error:
>>  	*of_flat_tree = NULL;
>>  	*of_size = 0;
>> -	if (!select && ok_no_fdt) {
>> +	if (!select) {
>>  		debug("Continuing to boot without FDT\n");
>>  		return 0;
>>  	}
>>
>> Thanks and regards,
>> Lokesh
>>
> 
> Thanks,
> Michal
> 

[U-Boot] [RFC PATCH] arm: bootm: Boot kernel with U-Boot's FDT blob

[Mark Rutland]

On Tue, Jan 10, 2017 at 06:50:19PM +0000, Jon Medhurst (Tixy) wrote:
> On Tue, 2017-01-10 at 18:34 +0000, Mark Rutland wrote:
> > Looking at the git log for arch/arm64/boot/dts/arm, most updates are
> > simply adding new descriptions, so a DTB from a year ago should work
> > just fine with mainline (modulo the Juno PCI window issue, which was a
> > DTB bug). Upgrading kernel shouldn't require a DTB upgrade to see
> > equivalent functionality.
> 
> But if you want the new functionality in the kernel, why should you be
> forced to wait for the bootloader to catch up (or do that work yourself)
> then upgrade to that new bootloader version??And what about the poor
> devs working on that new functionality, they're going to need to use not
> upstream device-trees. Then there's all the firmware and system
> configuration stuff that's in device-tree.

Developers working on low-level stuff will always need to be able to
override/upgrade/etc. I am certainly not arguing to remove those
capabilities.

The key point is that it is possible to provide a baseline DTB that is
good enough for most users, and will work with future kernels.

We're unlikely to get to a state where DTBs are perfect and complete
from day one. We can have something that remains usable.

Thanks,
Mark.

[U-Boot] [RFC PATCH] arm: bootm: Boot kernel with U-Boot's FDT blob

[Ryan Harkin]

On 12 January 2017 at 12:25, Mark Rutland <mark.rutland@arm.com> wrote:
> On Tue, Jan 10, 2017 at 06:50:19PM +0000, Jon Medhurst (Tixy) wrote:
>> On Tue, 2017-01-10 at 18:34 +0000, Mark Rutland wrote:
>> > Looking at the git log for arch/arm64/boot/dts/arm, most updates are
>> > simply adding new descriptions, so a DTB from a year ago should work
>> > just fine with mainline (modulo the Juno PCI window issue, which was a
>> > DTB bug). Upgrading kernel shouldn't require a DTB upgrade to see
>> > equivalent functionality.
>>
>> But if you want the new functionality in the kernel, why should you be
>> forced to wait for the bootloader to catch up (or do that work yourself)
>> then upgrade to that new bootloader version? And what about the poor
>> devs working on that new functionality, they're going to need to use not
>> upstream device-trees. Then there's all the firmware and system
>> configuration stuff that's in device-tree.
>
> Developers working on low-level stuff will always need to be able to
> override/upgrade/etc. I am certainly not arguing to remove those
> capabilities.
>
> The key point is that it is possible to provide a baseline DTB that is
> good enough for most users, and will work with future kernels.
>
> We're unlikely to get to a state where DTBs are perfect and complete
> from day one. We can have something that remains usable.
>

I hope it stays that way. Most of my users are either on 3.18 or 4.4.
And they are incompatible with each other w.r.t. DTBs to the point
where one won't even post a banner message with the other's DTB.

> Thanks,
> Mark.

[U-Boot] [RFC PATCH] arm: bootm: Boot kernel with U-Boot's FDT blob

[Mark Rutland]

On Thu, Jan 12, 2017 at 01:47:32PM +0000, Ryan Harkin wrote:
> On 12 January 2017 at 12:25, Mark Rutland <mark.rutland@arm.com> wrote:
> > On Tue, Jan 10, 2017 at 06:50:19PM +0000, Jon Medhurst (Tixy) wrote:
> >> On Tue, 2017-01-10 at 18:34 +0000, Mark Rutland wrote:
> >> > Looking at the git log for arch/arm64/boot/dts/arm, most updates are
> >> > simply adding new descriptions, so a DTB from a year ago should work
> >> > just fine with mainline (modulo the Juno PCI window issue, which was a
> >> > DTB bug). Upgrading kernel shouldn't require a DTB upgrade to see
> >> > equivalent functionality.

> > The key point is that it is possible to provide a baseline DTB that is
> > good enough for most users, and will work with future kernels.
> >
> > We're unlikely to get to a state where DTBs are perfect and complete
> > from day one. We can have something that remains usable.
> 
> I hope it stays that way. Most of my users are either on 3.18 or 4.4.
> And they are incompatible with each other w.r.t. DTBs to the point
> where one won't even post a banner message with the other's DTB.

Interesting. Just to check, do you mean v3.19? There was no upstream
Juno DT in v3.18.

Unfortunately, I can't spot any DT changes between v3.19 and v4.4 that
would obviously break compatibility such that serial wouldn't work.

If you have those kernels && DTBs to hand, are you able to take a look
if passing "earlycon=pl011,0x7ff80000"?

I know that the ARM Software linux repo shipped a broken DT, along with
some kernel modifications which bodge around that (specifically, they
exposed a broken MMIO timer as functional). IIRC, Poking that would
bring down the kernel, before the serial wa up.

Is your v3.18 DT the old ARM Software repo's Juno DT?

Thanks,
Mark.

[U-Boot] [RFC PATCH] arm: bootm: Boot kernel with U-Boot's FDT blob

[Ryan Harkin]

On 13 January 2017 at 14:19, Mark Rutland <mark.rutland@arm.com> wrote:
> On Thu, Jan 12, 2017 at 01:47:32PM +0000, Ryan Harkin wrote:
>> On 12 January 2017 at 12:25, Mark Rutland <mark.rutland@arm.com> wrote:
>> > On Tue, Jan 10, 2017 at 06:50:19PM +0000, Jon Medhurst (Tixy) wrote:
>> >> On Tue, 2017-01-10 at 18:34 +0000, Mark Rutland wrote:
>> >> > Looking at the git log for arch/arm64/boot/dts/arm, most updates are
>> >> > simply adding new descriptions, so a DTB from a year ago should work
>> >> > just fine with mainline (modulo the Juno PCI window issue, which was a
>> >> > DTB bug). Upgrading kernel shouldn't require a DTB upgrade to see
>> >> > equivalent functionality.
>
>> > The key point is that it is possible to provide a baseline DTB that is
>> > good enough for most users, and will work with future kernels.
>> >
>> > We're unlikely to get to a state where DTBs are perfect and complete
>> > from day one. We can have something that remains usable.
>>
>> I hope it stays that way. Most of my users are either on 3.18 or 4.4.
>> And they are incompatible with each other w.r.t. DTBs to the point
>> where one won't even post a banner message with the other's DTB.
>
> Interesting. Just to check, do you mean v3.19? There was no upstream
> Juno DT in v3.18.
>
> Unfortunately, I can't spot any DT changes between v3.19 and v4.4 that
> would obviously break compatibility such that serial wouldn't work.
>
> If you have those kernels && DTBs to hand, are you able to take a look
> if passing "earlycon=pl011,0x7ff80000"?
>
> I know that the ARM Software linux repo shipped a broken DT, along with
> some kernel modifications which bodge around that (specifically, they
> exposed a broken MMIO timer as functional). IIRC, Poking that would
> bring down the kernel, before the serial wa up.
>
> Is your v3.18 DT the old ARM Software repo's Juno DT?
>

I don't have any of the data points any more, but it wasn't due to the
ARMLT tree, which tends to be stable/reliable. It was mostly debian vs
upstream.


> Thanks,
> Mark.