The Qemu implementation uses a Flattened Device Tree (FTD) to manage the virtual implementation of the physical devices in a machine. I need to create a FTD entry for the MCTP-PCC implementation I am writing in Qemu. Since this is new to me, and I am working (as I most often do) via Ttrial and error, I want to see the FTD entry after I write it. Here is how I am dumping it.
Continue readingWhen developing Linux Kernel code, I have found myself wanting to have a test fixture inside the Firmware that lets me inspect the values communicated out of and into the Linux Kernel. I am currently writing one such fixture in Qemu. And I have an interrupt that is not getting handled by the Linux Kernel, I think because it is not getting delivered.
I have found it quite valuable to run this Qemu process in the Gnu Debugger. Here is how I (with help) got to the bottom of the mystery.
Continue readingHow do you know what is inside your computer? There are a couple tools. If the hardware is on the PCI bus, from the command line you can run lspci, which will in turn enumerate the discovered devices on that bus. But what if the hardware is not on the PCI bus? And how does the Kernel discover it in the first place? For the hardware that I have to work with, the answer is that it is enumerated by the Unified Extensible Firmware Interface (UEFI) coded embedded in the device and exposed via the Advanced Configuration and Power Interface (ACPI). This world is full of four letter acronyms. Here are my notes on some of them.
Continue readingThe systems I am working with have 80 or more cores in them. I’ve recently had to investigate processes around core start up. Here are my notes.
Continue readingToday I was reminded how easy it is to get fixed in your thinking.
The short lessons learned: if the Hostname fails (due to SSL) try the IP address.
Longer story:
Continue readingMost Minecraft servers are run on x86_64 based hardware. Ampere AltraMax chips run AARCH64…which is the non-ARM specific way of saying ARM64 instruction set.
Continue readingThe sys file system is used to expose Linux constructs to user space. One place we can see ACPI based information is in /sys/firmware/acpi
Continue readingMany other modules might trigger ACPI device registration. This means the the basic ACPI subsystem has to be up and available before much of the Hardware is usable. Hence, we can see that the ACPI subsystem gets registered here. What I am not certain of is when does this code get called?
Continue readingAs 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….
It started as a request from our tech lead: please help triage these patches. So I lookedat the set of patches and started with what looked like the simplest one:
Fix topology for Core scheduling.
It *just* reorders the code to call
store_cpu_topology(cpu);
before
notify_cpu_starting() .
Yeah…there is no such thing as a simple patch. These are my notes as I study and learn ACPI. My assumptions are here for all to see, and may well prove to be wrong.
Lets dig in.
Continue reading