On 2017-Apr-30, at 9:40 AM, Andrew Turner <andrew at fubar.geek.nz> wrote:

>> On 30 Apr 2017, at 12:02, Mark Millard <markmi at dsl-only.net> wrote:
>> On 2017-Apr-30, at 1:57 AM, Andrew Turner <andrew at fubar.geek.nz> wrote:
>>>> On 30 Apr 2017, at 04:29, Mark Millard <markmi at dsl-only.net> wrote:
>>>> ...
>>>> acpi0: <BOCHS BXPCFACP>
>>>> 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: <blue:heartbeat> 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
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 
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: <Open Firmware Device Tree>
psci0: <ARM Power State Co-ordination Interface Driver> on ofwbus0
gic0: <ARM Generic Interrupt Controller> mem 
 irq 18 on ofwbus0
gic0: pn 0x0, arch 0x0, rev 0x0, implementer 0x0 irqs 32
generic_timer0: <ARMv8 Generic Timer> irq 0,1,2,3 on ofwbus0
Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality 1000
Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality 1000
cpulist0: <Open Firmware CPU Group> on ofwbus0
cpu0: <Open Firmware CPU> on cpulist0
cpu1: <Open Firmware CPU> on cpulist0
cpu2: <Open Firmware CPU> on cpulist0
cpu3: <Open Firmware CPU> on cpulist0
pmu0: <Performance Monitoring Unit> irq 4,5,6,7 on ofwbus0
pmu0: could not allocate resources
device_attach: pmu0 attach returned 6
gpioled0: <GPIO LEDs> on ofwbus0
gpioled0: <blue:heartbeat> failed to map pin
cryptosoft0: <software crypto>
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 \
        -device virtio-blk-device,drive=hd0 \
        -device virtio-net-device,netdev=net0 \
        -netdev user,id=net0 \
        -smp cpus=4

based on:


but this time based on my build of head -r317015 .

I first got to the point of replicating what I'd
reported for:


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
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to