* Re: 85xx FDT updates?
From: Wolfgang Denk @ 2006-04-25 21:29 UTC (permalink / raw)
To: Andy Fleming; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <FB3CC275-6C15-414C-A1F2-F1A13E3E1279@freescale.com>
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.
^ permalink raw reply
* Re: 85xx FDT updates?
From: Wolfgang Denk @ 2006-04-25 21:25 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20060425184857.GB1132@gate.ebshome.net>
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.
^ permalink raw reply
* Re: 85xx FDT updates?
From: Wolfgang Denk @ 2006-04-25 21:24 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <E29663C3-8289-443F-BF7A-F973EC41CC72@kernel.crashing.org>
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
^ permalink raw reply
* Re: 85xx FDT updates?
From: Wolfgang Denk @ 2006-04-25 21:22 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <265F73F8-F641-4EDD-B88F-A2B2F7FA1308@kernel.crashing.org>
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
^ permalink raw reply
* Re: 85xx FDT updates?
From: Kumar Gala @ 2006-04-25 21:19 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev@ozlabs.org list
In-Reply-To: <20060425211639.DD1E8353DAC@atlas.denx.de>
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
^ permalink raw reply
* Re: 85xx FDT updates?
From: Wolfgang Denk @ 2006-04-25 21:16 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org list
In-Reply-To: <6F7CAB43-B4C0-47DA-BC7D-3FD04A552131@kernel.crashing.org>
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.
^ permalink raw reply
* Re: Kernel panic on mpc852.
From: Wolfgang Denk @ 2006-04-25 21:12 UTC (permalink / raw)
To: Gautam Borad; +Cc: linuxppc-embedded
In-Reply-To: <444E2ABA.60400@eisodus.com>
In message <444E2ABA.60400@eisodus.com> you wrote:
>
> I'm trying to port linux-2.4.21 to mpc852t custom board.
> The bootloader (u-boot) works fine and the kernel boots.
> The kernel is _VERY_ unstable, in that it gives sig 11
> ( Oops: kernel access of bad area, sig: 11 ) at random
> intervals.
2.4.21 is *very* old. I recommend to use a more recent (and better
supported) version of the kernel.
And please read the FAQ, especially
http://www.denx.de/wiki/view/DULG/LinuxCrashesRandomly
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
Disc space - the final frontier!
^ 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
* 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
* 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: 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
* 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: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
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