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 with
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 shou
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; bu
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
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
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
> > >>
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 kernel. No other target platform I've 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 kern
>> 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 hav
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, gettin
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 something that's sufficient to
> get working under just q
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 addi
On Saturday 22 September 2007 11:27:05 pm Paul Mackerras wrote:
> 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 pro
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 th
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 additi
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 platforms
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. W
17 matches
Mail list logo
