u-boot.git/arch/x86/lib, branch v2016.07

x86: acpi: Fix madt lapic generation

2016-06-12T04:19:35Z

An accumulated length was incorrectly added to current each pass through the loop. On system with more than 2 cores this caused a corrupt MADT to be generated. Signed-off-by: George McCollister Reviewed-by: Simon Glass Reviewed-by: Bin Meng

x86: Switch to use SMBIOS Kconfig options when writing SMBIOS tables

2016-05-23T07:27:42Z

Make use of the newly added Kconfig options of board manufacturer and product name to write SMBIOS tables. Signed-off-by: Bin Meng Reviewed-by: Simon Glass

x86: acpi: Remove header length check when writing tables

2016-05-23T07:18:00Z

Before moving 'current' pointer during ACPI table writing, we always check the table length to see if it is larger than the table header. Since our purpose is to generate valid tables, the check logic is always true, which can be avoided. Signed-off-by: Bin Meng Reviewed-by: Simon Glass

x86: acpi: Remove the unnecessary checksum calculation of DSDT

2016-05-23T07:18:00Z

The generated AmlCode[] from IASL already has the calculated DSDT table checksum in place. No need for us to calculate it again. Signed-off-by: Bin Meng Reviewed-by: Simon Glass

x86: acpi: Switch to ACPI mode by ourselves instead of requested by OSPM

2016-05-23T07:18:00Z

Per ACPI spec, during ACPI OS initialization, OSPM can determine that the ACPI hardware registers are owned by SMI (by way of the SCI_EN bit in the PM1_CNT register), in which case the ACPI OS issues the ACPI_ENABLE command to the SMI_CMD port. The SCI_EN bit effectively tracks the ownership of the ACPI hardware registers. However since U-Boot does not support SMI, we report all 3 fields in FADT (SMI_CMD, ACPI_ENABLE, ACPI_DISABLE) as zero, by following the spec who says: these fields are reserved and must be zero on system that does not support System Management mode. U-Boot seems to behave in a correct way that the ACPI spec allows, at least Linux does not complain, but apparently Windows does not think so. During Windows bring up debugging, it is observed that even these 3 fields are zero, Windows are still trying to issue SMI with hardcoded SMI port address and commands, and expecting SCI_EN to be changed by the firmware. Eventually Windows gives us a BSOD (Blue Screen of Death) saying ACPI_BIOS_ERROR and refuses to start. To fix this, turn on the SCI_EN bit by ourselves. With this patch, now U-Boot can install and boot Windows 8.1/10 successfully with the help of SeaBIOS using legacy interface (non-UEFI mode). Signed-off-by: Bin Meng Reviewed-by: Simon Glass

x86: Use high_table_malloc() for tables passing to SeaBIOS

2016-05-23T07:18:00Z

Now that we already reserved high memory for configuration tables, call high_table_malloc() to allocate tables from the region. Signed-off-by: Bin Meng Reviewed-by: Simon Glass

x86: Prepare configuration tables in dedicated high memory region

2016-05-23T07:18:00Z

Currently when CONFIG_SEABIOS is on, U-Boot allocates configuration tables via normal malloc(). To simplify, use a dedicated memory region which is reserved on the stack before relocation for this purpose. Add functions for reserve and malloc. Signed-off-by: Bin Meng Reviewed-by: Simon Glass

x86: Compile coreboot_table.c only for SeaBIOS

2016-05-23T07:18:00Z

coreboot_table.c only needs to be built when SeaBIOS is used. Signed-off-by: Bin Meng Reviewed-by: Simon Glass

x86: Fix up PIRQ routing table checksum earlier

2016-05-23T07:18:00Z

PIRQ routing table checksum is fixed up in copy_pirq_routing_table(), which is fine if we only write the configuration table once. But with the SeaBIOS case, when we write the table for the second time, the checksum will be fixed up to zero per the checksum algorithm, which is caused by the checksum field not being zero before fix up, since the checksum has already been calculated in the first run. To fix this, move the checksum fixup to create_pirq_routing_table(), so that copy_pirq_routing_table() only does what its function name suggests: copy the table to somewhere else. Signed-off-by: Bin Meng Reviewed-by: Simon Glass

x86: Call board_final_cleanup() in last_stage_init()

2016-05-23T07:18:00Z

At present board_final_cleanup() is called before booting a Linux kernel. This actually needs to be done before booting anything, like SeaBIOS, VxWorks or Windows. Move the call to last_stage_init() instead. Signed-off-by: Bin Meng Reviewed-by: Simon Glass