* Re: 85xx FDT updates?
From: Eugene Surovegin @ 2006-04-25 16:31 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org list, Paul Mackerras
In-Reply-To: <6F7CAB43-B4C0-47DA-BC7D-3FD04A552131@kernel.crashing.org>
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
^ permalink raw reply
* Re: 85xx FDT updates?
From: Dan Malek @ 2006-04-25 16:49 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20060425074902.GA20228@gate.ebshome.net>
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
^ permalink raw reply
* Re: 85xx FDT updates?
From: Kumar Gala @ 2006-04-25 16:51 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-dev@ozlabs.org list, Paul Mackerras
In-Reply-To: <20060425163118.GD20228@gate.ebshome.net>
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
^ permalink raw reply
* Re: 85xx FDT updates?
From: Kumar Gala @ 2006-04-25 16:55 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <66B13296-80E8-4C9E-803D-F4E3D7AABB25@embeddedalley.com>
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
^ permalink raw reply
* Re: [PATCH] fix cpm_uart driver for PQ1...
From: Vitaly Bordug @ 2006-04-25 16:57 UTC (permalink / raw)
To: David Jander; +Cc: linuxppc-embedded
In-Reply-To: <200604251155.50781.david.jander@protonic.nl>
David,
Sorry haven't noticed you submit once working on series.
>
> Hi,
>
> This patch fixes the following three problems:
>
> 1. Memory mapping virtual<-->dma is broken in the case that
> CONFIG_CONSISTENT_START > CPM_ADDR.
Due to broken address translation, I used Kenneth work as a base. I'd
appreciate if you take a look/comment (CPM_UART: Fixed odd address
translations). Mostly it did the same as your patch/Kenneth work (so I
think it will be fair enough to put your both signed-off lines in there
as well - just let me know you do not object).
>
> 2. SCC uart sends a break sequence each time it is stopped with the
> CPM_CR_STOP_TX command. That means that each time an application closes the
> serial device, a break is transmitted.
Can you please rebase it with my series applied? I'll submit it as incremental to my series then.
I am maintaining this part, and trying to make it better :).
>
> 3. Implemented default BRG routing for PQ1 (in the same sense as it is done
> for PQ2).
All ioport things are board-specific and should reside in BSP code (I'm pretty sure nobody will object...) - the BSP patch has examples how to do that. Though the legacy behavior it retaining,
I claim it as "no longer supported " and encourage board port owners to do minor changes in board-specific code and have cpm_uart operate on platform-device basis.
>
> Signed-off-by: David Jander
>
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: 85xx FDT updates?
From: Eugene Surovegin @ 2006-04-25 17:08 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <853005AF-8F43-454D-80E6-F39308F89A47@kernel.crashing.org>
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
^ permalink raw reply
* Re: 85xx FDT updates?
From: Kumar Gala @ 2006-04-25 17:39 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20060425170857.GE20228@gate.ebshome.net>
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
^ permalink raw reply
* Re: 85xx FDT updates?
From: Eugene Surovegin @ 2006-04-25 18:01 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <BEC38EF6-326E-4ED1-8F02-4A3FA928908F@kernel.crashing.org>
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
^ permalink raw reply
* Re: 85xx FDT updates?
From: Kumar Gala @ 2006-04-25 18:14 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20060425180119.GF20228@gate.ebshome.net>
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
^ permalink raw reply
* Re: 85xx FDT updates?
From: Eugene Surovegin @ 2006-04-25 18:24 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <265F73F8-F641-4EDD-B88F-A2B2F7FA1308@kernel.crashing.org>
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
^ permalink raw reply
* Re: 85xx FDT updates?
From: Brent Cook @ 2006-04-25 18:29 UTC (permalink / raw)
To: Kumar Gala, Dan Malek, linuxppc-dev@ozlabs.org
In-Reply-To: <20060425182418.GA1132@gate.ebshome.net>
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.
^ permalink raw reply
* Re: 85xx FDT updates?
From: Kumar Gala @ 2006-04-25 18:31 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20060425182418.GA1132@gate.ebshome.net>
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
^ permalink raw reply
* Re: 85xx FDT updates?
From: Kumar Gala @ 2006-04-25 18:33 UTC (permalink / raw)
To: Brent Cook; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <200604251329.35584.bcook@bpointsys.com>
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
^ permalink raw reply
* Re: 85xx FDT updates?
From: Eugene Surovegin @ 2006-04-25 18:48 UTC (permalink / raw)
To: Brent Cook; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <200604251329.35584.bcook@bpointsys.com>
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 :).
--
^ permalink raw reply
* Re: 85xx FDT updates?
From: Eugene Surovegin @ 2006-04-25 18:53 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <248CD1B3-A33B-47F5-AFE8-F7C9DDCD1D0B@kernel.crashing.org>
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
^ permalink raw reply
* Re: 85xx FDT updates?
From: Andy Fleming @ 2006-04-25 19:14 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20060425184857.GB1132@gate.ebshome.net>
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
^ permalink raw reply
* Re: 85xx FDT updates?
From: Kumar Gala @ 2006-04-25 19:20 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20060425185314.GC1132@gate.ebshome.net>
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
^ permalink raw reply
* Re: 85xx FDT updates?
From: Kumar Gala @ 2006-04-25 19:22 UTC (permalink / raw)
To: Andy Fleming; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <F2D4EB11-5E74-4A8E-9F73-B5BFEB2B950C@freescale.com>
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
^ permalink raw reply
* Re: 85xx FDT updates?
From: Eugene Surovegin @ 2006-04-25 19:27 UTC (permalink / raw)
To: Andy Fleming; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <F2D4EB11-5E74-4A8E-9F73-B5BFEB2B950C@freescale.com>
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
^ permalink raw reply
* Re: 85xx FDT updates?
From: Eugene Surovegin @ 2006-04-25 19:31 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <01B6C49A-F82A-47CF-B7B8-106BC0BBDF14@kernel.crashing.org>
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
^ permalink raw reply
* Re: 85xx FDT updates?
From: Kumar Gala @ 2006-04-25 19:41 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20060425193109.GE1132@gate.ebshome.net>
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
^ permalink raw reply
* Re: 85xx FDT updates?
From: Andy Fleming @ 2006-04-25 19:58 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20060425192714.GD1132@gate.ebshome.net>
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
^ permalink raw reply
* FT u-boot shim
From: Kumar Gala @ 2006-04-25 20:00 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20060425185314.GC1132@gate.ebshome.net>
> 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
^ permalink raw reply
* Re: 85xx FDT updates?
From: Eugene Surovegin @ 2006-04-25 20:04 UTC (permalink / raw)
To: Andy Fleming; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <FB3CC275-6C15-414C-A1F2-F1A13E3E1279@freescale.com>
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
^ permalink raw reply
* Re: 85xx FDT updates?
From: Wolfgang Denk @ 2006-04-25 21:09 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <34C11E8A-ED04-490F-B601-841DC1F94AD6@kernel.crashing.org>
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
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox