[U-Boot-Users] [PATCH 1/2] add ft_cpu_setup(..) on mpc8260

[U-Boot-Users] [PATCH 1/2] add ft_cpu_setup(..) on mpc8260

[Sergej Stepanov]

add ft_cpu_setup(..)-function to adapt it for use with libfdt
based on code from mpc5xxx

Sigend-off-by: Sergej Stepanov <Sergej.Stepanov@ids.de>
---

diff --git a/cpu/mpc8260/cpu.c b/cpu/mpc8260/cpu.c
index 94651dc..8e78d89 100644
--- a/cpu/mpc8260/cpu.c
+++ b/cpu/mpc8260/cpu.c
@@ -38,6 +38,9 @@
  *
  * added HiP7 (824x/827x/8280) processors support by
  * Yuli Barcohen <yuli@arabellasw.com>
+ * 
+ * add ft_cpu_setup(..) for use with CONFIG_OF_LIBFDT
+ * Sergej Stepanov <Sergej.Stepanov@ids.de> 
  */
 
 #include <common.h>
@@ -47,6 +50,11 @@
 #include <asm/processor.h>
 #include <asm/cpm_8260.h>
 
+#if defined(CONFIG_OF_LIBFDT)
+#include <libfdt.h>
+#include <libfdt_env.h>
+#endif
+
 DECLARE_GLOBAL_DATA_PTR;
 
 #if defined(CONFIG_GET_CPU_STR_F)
@@ -294,3 +302,36 @@ void watchdog_reset (void)
 #endif /* CONFIG_WATCHDOG */
 
 /* ------------------------------------------------------------------------- */
+#if defined(CONFIG_OF_LIBFDT)
+static void do_fixup(void *fdt, const char *node, const char *prop,
+		     const void *val, int len, int create)
+{
+#if defined(DEBUG)
+	int i;
+	debug("Updating property '%s/%s' = ", node, prop);
+	for (i = 0; i < len; i++)
+		debug(" %.2x", *(u8*)(val+i));
+	debug("\n");
+#endif
+	int rc = fdt_find_and_setprop(fdt, node, prop, val, len, create);
+	if (rc)
+		printf("Unable to update property %s:%s, err=%s\n",
+		       node, prop, fdt_strerror(rc));
+}
+
+static void do_fixup_u32(void *fdt, const char *node, const char *prop,
+			 u32 val, int create)
+{
+	val = cpu_to_fdt32(val);
+	do_fixup(fdt, node, prop, &val, sizeof(val), create);
+}
+
+void ft_cpu_setup (void *blob, bd_t *bd)
+{
+	char * cpu_path = "/cpus/" OF_CPU;
+
+	do_fixup_u32(blob, cpu_path, "bus-frequency", bd->bi_busfreq, 1);
+	do_fixup_u32(blob, cpu_path, "timebase-frequency", OF_TBCLK, 1);
+	do_fixup_u32(blob, cpu_path, "clock-frequency", bd->bi_intfreq, 1);
+}
+#endif /* CONFIG_OF_LIBFDT */

[U-Boot-Users] [PATCH 1/2] add ft_cpu_setup(..) on mpc8260

[Wolfgang Denk]

In message <1192605168.3174.17.camel@p60635-ste.ids.de> you wrote:
> add ft_cpu_setup(..)-function to adapt it for use with libfdt
> based on code from mpc5xxx
> 
> Sigend-off-by: Sergej Stepanov <Sergej.Stepanov@ids.de>
> ---
> 
> diff --git a/cpu/mpc8260/cpu.c b/cpu/mpc8260/cpu.c
> index 94651dc..8e78d89 100644
> --- a/cpu/mpc8260/cpu.c
> +++ b/cpu/mpc8260/cpu.c
> @@ -38,6 +38,9 @@
>   *
>   * added HiP7 (824x/827x/8280) processors support by
>   * Yuli Barcohen <yuli@arabellasw.com>
> + * 
> + * add ft_cpu_setup(..) for use with CONFIG_OF_LIBFDT
> + * Sergej Stepanov <Sergej.Stepanov@ids.de> 
>   */

Please omit such change log comments. We have the git history for
that.


[Please fix and resubmit.]

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Probably the best operating system in the world  is  the  [operating
system] made for the PDP-11 by Bell Laboratories."
                                           - Ted Nelson, October 1977

[U-Boot-Users] FDT intentions in u-boot

[Zach Sadecki]

I have some confusion about FDT and what the intentions are for its
support and usage in u-boot.

From what I understand so far, u-boot only supports modifying a FDT
already loaded into memory.  Isn't this kind of an odd usage of a device
tree?  I thought a unique tree should be created for each hardware
implementation (a.k.a. system board) and therefore you shouldn't be
modifying it.  If changes are made a new device tree should be created.

What is the intent for future support?  Creation of a device tree from
scratch?  That seems to be what the original (open firmware) intention
of FDTs were. (Allowing a bootloader to pass a implementation specific
hardware list up to an operating system.)  And the current Linux
implementation is a little backwards from that (let kernel compiler give
you a device tree which you then have to give to the bootloader to pass
back up to the kernel during boot).  It would seem to make more sense
(in my limited understanding of FDT) to allow the bootloader to be able
to generate this itself without dependence on a prior kernel compilation
for that particular hardware...

If the plans aren't for u-boot to have the ability to generate a device
tree would it be reasonable to create one and embed it in the u-boot
binary somehow? (so that another unique binary wouldn't have to be
loaded into another separate flash partition)

Thanks,
  Zach

[U-Boot-Users] FDT intentions in u-boot

[Jerry Van Baren]

Zach Sadecki wrote:
> I have some confusion about FDT and what the intentions are for its
> support and usage in u-boot.
> 
> From what I understand so far, u-boot only supports modifying a FDT
> already loaded into memory.  Isn't this kind of an odd usage of a device
> tree?  I thought a unique tree should be created for each hardware
> implementation (a.k.a. system board) and therefore you shouldn't be
> modifying it.  If changes are made a new device tree should be created.

You can only _modify_ a blob when it is in RAM.  You can store a blob in 
ROM (flash) and copy it to RAM for modification.

If you don't need to modify the blob in order to boot linux, there is no 
need (that I'm aware of) for loading/copying it to RAM.  *However* it is 
unlikely that you (u-boot/linux) will be able to use an unmodified blob. 
  For instance, the "chosen" node is (or should be?) generated by the 
boot loader (u-boot) to let the kernel know about certain choices that 
were made by the boot loader and/or the user.

The intent is to set properties (values) that can change from boot to 
boot or from board to board.  The classic example are clocks.  Boards, 
when they boot, can typically figure out and often can set clock rates. 
  Having a thousand FDTs with all the combinations of possible clocks is 
a maintenance nightmare.  Having u-boot set the clocks or probe for the 
clock rates is great.

> What is the intent for future support?  Creation of a device tree from
> scratch?  That seems to be what the original (open firmware) intention
> of FDTs were. (Allowing a bootloader to pass a implementation specific
> hardware list up to an operating system.)  And the current Linux
> implementation is a little backwards from that (let kernel compiler give
> you a device tree which you then have to give to the bootloader to pass
> back up to the kernel during boot).  It would seem to make more sense
> (in my limited understanding of FDT) to allow the bootloader to be able
> to generate this itself without dependence on a prior kernel compilation
> for that particular hardware...

There is no intention to create blobs from scratch in the boot loader 
(u-boot).  If you look at some of the SOC (8[3456]xx) blobs, you would 
see that that would be a nightmare, your fingers would be bloody stubs 
by the time you typed it all in, and then you would find you had a 
syntax error and have to start all over.
   <http://pez.multiply.com/journal/item/75/Computer_Frustration>
(I think that is the link, the filters at work don't let me browse it.)

On the other hand, 98% of the typical FDT blob (to make up a statistic) 
is static.  The intent of u-boot FDT support is to externally (via the 
dtc) generate a blob with the 98% already filled in and have u-boot 
configure the 2% that is board-specific or user selected.

The blob can be baked into u-boot, stored in flash separately from 
u-boot, or loaded as part of the kernel (baked into the kernel image in 
ROM, tftped separately from the kernel, tftped as part of the kernel image).

We are in the tool business, how to use the tool is up to the user.  ;-)

> If the plans aren't for u-boot to have the ability to generate a device
> tree would it be reasonable to create one and embed it in the u-boot
> binary somehow? (so that another unique binary wouldn't have to be
> loaded into another separate flash partition)
> 
> Thanks,
>   Zach

That option is already there as a multi-image boot image, one part of 
the image being a FDT blob.

Best regards,
gvb

[U-Boot-Users] FDT intentions in u-boot

[Joakim Tjernlund]

On Wed, 2007-10-17 at 11:02 -0400, Jerry Van Baren wrote:
> Zach Sadecki wrote:
> > I have some confusion about FDT and what the intentions are for its
> > support and usage in u-boot.
> > 
> > From what I understand so far, u-boot only supports modifying a FDT
> > already loaded into memory.  Isn't this kind of an odd usage of a device
> > tree?  I thought a unique tree should be created for each hardware
> > implementation (a.k.a. system board) and therefore you shouldn't be
> > modifying it.  If changes are made a new device tree should be created.
> 
> You can only _modify_ a blob when it is in RAM.  You can store a blob in 
> ROM (flash) and copy it to RAM for modification.
> 
> If you don't need to modify the blob in order to boot linux, there is no 
> need (that I'm aware of) for loading/copying it to RAM.  *However* it is 
> unlikely that you (u-boot/linux) will be able to use an unmodified blob. 
>   For instance, the "chosen" node is (or should be?) generated by the 
> boot loader (u-boot) to let the kernel know about certain choices that 
> were made by the boot loader and/or the user.

OT, but I have always wondered how the chosen node is supposed to be
used. Would it be possible to specify which devices in the device tree
that should be used by the OS?
Supposed I got two boards that are identical, except one of them
does not have ethernet i/f. Would it be possible use the same device
tree for both boards, but tell OS that the ethernet i/f isn't present
on one of the boards?

I getting a bunch of boards thats are very similiar from the OS point of
view and I would like to just have one mega devtree and remove some
devices at runtime or change som properties.

 Jocke

[U-Boot-Users] FDT intentions in u-boot

[Jerry Van Baren]

Joakim Tjernlund wrote:
> On Wed, 2007-10-17 at 11:02 -0400, Jerry Van Baren wrote:
>> Zach Sadecki wrote:
>>> I have some confusion about FDT and what the intentions are for its
>>> support and usage in u-boot.
>>>
>>> From what I understand so far, u-boot only supports modifying a FDT
>>> already loaded into memory.  Isn't this kind of an odd usage of a device
>>> tree?  I thought a unique tree should be created for each hardware
>>> implementation (a.k.a. system board) and therefore you shouldn't be
>>> modifying it.  If changes are made a new device tree should be created.
>> You can only _modify_ a blob when it is in RAM.  You can store a blob in 
>> ROM (flash) and copy it to RAM for modification.
>>
>> If you don't need to modify the blob in order to boot linux, there is no 
>> need (that I'm aware of) for loading/copying it to RAM.  *However* it is 
>> unlikely that you (u-boot/linux) will be able to use an unmodified blob. 
>>   For instance, the "chosen" node is (or should be?) generated by the 
>> boot loader (u-boot) to let the kernel know about certain choices that 
>> were made by the boot loader and/or the user.
> 
> OT, but I have always wondered how the chosen node is supposed to be
> used. 

I'm not an expert, I only play on on mail lists.  My understanding is 
that the chosen node indicates to the OS what choices the user (or boot 
loader) made between possible configurations...

> Would it be possible to specify which devices in the device tree
> that should be used by the OS?

...so the answer should be "yes" but that is making the assumption that 
the OS knows enough to look in the chosen node to figure out which 
devices it should use.  *That* part is probably a bad assumption (at the 
moment).

> Supposed I got two boards that are identical, except one of them
> does not have ethernet i/f. Would it be possible use the same device
> tree for both boards, but tell OS that the ethernet i/f isn't present
> on one of the boards?

I believe the theoretical answer is "yes" but the practical answer is 
"no" for doing this via the "chosen" node.

It is simpler and safer to use libfdt to simply delete the unpopulated 
node from the tree.

> I getting a bunch of boards thats are very similiar from the OS point of
> view and I would like to just have one mega devtree and remove some
> devices at runtime or change som properties.
> 
>  Jocke

Hopefully your boards have some method of self-determining what is 
populated or not.  Alternatively, you can use the ability to load 
board-specific FDT blobs to accomplish this.

Wolfgang Grandegger and Delev Zundel actually created a "universal" 
u-boot that was configured *itself* via a FDT blob (OK, it wasn't 
universal, but it sounds so good).  If your board isn't self-aware of 
its configuration, that would be an interesting path to go down.

gvb

[U-Boot-Users] FDT intentions in u-boot

[Zach Sadecki]

Jerry Van Baren wrote:
> Zach Sadecki wrote:
>> I have some confusion about FDT and what the intentions are for its
>> support and usage in u-boot.
>>
>> From what I understand so far, u-boot only supports modifying a FDT
>> already loaded into memory.  Isn't this kind of an odd usage of a device
>> tree?  I thought a unique tree should be created for each hardware
>> implementation (a.k.a. system board) and therefore you shouldn't be
>> modifying it.  If changes are made a new device tree should be created.
> 
> You can only _modify_ a blob when it is in RAM.  You can store a blob in 
> ROM (flash) and copy it to RAM for modification.
> 
> If you don't need to modify the blob in order to boot linux, there is no 
> need (that I'm aware of) for loading/copying it to RAM.  *However* it is 
> unlikely that you (u-boot/linux) will be able to use an unmodified blob. 
>  For instance, the "chosen" node is (or should be?) generated by the 
> boot loader (u-boot) to let the kernel know about certain choices that 
> were made by the boot loader and/or the user.
> 
> The intent is to set properties (values) that can change from boot to 
> boot or from board to board.  The classic example are clocks.  Boards, 
> when they boot, can typically figure out and often can set clock rates. 
>  Having a thousand FDTs with all the combinations of possible clocks is 
> a maintenance nightmare.  Having u-boot set the clocks or probe for the 
> clock rates is great.
OK, I see your point here.  That makes sense...

> 
>> What is the intent for future support?  Creation of a device tree from
>> scratch?  That seems to be what the original (open firmware) intention
>> of FDTs were. (Allowing a bootloader to pass a implementation specific
>> hardware list up to an operating system.)  And the current Linux
>> implementation is a little backwards from that (let kernel compiler give
>> you a device tree which you then have to give to the bootloader to pass
>> back up to the kernel during boot).  It would seem to make more sense
>> (in my limited understanding of FDT) to allow the bootloader to be able
>> to generate this itself without dependence on a prior kernel compilation
>> for that particular hardware...
> 
> There is no intention to create blobs from scratch in the boot loader 
> (u-boot).  If you look at some of the SOC (8[3456]xx) blobs, you would 
> see that that would be a nightmare, your fingers would be bloody stubs 
> by the time you typed it all in, and then you would find you had a 
> syntax error and have to start all over.
>   <http://pez.multiply.com/journal/item/75/Computer_Frustration>
> (I think that is the link, the filters at work don't let me browse it.)
What I meant was not typing it in by hand, but setting it up in your 
board.h file so that it can be generated during compile or during boot. 
  But if you can embed it into the u-boot image itself, maybe this is 
unnecessary.  It seems as I look deeper into the code it does support 
this to some extent (ft_build.c), but I think that it might not be as 
thorough as it would need to be to work.
> 
> On the other hand, 98% of the typical FDT blob (to make up a statistic) 
> is static.  The intent of u-boot FDT support is to externally (via the 
> dtc) generate a blob with the 98% already filled in and have u-boot 
> configure the 2% that is board-specific or user selected.
> 
> The blob can be baked into u-boot, stored in flash separately from 
> u-boot, or loaded as part of the kernel (baked into the kernel image in 
> ROM, tftped separately from the kernel, tftped as part of the kernel 
> image).
> 
> We are in the tool business, how to use the tool is up to the user.  ;-)
> 
>> If the plans aren't for u-boot to have the ability to generate a device
>> tree would it be reasonable to create one and embed it in the u-boot
>> binary somehow? (so that another unique binary wouldn't have to be
>> loaded into another separate flash partition)
>>
>> Thanks,
>>   Zach
> 
> That option is already there as a multi-image boot image, one part of 
> the image being a FDT blob.
I've seen a little info on using mkimage to add an initrd, but nothing 
specifically with fdt (or dtb).  I've seen no info on 'baking it into 
u-boot' that you mentioned above...  Is there any documentation on how 
to do either of these?

Thanks,
  Zach

[U-Boot-Users] FDT intentions in u-boot

[Jerry Van Baren]

Zach Sadecki wrote:
> Jerry Van Baren wrote:
>> Zach Sadecki wrote:
>>> I have some confusion about FDT and what the intentions are for its
>>> support and usage in u-boot.

[snip]

>>> What is the intent for future support?  Creation of a device tree from
>>> scratch?  That seems to be what the original (open firmware) intention
>>> of FDTs were. (Allowing a bootloader to pass a implementation specific
>>> hardware list up to an operating system.)  And the current Linux
>>> implementation is a little backwards from that (let kernel compiler give
>>> you a device tree which you then have to give to the bootloader to pass
>>> back up to the kernel during boot).  It would seem to make more sense
>>> (in my limited understanding of FDT) to allow the bootloader to be able
>>> to generate this itself without dependence on a prior kernel compilation
>>> for that particular hardware...
>>
>> There is no intention to create blobs from scratch in the boot loader 
>> (u-boot).  If you look at some of the SOC (8[3456]xx) blobs, you would 
>> see that that would be a nightmare, your fingers would be bloody stubs 
>> by the time you typed it all in, and then you would find you had a 
>> syntax error and have to start all over.
>>   <http://pez.multiply.com/journal/item/75/Computer_Frustration>
>> (I think that is the link, the filters at work don't let me browse it.)
> What I meant was not typing it in by hand, but setting it up in your 
> board.h file so that it can be generated during compile or during boot. 
>  But if you can embed it into the u-boot image itself, maybe this is 
> unnecessary.  It seems as I look deeper into the code it does support 
> this to some extent (ft_build.c), but I think that it might not be as 
> thorough as it would need to be to work.

Hmmm /me thinks you are confusing libfdt and The Other Way of supporting 
FDT blobs with the reference to ft_build.c.  While it is theoretically 
true that you could generate the blob from nothing, modifying and 
augmenting a static initial blob makes more sense.

I would not advocate embedding the FDT blob in u-boot but, if I were to 
do so, I would use the dtc to generate an assembly language output 
(actually, a lot of define byte statements) and then compile that in the 
u-boot build.

A better approach IMHO (subject to change) is to burn the FDT blob into 
a separate flash area so it can be updated later without rebuilding 
u-boot or downloading it via TFTP.  Obviously, this would be an 
engineering tradeoff and /your/ best choice for your situation is quite 
likely different from someone else's choice for their (different) situation.

>> On the other hand, 98% of the typical FDT blob (to make up a 
>> statistic) is static.  The intent of u-boot FDT support is to 
>> externally (via the dtc) generate a blob with the 98% already filled 
>> in and have u-boot configure the 2% that is board-specific or user 
>> selected.
>>
>> The blob can be baked into u-boot, stored in flash separately from 
>> u-boot, or loaded as part of the kernel (baked into the kernel image 
>> in ROM, tftped separately from the kernel, tftped as part of the 
>> kernel image).
>>
>> We are in the tool business, how to use the tool is up to the user.  ;-)
>>
>>> If the plans aren't for u-boot to have the ability to generate a device
>>> tree would it be reasonable to create one and embed it in the u-boot
>>> binary somehow? (so that another unique binary wouldn't have to be
>>> loaded into another separate flash partition)
>>>
>>> Thanks,
>>>   Zach
>>
>> That option is already there as a multi-image boot image, one part of 
>> the image being a FDT blob.
> I've seen a little info on using mkimage to add an initrd, but nothing 
> specifically with fdt (or dtb).  I've seen no info on 'baking it into 
> u-boot' that you mentioned above...  Is there any documentation on how 
> to do either of these?
> 
> Thanks,
>  Zach

I haven't tried to make a multi-image linux/FDT blob/RAM disk an may 
have misspoke about it being an option.  What I was recalling is 
something Timur did which was using mkimage to wrap a standalone blob.
<http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/28207/focus=28242>

Baking in - explained above, use dtc to generate assembly and link it in 
with u-boot.  It may make sense in places, but I would think hard about 
if it made sense before doing it.

gvb

[U-Boot-Users] FDT intentions in u-boot

[Haavard Skinnemoen]

On Thu, 18 Oct 2007 15:29:28 -0400
Jerry Van Baren <gerald.vanbaren@ge.com> wrote:

> I would not advocate embedding the FDT blob in u-boot but, if I were
> to do so, I would use the dtc to generate an assembly language output 
> (actually, a lot of define byte statements) and then compile that in
> the u-boot build.

Why not just generate a binary file (possibly compressed) and suck it
into an assembly file using .incbin?

> A better approach IMHO (subject to change) is to burn the FDT blob
> into a separate flash area so it can be updated later without
> rebuilding u-boot or downloading it via TFTP.  Obviously, this would
> be an engineering tradeoff and /your/ best choice for your situation
> is quite likely different from someone else's choice for their
> (different) situation.

Yes, having a mutable device tree probably makes more sense for a
development board. But embedding it in the u-boot binary could save
some space in the "production" image. Is it possible to support both?

I don't know all that much about FDT, so I could be way off. I would
like to try it out with avr32 at some point though, after all the
basics are in place.

H?vard

[U-Boot-Users] FDT intentions in u-boot

[Jerry Van Baren]

Haavard Skinnemoen wrote:
> On Thu, 18 Oct 2007 15:29:28 -0400
> Jerry Van Baren <gerald.vanbaren@ge.com> wrote:
> 
>> I would not advocate embedding the FDT blob in u-boot but, if I were
>> to do so, I would use the dtc to generate an assembly language output 
>> (actually, a lot of define byte statements) and then compile that in
>> the u-boot build.
> 
> Why not just generate a binary file (possibly compressed) and suck it
> into an assembly file using .incbin?

Yet Another Way to do the same thing.  Dtc produces a binary blob or 
human readable assembly, might as well output assembly and skip the 
.incbin, but to each their own.

Compressing probably isn't profitable, a blob is a few K uncompressed. 
On the other hand, u-boot knows how to uncompress, so anything is 
possible...

>> A better approach IMHO (subject to change) is to burn the FDT blob
>> into a separate flash area so it can be updated later without
>> rebuilding u-boot or downloading it via TFTP.  Obviously, this would
>> be an engineering tradeoff and /your/ best choice for your situation
>> is quite likely different from someone else's choice for their
>> (different) situation.
> 
> Yes, having a mutable device tree probably makes more sense for a
> development board. But embedding it in the u-boot binary could save
> some space in the "production" image. Is it possible to support both?

Yes.  Ultimately u-boot (mboot/linux) takes the address of the blob. 
You can store it anywhere you want, as long as it has an address.  If it 
doesn't have an address (e.g. i2c eeprom, NAND flash), you simply need 
to copy it somewhere addressable (RAM) first.  U-boot knows how to cp 
too.  :-)

> I don't know all that much about FDT, so I could be way off. I would
> like to try it out with avr32 at some point though, after all the
> basics are in place.
> 
> H?vard

You have the concepts OK.  FDT is pretty cool stuff, much better than 
shared "bd" structures.

gvb

[U-Boot-Users] [PATCH 1/2] add ft_cpu_setup(..) on mpc8260

[Scott Wood]

On Wed, Oct 17, 2007 at 09:12:48AM +0200, Sergej Stepanov wrote:
> +void ft_cpu_setup (void *blob, bd_t *bd)
> +{
> +	char * cpu_path = "/cpus/" OF_CPU;
> +
> +	do_fixup_u32(blob, cpu_path, "bus-frequency", bd->bi_busfreq, 1);
> +	do_fixup_u32(blob, cpu_path, "timebase-frequency", OF_TBCLK, 1);
> +	do_fixup_u32(blob, cpu_path, "clock-frequency", bd->bi_intfreq, 1);
> +}

You should also fix up /soc/cpm/brg/clock-frequency.

-Scott

[U-Boot-Users] [PATCH 1/2] add ft_cpu_setup(..) on mpc8260

[Sergej Stepanov]

Am Dienstag, den 23.10.2007, 14:34 -0500 schrieb Scott Wood:
> On Wed, Oct 17, 2007 at 09:12:48AM +0200, Sergej Stepanov wrote:
> > +void ft_cpu_setup (void *blob, bd_t *bd)
> > +{
> > +	char * cpu_path = "/cpus/" OF_CPU;
> > +
> > +	do_fixup_u32(blob, cpu_path, "bus-frequency", bd->bi_busfreq, 1);
> > +	do_fixup_u32(blob, cpu_path, "timebase-frequency", OF_TBCLK, 1);
> > +	do_fixup_u32(blob, cpu_path, "clock-frequency", bd->bi_intfreq, 1);
> > +}
> 
> You should also fix up /soc/cpm/brg/clock-frequency.
> 
I will do it.
But before i have the question: could somebody tell me, are there more other things to fix up?

Thanks.
Sergej.