On Thursday 18 October 2007 12:29:08 pm Grant Likely wrote:
On 10/18/07, Milton Miller [EMAIL PROTECTED] wrote:
If we say only some boards or ports are special and need to build then
I would vote for shipping asm files. If we think we need to build any
random embedded platform without
Grant Likely wrote:
On 9/30/07, David Gibson [EMAIL PROTECTED] wrote:
On Fri, Sep 28, 2007 at 06:53:28PM +0200, Segher Boessenkool wrote:
I'm working on merging dtc into the kernel tree instead.
I'm kind of late to this party; but I have to say I disagree. Most of
us are doing just fine
On Oct 18, 2007, at 4:59 AM, Matt Sealey wrote:
Grant Likely wrote:
On 9/30/07, David Gibson [EMAIL PROTECTED] wrote:
On Fri, Sep 28, 2007 at 06:53:28PM +0200, Segher Boessenkool wrote:
I'm working on merging dtc into the kernel tree instead.
I'm kind of late to this party; but I have to say
On 10/18/07, Milton Miller [EMAIL PROTECTED] wrote:
On Oct 18, 2007, at 4:59 AM, Matt Sealey wrote:
Which begs the question; why cloning?
Why can't development be MOVED to in-kernel?
Because we don't put userspace testsuites there for one.
And its a stand alone tool and should have its
On 9/30/07, David Gibson [EMAIL PROTECTED] wrote:
On Fri, Sep 28, 2007 at 06:53:28PM +0200, Segher Boessenkool wrote:
I'd be following this more closely if compiling a device tree didn't
currently
require an external utility (dtc or some such) that doesn't come with
the
Linux
On Wednesday 17 October 2007 3:28:41 pm Grant Likely wrote:
Including .dtbs in the kernel tree has a big practical problem:
they're binary, so can't be patch(1)ed, which makes updating them a
complete PITA.
I note that kconfig includes the lex/yacc output files (blah.c_shipped) so you
I'd be following this more closely if compiling a device tree didn't
currently
require an external utility (dtc or some such) that doesn't come with
the
Linux kernel. No other target platform I've built kernels for
requires such
an environmental dependency.
No? You haven't built
On Friday 28 September 2007 11:53:28 am Segher Boessenkool wrote:
I'd be following this more closely if compiling a device tree didn't
currently
require an external utility (dtc or some such) that doesn't come with
the
Linux kernel. No other target platform I've built kernels for
On Sep 24, 2007, at 2:46 AM, Christoph Hellwig wrote:
On Mon, Sep 24, 2007 at 02:00:47PM +1000, David Gibson wrote:
Basically because PReP support doesn't work under arch/powerpc.
Getting it working properly is something that should happen, but will
take a while. In the meantime, getting
On Sat, Sep 22, 2007 at 11:55:46AM +0200, Christoph Hellwig wrote:
On Fri, Sep 21, 2007 at 06:08:31PM -0500, Milton Miller wrote:
Here is the second rev of patches to boot a arch powerpc kernel on
qemu with the prep architecture.
So if this is supposed to be prep why do you need additional
On Fri, Sep 21, 2007 at 06:08:31PM -0500, Milton Miller wrote:
Here is the second rev of patches to boot a arch powerpc kernel on
qemu with the prep architecture.
So if this is supposed to be prep why do you need additional kernel
support? And if you really needed why isn't it under
On Saturday 22 September 2007 4:55:46 am Christoph Hellwig wrote:
On Fri, Sep 21, 2007 at 06:08:31PM -0500, Milton Miller wrote:
Here is the second rev of patches to boot a arch powerpc kernel on
qemu with the prep architecture.
So if this is supposed to be prep why do you need additional
Rob Landley writes:
Just to correct a few misconceptions:
2) PowerPC uses a device tree supplied by the hardware to identify the
available hardware, even for stuff living on PCI busses which it could
theoretically probe for but doesn't.
The device tree doesn't have to include anything that
Here is the second rev of patches to boot a arch powerpc kernel on
qemu with the prep architecture.
The goal is to provide an environment for use with the existing qemu
hardware suppplied hardware, as oposed to changing the qemu
machine description.
This patch contains only the kernel portion.
14 matches
Mail list logo
