Closed davidhuwyler closed 1 year ago
But your tables are generated? In my case the tables are generated and packaged. Then I install the package into the initrd image. And then the initrd gets loaded at boot, but that is the responsibility of the boot loader. In my case U-Boot. And the U-Boot recipe is adapted to load kernel and initrd.
In other cases the initrd might get built-in to the kernel (if it fits). Or the acpi-tables cpio concatenated to the kernel.
I never tried with efi. But it's gotta be similar.
There are two ways to get SSDT loaded at boot: via initramfs and via EFI variable. The type of the bootloader can be anything.
But your tables are generated? In my case the tables are generated and packaged. Then I install the package into the initrd image. And then the initrd gets loaded at boot, but that is the responsibility of the boot loader. In my case U-Boot. And the U-Boot recipe is adapted to load kernel and initrd.
In other cases the initrd might get built-in to the kernel (if it fits). Or the acpi-tables cpio concatenated to the kernel.
I never tried with efi. But it's gotta be similar.
Yes the tables are generated and the acpi-tables are generated. And the acpi-tables.cpio is generated (is this the initrd?) But the initrd is not loaded at boot. Any ideas what im missing? Some kerner command line param?
I use meta-intel which uses a initrd for the microcode. This initrd seems to be loaded fine.
Both .cpio images are added to the INITRD_LIVE yocto variable...
I don't know what Yocto is (okay, I know, but i have zero experience with it), what you need is to be sure that first archive in the initramfs is ACPI tables and it's not compressed. How to achieve this in the usual command line is written in the kernel documentation. I dunno how it should be done in Yocto.
You might want to consider to create an initramfs and stuff everything in there, microcode, acpi tables, modules needed to boot, maybe some disk repair tools and such.
TLDR;
Actually the acpi-tables.bb recipe in this layer (meta-acpi) does exactly as the kernel docs say to build the acpi-tables cpio.
Now, in Intel Edison case we use another recipe to generate an initramfs. The initramfs is put into a file (of type compressed cpio) that is called initrd. I think the file is called initrd because of historical reasons. Nevertheless, it contains a root file system that linux can boot. It has just the necessary stuff (modules, udev, some init script) to be able to mount the real file system. In case of Intel Edison the acpi tables are also there and loaded by the init script (though the configfs mechanism).
As @andy-shev says, the uncompressed acpi-tables.cpio can be concatenated to the (compressed) initrd (when you don't want to use the configfs) to form single file. The advantage would be that this way the tables are loaded earlier.
Again in case of Intel Edison, both kernel and initrd are loaded into RAM by U-Boot. Then U-Boot calls the kernel while passing the address of the initrd for the kernel to find. If initrd contains a concatenated acpi-tables.cpio and initramfs the kernel would find the acpi-tables first. Personally, I didn't get this to work (after manually concatenating the 2 cpio's).
The initrd can also be built-in into the kernel. Then U-Boot only needs to load a single file (the kernel). Yocto can build the initrd into the kernel automatically, but AFAIK it doesn't automatically concatenate the 2 cpio's. Moreover, U-Boot seemed to be limited to loading a 15MB kernel, so once there was substantial modules inside the initrd the size was too large. Loading initramfs this way worked, but we moved away from it.
Ok thanks for your inputs. It seems there are multiple ways to do this. I got it now working with grub & yocto: I load 2 uncompressed cpio files (microcode+tables). I adjusted the kernel command line (initrd=microcode.cpio acpi-tables.cpio). Now both are loaded.
And the initrd variable is processed by grub?
No grub just calls the kernel with the initrd variable in the kernel command line
Are you sure? I'm trying to wrap my head around this.
The kernel doesn't have a file system until after boot.
With U-Boot, U-Boot itself has a file system, a finds kernel and initrd on the file system, loads kernel and initrd into memory and executes kernel while pointing to location of initrd in memory.
I thought with grub, it passes the file locations to some reserved place first during update-grub. Then find these location during boot and loads the files into memory. This way, they don't need to build fs support into grub.
Hi
We tried to use meta-acpi for our custom x86 board. I cannot make it work: my custom tables are not loaded at boot...
But I use EFI_PROVIDER = "grub-efi". Does this only work with EDK2?
Regards Dave