On 2017-Apr-30, at 9:40 AM, Andrew Turner wrote:
>> On 30 Apr 2017, at 12:02, Mark Millard wrote:
>>
>> On 2017-Apr-30, at 1:57 AM, Andrew Turner wrote:
>>
On 30 Apr 2017, at 04:29, Mark Millard wrote:
...
acpi0:
acpi0: Power Button (fixed)
acpi0: Sleep Button (fixed)
>>>
>>> ACPI is not fully supported on arm64.
>>
>> Good to know. Thanks.
>>
>> But the messages:
>>
>> No valid device tree blob found!
>> WARNING! Trying to fire up the kernel, but no device tree blob found!
>>
>> were well before the acpi0 messages so I'd expect
>> that the lack of a "device tree blob" is a separate,
>> earlier issue, likely to do with the content of:
>>
>> FreeBSD-12.0-CURRENT-arm64-aarch64-20170420-r317181.raw
>
> No, the device tree blob comes from UEFI. It seems the current UEFI only
> provides the ACPI tables, and not a DTB.
So you are expecting that the older QEMU_EFI.fd I had
used before provided some sort of fairly generic dtb
(relative to qemu, fairly independent of the host
that was running qemu). Interesting. Thanks again.
It turns out that if I put the odroid-c2's dtb in where
I can load it from the loader prompt (e.g., in /boot/dtb/ )
I get a little farther, although with notices for:
Failed to start CPU 1 (1)
Failed to start CPU 2 (2)
Failed to start CPU 3 (3)
pmu0: could not allocate resources
device_attach: pmu0 attach returned 6
gpioled0: failed to map pin
usb_needs_explore_all: no devclass
The details of the sequence are:
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel] in 9 seconds...
Type '?' for a list of commands, 'help' for more detailed help.
OK load -t dtb /boot/dtb/meson64_odroidc2.dtb
/boot/dtb/meson64_odroidc2.dtb size=0x746c
OK boot
?[37m?[44mBooting...?[m
Using DTB from loaded file '/boot/dtb/meson64_odroidc2.dtb'.
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2017 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 12.0-CURRENT r317015M arm64
FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM
4.0.0)
VT: init without driver.
Starting CPU 1 (1)
Failed to start CPU 1 (1)
Starting CPU 2 (2)
Failed to start CPU 2 (2)
Starting CPU 3 (3)
Failed to start CPU 3 (3)
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
arc4random: no preloaded entropy cache
random: entropy device external interface
kbd0 at kbdmux0
ofwbus0:
psci0: on ofwbus0
gic0: mem
0xc4301000-0xc4301fff,0xc4302000-0xc4303fff,0xc4304000-0xc4305fff,0xc4306000-0xc4307fff
irq 18 on ofwbus0
gic0: pn 0x0, arch 0x0, rev 0x0, implementer 0x0 irqs 32
generic_timer0: irq 0,1,2,3 on ofwbus0
Timecounter "ARM MPCore Timecounter" frequency 2400 Hz quality 1000
Event timer "ARM MPCore Eventtimer" frequency 2400 Hz quality 1000
cpulist0: on ofwbus0
cpu0: on cpulist0
cpu1: on cpulist0
cpu2: on cpulist0
cpu3: on cpulist0
pmu0: irq 4,5,6,7 on ofwbus0
pmu0: could not allocate resources
device_attach: pmu0 attach returned 6
gpioled0: on ofwbus0
gpioled0: failed to map pin
cryptosoft0:
Timecounters tick every 1.000 msec
usb_needs_explore_all: no devclass
As of that it hangs.
Using something like pine64_plus.dtb did not get
far at all compared to the above.
It is possible that for "-enable-kvm -cpu host" that
the dtb needs to match the host machine's dtb.
Still, it is not like what I thought I remembered from
back in 2016-September: I did no dtb manipulations
back then since I was unaware of the issue.
The above is console output is for. . .
qemu-system-aarch64 -m 1024M -enable-kvm -cpu host -M virt \
-bios QEMU_EFI.fd -nographic \
-drive
format=raw,if=none,file=FreeBSD-12.0-CURRENT-arm64-aarch64-20170420-r317181.raw,id=hd0
\
-device virtio-blk-device,drive=hd0 \
-device virtio-net-device,netdev=net0 \
-netdev user,id=net0 \
-smp cpus=4
based on:
http://snapshots.linaro.org/components/kernel/leg-virt-tianocore-edk2-upstream/1917/QEMU-AARCH64/RELEASE_CLANG35/QEMU_EFI.fd
but this time based on my build of head -r317015 .
I first got to the point of replicating what I'd
reported for:
FreeBSD-12.0-CURRENT-arm64-aarch64-20170420-r317181.raw
then I added the 2 .dtb files to try loading. The
Odroid-C2 one worked better on the Odroid-C2.
It seems that qemu does not have a general dtb
emulation capability. (No surprise there?) But
I did not find anything saying what was required.
===
Mark Millard
markmi at dsl-only.net
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
