[U-Boot-Users] [PATCH/RFC] mpc5200: switch to CONFIG_OF_LIBFDT
From: Grant Likely grant.likely@secretlab.ca
Here is a patch which converts the icecube* and tqm5200 boards from using OF_FLAT_TREE to OF_LIBFDT. It also fixes the compile of cm5200.
It's been tested on the lite5200.
Still to be resolved: is there a better place to put the helper functions.
Signed-off-by: Grant Likely grant.likely@secretlab.ca ---
board/icecube/icecube.c | 10 ++++--- board/tqm5200/tqm5200.c | 12 +++++--- cpu/mpc5xxx/cpu.c | 67 ++++++++++++++++++++++++++++----------------- include/configs/IceCube.h | 2 + include/configs/TQM5200.h | 2 + 5 files changed, 57 insertions(+), 36 deletions(-)
diff --git a/board/icecube/icecube.c b/board/icecube/icecube.c index c027f6f..6a2a77a 100644 --- a/board/icecube/icecube.c +++ b/board/icecube/icecube.c @@ -29,9 +29,11 @@ #include <pci.h> #include <asm/processor.h>
-#if defined(CONFIG_OF_FLAT_TREE) -#include <ft_build.h> -#endif +#ifdef CONFIG_OF_LIBFDT +#include <libfdt.h> +#include <libfdt_env.h> +#include <fdt_support.h> +#endif /* CONFIG_OF_LIBFDT */
#if defined(CONFIG_LITE5200B) #include "mt46v32m16.h" @@ -386,7 +388,7 @@ void ide_set_reset (int idereset) } #endif
-#if defined(CONFIG_OF_FLAT_TREE) && defined(CONFIG_OF_BOARD_SETUP) +#if defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP) void ft_board_setup(void *blob, bd_t *bd) { diff --git a/board/tqm5200/tqm5200.c b/board/tqm5200/tqm5200.c index 51f4aeb..09f1709 100644 --- a/board/tqm5200/tqm5200.c +++ b/board/tqm5200/tqm5200.c @@ -32,9 +32,11 @@ #include <pci.h> #include <asm/processor.h>
-#if defined(CONFIG_OF_FLAT_TREE) -#include <ft_build.h> -#endif +#ifdef CONFIG_OF_LIBFDT +#include <libfdt.h> +#include <libfdt_env.h> +#include <fdt_support.h> +#endif /* CONFIG_OF_LIBFDT */
#ifdef CONFIG_VIDEO_SM501 #include <sm501.h> @@ -780,9 +782,9 @@ int board_get_height (void)
#endif /* CONFIG_VIDEO_SM501 */
-#if defined(CONFIG_OF_FLAT_TREE) && defined(CONFIG_OF_BOARD_SETUP) +#if defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP) void ft_board_setup(void *blob, bd_t *bd) { ft_cpu_setup(blob, bd); } -#endif /* defined(CONFIG_OF_FLAT_TREE) && defined(CONFIG_OF_BOARD_SETUP) */ +#endif /* defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP) */ diff --git a/cpu/mpc5xxx/cpu.c b/cpu/mpc5xxx/cpu.c index 1eac2bb..bb3ad49 100644 --- a/cpu/mpc5xxx/cpu.c +++ b/cpu/mpc5xxx/cpu.c @@ -31,8 +31,9 @@ #include <mpc5xxx.h> #include <asm/processor.h>
-#if defined(CONFIG_OF_FLAT_TREE) -#include <ft_build.h> +#if defined(CONFIG_OF_LIBFDT) +#include <libfdt.h> +#include <libfdt_env.h> #endif
DECLARE_GLOBAL_DATA_PTR; @@ -111,29 +112,45 @@ unsigned long get_tbclk (void)
/* ------------------------------------------------------------------------- */
-#ifdef CONFIG_OF_FLAT_TREE -void -ft_cpu_setup(void *blob, bd_t *bd) +#ifdef CONFIG_OF_LIBFDT +static void fixup_prop(void *fdt, char *node, char *prop, void *val, int size, + int create) { - u32 *p; - int len; - - /* Core XLB bus frequency */ - p = ft_get_prop(blob, "/cpus/" OF_CPU "/bus-frequency", &len); - if (p != NULL) - *p = cpu_to_be32(bd->bi_busfreq); - - /* SOC peripherals use the IPB bus frequency */ - p = ft_get_prop(blob, "/" OF_SOC "/bus-frequency", &len); - if (p != NULL) - *p = cpu_to_be32(bd->bi_ipbfreq); - - p = ft_get_prop(blob, "/" OF_SOC "/ethernet@3000/mac-address", &len); - if (p != NULL) - memcpy(p, bd->bi_enetaddr, 6); - - p = ft_get_prop(blob, "/" OF_SOC "/ethernet@3000/local-mac-address", &len); - if (p != NULL) - memcpy(p, bd->bi_enetaddr, 6); + int nodeoff; + int rc; + + nodeoff = fdt_find_node_by_path(fdt, node); + if (nodeoff < 0) { + printf("Couldn't find %s:%s\n", node, fdt_strerror(nodeoff)); + return; + } + + if ((!create) && (fdt_get_property(fdt, nodeoff, prop, 0) == NULL)) + return; + + rc = fdt_setprop(fdt, nodeoff, prop, val, size); + if (rc) + printf("Problem setting %s = %s: %s\n", + node, prop, fdt_strerror(rc)); +} + +static void fixup_int_prop(void *fdt, char *node, char *prop, u32 val, + int create) +{ + val = cpu_to_be32(val); + fixup_prop(fdt, node, prop, &val, sizeof(val), create); +} + +void ft_cpu_setup(void *blob, bd_t *bd) +{ + char * cpu_path = "/cpus/" OF_CPU; + char * eth_path = "/" OF_SOC "/ethernet@3000"; + + fixup_int_prop(blob, cpu_path, "timebase-frequency", OF_TBCLK, 1); + fixup_int_prop(blob, cpu_path, "bus-frequency", bd->bi_busfreq, 1); + fixup_int_prop(blob, cpu_path, "clock-frequency", bd->bi_intfreq, 1); + fixup_int_prop(blob, "/" OF_SOC, "bus-frequency", bd->bi_ipbfreq, 1); + fixup_prop(blob, eth_path, "mac-address", bd->bi_enetaddr, 6, 0); + fixup_prop(blob, eth_path, "local-mac-address", bd->bi_enetaddr, 6, 0); } #endif diff --git a/include/configs/IceCube.h b/include/configs/IceCube.h index bdd92ba..4c16d22 100644 --- a/include/configs/IceCube.h +++ b/include/configs/IceCube.h @@ -178,7 +178,7 @@ #endif /* CONFIG_MPC5200 */
/* pass open firmware flat tree */ -#define CONFIG_OF_FLAT_TREE 1 +#define CONFIG_OF_LIBFDT 1 #define CONFIG_OF_BOARD_SETUP 1
#define OF_CPU "PowerPC,5200@0" diff --git a/include/configs/TQM5200.h b/include/configs/TQM5200.h index c08173b..e0c9d81 100644 --- a/include/configs/TQM5200.h +++ b/include/configs/TQM5200.h @@ -701,7 +701,7 @@ * Open firmware flat tree support *----------------------------------------------------------------------- */ -#define CONFIG_OF_FLAT_TREE 1 +#define CONFIG_OF_LIBFDT 1 #define CONFIG_OF_BOARD_SETUP 1
#define OF_CPU "PowerPC,5200@0"
On Thu, 30 Aug 2007 12:20:14 -0600 Grant Likely grant.likely@secretlab.ca wrote:
From: Grant Likely grant.likely@secretlab.ca
Here is a patch which converts the icecube* and tqm5200 boards from using OF_FLAT_TREE to OF_LIBFDT. It also fixes the compile of cm5200.
It's been tested on the lite5200.
Still to be resolved: is there a better place to put the helper functions.
the way you've done them, they probably belong in libfdt space.
diff --git a/board/icecube/icecube.c b/board/icecube/icecube.c index c027f6f..6a2a77a 100644 --- a/board/icecube/icecube.c +++ b/board/icecube/icecube.c @@ -29,9 +29,11 @@ #include <pci.h> #include <asm/processor.h>
-#if defined(CONFIG_OF_FLAT_TREE) -#include <ft_build.h> -#endif +#ifdef CONFIG_OF_LIBFDT +#include <libfdt.h>
+#include <libfdt_env.h> +#include <fdt_support.h>
you really don't need (or want) the above two.
+#endif /* CONFIG_OF_LIBFDT */
diff --git a/board/tqm5200/tqm5200.c b/board/tqm5200/tqm5200.c index 51f4aeb..09f1709 100644 --- a/board/tqm5200/tqm5200.c +++ b/board/tqm5200/tqm5200.c @@ -32,9 +32,11 @@ #include <pci.h> #include <asm/processor.h>
-#if defined(CONFIG_OF_FLAT_TREE) -#include <ft_build.h> -#endif +#ifdef CONFIG_OF_LIBFDT +#include <libfdt.h> +#include <libfdt_env.h> +#include <fdt_support.h>
ditto.
+#endif /* CONFIG_OF_LIBFDT */
do the includes need such protection?
+void ft_cpu_setup(void *blob, bd_t *bd) +{
- char * cpu_path = "/cpus/" OF_CPU;
- char * eth_path = "/" OF_SOC "/ethernet@3000";
s/char * /char */
actually, we should get rid of OF_CPU, and OF_SOC altogether. fdt_find_node_by_type "cpu" and "soc" should be used instead. The cpu update code probably belongs in lib_ppc.
Kim
On 8/30/07, Kim Phillips kim.phillips@freescale.com wrote:
On Thu, 30 Aug 2007 12:20:14 -0600 Grant Likely grant.likely@secretlab.ca wrote:
From: Grant Likely grant.likely@secretlab.ca
Here is a patch which converts the icecube* and tqm5200 boards from using OF_FLAT_TREE to OF_LIBFDT. It also fixes the compile of cm5200.
It's been tested on the lite5200.
Still to be resolved: is there a better place to put the helper functions.
the way you've done them, they probably belong in libfdt space.
diff --git a/board/icecube/icecube.c b/board/icecube/icecube.c index c027f6f..6a2a77a 100644 --- a/board/icecube/icecube.c +++ b/board/icecube/icecube.c @@ -29,9 +29,11 @@ #include <pci.h> #include <asm/processor.h>
-#if defined(CONFIG_OF_FLAT_TREE) -#include <ft_build.h> -#endif +#ifdef CONFIG_OF_LIBFDT +#include <libfdt.h>
+#include <libfdt_env.h> +#include <fdt_support.h>
you really don't need (or want) the above two.
Okay, I'll pull them out.
-#if defined(CONFIG_OF_FLAT_TREE) -#include <ft_build.h> -#endif +#ifdef CONFIG_OF_LIBFDT +#include <libfdt.h> +#include <libfdt_env.h> +#include <fdt_support.h>
ditto.
+#endif /* CONFIG_OF_LIBFDT */
do the includes need such protection?
There are a number of 5200 boards that haven't been migrated to support fdt yet, so I left the protection in. I suppose it can be removed.
+void ft_cpu_setup(void *blob, bd_t *bd) +{
char * cpu_path = "/cpus/" OF_CPU;char * eth_path = "/" OF_SOC "/ethernet@3000";s/char * /char */
actually, we should get rid of OF_CPU, and OF_SOC altogether. fdt_find_node_by_type "cpu" and "soc" should be used instead. The cpu update code probably belongs in lib_ppc.
Sure, but if it's okay by you, I'd like to do that in another patch. In this case, I want to minimize the impact to 5xxx boards.
Thanks, g.
On 8/30/07, Grant Likely grant.likely@secretlab.ca wrote:
On 8/30/07, Kim Phillips kim.phillips@freescale.com wrote:
On Thu, 30 Aug 2007 12:20:14 -0600 Grant Likely grant.likely@secretlab.ca wrote:
From: Grant Likely grant.likely@secretlab.ca
Here is a patch which converts the icecube* and tqm5200 boards from using OF_FLAT_TREE to OF_LIBFDT. It also fixes the compile of cm5200.
It's been tested on the lite5200.
Still to be resolved: is there a better place to put the helper functions.
the way you've done them, they probably belong in libfdt space.
diff --git a/board/icecube/icecube.c b/board/icecube/icecube.c index c027f6f..6a2a77a 100644 --- a/board/icecube/icecube.c +++ b/board/icecube/icecube.c @@ -29,9 +29,11 @@ #include <pci.h> #include <asm/processor.h>
-#if defined(CONFIG_OF_FLAT_TREE) -#include <ft_build.h> -#endif +#ifdef CONFIG_OF_LIBFDT +#include <libfdt.h>
+#include <libfdt_env.h> +#include <fdt_support.h>
you really don't need (or want) the above two.
Okay, I'll pull them out.
-#if defined(CONFIG_OF_FLAT_TREE) -#include <ft_build.h> -#endif +#ifdef CONFIG_OF_LIBFDT +#include <libfdt.h> +#include <libfdt_env.h> +#include <fdt_support.h>
ditto.
+#endif /* CONFIG_OF_LIBFDT */
do the includes need such protection?
There are a number of 5200 boards that haven't been migrated to support fdt yet, so I left the protection in. I suppose it can be removed.
Ignore this comment; I was on crack.. Of course the protections are not needed for the board specific code. I'll fix.
g.
Grant Likely wrote: [...]
-#if defined(CONFIG_OF_FLAT_TREE) -#include <ft_build.h> -#endif +#ifdef CONFIG_OF_LIBFDT +#include <libfdt.h> +#include <libfdt_env.h> +#include <fdt_support.h>
ditto.
+#endif /* CONFIG_OF_LIBFDT */
do the includes need such protection?
There are a number of 5200 boards that haven't been migrated to support fdt yet, so I left the protection in. I suppose it can be removed.
Ignore this comment; I was on crack.. Of course the protections are not needed for the board specific code. I'll fix.
Could similar protections around ft_board_setup() definition in board-specific code be removed as well? I'm thinking about:
#if defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP) void ft_board_setup(void *blob, bd_t *bd) { ft_cpu_setup(blob, bd); } #endif /* defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP) */
Regards, Bartlomiej
On 9/3/07, Bartlomiej Sieka tur@semihalf.com wrote:
Grant Likely wrote: [...]
-#if defined(CONFIG_OF_FLAT_TREE) -#include <ft_build.h> -#endif +#ifdef CONFIG_OF_LIBFDT +#include <libfdt.h> +#include <libfdt_env.h> +#include <fdt_support.h>
ditto.
+#endif /* CONFIG_OF_LIBFDT */
do the includes need such protection?
There are a number of 5200 boards that haven't been migrated to support fdt yet, so I left the protection in. I suppose it can be removed.
Ignore this comment; I was on crack.. Of course the protections are not needed for the board specific code. I'll fix.
Could similar protections around ft_board_setup() definition in board-specific code be removed as well? I'm thinking about:
#if defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP) void ft_board_setup(void *blob, bd_t *bd) { ft_cpu_setup(blob, bd); } #endif /* defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP) */
I considered this, but ultimately decided not to do it (yet). It is still possible that someone will want to configure one of these boards without fdt support. In this case, the protection around the includes is benign, but ft_board_setup is not.
Also, there are some boards which use the tqm5200 board code, but whose config file is not setup to use LIBFDT.
Cheers, g.
On Thu, Aug 30, 2007 at 12:20:14PM -0600, Grant Likely wrote:
From: Grant Likely grant.likely@secretlab.ca
Here is a patch which converts the icecube* and tqm5200 boards from using OF_FLAT_TREE to OF_LIBFDT. It also fixes the compile of cm5200.
It's been tested on the lite5200.
Tested also on motionpro, with the below patch that converts it to OF_LIBFDT.
Grant: perhaps it would be a good idea to merge this patch with your upcoming updated patch for icecube and tqm5200?
Regards, Bartlomiej
diff --git a/board/motionpro/motionpro.c b/board/motionpro/motionpro.c index 6eb5fe9..f83998e 100644 --- a/board/motionpro/motionpro.c +++ b/board/motionpro/motionpro.c @@ -29,9 +29,7 @@ #include <common.h> #include <mpc5xxx.h> #include <miiphy.h> -#if defined(CONFIG_OF_FLAT_TREE) -#include <ft_build.h> -#endif +#include <libfdt.h>
#if defined(CONFIG_STATUS_LED) #include <status_led.h> @@ -196,12 +194,12 @@ int checkboard(void) }
-#if defined(CONFIG_OF_FLAT_TREE) && defined(CONFIG_OF_BOARD_SETUP) +#if defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP) void ft_board_setup(void *blob, bd_t *bd) { ft_cpu_setup(blob, bd); } -#endif /* defined(CONFIG_OF_FLAT_TREE) && defined(CONFIG_OF_BOARD_SETUP) */ +#endif /* defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP) */
#if defined(CONFIG_STATUS_LED) diff --git a/include/configs/motionpro.h b/include/configs/motionpro.h index 82827c6..9a21632 100644 --- a/include/configs/motionpro.h +++ b/include/configs/motionpro.h @@ -417,7 +417,7 @@ extern void __led_set(led_id_t id, int state); #define CFG_RESET_ADDRESS 0xfff00100
/* pass open firmware flat tree */ -#define CONFIG_OF_FLAT_TREE 1 +#define CONFIG_OF_LIBFDT 1 #define CONFIG_OF_BOARD_SETUP 1
#define OF_CPU "PowerPC,5200@0"
On 9/3/07, Bartlomiej Sieka tur@semihalf.com wrote:
On Thu, Aug 30, 2007 at 12:20:14PM -0600, Grant Likely wrote:
From: Grant Likely grant.likely@secretlab.ca
Here is a patch which converts the icecube* and tqm5200 boards from using OF_FLAT_TREE to OF_LIBFDT. It also fixes the compile of cm5200.
It's been tested on the lite5200.
Tested also on motionpro, with the below patch that converts it to OF_LIBFDT.
Grant: perhaps it would be a good idea to merge this patch with your upcoming updated patch for icecube and tqm5200?
Can do. I'll respin the patch and post it once more to the list before asking wd to pull it.
Cheers, g.
Grant Likely wrote:
On 9/3/07, Bartlomiej Sieka tur@semihalf.com wrote:
On Thu, Aug 30, 2007 at 12:20:14PM -0600, Grant Likely wrote:
From: Grant Likely grant.likely@secretlab.ca
Here is a patch which converts the icecube* and tqm5200 boards from using OF_FLAT_TREE to OF_LIBFDT. It also fixes the compile of cm5200.
It's been tested on the lite5200.
Tested also on motionpro, with the below patch that converts it to OF_LIBFDT.
Grant: perhaps it would be a good idea to merge this patch with your upcoming updated patch for icecube and tqm5200?
Can do. I'll respin the patch and post it once more to the list before asking wd to pull it.
Cheers, g.
Hi Grant,
My only critique/request is to change fixup_int_prop() to be fixup_u32_prop() so that we don't get confused if we ever have to fix up a u16 or u64 property.
Thanks, gvb
On 9/3/07, Jerry Van Baren vanbargw@gmail.com wrote:
Grant Likely wrote:
On 9/3/07, Bartlomiej Sieka tur@semihalf.com wrote:
On Thu, Aug 30, 2007 at 12:20:14PM -0600, Grant Likely wrote:
From: Grant Likely grant.likely@secretlab.ca
Here is a patch which converts the icecube* and tqm5200 boards from using OF_FLAT_TREE to OF_LIBFDT. It also fixes the compile of cm5200.
It's been tested on the lite5200.
Tested also on motionpro, with the below patch that converts it to OF_LIBFDT.
Grant: perhaps it would be a good idea to merge this patch with your upcoming updated patch for icecube and tqm5200?
Can do. I'll respin the patch and post it once more to the list before asking wd to pull it.
Cheers, g.
Hi Grant,
My only critique/request is to change fixup_int_prop() to be fixup_u32_prop() so that we don't get confused if we ever have to fix up a u16 or u64 property.
No problem. Should I move it to libfdt as well?
g.
Grant Likely wrote:
On 9/3/07, Jerry Van Baren vanbargw@gmail.com wrote:
Grant Likely wrote:
On 9/3/07, Bartlomiej Sieka tur@semihalf.com wrote:
On Thu, Aug 30, 2007 at 12:20:14PM -0600, Grant Likely wrote:
From: Grant Likely grant.likely@secretlab.ca
Here is a patch which converts the icecube* and tqm5200 boards from using OF_FLAT_TREE to OF_LIBFDT. It also fixes the compile of cm5200.
It's been tested on the lite5200.
Tested also on motionpro, with the below patch that converts it to OF_LIBFDT.
Grant: perhaps it would be a good idea to merge this patch with your upcoming updated patch for icecube and tqm5200?
Can do. I'll respin the patch and post it once more to the list before asking wd to pull it.
Cheers, g.
Hi Grant,
My only critique/request is to change fixup_int_prop() to be fixup_u32_prop() so that we don't get confused if we ever have to fix up a u16 or u64 property.
No problem. Should I move it to libfdt as well?
g.
Sure!
We have a 3-way coordination between you, Kim with the 83xx, and myself with libfdt and right now I'm pretty busy. I have not had the time to figure out where the routine should go and get together a set of patches for libfdt and 83xx to convert over to the New Improved helper routines.
If you are willing to figure out where to put it in libfdt, I'll push forward from this end but it may be a couple of weeks before I can put some time in on it (unless my more "urgent" duties get boring ;-).
In the last merge window, Kim & I traded some patches back and forth and git figured it out OK, so we should be able to apply the same patch to both your and my (and Kim's?) repositories and have it all work out.
Thanks, gvb
On 9/3/07, Jerry Van Baren vanbargw@gmail.com wrote:
Grant Likely wrote:
On 9/3/07, Jerry Van Baren vanbargw@gmail.com wrote:
Grant Likely wrote:
On 9/3/07, Bartlomiej Sieka tur@semihalf.com wrote:
On Thu, Aug 30, 2007 at 12:20:14PM -0600, Grant Likely wrote:
From: Grant Likely grant.likely@secretlab.ca
Here is a patch which converts the icecube* and tqm5200 boards from using OF_FLAT_TREE to OF_LIBFDT. It also fixes the compile of cm5200.
It's been tested on the lite5200.
Tested also on motionpro, with the below patch that converts it to OF_LIBFDT.
Grant: perhaps it would be a good idea to merge this patch with your upcoming updated patch for icecube and tqm5200?
Can do. I'll respin the patch and post it once more to the list before asking wd to pull it.
Cheers, g.
Hi Grant,
My only critique/request is to change fixup_int_prop() to be fixup_u32_prop() so that we don't get confused if we ever have to fix up a u16 or u64 property.
No problem. Should I move it to libfdt as well?
g.
Sure!
We have a 3-way coordination between you, Kim with the 83xx, and myself with libfdt and right now I'm pretty busy. I have not had the time to figure out where the routine should go and get together a set of patches for libfdt and 83xx to convert over to the New Improved helper routines.
If you are willing to figure out where to put it in libfdt, I'll push forward from this end but it may be a couple of weeks before I can put some time in on it (unless my more "urgent" duties get boring ;-).
In the last merge window, Kim & I traded some patches back and forth and git figured it out OK, so we should be able to apply the same patch to both your and my (and Kim's?) repositories and have it all work out.
Alright, I'll do so. Where does the 'upstream' libfdt source live nowdays? Do you want me to craft the change against the u-boot repo and let you merge it back in to libfdt upstream? Or should I put a temporary change into u-boot to fix the compile issues and base my patch against libfdt upstream (with the mind to remove the temporary fix when u-boot resyncs)?
Cheers, g.
Grant Likely wrote:
On 9/3/07, Jerry Van Baren vanbargw@gmail.com wrote:
Grant Likely wrote:
On 9/3/07, Jerry Van Baren vanbargw@gmail.com wrote:
Grant Likely wrote:
On 9/3/07, Bartlomiej Sieka tur@semihalf.com wrote:
On Thu, Aug 30, 2007 at 12:20:14PM -0600, Grant Likely wrote: > From: Grant Likely grant.likely@secretlab.ca > > Here is a patch which converts the icecube* and tqm5200 boards from using > OF_FLAT_TREE to OF_LIBFDT. It also fixes the compile of cm5200. > > It's been tested on the lite5200. Tested also on motionpro, with the below patch that converts it to OF_LIBFDT.
Grant: perhaps it would be a good idea to merge this patch with your upcoming updated patch for icecube and tqm5200?
Can do. I'll respin the patch and post it once more to the list before asking wd to pull it.
Cheers, g.
Hi Grant,
My only critique/request is to change fixup_int_prop() to be fixup_u32_prop() so that we don't get confused if we ever have to fix up a u16 or u64 property.
No problem. Should I move it to libfdt as well?
g.
Sure!
We have a 3-way coordination between you, Kim with the 83xx, and myself with libfdt and right now I'm pretty busy. I have not had the time to figure out where the routine should go and get together a set of patches for libfdt and 83xx to convert over to the New Improved helper routines.
If you are willing to figure out where to put it in libfdt, I'll push forward from this end but it may be a couple of weeks before I can put some time in on it (unless my more "urgent" duties get boring ;-).
In the last merge window, Kim & I traded some patches back and forth and git figured it out OK, so we should be able to apply the same patch to both your and my (and Kim's?) repositories and have it all work out.
Alright, I'll do so. Where does the 'upstream' libfdt source live nowdays? Do you want me to craft the change against the u-boot repo and let you merge it back in to libfdt upstream? Or should I put a temporary change into u-boot to fix the compile issues and base my patch against libfdt upstream (with the mind to remove the temporary fix when u-boot resyncs)?
Cheers, g.
Hi Grant,
The libfdt custodian repo is on the denx.de site, but should be the same as the mainline. I would say patch your 5xxx custodian repo, publishing the new functions that impact the libfdt stuff as a separate patch and The List can discuss them. I'll "ack" them and apply them to my repo as well, but NBD. I will plan on updating the 83xx implementation(s) and publish them for Kim to ack/adopt as well.
When we get the basics of the New Improved[tm] utility functions set up, we can redo the 83xx at our leisure.
Best regards, gvb
On 9/3/07, Jerry Van Baren vanbargw@gmail.com wrote:
Hi Grant,
The libfdt custodian repo is on the denx.de site, but should be the same as the mainline. I would say patch your 5xxx custodian repo, publishing the new functions that impact the libfdt stuff as a separate patch and The List can discuss them. I'll "ack" them and apply them to my repo as well, but NBD. I will plan on updating the 83xx implementation(s) and publish them for Kim to ack/adopt as well.
Ah, okay. I was more wondering if there was a libfdt repo that was upstream and separate from u-boot (as dtc uses libfdt also). Okay, I'll rebase against wd's mainline and repost ASAP.
Cheers, g.
On 9/3/07, Grant Likely grant.likely@secretlab.ca wrote:
On 9/3/07, Jerry Van Baren vanbargw@gmail.com wrote:
Hi Grant,
The libfdt custodian repo is on the denx.de site, but should be the same as the mainline. I would say patch your 5xxx custodian repo, publishing the new functions that impact the libfdt stuff as a separate patch and The List can discuss them. I'll "ack" them and apply them to my repo as well, but NBD. I will plan on updating the 83xx implementation(s) and publish them for Kim to ack/adopt as well.
Ah, okay. I was more wondering if there was a libfdt repo that was upstream and separate from u-boot (as dtc uses libfdt also). Okay, I'll rebase against wd's mainline and repost ASAP.
Hmmm. On a third reading, I don't think the fixup functions belong in libfdt, or at least not completely. I'll add a function 'fdt_find_and_setprop()' which handles the logic, but I'll keep a couple of helpers in cpu/mpc5200/cpu.c just because they involve printf() calls for user feedback and printf() calls don't really belong in libfdt.
Cheers, g.
Cheers, g.
-- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. grant.likely@secretlab.ca (403) 399-0195
Grant Likely wrote:
On 9/3/07, Jerry Van Baren vanbargw@gmail.com wrote:
Hi Grant,
The libfdt custodian repo is on the denx.de site, but should be the same as the mainline. I would say patch your 5xxx custodian repo, publishing the new functions that impact the libfdt stuff as a separate patch and The List can discuss them. I'll "ack" them and apply them to my repo as well, but NBD. I will plan on updating the 83xx implementation(s) and publish them for Kim to ack/adopt as well.
Ah, okay. I was more wondering if there was a libfdt repo that was upstream and separate from u-boot (as dtc uses libfdt also). Okay, I'll rebase against wd's mainline and repost ASAP.
Cheers, g.
Ahh, now I see what you were asking. When I ported libfdt to u-boot, I ended up forking it because the official libfdt did not have all the functionality we needed and, at the time, David Gibson was not taking patches. He was working on setting up a dual-licensing for libfdt and did not want changes before the lawyers were happy with the licensing.
David has since slain the licensing dragon, but we have not unforked libfdt.
To unfork, we have a couple of issues to work out. One is the amount of effort to undo the divergence (probably not bad). The other is the dual-licensing issue: David added a BSD license. Most of the new code is from me, but some is from others (Wolfgang G.) and some of it was shamelessly stolen from linux's FDT support (not LIBFDT). In order to unfork, we would have to have agreement from the authors of the additional code to relicense with the dual license... or maybe Jon and David have independently written equivalent routines (quite possible).
Best regards, gvb
On Tue, 2007-09-04 at 07:39, Jerry Van Baren wrote:
Ahh, now I see what you were asking. When I ported libfdt to u-boot, I ended up forking it
...
To unfork, we have a couple of issues to work out. One is the amount of effort to undo the divergence (probably not bad). The other is the dual-licensing issue:
...
In order to unfork, we would have to have agreement from the authors of the additional code to relicense with the dual license... or maybe Jon and David have independently written equivalent routines (quite possible).
Right.
Jon has recently been busy staring into Cardiac ICUs, getting a split tooth repaired, and breaking his big toe. No actual coding is taking place, unfortunately. :-)
jdl
PS -- All I need now is someone to staring using "u" instead of "you" to set me off...
On 9/4/07, Jon Loeliger jdl@freescale.com wrote:
jdl
PS -- All I need now is someone to staring using "u" instead of "you" to set me off...
u just need to relax.
g.
participants (6)
-
Bartlomiej Sieka -
Grant Likely -
Jerry Van Baren -
Jerry Van Baren -
Jon Loeliger -
Kim Phillips