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 ?[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: <Open Firmware Device Tree> psci0: <ARM Power State Co-ordination Interface Driver> on ofwbus0 gic0: <ARM Generic Interrupt Controller> 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: <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 \ -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 _______________________________________________ firstname.lastname@example.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"