Skip to content

patches to allow DTB to be appended to the ARM zImage

Tony Lindgren linux-arm-kernel linux-arm-msm linux-devicetree 1 version New

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 Latest0 of 3 patches 0 repliesNew

Patches in v1 No applies recorded yet

None of the 3 patches the cover letter announces are in this archive.

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.

Read the v1 thread

Cover letter [PATCH 0/3] patches to allow DTB to be appended to the ARM zImage
Quoted 14 lines · Russell King - ARM Linux
Quoted 13 lines · Nicolas Pitre
Quoted 11 lines · Tony Lindgren
Quoted 10 lines · Nicolas Pitre
Quoted 7 lines · Russell King - ARM Linux

I don't see this as a sustainable way forward. If we're going to move a particular SoC over to DT, we need to move the entire SoC over. We can't do this half-heartedly.

And that means we _must_ deal with accepting ATAGs from existing boot loaders, with that information taking precidence over the DT blob supplied with the kernel.

Quoted 8 lines
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines

Well... OK. Let's see how this can be accommodated with the existing patch floating around doing that.

I agree that we need to parse the user configurable ATAGs to support existing hardware properly. Otherwise we have edit the .dts for each board to change the user configurable things, which is not nice for distros.

You mean "existing bootloaders", right?

Yes that's correct. There are some bootloaders that will never get updated as they're proprietary and signed.

Quoted 7 lines
Quoted 2 lines

Updated bootloaders should translate user configurable information into proper DT records and pass the resulting DTB to the kernel separately.

OMAP is one of the code bases where this really matters - they have a _lot_ of existing platforms with boot loaders which do the ATAG stuff. They also have a lot of code in arch/arm that needs to be converted to a DT representation.

I think we're OK to start using appended device tree support for mach-omap2 once we have some real data. The only thing missing is the support for parsing ATAGs for cmdline and other user configurable stuff.

Of course that means that we need to set the DT_APPEND support on in the omap2plus_defconfig. And I'm assuming that the DT_APPEND support works also with bootloader passed DT data if the appended data is empty..

Quoted 10 lines

With the current situation where you can have either ATAGs or DT but not both, they're currently facing either having to break all the existing platforms by ignoring the ATAGs _or_ keeping two copies of a considerable amount of data - one in DT form and one in its existing form.

At present, DT can only be used sensibly on brand new SoCs where there are no existing platforms with ATAG based boot loaders to worry about. As things stand at present, even with your patch series, existing SoCs have no viable path to transition to DT.

The situation is not actually not that bad, but currently changes to the .dts file are needed. So some parsing of user configurable ATAGs is badly needed.

Regards,

Tony