Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 20 Dec 2015 10:45:25 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-bugs@FreeBSD.org
Subject:   [Bug 205458] 11.0-CURRENT/10-STABLE powerpc64: a PowerMac G5 specific sys/powerpc/ofw/ofw_machdep.c change for reliable PowerMac G5 booting (with lots of RAM)
Message-ID:  <bug-205458-8@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205458

            Bug ID: 205458
           Summary: 11.0-CURRENT/10-STABLE powerpc64: a PowerMac G5
                    specific sys/powerpc/ofw/ofw_machdep.c change for
                    reliable PowerMac G5 booting (with lots of RAM)
           Product: Base System
           Version: 11.0-CURRENT
          Hardware: ppc
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: freebsd-bugs@FreeBSD.org
          Reporter: markmi@dsl-only.net

The standard GENERIC64 powerpc64 FreeBSD builds do not reliably boot PowerMac
G5's: hang ups in the very early boot activity happen frequently but randomly.
11.0, 10.x, and far into the past are all this way as I understand. I have
experience with 10.0-RELEASE to 11.0-CURRENT.

I have been testing a PowerMac G5 specific change since late 2015-Feb or so and
have reliable booting with the change and horribly unreliable booting without
it. The G5's in question happen to have lots of RAM for their vintage (8GB,
12GB, 16GB). (It took months and thousands of reboot attempts to isolate the
change, the more RAM the worse the failure rate for booting in my testing.)

The change is in ofw_sprg_prepare of sys/powerpc/ofw/ofw_machdep.c and could
look something like (presented in a form to show new/PowerMacG5-Specific code
and old general code):

#ifdef POWERMAC_G5_SPECIFIC_BUILD
    __asm __volatile("mfsprg0 %0\n\t"
             "mtsprg1 %1\n\t"
             "mtsprg2 %2\n\t"
             "mtsprg3 %3\n\t"
             : "=&r"(ofw_sprg0_save)
             : "r"(ofmsr[2]),
             "r"(ofmsr[3]),
             "r"(ofmsr[4]));
#else
// The historical code:
    __asm __volatile("mfsprg0 %0\n\t"
             "mtsprg0 %1\n\t"
             "mtsprg1 %2\n\t"
             "mtsprg2 %3\n\t"
             "mtsprg3 %4\n\t"
             : "=&r"(ofw_sprg0_save)
             : "r"(ofmsr[1]),
             "r"(ofmsr[2]),
             "r"(ofmsr[3]),
             "r"(ofmsr[4]));
#endif

In other words: for PowerMac G5's omit the mtsprg0 from ofmsr[1]: leave the
register as it already is instead of resetting it. The value in ofmsr[1] is
inappropriate to the context. I deliberately kept the change minimal and left
in all other code related to the register.

Unfortunately I do not know how to accurately detect a PowerMac G5 context
while avoiding calling into openfirmware. So I do not know how to make this
have an auto-adjusting/dynamic check for a PowerMac G5. Entering openfirmware
first would likely recreate the problem (or other problems) from what I can
tell.

If appropriate FreeBSD folks consider PowerMac G5's still to be
worth-the-effort as tier2 examples to support a predefined, systematic way to
buildkernel for reliable PowerMac G5 booting then some sort of
publically-documented technique of configuring a build to control the
distinction would be appropriate. But it might be that there is a policy of "no
such platform-specific source code for desktop machines". Understandable if so.
There might be conventions for handling such contexts that I'm not aware of.

I've been testing/using various vintages of 11.0-CURRENT, 10.x-RELENG, and
10-STABLE, progressing over time. All have been reliably booting with the
change on all 3 PowerMac G5's that I have access to. (I have no other powerpc64
context.)

-- 
You are receiving this mail because:
You are the assignee for the bug.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-205458-8>