diff mbox series

[V3,2/2] scripts: dtc: Build fdtoverlay and fdtdump tools

Message ID 72c3a4f63dde3c172c11153e9a5b19fb6cdb4498.1610000585.git.viresh.kumar@linaro.org (mailing list archive)
State New, archived
Headers show
Series None | expand

Commit Message

Viresh Kumar Jan. 7, 2021, 6:25 a.m. UTC
We will start building overlays for platforms soon in the kernel and
would need these tools going forward. Lets start building them.

The fdtoverlay program applies (or merges) one ore more overlay dtb
blobs to a base dtb blob. The kernel build system would later use
fdtoverlay to generate the overlaid blobs based on platform specific
configurations.

The fdtdump program prints a readable version of a flat device-tree
file. This is a very useful tool to analyze the details of the overlay's
dtb and the final dtb produced by fdtoverlay after applying the
overlay's dtb to a base dtb.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
V3:
- Updated log
- Remove libfdt_dir

 scripts/dtc/Makefile | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

Comments

Frank Rowand Jan. 12, 2021, 12:44 a.m. UTC | #1
On 1/7/21 12:25 AM, Viresh Kumar wrote:
> We will start building overlays for platforms soon in the kernel and
> would need these tools going forward. Lets start building them.
> 
> The fdtoverlay program applies (or merges) one ore more overlay dtb
> blobs to a base dtb blob. The kernel build system would later use
> fdtoverlay to generate the overlaid blobs based on platform specific
> configurations.
> 
> The fdtdump program prints a readable version of a flat device-tree
> file. This is a very useful tool to analyze the details of the overlay's
> dtb and the final dtb produced by fdtoverlay after applying the
> overlay's dtb to a base dtb.

You can calso dump an FDT with:

   dtc -O dts XXX.dtb

Is this sufficient for the desired functionality, or is there something
additional in fdtdump that is needed?

If nothing additional needed, and there is no other justification for adding
another program, I would prefer to leave fdtdump out.

-Frank

> 
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> V3:
> - Updated log
> - Remove libfdt_dir
> 
>  scripts/dtc/Makefile | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/scripts/dtc/Makefile b/scripts/dtc/Makefile
> index 4852bf44e913..472ab8cd590c 100644
> --- a/scripts/dtc/Makefile
> +++ b/scripts/dtc/Makefile
> @@ -1,12 +1,17 @@
>  # SPDX-License-Identifier: GPL-2.0
>  # scripts/dtc makefile
>  
> -hostprogs-always-$(CONFIG_DTC)		+= dtc
> +hostprogs-always-$(CONFIG_DTC)		+= dtc fdtdump fdtoverlay
>  hostprogs-always-$(CHECK_DT_BINDING)	+= dtc
>  
>  dtc-objs	:= dtc.o flattree.o fstree.o data.o livetree.o treesource.o \
>  		   srcpos.o checks.o util.o
>  dtc-objs	+= dtc-lexer.lex.o dtc-parser.tab.o
> +fdtdump-objs	:= fdtdump.o util.o
> +
> +libfdt-objs	:= fdt.o fdt_ro.o fdt_wip.o fdt_sw.o fdt_rw.o fdt_strerror.o fdt_empty_tree.o fdt_addresses.o fdt_overlay.o
> +libfdt		= $(addprefix libfdt/,$(libfdt-objs))
> +fdtoverlay-objs	:= $(libfdt) fdtoverlay.o util.o
>  
>  # Source files need to get at the userspace version of libfdt_env.h to compile
>  HOST_EXTRACFLAGS += -I $(srctree)/$(src)/libfdt
>
Frank Rowand Jan. 12, 2021, 12:55 a.m. UTC | #2
Hi Viresh,

I may have an email hiccup, but I don't see a "[PATCH V3 1/2]" email, I
only see this "V3 2/2" email.

Please start each new version of a patch series as a stand alone email
instead of a reply to an email in a previous version of the series.
That way each patch series discussion stands out as a separate thread.

Also each version of the patch series needs to include all of the patches
in the current version, even if they are unchanged from the previous
version.

Thanks,

Frank

On 1/7/21 12:25 AM, Viresh Kumar wrote:
> We will start building overlays for platforms soon in the kernel and
> would need these tools going forward. Lets start building them.
> 
> The fdtoverlay program applies (or merges) one ore more overlay dtb
> blobs to a base dtb blob. The kernel build system would later use
> fdtoverlay to generate the overlaid blobs based on platform specific
> configurations.
> 
> The fdtdump program prints a readable version of a flat device-tree
> file. This is a very useful tool to analyze the details of the overlay's
> dtb and the final dtb produced by fdtoverlay after applying the
> overlay's dtb to a base dtb.
> 
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> V3:
> - Updated log
> - Remove libfdt_dir
> 
>  scripts/dtc/Makefile | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/scripts/dtc/Makefile b/scripts/dtc/Makefile
> index 4852bf44e913..472ab8cd590c 100644
> --- a/scripts/dtc/Makefile
> +++ b/scripts/dtc/Makefile
> @@ -1,12 +1,17 @@
>  # SPDX-License-Identifier: GPL-2.0
>  # scripts/dtc makefile
>  
> -hostprogs-always-$(CONFIG_DTC)		+= dtc
> +hostprogs-always-$(CONFIG_DTC)		+= dtc fdtdump fdtoverlay
>  hostprogs-always-$(CHECK_DT_BINDING)	+= dtc
>  
>  dtc-objs	:= dtc.o flattree.o fstree.o data.o livetree.o treesource.o \
>  		   srcpos.o checks.o util.o
>  dtc-objs	+= dtc-lexer.lex.o dtc-parser.tab.o
> +fdtdump-objs	:= fdtdump.o util.o
> +
> +libfdt-objs	:= fdt.o fdt_ro.o fdt_wip.o fdt_sw.o fdt_rw.o fdt_strerror.o fdt_empty_tree.o fdt_addresses.o fdt_overlay.o
> +libfdt		= $(addprefix libfdt/,$(libfdt-objs))
> +fdtoverlay-objs	:= $(libfdt) fdtoverlay.o util.o
>  
>  # Source files need to get at the userspace version of libfdt_env.h to compile
>  HOST_EXTRACFLAGS += -I $(srctree)/$(src)/libfdt
>
Viresh Kumar Jan. 12, 2021, 4:48 a.m. UTC | #3
On 11-01-21, 18:55, Frank Rowand wrote:
> Hi Viresh,
> 
> I may have an email hiccup,

No you don't, I just sent the 2nd patch alone.

> but I don't see a "[PATCH V3 1/2]" email, I
> only see this "V3 2/2" email.
> 
> Please start each new version of a patch series as a stand alone email
> instead of a reply to an email in a previous version of the series.
> That way each patch series discussion stands out as a separate thread.
> 
> Also each version of the patch series needs to include all of the patches
> in the current version, even if they are unchanged from the previous
> version.

Sure, just that some people like to just bump individual patches until
the time there is an agreement and then send the whole stuff together.

I will send the whole stuff going forward whenever the versions
change.

Thanks Frank.
Viresh Kumar Jan. 12, 2021, 5:08 a.m. UTC | #4
On 11-01-21, 18:44, Frank Rowand wrote:
> On 1/7/21 12:25 AM, Viresh Kumar wrote:
> > We will start building overlays for platforms soon in the kernel and
> > would need these tools going forward. Lets start building them.
> > 
> > The fdtoverlay program applies (or merges) one ore more overlay dtb
> > blobs to a base dtb blob. The kernel build system would later use
> > fdtoverlay to generate the overlaid blobs based on platform specific
> > configurations.
> > 
> > The fdtdump program prints a readable version of a flat device-tree
> > file. This is a very useful tool to analyze the details of the overlay's
> > dtb and the final dtb produced by fdtoverlay after applying the
> > overlay's dtb to a base dtb.
> 
> You can calso dump an FDT with:
> 
>    dtc -O dts XXX.dtb
> 
> Is this sufficient for the desired functionality, or is there something
> additional in fdtdump that is needed?

Not for my usecase at least.

> If nothing additional needed, and there is no other justification for adding
> another program, I would prefer to leave fdtdump out.

Okay, then I will also remove the stale version of fdtdump which is
already there in kernel since a long time.
Frank Rowand Jan. 12, 2021, 6:34 p.m. UTC | #5
On 1/11/21 11:08 PM, Viresh Kumar wrote:
> On 11-01-21, 18:44, Frank Rowand wrote:
>> On 1/7/21 12:25 AM, Viresh Kumar wrote:
>>> We will start building overlays for platforms soon in the kernel and
>>> would need these tools going forward. Lets start building them.
>>>
>>> The fdtoverlay program applies (or merges) one ore more overlay dtb
>>> blobs to a base dtb blob. The kernel build system would later use
>>> fdtoverlay to generate the overlaid blobs based on platform specific
>>> configurations.
>>>
>>> The fdtdump program prints a readable version of a flat device-tree
>>> file. This is a very useful tool to analyze the details of the overlay's
>>> dtb and the final dtb produced by fdtoverlay after applying the
>>> overlay's dtb to a base dtb.
>>
>> You can calso dump an FDT with:
>>
>>    dtc -O dts XXX.dtb
>>
>> Is this sufficient for the desired functionality, or is there something
>> additional in fdtdump that is needed?
> 

comment 1:

> Not for my usecase at least.

> 
>> If nothing additional needed, and there is no other justification for adding
>> another program, I would prefer to leave fdtdump out.
> 

comment 2:

> Okay, then I will also remove the stale version of fdtdump which is
> already there in kernel since a long time.
> 

I'm confused.  I read comment 1 as saying that fdtdump does provide a feature
that you need to analyze the dtb created by fdtoverlay.  But I read comment 2
as implying that you are accepting that fdtdump will not be added to the
Linux kernel source.

-Frank
Viresh Kumar Jan. 13, 2021, 4:55 a.m. UTC | #6
On 12-01-21, 12:34, Frank Rowand wrote:
> On 1/11/21 11:08 PM, Viresh Kumar wrote:
> > On 11-01-21, 18:44, Frank Rowand wrote:
> >> On 1/7/21 12:25 AM, Viresh Kumar wrote:
> >>> We will start building overlays for platforms soon in the kernel and
> >>> would need these tools going forward. Lets start building them.
> >>>
> >>> The fdtoverlay program applies (or merges) one ore more overlay dtb
> >>> blobs to a base dtb blob. The kernel build system would later use
> >>> fdtoverlay to generate the overlaid blobs based on platform specific
> >>> configurations.
> >>>
> >>> The fdtdump program prints a readable version of a flat device-tree
> >>> file. This is a very useful tool to analyze the details of the overlay's
> >>> dtb and the final dtb produced by fdtoverlay after applying the
> >>> overlay's dtb to a base dtb.
> >>
> >> You can calso dump an FDT with:
> >>
> >>    dtc -O dts XXX.dtb
> >>
> >> Is this sufficient for the desired functionality, or is there something
> >> additional in fdtdump that is needed?
> > 
> 
> comment 1:
> 
> > Not for my usecase at least.

I answered this question here (and yes I could have been more clear):

"is there something additional in fdtdump that is needed?"

> 
> > 
> >> If nothing additional needed, and there is no other justification for adding
> >> another program, I would prefer to leave fdtdump out.
> > 
> 
> comment 2:
> 
> > Okay, then I will also remove the stale version of fdtdump which is
> > already there in kernel since a long time.
> > 
> 
> I'm confused.  I read comment 1 as saying that fdtdump does provide a feature
> that you need to analyze the dtb created by fdtoverlay.  But I read comment 2
> as implying that you are accepting that fdtdump will not be added to the
> Linux kernel source.
diff mbox series

Patch

diff --git a/scripts/dtc/Makefile b/scripts/dtc/Makefile
index 4852bf44e913..472ab8cd590c 100644
--- a/scripts/dtc/Makefile
+++ b/scripts/dtc/Makefile
@@ -1,12 +1,17 @@ 
 # SPDX-License-Identifier: GPL-2.0
 # scripts/dtc makefile
 
-hostprogs-always-$(CONFIG_DTC)		+= dtc
+hostprogs-always-$(CONFIG_DTC)		+= dtc fdtdump fdtoverlay
 hostprogs-always-$(CHECK_DT_BINDING)	+= dtc
 
 dtc-objs	:= dtc.o flattree.o fstree.o data.o livetree.o treesource.o \
 		   srcpos.o checks.o util.o
 dtc-objs	+= dtc-lexer.lex.o dtc-parser.tab.o
+fdtdump-objs	:= fdtdump.o util.o
+
+libfdt-objs	:= fdt.o fdt_ro.o fdt_wip.o fdt_sw.o fdt_rw.o fdt_strerror.o fdt_empty_tree.o fdt_addresses.o fdt_overlay.o
+libfdt		= $(addprefix libfdt/,$(libfdt-objs))
+fdtoverlay-objs	:= $(libfdt) fdtoverlay.o util.o
 
 # Source files need to get at the userspace version of libfdt_env.h to compile
 HOST_EXTRACFLAGS += -I $(srctree)/$(src)/libfdt