You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hey buddy, thanks for your help so far. I'm afraid I don't use telegram.
Perhaps if we stay here we can potentially help out someone else who experiences the same issue.
After upgrading Big Sur & reinstalling the command-line tools, make seems to generate x86_64 object files... this only happened after the update (I think). Any idea what's causing it?
Running cc, gcc, or clang without any flags generate arm64, as expected. Even running the very same command that make (ninja) is running generates arm64. But inside the build arch is somehow x64.
I managed to get around the problem by editing build.ninja and adding arch --arm64e at the beginning of every command (cc, c++, clang). This is so weird that it was x86 by default. Now I've built it and it runs!
I tried running the Debian 10.7.0 installer, and I had to add these flags:
#!/bin/bash
windows10vhdx="disk_images/Windows10_InsiderPreview_Client_ARM64_en-us_21354.VHDX windows.qcow2"
virtio-win-iso="disk_images/virtio-win-0.1.190.iso"
efi_firm="$(dirname $(which qemu-img))/../share/qemu/edk2-aarch64-code.fd"
dd if=/dev/zero conv=sync bs=1m count=64 of=windows_ovmf_vars.fd
qemu-img convert -O qcow2 "$windows10vhdx" windows.qcow2
echo "starting"
qemu-system-aarch64 \
-machine virt,accel=hvf,highmem=off \
-cpu cortex-a72 -smp 4 -m 4G \
-device ramfb \
-device qemu-xhci,id=usb-bus \
-device usb-tablet,bus=usb-bus.0 \
-device usb-mouse,bus=usb-bus.0 \
-device usb-kbd,bus=usb-bus.0 \
-nic user,model=virtio \
-drive format=raw,file="$efi_firm",if=pflash,readonly=on \
-drive format=raw,file=windows_ovmf_vars.fd,if=pflash \
-drive if=none,media=disk,id=drive0,format=qcow2,file=windows.qcow2 \
-device nvme,drive=drive0,serial=drive0,bootindex=0 \
-device usb-storage,drive=drive2,removable=true,bootindex=2 \
-drive if=none,media=cdrom,id=drive2,file="$virtio-win-iso"
# To enable networking after installing:
# 1. run `bcdedit.exe -set TESTSIGNING ON`
# 2. Open device manager and find the unknown ethernet device.
# 3. Choose to update and search for the driver on the computer.
# 4. Navigate to and select D:\NetKVM\w10\ARM64
You will need to download the Windows VHDX from here and the latest virtio-win iso from here
Be sure to update windows10vhdx and virtio-win-iso to have the proper paths to the VHDX and iso respectively. I created a directory within my vm directory called "disk_images" and put them there for organization's sake.
Something you could do with this is create an extra drive that can be used for multiple different machines. If you do that, however, be sure to only run one machine at any given time because I'm sure it would cause severe corruption if both were to write to the drive at the same time.
Another thing to be aware of:
Unfortunately ARM64 Windows doesn't have virtio-gpu drivers yet (as far as I can tell, and I've searched hard for them) so we're stuck with ramfb. I'm not entirely sure, but I think this means everything is rendered in software. Additionally, my machine appears to be restricted to three different resolutions: 640x480, 800x600, and 1024x768. You can set this by hitting escape on the "TianoCore" screen before the windows loading dot circle thing.
I am building qemu on Mac Mini Silicon M1 according to the above instructions, it successfully compiled, but the utility only supports the 'tcg' accelerator.
./qemu-system-aarch64 -accel help
Accelerators supported in QEMU binary:
tcg
I examined the configuration output, the compiler detected that the CPU is x86_64:
Compilation
host CPU: x86_64
host endianness: little
Targets and accelerators
KVM support: NO
HAX support: NO
HVF support: NO
WHPX support: NO
NVMM support: NO
Xen support: NO
TCG support: YES
TCG backend: native (x86_64)
TCG debug enabled: NO
target list: aarch64-softmmu
default devices: YES
out of process emulation: NO
is it worth the update? how do i know which commit to apply the patch on? thanks
@cattyhouse the updates are always worthy, feel free to update to latest, I'm not currently using virtualization, if it was for me, I'd always go with latest updates, commits you can test at different dates
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.
Definitely an M1 problem. I tried using lcurl flag but did not work. Any ideas? @nrjdalal
@KPhans the version installed via brew works great out of the box now. Here's a wrapper script I use, which helps get the qemu command line args right:
@KPhans the version installed via brew works great out of the box now. Here's a wrapper script I use, which helps get the qemu command line args right:
since you guys are using bash/zsh, you can always use array to have a better syntax
#!/bin/bash#~/bin/qemu_ubuntu
options=(
# this is a comment# enable hvf for the best performance
-machine virt,accel=hvf
# use a newer cpu, you can also use 'host' with qemu 7.0#-cpu host
-cpu cortex-a72
# let's do 4core and 4GB RAM
-smp 4 -m 4G
# add a cd rom for the first time boot
-cdrom ubuntu-lts.iso
# let's go on, add anything you want
)
qemu-system-aarch64 "${options[@]}"
@ovidiy1 try -display default,show-cursor=on