All of lore.kernel.org
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
	geert@linux-m68k.org, arnd@arndb.de
Subject: Re: [RFC PATCH 01/10] powerpc/chrp: Remove CHRP support
Date: Wed, 27 Nov 2024 14:10:15 -0600	[thread overview]
Message-ID: <20241127201015.GO29862@gate.crashing.org> (raw)
In-Reply-To: <87mshm7ixu.fsf@mpe.ellerman.id.au>

On Tue, Nov 26, 2024 at 02:49:49PM +1100, Michael Ellerman wrote:
> Segher Boessenkool <segher@kernel.crashing.org> writes:
> > On Fri, Nov 15, 2024 at 12:11:04AM +1100, Michael Ellerman wrote:
> >> CHRP (Common Hardware Reference Platform) was a standard developed by
> >> IBM & Apple for PowerPC-based systems.
> >> 
> >> The standard was used in the development of some machines but never
> >> gained wide spread adoption.
> >> 
> >> The Linux CHRP code only supports a handful of machines, all 32-bit, eg.
> >> IBM B50, bplan/Genesi Pegasos/Pegasos2, Total Impact briQ, and possibly
> >> some from Motorola? No Apple machines should be affected.
> >> 
> >> All of those mentioned above are over or nearing 20 years old, and seem
> >> to have no active users.
> >
> > This was used by all non-IBM 970 systems as well.  The last was SLOF on
> > JS20 and JS21, about 20 years ago yes, and I doubt anyone uses it still
> > (I don't).
> 
> By "this" you mean the CHRP standard?

I mean the "maple" stuff, and the whole "chrp" thing in PowerPC Linux.

> At least in Linux the "CHRP" platform has always been 32-bit only AFAIK.

No?  I've written stuff for it for years :-)

> My memory is that JS20/JS21 used the "maple" platform, which was a
> 64-bit only bare-metal platform, possibly it was actually == CHRP, but
> we didn't call it that in Linux.

Well, it is what it is called in the Open Firmware device trees!

It has a root "device_type" property that starts with the string "chrp".
But that really is only because Yaboot for some reason needs it to
behave reasonably, heh.  (I didn't remember the details, but I still
have the original SLOF open source release tarballs :-) )  So yeah it
wasn't anything "chrp" in Linux itself, aha.

> But maybe I'm wrong, you were more involved than me back than, and it
> was a long time ago :)

Very long ago.  Sad to see it go, but the Git tree will never forget :-)


Segher


  reply	other threads:[~2024-11-27 20:13 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-14 13:11 [RFC PATCH 01/10] powerpc/chrp: Remove CHRP support Michael Ellerman
2024-11-14 13:11 ` [RFC PATCH 02/10] powerpc/chrp: Remove various dead code Michael Ellerman
2024-11-16 16:15   ` Christophe Leroy
2024-11-19  3:27     ` Michael Ellerman
2024-11-14 13:11 ` [RFC PATCH 03/10] powerpc/chrp: Remove PPC_CHRP from defconfigs Michael Ellerman
2024-11-14 13:11 ` [RFC PATCH 04/10] powerpc/powermac: Remove machine_is(chrp) test Michael Ellerman
2024-11-14 13:11 ` [RFC PATCH 05/10] powerpc/rtasd: Remove machine_is(chrp) tests Michael Ellerman
2024-11-14 13:11 ` [RFC PATCH 06/10] powerpc: Remove prom_init longtrail work arounds Michael Ellerman
2024-11-14 14:33   ` Geert Uytterhoeven
2024-11-14 13:11 ` [RFC PATCH 07/10] powerpc: Remove CONFIG_ISA Michael Ellerman
2024-11-14 14:34   ` Geert Uytterhoeven
2024-11-14 13:11 ` [RFC PATCH 08/10] macintosh: Remove ADB_MACIO Michael Ellerman
2024-11-14 14:35   ` Geert Uytterhoeven
2024-11-14 15:42   ` Arnd Bergmann
2024-11-14 16:35     ` Geert Uytterhoeven
2024-11-16 16:00   ` Christophe Leroy
2024-11-17 11:29     ` Michael Ellerman
2024-11-14 13:11 ` [RFC PATCH 09/10] i2c: Remove I2C_HYDRA Michael Ellerman
2024-11-14 14:37   ` Geert Uytterhoeven
2024-11-14 14:57     ` Wolfram Sang
2024-11-14 14:47   ` Geert Uytterhoeven
2024-11-19 23:11     ` Michael Ellerman
2024-11-14 13:11 ` [RFC PATCH 10/10] i2c: Drop reference to PPC_CHRP Michael Ellerman
2024-11-14 14:31 ` [RFC PATCH 01/10] powerpc/chrp: Remove CHRP support Geert Uytterhoeven
2024-11-14 15:43   ` Arnd Bergmann
2024-11-14 21:04 ` Segher Boessenkool
2024-11-26  3:49   ` Michael Ellerman
2024-11-27 20:10     ` Segher Boessenkool [this message]
2024-11-17 20:36 ` Gerhard Pircher
2024-11-18  6:07   ` Michael Ellerman
2024-11-21  8:41     ` John Paul Adrian Glaubitz
2024-11-22 18:31       ` Segher Boessenkool
2024-11-21  8:38 ` John Paul Adrian Glaubitz
2024-11-26  3:27   ` Michael Ellerman
2024-11-26 13:27     ` John Paul Adrian Glaubitz
2024-12-12  9:50       ` John Paul Adrian Glaubitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20241127201015.GO29862@gate.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=arnd@arndb.de \
    --cc=geert@linux-m68k.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.