85xx FDT updates?
galak at kernel.crashing.org
Wed Apr 26 04:14:55 EST 2006
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
>> 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.
More information about the Linuxppc-dev