2.4.9-ac12 ppc ftr_fixup

Tom Rini trini at kernel.crashing.org
Mon Aug 27 13:04:04 EST 2001


[cc's trimmed]

On Mon, Aug 27, 2001 at 12:47:57PM +1000, Keith Owens wrote:
> On Sun, 26 Aug 2001 19:15:36 -0700,
> Tom Rini <trini at kernel.crashing.org> wrote:
> >On Mon, Aug 27, 2001 at 10:27:22AM +1000, Keith Owens wrote:
> >
> >> 2.4.9-ac12 has new ppc code for CPU feature fixups.  The ftr_fixup code
> >> only handles entries that are built into the kernel.  timex.h defines
> >> get_cycles() using ftr_fixup and get_cycles() is used all over the
> >> place, including in modules.  AFAICT we need to add modutils support
> >> for ftr_fixup.
> >
> >Er, eh?  Excuse me if I'm being obtuse, but where is the problem?  The fixup
> >stuff is closely tied to bootup and what processor we happen to be on
> >at the time.  So we won't be trying to fixup any code in a module...
>
> do_cpu_ftr_fixups() replaces unsupported code with NOP, based on the
> table from __start___ftr_fixup to __stop___ftr_fixup which contains all
> the data marked as section(__ftr_fixup).  Fine, but it only handles
> section __ftr_fixup data in the kernel, it does not write NOP over
> __ftr_fixup data in modules.  So any code marked as section __ftr_fixup
> in a module executes unchanged.  Unless I am missing something, that is
> a problem.

After a bit more digging, I'm pretty sure it's not much of a problem.
get_cycles seems to be either a) SMP or b) DRM or c) arcnet related.
a and b aren't an issue for 601 (no SMP and possible but unlikely that
DRM will work on a machine w/ a 601).  If there's an arcnet PCI card, I suppose
it could be an issue then...  Anyhow...

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/





More information about the Linuxppc-dev mailing list