Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 18 Dec 2006 17:02:25 -0800
From:      Peter Grehan <grehan@freebsd.org>
To:        Marcel Moolenaar <xcllnt@mac.com>
Cc:        ppc@FreeBSD.org
Subject:   Re: Adding new PowerPC platforms to the build
Message-ID:  <45873A21.8020304@freebsd.org>
In-Reply-To: <DE8E70B1-9E3F-41E8-8502-AA374BFB150C@mac.com>
References:  <DE8E70B1-9E3F-41E8-8502-AA374BFB150C@mac.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi Marcel,

> There has been some mention of activity here about porting FreeBSD to
> hardware other than Macintosh. I'm in fact collaborating with Rafal to
> add support for e500 (mpc85xx).

  Very happy that this is being done. Long overdue :)

> There's another variable: MACHINE_CPU. It is defined as the oldest CPU
> that is supported for a particular architecture. This variable is not
> currently used on PowerPC. I don't think it's unreasonable to use this
> variable to indicate the kind of features we expect to find on the
> target CPU and as such to be able to use it to distinguish between,
> say, a PowerPC 7455 and a Book-E?

  See below, I wouldn't want to have a compile-time option for this 
unless it's absolutely necessary. Put all the CPU-model-specific code in 
it's own source file, glue them together with linker sets, and pick one 
at boot-time. If you only want one, then create a custom config that 
only includes the one of interest. GENERIC can have all of them, within 
reason.

> At this time there's nothing that checks and/or sets CPUTYPE for
> PowerPC. As I said, MACHINE_CPU is not used at all.
> 
> The big question is: can we make it so that we can use existing
> variables to build realeases for 1) Apple hardware, having a Book
> III-S ISA processor and 2) embedded hardware with varying drivers and
> using a Book III-E ISA processor?

  As I mentioned in the long reply to Rafal a while back, the ideal 
world is where GENERIC can run-time select between all boot-loaders and 
CPU architectures. That isn't possible for a small subset, for instance 
if there is conflicting SPR usage or locking issues.

  What I want to avoid is a separate kernel config per-CPU variant and 
per-platform, and one reason is the tinderbox coverage. If it's all in 
GENERIC then it will be constantly tested.

> In particular I'd like to see the tinderbox and make release work
> without any additional kluging. Would that be possible?
> 
> Thoughts?

  I hope it's possible. The easy way out is zillions of configs and 
conditional compilation: let's try and avoid that path.

later,

Peter.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45873A21.8020304>