general/other Apple Virtualization (ARM64 - M2 SoC)

T

taiwan740

Honestly not sure if this is a FreeBSD issue or more in Apple's camp.

I've got an M2 Macbook Pro, and I'm trying to virtualise FreeBSD on it using UTM. UTM can harness Apple Virtualization, but notes it is experimental. I can boot the ARM64 version of Fedora Linux using it and it works really well, impressively so.

Unfortunately, when I swap out the Fedora Workstation ISO for the FreeBSD 13.2 RELEASE aarch64 disc1 install ISO, I get the bootloader, and it attempts to boot the kernel and then seems to immediately reboot. Unfortunately, this sequence is too fast for my eyeballs to see any messages on screen, and as it is the install iso, I'm not sure I can capture any panic or crash info.

The same ISO boots fine using QEMU via UTM.

I don't really *need* this to work, but would be fun to investigate what is going wrong, so any advice you could give for me to provide further information on the crashing issue, I'd be happy to oblige.
 
OK I managed to capture it, please forgive me as I have to type it all out, and it's small text too

Code: 
Consoles: EFI Console
Reading loader env vars from /efi/freebsd/loader.env
Setting currdev to disk1p1:
FreeBSD/arm64 EFI Loader, Revision 1.1

Command line arguments: loader.efi
Image base: Rxl16e57f000
EFI version: 2.70
EFI firmware: EDK 11 (rev 1.00)
Console: efi (0)
Load path: \EFI\BOOT\BOOTRA64.EFI
Load device: <no chance I'm typing all that out as I can't even read it>
BootCurrent: 0001

etc...

Ignoring Boot0001: Only one DP found

Please set hw.efifb.address and hw.efifb.stride

Nothing else, just loops back to the boot loader.
 
taiwan740 said:
Ignoring Boot0001: Only one DP found
Please set hw.efifb.address and hw.efifb.stride
Click to expand...
To me that looks like a UEFI boot menu entry.

I would start by investigating boot options with efibootmgr.

Being virt maybe it is the EDK2 BIOS for the VM.
You can enter the virtual BIOS with F2 or ESC key.
 
I use UTM on a M2 Mac Mini. I created an arm64 image. I use this system to build packages with Poudriere.
The target system for the packages is an Orange Pi 5 Plus. The Orange Pi is slow and not fit for Poudriere.
The UTM on the Mac Mini creates packages at an acceptable speed.
I also use UTM to buildworld and install system updates to the Orange Pi using nfs.

The difference is I installed FreeBSD 15.

The only problem I had during install was creating the disk image.
gpart would not use the blank UTM created image.
I copied in a FreeBSD 15 qcow2 image as my starter image. Then in UTM used the
resize image. Next booted from the FreeBSD arm64 current iso.
Installed FreeBSD as normal.

This setup works well to feed packages and updates to Orange Pi 5 Plus.
 
You must log in or register to reply here.
Back
Top