Re: what's next for the linux kernel?
From: Luke Kenneth Casson Leighton (lkcl_at_lkcl.net)
Date: 10/07/05
- Previous message: Alejandro Bonilla: "Re: Why is this list using Majordomo?"
- In reply to: Luke Kenneth Casson Leighton: "Re: what's next for the linux kernel?"
- Next in thread: Al Viro: "Re: what's next for the linux kernel?"
- Reply: Al Viro: "Re: what's next for the linux kernel?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 7 Oct 2005 01:38:41 +0100 To: Rik van Riel <riel@redhat.com>
http://www.eet.com/in_focus/embedded_systems/OEG20021213S0029
It was decided at the beginning that we would design
a system-on-chip (SoC) platform, which yields the
best unit price when manufactured in high volume. The
usual approach would be to license all the technology
from third party suppliers, [...] [but] we didn't
want to deal with huge NRE and royalty fees. Also,
we would not get the necessary know-how that is often
a determining factor when designing a new product in
today's ever decreasing time-to-market.
So, we decided to follow the Linux open source
philosophy and build our first platform on open
source technology. We took several open source IPs
from OpenCores [http://www.opencores.org] and integrate
them into an underlying hardware SoC platform optimized
for running Linux.
[...]
... As the main processor we chose OpenRISC 1200
[http://www.opencores.org/pnews.cgi/list/or1k?no_loop=yes],
a 32-bit RISC processor that comes with a stable GNU
Toolchain and a port of small footprint Microcontroller
Linux, the uClinux.
The next critical part of the whole project was to set up a
scheme on how to connect all the IPs in a modular way so that
we could configure the platform for different embedded
applications. [...]
We found out that a central configurable block
interconnecting the processor and peripheral IPs did
the trick. [...] we created a tool that automatically
generated this central block [...] and automatically
configures Linux kernel and device drivers for that
particular application.
As embedded developers often find out, it is difficult
to start writing and testing software, if hardware
designers are still designing the hardware. It is
necessary to parallel these two tasks in order to meet
^^^^^^^^^^^^^^^^^^^^^^^^
today's critical time-to-market schedules. In addition,
each group can provide some test cases to the other
as we found out.
these people designed the _entire_ embedded system - from free software
licensed components.
the processor design.
the software toolchain.
the kernel running on the free software licensed processor design.
it CAN be done. it HAS been done.
convincing yourselves that you "must have hardware before you will get
off your fat asses" is _so_ self-disempowering. STOP IT.
you - the linux kernel designers - are an extremely powerful
group who quite literally could hold the technical world to
ransom if you so chose (albeit for a very brief amount of time until
someone considered your actions to be the equivalent of a
"bus-running-over" event).
god help the world when you decide to actually say "thank you
for your hardware. next time, consult us on what should be
in it _before_ you finalise its design".
l.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Previous message: Alejandro Bonilla: "Re: Why is this list using Majordomo?"
- In reply to: Luke Kenneth Casson Leighton: "Re: what's next for the linux kernel?"
- Next in thread: Al Viro: "Re: what's next for the linux kernel?"
- Reply: Al Viro: "Re: what's next for the linux kernel?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
