Enabling ARM64 CPU Capabilities in the Linux Kernel

ARM64 design defines features long before there is a CPU that can implement those features. Since the ARM ecosystem is so varied, there are many different CPU designs out there with different capabilities. A general purpose linux Kernel build put out by a major distribution has to work across a wide array of chips by a large nuymber of vendors. Thus, there is an enumeration of the capabilities inside the Kernel and mechnism for describing how to probe each of these capabilities.

Continue reading

Finding Linux Kernel Config options in menuconfig

We have reason to believe that we should not be setting CONFIG_EFI_DISABLE_RUNTIME=y In our Kernel configs. I want to perform a controlled expereient booting two Kernel builds, one with this option set and one with it disabled. Since I have the option set, building that Kernel is trivial.

 make olddefconfig
 make -j$(nproc)  rpm-pkg

Now, to turn that option off, I could just edit the .config file. However, it is possible that there are other config options linked to that one, and there is logic to modify them together. I want to see what happens if I use make menuconfig to change the option to confirm (or deny) that only that option gets changed. But where do I find this option in the menu?

Continue reading

Building and Running the Linux Kernel Selftests on AARCH64/ Fedora

I won’t go into checking out or building the Kernel, as that is covered elsewhere. Assuming you have a buildable Kernel, you can build the tests with:

make -C tools/testing/selftests

But you are probably going to see errors like this:

ksm_tests.c:7:10: fatal error: numa.h: No such file or directory
    7 | #include <numa.h>
      |          ^~~~~~~~
compilation terminated.

The userland test suites use several libraries and need headers to compile the tests that call those libraries. Here is the yum, line I ran to get the dependencies I needed for my system:

sudo yum install libmnl-devel fuse-devel numactl-devel libcap-ng-devel alsa-lib-devel

With those installed, the make line succeeded.

Running the test like this CRASHED THE SYSTEM. Don’t do this.

 make -C tools/testing/selftests run_tests

A more sensible test to run is the example on the Docs page:

# make -C tools/testing/selftests TARGETS=ptrace run_tests
make: Entering directory '/root/linux/tools/testing/selftests'
make --no-builtin-rules ARCH=arm64 -C ../../.. headers_install
make[1]: Entering directory '/root/linux'
  INSTALL ./usr/include
make[1]: Leaving directory '/root/linux'
make[1]: Entering directory '/root/linux/tools/testing/selftests/ptrace'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/root/linux/tools/testing/selftests/ptrace'
make[1]: Entering directory '/root/linux/tools/testing/selftests/ptrace'
TAP version 13
1..3
# selftests: ptrace: get_syscall_info
# TAP version 13
# 1..1
# # Starting 1 tests from 1 test cases.
# #  RUN           global.get_syscall_info ...
# #            OK  global.get_syscall_info
# ok 1 global.get_syscall_info
# # PASSED: 1 / 1 tests passed.
# # Totals: pass:1 fail:0 xfail:0 xpass:0 skip:0 error:0
ok 1 selftests: ptrace: get_syscall_info
# selftests: ptrace: peeksiginfo
# PASS
ok 2 selftests: ptrace: peeksiginfo
# selftests: ptrace: vmaccess
# TAP version 13
# 1..2
# # Starting 2 tests from 1 test cases.
# #  RUN           global.vmaccess ...
# #            OK  global.vmaccess
# ok 1 global.vmaccess
# #  RUN           global.attach ...
 
 
# # attach: Test terminated by timeout
# #          FAIL  global.attach
# not ok 2 global.attach
# # FAILED: 1 / 2 tests passed.
# # Totals: pass:1 fail:1 xfail:0 xpass:0 skip:0 error:0
not ok 3 selftests: ptrace: vmaccess # exit=1
make[1]: Leaving directory '/root/linux/tools/testing/selftests/ptrace'
make: Leaving directory '/root/linux/tools/testing/selftests'

Next up is to write my own stub test.

A Non-authoritative history of Preemptive Multitasking in the personal computing world.

Back when machines only had one or two CPUs (still the case for embedded devices) the OS Kernel was responsible for making sure that the machine coule process more than one instruction “path” at a time. I started coding back on the Commodore 64, and there it was easy to lock up the machine: just run a program that does nothing. I’d have to look back at the Old Programmer’s Guide, but I am pretty sure that a program had to voluntarily give up the CPU if you wanted any form of multi-tasking.

The alternative is called “preemptive multitasking” where the hardware provides a mechanism that can call a controller function to switch tasks. The task running on the CPU is paused, the state is saved, and the controller function decides what to do next.

Continue reading

ACPI root pointer from UEFI System Table.

As I found out after I posted my lat entry , the correct way to find the Root pointer for the ACPI tables is to get it from the EFI System table. Where does that get set? Here’s the general flow: again, we start at init/main.c. start_kernel.   However, the call is not in the ACPI code, but rather in setup_arch. The call chain goes

start-Kernel->setup_arch->efi_init->efi_get_fdt_params and that seems to pull it our of initial_boot_params. I can’t quite see where that is initialized. Yet. From context it looks like it is constructed out of the kernel command line parameters. Still learning….