Re: [PATCH 1/2] qemu platform, v2

2007-10-18 Thread Rob Landley
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

Re: [PATCH 1/2] qemu platform, v2

2007-10-18 Thread Grant Likely
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

Re: [PATCH 1/2] qemu platform, v2

2007-10-18 Thread Milton Miller
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

Re: [PATCH 1/2] qemu platform, v2

2007-10-18 Thread Matt Sealey
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

Re: [PATCH 1/2] qemu platform, v2

2007-10-17 Thread Rob Landley
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

Re: [PATCH 1/2] qemu platform, v2

2007-10-17 Thread Grant Likely
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 > > >>

Re: [PATCH 1/2] qemu platform, v2

2007-09-30 Thread David Gibson
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

Re: [PATCH 1/2] qemu platform, v2

2007-09-28 Thread Rob Landley
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

Re: [PATCH 1/2] qemu platform, v2

2007-09-28 Thread Segher Boessenkool
>> 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

Re: [PATCH 1/2] qemu platform, v2

2007-09-24 Thread Milton Miller
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

Re: [PATCH 1/2] qemu platform, v2

2007-09-24 Thread Christoph Hellwig
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

Re: [PATCH 1/2] qemu platform, v2

2007-09-23 Thread David Gibson
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

Re: [PATCH 1/2] qemu platform, v2

2007-09-23 Thread Rob Landley
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

Re: [PATCH 1/2] qemu platform, v2

2007-09-22 Thread Paul Mackerras
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

Re: [PATCH 1/2] qemu platform, v2

2007-09-22 Thread Rob Landley
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

Re: [PATCH 1/2] qemu platform, v2

2007-09-22 Thread Christoph Hellwig
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