svn commit: r302214 - head/sys/powerpc/aim ["set usefdt=1" gets farther if I unload first; result more interesting]

Wed Nov 16 23:47:58 UTC 2016

[I pondered some more and came up with another test with different
results: gets farther before crashing.]

On 2016-Nov-16, at 2:40 PM, Mark Millard <markmi at dsl-only.net> wrote:

> [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 the PowerMac11,3 I've now tried at the loader prompt:

Ok unload
Ok set usefdt=1
Ok boot

(or autoboot). This does get farther in the boot sequence
(from hand written notes):

. . .
cpu3: dev=0xc7f0
random: unblocking device
random: entropy device external interface
kdb0 at kdbmux0

fatal kernel trap

exception = 0x700 (program)
     srr0 = 0x10c384
     srr1 = 0x9000000000081032
curthread = 0x12177a0
   pid = 0 comm = swapper

[thread pid 0 tid 100000]
stopped at .xpt_lock_buses: illegal instruction 0
db>

Multiple tries stopped at this same point with the same
text showing.

It is not far enough along to take input to the db> prompt.
But I could rebuild with an internal db script that executes
before the db> prompt appears.

objdump -d /boot/kernel/kernel shows:

. . .
  10c374:       4e 80 00 20     blr
  10c378:       00 00 00 00     .long 0x0
  10c37c:       00 00 00 01     .long 0x1
  10c380:       80 05 00 00     lwz     r0,0(r5)

000000000010c384 <.xpt_lock_buses>:
  10c384:       7c 08 02 a6     mflr    r0
  10c388:       f8 01 00 10     std     r0,16(r1)
  10c38c:       fb e1 ff f8     std     r31,-8(r1)
  10c390:       f8 21 ff 81     stdu    r1,-128(r1)
  10c394:       7c 3f 0b 78     mr      r31,r1
  10c398:       7d a4 6b 78     mr      r4,r13
  10c39c:       60 00 00 00     nop
  10c3a0:       e9 22 83 58     ld      r9,-31912(r2)
  10c3a4:       2b a9 00 04     cmpldi  cr7,r9,4
  10c3a8:       40 9e 00 44     bne     cr7,10c3ec <.xpt_lock_buses+0x68>
. . .

That does not match 0 as the encoding at 0x10c384, suggesting that the
code has not been correctly loaded and made available to the processor.

Older notes. . .

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

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