FreeBSD OS installation stuck after selecting Boot installer

[arjun.a.14]

I am trying to bring up FreeBSD OS(FreeBSD-15.0-CURRENT-arm64-aarch64-20240523-1e84b85aad10-270337-memstick.img or any other FreeBSD version) on Intel IPU E2100 (https://www.intel.com/content/www/us/en/products/details/network-io/ipu.html) from UEFI environment.
Installation however fails on Arm Neoverse N1 CPU Cores at up to 3.0GHz with below errors:

Since the IPU E2100 does not support device tree, i have tried to disable it with below cmds and also made sure to enable ACPI(which was enabled by default with FreeBSD-above screenshot). As, enabling ACPI should not require device tree
From the BSD Boot Loader Prompt, i did set following options but still ran into install issue(below screenshot):

set boot_serial="YES"
echo boot_serial is set to ${boot_serial}
set comconsole_speed="115200"
echo comconsole_speed is set to ${comconsole_speed}

set hint.acpi.0.disabled=0
set hint.fdt.0.disabled=1

OK set acpi_load="YES"
OK echo acpi_load is set to ${acpi_load}
acpi_load is set to YES

OK set fdt_enable="NO"
OK echo fdt_enable is set to ${fdt_enable}
fdt_enable is set to NO
OK boot

Other OS's like Ubuntu, Rocky Linux installs just fine. So, any pointers to solve this FreeBSD issue is much appreciated..
Thanks

 

[SirDice]

FreeBSD-15.0-CURRENT

Topics about unsupported FreeBSD versions

The FreeBSD Forums cater primarily to end-users and systems administrators. As such, the Forums focus almost exclusively on FreeBSD versions that are officially supported according to the official FreeBSD website. Since resources are scarce, the FreeBSD Forums strongly suggest that anyone asking...

forums.freebsd.org

 

[arjun.a.14]

Same issue seen on https://download.freebsd.org/releases/ISO-IMAGES/14.1/ as well as other previous releases..

 

[bakul]

This seems to be some specialized hardware. I very much doubt FreeBSD would work on it.

Other OS's like Ubuntu, Rocky Linux installs just fine.

I read somewhere "The Intel IPU E2100 represents the inaugural public iteration of the series for clientele beyond Google." so very likely Intel &/or Google helped with this, who have a few more resources than FreeBSD.

 

[arjun.a.14]

This seems to be some specialized hardware. I very much doubt FreeBSD would work on it.

I read somewhere "The Intel IPU E2100 represents the inaugural public iteration of the series for clientele beyond Google." so very likely Intel &/or Google helped with this, who have a few more resources than FreeBSD.

As mentioned in product brief : https://www.intel.com/content/www/us/en/products/details/network-io/ipu/adapter-e2100.html E2100 is available for all customers and there should be no reason FreeBSD shouldn't work on this, as other OS's like Ubuntu, RHEL and Rocky Linux installs by default.
Issue only seen with FreeBSD, so any pointers for further debug from FreeBSD experts are much appreciated..

 

[bakul]

there should be no reason FreeBSD shouldn't work on this, as other OS's like Ubuntu, RHEL and Rocky Linux installs by default.

FreeBSD is not Linux nor a Linux distro.

 

[sko]

Given this is rather new and *very* specialized niche hardware, I would advise seeking help on the freebsd-arm mailing list [1]. This is where you find most of the developers and hence will likely find the right person(s) who can assist in getting it to work and make sure possible patches will be committed.

[1] https://lists.freebsd.org/subscription/freebsd-arm

 

[arjun.a.14]

Hi,

After trying some UART related configurations, i was able to move past the Garbage print outs, but still get stuck with EFI Frame buffer information.
I was told that the warning related to device tree blob can be ignored..

I also saw number of other posts related to this issue : https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209821
So, any inputs from the community is appreciated..

 

[Cath O'Deray]

… stuck with EFI Frame buffer information. …

Maybe staging. From release notes for 13.1:

"… The loader detects whether the loaded kernel can handle the in-place staging area (non-copying mode). The default is copy_staging auto. Auto-detection can be overridden, for example: with copy_staging enable, the loader will unconditionally copy the staging area to 2M, regardless of kernel capabilities."

loader.efi(8)