| Message ID | 2b4f0cab210294fccacd639c13cae038ca842f6b.1484053094.git.michal.simek@xilinx.com |
|---|---|
| State | RFC |
| Delegated to: | Tom Rini |
| Headers | show |
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(¶ms); > 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();
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
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
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
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
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
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
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@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot
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
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
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 >
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.
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
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.
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.)
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.
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.
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.
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.
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(¶ms); 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 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(+)