[U-Boot-Users] [RFC][PATCH] fdt fixup

[U-Boot-Users] [RFC][PATCH] fdt fixup

[Kumar Gala]

This code adds a generic fixup mechanism that allows us to get ride of
needing explicit paths to device nodes.

diff --git a/common/fdt_support.c b/common/fdt_support.c
index 7a81469..2c1e8ac 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -363,4 +363,125 @@ int fdt_bd_t(void *fdt)
 }
 #endif /* ifdef CONFIG_OF_HAS_BD_T */

+/*
+ * "Setter" functions used to add/modify FDT entries.
+ */
+#ifdef CONFIG_HAS_ETH0
+static int fdt_set_eth0(void *blob, int nodeoffset, const char *name, bd_t *bd)
+{
+	/* Fix it up if it exists, don't create it if it doesn't exist */
+	if (fdt_get_property(blob, nodeoffset, name, 0)) {
+		return fdt_setprop(blob, nodeoffset, name, bd->bi_enetaddr, 6);
+	}
+	return 0;
+}
+#endif
+#ifdef CONFIG_HAS_ETH1
+/* second onboard ethernet port */
+static int fdt_set_eth1(void *blob, int nodeoffset, const char *name, bd_t *bd)
+{
+	/* Fix it up if it exists, don't create it if it doesn't exist */
+	if (fdt_get_property(blob, nodeoffset, name, 0)) {
+		return fdt_setprop(blob, nodeoffset, name, bd->bi_enet1addr, 6);
+	}
+	return 0;
+}
+#endif
+#ifdef CONFIG_HAS_ETH2
+/* third onboard ethernet port */
+static int fdt_set_eth2(void *blob, int nodeoffset, const char *name, bd_t *bd)
+{
+	/* Fix it up if it exists, don't create it if it doesn't exist */
+	if (fdt_get_property(blob, nodeoffset, name, 0)) {
+		return fdt_setprop(blob, nodeoffset, name, bd->bi_enet2addr, 6);
+	}
+	return 0;
+}
+#endif
+#ifdef CONFIG_HAS_ETH3
+/* fourth onboard ethernet port */
+static int fdt_set_eth3(void *blob, int nodeoffset, const char *name, bd_t *bd)
+{
+	/* Fix it up if it exists, don't create it if it doesn't exist */
+	if (fdt_get_property(blob, nodeoffset, name, 0)) {
+		return fdt_setprop(blob, nodeoffset, name, bd->bi_enet3addr, 6);
+	}
+	return 0;
+}
+#endif
+
+static int fdt_set_busfreq(void *blob, int nodeoffset, const char *name, bd_t *bd)
+{
+	u32 tmp;
+	/* Create or update the property */
+	tmp = cpu_to_be32(bd->bi_busfreq);
+	return fdt_setprop(blob, nodeoffset, name, &tmp, sizeof(tmp));
+}
+
+static int fdt_set_tbfreq(void *blob, int nodeoffset, const char *name, bd_t *bd)
+{
+	u32 tmp;
+	/* Create or update the property */
+	tmp = cpu_to_be32(bd->bi_busfreq / 8);
+	return fdt_setprop(blob, nodeoffset, name, &tmp, sizeof(tmp));
+}
+
+static int fdt_set_stdout_path(void *blob, int nodeoffset, const char *name, bd_t *bd)
+{
+	char buf[256];
+	int err, off;
+
+	off = fdt_path_offset(blob, "/chosen");
+	if (off < 0)
+		return off;
+
+	err = fdt_get_path(blob, nodeoffset, &buf, 256);
+	if (err < 0)
+		return err;
+
+	err = fdt_setprop(blob, off, "linux,stdout-path", buf, err + 1);
+
+	return err;
+}
+
+/*
+ * Fixups to the fdt.
+ */
+
+void fdt_fixups(struct fdt_fixup *tbl, int num, void *blob, bd_t *bd)
+{
+	int j, err, off;
+
+	for (j = 0; j < num; j++) {
+		off = -1;
+		do {
+			if (tbl[j].compat)
+				off = fdt_node_offset_by_prop_and_compat(blob,
+					off, tbl[j].compat, "device_type",
+					tbl[j].type, strlen(tbl[j].type) + 1);
+			else
+				off = fdt_node_offset_by_prop_value(blob, off,
+					"device_type",
+					tbl[j].type, strlen(tbl[j].type) + 1);
+
+			if (off >= 0) {
+				if (tbl[j].name) {
+					int len;
+					const char *name;
+
+					name = fdt_get_name(blob, off, &len);
+					if (strncmp(name, tbl[j].name, len) != 0)
+						continue;
+				}
+
+				err = tbl[j].set_fn(blob, off, tbl[j].prop, bd);
+				if (err < 0)
+					debug("Problem setting %s = %s: %s\n",
+					      tbl[j].node, tbl[j].prop,
+					      fdt_strerror(err));
+			}
+		} while (off >= 0);
+	}
+}
+
 #endif /* CONFIG_OF_LIBFDT */
diff --git a/include/fdt_support.h b/include/fdt_support.h
index 60fa423..f66e562 100644
--- a/include/fdt_support.h
+++ b/include/fdt_support.h
@@ -28,7 +28,18 @@

 #include <fdt.h>

+typedef int (*set_fn_t)(void *blob, int nodeoffset, const char *name, bd_t *bd);
+
+struct fdt_fixup {
+	const char *type;
+	const char *compat;
+	const char *prop;
+	const char *name;
+	set_fn_t set_fn;
+};
+
 int fdt_chosen(void *fdt, ulong initrd_start, ulong initrd_end, int force);
+void fdt_fixups(struct fdt_fixup *tbl, int num, void *blob, bd_t *bd);

 #ifdef CONFIG_OF_HAS_UBOOT_ENV
 int fdt_env(void *fdt);

[U-Boot-Users] [RFC][PATCH] fdt fixup

[gvb.uboot]

Kumar Gala wrote:
> This code adds a generic fixup mechanism that allows us to get ride of
> needing explicit paths to device nodes.
> 
> diff --git a/common/fdt_support.c b/common/fdt_support.c
> index 7a81469..2c1e8ac 100644
> --- a/common/fdt_support.c
> +++ b/common/fdt_support.c
> @@ -363,4 +363,125 @@ int fdt_bd_t(void *fdt)
>  }
>  #endif /* ifdef CONFIG_OF_HAS_BD_T */
> 
> +/*
> + * "Setter" functions used to add/modify FDT entries.
> + */
> +#ifdef CONFIG_HAS_ETH0
> +static int fdt_set_eth0(void *blob, int nodeoffset, const char *name, bd_t *bd)
> +{
> +	/* Fix it up if it exists, don't create it if it doesn't exist */
> +	if (fdt_get_property(blob, nodeoffset, name, 0)) {
> +		return fdt_setprop(blob, nodeoffset, name, bd->bi_enetaddr, 6);
> +	}
> +	return 0;
> +}

[snip a bunch more setter functions]

Hi Kumar,

The direction Grant Likely went with 5xxx and where Sergej was heading 
with 82xx (if only I got around to applying his patch) and where I want 
to go is to replace the table-driven methodology with direct calls to 
more generic functions, eliminating the hordes of specialized "setter" 
functions (all nearly identical).

Discussions and patches:
<http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/32573/focus=32573>
<http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/32577>

If we get the mpc5xxx style setter functions combined with your 
fdt_node_offset_by_prop_and_compat() finding changes, I think we would 
be in fat city.

Best regards,
gvb

P.S. Is David done changing libfdt yet??? ;-)  I saw you are still 
keeping up with him...

[U-Boot-Users] [RFC][PATCH] fdt fixup

[Jon Loeliger]

gvb.uboot wrote:

> P.S. Is David done changing libfdt yet??? ;-)  I saw you are still 
> keeping up with him...
>

I have a couple more patches queued up here still.

jdl

[U-Boot-Users] [RFC][PATCH] fdt fixup

[Kumar Gala]

> [snip a bunch more setter functions]
>
> Hi Kumar,
>
> The direction Grant Likely went with 5xxx and where Sergej was  
> heading with 82xx (if only I got around to applying his patch) and  
> where I want to go is to replace the table-driven methodology with  
> direct calls to more generic functions, eliminating the hordes of  
> specialized "setter" functions (all nearly identical).
>
> Discussions and patches:
> <http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/32573/ 
> focus=32573>
> <http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/32577>
>
> If we get the mpc5xxx style setter functions combined with your  
> fdt_node_offset_by_prop_and_compat() finding changes, I think we  
> would be in fat city.

So we can easily extend what I have to include generic call backs and  
remove the specific set props.  The problem I have with the 5xxx  
mechanism is its requires too much knowledge of how the device tree  
is laid out since it uses explicit paths to the nodes.

The other option is to extend what Grant has.

Today its:

do_fixup_path(fdt, path, prop, val, len, create)
do_fixup_path_u32(fdt,  path, prop, val, create)

Add:

do_fixup_prop(fdt, find_prop, find_propval, findlen, prop, val, len,  
create)
do_fixup_prop_u32(fdt, find_prop, find_propval, findlen, prop, val,  
create)
do_fixup_compat(fdt, compat, prop, val, len, create)
do_fixup_compat_u32(fdt, compat, prop, val, create)
do_fixup_prop_and_compat(fdt, find_prop, find_proval, findlen,  
compat, prop, val, len, create)
do_fixup_prop_and_compat_u32(fdt, find_prop, find_proval, findlen,  
compat, prop, val, create)

We get something like "do_fixup_device_type" by do_fixup_prop(fdt,  
"device_type", ...)

> P.S. Is David done changing libfdt yet??? ;-)  I saw you are still  
> keeping up with him...

Not sure, as jdl commits things I reimport and update.

- k

[U-Boot-Users] [RFC][PATCH] fdt fixup

[Grant Likely]

On 11/2/07, Kumar Gala <galak@kernel.crashing.org> wrote:
> > [snip a bunch more setter functions]
> >
> > Hi Kumar,
> >
> > The direction Grant Likely went with 5xxx and where Sergej was
> > heading with 82xx (if only I got around to applying his patch) and
> > where I want to go is to replace the table-driven methodology with
> > direct calls to more generic functions, eliminating the hordes of
> > specialized "setter" functions (all nearly identical).
> >
> > Discussions and patches:
> > <http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/32573/
> > focus=32573>
> > <http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/32577>
> >
> > If we get the mpc5xxx style setter functions combined with your
> > fdt_node_offset_by_prop_and_compat() finding changes, I think we
> > would be in fat city.
>
> So we can easily extend what I have to include generic call backs and
> remove the specific set props.  The problem I have with the 5xxx
> mechanism is its requires too much knowledge of how the device tree
> is laid out since it uses explicit paths to the nodes.

Yes, I agree.  The hard coded paths are stinky.  Looking for
device_type or compatible might be better.

However, even with using some combination of property values, figuring
out which device is which is still a problem.  (ie, which network
device is eth0 and which is eth1?).  Relying on the implicit order in
the device tree is just as fragile as using the full path.  At least
with using the full path, you don't run the risk of getting the wrong
node (you just don't find the node at all).

I agree with dwg in that I think embedding a "node-index" or similar
property into the node is not a good solution.  This may be yet
another situation where an aliases node would be a good solution.
Have the aliases node populated with the device enumeration (ie. eth0
mapped to "/full/path/to/ethernet at addr") an allow either a full path
to be specified or an alias.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

[U-Boot-Users] [RFC][PATCH] fdt fixup

[Kumar Gala]

On Nov 1, 2007, at 11:00 PM, Grant Likely wrote:

> On 11/2/07, Kumar Gala <galak@kernel.crashing.org> wrote:
>>> [snip a bunch more setter functions]
>>>
>>> Hi Kumar,
>>>
>>> The direction Grant Likely went with 5xxx and where Sergej was
>>> heading with 82xx (if only I got around to applying his patch) and
>>> where I want to go is to replace the table-driven methodology with
>>> direct calls to more generic functions, eliminating the hordes of
>>> specialized "setter" functions (all nearly identical).
>>>
>>> Discussions and patches:
>>> <http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/32573/
>>> focus=32573>
>>> <http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/32577>
>>>
>>> If we get the mpc5xxx style setter functions combined with your
>>> fdt_node_offset_by_prop_and_compat() finding changes, I think we
>>> would be in fat city.
>>
>> So we can easily extend what I have to include generic call backs and
>> remove the specific set props.  The problem I have with the 5xxx
>> mechanism is its requires too much knowledge of how the device tree
>> is laid out since it uses explicit paths to the nodes.
>
> Yes, I agree.  The hard coded paths are stinky.  Looking for
> device_type or compatible might be better.
>
> However, even with using some combination of property values, figuring
> out which device is which is still a problem.  (ie, which network
> device is eth0 and which is eth1?).  Relying on the implicit order in
> the device tree is just as fragile as using the full path.  At least
> with using the full path, you don't run the risk of getting the wrong
> node (you just don't find the node at all).

I wasn't thinking of using implicit order,  We can use reg or the  
node name in addition to compat.

So something like:
	do_fixup_by_compat_and_name(blob, "gianfar", "ethernet at 24000", "mac- 
address", bd->bi_enetaddr, 6)
	do_fixup_by_compat_and_name(blob, "gianfar", "ethernet at 25000", "mac- 
address", bd->bi_enet1addr, 6)
	do_fixup_by_compat_and_name(blob, "gianfar", "ethernet at 26000", "mac- 
address", bd->bi_enet2addr, 6)

or something like:
	u32 reg_buf[2];
	reg_buf[0] = cpu_to_fdt32(0x24000);
	reg_buf[1] = cpu_to_fdt32(0x1000);
	
	do_fixup_by_compat_and_prop(blob, "gianfar", "reg", &reg_buf, 8,  
"mac-address", bd->bi_enetaddr, 6)

	reg_buf[0] = cpu_to_fdt32(0x25000);
	do_fixup_by_compat_and_prop(blob, "gianfar", "reg", &reg_buf, 8,  
"mac-address", bd->bi_enet1addr, 6)

	reg_buf[0] = cpu_to_fdt32(0x26000);
	do_fixup_by_compat_and_prop(blob, "gianfar", "reg", &reg_buf, 8,  
"mac-address", bd->bi_enet2addr, 6)

- k

[U-Boot-Users] [RFC][PATCH] fdt fixup

[Grant Likely]

On 11/2/07, Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Nov 1, 2007, at 11:00 PM, Grant Likely wrote:
>
> > On 11/2/07, Kumar Gala <galak@kernel.crashing.org> wrote:
> >>> [snip a bunch more setter functions]
> >>>
> >>> Hi Kumar,
> >>>
> >>> The direction Grant Likely went with 5xxx and where Sergej was
> >>> heading with 82xx (if only I got around to applying his patch) and
> >>> where I want to go is to replace the table-driven methodology with
> >>> direct calls to more generic functions, eliminating the hordes of
> >>> specialized "setter" functions (all nearly identical).
> >>>
> >>> Discussions and patches:
> >>> <http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/32573/
> >>> focus=32573>
> >>> <http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/32577>
> >>>
> >>> If we get the mpc5xxx style setter functions combined with your
> >>> fdt_node_offset_by_prop_and_compat() finding changes, I think we
> >>> would be in fat city.
> >>
> >> So we can easily extend what I have to include generic call backs and
> >> remove the specific set props.  The problem I have with the 5xxx
> >> mechanism is its requires too much knowledge of how the device tree
> >> is laid out since it uses explicit paths to the nodes.
> >
> > Yes, I agree.  The hard coded paths are stinky.  Looking for
> > device_type or compatible might be better.
> >
> > However, even with using some combination of property values, figuring
> > out which device is which is still a problem.  (ie, which network
> > device is eth0 and which is eth1?).  Relying on the implicit order in
> > the device tree is just as fragile as using the full path.  At least
> > with using the full path, you don't run the risk of getting the wrong
> > node (you just don't find the node at all).
>
> I wasn't thinking of using implicit order,  We can use reg or the
> node name in addition to compat.

Ah, okay.  I wasn't sure if name was optional in your last email.

However, if name is specified does compatible even matter?

Or, on the other hand, is name specific enough?  For example; is it
still possible to wire up two 82xx chips back to back and have one CPU
control both socs?  In which case you could end up with 2 identical
devices with identical node names in the tree.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

[U-Boot-Users] [RFC][PATCH] fdt fixup

[Kumar Gala]

On Nov 1, 2007, at 11:55 PM, Grant Likely wrote:

> On 11/2/07, Kumar Gala <galak@kernel.crashing.org> wrote:
>>
>> On Nov 1, 2007, at 11:00 PM, Grant Likely wrote:
>>
>>> On 11/2/07, Kumar Gala <galak@kernel.crashing.org> wrote:
>>>>> [snip a bunch more setter functions]
>>>>>
>>>>> Hi Kumar,
>>>>>
>>>>> The direction Grant Likely went with 5xxx and where Sergej was
>>>>> heading with 82xx (if only I got around to applying his patch) and
>>>>> where I want to go is to replace the table-driven methodology with
>>>>> direct calls to more generic functions, eliminating the hordes of
>>>>> specialized "setter" functions (all nearly identical).
>>>>>
>>>>> Discussions and patches:
>>>>> <http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/32573/
>>>>> focus=32573>
>>>>> <http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/32577>
>>>>>
>>>>> If we get the mpc5xxx style setter functions combined with your
>>>>> fdt_node_offset_by_prop_and_compat() finding changes, I think we
>>>>> would be in fat city.
>>>>
>>>> So we can easily extend what I have to include generic call  
>>>> backs and
>>>> remove the specific set props.  The problem I have with the 5xxx
>>>> mechanism is its requires too much knowledge of how the device tree
>>>> is laid out since it uses explicit paths to the nodes.
>>>
>>> Yes, I agree.  The hard coded paths are stinky.  Looking for
>>> device_type or compatible might be better.
>>>
>>> However, even with using some combination of property values,  
>>> figuring
>>> out which device is which is still a problem.  (ie, which network
>>> device is eth0 and which is eth1?).  Relying on the implicit  
>>> order in
>>> the device tree is just as fragile as using the full path.  At least
>>> with using the full path, you don't run the risk of getting the  
>>> wrong
>>> node (you just don't find the node at all).
>>
>> I wasn't thinking of using implicit order,  We can use reg or the
>> node name in addition to compat.
>
> Ah, okay.  I wasn't sure if name was optional in your last email.
>
> However, if name is specified does compatible even matter?
>
> Or, on the other hand, is name specific enough?  For example; is it
> still possible to wire up two 82xx chips back to back and have one CPU
> control both socs?  In which case you could end up with 2 identical
> devices with identical node names in the tree.

If you have one cpu controller things will have different reg props  
than.

Name is one way to distinguish.  For a given board you're going to  
know some level of detail about the setup such that you can choose  
the best mechanism to match on.

- k

[U-Boot-Users] [RFC][PATCH] fdt fixup

[Grant Likely]

On 11/2/07, Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Nov 1, 2007, at 11:55 PM, Grant Likely wrote:
>
> > On 11/2/07, Kumar Gala <galak@kernel.crashing.org> wrote:
> >>
> >> On Nov 1, 2007, at 11:00 PM, Grant Likely wrote:
> >>
> >>> On 11/2/07, Kumar Gala <galak@kernel.crashing.org> wrote:
> >>>>> [snip a bunch more setter functions]
> >>>>>
> >>>>> Hi Kumar,
> >>>>>
> >>>>> The direction Grant Likely went with 5xxx and where Sergej was
> >>>>> heading with 82xx (if only I got around to applying his patch) and
> >>>>> where I want to go is to replace the table-driven methodology with
> >>>>> direct calls to more generic functions, eliminating the hordes of
> >>>>> specialized "setter" functions (all nearly identical).
> >>>>>
> >>>>> Discussions and patches:
> >>>>> <http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/32573/
> >>>>> focus=32573>
> >>>>> <http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/32577>
> >>>>>
> >>>>> If we get the mpc5xxx style setter functions combined with your
> >>>>> fdt_node_offset_by_prop_and_compat() finding changes, I think we
> >>>>> would be in fat city.
> >>>>
> >>>> So we can easily extend what I have to include generic call
> >>>> backs and
> >>>> remove the specific set props.  The problem I have with the 5xxx
> >>>> mechanism is its requires too much knowledge of how the device tree
> >>>> is laid out since it uses explicit paths to the nodes.
> >>>
> >>> Yes, I agree.  The hard coded paths are stinky.  Looking for
> >>> device_type or compatible might be better.
> >>>
> >>> However, even with using some combination of property values,
> >>> figuring
> >>> out which device is which is still a problem.  (ie, which network
> >>> device is eth0 and which is eth1?).  Relying on the implicit
> >>> order in
> >>> the device tree is just as fragile as using the full path.  At least
> >>> with using the full path, you don't run the risk of getting the
> >>> wrong
> >>> node (you just don't find the node at all).
> >>
> >> I wasn't thinking of using implicit order,  We can use reg or the
> >> node name in addition to compat.
> >
> > Ah, okay.  I wasn't sure if name was optional in your last email.
> >
> > However, if name is specified does compatible even matter?
> >
> > Or, on the other hand, is name specific enough?  For example; is it
> > still possible to wire up two 82xx chips back to back and have one CPU
> > control both socs?  In which case you could end up with 2 identical
> > devices with identical node names in the tree.
>
> If you have one cpu controller things will have different reg props
> than.

If you have two identical SoCs back-to-back, the soc nodes will have
different ranges, but the device nodes themselves will be pretty much
identical.  You'd need to parse all the ranges properties to get a
real physaddr before you as sure to get a unique addr.

>
> Name is one way to distinguish.  For a given board you're going to
> know some level of detail about the setup such that you can choose
> the best mechanism to match on.

Possibly true; but I am concerned that it just trades one fragile
method (strict path) for another (expected differences between nodes
for identical devices in the tree)

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

[U-Boot-Users] [RFC][PATCH] fdt fixup

[Kumar Gala]

>>> Ah, okay.  I wasn't sure if name was optional in your last email.
>>>
>>> However, if name is specified does compatible even matter?
>>>
>>> Or, on the other hand, is name specific enough?  For example; is it
>>> still possible to wire up two 82xx chips back to back and have  
>>> one CPU
>>> control both socs?  In which case you could end up with 2 identical
>>> devices with identical node names in the tree.
>>
>> If you have one cpu controller things will have different reg props
>> than.
>
> If you have two identical SoCs back-to-back, the soc nodes will have
> different ranges, but the device nodes themselves will be pretty much
> identical.  You'd need to parse all the ranges properties to get a
> real physaddr before you as sure to get a unique addr.

True, we probably need an of_translate_addr() equivalent.

>> Name is one way to distinguish.  For a given board you're going to
>> know some level of detail about the setup such that you can choose
>> the best mechanism to match on.
>
> Possibly true; but I am concerned that it just trades one fragile
> method (strict path) for another (expected differences between nodes
> for identical devices in the tree)

Yeah, I guess the best one can do is leave it up to the developer to  
pick the right method.  Its not as if we'd get ride of explicit path  
fixups.

The idea of aliases is looking more and more appealing to me.

- k

[U-Boot-Users] [RFC][PATCH] fdt fixup

[Grant Likely]

On 11/2/07, Kumar Gala <galak@kernel.crashing.org> wrote:
> > Possibly true; but I am concerned that it just trades one fragile
> > method (strict path) for another (expected differences between nodes
> > for identical devices in the tree)
>
> Yeah, I guess the best one can do is leave it up to the developer to
> pick the right method.  Its not as if we'd get ride of explicit path
> fixups.
>
> The idea of aliases is looking more and more appealing to me.

Indeed.

It also an area where device_type might actually be a useful property
if it is used to auto enumerate devices of the same type.  ie. If the
dtb doesn't explicitly specify eth* aliases, then u-boot could
enumerate them so that generic fixup routines can be used and so Linux
(or other OS) can use the same device numbering as u-boot.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

[U-Boot-Users] [RFC][PATCH] fdt fixup

[Sergej Stepanov]

Am Freitag, den 02.11.2007, 08:56 -0600 schrieb Grant Likely:
> On 11/2/07, Kumar Gala <galak@kernel.crashing.org> wrote:
> > > Possibly true; but I am concerned that it just trades one fragile
> > > method (strict path) for another (expected differences between nodes
> > > for identical devices in the tree)
> >
> > Yeah, I guess the best one can do is leave it up to the developer to
> > pick the right method.  Its not as if we'd get ride of explicit path
> > fixups.
> >
> > The idea of aliases is looking more and more appealing to me.
> 
> Indeed.
> 
> It also an area where device_type might actually be a useful property
> if it is used to auto enumerate devices of the same type.  ie. If the
> dtb doesn't explicitly specify eth* aliases, then u-boot could
> enumerate them so that generic fixup routines can be used and so Linux
> (or other OS) can use the same device numbering as u-boot.
> 
sorry...
in chosen-node select defaults, for example?

-- 
Sergej I. Stepanov
E-PA
IDS GmbH
Nobelstr. 18, Zim. 2.1.05
D-76275 Ettlingen
T +49 (0) 72 43/2 18-615
F +49 (0) 72 43/2 18-400
Email: <Sergej.Stepanov@ids.de>

<http://www.ids.de>
Gesch?ftsf?hrer: Norbert Wagner, Friedrich Abri? 
Sitz der Gesellschaft: Ettlingen 
Amtsgericht Mannheim HRB 362503

[U-Boot-Users] [RFC][PATCH] fdt fixup

[Grant Likely]

On 11/2/07, Sergej Stepanov <Sergej.Stepanov@ids.de> wrote:
> Am Freitag, den 02.11.2007, 08:56 -0600 schrieb Grant Likely:
>
> > It also an area where device_type might actually be a useful property
> > if it is used to auto enumerate devices of the same type.  ie. If the
> > dtb doesn't explicitly specify eth* aliases, then u-boot could
> > enumerate them so that generic fixup routines can be used and so Linux
> > (or other OS) can use the same device numbering as u-boot.
> >
> sorry...
> in chosen-node select defaults, for example?

I don't understand what you mean or are asking, but let me clarify what I mean.

I'm not talking about selected defaults; but about device enumeration
(which is similar, but not exactly the same thing).  If there is a
class of devices which is typically enumerated (like ethernet
devices), then the device_type property *might* be useful because it
would allow firmware to find all devices of a similar type and assign
numbers to them.

Also, OF has an 'aliases' mechanism defined which could be very
useful.  The '/aliases' node contains a set of properties which assign
a set of 'simple' names to the full path of a node.  For example, on
the efika, /aliases looks like this:

ok cd /aliases
ok .properties
name                  "aliases"
eth                   "/builtin/ethernet"
ok

Now; for our purposes, using name->full_path mapping is probably
sub-optimal and name->phandle might be better.  But regardless, the
alias can be used as a shortcut to refer to a particular node.  For
example, on the efika:

ok cd /
ok cd eth
ok pwd
/builtin at F0000000/ethernet at F0003000
ok

So, if the aliases node was populated with common names, or if u-boot
could auto-populate the /aliases node with enumerated values for
things like 'eth#' and 'serial#', then we could do something like this
for fixups:

do_fixup_by_name(blob, "eth0", "mac-address", bd->bi_enetaddr, 6)
do_fixup_by_name(blob, "eth1", "mac-address", bd->bi_enet1addr, 6)
do_fixup_by_name(blob, "eth2", "mac-address", bd->bi_enet2addr, 6)

Which will work for *any* board, regardless of where the ethernet
nodes are in the tree.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

[U-Boot-Users] [RFC][PATCH] fdt fixup

[Kumar Gala]

On Nov 2, 2007, at 10:47 AM, Grant Likely wrote:

> On 11/2/07, Sergej Stepanov <Sergej.Stepanov@ids.de> wrote:
>> Am Freitag, den 02.11.2007, 08:56 -0600 schrieb Grant Likely:
>>
>>> It also an area where device_type might actually be a useful  
>>> property
>>> if it is used to auto enumerate devices of the same type.  ie. If  
>>> the
>>> dtb doesn't explicitly specify eth* aliases, then u-boot could
>>> enumerate them so that generic fixup routines can be used and so  
>>> Linux
>>> (or other OS) can use the same device numbering as u-boot.
>>>
>> sorry...
>> in chosen-node select defaults, for example?
>
> I don't understand what you mean or are asking, but let me clarify  
> what I mean.
>
> I'm not talking about selected defaults; but about device enumeration
> (which is similar, but not exactly the same thing).  If there is a
> class of devices which is typically enumerated (like ethernet
> devices), then the device_type property *might* be useful because it
> would allow firmware to find all devices of a similar type and assign
> numbers to them.
>
> Also, OF has an 'aliases' mechanism defined which could be very
> useful.  The '/aliases' node contains a set of properties which assign
> a set of 'simple' names to the full path of a node.  For example, on
> the efika, /aliases looks like this:
>
> ok cd /aliases
> ok .properties
> name                  "aliases"
> eth                   "/builtin/ethernet"
> ok
>
> Now; for our purposes, using name->full_path mapping is probably
> sub-optimal and name->phandle might be better.  But regardless, the
> alias can be used as a shortcut to refer to a particular node.  For
> example, on the efika:
>
> ok cd /
> ok cd eth
> ok pwd
> /builtin at F0000000/ethernet at F0003000
> ok
>
> So, if the aliases node was populated with common names, or if u-boot
> could auto-populate the /aliases node with enumerated values for
> things like 'eth#' and 'serial#', then we could do something like this
> for fixups:

I dont see how u-boot could auto-populate, that seems to defeat the  
purpose of aliases.

- k

[U-Boot-Users] [RFC][PATCH] fdt fixup

[Grant Likely]

On 11/3/07, Kumar Gala <galak@kernel.crashing.org> wrote:
> > So, if the aliases node was populated with common names, or if u-boot
> > could auto-populate the /aliases node with enumerated values for
> > things like 'eth#' and 'serial#', then we could do something like this
> > for fixups:
>
> I dont see how u-boot could auto-populate, that seems to defeat the
> purpose of aliases.

As I said, it *might* make sense.  :-)

I'm thinking in terms of if aliases are provided then use them.  But
that doesn't preclude u-boot assigning aliases to device nodes that
don't have them.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195