Speed up Ampere Altra boot time

General Discussion
1

I’m using an Ampere Altra as a QNX kernel development system. The board works great, but boot times are atrocious, which is not great for kernel development. It takes a couple of minutes for the firmware to do whatever it does, with debug output along the lines of PROGRESS CODE: V03040002 I0. This is even before I get the prompt to select a boot device.

I realize this is a server-class machine that is not expected to boot too often, but is there any way to skip these checks?

2

The easiest way I’ve gotten boot times down is by replacing AMI Aptio with EDKII. The boot times are just a couple minutes.

2 Likes
3

Thanks for the reply. I’m not sure what firmware is currently flashed on the machine, but will check later. Unfortunately, “a couple of minutes” is exactly what I’m trying to speed up - I’m used to an entire boot sequence (from powering up a machine to a working OS) taking single-digit seconds.

1 Like
4

The first good chunk which is the slowest is pretty much impossible to optimize. The memory training and CPU checks are burned into the maskrom afaik. I don’t think you can do any better than a couple minutes.

2 Likes
5

I want to throw it out there - hardware has very well-functioning SRIOV. You can pass through PCI-E hardware to VMs in Incus\LXD, Libvirt, Qemu\KVM

Do you have a strong reason for booting the kernel repeatedly on bare metal? You might be better served through virtualization.

I have not used QNX but it seems they do offer relevant info
Creating a QNX virtual machine

6

Thanks, Dylan. As QNX’s lead architect I am aware of the virtualization option :wink:

The reason I’m not happy going down this path is that my main use case for the Altra is to test the performance (both throughput and latency) of various kernel changes on a machine with many cores. Virtualization typically gets in the way, especially when our interrupt latency targets are what they are (average of 1-2us, maximum of 20us). You might be able to get there with very strict limitations on the hypervisor (e.g., 1-1 mapping of vCPU to CPU). We do have our own hypervisor working on this board, so I might actually look at the numbers - maybe my hesitation is unjustified.