u-boot.git/arch/x86/lib, branch v2017.09

x86: fsp: Configure SPI opcode registers before SPI is locked down

2017-08-24T03:00:47Z

Some Intel FSP (like Braswell) does SPI lock-down during the call to fsp_notify(INIT_PHASE_BOOT). But before SPI lock-down is done, it's bootloader's responsibility to configure the SPI controller's opcode registers properly otherwise SPI controller driver doesn't know how to communicate with the SPI flash device. This introduces a Kconfig option CONFIG_FSP_LOCKDOWN_SPI for such FSPs. When it is on, U-Boot will configure the SPI opcode registers before the lock-down. Signed-off-by: Bin Meng Reviewed-by: Stefan Roese

env: Rename getenv/_f() to env_get()

2017-08-16T12:30:24Z

We are now using an env_ prefix for environment functions. Rename these two functions for consistency. Also add function comments in common.h. Quite a few places use getenv() in a condition context, provoking a warning from checkpatch. These are fixed up in this patch also. Suggested-by: Wolfgang Denk Signed-off-by: Simon Glass

x86: acpi: Fix build error with certain configuration

2017-08-08T13:13:05Z

When CONFIG_EFI_PARTITION is not set, the following build error is seen in arch/x86/lib/acpi_s3.c: error: expected declaration specifiers or '...' before '*' token static void asmlinkage (*acpi_do_wakeup)(void *vector) = (void*)WAKEUP_BASE; This is actually caused by missing asmlinkage declaration, but with CONFIG_EFI_PARTITION on, the declaration comes from part.h which is included from common.h. Signed-off-by: Bin Meng Reviewed-by: Stefan Roese

x86: acpi: Don't touch hardware on HW reduced platforms

2017-07-30T02:30:25Z

If ACPI HW reduced bit in FADT is set we should ignore any ACPI hardware communications. Signed-off-by: Andy Shevchenko Reviewed-by: Bin Meng

x86: acpi: Export acpi_fill_mcfg() with __weak attribute

2017-07-30T02:30:25Z

Some platforms might require different approach when filling memory mappings configuration table. Allow them to override the common method. At the same time export acpi_create_mcfg_mmconfig(). Signed-off-by: Andy Shevchenko Reviewed-by: Bin Meng

x86: acpi: Deduplicate acpi_fill_madt() implementation

2017-07-30T02:30:25Z

In Baytrail and Quark support code acpi_fill_madt() is identical. Deduplicate its implementation by moving to lib/acpi_tables.c. At the same time mark acpi_fill_madt() with __weak attribute to keep a possibility to override it in platform code Signed-off-by: Andy Shevchenko Reviewed-by: Bin Meng

x86: acpi: Fill OEM revision

2017-07-30T02:30:25Z

Fill OEM revision field in the tables by U-Boot build date. Signed-off-by: Andy Shevchenko Reviewed-by: Bin Meng

x86: fsp: Remove the call to set up internal uart in fsp_init()

2017-06-05T00:55:22Z

First of all, it's inappropriate to call setup_internal_uart() in a generic API fsp_init(), as CONFIG_INTERNAL_UART is an option that is only available on BayTrail platform. Secondly even for BayTrail, there is no need to call setup_internal_uart() at all, as Intel FSP will do this for us. Signed-off-by: Bin Meng Reviewed-by: Stefan Roese Reviewed-by: Simon Glass

x86: bootm: Add dm_remove_devices_flags() call to bootm_announce_and_cleanup()

2017-05-17T09:13:06Z

This patch adds a call to dm_remove_devices_flags() to bootm_announce_and_cleanup() so that drivers that have one of the removal flags set (e.g. DM_FLAG_ACTIVE_DMA_REMOVE) in their driver struct, may do some last-stage cleanup before the OS is started. Signed-off-by: Stefan Roese Cc: Bin Meng Reviewed-by: Simon Glass

x86: acpi: Fix Windows S3 resume failure

2017-05-17T09:11:46Z

U-Boot sets up the real mode interrupt handler stubs starting from address 0x1000. In most cases, the first 640K (0x00000 - 0x9ffff) system memory is reported as system RAM in E820 table to the OS. (see install_e820_map() implementation for each platform). So OS can use these memories whatever it wants. If U-Boot is in an S3 resume path, care must be taken not to corrupt these memorie otherwise OS data gets lost. Testing shows that, on Microsoft Windows 10 on Intel Baytrail its wake up vector happens to be installed at the same address 0x1000. While on Linux its wake up vector does not overlap this memory range, but after resume kernel checks low memory range per config option CONFIG_X86_RESERVE_LOW which is 64K by default to see whether a memory corruption occurs during the suspend/resume (it's harmless, but warnings are shown in the kernel dmesg logs). We cannot simply mark the these memory as reserved in E820 table because such configuration makes GRUB complain: unable to allocate real mode page. Hence we choose to back up these memories to the place where we reserved on our stack for our S3 resume work. Before jumping to OS wake up vector, we need restore the original content there. Signed-off-by: Bin Meng Reviewed-by: Simon Glass Tested-by: Stefan Roese