linux-mips
[Top] [All Lists]

Re: [PATCH 0/3] Alchemy: platform updates

To: Kevin Hickey <khickey@rmicorp.com>
Subject: Re: [PATCH 0/3] Alchemy: platform updates
From: Manuel Lauss <mano@roarinelk.homelinux.net>
Date: Sun, 29 Mar 2009 17:52:43 +0200
Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>, Linux-MIPS <linux-mips@linux-mips.org>
In-reply-to: <1238340466.28598.4.camel@kh-d820>
Organization: Private
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <1238318822-4772-1-git-send-email-mano@roarinelk.homelinux.net> <49CF5CE6.1070003@ru.mvista.com> <20090329143802.0a09baca@scarran.roarinelk.net> <49CF71BE.2070109@ru.mvista.com> <1238340466.28598.4.camel@kh-d820>
Sender: linux-mips-bounce@linux-mips.org
On Sun, 29 Mar 2009 10:27:46 -0500
Kevin Hickey <khickey@rmicorp.com> wrote:

> On Sun, 2009-03-29 at 17:03 +0400, Sergei Shtylyov wrote:
> >   Single kernel binary? If it's at all possible, I am all for it.
> 
> On some level, I agree but not at the expense of a larger kernel or
> longer boot times.  Maybe I'm just not following how your implementation
> works but it seems to me that runtime checks will add to boot time.
> More importantly it adds to the kernel memory footprint as the tables of
> constants for multiple CPUs will have to be compiled in.  If I'm
> designing a board with an Au1250 in it, I don't care about the interrupt
> numbers for Au1100 or Au1500.  This problem compounds when we introduce
> Au1300 - several of its subsystems (like the interrupt controller) are
> new requiring not only a new table of constants but a new object as
> well.  In the desktop space I can understand this approach, but in the
> embedded space it seems like an unnecessary resource burden.  
> 
> Please enlighten me :)

You're right, from a single-cpu-board POV it doesn't make sense.
However if you have a few boards which mostly differ in the Alchemy
chip used (and not much else difference in board support code), I find
this to be highly beneficial.  If I can have a single binary for the
folks testing these boards, all the better!

Yes, increased binary size is to be expected, but I don't expect it to
be in the megabyte range.

I'm primarily doing this for company-internal purposes; I just thought
I'd share the final result, maybe someone else might find it useful.

        Manuel Lauss

<Prev in Thread] Current Thread [Next in Thread>