RE: FT u-boot shim

RE: FT u-boot shim

[Rune Torgersen]

Would it be possible to have the kernel smart enough that if it gets
passed a bd_t pointer, it updates the dts before booting fully.=20
Newer u-boot versions that support dts then would pass a NULL bd_t
pointer to a kernel that supports dts. Kernel would then not update the
dts, but use the one it gets handed.

bootm should be able to see if the kernel has an attached dts, update it
with runtime parameters, and hand it off to the kernel. If it is an old
kernel, hand it the bd_t pointer.

Re: FT u-boot shim

[Kumar Gala]

On Apr 27, 2006, at 2:30 PM, Rune Torgersen wrote:

> Would it be possible to have the kernel smart enough that if it gets
> passed a bd_t pointer, it updates the dts before booting fully.
> Newer u-boot versions that support dts then would pass a NULL bd_t
> pointer to a kernel that supports dts. Kernel would then not update  
> the
> dts, but use the one it gets handed.

What you are describing is the boot shim method.

U-boot is already capable of effectively doing this.  You can set a u- 
boot environment variable to make bootm do different things if you  
have flat device tree support built into u-boot.

> bootm should be able to see if the kernel has an attached dts,  
> update it
> with runtime parameters, and hand it off to the kernel. If it is an  
> old
> kernel, hand it the bd_t pointer.

We can do this w/o too much modification to what is happening in u- 
boot today.  I'd probably like to keep the ability to build a dev  
tree into the u-boot binary, but make the preferred means to pass a  
blob into the bootm command.

- kumar

Re: FT u-boot shim

[Wolfgang Denk]

In message <2CD98C5D-E51C-49CA-9BDC-6FE4C1B67854@kernel.crashing.org> you wrote:
> 
> We can do this w/o too much modification to what is happening in u- 
> boot today.  I'd probably like to keep the ability to build a dev  
> tree into the u-boot binary, but make the preferred means to pass a  

I don't like this, as it's a very Linux-centric view, but  U-Boot  is
supposed to be OS unaware and independent.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Q: Why do PCs have a reset button on the front?
A: Because they are expected to run Microsoft operating systems.

Re: FT u-boot shim

[Kumar Gala]

On Apr 27, 2006, at 2:45 PM, Wolfgang Denk wrote:

> In message <2CD98C5D- 
> E51C-49CA-9BDC-6FE4C1B67854@kernel.crashing.org> you wrote:
>>
>> We can do this w/o too much modification to what is happening in u-
>> boot today.  I'd probably like to keep the ability to build a dev
>> tree into the u-boot binary, but make the preferred means to pass a
>
> I don't like this, as it's a very Linux-centric view, but  U-Boot  is
> supposed to be OS unaware and independent.

Hmm, I guess.  There really isn't anything about the device tree that  
is Linux specific.  Other OSes could choice to use it.  But lets  
argue about that one once I've got the mechanism in which we pass the  
blob in via the bootm command.

The only difference I see would be that the address of the blob would  
be implicit if the blob was built into u-boot.  We would still use a  
passed in blob via the bootm command if given.

- kumar

Re: FT u-boot shim

[Wolfgang Denk]

In message <9F5CC364-8FC8-48BA-8D12-E524815B6537@kernel.crashing.org> you wrote:
> 
> Hmm, I guess.  There really isn't anything about the device tree that  
> is Linux specific.  Other OSes could choice to use it.  But lets  

I guess there are VxWorks BSP's for most of the boards we are talking
about, right? Do  they  use  the  device  tree?  I  would  be  *very*
surprised.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Microsoft Multimedia:
You have nice graphics, sound and animations when the system crashes.

Re: 85xx FDT updates?

[Kumar Gala]

On Apr 24, 2006, at 12:41 PM, Jon Loeliger wrote:

> OK, so what is the deal with the 85xx patches
> that have been submitted for more FDT support?
> I get a variety of mixed stories, message and
> vague comments.  I want some facts and direction.
>
> Can anyone verify, validate, refute, deny or
> support any of these statements?  Not trying to
> be mean, point fingers or sound negative here,
> I'm just trying to pinpoint the apparent log-jam.
>
>
> 1. The 85xx patches that Andy submitted, that
>    have been pulled into Kumar's 85xx git tree
>    are going to sit there until further patches
>    are submitted that _remove_all_85xx_support_
>    from the arch/ppc tree as well.
>
> 2. The same patches are going to sit in Kumar's
>    tree until 8560 patches with support for CPM
>    are released and all 85xx ports appear fully
>    and completely in arch/powerpc.  BTW, CPM is
>    waiting on approval of Vitaly's CPM proposal
>    for OF FDT support.
>
> 3. Statements 1 and 2 combined.
>
> 4. The same 85xx patches have just slipped through
>    some mental crack and simply need to be pulled,
>    re-applied, re-drafted, re-submitted.  Oops, sorry.
>    The action item is in _________'s lap.
>
> 5. There was an unresolved comment/issue that
>    FSL still needs to address.  BTW, that issue
>    is ________.
>
> 6. We are waiting on something else and that
>    item is _______.
>
> 7. You know, you really need to address the _other_
>    85xx ports (such as TQMs) as well.  Can you
>    please do something about those as well?
>
> 8. These Linux patches aren't going to be picked
>    up until the corresponding U-Boot patches are
>    picked up as well.

My understanding is that paulus should pull them into powerpc.git.   
He hasn't given me any reason to believe that shouldn't just happen.   
I dont see any reason that we need to have other dependancies for  
code that works.  I'll push on paulus to pull the patches in my tree  
into powerpc.git.

However, I am against removing the arch/ppc support until the u-boot  
patches are picked up.  I think its bad form to give people a kernel  
they can't easily boot.

- k

Re: 85xx FDT updates?

[Kumar Gala]

On Apr 25, 2006, at 1:01 PM, Eugene Surovegin wrote:

> On Tue, Apr 25, 2006 at 12:39:45PM -0500, Kumar Gala wrote:
>>> Kumar, you are missing our point. Let's say I packaged Motorola eval
>>> board and sold it as my product. So, you have this board in the tree
>>> but I cannot update firmware on this board. What you suggest I  
>>> have to
>>> do so my customer can run new kernel on it? Recall the board or fly
>>> to the customer site with Abatron? This is just ridiculous.
>>
>> If you are doing this, you should have someone for your customers to
>> update the firmware.
>
> Wow, I want to live in that world you seem to be living. I rest my
> case.

s/someone/someway/

>> What happens when Freescale finds an errata that requires a new
> firmware image?
>
> I find a way to handle it in the kernel. So far, I was quite
> successful in doing this for 440 (I just sent a patch for one of such
> erratum upstream).

This may be true for the errata on the 440, however I can envision  
DDR performance tweaks which are not as ease to implement in the  
kernel w/o reproducing the work of the firmware.

>> I understand the point for a custom solution, however I think make
>> the same claim for a reference board is silly, until someone can show
>> me a real case in which its not feasible to update the firmware.
>
> I can imagine doing this for CDS for example.
>
> Kumar, you seem to insist that it's easy to update firmware in field,
> it's not. I've been doing this stuff for many years, Dan - probably
> for decades, but you refuse to listen.

I believe you with regards to custom boards, however I dont feel the  
same is true for reference boards.  I'm in the same boat as you with  
regards to building a product.  But, I see the intent and usage of a  
reference board from Freescale, IBM, or AMCC as a completely  
different usage model.  If you know of someone that is buttoning up a  
reference board from one of these guys let me know.  I've got some  
bridges I can sell the guy as well.

> What you will end up with is that that small amount of embedded people
> who bother to contribute something back will stop doing this. We are
> more than capable of maintaining our internal kernel trees :).

I'm not sure what to say to this.  Things need to move forward at  
some point.  I still not clear as to what exactly you are advocating  
beyond that we should keep the arch/ppc code around for ever.

- kumar

Re: 85xx FDT updates?

[Eugene Surovegin]

On Tue, Apr 25, 2006 at 01:14:55PM -0500, Kumar Gala wrote:
> 
> >What you will end up with is that that small amount of embedded people
> >who bother to contribute something back will stop doing this. We are
> >more than capable of maintaining our internal kernel trees :).
> 
> I'm not sure what to say to this.  Things need to move forward at  
> some point.  

I don't see how removing features and breaking compatibility with 
almost _all_ current embedded PPC boards boards is "moving forward". 
Enlighten me, please.

> I still not clear as to what exactly you are advocating  
> beyond that we should keep the arch/ppc code around for ever.

Providing compatibility for non-flat-tree firmware. This doesn't mean 
keeping arch/ppc.

-- 
Eugene

Re: 85xx FDT updates?

[Brent Cook]

On Tuesday 25 April 2006 13:24, Eugene Surovegin wrote:
> On Tue, Apr 25, 2006 at 01:14:55PM -0500, Kumar Gala wrote:
> > >What you will end up with is that that small amount of embedded people
> > >who bother to contribute something back will stop doing this. We are
> > >more than capable of maintaining our internal kernel trees :).
> >
> > I'm not sure what to say to this.  Things need to move forward at
> > some point.
>
> I don't see how removing features and breaking compatibility with
> almost _all_ current embedded PPC boards boards is "moving forward".
> Enlighten me, please.
>
> > I still not clear as to what exactly you are advocating
> > beyond that we should keep the arch/ppc code around for ever.
>
> Providing compatibility for non-flat-tree firmware. This doesn't mean
> keeping arch/ppc.

Would it be possible to create the device tree in the kernel and then jump 
into the normal entry point? We need some sort of translation shim between 
the normal kernel and whatever oddball method firmware X chooses to hand-off 
to the kernel.

Re: 85xx FDT updates?

[Kumar Gala]

On Apr 25, 2006, at 1:29 PM, Brent Cook wrote:

> On Tuesday 25 April 2006 13:24, Eugene Surovegin wrote:
>> On Tue, Apr 25, 2006 at 01:14:55PM -0500, Kumar Gala wrote:
>>>> What you will end up with is that that small amount of embedded  
>>>> people
>>>> who bother to contribute something back will stop doing this. We  
>>>> are
>>>> more than capable of maintaining our internal kernel trees :).
>>>
>>> I'm not sure what to say to this.  Things need to move forward at
>>> some point.
>>
>> I don't see how removing features and breaking compatibility with
>> almost _all_ current embedded PPC boards boards is "moving forward".
>> Enlighten me, please.
>>
>>> I still not clear as to what exactly you are advocating
>>> beyond that we should keep the arch/ppc code around for ever.
>>
>> Providing compatibility for non-flat-tree firmware. This doesn't mean
>> keeping arch/ppc.
>
> Would it be possible to create the device tree in the kernel and  
> then jump
> into the normal entry point? We need some sort of translation shim  
> between
> the normal kernel and whatever oddball method firmware X chooses to  
> hand-off
> to the kernel.

Agreed, that would be nice.  I would love for someone to create such  
a thing.  I personally dont have any time or interesting in it.

- kumar

Re: 85xx FDT updates?

[Eugene Surovegin]

On Tue, Apr 25, 2006 at 01:33:38PM -0500, Kumar Gala wrote:
> I personally dont have any time or interesting in it.

So, don't break compatibility if you don't have time/interest to fix 
it. We can wait till someone who "wants to move forward" can do this 
professionally without screwing everybody else.

-- 
Eugene

FT u-boot shim

[Kumar Gala]

> So, don't break compatibility if you don't have time/interest to fix
> it. We can wait till someone who "wants to move forward" can do this
> professionally without screwing everybody else.

So, lets turn this discussion into something useful (since having us  
going back and forth about our opinions isn't really going anywhere)

If we have a u-boot shim there are some questions that need answering:
* where should the .dts live (hate duplicating the file both in u- 
boot and kernel source tree)
* how does build system find .dts
* a Kconfig option to enable shim
* assume done as a boot wrapper of sorts

- kumar

Re: FT u-boot shim

[Wolfgang Denk]

In message <1448E56E-1327-40D5-BE44-0DC103AC3E8A@kernel.crashing.org> you wrote:
>
> If we have a u-boot shim there are some questions that need answering:
> * where should the .dts live (hate duplicating the file both in u- 
> boot and kernel source tree)

Since U-Boot  does  not  need  nor  use  this  information  for  it's
operation, but the kernel does, it should be part of the kernel.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"We don't have to protect the environment -- the Second Coming is  at
hand."                                                   - James Watt

Re: FT u-boot shim

[Kumar Gala]

On Apr 25, 2006, at 4:30 PM, Wolfgang Denk wrote:

> In message <1448E56E-1327-40D5- 
> BE44-0DC103AC3E8A@kernel.crashing.org> you wrote:
>>
>> If we have a u-boot shim there are some questions that need  
>> answering:
>> * where should the .dts live (hate duplicating the file both in u-
>> boot and kernel source tree)
>
> Since U-Boot  does  not  need  nor  use  this  information  for  it's
> operation, but the kernel does, it should be part of the kernel.

What about the case in which u-boot already has a .dts for a given  
board?  Should we duplicate the files between the kernel & u-boot?

- kumar

Re: FT u-boot shim

[Wolfgang Denk]

In message <07A76292-03D1-4648-AA40-11E06698FEE1@kernel.crashing.org> you wrote:
> 
> > Since U-Boot  does  not  need  nor  use  this  information  for  it's
> > operation, but the kernel does, it should be part of the kernel.
> 
> What about the case in which u-boot already has a .dts for a given  
> board?  Should we duplicate the files between the kernel & u-boot?

No. Remove them from the U-Boot tree. I was never happy to  see  this
stuff there.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Don't panic.

Re: FT u-boot shim

[Kumar Gala]

On Apr 25, 2006, at 4:39 PM, Wolfgang Denk wrote:

> In message <07A76292-03D1-4648- 
> AA40-11E06698FEE1@kernel.crashing.org> you wrote:
>>
>>> Since U-Boot  does  not  need  nor  use  this  information  for   
>>> it's
>>> operation, but the kernel does, it should be part of the kernel.
>>
>> What about the case in which u-boot already has a .dts for a given
>> board?  Should we duplicate the files between the kernel & u-boot?
>
> No. Remove them from the U-Boot tree. I was never happy to  see  this
> stuff there.

Then why did you accept the patches for them?  I'm confused on what  
you see as the solution for how to boot an arch/powerpc kernel going  
forward.

- k

Re: FT u-boot shim

[Wolfgang Denk]

In message <DAD4396E-7458-471C-8150-9DDCD396BA63@kernel.crashing.org> you wrote:
> 
> > No. Remove them from the U-Boot tree. I was never happy to  see  this
> > stuff there.
> 
> Then why did you accept the patches for them?  I'm confused on what  

Because I  had  neither  time  nor  nerves  to  discuss  with  kernel
maintainers how this could be done. Several people asked me again and
again  to  accept  these  patches  because  they  were  vital for FDT
support, so I gave in.

> you see as the solution for how to boot an arch/powerpc kernel going  
> forward.

I strongly agree with Dan and Eugene: the kernel should not depend on
any specific version of a boot loader, and more general not  even  on
any specific boot loader at all.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Any sufficiently advanced technology is indistinguishable from magic.
Clarke's Third Law       - _Profiles of the Future_ (1962; rev. 1973)
                  ``Hazards of Prophecy: The Failure of Imagination''

Re: FT u-boot shim

[Kumar Gala]

On Apr 25, 2006, at 5:28 PM, Wolfgang Denk wrote:

> In message  
> <DAD4396E-7458-471C-8150-9DDCD396BA63@kernel.crashing.org> you wrote:
>>
>>> No. Remove them from the U-Boot tree. I was never happy to  see   
>>> this
>>> stuff there.
>>
>> Then why did you accept the patches for them?  I'm confused on what
>
> Because I  had  neither  time  nor  nerves  to  discuss  with  kernel
> maintainers how this could be done. Several people asked me again and
> again  to  accept  these  patches  because  they  were  vital for FDT
> support, so I gave in.
>
>> you see as the solution for how to boot an arch/powerpc kernel going
>> forward.
>
> I strongly agree with Dan and Eugene: the kernel should not depend on
> any specific version of a boot loader, and more general not  even  on
> any specific boot loader at all.

I think thats part of the idea with arch/powerpc defining a standard  
mechanism for how a boot loader should pass information to the kernel  
(via a flat device tree).

How would you propose that we handle booting arch/powerpc kernels  
from u-boot going forward? (for new board ports and existing board  
ports).

- kumar

Re: FT u-boot shim

[Wolfgang Denk]

In message <A8793E99-83C1-4FD9-8735-D2E8F98B3003@kernel.crashing.org> you wrote:
> 
> I think thats part of the idea with arch/powerpc defining a standard  
> mechanism for how a boot loader should pass information to the kernel  
> (via a flat device tree).

Yet another standard.

> How would you propose that we handle booting arch/powerpc kernels  
> from u-boot going forward? (for new board ports and existing board  
> ports).

Ideally, I'd like to see a common kernel  interface  for  all  archi-
tectures,  PowerPC  and ARM and MIPS and ... But last time I dared to
suggest this I've been told what a nincompoop I am.

I will accept what is decided by the P.T.B., but  I  request  not  to
break backwards compatibility with existing systems.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Monday is an awful way to spend one seventh of your life.

Re: FT u-boot shim

[Geert Uytterhoeven]

On Wed, 26 Apr 2006, Wolfgang Denk wrote:
> In message <A8793E99-83C1-4FD9-8735-D2E8F98B3003@kernel.crashing.org> you wrote:
> > How would you propose that we handle booting arch/powerpc kernels  
> > from u-boot going forward? (for new board ports and existing board  
> > ports).
> 
> Ideally, I'd like to see a common kernel  interface  for  all  archi-
> tectures,  PowerPC  and ARM and MIPS and ... But last time I dared to
> suggest this I've been told what a nincompoop I am.

Let's hope Linux Darwinism will convergenge to a common kernel interface...

> I will accept what is decided by the P.T.B., but  I  request  not  to
> break backwards compatibility with existing systems.

[ dict ptb -> Physikalisch-Technische Bundesanstalt ? ]

Ah, Powers That Be!

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: FT u-boot shim

[Kumar Gala]

On Apr 26, 2006, at 2:19 PM, Wolfgang Denk wrote:

> In message <A8793E99-83C1-4FD9-8735- 
> D2E8F98B3003@kernel.crashing.org> you wrote:
>>
>> I think thats part of the idea with arch/powerpc defining a standard
>> mechanism for how a boot loader should pass information to the kernel
>> (via a flat device tree).
>
> Yet another standard.
>
>> How would you propose that we handle booting arch/powerpc kernels
>> from u-boot going forward? (for new board ports and existing board
>> ports).
>
> Ideally, I'd like to see a common kernel  interface  for  all  archi-
> tectures,  PowerPC  and ARM and MIPS and ... But last time I dared to
> suggest this I've been told what a nincompoop I am.
>
> I will accept what is decided by the P.T.B., but  I  request  not  to
> break backwards compatibility with existing systems.

I've been thinking about the various issues related to booting an  
arch/powerpc kernel via u-boot.   I was hoping to get some ideas/ 
comments on what people thought about the various issues/questions  
related to producing a system that can boot an arch/powerpc kernel  
for an embedded system.  I'm using u-boot as the boot loader since  
its a popular choice (I imagine the issues are similar for others):

[NOTE: dts, flat dev tree, etc are used interchangeably]

1. boot with an "old" u-boot (via bd_t):
* Have a boot wrapper that takes bd_t and dts and merges them @ runtime
* Boot wrapper has to be custom based on bd_t definition for the system
* dts owned by kernel??

2. boot with a "new" u-boot (has a .dts in it):
* capable of booting arch/powerpc kernel directly w/o modification
* in a production system don't want to update u-boot
* dts owned by u-boot??

Some questions/issues:
* ownership of .dts is problematic.  I hate having a file duplicated  
by both u-boot and kernel.  However it also seems bad to make the  
build of either depend on the user grabbing a dts from some third  
party.  Ideas?  A concrete example would be the MPC8349 ADS/SYS/MDS  
port.  Boards ship with an "old" u-boot, thus we need a kernel  
wrapper with .dts.  However, newer u-boot's can (hopefully will) have  
a dts in them

* updating of dts:  In case 1, this is trivial since its part of the  
kernel blob.  Case 2. is more difficult.  What do people think of  
treating the dts like the environment.  You have a version compiled  
in, but can alternately have a blob in another location that will be  
used if exists.  This would allow one to update the dts portion w/o  
effecting the actual boot loader.

* one solution to the copies of .dts is that we make the wrapper  
portion of the kernel the owner of the official latest and  
greatest .dts.  Every so often a maintainer can sync their .dts with  
u-boot to keep them relatively in sync.  However, the main mechanism  
would be to load the latest .dts blob into the secondary location.   
We can provide scripts/tools to do this via u-boot and linux.

comments, other issues people have thought of?

- kumar

Re: FT u-boot shim

[Wolfgang Denk]

In message <6E3621C5-A379-4ABC-99C0-9A02B48D525D@kernel.crashing.org>
Kumar Gala wrote:
> 
> 1. boot with an "old" u-boot (via bd_t):
> * Have a boot wrapper that takes bd_t and dts and merges them @ runtime
> * Boot wrapper has to be custom based on bd_t definition for the system
> * dts owned by kernel??

Since we cannot go back in time and fix the "old" U-Boot  this  seems
to be the only option.

> 2. boot with a "new" u-boot (has a .dts in it):
> * capable of booting arch/powerpc kernel directly w/o modification

OK.

> * in a production system don't want to update u-boot

Let's say we have to support such situations, too.

> * dts owned by u-boot??

I'm not sure about this. I tend to believe the  dts  belongs  to  the
kernel.

> Some questions/issues:
> * ownership of .dts is problematic.  I hate having a file duplicated  
> by both u-boot and kernel.  However it also seems bad to make the  
> build of either depend on the user grabbing a dts from some third  
> party.  Ideas?  A concrete example would be the MPC8349 ADS/SYS/MDS  
> port.  Boards ship with an "old" u-boot, thus we need a kernel  
> wrapper with .dts.  However, newer u-boot's can (hopefully will) have  
> a dts in them

Can we provide the dts as a separate blob that gets  built  with  the
kernel image? From U-Boot's point of view, this could be a multi-file
image  which  combines  the  dts and the kernel into a single file so
that users don't have to care much about this.

> * updating of dts:  In case 1, this is trivial since its part of the  
> kernel blob.  Case 2. is more difficult.  What do people think of  
> treating the dts like the environment.  You have a version compiled  

I don't like this idea.

> in, but can alternately have a blob in another location that will be  
> used if exists.  This would allow one to update the dts portion w/o  
> effecting the actual boot loader.

If we consider this, then we might as well combine the dts  with  the
kernel  image.  Alternatively,  the dts might be stored in a separate
location in memory. It would be easy to extend the "bootm" command to
take an additional argument (dts address).

> * one solution to the copies of .dts is that we make the wrapper  
> portion of the kernel the owner of the official latest and  
> greatest .dts.  Every so often a maintainer can sync their .dts with  
> u-boot to keep them relatively in sync.  However, the main mechanism  
> would be to load the latest .dts blob into the secondary location.   

Why not load it separately or as part of the Linux kernel image?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
No user-servicable parts inside. Refer to qualified service personnel.

Re: FT u-boot shim

[Kumar Gala]

> Let's say we have to support such situations, too.
>
>> * dts owned by u-boot??
>
> I'm not sure about this. I tend to believe the  dts  belongs  to  the
> kernel.
>
>> Some questions/issues:
>> * ownership of .dts is problematic.  I hate having a file duplicated
>> by both u-boot and kernel.  However it also seems bad to make the
>> build of either depend on the user grabbing a dts from some third
>> party.  Ideas?  A concrete example would be the MPC8349 ADS/SYS/MDS
>> port.  Boards ship with an "old" u-boot, thus we need a kernel
>> wrapper with .dts.  However, newer u-boot's can (hopefully will) have
>> a dts in them
>
> Can we provide the dts as a separate blob that gets  built  with  the
> kernel image? From U-Boot's point of view, this could be a multi-file
> image  which  combines  the  dts and the kernel into a single file so
> that users don't have to care much about this.

The problem is that there are somethings that u-boot knows that needs  
to go into the blob (memory size, boot args, initrd info,  
frequencies, etc.)

>> * updating of dts:  In case 1, this is trivial since its part of the
>> kernel blob.  Case 2. is more difficult.  What do people think of
>> treating the dts like the environment.  You have a version compiled
>
> I don't like this idea.
>
>> in, but can alternately have a blob in another location that will be
>> used if exists.  This would allow one to update the dts portion w/o
>> effecting the actual boot loader.
>
> If we consider this, then we might as well combine the dts  with  the
> kernel  image.  Alternatively,  the dts might be stored in a separate
> location in memory. It would be easy to extend the "bootm" command to
> take an additional argument (dts address).

How would we distinguish the bootm command that takes a blob versus  
the ones we have today?

>> * one solution to the copies of .dts is that we make the wrapper
>> portion of the kernel the owner of the official latest and
>> greatest .dts.  Every so often a maintainer can sync their .dts with
>> u-boot to keep them relatively in sync.  However, the main mechanism
>> would be to load the latest .dts blob into the secondary location.
>
> Why not load it separately or as part of the Linux kernel image?

As stated before, the main issue is doing some runtime fix ups to the  
blob before its handed to the kernel.

The following pieces of info are setup at runtime that are board  
specific:

linux,stdout_path
cpus/<foo>/clock-frequency
cpus/<foo>/timebase-frequency
cpus/<foo>/bus-frequency
<soc>/pci/bus-range
<soc>/bus-frequency
<soc>/serial/clock-frequecny
<soc>/ethernet/address

We could hand bootm a memory location with a blob and do the fix ups  
at runtime, we would still have some coupling between the blob and u- 
boot build.  At least the blob wouldn't be built into u-boot.

- kumar

Re: FT u-boot shim

[Jerry Van Baren]

Kumar Gala wrote:
>> Let's say we have to support such situations, too.
>>
>>> * dts owned by u-boot??
>> I'm not sure about this. I tend to believe the  dts  belongs  to  the
>> kernel.
>>
>>> Some questions/issues:
>>> * ownership of .dts is problematic.  I hate having a file duplicated
>>> by both u-boot and kernel.  However it also seems bad to make the
>>> build of either depend on the user grabbing a dts from some third
>>> party.  Ideas?  A concrete example would be the MPC8349 ADS/SYS/MDS
>>> port.  Boards ship with an "old" u-boot, thus we need a kernel
>>> wrapper with .dts.  However, newer u-boot's can (hopefully will) have
>>> a dts in them
>> Can we provide the dts as a separate blob that gets  built  with  the
>> kernel image? From U-Boot's point of view, this could be a multi-file
>> image  which  combines  the  dts and the kernel into a single file so
>> that users don't have to care much about this.
> 
> The problem is that there are somethings that u-boot knows that needs  
> to go into the blob (memory size, boot args, initrd info,  
> frequencies, etc.)

[snip]

> - kumar

A thought that keeps recurring (but I've suppressed because I don't have 
time to play...) is that it would be Really Cool[tm] to store the u-boot 
env variables in a flat tree and then pass the env/tree to linux.  It 
also sounds like a major change & disruption to u-boot :-(.  I haven't 
looked at what it would do to code size either.

U-boot could then be a better OpenBoot than OpenBoot ;-)

gvb

Re: FT u-boot shim

[Wolfgang Denk]

In message <D358E665-60E4-48C0-82FD-7A1C16DAF00C@kernel.crashing.org> you wrote:
>
> The problem is that there are somethings that u-boot knows that needs  
> to go into the blob (memory size, boot args, initrd info,  
> frequencies, etc.)

Yes. Can we append auch variable data to the fixed part of the dts?

> How would we distinguish the bootm command that takes a blob versus  
> the ones we have today?

Arg count. For example:

OLD:	bootm <kernel_addr>
   or	bootm <kernel_addr> <ramdisk_addr>

NEW:	bootm <kernel_addr> - <dts_addr>
   or	bootm <kernel_addr> <ramdisk_addr> <dts_addr>

> As stated before, the main issue is doing some runtime fix ups to the  
> blob before its handed to the kernel.

Let's do exactly this: runtime fix ups.

> We could hand bootm a memory location with a blob and do the fix ups  
> at runtime, we would still have some coupling between the blob and u- 
> boot build.  At least the blob wouldn't be built into u-boot.

OK.



Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
It is necessary to have purpose.
	-- Alice #1, "I, Mudd", stardate 4513.3

Re: FT u-boot shim

[Kumar Gala]

On Apr 27, 2006, at 2:40 PM, Wolfgang Denk wrote:

> In message  
> <D358E665-60E4-48C0-82FD-7A1C16DAF00C@kernel.crashing.org> you wrote:
>>
>> The problem is that there are somethings that u-boot knows that needs
>> to go into the blob (memory size, boot args, initrd info,
>> frequencies, etc.)
>
> Yes. Can we append auch variable data to the fixed part of the dts?

appending is not really how it works, but the runtime fixup is doable.

>> How would we distinguish the bootm command that takes a blob versus
>> the ones we have today?
>
> Arg count. For example:
>
> OLD:	bootm <kernel_addr>
>    or	bootm <kernel_addr> <ramdisk_addr>
>
> NEW:	bootm <kernel_addr> - <dts_addr>
>    or	bootm <kernel_addr> <ramdisk_addr> <dts_addr>
>
>> As stated before, the main issue is doing some runtime fix ups to the
>> blob before its handed to the kernel.
>
> Let's do exactly this: runtime fix ups.
>
>> We could hand bootm a memory location with a blob and do the fix ups
>> at runtime, we would still have some coupling between the blob and u-
>> boot build.  At least the blob wouldn't be built into u-boot.
>
> OK.

Let me play with this some now that I've got some direction.

- kumar

Re: FT u-boot shim

[Kumar Gala]

>> How would we distinguish the bootm command that takes a blob versus
>> the ones we have today?
>
> Arg count. For example:
>
> OLD:	bootm <kernel_addr>
>    or	bootm <kernel_addr> <ramdisk_addr>
>
> NEW:	bootm <kernel_addr> - <dts_addr>
>    or	bootm <kernel_addr> <ramdisk_addr> <dts_addr>

do you mean a literal '-' char for the no ramdisk, but dts case?

- kumar

Re: FT u-boot shim

[Wolfgang Denk]

In message <7BC50BA2-D657-4907-94AA-DB5926F22504@kernel.crashing.org> you wrote:
>
> > NEW:	bootm <kernel_addr> - <dts_addr>
> >    or	bootm <kernel_addr> <ramdisk_addr> <dts_addr>
> 
> do you mean a literal '-' char for the no ramdisk, but dts case?

Yes. We could write "bootm <kernel_addr> NULL <dts_addr>"  or  "bootm
<kernel_addr> none <dts_addr>" or anythingl ike that as well, but I'm
a lazy typist :-)

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"...this does not mean that some of us should not want, in  a  rather
dispassionate sort of way, to put a bullet through csh's head."
                   - Larry Wall in <1992Aug6.221512.5963@netlabs.com>

Re: FT u-boot shim

[Mark A. Greer]

On Tue, Apr 25, 2006 at 03:00:05PM -0500, Kumar Gala wrote:
> > So, don't break compatibility if you don't have time/interest to fix
> > it. We can wait till someone who "wants to move forward" can do this
> > professionally without screwing everybody else.
> 
> So, lets turn this discussion into something useful (since having us  
> going back and forth about our opinions isn't really going anywhere)
> 
> If we have a u-boot shim there are some questions that need answering:
> * where should the .dts live (hate duplicating the file both in u- 
> boot and kernel source tree)
> * how does build system find .dts
> * a Kconfig option to enable shim
> * assume done as a boot wrapper of sorts

Haven't we always had a shim like layer like this only we called it the
bootwrapper?  IOW, arch/ppc/boot/*...now called arch/powerpc/boot?

FWIW, I'm farting around with a non u-boot platform and, basically, I added
a dts directory under arch/powerpc/boot.  I use dtc to compile a dts file
into a .S file then build the .S file with the normal kernel build (you
could easily do the dtc compile w/ the build as well).  Some minor hacking
of other stuff in the boot dir and it gets the job done.  Its a total
hack right now so I'd rather not give a patch but the point is we
already have a logical place for it and its not that hard.

I know the boot dir is supposed to be moved at some point but it seems
like the logical place to put this functionality until it does move
(and even after it moves).

Mark

Re: FT u-boot shim

[Eugene Surovegin]

On Tue, Apr 25, 2006 at 03:00:05PM -0500, Kumar Gala wrote:
> 
> If we have a u-boot shim there are some questions that need answering:
> * where should the .dts live (hate duplicating the file both in u- 
> boot and kernel source tree)

I have no strong opinion on this, maybe arch/powerpc/boot/85xx or 
something. Although we may require having U-Boot tree somewhere I 
don't particularly like this solution, it's better to keep kernel 
self-contained, even if it requires some duplication. I personally 
don't see this as an issue, because I assume this file isn't gonna 
change frequently anyway.

Also, I think it's much safer to have this file in the kernel, this 
way we will avoid potential problems with using different U-Boot 
versions with different versions.

> * how does build system find .dts

If we go with "we-need-U-Boot-tree" solution, we can add Kconfig 
option to specify path to U-Boot tree.

> * a Kconfig option to enable shim

Yes, there should be an option, for boards which can support old and 
new U-Boot it should be user-selectable with old U-Boot being 
a default. For boards which support only one type of U-Boot, this 
option can be selected automatically.

> * assume done as a boot wrapper of sorts

Yeah, probably.

-- 
Eugene

Re: FT u-boot shim

[Paul Mackerras]

Kumar Gala writes:

> If we have a u-boot shim there are some questions that need answering:
> * where should the .dts live (hate duplicating the file both in u- 
> boot and kernel source tree)
> * how does build system find .dts
> * a Kconfig option to enable shim
> * assume done as a boot wrapper of sorts

What I think would be useful is a stand-alone tool that would take a
kernel and a dts and construct an image that is bootable on a given
board by its existing firmware.  That means there would either need to
be a version of the tool for each firmware, or alternatively a set of
command-line options to tell it what sort of firmware you have.

This wouldn't have to be done at kernel build time; it could be
potentially be done much later.  Hopefully then the board vendors
could take on the job of generating the dts.  In fact for some boards
the board-support package could be just the dts.

This tool would need to insert a suitable shim, which might actually
need to contain code to pull stuff out of a firmware-specific
structure such as a bd_t, and stuff it into the dts.  That should be
doable provided there is a convention about labels in the dts for
things such as memory size, ethernet mac address, etc.

Clearly it is neater if the firmware can supply the device-tree blob
directly, and just boot a raw kernel.  However, there will always be
situations where we don't get to choose the firmware, so I think we
need this tool.

Paul.

Re: FT u-boot shim

[Kumar Gala]

On Apr 28, 2006, at 6:28 AM, Paul Mackerras wrote:

> Kumar Gala writes:
>
>> If we have a u-boot shim there are some questions that need  
>> answering:
>> * where should the .dts live (hate duplicating the file both in u-
>> boot and kernel source tree)
>> * how does build system find .dts
>> * a Kconfig option to enable shim
>> * assume done as a boot wrapper of sorts
>
> What I think would be useful is a stand-alone tool that would take a
> kernel and a dts and construct an image that is bootable on a given
> board by its existing firmware.  That means there would either need to
> be a version of the tool for each firmware, or alternatively a set of
> command-line options to tell it what sort of firmware you have.
>
> This wouldn't have to be done at kernel build time; it could be
> potentially be done much later.  Hopefully then the board vendors
> could take on the job of generating the dts.  In fact for some boards
> the board-support package could be just the dts.
>
> This tool would need to insert a suitable shim, which might actually
> need to contain code to pull stuff out of a firmware-specific
> structure such as a bd_t, and stuff it into the dts.  That should be
> doable provided there is a convention about labels in the dts for
> things such as memory size, ethernet mac address, etc.
>
> Clearly it is neater if the firmware can supply the device-tree blob
> directly, and just boot a raw kernel.  However, there will always be
> situations where we don't get to choose the firmware, so I think we
> need this tool.

I agree with this (after having it beaten into me :).

However, I really hate introducing some third project that is  
required.  If we decide to pull ALL of boot wrappers out of the  
kernel tree than I'd be ok with it.  But until that time I think this  
lives under arch/powerpc/boot/...

What I envision as the way one boots for something like u-boot is one  
of three options:
1. using an old u-boot + boot wrapper (bd_t -> wrapper -> kernel)
2. using a u-boot that is ft aware + dtb (boot command in u-boot  
takes kernel & dtb images, updates blob and passes to kernel)
3. using a u-boot that is ft aware + built in dtb.

The issue is that for a given system/board you may need to support  
multiple or all three.  This raises the question where does the .dts  
live.  For the time being I say it lives in the boot wrapper part of  
the kernel tree.  Thus we handle the three cases as follows:

1. built as part of the boot wrapper
2. build a multi image u-boot image, one section for the blob
3. point u-boot build system at .dts

- kumar

Re: FT u-boot shim

[Wolfgang Denk]

In message <EA2821E8-FB7E-4DDA-8C18-C659B5483DC2@kernel.crashing.org>
Kumar Gala wrote:
> 
> What I envision as the way one boots for something like u-boot is one  
> of three options:
> 1. using an old u-boot + boot wrapper (bd_t -> wrapper -> kernel)
> 2. using a u-boot that is ft aware + dtb (boot command in u-boot  
> takes kernel & dtb images, updates blob and passes to kernel)
> 3. using a u-boot that is ft aware + built in dtb.
> 
> The issue is that for a given system/board you may need to support  
> multiple or all three.  This raises the question where does the .dts  

Assuming we had 2., under which circumstances would we need 3. then?


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
A conservative is a man with two perfectly good legs  who  has  never
learned to walk.                              - Franklin D. Roosevelt

Re: FT u-boot shim

[Tom Rini]

On Fri, Apr 28, 2006 at 09:11:24PM +0200, Wolfgang Denk wrote:
> In message <EA2821E8-FB7E-4DDA-8C18-C659B5483DC2@kernel.crashing.org>
> Kumar Gala wrote:
> > 
> > What I envision as the way one boots for something like u-boot is one  
> > of three options:
> > 1. using an old u-boot + boot wrapper (bd_t -> wrapper -> kernel)
> > 2. using a u-boot that is ft aware + dtb (boot command in u-boot  
> > takes kernel & dtb images, updates blob and passes to kernel)
> > 3. using a u-boot that is ft aware + built in dtb.
> > 
> > The issue is that for a given system/board you may need to support  
> > multiple or all three.  This raises the question where does the .dts  
> 
> Assuming we had 2., under which circumstances would we need 3. then?

Especially if we had mkuimage let you tack your dtb into the 'kernel'
image.

-- 
Tom Rini
http://gate.crashing.org/~trini/

Re: FT u-boot shim

[Wolfgang Denk]

Dear Tom,

in message <20060428194457.GA458@smtp.west.cox.net> you wrote:
>
> > > 3. using a u-boot that is ft aware + built in dtb.
...
> > Assuming we had 2., under which circumstances would we need 3. then?
> 
> Especially if we had mkuimage let you tack your dtb into the 'kernel'
> image.

Sorry, but I don't understand. If we have the dtb combined  with  the
kernel  image,  then  why would we need another copy of the dtb built
into U-Boot?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
A day without sunshine is like night.

Re: FT u-boot shim

[Tom Rini]

On Sat, Apr 29, 2006 at 01:07:20AM +0200, Wolfgang Denk wrote:
> Dear Tom,
> 
> in message <20060428194457.GA458@smtp.west.cox.net> you wrote:
> >
> > > > 3. using a u-boot that is ft aware + built in dtb.
> ...
> > > Assuming we had 2., under which circumstances would we need 3. then?
> > 
> > Especially if we had mkuimage let you tack your dtb into the 'kernel'
> > image.
> 
> Sorry, but I don't understand. If we have the dtb combined  with  the
> kernel  image,  then  why would we need another copy of the dtb built
> into U-Boot?

You wouldn't have the dtb combined in the kernel image, unless you have
the shim.   This is instead of loading a separate dtb anyhow.

-- 
Tom Rini
http://gate.crashing.org/~trini/

Re: FT u-boot shim

[Wolfgang Denk]

In message <20060428232211.GE458@smtp.west.cox.net> you wrote:
>
> You wouldn't have the dtb combined in the kernel image, unless you have
> the shim.   This is instead of loading a separate dtb anyhow.

Now you got me completely confused. [Maybe I should go to bed.]

Kumar wrote:

> What I envision as the way one boots for something like u-boot is one  
> of three options:
> 1. using an old u-boot + boot wrapper (bd_t -> wrapper -> kernel)
> 2. using a u-boot that is ft aware + dtb (boot command in u-boot  
> takes kernel & dtb images, updates blob and passes to kernel)
> 3. using a u-boot that is ft aware + built in dtb.

In my understanding, 1. is with a shim; 2. is loading a separate  dtb
(probably  as  multi-file  image), and 3. is when U-Boot provides the
dtb. Am I missing something?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
If you fail to plan, plan to fail.

Re: FT u-boot shim

[Tom Rini]

On Sat, Apr 29, 2006 at 02:32:32AM +0200, Wolfgang Denk wrote:
> In message <20060428232211.GE458@smtp.west.cox.net> you wrote:
> >
> > You wouldn't have the dtb combined in the kernel image, unless you have
> > the shim.   This is instead of loading a separate dtb anyhow.
> 
> Now you got me completely confused. [Maybe I should go to bed.]
> 
> Kumar wrote:
> 
> > What I envision as the way one boots for something like u-boot is one  
> > of three options:
> > 1. using an old u-boot + boot wrapper (bd_t -> wrapper -> kernel)
> > 2. using a u-boot that is ft aware + dtb (boot command in u-boot  
> > takes kernel & dtb images, updates blob and passes to kernel)
> > 3. using a u-boot that is ft aware + built in dtb.
> 
> In my understanding, 1. is with a shim; 2. is loading a separate  dtb
> (probably  as  multi-file  image), and 3. is when U-Boot provides the
> dtb. Am I missing something?

I'm suggesting that we make 2 easier.  U-Boot needs the file mkuimage'd
anyways.  Why not make it easier and make adding the dtb part of that
step instead of a seperate load?  It's still quite easy to replace if
you're testing new dtb's out.

-- 
Tom Rini
http://gate.crashing.org/~trini/

Re: FT u-boot shim

[Wolfgang Denk]

In message <20060429005231.GH458@smtp.west.cox.net> you wrote:
>
> > In my understanding, 1. is with a shim; 2. is loading a separate  dtb
> > (probably  as  multi-file  image), and 3. is when U-Boot provides the
> > dtb. Am I missing something?
> 
> I'm suggesting that we make 2 easier.  U-Boot needs the file mkuimage'd
> anyways.  Why not make it easier and make adding the dtb part of that
> step instead of a seperate load?  It's still quite easy to replace if
> you're testing new dtb's out.

But that's what I'm trying to  tell  you  all  the  time.  An  U-Boot
multi-file  image is a single file (=no separate load) which combines
several files (similar to a  tarball),  here  the  kernel  +  dtb  (+
eventually ramdisk).

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Shakespeare's Law of Prototyping: (Hamlet III, iv, 156-160)
        O, throw away the worser part of it,
        And live the purer with the other half.

Re: FT u-boot shim

[Kumar Gala]

On Apr 29, 2006, at 3:37 AM, Wolfgang Denk wrote:

> In message <20060429005231.GH458@smtp.west.cox.net> you wrote:
>>
>>> In my understanding, 1. is with a shim; 2. is loading a separate   
>>> dtb
>>> (probably  as  multi-file  image), and 3. is when U-Boot provides  
>>> the
>>> dtb. Am I missing something?
>>
>> I'm suggesting that we make 2 easier.  U-Boot needs the file  
>> mkuimage'd
>> anyways.  Why not make it easier and make adding the dtb part of that
>> step instead of a seperate load?  It's still quite easy to replace if
>> you're testing new dtb's out.
>
> But that's what I'm trying to  tell  you  all  the  time.  An  U-Boot
> multi-file  image is a single file (=no separate load) which combines
> several files (similar to a  tarball),  here  the  kernel  +  dtb  (+
> eventually ramdisk).

This was my intent for #2.  You could either provide an explicit  
image or use a multi-file image.  I was going to look at having the  
default build target that we use for uImage create a multi file image  
(kernel & dtb) so the user still only sees one image.

- kumar

Re: FT u-boot shim

[Paul Mackerras]

Wolfgang Denk writes:

> > 2. using a u-boot that is ft aware + dtb (boot command in u-boot  
> > takes kernel & dtb images, updates blob and passes to kernel)
> > 3. using a u-boot that is ft aware + built in dtb.
> > 
> > The issue is that for a given system/board you may need to support  
> > multiple or all three.  This raises the question where does the .dts  
> 
> Assuming we had 2., under which circumstances would we need 3. then?

I imagine 3. would be more convenient for users than 2., or at least
it would seem to mean less typing for them.

Paul.

Re: FT u-boot shim

[Wolfgang Denk]

In message <17490.42678.793678.267072@cargo.ozlabs.ibm.com> you wrote:
>
> > > 2. using a u-boot that is ft aware + dtb (boot command in u-boot  
> > > takes kernel & dtb images, updates blob and passes to kernel)
> > > 3. using a u-boot that is ft aware + built in dtb.
...
> I imagine 3. would be more convenient for users than 2., or at least
> it would seem to mean less typing for them.

This is not necessarily the case. We discussed that kernel & dtb
could be combined in what U-Boot calls a single "multi-file image".
>From the user's point of view there would be no difference to the
current state: he has to deal with a single image file, and needs
only it's start address in emory as argument to the "bootm" command.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Cleverness and Style have no place in getting a project completed.
                                                  -- Tom Christiansen

Re: FT u-boot shim

[Tom Rini]

On Fri, Apr 28, 2006 at 11:01:20AM -0500, Kumar Gala wrote:

> However, I really hate introducing some third project that is  
> required.  If we decide to pull ALL of boot wrappers out of the  
> kernel tree than I'd be ok with it.  But until that time I think this  
> lives under arch/powerpc/boot/...

The more I think about this, and hear about what some vendors do,
pulling arch/p*pc/boot/ out of the kernel is making more and more sense.
Especially with the serial headache, a depends-on-nothing,
can-translate-$(firmware information) tool might be best.

> What I envision as the way one boots for something like u-boot is one  
> of three options:
> 1. using an old u-boot + boot wrapper (bd_t -> wrapper -> kernel)
> 2. using a u-boot that is ft aware + dtb (boot command in u-boot  
> takes kernel & dtb images, updates blob and passes to kernel)
> 3. using a u-boot that is ft aware + built in dtb.

And more generally:
1. using an old firmware + kernel boot wrapper (firmware->dtb converter)
boots kernel.
2. using a dtb-aware firmware boots kernel (compressed or not) and
passes dtb in.

> The issue is that for a given system/board you may need to support  
> multiple or all three.  This raises the question where does the .dts  
> live.  For the time being I say it lives in the boot wrapper part of  
> the kernel tree.  Thus we handle the three cases as follows:

We could stick it in the seprate kernel boot wrapper project.  But I
really think this really has to live in two places.  The kernel should
be The Owner, as until *BSD or something adopts this, it's a
Linux-specific thing.  But any firmware that wishes to skip the kernel
boot wrapper and be a direct kernel booter, will need to own a copy.

-- 
Tom Rini
http://gate.crashing.org/~trini/