* ELC CFP deadline is Jan 9
From: Tim Bird @ 2015-01-08 22:45 UTC (permalink / raw)
To: linux-embedded@vger.kernel.org
Hi embedded Linux developers,
This is quick reminder that the deadline for the Call For Participation for
Embedded Linux Conference 2015 is January 9 (this Friday). The event
is on March 23-25 in San Jose, California.
Please make sure to propose something if you are interested in coming.
I'd write more, but I'm probably breaking list etiquette enough as it is... :-)
Check out the CFP for details:
http://events.linuxfoundation.org/events/embedded-linux-conference/program/cfp
-- Tim
^ permalink raw reply
* embedding dtb file into kernel
From: K Richard Pixley @ 2015-02-12 19:33 UTC (permalink / raw)
To: linux-embedded
I'm having trouble figuring out how to embed a dtb file into my kernel.
I'm thinking that there should be a standard, architecture independent
facility for this akin to initramfs, yes?
Could someone please either point me to the standard facility, relevant
doc, a currently building board that uses the standard facility, or
outline what needs to be done to do this with a new board?
If it matters, (I can't think why it would), I'm working with powerpc on
a 3.10 kernel. But if there are better facilities in other versions I'd
appreciate hearing about that too.
Thank you in advance.
--rich
^ permalink raw reply
* Re: embedding dtb file into kernel
From: Tim Bird @ 2015-02-12 22:01 UTC (permalink / raw)
To: K Richard Pixley, linux-embedded@vger.kernel.org
In-Reply-To: <54DD0018.7010409@graphitesystems.com>
On 02/12/2015 11:33 AM, K Richard Pixley wrote:
> I'm having trouble figuring out how to embed a dtb file into my kernel.
> I'm thinking that there should be a standard, architecture independent
> facility for this akin to initramfs, yes?
>
> Could someone please either point me to the standard facility, relevant
> doc, a currently building board that uses the standard facility, or
> outline what needs to be done to do this with a new board?
>
> If it matters, (I can't think why it would), I'm working with powerpc on
> a 3.10 kernel. But if there are better facilities in other versions I'd
> appreciate hearing about that too.
The normal method is just to cat the two files together, like so:
$ cat zImage <filename>.dtb > zImage_w_dtb
See https://community.freescale.com/thread/315543 for one example, on ARM.
I'm not sure what the status is for appended DTBs on powerpc, but it's
easy enough you can just try it and see what happens.
-- Tim
^ permalink raw reply
* Re: embedding dtb file into kernel
From: K Richard Pixley @ 2015-02-12 22:30 UTC (permalink / raw)
To: Tim Bird, linux-embedded@vger.kernel.org
In-Reply-To: <54DD22BF.4040607@sonymobile.com>
On 2/12/15 14:01 , Tim Bird wrote:
> On 02/12/2015 11:33 AM, K Richard Pixley wrote:
>> I'm having trouble figuring out how to embed a dtb file into my kernel.
>> I'm thinking that there should be a standard, architecture independent
>> facility for this akin to initramfs, yes?
>>
>> Could someone please either point me to the standard facility, relevant
>> doc, a currently building board that uses the standard facility, or
>> outline what needs to be done to do this with a new board?
>>
>> If it matters, (I can't think why it would), I'm working with powerpc on
>> a 3.10 kernel. But if there are better facilities in other versions I'd
>> appreciate hearing about that too.
> The normal method is just to cat the two files together, like so:
> $ cat zImage <filename>.dtb > zImage_w_dtb
>
> See https://community.freescale.com/thread/315543 for one example, on ARM.
> I'm not sure what the status is for appended DTBs on powerpc, but it's
> easy enough you can just try it and see what happens.
> -- Tim
Thanks!
How do I tell the kernel where to find that dtb? Is there a relevant
config option?
--rich
^ permalink raw reply
* Re: embedding dtb file into kernel
From: Tim Bird @ 2015-02-13 0:56 UTC (permalink / raw)
To: K Richard Pixley, linux-embedded@vger.kernel.org
In-Reply-To: <54DD296E.7080901@graphitesystems.com>
On 02/12/2015 02:30 PM, K Richard Pixley wrote:
> On 2/12/15 14:01 , Tim Bird wrote:
>> On 02/12/2015 11:33 AM, K Richard Pixley wrote:
>>> I'm having trouble figuring out how to embed a dtb file into my kernel.
>>> I'm thinking that there should be a standard, architecture independent
>>> facility for this akin to initramfs, yes?
>>>
>>> Could someone please either point me to the standard facility, relevant
>>> doc, a currently building board that uses the standard facility, or
>>> outline what needs to be done to do this with a new board?
>>>
>>> If it matters, (I can't think why it would), I'm working with powerpc on
>>> a 3.10 kernel. But if there are better facilities in other versions I'd
>>> appreciate hearing about that too.
>> The normal method is just to cat the two files together, like so:
>> $ cat zImage <filename>.dtb > zImage_w_dtb
>>
>> See https://community.freescale.com/thread/315543 for one example, on ARM.
>> I'm not sure what the status is for appended DTBs on powerpc, but it's
>> easy enough you can just try it and see what happens.
>> -- Tim
>
> Thanks!
>
> How do I tell the kernel where to find that dtb? Is there a relevant
> config option?
Usually you make the dtb from sources in the kernel.
I don't know how it works on powerpc, but on arm, the .dts
files are located in arch/arm/boot/dts, and you would make
the dtb for the corresponding "foo.dts" source
by typing:
$ make foo.dtb
-- Tim
^ permalink raw reply
* Re: embedding dtb file into kernel
From: Rob Landley @ 2015-02-13 6:10 UTC (permalink / raw)
To: Tim Bird, K Richard Pixley, linux-embedded@vger.kernel.org
In-Reply-To: <54DD4BAF.9040206@sonymobile.com>
On 02/12/2015 06:56 PM, Tim Bird wrote:
>
>
> On 02/12/2015 02:30 PM, K Richard Pixley wrote:
>> On 2/12/15 14:01 , Tim Bird wrote:
>>> On 02/12/2015 11:33 AM, K Richard Pixley wrote:
>>>> I'm having trouble figuring out how to embed a dtb file into my kernel.
>>>> I'm thinking that there should be a standard, architecture independent
>>>> facility for this akin to initramfs, yes?
>>>>
>>>> Could someone please either point me to the standard facility, relevant
>>>> doc, a currently building board that uses the standard facility, or
>>>> outline what needs to be done to do this with a new board?
>>>>
>>>> If it matters, (I can't think why it would), I'm working with powerpc on
>>>> a 3.10 kernel. But if there are better facilities in other versions I'd
>>>> appreciate hearing about that too.
>>> The normal method is just to cat the two files together, like so:
>>> $ cat zImage <filename>.dtb > zImage_w_dtb
>>>
>>> See https://community.freescale.com/thread/315543 for one example, on ARM.
>>> I'm not sure what the status is for appended DTBs on powerpc, but it's
>>> easy enough you can just try it and see what happens.
>>> -- Tim
>>
>> Thanks!
>>
>> How do I tell the kernel where to find that dtb? Is there a relevant
>> config option?
>
> Usually you make the dtb from sources in the kernel.
> I don't know how it works on powerpc, but on arm, the .dts
> files are located in arch/arm/boot/dts, and you would make
> the dtb for the corresponding "foo.dts" source
> by typing:
> $ make foo.dtb
It's probably somewhere in:
https://www.kernel.org/doc/Documentation/devicetree/booting-without-of.txt
Rob
^ permalink raw reply
* Re: embedding dtb file into kernel
From: Hugh Blemings @ 2015-02-13 6:15 UTC (permalink / raw)
To: Rob Landley, Tim Bird, K Richard Pixley,
linux-embedded@vger.kernel.org
In-Reply-To: <54DD9570.1080901@landley.net>
On 13/02/2015 17:10, Rob Landley wrote:
> On 02/12/2015 06:56 PM, Tim Bird wrote:
>>
>>
>> On 02/12/2015 02:30 PM, K Richard Pixley wrote:
>>> On 2/12/15 14:01 , Tim Bird wrote:
>>>> On 02/12/2015 11:33 AM, K Richard Pixley wrote:
>>>>> I'm having trouble figuring out how to embed a dtb file into my kernel.
>>>>> I'm thinking that there should be a standard, architecture independent
>>>>> facility for this akin to initramfs, yes?
>>>>>
>>>>> Could someone please either point me to the standard facility, relevant
>>>>> doc, a currently building board that uses the standard facility, or
>>>>> outline what needs to be done to do this with a new board?
>>>>>
>>>>> If it matters, (I can't think why it would), I'm working with powerpc on
>>>>> a 3.10 kernel. But if there are better facilities in other versions I'd
>>>>> appreciate hearing about that too.
>>>> The normal method is just to cat the two files together, like so:
>>>> $ cat zImage <filename>.dtb > zImage_w_dtb
>>>>
>>>> See https://community.freescale.com/thread/315543 for one example, on ARM.
>>>> I'm not sure what the status is for appended DTBs on powerpc, but it's
>>>> easy enough you can just try it and see what happens.
>>>> -- Tim
>>>
>>> Thanks!
>>>
>>> How do I tell the kernel where to find that dtb? Is there a relevant
>>> config option?
>>
>> Usually you make the dtb from sources in the kernel.
>> I don't know how it works on powerpc, but on arm, the .dts
>> files are located in arch/arm/boot/dts, and you would make
>> the dtb for the corresponding "foo.dts" source
>> by typing:
>> $ make foo.dtb
>
> It's probably somewhere in:
>
> https://www.kernel.org/doc/Documentation/devicetree/booting-without-of.txt
Worth pointing out the folk over in linuxppc-dev are usually pretty
friendly, may be able to help out with this too.
https://lists.ozlabs.org/listinfo/linuxppc-dev
Cheers,
Hugh
^ permalink raw reply
* Re: embedding dtb file into kernel
From: Sam Protsenko @ 2015-02-13 13:31 UTC (permalink / raw)
To: K Richard Pixley; +Cc: linux-embedded
In-Reply-To: <54DD0018.7010409@graphitesystems.com>
On Thu, Feb 12, 2015 at 9:33 PM, K Richard Pixley
<rpixley@graphitesystems.com> wrote:
> I'm having trouble figuring out how to embed a dtb file into my kernel. I'm
> thinking that there should be a standard, architecture independent facility
> for this akin to initramfs, yes?
>
> Could someone please either point me to the standard facility, relevant doc,
> a currently building board that uses the standard facility, or outline what
> needs to be done to do this with a new board?
>
> If it matters, (I can't think why it would), I'm working with powerpc on a
> 3.10 kernel. But if there are better facilities in other versions I'd
> appreciate hearing about that too.
>
> Thank you in advance.
>
> --rich
> --
> To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Look into Documentation/powerpc/bootwrapper.txt.
It reveals that there is "wrapper" script which does the trick and
this script should be used
via Makefile. Both "wrapper" script and Makefile resides in
arch/powerpc/boot/ directory.
I think you can figure out how to use it properly from that documentation.
^ permalink raw reply
* [PATCH 1/3] kernel: Add a new config option to remove command line parsing
From: Iulia Manda @ 2015-04-01 14:34 UTC (permalink / raw)
To: josh; +Cc: linux-embedded, tim.bird, paulmck, dvhart, peterz, mihai.caraman
This patch introduces CONFIG_CMDLINE_PARSE option which conditionally compiles
the support for parsing kernel command line arguments. The corresponding
functions that actually do the parsing will be compiled out.
This is used when no parameters will be specified neither at compile time nor at
boot time.
Bloat-o-meter output (compared to the preivous version in which builtin cmdline
was also set to 'Y'):
add/remove: 0/8 grow/shrink: 0/6 up/down: 0/-3669 (-3669)
function old new delta
load_module 5571 5563 -8
parse_early_param 54 44 -10
parse_early_options 33 5 -28
initcall_level_names 32 - -32
kernel_init_freeable 413 360 -53
unknown_module_param_cb 60 - -60
setup_arch 3041 2972 -69
set_init_arg 73 - -73
repair_env_string 81 - -81
start_kernel 857 759 -98
do_early_param 117 - -117
unknown_bootoption 366 - -366
parse_args 626 - -626
builtin_cmdline 2048 - -2048
Signed-off-by: Iulia Manda <iulia.manda21@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
---
arch/x86/Kconfig | 15 +++++++++++++++
include/linux/moduleparam.h | 14 ++++++++++++++
kernel/params.c | 2 ++
3 files changed, 31 insertions(+)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index c2fb8a8..f1e02ea 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2003,8 +2003,23 @@ config COMPAT_VDSO
If unsure, say N: if you are compiling your own kernel, you
are unlikely to be using a buggy version of glibc.
+config CMDLINE_PARSE
+ bool "Enable support for command line parsing"
+ default y
+ ---help---
+ With this option set to 'Y', kernel parameters, both the ones
+ passed at boot time and at compile time are parsed.
+
+ If you say no here, all the kernel parameters' values will be set
+ to their defaults at compile time, in order to make constant
+ folding possible.
+
+ Systems with no space constraints should leave this option set to
+ 'Y'.
+
config CMDLINE_BOOL
bool "Built-in kernel command line"
+ depends on CMDLINE_PARSE
---help---
Allow for specifying boot arguments to the kernel at
build time. On some systems (e.g. embedded ones), it is
diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h
index 1c9effa..f97397c 100644
--- a/include/linux/moduleparam.h
+++ b/include/linux/moduleparam.h
@@ -350,6 +350,7 @@ extern bool parameq(const char *name1, const char *name2);
*/
extern bool parameqn(const char *name1, const char *name2, size_t n);
+#ifdef CONFIG_CMDLINE_PARSE
/* Called on module insert or kernel boot */
extern char *parse_args(const char *name,
char *args,
@@ -359,6 +360,19 @@ extern char *parse_args(const char *name,
s16 level_max,
int (*unknown)(char *param, char *val,
const char *doing));
+#else
+static inline char *parse_args(const char *name,
+ char *args,
+ const struct kernel_param *params,
+ unsigned num,
+ s16 level_min,
+ s16 level_max,
+ int (*unknown)(char *param, char *val,
+ const char *doing))
+{
+ return NULL;
+}
+#endif
/* Called by module remove. */
#ifdef CONFIG_SYSFS
diff --git a/kernel/params.c b/kernel/params.c
index 728e05b..d3bfe47 100644
--- a/kernel/params.c
+++ b/kernel/params.c
@@ -93,6 +93,7 @@ static void param_check_unsafe(const struct kernel_param *kp)
}
}
+#ifdef CONFIG_CMDLINE_PARSE
static int parse_one(char *param,
char *val,
const char *doing,
@@ -239,6 +240,7 @@ char *parse_args(const char *doing,
/* All parsed OK. */
return NULL;
}
+#endif
/* Lazy bastard, eh? */
#define STANDARD_PARAM_DEF(name, type, format, strtolfn) \
--
1.9.1
^ permalink raw reply related
* [PATCH 2/3] linux: Add macros that define and declare a core_param variable
From: Iulia Manda @ 2015-04-01 14:34 UTC (permalink / raw)
To: josh; +Cc: linux-embedded, tim.bird, paulmck, dvhart, peterz, mihai.caraman
In-Reply-To: <1427898893-8257-1-git-send-email-iulia.manda21@gmail.com>
This patch introduces two macros for kernel command line arguments subsequently
defined as core parameters:
* DECLARE_CORE_PARAM - declares an extern variable in case CMDLINE_PARSE is
set. In the other case it will make the variable a static constant asigned with
a default value to enable constant folding;
* DEFINE_CORE_PARAM - defines a core_param variable if CMDLINE_PARSE is set. In
the other case it leaves the definition to be handled by DECLARE_CORE_PARAM
macro.
Introducing a new header file for the declaration of kernel parameters seemed
to be the best option, because it solves the circular includes problem. Any
other proposal that would be fit for this case is welcomed.
Signed-off-by: Iulia Manda <iulia.manda21@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
---
include/linux/moduleparam.h | 9 +++++++++
include/linux/params.h | 12 ++++++++++++
2 files changed, 21 insertions(+)
create mode 100644 include/linux/params.h
diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h
index f97397c..17efa97 100644
--- a/include/linux/moduleparam.h
+++ b/include/linux/moduleparam.h
@@ -310,6 +310,15 @@ static inline void __kernel_param_unlock(void)
#define core_param(name, var, type, perm) \
param_check_##type(name, &(var)); \
__module_param_call("", name, ¶m_ops_##type, &var, perm, -1, 0)
+
+#ifdef CONFIG_CMDLINE_PARSE
+#define DEFINE_CORE_PARAM(name, var, val, type, perm) \
+ type var = val; \
+ core_param(name, var, type, perm)
+#else
+#define DEFINE_CORE_PARAM(name, var, val, type, perm)
+#endif
+
#endif /* !MODULE */
/**
diff --git a/include/linux/params.h b/include/linux/params.h
new file mode 100644
index 0000000..c1ee6ff
--- /dev/null
+++ b/include/linux/params.h
@@ -0,0 +1,12 @@
+#ifndef _LINUX_PARAMS_H
+#define _LINUX_PARAMS_H
+
+#ifdef CONFIG_CMDLINE_PARSE
+#define DECLARE_CORE_PARAM(var, val, type) \
+ extern type var
+#else
+#define DECLARE_CORE_PARAM(var, val, type) \
+ static const type var = val
+#endif
+
+#endif /* _LINUX_PARAMS_H */
--
1.9.1
^ permalink raw reply related
* [PATCH 3/3] init: Set initcall_debug to a default value
From: Iulia Manda @ 2015-04-01 14:34 UTC (permalink / raw)
To: josh; +Cc: linux-embedded, tim.bird, paulmck, dvhart, peterz, mihai.caraman
In-Reply-To: <1427898893-8257-1-git-send-email-iulia.manda21@gmail.com>
Test the previously implemented macros on initcall_debug parameter, after
setting CONFIG_CMDLINE_PARSE to 'n'.
This change is a first example for how knowing the values of kernel parameters
at build time can allow GCC constant folding and result in an actually
relevant decrease in size. Other types of parameters also need to be handled.
Also, at the moment this would only work with default values. For being able
to change those defaults and still know their values at compile time, a
pre-compiled stand-alone parser should be run on those variables. This will be
discussed in a following patch.
The variable corresponding to initcall_debug kernel parameter is set by default
to false. Even though DEFINE_CORE_PARAM resumes to nothing when
CONFIG_CMDLINE_PARSE is not set, we need to use it in main.c so that it is
still defined when this option is 'y'.
Bloat-o-meter output:
add/remove: 0/3 grow/shrink: 0/9 up/down: 0/-385 (-385)
function old new delta
initcall_debug 1 - -1
pm_init 105 100 -5
__param_str_initcall_debug 15 - -15
__param_initcall_debug 16 - -16
syscore_suspend 247 224 -23
syscore_resume 175 152 -23
syscore_shutdown 80 55 -25
pci_fixup_device 235 198 -37
async_synchronize_cookie_domain 162 116 -46
async_run_entry_fn 178 127 -51
device_shutdown 256 204 -52
do_one_initcall 339 248 -91
Signed-off-by: Iulia Manda <iulia.manda21@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
---
include/linux/init.h | 3 ++-
init/main.c | 3 +--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/linux/init.h b/include/linux/init.h
index 2df8e8d..d53f28d 100644
--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -3,6 +3,7 @@
#include <linux/compiler.h>
#include <linux/types.h>
+#include <linux/params.h>
/* These macros are used to mark some functions or
* initialized data (doesn't apply to uninitialized data)
@@ -155,7 +156,7 @@ int __init init_rootfs(void);
extern void (*late_time_init)(void);
-extern bool initcall_debug;
+DECLARE_CORE_PARAM(initcall_debug, false, bool);
#endif
diff --git a/init/main.c b/init/main.c
index 6f0f1c5f..85e9001 100644
--- a/init/main.c
+++ b/init/main.c
@@ -685,8 +685,7 @@ static void __init do_ctors(void)
#endif
}
-bool initcall_debug;
-core_param(initcall_debug, initcall_debug, bool, 0644);
+DEFINE_CORE_PARAM(initcall_debug, initcall_debug, false, bool, 0644);
#ifdef CONFIG_KALLSYMS
struct blacklist_entry {
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 1/3] kernel: Add a new config option to remove command line parsing
From: Tim Bird @ 2015-04-09 14:44 UTC (permalink / raw)
To: Iulia Manda, josh@joshtriplett.org
Cc: linux-embedded@vger.kernel.org, paulmck@linux.vnet.ibm.com,
dvhart@linux.intel.com, peterz@infradead.org,
mihai.caraman@freescale.com, linux-kernel@vger.kernel.org
In-Reply-To: <1427898893-8257-1-git-send-email-iulia.manda21@gmail.com>
On 04/01/2015 07:34 AM, Iulia Manda wrote:
> This patch introduces CONFIG_CMDLINE_PARSE option which conditionally compiles
> the support for parsing kernel command line arguments. The corresponding
> functions that actually do the parsing will be compiled out.
>
> This is used when no parameters will be specified neither at compile time nor at
> boot time.
>
> Bloat-o-meter output (compared to the preivous version in which builtin cmdline
> was also set to 'Y'):
>
> add/remove: 0/8 grow/shrink: 0/6 up/down: 0/-3669 (-3669)
I think this is great stuff. (Of course, having research something like this
previously, I'm a bit biased.)
It's very nice to have the Bloat-o-meter output for these kernel size shrinking
patches.
The patch itself looks very straightforward, and I don't see any problems
in a visual inspection.
You can add a Reviewed-by: Tim Bird <tim.bird@sonymobile.com> to this patch.
I'd like to be able to point people to this on the mailing list. In the future
can you make sure to CC: <linux-kernel@vger.kernel.org>, so there's a reference
on lkml.org I can point people to?
Thanks for this great work!
-- Tim
^ permalink raw reply
* Invitation and RFC: Linux Plumbers Device Tree track proposed
From: Rowand, Frank @ 2015-04-11 19:20 UTC (permalink / raw)
To: devicetree@vger.kernel.org, devicetree-compiler@vger.kernel.org,
linux-embedded@vger.kernel.org,
celinux-dev@lists.celinuxforum.org, linux-kernel@vger.kernel.org
In recent years there have been proposed tools to aid in the creation of valid
device trees and in debugging device tree issues. An example of this is the
various approaches proposed (with source code provided) to validate device tree
source against valid bindings. As of today, device tree related tools,
techniques, and debugging infrastructure have not progressed very far. I have
submitted a device tree related proposal for the Linux Plumbers 2015 conference
to spur action and innovation in such tools, techniques, and debugging
infrastructure.
The current title of the track is "Device Tree Tools, Validation, and
Troubleshooting". The proposal is located at
http://wiki.linuxplumbersconf.org/2015:device_tree_tools_validation_and_trouble_shooting
I am looking for several things at the moment:
1) Suggestions of additional topics to be discussed.
2) Emails or other messages expressing an interest in attending the
device tree track.
3) Commitments to attend the device tree track (the conference committee
is looking at attendee interest and commitments as part of the process
of accepting the device tree track).
4) Identifying additional people who should attend the device tree track.
The desired outcome of the device tree track is to encourage the future
development of tools, process, etc to make device tree related development,
test, review and system administration more efficient, faster, easier, more
robust, and to improve troubleshooting and debugging facilities. Some
examples of areas of interest could include:
- make it easier to create correct device tree source files
- support for debugging incorrect device tree source files
- create a kernel that correctly boots one or more specific device trees
(eg a kernel configured to include the proper drivers and subsystems)
- create drivers that properly work for a device tree binding definition
- create drivers that support detecting errors in the related node(s) in
a device tree
The wiki page lists additional areas of interest.
Thanks,
Frank Rowand
Sony Mobile Communications
^ permalink raw reply
* Re: Invitation and RFC: Linux Plumbers Device Tree track proposed
From: Rob Landley @ 2015-04-12 0:05 UTC (permalink / raw)
To: Rowand, Frank
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
celinux-dev-idqoXFIVOFIh9xQPArXXUATG8MYbGj4l@public.gmane.org,
linux-embedded-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <8251B150E4DF5041A62C3EA9F0AB2E0603A53FE1082E-6yWnlZQfN9JoBVljSLT0Ysm4BeyDBExM@public.gmane.org>
On Sat, Apr 11, 2015 at 2:20 PM, Rowand, Frank
<Frank.Rowand-/MT0OVThwyLZJqsBc5GL+g@public.gmane.org> wrote:
> In recent years there have been proposed tools to aid in the creation of valid
> device trees and in debugging device tree issues. An example of this is the
> various approaches proposed (with source code provided) to validate device tree
> source against valid bindings. As of today, device tree related tools,
> techniques, and debugging infrastructure have not progressed very far. I have
> submitted a device tree related proposal for the Linux Plumbers 2015 conference
> to spur action and innovation in such tools, techniques, and debugging
> infrastructure.
>
> The current title of the track is "Device Tree Tools, Validation, and
> Troubleshooting". The proposal is located at
>
> http://wiki.linuxplumbersconf.org/2015:device_tree_tools_validation_and_trouble_shooting
>
> I am looking for several things at the moment:
>
> 1) Suggestions of additional topics to be discussed.
>
> 2) Emails or other messages expressing an interest in attending the
> device tree track.
>
> 3) Commitments to attend the device tree track (the conference committee
> is looking at attendee interest and commitments as part of the process
> of accepting the device tree track).
>
> 4) Identifying additional people who should attend the device tree track.
>
> The desired outcome of the device tree track is to encourage the future
> development of tools, process, etc to make device tree related development,
> test, review and system administration more efficient, faster, easier, more
> robust, and to improve troubleshooting and debugging facilities. Some
> examples of areas of interest could include:
> - make it easier to create correct device tree source files
> - support for debugging incorrect device tree source files
> - create a kernel that correctly boots one or more specific device trees
> (eg a kernel configured to include the proper drivers and subsystems)
> - create drivers that properly work for a device tree binding definition
> - create drivers that support detecting errors in the related node(s) in
> a device tree
>
> The wiki page lists additional areas of interest.
Is there a device tree porting HOWTO anywhere? If I have a board
that's using explicit C initialization, and I want to convert it over
to device tree, step by step what do I do?
If I'm writing a new board support, what device tree bits do I need to
get a shell prompt on a serial port running out of initramfs?
(Physical memory, interrupt controller, timer to drive the scheduler,
serial chip...)
There's a bunch of device tree reference material out there, but no
tutorial material at all, that I can find...
Rob
^ permalink raw reply
* Re: [Celinux-dev] Invitation and RFC: Linux Plumbers Device Tree track proposed
From: Geert Uytterhoeven @ 2015-04-12 7:53 UTC (permalink / raw)
To: Rob Landley
Cc: Rowand, Frank, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
celinux-dev-idqoXFIVOFIh9xQPArXXUATG8MYbGj4l@public.gmane.org,
linux-embedded-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAOS_Y6Qmt2KTRu6urPs-Y1e2Xv1QPNTaQHH4_N8Kk8XU7n+ecQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Rob,
On Sun, Apr 12, 2015 at 2:05 AM, Rob Landley <rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org> wrote:
> Is there a device tree porting HOWTO anywhere? If I have a board
> that's using explicit C initialization, and I want to convert it over
> to device tree, step by step what do I do?
>
> If I'm writing a new board support, what device tree bits do I need to
> get a shell prompt on a serial port running out of initramfs?
> (Physical memory, interrupt controller, timer to drive the scheduler,
> serial chip...)
>
> There's a bunch of device tree reference material out there, but no
> tutorial material at all, that I can find...
http://www.devicetree.org/Device_Tree_Usage
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree-compiler" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Invitation and RFC: Linux Plumbers Device Tree track proposed
From: David Gibson @ 2015-04-13 5:13 UTC (permalink / raw)
To: Rowand, Frank
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-embedded-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
celinux-dev-idqoXFIVOFIh9xQPArXXUATG8MYbGj4l@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <8251B150E4DF5041A62C3EA9F0AB2E0603A53FE1082E-6yWnlZQfN9JoBVljSLT0Ysm4BeyDBExM@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1697 bytes --]
On Sat, Apr 11, 2015 at 09:20:33PM +0200, Rowand, Frank wrote:
> In recent years there have been proposed tools to aid in the creation of valid
> device trees and in debugging device tree issues. An example of this is the
> various approaches proposed (with source code provided) to validate device tree
> source against valid bindings. As of today, device tree related tools,
> techniques, and debugging infrastructure have not progressed very far. I have
> submitted a device tree related proposal for the Linux Plumbers 2015 conference
> to spur action and innovation in such tools, techniques, and debugging
> infrastructure.
>
> The current title of the track is "Device Tree Tools, Validation, and
> Troubleshooting". The proposal is located at
>
> http://wiki.linuxplumbersconf.org/2015:device_tree_tools_validation_and_trouble_shooting
>
> I am looking for several things at the moment:
>
> 1) Suggestions of additional topics to be discussed.
>
> 2) Emails or other messages expressing an interest in attending the
> device tree track.
>
> 3) Commitments to attend the device tree track (the conference committee
> is looking at attendee interest and commitments as part of the process
> of accepting the device tree track).
It happens that I'll be in Seattle at the time for the KVM Forum.
It's my intention to attend the Plumbers' device tree track, except
where it collides with things I need to attend at KVM Forum.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: Invitation and RFC: Linux Plumbers Device Tree track proposed
From: Rob Herring @ 2015-04-14 15:36 UTC (permalink / raw)
To: Rowand, Frank
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-embedded-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
celinux-dev-idqoXFIVOFIh9xQPArXXUATG8MYbGj4l@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Matt Porter,
Jon Loeliger, Arnd Bergmann, Gaurav Minocha
In-Reply-To: <8251B150E4DF5041A62C3EA9F0AB2E0603A53FE1082E-6yWnlZQfN9JoBVljSLT0Ysm4BeyDBExM@public.gmane.org>
On Sat, Apr 11, 2015 at 2:20 PM, Rowand, Frank
<Frank.Rowand-/MT0OVThwyLZJqsBc5GL+g@public.gmane.org> wrote:
> In recent years there have been proposed tools to aid in the creation of valid
> device trees and in debugging device tree issues. An example of this is the
> various approaches proposed (with source code provided) to validate device tree
> source against valid bindings. As of today, device tree related tools,
> techniques, and debugging infrastructure have not progressed very far. I have
> submitted a device tree related proposal for the Linux Plumbers 2015 conference
> to spur action and innovation in such tools, techniques, and debugging
> infrastructure.
>
> The current title of the track is "Device Tree Tools, Validation, and
> Troubleshooting". The proposal is located at
>
> http://wiki.linuxplumbersconf.org/2015:device_tree_tools_validation_and_trouble_shooting
>
> I am looking for several things at the moment:
>
> 1) Suggestions of additional topics to be discussed.
A few things on my list:
- Supported and not supported overlay usecases
- Tools for overlays - I think overlays has created new challenges in
validation and a need for new tools. How to test an overlay applies?
Generating a dtb from dts + overlay dts. Generating an overlay from a
diff of old and new dts (overlay as a way to update old dtbs)
- Shrinking the binding review fire hose. How to improve binding
documentation structure and review.
- Standardizing Android dtb handling. Appended DTB for arm64? Not
liked by upstream, but already in use.
> 2) Emails or other messages expressing an interest in attending the
> device tree track.
>
> 3) Commitments to attend the device tree track (the conference committee
> is looking at attendee interest and commitments as part of the process
> of accepting the device tree track).
I plan to attend. I'm probably attending some of the Android mini conf
too, so I'll have to split my time.
> 4) Identifying additional people who should attend the device tree track.
Arnd Bergmann
Matt Porter
Jon Loeliger
Gaurav Minocha
Rob
> The desired outcome of the device tree track is to encourage the future
> development of tools, process, etc to make device tree related development,
> test, review and system administration more efficient, faster, easier, more
> robust, and to improve troubleshooting and debugging facilities. Some
> examples of areas of interest could include:
> - make it easier to create correct device tree source files
> - support for debugging incorrect device tree source files
> - create a kernel that correctly boots one or more specific device trees
> (eg a kernel configured to include the proper drivers and subsystems)
> - create drivers that properly work for a device tree binding definition
> - create drivers that support detecting errors in the related node(s) in
> a device tree
>
> The wiki page lists additional areas of interest.
>
> Thanks,
>
> Frank Rowand
> Sony Mobile Communications
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree-compiler" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Invitation and RFC: Linux Plumbers Device Tree track proposed
From: Mark Rutland @ 2015-04-14 17:14 UTC (permalink / raw)
To: Rob Herring
Cc: Rowand, Frank, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-embedded-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
celinux-dev-idqoXFIVOFIh9xQPArXXUATG8MYbGj4l@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Matt Porter,
Jon Loeliger, Arnd Bergmann, Gaurav Minocha
In-Reply-To: <CAL_JsqL0FdvKtGTxFNYxtrGWkm3z-1m0v9dHwYezCtkFOW6EgQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Apr 14, 2015 at 04:36:15PM +0100, Rob Herring wrote:
> On Sat, Apr 11, 2015 at 2:20 PM, Rowand, Frank
> <Frank.Rowand-/MT0OVThwyLZJqsBc5GL+g@public.gmane.org> wrote:
> > In recent years there have been proposed tools to aid in the creation of valid
> > device trees and in debugging device tree issues. An example of this is the
> > various approaches proposed (with source code provided) to validate device tree
> > source against valid bindings. As of today, device tree related tools,
> > techniques, and debugging infrastructure have not progressed very far. I have
> > submitted a device tree related proposal for the Linux Plumbers 2015 conference
> > to spur action and innovation in such tools, techniques, and debugging
> > infrastructure.
> >
> > The current title of the track is "Device Tree Tools, Validation, and
> > Troubleshooting". The proposal is located at
> >
> > http://wiki.linuxplumbersconf.org/2015:device_tree_tools_validation_and_trouble_shooting
> >
> > I am looking for several things at the moment:
> >
> > 1) Suggestions of additional topics to be discussed.
>
> A few things on my list:
>
> - Supported and not supported overlay usecases
I guess Kernel-driven overlay application (it's been called "quirks"
elsewhere) would fall under this? It's rather scary, and would need
fairly strict rules to be feasible and remain maintainable, which is
going to limit where it can be used.
I think the core guys for that are on the list already?
> - Standardizing Android dtb handling. Appended DTB for arm64? Not
> liked by upstream, but already in use.
If people are going to package a kernel and DTB together, it would be
nice if they could at least be easily decomposed (using something like
FIT).
So +1 for that discussion.
> > 2) Emails or other messages expressing an interest in attending the
> > device tree track.
I'm interested.
> > 3) Commitments to attend the device tree track (the conference committee
> > is looking at attendee interest and commitments as part of the process
> > of accepting the device tree track).
If the DT track goes ahead, I'll be there.
Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Invitation and RFC: Linux Plumbers Device Tree track proposed
From: Arnd Bergmann @ 2015-04-14 20:58 UTC (permalink / raw)
To: Rob Herring
Cc: Rowand, Frank, devicetree@vger.kernel.org,
devicetree-compiler@vger.kernel.org,
linux-embedded@vger.kernel.org,
celinux-dev@lists.celinuxforum.org, linux-kernel@vger.kernel.org,
Matt Porter, Jon Loeliger, Gaurav Minocha
In-Reply-To: <CAL_JsqL0FdvKtGTxFNYxtrGWkm3z-1m0v9dHwYezCtkFOW6EgQ@mail.gmail.com>
On Tuesday 14 April 2015 10:36:15 Rob Herring wrote:
>
> > 4) Identifying additional people who should attend the device tree track.
>
> Arnd Bergmann
> Matt Porter
> Jon Loeliger
> Gaurav Minocha
Sorry, I won't be there. I should have replied earlier, but I'll be on
parental leave at the time.
Arnd
^ permalink raw reply
* Re: Invitation and RFC: Linux Plumbers Device Tree track proposed
From: Matt Porter @ 2015-05-01 13:32 UTC (permalink / raw)
To: Rob Herring
Cc: Rowand, Frank, devicetree@vger.kernel.org,
devicetree-compiler@vger.kernel.org,
linux-embedded@vger.kernel.org,
celinux-dev@lists.celinuxforum.org, linux-kernel@vger.kernel.org,
Jon Loeliger, Arnd Bergmann, Gaurav Minocha
In-Reply-To: <CAL_JsqL0FdvKtGTxFNYxtrGWkm3z-1m0v9dHwYezCtkFOW6EgQ@mail.gmail.com>
On Tue, Apr 14, 2015 at 10:36:15AM -0500, Rob Herring wrote:
> On Sat, Apr 11, 2015 at 2:20 PM, Rowand, Frank
> <Frank.Rowand@sonymobile.com> wrote:
> > In recent years there have been proposed tools to aid in the creation of valid
> > device trees and in debugging device tree issues. An example of this is the
> > various approaches proposed (with source code provided) to validate device tree
> > source against valid bindings. As of today, device tree related tools,
> > techniques, and debugging infrastructure have not progressed very far. I have
> > submitted a device tree related proposal for the Linux Plumbers 2015 conference
> > to spur action and innovation in such tools, techniques, and debugging
> > infrastructure.
> >
> > The current title of the track is "Device Tree Tools, Validation, and
> > Troubleshooting". The proposal is located at
> >
> > http://wiki.linuxplumbersconf.org/2015:device_tree_tools_validation_and_trouble_shooting
> >
> > I am looking for several things at the moment:
> >
> > 1) Suggestions of additional topics to be discussed.
>
> A few things on my list:
>
> - Supported and not supported overlay usecases
> - Tools for overlays - I think overlays has created new challenges in
> validation and a need for new tools. How to test an overlay applies?
> Generating a dtb from dts + overlay dts. Generating an overlay from a
> diff of old and new dts (overlay as a way to update old dtbs)
> - Shrinking the binding review fire hose. How to improve binding
> documentation structure and review.
> - Standardizing Android dtb handling. Appended DTB for arm64? Not
> liked by upstream, but already in use.
- Clean up of existing hardware-specific bindings to conform to the
generic bindings, working dts files in the kernel tree, and bring
consistency to the documentation style/syntax.
> > 2) Emails or other messages expressing an interest in attending the
> > device tree track.
> >
> > 3) Commitments to attend the device tree track (the conference committee
> > is looking at attendee interest and commitments as part of the process
> > of accepting the device tree track).
>
> I plan to attend. I'm probably attending some of the Android mini conf
> too, so I'll have to split my time.
>
> > 4) Identifying additional people who should attend the device tree track.
>
> Arnd Bergmann
> Matt Porter
> Jon Loeliger
> Gaurav Minocha
I also plan to attend. I have an interest in most of the topics already
mentioned as well as the topic I added above.
-Matt
^ permalink raw reply
* Re: [Celinux-dev] Invitation and RFC: Linux Plumbers Device Tree track proposed
From: Rob Landley @ 2015-05-01 21:22 UTC (permalink / raw)
To: Rowand, Frank, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-embedded-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
celinux-dev-idqoXFIVOFIh9xQPArXXUATG8MYbGj4l@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <8251B150E4DF5041A62C3EA9F0AB2E0603A53FE1082E-6yWnlZQfN9JoBVljSLT0Ysm4BeyDBExM@public.gmane.org>
On 04/11/2015 02:20 PM, Rowand, Frank wrote:
> In recent years there have been proposed tools to aid in the creation of valid
> device trees and in debugging device tree issues. An example of this is the
> various approaches proposed (with source code provided) to validate device tree
> source against valid bindings. As of today, device tree related tools,
> techniques, and debugging infrastructure have not progressed very far. I have
> submitted a device tree related proposal for the Linux Plumbers 2015 conference
> to spur action and innovation in such tools, techniques, and debugging
> infrastructure.
>
> The current title of the track is "Device Tree Tools, Validation, and
> Troubleshooting". The proposal is located at
>
> http://wiki.linuxplumbersconf.org/2015:device_tree_tools_validation_and_trouble_shooting
Want I want to do is:
1) Download an archive of device tree files describing a bunch of
boards. (Both dts and corresponding dtb files, with maybe a .txt telling
me about the board and the -append line qemu needs to give it any
board-specific kernel command line stuff like "console=myserialport".)
2) Feed one of the dtb files to qemu to instantiate a bunch of devices.
3) Feed the same file to a generic-ish linux kernel to bind to those
devices. (Or have qemu do this for me.)
Every year or so I sit down to figure out how to do this, spent fifteen
minutes head scratching, and wander away again.
The archive in 1) should have subdirectories for architectures, with the
same name as the corresponding kernel arch directory. It would be nice
if there was some sort of dts_defconfig that built a vmlinux that
statically linked in all the drivers with a device tree binding. It
would be _really_ nice if qemu's vmlinux loader actually worked on all
the hardware targets.
In theory, this should be easy. In practice, I've never made it work.
Rob
^ permalink raw reply
* Re: Invitation and RFC: Linux Plumbers Device Tree track proposed
From: Geert Uytterhoeven @ 2015-05-02 7:51 UTC (permalink / raw)
To: Rob Landley
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-embedded-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Rowand, Frank,
celinux-dev-idqoXFIVOFIh9xQPArXXUATG8MYbGj4l@public.gmane.org,
devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <5543EE80.5060109-VoJi6FS/r0vR7s880joybQ@public.gmane.org>
Hi Rob,
On Fri, May 1, 2015 at 11:22 PM, Rob Landley <rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org> wrote:
> The archive in 1) should have subdirectories for architectures, with the
> same name as the corresponding kernel arch directory. It would be nice
> if there was some sort of dts_defconfig that built a vmlinux that
> statically linked in all the drivers with a device tree binding. It
"Generating .config from DTS"
https://groups.google.com/forum/#!topic/linux.kernel/xYrKolsgr0Y
In the mean time, partial mathing (for i2c/spi devices) has been implemented.
https://github.com/geertu/linux-scripts/blob/master/linux-config-from-dt
It needs more work to generate a full .config, though.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [Celinux-dev] Invitation and RFC: Linux Plumbers Device Tree track proposed
From: Rob Herring @ 2015-05-04 23:20 UTC (permalink / raw)
To: Rob Landley
Cc: Rowand, Frank, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-embedded-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
celinux-dev-idqoXFIVOFIh9xQPArXXUATG8MYbGj4l@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <5543EE80.5060109-VoJi6FS/r0vR7s880joybQ@public.gmane.org>
On Fri, May 1, 2015 at 4:22 PM, Rob Landley <rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org> wrote:
> On 04/11/2015 02:20 PM, Rowand, Frank wrote:
>> In recent years there have been proposed tools to aid in the creation of valid
>> device trees and in debugging device tree issues. An example of this is the
>> various approaches proposed (with source code provided) to validate device tree
>> source against valid bindings. As of today, device tree related tools,
>> techniques, and debugging infrastructure have not progressed very far. I have
>> submitted a device tree related proposal for the Linux Plumbers 2015 conference
>> to spur action and innovation in such tools, techniques, and debugging
>> infrastructure.
>>
>> The current title of the track is "Device Tree Tools, Validation, and
>> Troubleshooting". The proposal is located at
>>
>> http://wiki.linuxplumbersconf.org/2015:device_tree_tools_validation_and_trouble_shooting
>
> Want I want to do is:
>
> 1) Download an archive of device tree files describing a bunch of
> boards. (Both dts and corresponding dtb files, with maybe a .txt telling
> me about the board and the -append line qemu needs to give it any
> board-specific kernel command line stuff like "console=myserialport".)
The dts half is here[1]. It is a kernel repository automatically
stripped of everything but dts files.
> 2) Feed one of the dtb files to qemu to instantiate a bunch of devices.
I'd like this too. The QEMU maintainers don't really agree. I think
the ARM virt platform is the wrong way around with QEMU generating the
DT. There was a patch series to allow sysbus devices to be created on
the command line like you can with PCI. This would have allowed a
front end script to generate a QEMU command line from a DT. I'm not
sure if it ever got in.
It would lower the bar to adding new platforms to just writing models
for blocks perhaps. I'm not sure there's enough interest. The number
of ARM platforms supported in QEMU is much less than the kernel.
Rob
[1] https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [Celinux-dev] Invitation and RFC: Linux Plumbers Device Tree track proposed
From: Geert Uytterhoeven @ 2015-05-05 7:34 UTC (permalink / raw)
To: Rob Herring
Cc: Rob Landley, Rowand, Frank,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-embedded-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
celinux-dev-idqoXFIVOFIh9xQPArXXUATG8MYbGj4l@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAL_JsqKkZYEMdYmh=JkA6O34a+7mKy=SgB2XxzgTM70mihgQeQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Rob
On Tue, May 5, 2015 at 1:20 AM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Fri, May 1, 2015 at 4:22 PM, Rob Landley <rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org> wrote:
>> On 04/11/2015 02:20 PM, Rowand, Frank wrote:
>>> In recent years there have been proposed tools to aid in the creation of valid
>>> device trees and in debugging device tree issues. An example of this is the
>>> various approaches proposed (with source code provided) to validate device tree
>>> source against valid bindings. As of today, device tree related tools,
>>> techniques, and debugging infrastructure have not progressed very far. I have
>>> submitted a device tree related proposal for the Linux Plumbers 2015 conference
>>> to spur action and innovation in such tools, techniques, and debugging
>>> infrastructure.
>>>
>>> The current title of the track is "Device Tree Tools, Validation, and
>>> Troubleshooting". The proposal is located at
>>>
>>> http://wiki.linuxplumbersconf.org/2015:device_tree_tools_validation_and_trouble_shooting
>>
>> Want I want to do is:
>>
>> 1) Download an archive of device tree files describing a bunch of
>> boards. (Both dts and corresponding dtb files, with maybe a .txt telling
>> me about the board and the -append line qemu needs to give it any
>> board-specific kernel command line stuff like "console=myserialport".)
>
> The dts half is here[1]. It is a kernel repository automatically
> stripped of everything but dts files.
>
> [1] https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/
Great!
While "git log" has the "--nomerges" option, cgit hasn't, making it hard to see
the actual changes through the forest of merges.
Any chance merge commits not causing any changes can be stripped out, too?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: Invitation and RFC: Linux Plumbers Device Tree track proposed
From: Rob Herring @ 2015-05-05 19:32 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-embedded-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Rowand, Frank,
celinux-dev-idqoXFIVOFIh9xQPArXXUATG8MYbGj4l@public.gmane.org,
devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAMuHMdV7xfbBYL5fhudObdwNVJ0L_1_h0ozT+U4Lpx=Mu9UGhw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
+Ian
On Tue, May 5, 2015 at 2:34 AM, Geert Uytterhoeven <geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org> wrote:
> Hi Rob
>
> On Tue, May 5, 2015 at 1:20 AM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On Fri, May 1, 2015 at 4:22 PM, Rob Landley <rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org> wrote:
>>> On 04/11/2015 02:20 PM, Rowand, Frank wrote:
>>>> In recent years there have been proposed tools to aid in the creation of valid
>>>> device trees and in debugging device tree issues. An example of this is the
>>>> various approaches proposed (with source code provided) to validate device tree
>>>> source against valid bindings. As of today, device tree related tools,
>>>> techniques, and debugging infrastructure have not progressed very far. I have
>>>> submitted a device tree related proposal for the Linux Plumbers 2015 conference
>>>> to spur action and innovation in such tools, techniques, and debugging
>>>> infrastructure.
>>>>
>>>> The current title of the track is "Device Tree Tools, Validation, and
>>>> Troubleshooting". The proposal is located at
>>>>
>>>> http://wiki.linuxplumbersconf.org/2015:device_tree_tools_validation_and_trouble_shooting
>>>
>>> Want I want to do is:
>>>
>>> 1) Download an archive of device tree files describing a bunch of
>>> boards. (Both dts and corresponding dtb files, with maybe a .txt telling
>>> me about the board and the -append line qemu needs to give it any
>>> board-specific kernel command line stuff like "console=myserialport".)
>>
>> The dts half is here[1]. It is a kernel repository automatically
>> stripped of everything but dts files.
>>
>> [1] https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/
>
> Great!
>
> While "git log" has the "--nomerges" option, cgit hasn't, making it hard to see
> the actual changes through the forest of merges.
>
> Any chance merge commits not causing any changes can be stripped out, too?
That's a question for Ian.
Rob
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox