Date: Wed, 16 Nov 2016 14:02:05 -0800 From: Mark Millard <markmi@dsl-only.net> To: Jukka Ukkonen <jau789@gmail.com> Cc: Justin Hibbits <chmeeedalf@gmail.com>, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: Re: svn commit: r306065 - in head/sys vs. PowerMacs: Nathan's trail patch included but inappropriate? [My hack vs. Apple G4's.] Message-ID: <56703830-B39E-41DE-A5FA-B9C3673EA643@dsl-only.net> In-Reply-To: <EC569F92-9BD0-4683-B8E4-22ABF79506D5@dsl-only.net> References: <C48933C3-DB22-4D94-B22D-B51822197E4E@dsl-only.net> <917EFF5A-D054-4424-9D7D-4E4BEF6072EF@gmail.com> <4bb1046a-225d-66b2-7b00-067f0d6f6c60@gmail.com> <465041D5-C1A2-48F4-9CA7-DD03B094FAE4@dsl-only.net> <01cfa4e9-954f-3e86-c8d7-36ec8523dde0@freebsd.org> <B28E3336-2F85-4395-8DDF-CF09CA9D41E1@dsl-only.net> <5C253E59-265B-4F5F-A4C5-E4FB7EEBF084@gmail.com> <7E73DEEA-AA99-48CD-A441-5596A6F0D8E8@dsl-only.net> <5F29E512-A5F0-452F-B816-FA5907DF875A@dsl-only.net> <F658C426-84CF-4AD2-B993-8D9F2FB16B05@dsl-only.net> <EC569F92-9BD0-4683-B8E4-22ABF79506D5@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[This reports on not having the problem on a PowerMac7,2 as well. Also
on possibilities for going forward.]
On 2016-Nov-15, at 4:18 PM, Mark Millard <markmi at dsl-only.net> wrote:
> On 2016-Nov-15, at 3:01 PM, Mark Millard <markmi at dsl-only.net> =
wrote:
>=20
>=20
>> On 2016-Nov-15, at 1:42 PM, Mark Millard <markmi at dsl-only.net> =
wrote:
>>=20
>>> [Top post of an experiment with loading iicsmb.ko from the loader =
prompt.]
>>>=20
>>> I stopped a PowerMac G5 "Quad Core" at the loader prompt (not
>>> using /boot/loader.conf or other such) and did a:
>>>=20
>>> load iicsmb
>>> boot
>>>=20
>>> (smbus.ko also loads --and so for my earlier "in kernel" suggestion
>>> "device smbus" should also be listed in the KERNCONF file.)
>>>=20
>>> It booted fine. Afterwards kldstat reported:
>>>=20
>>> # kldstat
>>> Id Refs Address Size Name
>>> 1 6 0x100000 16901b0 kernel
>>> 2 1 0x1792000 14598 iicsmb.ko
>>> 3 2 0x17a7000 13f80 smbus.ko
>>>=20
>>> Those are not the addresses that were reported at the loader prompt =
for
>>> iicsmb and smbus:
>>>=20
>>> .text for iccsmb was listed as at 0x28e0 if I remember right
>>> .text for smbus was listed as at 0x2800 if I remember right
>>>=20
>>> The .data for each were listed at the loader prompt as each starting =
in
>>> the 0x6xxx range as I remember.
>>=20
>> One too many x's: 0x6c8 and 0x600 were the figures.
>>=20
>>> I'm not sure that what the loader prompt context listed was actually =
the
>>> load addresses at that time.
>>>=20
>>> I do not know if you get similar results or not.
>>>=20
>>> If the loader prompt loads always work and the loader.conf loads do =
not
>>> that might also be interesting evidence about the problem(s) =
involved.
>>>=20
>>> I do not know how to tell if iicsmb and smbus are working or not.
>>>=20
>>> It may be that explicit loads from the loader prompt are another
>>> workaround.
>>>=20
>>>=20
>>> I have not yet tried:
>>>=20
>>> unload
>>> load iccsmb
>>> boot
>>=20
>> (typo above: iicsmb is what I loaded.)
>>=20
>> That did not work: the kernel needs to be loaded first. . .
>>=20
>> unload
>> load kernel
>> load iicsmb
>> boot
>>=20
>> did work. The kldstat then ends up being:
>>=20
>> # kldstat
>> Id Refs Address Size Name
>> 1 6 0x100000 16901b0 kernel
>> 2 1 0x1791000 14598 iicsmb.ko
>> 3 2 0x17a6000 13f80 smbus.ko
>>=20
>> (Not much different --but not identical to before for 2 of the =
Address values.)
>=20
> Based on:
>=20
> # more /boot/loader.conf
> #verbose_loading=3D"YES"
> kernel=3D"kernel"
> kern.vty=3Dvt
> dumpdev=3D"/dev/label/FBSDG5Lswap"
> smbus_load=3D"YES"
> iicsmb_load=3D"YES"
>=20
> I have no trouble booting the PowerMac G5 (with my version of the boot
> hack in place). (I do not use any hack for 32-bit powerpc.)
I temporarily moved the SSD from that PowerMac11,3 to the PowerMac7,2 =
that
I have access to.
The PowerMac7,2 behaves like the above as well: I've not been able to
reproduce any boot time problems with using iicsmb_load=3D"YES" in
/boot/loader.conf .
I do not have access to any other types of PowerMac G5's (or to
non-PowerMac powerpc64 systems).
On the information that I currently have available it does not appear
that I can help you track down what is going on in your environment.
It appears I'd have to try to reproduce how you configure and build your
kernel and possibly other details to have a chance to reproduce the
problem.
My results do tend to suggest that the SPRG0 handling in my hack for
supporting PowerMac G5's booting reliably is not part of the problem
(otherwise I'd likely have been able to reproduce the boot crashes that
you report). (You experimented with variations on my hack and I do not
know if your current variant and mine match for the code generated.)
As I do not know how to test if iicsmb is working, you could let me
know of a good way to check that if one is available on a basic
PowerMac configuration.
Another option is for you to try building using as much of the build
configuration information that I've provided as you can to see if the
problem goes away. If you have the PowerMac self-host buildworld
buildkernel I'd also need to provide notes about getting powerpc64-gcc
installed. (lang/gcc49 is also used but should install fine, at least
if you select to avoid including the JAVA material.) If you cross
build I could provide alternate src.conf content for that. (Actually
I use SRC_ENV_CONF currently, per the script that I had included in
what I reported.)
Too bad we have not been able to figure this out (yet).
> # uname -apKU
> FreeBSD FBSDG5L 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r308247M: Fri Nov =
4 03:18:34 PDT 2016 =
markmi@FreeBSDx64:/usr/obj/powerpc64vtsc_xtoolchain/powerpc.powerpc64/usr/=
src/sys/GENERIC64vtsc-NODBG powerpc powerpc64 1200014 1200014
>=20
> Unfortunately we then hit my odd context from doing libc++ based =
builds
> for powerpc64, including self-hosted builds, and my experimenting with
> clang.
>=20
> I use devel/powerpc-xtoolchain-gcc (and so devel/powerpc64-gcc) to
> buildworld buildkernel for powerpc64, be it cross compiling from amd64
> or on the powerpc64 itself (self hosted cross build). (A work around =
is
> required to get it installed on a powerpc64 FreeBSD.) I use a libc++
> based build --something gcc 4.2.1 will not do.
>=20
> For self hosting on powerpc64 I use lang/gcc49 as the so-called =
"system
> compiler" and devel/powerpc64-gcc as the "cross" compiler for =
buildworld
> buildkernel .
>=20
> So my src.conf sort of content and related context is probably not =
like
> yours (showing for self-hosted below). I list several files with =
details
> of my buildworld buildkernel environment.
>=20
> (There are long lines likely implicitly wrapped in the below --in
> addition to \ end-of-line notation.)
>=20
> # more =
~/sys_build_scripts.powerpc64-host/make_powerpc64vtsc_nodebug_incl_clang_x=
toolchain-powerpc64-host.sh=20
> kldload -n filemon && \
> script =
~/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_incl_clang_xtoolch=
ain-powerpc64-host-$(date +%Y-%m-%d:%H:%M:%S) \
> env __MAKE_CONF=3D"/root/src.configs/make.conf" SRCCONF=3D"/dev/null" =
SRC_ENV_CONF=3D"/root/src.configs/src.conf.powerpc64-xtoolchain.powerpc64-=
host" \
> WITH_META_MODE=3Dyes \
> MAKEOBJDIRPREFIX=3D"/usr/obj/powerpc64vtsc_xtoolchain/powerpc.powerpc64"=
\
> make $*
>=20
>=20
> # more ~/src.configs/make.conf=20
> CFLAGS.gcc+=3D -v
>=20
>=20
> # more ~/src.configs/src.conf.powerpc64-xtoolchain.powerpc64-host
> TO_TYPE=3Dpowerpc64
> TOOLS_TO_TYPE=3D${TO_TYPE}
> FROM_TYPE=3D${TO_TYPE}
> TOOLS_FROM_TYPE=3D${FROM_TYPE}
> VERSION_CONTEXT=3D12.0
> #
> KERNCONF=3DGENERIC64vtsc-NODBG
> TARGET=3Dpowerpc
> .if ${.MAKE.LEVEL} =3D=3D 0
> TARGET_ARCH=3D${TO_TYPE}
> .export TARGET_ARCH
> .endif
> #
> WITHOUT_CROSS_COMPILER=3D
> WITHOUT_SYSTEM_COMPILER=3D
> #
> WITH_LIBCPLUSPLUS=3D
> WITHOUT_BINUTILS_BOOTSTRAP=3D
> WITHOUT_CLANG_BOOTSTRAP=3D
> WITH_CLANG=3D
> WITH_CLANG_IS_CC=3D
> WITH_CLANG_FULL=3D
> WITH_CLANG_EXTRAS=3D
> WITH_LLDB=3D
> #
> WITH_BOOT=3D
> # powerpc64 LIB32 builds via gcc 4.9 or later variants that I've tried
> # but the LIB32 does not work [crtbeginS code problem(s)]
> WITHOUT_LIB32=3D
> #
> WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D
> WITHOUT_GCC_BOOTSTRAP=3D
> WITHOUT_GCC=3D
> WITHOUT_GCC_IS_CC=3D
> WITHOUT_GNUCXX=3D
> #
> NO_WERROR=3D
> #WERROR=3D
> MALLOC_PRODUCTION=3D
> #
> WITH_DEBUG_FILES=3D
> #
> #
> # For TO (so-called "cross") stages . . .
> # So-called-cross via ${TO_TYPE}-xtoolchain-gcc/${TO_TYPE}-gcc. . .
> # TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related binutils. . =
.
> #
> CROSS_TOOLCHAIN=3D${TO_TYPE}-gcc
> X_COMPILER_TYPE=3Dgcc
> CROSS_BINUTILS_PREFIX=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/
> .if ${.MAKE.LEVEL} =3D=3D 0
> =
XCC=3D/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-gc=
c
> =
XCXX=3D/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-g=
++
> =
XCPP=3D/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-c=
pp
> .export XCC
> .export XCXX
> .export XCPP
> XAS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as
> XAR=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar
> XLD=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld
> XNM=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm
> XOBJCOPY=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy
> XOBJDUMP=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump
> XRANLIB=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib
> XSIZE=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size
> #NO-SUCH: XSTRINGS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings
> XSTRINGS=3D/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings
> .export XAS
> .export XAR
> .export XLD
> .export XNM
> .export XOBJCOPY
> .export XOBJDUMP
> .export XRANLIB
> .export XSIZE
> .export XSTRINGS
> .endif
> #
> #
> # For FROM (host) stages . . .
> # =46rom gccXY (such as gcc49 but not xtoolchain)
> # TOOLS_FROM_TYPE's appropriate binutils. . .
> #
> .if ${.MAKE.LEVEL} =3D=3D 0
> CC=3Denv C_INCLUDE_PATH=3D/usr/include /usr/local/bin/gcc49 -L/usr/lib
> CXX=3Denv C_INCLUDE_PATH=3D/usr/include =
CPLUS_INCLUDE_PATH=3D/usr/include/c++/v1 /usr/local/bin/g++49 -std=3Dc++11=
-nostdinc++ -L/usr/lib
> CPP=3D/usr/local/bin/cpp49
> .export CC
> .export CXX
> .export CPP
> =
AS=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/a=
s
> =
AR=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/a=
r
> =
LD=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/l=
d
> =
NM=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/n=
m
> =
OBJCOPY=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/=
bin/objcopy
> =
OBJDUMP=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/=
bin/objdump
> =
RANLIB=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/b=
in/ranlib
> =
SIZE=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin=
/size
> #NO-SUCH: =
STRINGS=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/=
bin/strings
> STRINGS=3D/usr/local/bin/strings
> .export AS
> .export AR
> .export LD
> .export NM
> .export OBJCOPY
> .export OBJDUMP
> .export RANLIB
> .export SIZE
> .export STRINGS
> .endif
>=20
> # more /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG=20
> #
> # GENERIC -- Custom configuration for the powerpc/powerpc64
> #
>=20
> include "GENERIC64"
>=20
> ident GENERIC64vtsc-NODGB
>=20
> makeoptions DEBUG=3D-g # Build kernel with gdb(1) =
debug symbols
>=20
> nooptions PS3 # Sony Playstation 3 =
HACK!!! to allow sc
>=20
> options KDB # Enable kernel debugger =
support
>=20
> # For minimum debugger support (stable branch) use:
> options KDB_TRACE # Print a stack trace for a =
panic
> options DDB # Enable the kernel debugger
> options GDB # HACK!!! ...
>=20
> # Extra stuff:
> #options VERBOSE_SYSINIT # Enable verbose sysinit =
messages
> #options BOOTVERBOSE=3D1
> #options BOOTHOWTO=3DRB_VERBOSE
> #options KTR
> #options KTR_MASK=3DKTR_TRAP
> ##options KTR_CPUMASK=3D0xF
> #options KTR_VERBOSE
>=20
> # HACK!!! to allow sc for 2560x1440 display on Radeon X1950 that vt =
historically mishandled during booting
> device sc
> #device kbdmux # HACK: already listed by vt
> options SC_OFWFB # OFW frame buffer
> options SC_DFLT_FONT # compile font in
> makeoptions SC_DFLT_FONT=3Dcp437
>=20
> # Disable any extra checking for. . .
> nooptions DEADLKRES # Enable the deadlock resolver
> nooptions INVARIANTS # Enable calls of extra sanity =
checking
> nooptions INVARIANT_SUPPORT # Extra sanity checks of =
internal structures, required by INVARIANTS
> nooptions WITNESS # Enable checks to detect =
deadlocks and cycles
> nooptions WITNESS_SKIPSPIN # Don't run witness on =
spinlocks for speed
> nooptions DIAGNOSTIC
> nooptions MALLOC_DEBUG_MAXZONES # Separate malloc(9) zones
>=20
>=20
> # svnlite diff /usr/src/sys/powerpc/ofw/ofw_machdep.c=20
> Index: /usr/src/sys/powerpc/ofw/ofw_machdep.c
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- /usr/src/sys/powerpc/ofw/ofw_machdep.c (revision 308247)
> +++ /usr/src/sys/powerpc/ofw/ofw_machdep.c (working copy)
> @@ -111,6 +111,24 @@
> * Assume that interrupt are disabled at this point, or
> * SPRG1-3 could be trashed
> */
> +#if defined(AIM) && defined(__powerpc64__)
> +/* HACK: PowerMac G5 specific code to avoid demonstrated hangs in
> + * the early boot time frame: avoid mtsprg0 use.
> + * This would need a live test for PowerMac vs. not in order
> + * to remove HACK status --but without calling into
> + * OpenFirmware or the problem would be recreated.
> + */
> + if (1)
> + __asm __volatile("mfsprg0 %0\n\t"
> + "mtsprg1 %1\n\t"
> + "mtsprg2 %2\n\t"
> + "mtsprg3 %3\n\t"
> + : "=3D&r"(ofw_sprg0_save)
> + : "r"(ofmsr[2]),
> + "r"(ofmsr[3]),
> + "r"(ofmsr[4]));
> + else
> +#endif
> __asm __volatile("mfsprg0 %0\n\t"
> "mtsprg0 %1\n\t"
> "mtsprg1 %2\n\t"
>=20
>=20
>=20
>=20
> You have not sent out such materials for anyone to look at
> so I've no clue what all the differences might be in what
> you have.
>=20
> =3D=3D=3D
> Mark Millard
> markmi at dsl-only.net
As for building powerpc64-gcc on a powerpc64 environment (self hosting):
I use portmaster and its -DK options to leave the material in place:
portmaster -DK devel/powerpc64-xtoolchain-gcc
I let it run until it fails. Then I fix up 6 files it mishandles
for self-hosting (the below show my personal file path prefix choice:
/usr/obj/portswork/ for where ports are built --adjust as necessary):
(the lines below are very long and will likely wrap)
# more powerpc64-gcc_fixup.sh
#!/bin/sh
cp -ax =
/usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/.build/gcc/gcov =
/usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/bin/=
powerpc64-portbld-freebsd12.0-gcov
cp -ax =
/usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/.build/gcc/gcov-tool=
=
/usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/bin/=
powerpc64-portbld-freebsd12.0-gcov-tool
gzip -c =
/usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/gcc-*/gcc/doc/cpp.1 =
> =
/usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/man/=
man1/powerpc64-portbld-freebsd12.0-cpp.1.gz
gzip -c =
/usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/.build/gcc/doc/g++.1=
> =
/usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/man/=
man1/powerpc64-portbld-freebsd12.0-g++.1.gz
gzip -c =
/usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/.build/gcc/doc/gcc.1=
> =
/usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/man/=
man1/powerpc64-portbld-freebsd12.0-gcc.1.gz
gzip -c =
/usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/gcc-*/gcc/doc/gcov.1=
> =
/usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/man/=
man1/powerpc64-portbld-freebsd12.0-gcov.1.gz
I then use -C as well in portmaster to have it continue without first
cleaning up the prior material:
portmaster -CDK devel/powerpc64-xtoolchain-gcc
=3D=3D=3D
Mark Millard
markmi at dsl-only.net
_______________________________________________
freebsd-ppc@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ppc
To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?56703830-B39E-41DE-A5FA-B9C3673EA643>