Hi Michael,
On Mon, 12 May 2025 at 15:59, Michael <mep.sw....@gmail.com> wrote:
>
> Hi Simon,
>
> when i execute the 'acpi' command i can see the tables.
> I've also tried to enable the CONFIG_SMP Option - without any changes.
> When using grub i can dump the tables - With u-boot i'm getting "Could not
> get acpi tables AE_NOT_FOUND" (/sys/firmware/acpi is missing)
>
> acpi list
> Name Base Size Detail
> ---- ---------------- ----- ----------------------------
> RSDP 9b693014 24 v02 ALASKA
> RSDT 9b692394 78 v01 ALASKA A M I 1072009 AMI 1000013
> XSDT 9b692728 cc v01 ALASKA A M I 1072009 AMI 1000013
> FACP 9b616000 114 v06 ALASKA A M I 1072009 AMI 10013
> DSDT 9b5d1000 44832 v02 ALASKA A M I 1072009 INTL 20160527
> FACS 9b71c000 40
> MCFG 9b61a000 3c v01 ALASKA A M I 1072009 MSFT 97
> SSDT 9b617000 20ad v02 CpuRef CpuSsdt 3000 INTL 20160527
> FIDT 9b5d0000 9c v01 ALASKA A M I 1072009 AMI 10013
> SSDT 9b5cc000 31da v02 SaSsdt SaSsdt 3000 INTL 20160527
> HPET 9b61c000 38 v01 ALASKA A M I 1072009 AMI 1000013
> SSDT 9b5ca000 147b v02 ALASKA Ther_Rvp 1000 INTL 20160527
> SSDT 9b5c6000 3240 v02 INTEL xh_cmsd4 0 INTL 20160527
> NHLT 9b5c4000 1821 v00 ALASKA A M I 1072009 AMI 1000013
> LPIT 9b61b000 94 v01 ALASKA A M I 1072009 AMI 1000013
> SSDT 9b5c0000 2720 v02 ALASKA PtidDevc 1000 INTL 20160527
> SSDT 9b5bd000 25b2 v02 ALASKA TbtTypeC 0 INTL 20160527
> DBGP 9b5bc000 34 v01 ALASKA A M I 1072009 AMI 1000013
> DBG2 9b5bb000 54 v00 ALASKA A M I 1072009 AMI 1000013
> SSDT 9b5b9000 1b67 v02 ALASKA UsbCTabl 1000 INTL 20160527
> DMAR 9b5b8000 c8 v01 INTEL EDK2 2 1000013
> BGRT 9b5b7000 38 v01 ALASKA A M I 1072009 AMI 10013
> ASF! 9b5b6000 74 v32 ALASKA A M I 1072009 AMI 1000013
> WSMT 9b5c3000 28 v01 ALASKA A M I 1072009 AMI 10013
> APIC 9b5b5000 12c v04 ALASKA A M I 1072009 AMI 10013
> FPDT 9b5b4000 44 v01 ALASKA CML 1072009 AMI 1000013
(please try to avoid top-posting on the mailing list as it gets
confusing when there are replies)
I suspect you are not getting the ACPI tables at all in this case,
since there is no 'pointer' at f0000 and x86 expects that when using
zboot. We need the code at the bottom of write_tables() to be invoked
somehow:
if (IS_ENABLED(CONFIG_BLOBLIST_TABLES)) {
void *ptr = (void *)CONFIG_ROM_TABLE_ADDR;
/* Write an RSDP pointing to the tables */
if (IS_ENABLED(CONFIG_GENERATE_ACPI_TABLE)) {
struct acpi_ctx *ctx = gd_acpi_ctx();
acpi_write_rsdp(ptr, ctx->rsdt, ctx->xsdt);
ptr += ALIGN(sizeof(struct acpi_rsdp), 16);
}
if (IS_ENABLED(CONFIG_GENERATE_SMBIOS_TABLE)) {
void *smbios;
smbios = bloblist_find(BLOBLISTT_SMBIOS_TABLES, 0);
if (!smbios)
return log_msg_ret("smbios", -ENOENT);
memcpy(ptr, smbios, sizeof(struct smbios_entry));
}
}
Regards,
Simon
>
>
> Regards,
> Michael
>
>
> Am Mo., 12. Mai 2025 um 15:08 Uhr schrieb Simon Glass <s...@chromium.org>:
>>
>> Hi Michael,
>>
>> On Thu, 8 May 2025 at 14:51, Michael <mep.sw....@gmail.com> wrote:
>> >
>> > Hello!,
>> >
>> > i'm currently working on a project that could use several architectures
>> > (arm / x86).
>> > To have a common base for all systems, i want to use u-boot as unified
>> > bootloader for both platforms.
>> > At the moment i try to get u-boot working on x86. These systems are more
>> > general pcs than classic embedded systems and can have intel atom / i3...
>> > etc. processors (for example advantech mio series) - All of them have a
>> > uefi bios.
>> > To build the whole system i am using yocto. I have made some minor changes
>> > to u-boot (v2025.01 / build as efi app / binary) to fit my use case (find
>> > env partition via gpt part uuid / A/B update mechanism etc.)
>> > The kernel and initramfs are packed as fit image (
>> > https://docs.u-boot.org/en/latest/usage/fit/x86-fit-boot.html). I can boot
>> > the system and the a/b update mechanism is also working.
>> >
>> > The fit image contains kernel / setup / initramfs - (
>> > https://docs.u-boot.org/en/latest/usage/fit/kernel.html)
>> > The current boot procedure is: "boot uboot.efi" → "load fit image over the
>> > efi interface" → "bootm"
>> >
>> > My current problem is, that i can only use one cpu core. I think there is a
>> > problem with the acpi tables ("smpboot: Boot CPU (id 0) not listed by BIOS"
>> > / "smpboot: Allowing 1 CPUs, 0 hotplug CPUs" / "smpboot: SMP disabled")
>> > I already got some hints on the irc chat (thanks for that!), but i could
>> > not fix the issue yet. I also tried an "EFI handover" patch for uboot, but
>> > with this, i cannot boot the kernel anymore (exception).
>>
>> Can you use the 'acpi' command to examine the tables and see what is
>> there? These tables are not created by U-Boot in this case. Also, I'm
>> assuming that U-Boot does not have CONFIG_SMP set, so it should be
>> ignoring the other CPUs.
>>
>> I did think of one issue, though. The ACPI tables are expected to be
>> at f0000, but when booting as an EFI app, that is not the case. There
>> is code at the bottom of write_tables() to add a pointer from f0000 to
>> where the tables actually are. So you may need to put that code
>> somewhere so it is done in the zboot case.
>>
>> You could also try dumping the ACPI tables within Linux for the two
>> different scenarios (booting via U-Boot and not). That might provide a
>> clue as to the difference.
>>
>> >
>> > At a later point i want to lock down the device with enabling the "secure
>> > boot" bios function. I have not worked with secure boot yet. I think i can
>> > only get it working with the fit images (fit signature verification)?
>>
>> Yes you can use FIT, which is good if you are trying to be like ARM.
>> You may have seen this talk[1]
>>
>> >
>> > Is this thre right implementation approch?
>> > I am grateful for any advice!
>>
>> Yes it seems right to me. I'm hoping to get this into CI early next
>> month so it is properly tested.
>>
>> Regards,
>> SImon
>>
>> [1] https://www.youtube.com/watch?v=hte60f7I9j4
