merge progress

merge progress

[Paul Mackerras]

I have just pushed out a new pile of commits to the powerpc-merge tree
on kernel.org.  (It may take a little while for them to get mirrored
from master.kernel.org to ftp/rsync.kernel.org.)

The current state is that with ARCH=ppc, the merge tree will build all
the ppc32 configs that build in the stock 2.6.14-rc2 tree, and the
powermac configs run (I haven't boot-tested any of the others).

With ARCH=powerpc, a 32-bit powermac target builds (both UP and SMP)
and runs, and a 64-bit pSeries target builds and runs.  64-bit iSeries
builds but there is some weird bug that Stephen Rothwell and BenH have
been chasing.  I haven't got far enough with the merge to be able to
build a 64-bit powermac target.

With ARCH=ppc64, pSeries, iSeries, powermac and maple all build, and
pSeries and iSeries have been boot-tested.  I think I have broken
BPA/cell because it was using pSeries_smp.c (I think we need to make
cell have its own bpa_smp.c or whatever anyway).

I have about a week's backlog of mail, resulting from being on
vacation last week and from concentrating on pushing the merge along.
Tomorrow I'll hopefully get a chance to look at all the patches people
have sent in the last week. :)

Paul.

Re: merge progress

[Simon Richter]

[-- Attachment #1: Type: text/plain, Size: 403 bytes --]

Hi,

Paul Mackerras wrote:

> I have just pushed out a new pile of commits to the powerpc-merge tree
> on kernel.org.  (It may take a little while for them to get mirrored
> from master.kernel.org to ftp/rsync.kernel.org.)

Should I fast-forward the APUS patches towards the merge tree, or is it 
better to apply them in the unmerged tree and merge them back into the 
merge tree from there?

    Simon

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 307 bytes --]

Re: merge progress

[Paul Mackerras]

Simon Richter writes:

> Should I fast-forward the APUS patches towards the merge tree, or is it 
> better to apply them in the unmerged tree and merge them back into the 
> merge tree from there?

Hmmm, probably should work off the merge tree.  However, we decided at
OLS that platforms would require a device tree before being merged.
Have you looked at creating a suitable flattened device tree blob with
dtc?  (If not, you can continue to compile with ARCH=ppc for now.)

Paul.

Re: merge progress

[Simon Richter]

[-- Attachment #1: Type: text/plain, Size: 872 bytes --]

Hi,

Paul Mackerras schrieb:

> Hmmm, probably should work off the merge tree.

Good, then I'll fast-forward them there.

> However, we decided at
> OLS that platforms would require a device tree before being merged.
> Have you looked at creating a suitable flattened device tree blob with
> dtc?  (If not, you can continue to compile with ARCH=ppc for now.)

In fact my current plan is to move away from m68k bootinfo (which APUS
borrows so you can use the same bootloader) towards a flattened dev tree
passed in from the bootloader. For that, however, we need a new
bootloader first, which is dependant on AmigaOS binutils/gcc.

So I guess it will be ARCH=ppc until the new bootloader is ready.

Should APUS still get a special treatment then, or should I try to
emulate enough of OF in the bootloader so it is possible to build CHRP
images that work on APUS?

   Simon

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 374 bytes --]

Re: merge progress

[Geert Uytterhoeven]

On Tue, 18 Oct 2005, Simon Richter wrote:
> Paul Mackerras schrieb:
> > Hmmm, probably should work off the merge tree.
> 
> Good, then I'll fast-forward them there.
> 
> > However, we decided at
> > OLS that platforms would require a device tree before being merged.
> > Have you looked at creating a suitable flattened device tree blob with
> > dtc?  (If not, you can continue to compile with ARCH=ppc for now.)
> 
> In fact my current plan is to move away from m68k bootinfo (which APUS
> borrows so you can use the same bootloader) towards a flattened dev tree

Is requiring a flattened device tree really the right approach to take, for
APUS? APUS borrows from/shares with m68k a lot of code.

BTW, why do you want to move away from m68k bootinfo (apart from using a
flattened device tree)?

> passed in from the bootloader. For that, however, we need a new
> bootloader first, which is dependant on AmigaOS binutils/gcc.
> 
> So I guess it will be ARCH=ppc until the new bootloader is ready.

Happy hacking!

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: merge progress

[Kumar Gala]

> Hmmm, probably should work off the merge tree.  However, we decided at
> OLS that platforms would require a device tree before being merged.
> Have you looked at creating a suitable flattened device tree blob with
> dtc?  (If not, you can continue to compile with ARCH=ppc for now.)

That would assume the ARCH=ppc builds in the merge tree.  Paul, stop  
breaking ARCH=ppc just because your annoyed at me for killing 970 and  
POWER4 in the cputable :)

syscalls has issues in ARCH=ppc.

- kumar

Re: merge progress

[Arnd Bergmann]

On Dinsdag 11 Oktober 2005 14:26, Paul Mackerras wrote:
> With ARCH=ppc64, pSeries, iSeries, powermac and maple all build, and
> pSeries and iSeries have been boot-tested.  I think I have broken
> BPA/cell because it was using pSeries_smp.c (I think we need to make
> cell have its own bpa_smp.c or whatever anyway).

I will fix that up when I move BPA over to arch/powerpc/platforms/cell.

Do you plan to have the whole merge tree included in 2.6.15? Otherwise
I'd rather postpone doing the structural changes on BPA until November,
because we're currently freezing our spufs development to 2.6.14 and
I'd like to have only one current set of big patches.

	Arnd <><