(Try 2) Please pull branch fdt-cmd from u-boot-fdt.git

Please pull from the "fdt-cmd" branch at
git://cideas.us/pub/scm/u-boot/u-boot-fdt.git fdt-cmd
currently broken, someday fixed:

git://denx.de/git/u-boot-fdt.git fdt-cmd

Dear Wolfgang,

Please pull from the "fdt-cmd" branch at
git://cideas.us/pub/scm/u-boot/u-boot-fdt.git fdt-cmd
currently broken, someday fixed:
git://denx.de/git/u-boot-fdt.git fdt-cmd

Quoted 3 lines · In message <[email protected]> you wrote:

Please pull from the "fdt-cmd" branch at
git://cideas.us/pub/scm/u-boot/u-boot-fdt.git fdt-cmd
currently broken, someday fixed:

Not broken, just using a separate branch...

Quoted 1 line

git://denx.de/git/u-boot-fdt.git fdt-cmd

Best regards,
Wolfgang Denk

Dear Wolfgang,

Please pull from the "fdt-cmd" branch at
git://cideas.us/pub/scm/u-boot/u-boot-fdt.git fdt-cmd
currently broken, someday fixed:
git://denx.de/git/u-boot-fdt.git fdt-cmd

I've resplit the patches and emailed them to the u-boot list.

This change is only the starting point. :-) I've only done the mpc8360/mpc8360emds board. Some fairly small changes need to be done to the other mpc8xxx family CPU and board subdirectories to allow them to use the libfdt/fdt command. To see what needs adapting, see:

  cpu/mpc83xx/cpu.c               |  102 +++++-
  board/mpc8360emds/pci.c         |   20 +

Note that I've created a new CONFIG_OF_LIBFDT that is intended to ultimately supplant CONFIG_OF_FLAT_TREE. Use one or the other: new way CONFIG_OF_LIBFDT or old way CONFIG_OF_FLAT_TREE. Obviously, the only way to get the new fdt command is to use CONFIG_OF_LIBFDT.

Quoted 13 lines · Jerry Van Baren

Dear Wolfgang,

Please pull from the "fdt-cmd" branch at
git://cideas.us/pub/scm/u-boot/u-boot-fdt.git fdt-cmd
currently broken, someday fixed:
git://denx.de/git/u-boot-fdt.git fdt-cmd

I've resplit the patches and emailed them to the u-boot list.

This change is only the starting point. :-) I've only done the mpc8360/mpc8360emds board. Some fairly small changes need to be done to the other mpc8xxx family CPU and board subdirectories to allow them to use the libfdt/fdt command. To see what needs adapting, see:

Quoted 7 lines

  cpu/mpc83xx/cpu.c               |  102 +++++-
  board/mpc8360emds/pci.c         |   20 +

Note that I've created a new CONFIG_OF_LIBFDT that is intended to ultimately supplant CONFIG_OF_FLAT_TREE. Use one or the other: new way CONFIG_OF_LIBFDT or old way CONFIG_OF_FLAT_TREE. Obviously, the only way to get the new fdt command is to use CONFIG_OF_LIBFDT.

This is probably a little off but I am thinking about were to put my dtb on the flash and it occured to me that it could fit into the environment sector as the environment doesn't use the whole sector. But one can't just write it into that sector without take measures to preserve the environment.
Is this a bad idea?

Jocke

Quoted 29 lines · Joakim Tjernlund

Quoted 13 lines · Jerry Van Baren

Dear Wolfgang,

Please pull from the "fdt-cmd" branch at
git://cideas.us/pub/scm/u-boot/u-boot-fdt.git fdt-cmd
currently broken, someday fixed:
git://denx.de/git/u-boot-fdt.git fdt-cmd

I've resplit the patches and emailed them to the u-boot list.

This change is only the starting point. :-) I've only done the mpc8360/mpc8360emds board. Some fairly small changes need to be done to the other mpc8xxx family CPU and board subdirectories to allow them to use the libfdt/fdt command. To see what needs adapting, see:

Quoted 7 lines

  cpu/mpc83xx/cpu.c               |  102 +++++-
  board/mpc8360emds/pci.c         |   20 +

Note that I've created a new CONFIG_OF_LIBFDT that is intended to ultimately supplant CONFIG_OF_FLAT_TREE. Use one or the other: new way CONFIG_OF_LIBFDT or old way CONFIG_OF_FLAT_TREE. Obviously, the only way to get the new fdt command is to use CONFIG_OF_LIBFDT.

This is probably a little off but I am thinking about were to put my dtb on the flash and it occured to me that it could fit into the environment sector as the environment doesn't use the whole sector. But one can't just write it into that sector without take measures to preserve the environment.
Is this a bad idea?

Quoted 1 line

Jocke

That is an excellent idea and should be one of our goals: to better coordinate the dft and env variables. As the penultimate goal, I believe we could move the env variables _into_ the dft and replace the get/set env routines with dft get/set routines. I'm still thinking about this... env variables are used very early in power up (before RAM is initialized), but I haven't seen any reason that it /can't/ be done.

The downside of dfts is that the code is bigger. My preliminary size delta with the code as it stands is about +4.5K. I don't know how much we would save if we removed the env handling routines, but I'm sure nowhere near that (0.5K would be my guess). For size sensitive u-boot images, we could use it read-only which would probably cut it down to 1-2K, but then we would not be able to replace the env handling.

gvb

Quoted 29 lines · Jerry Van Baren

Quoted 28 lines · Joakim Tjernlund

Quoted 13 lines · Jerry Van Baren

Dear Wolfgang,

Please pull from the "fdt-cmd" branch at
git://cideas.us/pub/scm/u-boot/u-boot-fdt.git fdt-cmd
currently broken, someday fixed:
git://denx.de/git/u-boot-fdt.git fdt-cmd

I've resplit the patches and emailed them to the u-boot list.

This change is only the starting point. :-) I've only done the mpc8360/mpc8360emds board. Some fairly small changes need to be done to the other mpc8xxx family CPU and board subdirectories to allow them to use the libfdt/fdt command. To see what needs adapting, see:

Quoted 7 lines

  cpu/mpc83xx/cpu.c               |  102 +++++-
  board/mpc8360emds/pci.c         |   20 +

Note that I've created a new CONFIG_OF_LIBFDT that is intended to ultimately supplant CONFIG_OF_FLAT_TREE. Use one or the other: new way CONFIG_OF_LIBFDT or old way CONFIG_OF_FLAT_TREE. Obviously, the only way to get the new fdt command is to use CONFIG_OF_LIBFDT.

This is probably a little off but I am thinking about were to put my dtb on the flash and it occured to me that it could fit into the environment sector as the environment doesn't use the whole sector. But one can't just write it into that sector without take measures to preserve the environment.
Is this a bad idea?

Quoted 7 lines

Quoted 1 line

Jocke

That is an excellent idea and should be one of our goals: to better coordinate the dft and env variables. As the penultimate goal, I believe we could move the env variables _into_ the dft and replace the get/set env routines with dft get/set routines. I'm still thinking about this... env variables are used very early in power up (before RAM is initialized), but I haven't seen any reason that it /can't/ be done.

Good, I am not totally off then :)
I think to start with one would just need an install dtb command that places the dtb at the end of the env. sector to allow either one to grow without trashing eachother. Also rendundant env needs to be handled by this new command.
Secondly one needs someway of telling bootm where to find the dtb.

I have just started a board port here and there will be some time before I get to to the dtb part.

Jocke

This is probably a little off but I am thinking about were to put my dtb on the flash and it occured to me that it could fit into the environment sector as the environment doesn't use the whole sector.

But one can't just write it into that sector without take measures to preserve the environment.

Is this a bad idea?

That is an excellent idea and should be one of our goals: to better coordinate the dft and env variables. As the penultimate goal, I believe we could move the env variables _into_ the dft and replace the get/set env routines with dft get/set routines. I'm still thinking about this... env variables are used very early in power up (before RAM is initialized), but I haven't seen any reason that it /can't/ be done.

The downside of dfts is that the code is bigger. My preliminary size

I think to start with one would just need an install dtb command that places the dtb at the end of the env. sector to allow either one to grow without trashing eachother. Also rendundant env needs to be

Secondly one needs someway of telling bootm where to find the dtb.

Hi,

Quoted 4 lines · in message <[email protected]> you wrote:

This is probably a little off but I am thinking about were to put my dtb on the flash and it occured to me that it could fit into the environment sector as the environment doesn't use the whole sector.

It is you who defines the usage of yoru flash.

Quoted 3 lines

But one can't just write it into that sector without take measures to preserve the environment.

What measures? No matter where you store it in flash you must make
sure it's an otherwise unused area. The unused part of the
environment sector is not much different.

Quoted 2 lines

Is this a bad idea?

I think it is not a good idea. When something goes wrong during a "saveenv" you lose your dtb. THe environment is still secured if you use redundant environment, but your dtb is gone.

I would use a dedicated flash sector, but that's just my $ 0.02

Best regards,

Wolfgang Denk

Quoted 4 lines · In message <[email protected]> you wrote:

I think to start with one would just need an install dtb command that places the dtb at the end of the env. sector to allow either one to grow without trashing eachother. Also rendundant env needs to be

Umm... The environment will not grow beyond it's defined size. Then just use "cp" to copy the dtb to the next free address.

Quoted 2 lines

Secondly one needs someway of telling bootm where to find the dtb.

You pass the address as an argument...

Quoted 6 lines · Wolfgang Denk

Quoted 3 lines · In message <[email protected]> you wrote:

I think to start with one would just need an install dtb command that places the dtb at the end of the env. sector to allow either one to grow without trashing eachother. Also rendundant env needs to be

Umm... The environment will not grow beyond it's defined size. Then just use "cp" to copy the dtb to the next free address.

And later you need some more space for env. so you increase CFG_ENV_SIZE a little and now you have destroyed your dtb as well.

Quoted 2 lines

Quoted 1 line

Secondly one needs someway of telling bootm where to find the dtb.

You pass the address as an argument...

yes, but it would be handy to just say "use the dtb in my spare env space", especially if you use rendundant env. so the right one is selected.

Regards
Jocke

Actually, it is much worse than that: currently when you do a "saveenv"
it will wipe out the fdt blob because it doesn't know that the blob is in the same sector.

Quoted 8 lines · Joakim Tjernlund

Quoted 6 lines · Wolfgang Denk

Quoted 3 lines · In message <[email protected]> you wrote:

I think to start with one would just need an install dtb command that places the dtb at the end of the env. sector to allow either one to grow without trashing eachother. Also rendundant env needs to be

Umm... The environment will not grow beyond it's defined size. Then just use "cp" to copy the dtb to the next free address.

Quoted 2 lines

And later you need some more space for env. so you increase CFG_ENV_SIZE a little and now you have destroyed your dtb as well.

Actually, it is much worse than that: currently when you do a "saveenv" it will wipe out the fdt blob because it doesn't know that the blob is in the same sector.

I'm thinking that we want to store the blob immediately after the env variable storage _reserved area_ as a #define option (as a new #define option? part of the CONFIG_OF_LIBFDT define?) and enhance the env save/restore to do the blob too. This would get us the redundancy and we can cover it with a new (preferred?) or existing env CRC (not good?).

Quoted 10 lines

Quoted 3 lines

Quoted 2 lines

Secondly one needs someway of telling bootm where to find the dtb.

You pass the address as an argument...

yes, but it would be handy to just say "use the dtb in my spare env space", especially if you use rendundant env. so the right one is selected.

Regards
Jocke

Best regards,
gvb

Quoted 10 lines · Jerry Van Baren

Quoted 9 lines · Joakim Tjernlund

Quoted 6 lines · Wolfgang Denk

Quoted 3 lines · In message <[email protected]> you wrote:

I think to start with one would just need an install dtb command that places the dtb at the end of the env. sector to allow either one to grow without trashing eachother. Also rendundant env needs to be

Umm... The environment will not grow beyond it's defined size. Then just use "cp" to copy the dtb to the next free address.

And later you need some more space for env. so you increase CFG_ENV_SIZE a little and now you have destroyed your dtb as well.

Quoted 3 lines

Actually, it is much worse than that: currently when you do a "saveenv" it will wipe out the fdt blob because it doesn't know that the blob is in the same sector.

Oh, my memory from the good old days(ppcboot) was that saveenv copied the whole sector to RAM, modified env. parts and wrote the whole block back. Probably I remember incorrectly.

You need some help from u-boot to make this practical to use:
Add an command like dtbinstall that given an address saves the dtb into the free area avaliable in the env. sector (and into the redundant env sector if enabled)

Actually, it is much worse than that: currently when you do a "saveenv" it will wipe out the fdt blob because it doesn't know that the blob is in the same sector.

I'm thinking that we want to store the blob immediately after the env variable storage _reserved area_ as a #define option (as a new #define option? part of the CONFIG_OF_LIBFDT define?) and enhance the env

save/restore to do the blob too. This would get us the redundancy and we can cover it with a new (preferred?) or existing env CRC (not good?).

Quoted 3 lines

yes, but it would be handy to just say "use the dtb in my spare env space", especially if you use rendundant env. so the right one is selected.

-----Original Message-----
From: wd at denx.de [mailto:wd at denx.de]
Sent: den 3 april 2007 17:25
To: Jerry Van Baren
Cc: joakim.tjernlund at transmode.se; u-boot-users at lists.sourceforge.net
Subject: Re: [U-Boot-Users] dtb in env sector - was: (Try 2) Please pull ...

Quoted 2 lines · In message <[email protected]> you wrote:

Actually, it is much worse than that: currently when you do

a "saveenv"

Quoted 1 line

it will wipe out the fdt blob because it doesn't know that

the blob is

Quoted 1 line

in the same sector.

No, it doesn't; see "common/env_flash.c":

#if defined(CFG_ENV_SECT_SIZE) && (CFG_ENV_SECT_SIZE > CFG_ENV_SIZE)
	...
	/* copy old contents to temporary buffer */
	...
	/* copy current environment to temporary buffer */
	...
	flash_sect_protect(OFF,...);
	...
	flash_sect_erase();
	...
	flash_write();
	...

Quoted 1 line

I'm thinking that we want to store the blob immediately

after the env

Quoted 1 line

variable storage _reserved area_ as a #define option (as a

new #define

Quoted 1 line

option? part of the CONFIG_OF_LIBFDT define?) and enhance the env

You mean at CFG_ENV_ADDR+CFG_ENV_SIZE ?

Quoted 1 line

save/restore to do the blob too. This would get us the

redundancy and

Quoted 1 line

we can cover it with a new (preferred?) or existing env CRC

(not good?).

Not good.

Quoted 3 lines

Quoted 3 lines

yes, but it would be handy to just say "use the dtb in my spare env space", especially if you use rendundant env. so the right one is selected.

I consider this bad design. The environment is one thing, and the dtb is a different thing. You are mixing two unrelated things here, which causes interdependencies that can cause a lot of trouble.

Quoted 7 lines

Not broken, just using a separate branch...

Quoted 1 line

git://denx.de/git/u-boot-fdt.git fdt-cmd

Best regards,
Wolfgang Denk

FYI, I needed to use the --all option on the git-push.

$ git push --all git+ssh://gu-fdt at www.denx.de/u-boot-fdt

I figured out what I was doing wrong, so the u-boot-fdt repository now has my fdt-cmd branch with the changes in it. Life is good!
<http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot/u-boot-fdt.git;a=shortlog;h=fdt-cmd>

Quoted 7 lines · In message <[email protected]> you wrote:

Quoted 5 lines

Not broken, just using a separate branch...

Quoted 1 line

git://denx.de/git/u-boot-fdt.git fdt-cmd

Best regards,
Wolfgang Denk

FYI, I needed to use the --all option on the git-push.

$ git push --all git+ssh://gu-fdt at www.denx.de/u-boot-fdt

Pulled, and cleaned up. Please be a bit more careful about the coding style.

Best regards,

Wolfgang Denk

Quoted 1 line

Wolfgang Denk wrote:

Quoted 5 lines

Pulled, and cleaned up. Please be a bit more careful about the coding style.

Best regards,

Quoted 1 line

Wolfgang Denk

Looking good. Thanks for the quick pull, git is GREAT!

Sorry about the coding style violations. :-(

Best regards,
gvb

As a result, if you pull an update from the master u-boot repository, you will get the new fdt command, libfdt support, *and modified bootm* command. While this shouldn't be a bad thing, it *is not* backward compatible with CONFIG_OF_FLAT_TREE.

Quoted 4 lines · Jerry Van Baren

As a result, if you pull an update from the master u-boot repository, you will get the new fdt command, libfdt support, *and modified bootm* command. While this shouldn't be a bad thing, it *is not* backward compatible with CONFIG_OF_FLAT_TREE.

I'm a little confused. CONFIG_OF_FLAT_TREE is needed to boot any powerpc kernel. Are you saying that the two options are mutually exclusive? Shouldn't CONFIG_OF_LIBFDT be a subset (instead of an alternative) to CONFIG_OF_FLAT_TREE? That is, you need to define CONFIG_OF_FLAT_TREE in order for CONFIG_OF_LIBFDT to be recognized?

Maybe I should have been paying more attention to your libfdt work, but I was assuming you were just going to alter the back-end handling of OF trees, not break existing code.

I view autogenerating fdt entries inside "bootm" as being evil. Obviously, if there are enough people on the Dark Side to overwhelm me, that can be changed.

Quoted 3 lines · In message <[email protected]> you wrote:

I view autogenerating fdt entries inside "bootm" as being evil. Obviously, if there are enough people on the Dark Side to overwhelm me, that can be changed.

"bootm" is intended to boot an image located somewhere in system memory. It will pass arguments like the booargs and the FDT to the kernel. It evaluates bootargs and substitured env vars for this. It might not be insane to expect that it also does reasonable things to the FDT.

I'm not in a position to determine what's reasonable there, though.

Best regards,

Wolfgang Denk

If bootm edits/augments the FDT, the boot scripts/user has no chance to change the items it edits/augments (biggie: the chosen node), or even print it before linux is launched. This defeats 90% of the purpose of the fdt command - allowing the user/script customize the blob before linux is launched.

My reasoning is that you can string together (or script) the proper "fdt" commands to do what previously was done by "bootm" in one step, so we are losing a small bit of convenience and gaining a whole lot of flexibility. As a for instance, currently/previously you had to

Much, perhaps most, possibly even all of the current stuff that is wedged into bootm is or should be passed through the blob.

Quoted 5 lines · In message <[email protected]> you wrote:

If bootm edits/augments the FDT, the boot scripts/user has no chance to change the items it edits/augments (biggie: the chosen node), or even print it before linux is launched. This defeats 90% of the purpose of the fdt command - allowing the user/script customize the blob before linux is launched.

I agree that it should be *possible* to do this, if wanted.Similar like we can set up our own contents of thebootargs variable.

On the other hand, bootm should do everything that is necessary to start a kernel without such interaction, if needed.

Remember for example that bootm gets called automatically and without user interaction after download commands when "autostart" is set to "yes".

Now assume we set "autostart" to "yes" nd use "dhcp" to load and start a multifile image containing the FDT. This is required to work, to.

Quoted 4 lines

My reasoning is that you can string together (or script) the proper "fdt" commands to do what previously was done by "bootm" in one step, so we are losing a small bit of convenience and gaining a whole lot of flexibility. As a for instance, currently/previously you had to

Agreed, but as an option, and without breaking compatibility of exiting methods.

Quoted 2 lines

Much, perhaps most, possibly even all of the current stuff that is wedged into bootm is or should be passed through the blob.

I cannot parse this. Please explain what you have in mind.

Best regards,
Wolfgang Denk

What if we made it so if there isn't a chosen node in the blob when bootm is called, it fills in a default one. This prevents some odd failures, and allows people to continue using device trees in the current manner, while still enabling the extra flexibility.

Quoted 2 lines · Wolfgang Denk

Quoted 1 line · In message <[email protected]> you wrote:

If bootm edits/augments the FDT, the boot scripts/user has no chance

Quoted 3 lines

Quoted 3 lines

change the items it edits/augments (biggie: the chosen node), or even

print it before linux is launched. This defeats 90% of the purpose

Quoted 9 lines

Quoted 2 lines

the fdt command - allowing the user/script customize the blob before linux is launched.

I agree that it should be *possible* to do this, if wanted.Similar like we can set up our own contents of thebootargs variable.

On the other hand, bootm should do everything that is necessary to start a kernel without such interaction, if needed.

Hi all

u-boot-users-bounces at lists.sourceforge.net wrote on 04/05/2007 04:00:15 AM:

Quoted 3 lines

Quoted 2 lines · Wolfgang Denk

Quoted 1 line · In message <[email protected]> you wrote:

If bootm edits/augments the FDT, the boot scripts/user has no chance

to

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

change the items it edits/augments (biggie: the chosen node), or even

print it before linux is launched. This defeats 90% of the purpose

of

Quoted 8 lines

Quoted 8 lines

Quoted 2 lines

the fdt command - allowing the user/script customize the blob before linux is launched.

I agree that it should be *possible* to do this, if wanted.Similar like we can set up our own contents of thebootargs variable.

On the other hand, bootm should do everything that is necessary to start a kernel without such interaction, if needed.

<snip snip>

My two cents worth (for what it's worth :-/): from the standpoint of someone using uboot for the first time and having to learn from the ground up without the benefit of having used this stuff for many years, I agree with Wolfgang. It took me two weeks just to figure out what a device tree is and that I even needed one. It took me two more days to figure out how to create the blob and how to use it. I still don't know the details of DTS files, what needs to be in them or what the different fields mean. Adding another step/level of obscurity with REQUIRING the use of fdt commands and/or scripts is just another barrier to new users. And I have to tell you, this thing is a bear to learn. For folks who have been digging around in the guts of it, I'm sure it's trivial. But I at least am pretty overwhelmed by it.

I think it would be great to have the option of using the ftd commands if it suited your purpose, but still be able to use things as they currently are. That would be the most flexible, give the expert users something they want, and not add yet another thing that new people HAVE to learn just to get an OS to boot.

Again just my 2 cents. Flames welcome.

Bruce

Quoted 4 lines

What if we made it so if there isn't a chosen node in the blob when bootm is called, it fills in a default one. This prevents some odd failures, and allows people to continue using device trees in the current manner, while still enabling the extra flexibility.

I plan to implement Andy Fleming's suggestion which will resolve the

Quoted 4 lines

Quoted 4 lines

What if we made it so if there isn't a chosen node in the blob when bootm is called, it fills in a default one. This prevents some odd failures, and allows people to continue using device trees in the current manner, while still enabling the extra flexibility.

gvb
Pedantic Script: device trees and blobs are kernel things, they ain't our fault. :-P Yet. ;-)

This was sloppy on my part and I apologize in advance for any confusion this may cause. Please take this opportunity to generate improvement patches, rather than invectives toward myself. ;-)

Quoted 3 lines · Jerry Van Baren

This was sloppy on my part and I apologize in advance for any confusion this may cause. Please take this opportunity to generate improvement patches, rather than invectives toward myself. ;-)

I finally had a chance to look at this code, and, well, I'm not crazy about it.

In short, I have a real problem with this:

#define FT_BUSFREQ 0x00000002 /* source is bd->bi_busfreq */
#define FT_ENETADDR 0x00000004 /* source is bd->bi_enetaddr */

Using flags to determine the SOURCE of the property data is bad, IMHO. It's just not flexible enough. Not only that, but you already have a bug in the definition of fixup_props[]:

#ifdef CONFIG_MPC83XX_TSEC2
	{	FT_UPDATE | FT_ENETADDR,
		"/" OF_SOC "/ethernet at 25000,
		"mac-address",
	},
	{	FT_UPDATE | FT_ENETADDR,
		"/" OF_SOC "/ethernet at 25000,
		"local-mac-address",
	},

#endif

FT_ENETADDR is the MAC address of eth0, but here it's being programmed into eth1! The obvious solution is to introduce:

#define FT_ENETADDR1 0x00000008 /* source is bd->bi_enetaddr1 */

But then you need definitions for eth2 and eth3

#define FT_ENETADDR2 0x00000010 /* source is bd->bi_enetaddr2 */
#define FT_ENETADDR3 0x00000020 /* source is bd->bi_enetaddr3 */

As you can see, you're already bloating the code.

A better solution would be to provide a function pointer for a function that can be called to fill in the property. Something like:

int ft_set_eth0(void *fdt, int nodeoffset, const char *name, bd_t *bd)

{
	return fdt_setprop(fdt, nodeoffset, name, bd->bi_enetaddr, 6);
}

or something like that. Then define fixup_props[] like this:

static const struct {
	int  createflags;
	char *node;
	char *prop;
	int (*set_function)(void *fdt, int nodeoffset, const char *name, bd_t *bd);
} fixup_props[] = {

What do you think about that? If you like it, I can make the change to mpc83xx/cpu.c

P.S. I've pushed a new fdt-cmd branch to the u-boot-fdt repo that does some clean up and separates out some fdt_support.c functions in preparation for improving the bootm automagic logic. There should be no collisions with Timur's proposed changes (if there are, I'll bear the responsibility of merging them :-/).

Quoted 5 lines · In message <[email protected]> you wrote:

P.S. I've pushed a new fdt-cmd branch to the u-boot-fdt repo that does some clean up and separates out some fdt_support.c functions in preparation for improving the bootm automagic logic. There should be no collisions with Timur's proposed changes (if there are, I'll bear the responsibility of merging them :-/).

I understand this is a call for review, not a pull request yet?

Best regards,

Wolfgang Denk