svn commit: r302214 - head/sys/powerpc/aim ["set usefdt=1" test fails on PowerMac7,2 as well]

Wed Nov 16 22:40:55 UTC 2016

[Top post of a new "set usefdt=1" test on a different type of PowerMac.]

I now have the SSD at -r308247 of head and have also tried "set usefdt=1" at
the loader prompt on a PowerMac7,2 (before it was a PowerMac11,3 that was
tested).

> Ok set usefdt=1
> Ok boot

still failed. (My SPRG0 PowerMac G5 boot-reliability hack is present in what
I tested.)

It got another "Error -2 adding node" but was adding a CPU node (PPC970).
It hung just after the "kernel entry at 0x100120" message (earlier than
the prior report relative to the message outputs shown).

All I have access to for powerpc64 are a couple of PowerMac11,3's and the
one PowerMac7,2 so those are all that I can test.

[The PowerMac11,3 test likely was using sc but this PowerMac7,2 was using
vt --in case that might matter for something.]

If it is likely to make a difference I could try without the SPRG0 hack. But
so far you have not reported that "set usefdt=1" would be likely to depend
on such details.

Otherwise as far as I know there is no more that I have context to help with
for this type of attempt to avoid depending on Apple's OpenFirmware in the
kernel. So far the SPRG0 hack has been the most useful technique for booting
reliably on PowerMac G5's. (And I've not been able to reproduce Jukka U.'s
iicsmb_load="YES" in /boot/loader.conf problems so the run-time module
loading issue is likely a distinct issue.)

===
Mark Millard
markmi at dsl-only.net

On 2016-Oct-18, at 5:30 PM, Mark Millard <markmi at dsl-only.net> wrote:

[I've finally got a access to the powerpc's and powerpc64's, at least for a little bit. But other things may take much of my time.]

Nathan Whitehorn nwhitehorn at freebsd.org  wrote on Sun Jun 26 23:38:36 UTC 2016 [back in 11-CURRENT days]:

>> . . .
>>> Author: nwhitehorn
>>> Date: Sun Jun 26 18:43:42 2016
>>> New Revision: 302214
>>> URL:
>>> https://svnweb.freebsd.org/changeset/base/302214
>>> 
>>> 
>>> Log:
>>>  Enter 64-bit mode as early as possible in the 64-bit PowerPC boot sequence.
>>>  Most of the effect of setting MSR[SF] is that the CPU will stop ignoring
>>>  the high 32 bits of registers containing addresses in load/store
>>>  instructions. As such, the kernel was setting it only when it began to
>>>  need access to high memory. MSR[SF] also affects the operation of some
>>>  conditional instructions, however, and so setting it at late times could
>>>  subtly break code at very early times. This fixes use of the FDT mode in
>>>  loader, and FDT boot more generally, on 64-bit PowerPC systems.
>>> 
>>>  Hardware provided by: IBM LTC
>>>  Approved by: re (kib)
>>> 
>>> Modified:
>>>  head/sys/powerpc/aim/aim_machdep.c
>>>  head/sys/powerpc/aim/locore64.S
>> . . .
> 
> . . .
> 
> One thing it would be great to have some testing on after this change is 
> the FDT layer in loader. If you set usefdt=1 from the loader prompt, 
> loader will distill the OF device tree into an FDT and then stop Open 
> Firmware completely before transferring control to FreeBSD. This should 
> avoid any possible problems accessing Open Firmware from the kernel, as 
> well as making boot a little faster.
> -Nathan

I updated the old 2016-June-1 SSD contents to head's -r302214 and did
buildworld and buildkernel and installed them, but with my PowerMac G5
boot-hack still present. This was to be the first test if things went
well for "set usefdst=1". They did not so no tests without the hack were
made.

A normal boot works fine for -r203214 but use of "set usefdt=1" before
"boot" fails.

A hand transcribed report of the visible "set usefdt=1" results are:

> Ok set usefdt=1
> Ok boot
> Booting...
> Error -2 adding node /ht at 0,f2000000/pci at 8/macio at 7/i2c at 18000/i2c-bus at 0 (i2c-bus at 0), skipping
> 
> kernel entry at 0x100120
> Invalid memory access at %SRR0: 00000000.00100120 %SRR1: 10000000.00083030

It then reports the Apple model and firmware version and and some other
Apple text and gets stuck. (Power switch time.)

Note: I've not updated /usr/ports so the modern binutils poewrpc64 issue
is not involved:

> #svnlite info /usr/ports/ | grep "Re[lv]"
> Relative URL: ^/head
> Revision: 415874
> Last Changed Rev: 415874

> # uname -apKU
> FreeBSD FBSDG5C0 11.0-ALPHA5 FreeBSD 11.0-ALPHA5 #40 r302214M: Tue Oct 18 06:11:02 PDT 2016     root at FBSDG5C0:/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/sys/GENERIC64vtsc-NODEBUG  powerpc powerpc64 1100120 1100120

devel/powrepc64-gcc was used to do the system builds and it is a libc++
based build.

> # svnlite info /usr/src/ | grep "Re[lv]"
> Relative URL: ^/head
> Revision: 302214
> Last Changed Rev: 302214

> # svnlite status /usr/src
> ?       /usr/src/.snap
> M       /usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
> M       /usr/src/lib/csu/powerpc64/Makefile
> ?       /usr/src/restoresymtable
> ?       /usr/src/sys/arm/conf/RPI2-NODBG
> M       /usr/src/sys/boot/ofw/Makefile.inc
> M       /usr/src/sys/boot/powerpc/Makefile
> M       /usr/src/sys/boot/powerpc/Makefile.inc
> M       /usr/src/sys/boot/uboot/Makefile.inc
> M       /usr/src/sys/conf/Makefile.powerpc
> M       /usr/src/sys/conf/kern.mk
> M       /usr/src/sys/conf/kmod.mk
> ?       /usr/src/sys/powerpc/conf/GENERIC64-NODBG
> ?       /usr/src/sys/powerpc/conf/GENERIC64vtsc
> ?       /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODEBUG
> ?       /usr/src/sys/powerpc/conf/GENERICvtsc
> ?       /usr/src/sys/powerpc/conf/GENERICvtsc-NODEBUG
> M       /usr/src/sys/powerpc/ofw/ofw_machdep.c
> M       /usr/src/sys/powerpc/powerpc/exec_machdep.c

===
Mark Millard
markmi at dsl-only.net

_______________________________________________
freebsd-ppc at freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ppc
To unsubscribe, send any mail to "freebsd-ppc-unsubscribe at freebsd.org"