85xx FDT updates?

85xx FDT updates?

[Jon Loeliger]

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.

Thanks,
jdl

Re: 85xx FDT updates?

[Vitaly Bordug]

On Mon, 24 Apr 2006 12:41:56 -0500
Jon Loeliger <jdl@freescale.com> 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.
> 

That's my understanding. We agreed to have the CPM dts that is limited to "devices" only,
(scc, fcc or ucc) inside it. 

Right now I am in process of update the drivers part (yet keeping compatibility with existing ppc stuff, that is tricky), then I am going to rework immap stuff a bit to utilize the parts that are common across the PQ family, and go ahead with some CPM(2) code to powerpc.

> 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 _______.
> 
Well, as already mentioned, the CPM2-related drivers the way they are could not be utilized in powerpc 
sane way. Thankfully, the update is 90% ready right now.

> 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.
> 
> Thanks,
> jdl
> 
> 
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
> 
> 


-- 
Sincerely, 
Vitaly

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?

[Dan Malek]

On Apr 24, 2006, at 5:43 PM, Kumar Gala wrote:

> 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.

What about systems that can't update u-boot, but want to run
a newer kernel?


	-- Dan

Re: 85xx FDT updates?

[Kumar Gala]

On Apr 24, 2006, at 5:31 PM, Dan Malek wrote:

>
> On Apr 24, 2006, at 5:43 PM, Kumar Gala wrote:
>
>> 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.
>
> What about systems that can't update u-boot, but want to run
> a newer kernel?

Does this situation exist for any in tree boards that are supported?

- kumar

Re: 85xx FDT updates?

[Eugene Surovegin]

On Tue, Apr 25, 2006 at 01:08:00AM -0500, Kumar Gala wrote:
> 
> On Apr 24, 2006, at 5:31 PM, Dan Malek wrote:
> 
> >
> > On Apr 24, 2006, at 5:43 PM, Kumar Gala wrote:
> >
> >> 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.
> >
> > What about systems that can't update u-boot, but want to run
> > a newer kernel?
> 
> Does this situation exist for any in tree boards that are supported?

Kumar, with all due respect, I don't like this attitude. I can have 
eval board where I don't want to upgrade firmware.

Also, this "let's screw everybody who doesn't have their board support 
in tree" is very counter productive. FYI, almost all my contributed 
kernel work was done on custom hardware, not on reference boards.

It seems some people here lost touch with reality - embedded Linux is 
mostly run on custom hardware, not on evaluation boards.

-- 
Eugene

Re: 85xx FDT updates?

[Kumar Gala]

On Apr 25, 2006, at 2:49 AM, Eugene Surovegin wrote:

> On Tue, Apr 25, 2006 at 01:08:00AM -0500, Kumar Gala wrote:
>>
>> On Apr 24, 2006, at 5:31 PM, Dan Malek wrote:
>>
>>>
>>> On Apr 24, 2006, at 5:43 PM, Kumar Gala wrote:
>>>
>>>> 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.
>>>
>>> What about systems that can't update u-boot, but want to run
>>> a newer kernel?
>>
>> Does this situation exist for any in tree boards that are supported?
>
> Kumar, with all due respect, I don't like this attitude. I can have
> eval board where I don't want to upgrade firmware.
>
> Also, this "let's screw everybody who doesn't have their board support
> in tree" is very counter productive. FYI, almost all my contributed
> kernel work was done on custom hardware, not on reference boards.
>
> It seems some people here lost touch with reality - embedded Linux is
> mostly run on custom hardware, not on evaluation boards.

Well, first all I said was that we shouldn't remove arch/ppc support  
until the u-boot patches are in.  I made no statement about when  
after that we should remove arch/ppc support.

Second, this seems normal like normal kernel development to me.  I  
think its reasonable to pick some time frame after which we will  
remove the support and to let everyone know what that is.  I see this  
as no different than having a driver outside of the kernel tree and  
having it break when APIs change.

- kumar

Re: 85xx FDT updates?

[Eugene Surovegin]

On Tue, Apr 25, 2006 at 09:05:54AM -0500, Kumar Gala wrote:
> 
> Second, this seems normal like normal kernel development to me.  I  
> think its reasonable to pick some time frame after which we will  
> remove the support and to let everyone know what that is.  I see this  
> as no different than having a driver outside of the kernel tree and  
> having it break when APIs change.

I don't agree. This is not the same as changing _internal_ kernel API 
for a simple reason that _firmware_ was never part of the kernel and 
will never be. You seem to have an idea that's that's OK to _remove_ 
existing functionality from the kernel for no reason except your 
convenience. I think this is unacceptable. If kernel was able to boot 
on some hardware (including reference one) in the past it should be 
able to do this now even if this will require some boot shim.

-- 
Eugene

Re: 85xx FDT updates?

[Kumar Gala]

On Apr 25, 2006, at 11:12 AM, Eugene Surovegin wrote:

> On Tue, Apr 25, 2006 at 09:05:54AM -0500, Kumar Gala wrote:
>>
>> Second, this seems normal like normal kernel development to me.  I
>> think its reasonable to pick some time frame after which we will
>> remove the support and to let everyone know what that is.  I see this
>> as no different than having a driver outside of the kernel tree and
>> having it break when APIs change.
>
> I don't agree. This is not the same as changing _internal_ kernel API
> for a simple reason that _firmware_ was never part of the kernel and
> will never be. You seem to have an idea that's that's OK to _remove_
> existing functionality from the kernel for no reason except your
> convenience. I think this is unacceptable. If kernel was able to boot
> on some hardware (including reference one) in the past it should be
> able to do this now even if this will require some boot shim.

If we are talking about a reference board than I think this is an  
absurd requirement.  If you are willing to update your kernel on such  
a board why would you not be willing to update the firmware as well.

To my knowledge all the in tree boards that are supported for 85xx  
all boot via u-boot.  So if u-boot is available for the given board  
that is capable of booting an arch/powerpc kernel why would we need  
to continue supporting the board in arch/ppc.

- kumar 

Re: 85xx FDT updates?

[Eugene Surovegin]

On Tue, Apr 25, 2006 at 11:25:59AM -0500, Kumar Gala wrote:
> If we are talking about a reference board than I think this is an  
> absurd requirement.  If you are willing to update your kernel on such  
> a board why would you not be willing to update the firmware as well.

1) I don't have JTAG
2) I don't trust new U-Boot version
3) I want to be able to boot old kernels

What you are proposing is more like saying - we changed kernel 
user-space API, old applications aren't supported anymore, get the new 
libc and rebuild them all. For some reason we don't intentionally do 
this, I wonder why.

-- 
Eugene

Re: 85xx FDT updates?

[Dan Malek]

On Apr 25, 2006, at 3:49 AM, Eugene Surovegin wrote:

> It seems some people here lost touch with reality - embedded Linux is
> mostly run on custom hardware, not on evaluation boards.

This is the reason I usually mention such things.  While we all
want to see the new features, we have to be sensitive to the
real world product deployment of Linux.  While your world
may be a few evaluation boards that allow you to update
software many times a day, the real world products can't
afford to do that.  From my own experience, I can tell you
that none of the deployed systems I've worked on will
ever update U-Boot.  They consider this a sacred piece of
software such that is all else fails they can recover a
system remotely using U-Boot commands.  They won't
risk updating U-Boot in case it fails.  Making Linux dependent
on a particular, updated, version of U-Boot just isn't going
to work in most deployed systems.  Or worse, making
Linux dependent on U-Boot isn't necessarily popular
either.  For various reasons, especially when replacing
legacy software, some custom boot rom is often the
only choice.

Thanks.


	-- Dan

Re: 85xx FDT updates?

[Kumar Gala]

On Apr 25, 2006, at 11:31 AM, Eugene Surovegin wrote:

> On Tue, Apr 25, 2006 at 11:25:59AM -0500, Kumar Gala wrote:
>> If we are talking about a reference board than I think this is an
>> absurd requirement.  If you are willing to update your kernel on such
>> a board why would you not be willing to update the firmware as well.
>
> 1) I don't have JTAG
> 2) I don't trust new U-Boot version
> 3) I want to be able to boot old kernels
>
> What you are proposing is more like saying - we changed kernel
> user-space API, old applications aren't supported anymore, get the new
> libc and rebuild them all. For some reason we don't intentionally do
> this, I wonder why.

I dont think this is like the user-space API at all.  The binding  
between kernel and u-boot is actually pretty tight.  For certain  
config options you have to ensure that u-boot and the kernel agree  
(for example CONFIG_CPM2).

If you dont trust the new u-boot I dont know why you would trust the  
new kernel anymore.  Also, I find it difficult to believe people  
would not be willing to update a u-boot to get any bug or performance  
tweaks that might exist after the initial release that came on their  
board.

You can boot old kernels with the new u-boot if you want to.

- kumar

Re: 85xx FDT updates?

[Kumar Gala]

On Apr 25, 2006, at 11:49 AM, Dan Malek wrote:

>
> On Apr 25, 2006, at 3:49 AM, Eugene Surovegin wrote:
>
>> It seems some people here lost touch with reality - embedded Linux is
>> mostly run on custom hardware, not on evaluation boards.
>
> This is the reason I usually mention such things.  While we all
> want to see the new features, we have to be sensitive to the
> real world product deployment of Linux.  While your world
> may be a few evaluation boards that allow you to update
> software many times a day, the real world products can't
> afford to do that.  From my own experience, I can tell you
> that none of the deployed systems I've worked on will
> ever update U-Boot.  They consider this a sacred piece of
> software such that is all else fails they can recover a
> system remotely using U-Boot commands.  They won't
> risk updating U-Boot in case it fails.  Making Linux dependent
> on a particular, updated, version of U-Boot just isn't going
> to work in most deployed systems.  Or worse, making
> Linux dependent on U-Boot isn't necessarily popular
> either.  For various reasons, especially when replacing
> legacy software, some custom boot rom is often the
> only choice.

I understand this, however these systems are not in the kernel tree  
and thus we can only do so much for them.  I agree a shim between a  
non-flat dev tree aware u-boot and kernel would be a good thing.   
However, I don't see that as something I have to produce as a board  
maintainer if I can give you and updated u-boot to use.

- kumar

Re: 85xx FDT updates?

[Eugene Surovegin]

On Tue, Apr 25, 2006 at 11:55:49AM -0500, Kumar Gala wrote:
> 
> On Apr 25, 2006, at 11:49 AM, Dan Malek wrote:
> 
> >
> >On Apr 25, 2006, at 3:49 AM, Eugene Surovegin wrote:
> >
> >>It seems some people here lost touch with reality - embedded Linux is
> >>mostly run on custom hardware, not on evaluation boards.
> >
> >This is the reason I usually mention such things.  While we all
> >want to see the new features, we have to be sensitive to the
> >real world product deployment of Linux.  While your world
> >may be a few evaluation boards that allow you to update
> >software many times a day, the real world products can't
> >afford to do that.  From my own experience, I can tell you
> >that none of the deployed systems I've worked on will
> >ever update U-Boot.  They consider this a sacred piece of
> >software such that is all else fails they can recover a
> >system remotely using U-Boot commands.  They won't
> >risk updating U-Boot in case it fails.  Making Linux dependent
> >on a particular, updated, version of U-Boot just isn't going
> >to work in most deployed systems.  Or worse, making
> >Linux dependent on U-Boot isn't necessarily popular
> >either.  For various reasons, especially when replacing
> >legacy software, some custom boot rom is often the
> >only choice.
> 
> I understand this, however these systems are not in the kernel tree  
> and thus we can only do so much for them.  I agree a shim between a  
> non-flat dev tree aware u-boot and kernel would be a good thing.   
> However, I don't see that as something I have to produce as a board  
> maintainer if I can give you and updated u-boot to use.

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.

-- 
Eugene

Re: 85xx FDT updates?

[Kumar Gala]

On Apr 25, 2006, at 12:08 PM, Eugene Surovegin wrote:

> On Tue, Apr 25, 2006 at 11:55:49AM -0500, Kumar Gala wrote:
>>
>> On Apr 25, 2006, at 11:49 AM, Dan Malek wrote:
>>
>>>
>>> On Apr 25, 2006, at 3:49 AM, Eugene Surovegin wrote:
>>>
>>>> It seems some people here lost touch with reality - embedded  
>>>> Linux is
>>>> mostly run on custom hardware, not on evaluation boards.
>>>
>>> This is the reason I usually mention such things.  While we all
>>> want to see the new features, we have to be sensitive to the
>>> real world product deployment of Linux.  While your world
>>> may be a few evaluation boards that allow you to update
>>> software many times a day, the real world products can't
>>> afford to do that.  From my own experience, I can tell you
>>> that none of the deployed systems I've worked on will
>>> ever update U-Boot.  They consider this a sacred piece of
>>> software such that is all else fails they can recover a
>>> system remotely using U-Boot commands.  They won't
>>> risk updating U-Boot in case it fails.  Making Linux dependent
>>> on a particular, updated, version of U-Boot just isn't going
>>> to work in most deployed systems.  Or worse, making
>>> Linux dependent on U-Boot isn't necessarily popular
>>> either.  For various reasons, especially when replacing
>>> legacy software, some custom boot rom is often the
>>> only choice.
>>
>> I understand this, however these systems are not in the kernel tree
>> and thus we can only do so much for them.  I agree a shim between a
>> non-flat dev tree aware u-boot and kernel would be a good thing.
>> However, I don't see that as something I have to produce as a board
>> maintainer if I can give you and updated u-boot to use.
>
> 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.  What happens when Freescale finds an errata  
that requires a new firmware image?

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.

- kumar

Re: 85xx FDT updates?

[Eugene Surovegin]

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.

> 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).

> 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. 

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 :).

-- 
Eugene

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:24 PM, 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'm not talking about all embedded PPC boards.  I'm taking about the  
subset that exists for 85xx.  Also, its moving forward as the  
standard way of booting future systems.

>> 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.

And how do you suggest we do this?  My argument is for the boards I'm  
talking about updating u-boot is the easiest and most straight  
forward solution.  I'm not advocating this at the right solution for  
all boards.

- kumar

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:29:34PM -0500, 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.

Yes. This was suggested numerous number of times. Kumar, for some 
reason which I don't understand, keeps ignoring this.

And yes, I think person who breaks compatibility is the one who should 
be doing this work :).

-- 

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

Re: 85xx FDT updates?

[Andy Fleming]

On Apr 25, 2006, at 13:48, Eugene Surovegin wrote:

> On Tue, Apr 25, 2006 at 01:29:34PM -0500, Brent Cook wrote:
>>> ....

>>> 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.
>
> Yes. This was suggested numerous number of times. Kumar, for some
> reason which I don't understand, keeps ignoring this.
>
> And yes, I think person who breaks compatibility is the one who should
> be doing this work :).

I think there's some confusion here (at least, I'm confused), so let  
me see if I have this right:

1) Kumar is advocating the eventual removal of support for booting  
the 85xx CDS and 85xx ADS boards without a flat-device tree

2) Eugene and Dan say this will break systems that are already deployed

3) Kumar says that the 85xx CDS and ADS systems are reference  
platforms, and therefore not meant for deployment.

4) Eugene implies that removal of 85xx CDS and ADS support from arch/ 
ppc should be accompanied by some sort of compatibility options for  
booting arch/powerpc Linux from an old u-boot

Do I have this right?

Oh, and 5) Kumar implies that anyone who buys a repackaged CDS system  
is a sucker, and should be parted from his or her money with all  
possible speed.  :)


Andy Fleming

Re: 85xx FDT updates?

[Kumar Gala]

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

> 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.

If I break compatibility for boards I maintain I don't see the issue  
as long as I provide a workable solution.

- kumar

Re: 85xx FDT updates?

[Kumar Gala]

On Apr 25, 2006, at 2:14 PM, Andy Fleming wrote:

>
> On Apr 25, 2006, at 13:48, Eugene Surovegin wrote:
>
>> On Tue, Apr 25, 2006 at 01:29:34PM -0500, Brent Cook wrote:
>>>> ....
>
>>>> 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.
>>
>> Yes. This was suggested numerous number of times. Kumar, for some
>> reason which I don't understand, keeps ignoring this.
>>
>> And yes, I think person who breaks compatibility is the one who  
>> should
>> be doing this work :).
>
> I think there's some confusion here (at least, I'm confused), so let
> me see if I have this right:
>
> 1) Kumar is advocating the eventual removal of support for booting
> the 85xx CDS and 85xx ADS boards without a flat-device tree
>
> 2) Eugene and Dan say this will break systems that are already  
> deployed
>
> 3) Kumar says that the 85xx CDS and ADS systems are reference
> platforms, and therefore not meant for deployment.

I'd say production instead of deployment.

> 4) Eugene implies that removal of 85xx CDS and ADS support from arch/
> ppc should be accompanied by some sort of compatibility options for
> booting arch/powerpc Linux from an old u-boot
>
> Do I have this right?
>
> Oh, and 5) Kumar implies that anyone who buys a repackaged CDS system
> is a sucker, and should be parted from his or her money with all
> possible speed.  :)

(as a production system).

I think everything else is correct.

- kumar

Re: 85xx FDT updates?

[Eugene Surovegin]

On Tue, Apr 25, 2006 at 02:14:28PM -0500, Andy Fleming wrote:
> I think there's some confusion here (at least, I'm confused), so let  
> me see if I have this right:
> 
> 1) Kumar is advocating the eventual removal of support for booting  
> the 85xx CDS and 85xx ADS boards without a flat-device tree
> 
> 2) Eugene and Dan say this will break systems that are already deployed
> 
> 3) Kumar says that the 85xx CDS and ADS systems are reference  
> platforms, and therefore not meant for deployment.
> 
> 4) Eugene implies that removal of 85xx CDS and ADS support from arch/ 
> ppc should be accompanied by some sort of compatibility options for  
> booting arch/powerpc Linux from an old u-boot
> 
> Do I have this right?

Yes :)

-- 
Eugene

Re: 85xx FDT updates?

[Eugene Surovegin]

On Tue, Apr 25, 2006 at 02:20:03PM -0500, Kumar Gala wrote:
> 
> On Apr 25, 2006, at 1:53 PM, Eugene Surovegin wrote:
> 
> >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.
> 
> If I break compatibility for boards I maintain I don't see the issue  
> as long as I provide a workable solution.

Sorry, but IMO saying you have to upgrade firmware is not a workable 
solution.

Firmware <-> kernel is external interface. Kernel shouldn't break it 
unless there is a good technical reason to do so. Developer 
convenience or lack of time is not a good technical reason in my book.

-- 
Eugene

Re: 85xx FDT updates?

[Kumar Gala]

On Apr 25, 2006, at 2:31 PM, Eugene Surovegin wrote:

> On Tue, Apr 25, 2006 at 02:20:03PM -0500, Kumar Gala wrote:
>>
>> On Apr 25, 2006, at 1:53 PM, Eugene Surovegin wrote:
>>
>>> 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.
>>
>> If I break compatibility for boards I maintain I don't see the issue
>> as long as I provide a workable solution.
>
> Sorry, but IMO saying you have to upgrade firmware is not a workable
> solution.

I disagree.  I think its completely reasonable to deprecate the  
interface and require people to upgrade over some give time period.

> Firmware <-> kernel is external interface. Kernel shouldn't break it
> unless there is a good technical reason to do so. Developer
> convenience or lack of time is not a good technical reason in my book.

I dont see it as breaking the interface.  I see it as deprecation of  
the current interface.

- kumar

Re: 85xx FDT updates?

[Andy Fleming]

On Apr 25, 2006, at 14:27, Eugene Surovegin wrote:

> On Tue, Apr 25, 2006 at 02:14:28PM -0500, Andy Fleming wrote:
>> I think there's some confusion here (at least, I'm confused), so let
>> me see if I have this right:
>>
>> 1) Kumar is advocating the eventual removal of support for booting
>> the 85xx CDS and 85xx ADS boards without a flat-device tree
>>
>> 2) Eugene and Dan say this will break systems that are already  
>> deployed
>>
>> 3) Kumar says that the 85xx CDS and ADS systems are reference
>> platforms, and therefore not meant for deployment.
>>
>> 4) Eugene implies that removal of 85xx CDS and ADS support from arch/
>> ppc should be accompanied by some sort of compatibility options for
>> booting arch/powerpc Linux from an old u-boot
>>
>> Do I have this right?
>
> Yes :)


Well, let's discuss this hypothetical shim layer.  It's fairly  
straightforward to incorporate a device tree into the kernel, and  
hook it up.  The only issue is the elements of the flat device tree  
which are dynamic.  All of this information is passed in the bd_t or  
the command line arguments, though, so it should be possible to hook  
them up.

Would it be acceptable to require a new command-line argument (I'm  
thinking specifically of the stdout device path, normally passed in  
the "chosen" node of the oftree) to be passed in the bootargs?  Or is  
u-boot absolutely unupdateable on these swiftly-aging systems?

Andy

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: 85xx FDT updates?

[Eugene Surovegin]

On Tue, Apr 25, 2006 at 02:58:34PM -0500, Andy Fleming wrote:
> Well, let's discuss this hypothetical shim layer.  It's fairly  
> straightforward to incorporate a device tree into the kernel, and  
> hook it up.  The only issue is the elements of the flat device tree  
> which are dynamic.  All of this information is passed in the bd_t or  
> the command line arguments, though, so it should be possible to hook  
> them up.
> 
> Would it be acceptable to require a new command-line argument (I'm  
> thinking specifically of the stdout device path, normally passed in  
> the "chosen" node of the oftree) to be passed in the bootargs?  Or is  
> u-boot absolutely unupdateable on these swiftly-aging systems?

Andy, I think we have to try to not making any changes to the way old 
U-Boot operates, including adding additional boot args. It doesn't 
matter _how_ information is passed between firmware and kernel (in 
bd_t or command line), the moment we add additional requirement 
which never existed before - we break this interface.

-- 
Eugene

Re: 85xx FDT updates?

[Wolfgang Denk]

In message <34C11E8A-ED04-490F-B601-841DC1F94AD6@kernel.crashing.org> you wrote:
> 
> > What about systems that can't update u-boot, but want to run
> > a newer kernel?
> 
> Does this situation exist for any in tree boards that are supported?

Probably. We don't know what our users do. Not so few of the projects
run a policy on never touching 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
The only way to get rid of a temptation is to yield to it.
                                                        - Oscar Wilde

Re: 85xx FDT updates?

[Wolfgang Denk]

In message <6F7CAB43-B4C0-47DA-BC7D-3FD04A552131@kernel.crashing.org> you wrote:
> 
> If we are talking about a reference board than I think this is an  
> absurd requirement.  If you are willing to update your kernel on such  
> a board why would you not be willing to update the firmware as well.

For example, because I don't own it and have  to  return  it  in  the
original state.

For example, because U-Boot is in a ROM which cannot  be  written  to
without special tools.

Kumar, please try seeing the world from the eyes of a *user*, not the
developer you and me are.

We should help the users, not make their live harder than necessary.

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 believe that feeling bad or worrying long enough will change a
past or future event, then you are residing on another planet with  a
different reality system.

Re: 85xx FDT updates?

[Kumar Gala]

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

> In message <6F7CAB43-B4C0-47DA- 
> BC7D-3FD04A552131@kernel.crashing.org> you wrote:
>>
>> If we are talking about a reference board than I think this is an
>> absurd requirement.  If you are willing to update your kernel on such
>> a board why would you not be willing to update the firmware as well.
>
> For example, because I don't own it and have  to  return  it  in  the
> original state.
>
> For example, because U-Boot is in a ROM which cannot  be  written  to
> without special tools.
>
> Kumar, please try seeing the world from the eyes of a *user*, not the
> developer you and me are.
>
> We should help the users, not make their live harder than necessary.

Which users are you speaking of, end users or developers that will  
use u-boot & linux for building a product?

- kumar

Re: 85xx FDT updates?

[Wolfgang Denk]

In message <265F73F8-F641-4EDD-B88F-A2B2F7FA1308@kernel.crashing.org> you wrote:
> 
> 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  

The same is true.  Please listen.

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 one can guarantee the actions of another.
	-- Spock, "Day of the Dove", stardate unknown

Re: 85xx FDT updates?

[Wolfgang Denk]

In message <E29663C3-8289-443F-BF7A-F973EC41CC72@kernel.crashing.org> you wrote:
> 
> I'm not talking about all embedded PPC boards.  I'm taking about the  
> subset that exists for 85xx.  Also, its moving forward as the  

What's the difference?

> And how do you suggest we do this?  My argument is for the boards I'm  
> talking about updating u-boot is the easiest and most straight  
> forward solution.  I'm not advocating this at the right solution for  

It may be easiest for you, not for others. 

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
As far as we know, our computer has never had an undetected error.
		                                           -- Weisert

Re: 85xx FDT updates?

[Wolfgang Denk]

In message <20060425184857.GB1132@gate.ebshome.net> you wrote:
>
> Yes. This was suggested numerous number of times. Kumar, for some 
> reason which I don't understand, keeps ignoring this.
> 
> And yes, I think person who breaks compatibility is the one who should 
> be doing this work :).

Agreed. No smiley here.

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
 The software required `Windows 95 or better', so I installed Linux.

Re: 85xx FDT updates?

[Wolfgang Denk]

In message <FB3CC275-6C15-414C-A1F2-F1A13E3E1279@freescale.com> you wrote:
> 
> Would it be acceptable to require a new command-line argument (I'm  
> thinking specifically of the stdout device path, normally passed in  
> the "chosen" node of the oftree) to be passed in the bootargs?  Or is  
> u-boot absolutely unupdateable on these swiftly-aging systems?

Command line options  can  be  set  as  part  of  U-Boot  environment
variables. These are freely changable. No update needed.

Yes, thius would be possible.

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
...when fits of creativity run strong, more than  one  programmer  or
writer  has  been  known to abandon the desktop for the more spacious
floor.                                             - Fred Brooks, Jr.

Re: 85xx FDT updates?

[Kumar Gala]

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

> In message <265F73F8-F641-4EDD-B88F- 
> A2B2F7FA1308@kernel.crashing.org> you wrote:
>>
>> 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
>
> The same is true.  Please listen.

I'm listening, I just dont agree.  I see reference boards used by  
developers who will end up building a custom board.  I'm happy to be  
enlightened if people are using reference boards for some other  
purpose (beyond evaluation of the processor).

- 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: 85xx FDT updates?

[Kumar Gala]

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

> In message <E29663C3-8289-443F-BF7A- 
> F973EC41CC72@kernel.crashing.org> you wrote:
>>
>> I'm not talking about all embedded PPC boards.  I'm taking about the
>> subset that exists for 85xx.  Also, its moving forward as the
>
> What's the difference?

The difference is that I'm only prescribing my views for a specific  
subset of HW.

>
>> And how do you suggest we do this?  My argument is for the boards I'm
>> talking about updating u-boot is the easiest and most straight
>> forward solution.  I'm not advocating this at the right solution for
>
> It may be easiest for you, not for others.

Are we talking about other users of a board I maintain or for other  
maintaining a different board?

- kumar

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

[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: 85xx FDT updates?

[Wolfgang Denk]

In message <07032FB1-0607-4862-815A-C817C7222FF5@kernel.crashing.org> you wrote:
> 
> Which users are you speaking of, end users or developers that will  
> use u-boot & linux for building a product?

Users that try to get some application running on some hardware; they
might be interested to compare different kernel  versions,  but  they
probably  have  no interest (or are not capable or allowed) to change
U-Boot. I'm not sure if this is what you call "end users" - they  are
software engineers, too, but work in a different department.

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
Gewöhnlich glaubt der Mensch,  wenn er nur Worte hört,  es müsse sich
dabei doch auch was denken lassen.                 -- Goethe, Faust I

Re: 85xx FDT updates?

[Wolfgang Denk]

In message <4BCCDE94-8A82-41C4-B4F9-F111E761F926@kernel.crashing.org> you wrote:
> 
> I'm listening, I just dont agree.  I see reference boards used by  
> developers who will end up building a custom board.  I'm happy to be  
> enlightened if people are using reference boards for some other  
> purpose (beyond evaluation of the processor).

Some do. Some use them in products.

Others (and not a small number)  use  them  for  testing  application
code. In your definition these are probably "end users", too.

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
You can only live once, but if you do it right, once is enough.

Re: 85xx FDT updates?

[Kumar Gala]

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

> In message <4BCCDE94-8A82-41C4-B4F9- 
> F111E761F926@kernel.crashing.org> you wrote:
>>
>> I'm listening, I just dont agree.  I see reference boards used by
>> developers who will end up building a custom board.  I'm happy to be
>> enlightened if people are using reference boards for some other
>> purpose (beyond evaluation of the processor).
>
> Some do. Some use them in products.

Can you give a concrete example of this.

> Others (and not a small number)  use  them  for  testing  application
> code. In your definition these are probably "end users", too.

Then they can use the kernel the board comes with.

- kumar

Re: 85xx FDT updates?

[Wolfgang Denk]

In message <719F1078-8AFB-48A8-9FB7-4128354F7774@kernel.crashing.org> you wrote:
> 
> >> I'm not talking about all embedded PPC boards.  I'm taking about the
> >> subset that exists for 85xx.  Also, its moving forward as the
> >
> > What's the difference?
> 
> The difference is that I'm only prescribing my views for a specific  
> subset of HW.

To me it makes things not better that just a certain group of  boards
is affected.

> Are we talking about other users of a board I maintain or for other  
> maintaining a different board?

I'm talking about users of any board. Yes, this includes  the  boards
you maintain.

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
Crash programs fail because they are based on the theory  that,  with
nine women pregnant, you can get a baby a month.  - Wernher von Braun

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

[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: 85xx FDT updates?

[Wolfgang Denk]

In message <D6F58AA4-54EA-44BF-A0B7-83397B115B27@kernel.crashing.org> you wrote:
> 
> > Some do. Some use them in products.
> 
> Can you give a concrete example of this.

No, I cannot. Not in public.

> > Others (and not a small number)  use  them  for  testing  application
> > code. In your definition these are probably "end users", too.
> 
> Then they can use the kernel the board comes with.

No, they cannot. Running different  kernel  versions  (including  old
ones,  eventually even 2.4) may be the key issue of their tests. Note
that this is something which does not require any modification to the
board - I can just TFTP the kernel image and boot it.

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
Weekends were made for programming.                 - Karl Lehenbauer

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: 85xx FDT updates?

[Dan Malek]

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

> Others (and not a small number)  use  them  for  testing  application
> code. In your definition these are probably "end users", too.

I'm surprised by how much of this I see as well.  People will
buy various evaluation boards for the purposes of evaluation
(imagine that :-)).  They will try different kernel versions, write
some test applications, before making a choice of what
processor and tools to purchase.  Only after that point will
they likely have some debugger capability that will allow
them to update flash parts.  Based on this behavior, it's not
good to assume that just because someone has an eval
board they have the ability to update the flash on it.  A failed
flash update and the inability to recover is a good way to
ensure the board/processor is not chosen for a product :-)

Thanks.

	-- Dan

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

[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

[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

[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 <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: [U-Boot-Users] Re: FT u-boot shim

[Kumar Gala]

[snip]

> 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.

I believe this is already supported in u-boot as a config option.   
You can also pass the bd_t to the kernel via the flat dev tree if you  
want.

- kumar

Re: [U-Boot-Users] Re: FT u-boot shim

[Wolfgang Denk]

In message <44511C88.1010107@smiths-aerospace.com> you wrote:
> 
> 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 

If somebody wants to read the environment variables, you  don't  need
to create a flat tree from it.

Also, it doesn't solve the original problem as most of  the  informa-
tion  you  need to pass is NOT part of the environment (and shall not
become such a part).


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
I thought my people would grow tired of killing. But you were  right,
they  see it is easier than trading. And it has its pleasures. I feel
it myself. Like the hunt, but with richer rewards.
	-- Apella, "A Private Little War", stardate 4211.8

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: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]

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

[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: [U-Boot-Users] Re: FT u-boot shim

[Jerry Van Baren]

Wolfgang Denk wrote:
> In message <44511C88.1010107@smiths-aerospace.com> you wrote:
>> 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 
> 
> If somebody wants to read the environment variables, you  don't  need
> to create a flat tree from it.

Understood.  That is why it is Really Cool[tm] rather than Really 
Useful[tm] ;-)

> Also, it doesn't solve the original problem as most of  the  informa-
> tion  you  need to pass is NOT part of the environment (and shall not
> become such a part).
> 
> Best regards,
> Wolfgang Denk

I agree and disagree with the parenthetical part of your statement. 
Agree because it _wouldn't_ be a part of u-boot (technically it would be 
if someone put it in their default env for their specific board, but why 
would denx.de care?).

Disagree because, while u-boot needs/uses some env variables, 
engineers/companies/end users are free to add variables and, I dare say, 
most do.  If a given board needs to pass certain non u-boot parameters 
to linux, it would simply add that to its env (which already happens).

I'm not sure you (Wolfgang and Kumar) are following my thought fully (or 
my ignorance is showing to everybody but me).  The thought is to change 
the native format of the u-boot environment storage from the 
key-string/value-string pairs to the flat tree (OpenFirmware) format 
which still supports the same key-string/value-string capability (but 
can do more than that).

The advantage, as I see it, is that it would be unifying and thus easier 
to maintain the common variables (call it the GRand Unifying Flat Tree 
(GRAFT) ;-).  One language (flat tree), no shims, equivalent key/value 
utility (but a different underlying storage format), no visible 
difference for the users (but potentially an upgrade challenge for 
existing boards and env variables).

The disadvantage is that it would be disruptive to u-boot and may cause 
some bloating and discomfort.

gvb
(the naive)

P.S. For the non-USA readers: "may cause some bloating and discomfort" 
is a standard disclaimer on medicines advertised on TV over here.

Re: [U-Boot-Users] Re: FT u-boot shim

[Pantelis Antoniou]

On Thursday 27 April 2006 23:40, Jerry Van Baren wrote:
> Wolfgang Denk wrote:
> > In message <44511C88.1010107@smiths-aerospace.com> you wrote:
> >> 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 
> > 
> > If somebody wants to read the environment variables, you  don't  need
> > to create a flat tree from it.
> 
> Understood.  That is why it is Really Cool[tm] rather than Really 
> Useful[tm] ;-)
> 
> > Also, it doesn't solve the original problem as most of  the  informa-
> > tion  you  need to pass is NOT part of the environment (and shall not
> > become such a part).
> > 
> > Best regards,
> > Wolfgang Denk
> 
> I agree and disagree with the parenthetical part of your statement. 
> Agree because it _wouldn't_ be a part of u-boot (technically it would be 
> if someone put it in their default env for their specific board, but why 
> would denx.de care?).
> 
> Disagree because, while u-boot needs/uses some env variables, 
> engineers/companies/end users are free to add variables and, I dare say, 
> most do.  If a given board needs to pass certain non u-boot parameters 
> to linux, it would simply add that to its env (which already happens).
> 
> I'm not sure you (Wolfgang and Kumar) are following my thought fully (or 
> my ignorance is showing to everybody but me).  The thought is to change 
> the native format of the u-boot environment storage from the 
> key-string/value-string pairs to the flat tree (OpenFirmware) format 
> which still supports the same key-string/value-string capability (but 
> can do more than that).
> 
> The advantage, as I see it, is that it would be unifying and thus easier 
> to maintain the common variables (call it the GRand Unifying Flat Tree 
> (GRAFT) ;-).  One language (flat tree), no shims, equivalent key/value 
> utility (but a different underlying storage format), no visible 
> difference for the users (but potentially an upgrade challenge for 
> existing boards and env variables).
> 
> The disadvantage is that it would be disruptive to u-boot and may cause 
> some bloating and discomfort.
> 
> gvb
> (the naive)
> 
> P.S. For the non-USA readers: "may cause some bloating and discomfort" 
> is a standard disclaimer on medicines advertised on TV over here.
> 

Since I'm the guy responsible let me weigh in a bit.

For starters, yes it's possible to pass the whole env using the FT tree.
Use CONFIG_OF_HAS_UBOOT_ENV to pass the u-boot env to the FT tree.

As for the rest of the cat-fight, I'm afraid I don't have the energy
to jump in at the moment.

Perhaps tomorrow :)

Regards

Pantelis

> 
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
> 

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: 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: [U-Boot-Users] Re: FT u-boot shim

[Tolunay Orkun]

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?
> 
>> 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>


How would you like to handle the case when dts is packed into 
multi-image file? Is bootm going to assume that the 3rd Image is dts?

Since dts is tightly coupled to kernel I would prefer something like:

bootm <kernel_addr>[:<dts_addr>] <ramdisk_addr>

Best regards,
Tolunay

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

[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/

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

[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

[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