With: http://snapshots.linaro.org/components/kernel/leg-virt-tianocore-edk2-upstream/1917/QEMU-AARCH64/RELEASE_CLANG35/QEMU_EFI.fd for QEMU_EFI.fd and with: http://ftp1.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/12.0-CURRENT/aarch64/20170420/FreeBSD-12.0-CURRENT-arm64-aarch64-20170420-r317181.raw.xz for FreeBSD's .raw file (after unxz) I tried: 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 on an odroid-c2 running UbuntuMate: # uname -a Linux odroidc2UbMate 3.14.79-110 #1 SMP PREEMPT Tue Apr 11 20:16:54 BRT 2017 aarch64 aarch64 aarch64 GNU/Linux The result was: . . . Booting [/boot/kernel/kernel]... No valid device tree blob found! WARNING! Trying to fire up the kernel, but no device tree blob found! . . . generic_timer0: <ARM Generic Timer> irq 29,30,27 on acpi0 panic: Attempt to copy invalid resource id: 29 In full detail: >> FreeBSD EFI boot block Loader path: /boot/loader.efi Initializing modules: ZFS UFS Probing 5 block devices.......* done ZFS found no pools UFS found 1 partition Consoles: EFI console Command line arguments: loader.efi Image base: 0x763b1000 EFI version: 2.60 EFI Firmware: EDK II (rev 1.00) FreeBSD/arm64 EFI loader, Revision 1.1 (Thu Apr 20 16:51:44 UTC 2017 root_at_releng3.nyi.freebsd.org) EFI boot environment Loading /boot/defaults/loader.conf /boot/kernel/kernel text=0x7b6848 data=0xa0578+0x43b3be syms=[0x8+0x106938+0x8+0xfb67b] \ Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... No valid device tree blob found! WARNING! Trying to fire up the kernel, but no device tree blob found! 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 #0 r317181: Thu Apr 20 16:54:23 UTC 2017 root_at_releng3.nyi.freebsd.org:/usr/obj/arm64.aarch64/usr/src/sys/GENERIC arm64 FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0) WARNING: WITNESS option enabled, expect reduced performance. VT: init without driver. Starting CPU 1 (1) Starting CPU 2 (2) Starting CPU 3 (3) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs arc4random: no preloaded entropy cache random: entropy device external interface kbd0 at kbdmux0 acpi0: <BOCHS BXPCFACP> acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) psci0: <ARM Power State Co-ordination Interface Driver> on acpi0 generic_timer0: <ARM Generic Timer> irq 29,30,27 on acpi0 panic: Attempt to copy invalid resource id: 29 cpuid = 0 time = 1 KDB: stack backtrace: db_trace_self() at db_trace_self_wrapper+0x28 pc = 0xffff0000005db8a0 lr = 0xffff000000088910 sp = 0xffff0000000102a0 fp = 0xffff0000000104b0 db_trace_self_wrapper() at vpanic+0x184 pc = 0xffff000000088910 lr = 0xffff00000030a774 sp = 0xffff0000000104c0 fp = 0xffff000000010540 vpanic() at panic+0x48 pc = 0xffff00000030a774 lr = 0xffff00000030a800 sp = 0xffff000000010550 fp = 0xffff0000000105d0 panic() at intr_map_copy_map_data+0x164 pc = 0xffff00000030a800 lr = 0xffff000000616600 sp = 0xffff0000000105e0 fp = 0xffff000000010630 intr_map_copy_map_data() at intr_activate_irq+0xd8 pc = 0xffff000000616600 lr = 0xffff000000616280 sp = 0xffff000000010640 fp = 0xffff000000010690 intr_activate_irq() at nexus_activate_resource+0xb8 pc = 0xffff000000616280 lr = 0xffff0000005e77b8 sp = 0xffff0000000106a0 fp = 0xffff0000000106d0 nexus_activate_resource() at nexus_alloc_resource+0x10c pc = 0xffff0000005e77b8 lr = 0xffff0000005e76cc sp = 0xffff0000000106e0 fp = 0xffff000000010730 nexus_alloc_resource() at resource_list_alloc+0x1d4 pc = 0xffff0000005e76cc lr = 0xffff00000033bf94 sp = 0xffff000000010740 fp = 0xffff000000010790 resource_list_alloc() at acpi_alloc_resource+0x17c pc = 0xffff00000033bf94 lr = 0xffff0000000924fc sp = 0xffff0000000107a0 fp = 0xffff000000010850 acpi_alloc_resource() at bus_alloc_resources+0xd8 pc = 0xffff0000000924fc lr = 0xffff00000033dfa4 sp = 0xffff000000010860 fp = 0xffff0000000108b0 bus_alloc_resources() at arm_tmr_attach+0xc8 pc = 0xffff00000033dfa4 lr = 0xffff0000005ca394 sp = 0xffff0000000108c0 fp = 0xffff0000000108f0 arm_tmr_attach() at device_attach+0x404 pc = 0xffff0000005ca394 lr = 0xffff00000033b60c sp = 0xffff000000010900 fp = 0xffff000000010950 device_attach() at bus_generic_attach+0x50 pc = 0xffff00000033b60c lr = 0xffff00000033c808 sp = 0xffff000000010960 fp = 0xffff000000010980 bus_generic_attach() at acpi_attach+0xd44 pc = 0xffff00000033c808 lr = 0xffff000000091b98 sp = 0xffff000000010990 fp = 0xffff000000010a40 acpi_attach() at device_attach+0x404 pc = 0xffff000000091b98 lr = 0xffff00000033b60c sp = 0xffff000000010a50 fp = 0xffff000000010aa0 device_attach() at bus_generic_new_pass+0x120 pc = 0xffff00000033b60c lr = 0xffff00000033ced0 sp = 0xffff000000010ab0 fp = 0xffff000000010ae0 bus_generic_new_pass() at bus_generic_new_pass+0xe4 pc = 0xffff00000033ced0 lr = 0xffff00000033ce94 sp = 0xffff000000010af0 fp = 0xffff000000010b20 bus_generic_new_pass() at bus_set_pass+0x8c pc = 0xffff00000033ce94 lr = 0xffff000000339114 sp = 0xffff000000010b30 fp = 0xffff000000010b60 bus_set_pass() at mi_startup+0xc8 pc = 0xffff000000339114 lr = 0xffff0000002a8c34 sp = 0xffff000000010b70 fp = 0xffff000000010bb0 mi_startup() at virtdone+0x54 pc = 0xffff0000002a8c34 lr = 0xffff000000001084 sp = 0xffff000000010bc0 fp = 0x0000000000000000 KDB: enter: panic [ thread pid 0 tid 100000 ] Stopped at kdb_enter+0x40: undefined d4200000 db> Historical note: I last tried this sort of thing was back in 2016-September with 11-RELEASE and it booted but there were later problems. I tried the above because of the two recent fixes that remove aarch64-specific problems that were happening during fork. (There is no snapshot of stable/11 that has both of those fixes yet --and I've been using CURRENT anyway.) Some notes from back in 2016-August through 2016-October by other folks are at: https://forum.odroid.com/viewtopic.php?t=23356 The Odroid-C2 has also had various software updates since my earlier attempt so nothing has a known-good status for the purpose as far as my history goes. I can not lay blame as stands. === Mark Millard markmi at dsl-only.netReceived on Sun Apr 30 2017 - 01:29:12 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:11 UTC