fdt fixup
RFC PATCH 1/1 fdt fixup
This code adds a generic fixup mechanism that allows us to get ride of needing explicit paths to device nodes.
common/fdt_support.c +121 -0
@@ -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 */
include/fdt_support.h +11 -0
@@ -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);
RFC PATCH 1/1 fdt fixup
Quoted 13 lines · Kumar Gala
This code adds a generic fixup mechanism that allows us to get ride of needing explicit paths to device nodes.
common/fdt_support.c +2
-0@@ -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.
common/fdt_support.c int fdt_bd_t(void *fdt) · line 377
Quoted 10 lines
common/fdt_support.c +10
-0+*/ +#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...
RFC PATCH 1/1 fdt fixup
Quoted 10 lines
[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).
Quoted 8 lines
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", ...)
Quoted 2 lines
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
RFC PATCH 1/1 fdt fixup
Quoted 15 lines · Kumar Gala
Quoted 15 lines
[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>
Quoted 8 lines
Quoted 3 lines
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.
Signature · 4 lines
Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. grant.likely at secretlab.ca (403) 399-0195
RFC PATCH 1/1 fdt fixup
Quoted 28 lines · Grant Likely
Quoted 15 lines · Kumar Gala
Quoted 15 lines
[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>Quoted 8 lines
Quoted 3 lines
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_typeor compatible might be better.
Quoted 6 lines
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", ®_buf, 8,
"mac-address", bd->bi_enetaddr, 6)
reg_buf[0] = cpu_to_fdt32(0x25000); do_fixup_by_compat_and_prop(blob, "gianfar", "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", ®_buf, 8,
"mac-address", bd->bi_enet2addr, 6)
- k
RFC PATCH 1/1 fdt fixup
Quoted 38 lines · Kumar Gala
Quoted 28 lines · Grant Likely
Quoted 15 lines · Kumar Gala
Quoted 15 lines
[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>Quoted 8 lines
Quoted 3 lines
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_typeor compatible might be better.Quoted 6 lines
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).
Quoted 2 lines
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.
Signature · 4 lines
Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. grant.likely at secretlab.ca (403) 399-0195
RFC PATCH 1/1 fdt fixup
Quoted 46 lines · Grant Likely
Quoted 42 lines · Kumar Gala
Quoted 29 lines · Grant Likely
Quoted 19 lines · Kumar Gala
Quoted 10 lines
[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).
Quoted 8 lines
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.Quoted 5 lines
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_typeor compatible might be better.Quoted 9 lines
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).Quoted 2 lines
I wasn't thinking of using implicit order, We can use reg or the node name in addition to compat.
Quoted 8 lines
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
RFC PATCH 1/1 fdt fixup
Quoted 53 lines · Kumar Gala
Quoted 50 lines · Grant Likely
Quoted 42 lines · Kumar Gala
Quoted 29 lines · Grant Likely
Quoted 19 lines · Kumar Gala
Quoted 10 lines
[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).
Quoted 8 lines
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.Quoted 5 lines
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_typeor compatible might be better.Quoted 9 lines
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).Quoted 2 lines
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?
Quoted 7 lines
Quoted 4 lines
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.
Quoted 4 lines
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.
Signature · 4 lines
Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. grant.likely at secretlab.ca (403) 399-0195
RFC PATCH 1/1 fdt fixup
Quoted 10 lines
Quoted 10 lines
Quoted 9 lines
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.
Quoted 7 lines
Quoted 2 lines
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.
Quoted 7 lines
Quoted 3 lines
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
RFC PATCH 1/1 fdt fixup
Quoted 9 lines · Kumar Gala
Quoted 3 lines
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.
Signature · 4 lines
Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. grant.likely at secretlab.ca (403) 399-0195
RFC PATCH 1/1 fdt fixup
Am Freitag, den 02.11.2007, 08:56 -0600 schrieb Grant Likely:
Quoted 11 lines · Kumar Gala
Quoted 9 lines
Quoted 3 lines
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.
Quoted 8 lines
Indeed.
It also an area where
device_typemight 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?
Signature · 13 lines
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: <[email protected]> <http://www.ids.de> Gesch?ftsf?hrer: Norbert Wagner, Friedrich Abri? Sitz der Gesellschaft: Ettlingen Amtsgericht Mannheim HRB 362503
RFC PATCH 1/1 fdt fixup
Quoted 10 lines · Sergej Stepanov
Am Freitag, den 02.11.2007, 08:56 -0600 schrieb Grant Likely:
Quoted 6 lines
It also an area where
device_typemight 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.
Signature · 4 lines
Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. grant.likely at secretlab.ca (403) 399-0195
RFC PATCH 1/1 fdt fixup
Quoted 47 lines · Grant Likely
Quoted 11 lines · Sergej Stepanov
Am Freitag, den 02.11.2007, 08:56 -0600 schrieb Grant Likely:
Quoted 9 lines
It also an area where
device_typemight 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.Quoted 2 lines
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_typeproperty *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"
okNow; for our purposes, using
name->full_pathmapping is probably sub-optimal andname->phandlemight 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
Quoted 4 lines
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
RFC PATCH 1/1 fdt fixup
Quoted 7 lines · Kumar Gala
Quoted 4 lines
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.
Signature · 4 lines
Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. grant.likely at secretlab.ca (403) 399-0195
RFC PATCH 1/1 fdt fixup
In reply to gvb.ubootQuoted 3 lines · gvb.uboot
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