summaryrefslogtreecommitdiff
path: root/arch/x86
AgeCommit message (Collapse)Author
2019-01-26linker: Modify linker scripts to be more genericTom Rini
Make use of "IMAGE_MAX_SIZE" and "IMAGE_TEXT_BASE" rather than CONFIG_SPL_MAX_SIZE and CONFIG_SPL_TEXT_BASE. This lets us re-use the same script for both SPL and TPL. Add logic to scripts/Makefile.spl to pass in the right value when preprocessing the script. Cc: Stefano Babic <sbabic@denx.de> Cc: Fabio Estevam <fabio.estevam@nxp.com> Cc: Jagan Teki <jagan@openedev.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Andreas Bießmann <andreas@biessmann.org> Cc: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Cc: Michal Simek <monstr@monstr.eu> Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com> Cc: York Sun <york.sun@nxp.com> Cc: Bin Meng <bmeng.cn@gmail.com> Cc: Heiko Schocher <hs@denx.de> Cc: Adam Ford <aford173@gmail.com> Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com> Tested-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com> Tested-by: Adam Ford <aford173@gmail.com> #da850evm & omap3_logic_somlv Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
2019-01-18x86: Kconfig: spelling fixesChris Packham
Signed-off-by: Chris Packham <judge.packham@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2019-01-14dm: serial: Adjust serial_getinfo() to use proper APISimon Glass
All driver-model functions should have a device as the first parameter. Update this function accordingly. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
2019-01-14dm: serial: Adjust serial_getconfig() to use proper APISimon Glass
All driver-model functions should have a device as the first parameter. Update this function accordingly. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
2018-12-10efi: payload: only init usb if necessaryBin Meng
Up until now the call to initialize the USB subsystem was hardcoded for U-Boot running as an EFI payload. This was used to enable the use of a USB keyboard in the U-Boot shell. However not all boards might need this functionality. As initializing the USB subsystem can take a considerable amount of time (several seconds on some boards), we now initialize the USB subsystem only if U-Boot is configured to use USB keyboards. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
2018-12-10coreboot: only init usb if necessaryThomas RIENOESSL
Up until now the call to initialize the USB subsystem was hardcoded for U-Boot running as a coreboot payload. This was used to enable the use of a USB keyboard in the U-Boot shell. However not all boards might need this functionality. As initializing the USB subsystem can take a considerable amount of time (several seconds on some boards), we now initialize the USB subsystem only if U-Boot is configured to use USB keyboards. Signed-off-by: Thomas RIENOESSL <thomas.rienoessl@bachmann.info> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
2018-12-10x86: kconfig: Allow board defconfig file to disable 8259 and APICBin Meng
At present the Kconfig options (CONFIG_I8259_PIC and CONFIG_APIC) do not include a prompt message, which makes it impossible to be disabled from a board defconfig file. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-12-10x86: Wrap calls to 8259 with CONFIG_I8259_PICBin Meng
mask_irq(), unmask_irq() and specific_eoi() are provided by the i8259 PIC driver and should be wrapped with CONFIG_I8259_PIC. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Hannes Schmelzer <oe5hpm@oevsv.at>
2018-12-10x86: make the LAPIC / IOAPIC construct switchable with KconfigHannes Schmelzer
There are still systems running which do not have any LAPIC or even IOAPIC. Responsible MSRs for those do not exist and the systems are crashing on trying to setup LAPIC. This commit makes the APIC stuff able to switch off for those boards which dont' have an LAPIC / IOAPIC. Signed-off-by: Hannes Schmelzer <oe5hpm@oevsv.at> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2018-12-10x86: acpi: Fix indentation in Intel Tangier ASL codeAndy Shevchenko
Make the indentation aligned with what used elsewhere in U-Boot. No functional change intended. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2018-12-10x86: acpi: Enable RTC for Intel TangierAndy Shevchenko
Intel Tangier SoC has RTC inside. So, enable it in ACPI. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2018-12-05x86: acpi: Generate SPCR tableAndy Shevchenko
Microsoft specifies a SPCR (Serial Port Console Redirection Table) [1]. Let's provide it in U-Boot. [1]: https://docs.microsoft.com/en-us/windows-hardware/drivers/serports/serial-port-console-redirection-table Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-12-05x86: acpi: Add SPCR table descriptionAndy Shevchenko
Add SPCR table description as it provided in Linux kernel. Port subtype for ACPI_DBG2_SERIAL_PORT is used as an interface type in SPCR. Thus, provide a set of definitions to be utilized later. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2018-12-02x86: efi: app: Generate Microsoft PE format compliant imageBin Meng
Per Microsoft PE Format documentation [1], PointerToSymbolTable and NumberOfSymbols should be zero for an image in the COFF file header. Currently U-Boot is generating u-boot-app.efi in which these two members are not zero. This updates the build rules to tell linker to remove the symbol table completely so that we can generate compliant *.efi images. [1] https://docs.microsoft.com/zh-cn/windows/desktop/Debug/pe-format Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
2018-12-02x86: efi: payload: Generate Microsoft PE format compliant imageBin Meng
Per Microsoft PE Format documentation [1], PointerToSymbolTable and NumberOfSymbols should be zero for an image in the COFF file header. Currently U-Boot is generating u-boot-payload.efi image in which these two members are not zero. This updates the build rules to tell linker to remove the symbol table completely so that we can generate compliant *.efi images. [1] https://docs.microsoft.com/zh-cn/windows/desktop/Debug/pe-format Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
2018-11-14cpu: Add DM_FLAG_PRE_RELOC flag to various cpu driversBin Meng
It turns out commit c0434407b595 broke some boards which have DM CPU driver with CONFIG_DISPLAY_CPUINFO option on. These boards just fail to boot when print_cpuinfo() is called during boot. Fixes: c0434407b595 ("board_f: Use static print_cpuinfo if CONFIG_CPU is active") Reported-by: Stefan Roese <sr@denx.de> Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de> Tested-by: Stefan Roese <sr@denx.de>
2018-11-14sysreset: Remove DM_FLAG_PRE_RELOC flag in various driversBin Meng
When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be bound before relocation. However due to a bug in the DM core, the flag only takes effect when devices are statically declared via U_BOOT_DEVICE(). This bug has been fixed recently by commit "dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in lists_bind_fdt()", but with the fix, it has a side effect that all existing drivers that declared DM_FLAG_PRE_RELOC flag will be bound before relocation now. This may expose potential boot failure on some boards due to insufficient memory during the pre-relocation stage. To mitigate this potential impact, the following changes are implemented: - Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver only supports configuration from device tree (OF_CONTROL) - Keep DM_FLAG_PRE_RELOC flag in the driver only if the device is statically declared via U_BOOT_DEVICE() - Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for drivers that support both statically declared devices and configuration from device tree Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-11-14x86: Implement arch-specific io accessor routinesBin Meng
At present the generic io{read,write}{8,16,32} routines only support MMIO access. With architecture like x86 that has a separate IO space, these routines cannot be used to access I/O ports. Implement x86-specific version to support both PIO and MMIO access, so that drivers for multiple architectures can use these accessors without the need to know whether it's MMIO or PIO. These are ported from Linux kernel lib/iomap.c, with slight changes. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-11-06x86: acpi: Remove redundant Offset (0x00)Andy Shevchenko
New ACPI assembler issues a warning: board/intel/edison/dsdt.asl.tmp 13: Offset (0x00), Remark 2158 - ^ Unnecessary/redundant use of Offset operator Indeed, in the OperationRegion the offset is 0x00 by default. Thus, drop unneeded Offset() use as suggested by ACPI assembler. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2018-10-28x86: Fix car_uninit weak symbol definitionBin Meng
Since commit 80df194f0165 ("x86: detect unsupported relocation types"), an error message is seen on QEMU x86 target during boot: do_elf_reloc_fixups32: unsupported relocation type 0x1 at fff841f0, offset = 0xfff00087 do_elf_reloc_fixups32: unsupported relocation type 0x2 at fff841f8, offset = 0xfff00091 Check offset 0xfff00087 and 0xfff00091 in the u-boot ELF image, fff00087 000df401 R_386_32 00000000 car_uninit fff00091 000df402 R_386_PC32 00000000 car_uninit we see R_386_32 and R_386_PC32 relocation type is generated for symbol car_uninit, which is declared as a weak symbol in start.S. However the actual weak symbol implementation ends up nowhere. As we can see below, it's *UND*. $ objdump -t u-boot | grep car_uninit 00000000 w *UND* 00000000 car_uninit With this fix, it is normal now. $ objdump -t u-boot | grep car_uninit fff00094 w F .text.start 00000001 car_uninit Reported-by: Hannes Schmelzer <hannes@schmelzer.or.at> Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Hannes Schmelzer <oe5hpm@oevsv.at>
2018-10-28x86: BayTrail: southcluster.asl: Change PCI 64 bit address range / regionStefan Roese
To allow bigger 64 bit prefetchable PCI regions in Linux, this patch changes the base address and range of the ACPI area passed to Linux. BayTrail can only physically access 36 bit of PCI address space. So just chaning the range without changing the base address won't work here, as 0xf.ffff.ffff is already the maximum address. With this patch, a maximum of 16 GiB of local DDR is supported. This should be enough for all BayTrail boards though. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Bin Meng <bmeng.cn@gmail.com> Cc: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2018-10-22x86: quark: Specify X86_TSC_TIMER_EARLY_FREQBin Meng
Specify X86_TSC_TIMER_EARLY_FREQ for Quark SoC so that TSC as the early timer can be supported. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-10-22x86: Fix the mystery of printch() during 64-bit bootBin Meng
At present in arch_setup_gd() it calls printch(' ') at the end which has been a mystery for a long time as without such call the 64-bit U-Boot just does not boot at all. In fact this is due to the bug that board_init_f() was called with boot_flags not being set. Hence whatever value being there in the rdi register becomes the boot_flags if without such magic call. With a printch(' ') call the rdi register is initialized as 0x20 and this value seems to be sane enough for the whole boot process. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2018-10-22x86: put global data pointer into the .data sectionHeinrich Schuchardt
On x86_64 the field global_data_ptr is assigned before relocation. As sections for uninitialized global data (.bss) overlap with the relocation sections (.rela) this destroys the relocation table and leads to spurious errors. Initialization forces the global_data_ptr into a section for initialized global data (.data) which cannot overlap any .rela section. Fixes: a160092a610f ("x86: Support global_data on x86_64") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
2018-10-22x86: detect unsupported relocation typesHeinrich Schuchardt
Currently we support only relocations of type ELF64_R_TYPE or ELF32_R_TYPE. We should be warned if other relocation types appear in the relocation sections. This type of message has helped to identify code overwriting a relocation section before relocation and incorrect parsing of relocation tables. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
2018-10-22x86: Ensure no instruction sets of MMX/SSE are generated in 64-bit buildBin Meng
With the '-march=core2' fix, it seems that we have some luck that the 64-bit U-Boot boots again. However if we examine the disassembly codes there are still SSE instructions elsewhere which means passing cpu type to GCC is not enough to prevent it from generating these instructions. A simple test case is doing a 'bootefi selftest' from the U-Boot shell and it leads to a reset too. The 'bootefi selftest' reset is even seen with the image created by the relative older GCC 5.4.0, the one shipped by Ubuntu 16.04. The reset actually originates from undefined instruction exception caused by these SSE instructions. To keep U-Boot as a bootloader as simple as possible, we don't want to handle such advanced SIMD stuff. To make sure no MMX/SSE instruction sets are generated, tell GCC not to do this. Note AVX is out of the question as CORE2 is old enough to support AVX yet. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-10-22x86: Specify -march=core2 to build 64-bit U-Boot properBin Meng
With newer kernel.org GCC (7.3.0 or 8.1.0), the u-boot.rom image built for qemu-x86_64 target does not boot. It keeps resetting soon after the 32-bit SPL jumps to 64-bit proper. Debugging shows that the reset happens inside env_callback_init(). 000000000113dd85 <env_callback_init>: 113dd85: 41 54 push %r12 113dd87: 55 push %rbp 113dd88: 31 c0 xor %eax,%eax 113dd8a: 53 push %rbx 113dd8b: 0f 57 c0 xorps %xmm0,%xmm0 Executing "xorps %xmm0,%xmm0" causes CPU to immediately reset. However older GCC like 5.4.0 (the one shipped by Ubuntu 16.04) does not generate such instructions that utilizes SSE for this function - env_callback_init() and U-Boot boots without any issue. Explicitly specifying -march=core2 for newer GCC allows U-Boot proper to boot again. Examine assembly codes of env_callback_init and there is no SSE instruction in that function hence U-Boot continues to boot. core2 seems to be the oldest arch in GCC that supports 64-bit. Like 32-bit U-Boot build we use -march=i386 which is the most conservative cpu type so that the image can run on any x86 processor, let's do the same for the 64-bit U-Boot build. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-10-22x86/bootm: fix error handling in boot_prep_linux(...)Hannes Schmelzer
Once we get a zero pointer from load_zimage(...) we must bunch out instead of continue boot. Signed-off-by: Hannes Schmelzer <hannes.schmelzer@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2018-10-09x86: Update mtrr functions to allow leaving cache aloneSimon Glass
At present the mtrr functions disable the cache before making changes and enable it again afterwards. This is fine in U-Boot, but does not work if running in CAR (such as we are in SPL). Update the functions so that the caller can request that caches be left alone. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2018-09-26Merge tag 'signed-efi-next' of git://github.com/agraf/u-bootTom Rini
Patch queue for efi - 2018-09-26 A lot of goodness in this release. We're *very* close to running the UEFI Shell and SCT natively. The only missing piece are HII protocols. - FAT write support (needed for SCT) - improved FAT directory support (needed for SCT) - RTC support with QEMU -M virt - Sandbox support (run UEFI binaries in Linux - yay) - Proper UTF-16 support - EFI_UNICODE_COLLATION_PROTOCOL support (for UEFI Shell) - EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL support (for UEFI Shell) - Fix window size determination - Fix Tegra by explicitly unmapping RAM - Clean up handle entanglement - Lots of generic code cleanup [trini: Fixup merge conflict in include/configs/qemu-arm.h] Signed-off-by: Tom Rini <trini@konsulko.com>
2018-09-25config.mk: Remove duplicated -fno-strict-aliasingBin Meng
Now that we already disable the "strict-aliasing" globally, remove the duplicates in the nds32/riscv/x86 arch-specific Makefiles. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Rick Chen <rick@andestech.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-09-23efi_loader: simplify ifdefsStephen Warren
Use CONFIG_IS_ENABLED(EFI_LOADER) to avoid explicitly checking CONFIG_SPL too. This simplifies the conditional. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Alexander Graf <agraf@suse.de>
2018-09-17x86: cpu: add docstring to scu_ipc_command()Georgii Staroselskii
These comments were copied from the Linux kernel driver in drivers/platform/x86/intel_scu_ipc.c Signed-off-by: Georgii Staroselskii <georgii.staroselskii@emlid.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2018-09-17x86: tangier: acpi: add I2C6 nodeGeorgii Staroselskii
Now that we have I2C#6 working, it's time to add a corresponsing ACPI binding. Signed-off-by: Georgii Staroselskii <georgii.staroselskii@emlid.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2018-09-17x86: dts: edison: configure I2C#6 pinsGeorgii Staroselskii
Now that we have the pinctrl driver for Merrifield in place we can make use of it and set I2C#6 pins appropriately. Initial configuration came from the firmware. Which quite likely has been used in the phones, where that is not part of Atom peripheral, is in use. Thus we need to override the leftover. Signed-off-by: Georgii Staroselskii <georgii.staroselskii@emlid.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2018-09-17x86: tangier: pinmux: add API to configure protected pinsGeorgii Staroselskii
This API is going to be used to configure some pins that are protected for simple modification. It's not a comprehensive pinctrl driver but can be turned into one when we need this in the future. Now it is planned to be used only in one place. So that's why I decided not to pollute the codebase with a full-blown pinctrl-merrifield nobody will use. This driver reads corresponding fields in DT and configures pins accordingly. The "protected" flag is used to distinguish configuration of SCU-owned pins from the ordinary ones. The code has been adapted from Linux work done by Andy Shevchenko in pinctrl-merrfifield.c Signed-off-by: Georgii Staroselskii <georgii.staroselskii@emlid.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> [bmeng: fix build warning] Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
2018-09-17x86: cpu: introduce scu_ipc_raw_command()Georgii Staroselskii
This interface will be used to configure properly some pins on Merrifield that are shared with SCU. scu_ipc_raw_command() writes SPTR and DPTR registers before sending a command to SCU. This code has been ported from Linux work done by Andy Shevchenko. Signed-off-by: Georgii Staroselskii <georgii.staroselskii@emlid.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2018-09-10Remove <inttypes.h> includes and PRI* usages in printf() entirelyMasahiro Yamada
In int-ll64.h, we always use the following typedefs: typedef unsigned int u32; typedef unsigned long uintptr_t; typedef unsigned long long u64; This does not need to match to the compiler's <inttypes.h>. Do not include it. The use of PRI* makes the code super-ugly. You can simply use "l" for printing uintptr_t, "ll" for u64, and no modifier for u32. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-09-10arch: types.h: factor out fixed width typedefs to int-ll64.hMasahiro Yamada
All architectures have the same definition for s8/16/32/64 and u8/16/32/64. Factor out the duplicated code into <asm-generic/int-ll64.h>. BTW, Linux unified the kernel space definition into int-ll64.h a few years ago as you see in Linux commit 0c79a8e29b5f ("asm/types.h: Remove include/asm-generic/int-l64.h"). Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-09-10Remove CONFIG_USE_STDINTMasahiro Yamada
You do not need to use the typedefs provided by compiler. Our compilers are either IPL32 or LP64. Hence, U-Boot can/should always use int-ll64.h typedefs like Linux kernel, whatever the typedefs the compiler internally uses. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-08-30x86: zimage: Remove acpi_rsdp_addr propagation to kernel boot parametersBin Meng
As of today, the proposal of adding "acpi_rsdp_addr" to the kernel boot protocol does not make its way to the kernel mainline. This creates some confusion if we leave it in the U-Boot code base. Remove it for now until we have a clear picture with kernel upstream. Note this eventually does a partial revert to commit 3469bf427454 ("x86: zImage: Propagate acpi_rsdp_addr to kernel via boot parameters") Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-08-30x86: zimage: Support booting Linux kernel from an EFI payloadBin Meng
At present Linux kernel loaded from U-Boot as an EFI payload does not boot. This fills in kernel's boot params structure with the required critical EFI information like system table address and memory map stuff so that kernel can obtain essential data like runtime services and ACPI table to boot. With this patch, now U-Boot as an EFI payload becomes much more practical: it is another option of kernel bootloader, ie, can be a replacement for grub. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-08-30x86: efi: payload: Install E820 map from EFI memory mapBin Meng
This implements payload-specific install_e820_map() to get E820 map from the EFI memory map descriptors. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-08-21Merge tag 'signed-efi-2018.09' of git://github.com/agraf/u-bootTom Rini
Patch queue for efi - 2018-08-21 A few fixes for 2018.09. Most noticable are: - unbreak x86 target (-fdata-section fallout) - fix undefined behavior in a few corner cases - make Jetson TX1 boot again - RTS fixes - implement reset for simple output
2018-08-20x86: Enable -fdata-sections alwaysAlexander Graf
We left -fdata-sections disabled for x86_64 before because we encountered random bugs that were at that time inexplicable. Turns out this really was just side effects of missing .bss* statements in the linker scripts. With those fixed, we can enable data sections for all targets. Signed-off-by: Alexander Graf <agraf@suse.de>
2018-08-20x86: Include bss subsections in linker scriptAlexander Graf
When we build with -fdata-sections we may end up with bss subsections. Our linker script explicitly lists only a single consecutive bss section though. Adapt the statement to also include subsections. This fixes booting efi-x86_app_defconfig. Signed-off-by: Alexander Graf <agraf@suse.de>
2018-08-20x86: efi: payload: Add default TSC frequency in the device treeBin Meng
It was observed sometimes U-Boot as the EFI payload fails to boot on QEMU. This is because TSC calibration fails with no valid frequency. This adds default TSC frequency in the device tree. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-08-20x86: coreboot: Add default TSC frequency in the device treeBin Meng
It was observed sometimes U-Boot as the coreboot payload fails to boot on QEMU. This is because TSC calibration fails with no valid frequency. This adds default TSC frequency in the device tree. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
2018-08-20x86: dts: Remove coreboot_fb.dtsiBin Meng
There is no need to keep a separate coreboot_fb.dtsi since now we have a generic coreboot payload dts. While we are here, this also remove the out-of-date description in the documentation regarding to coreboot framebuffer driver with U-Boot loaded as a payload from coreboot. As the testing result with QEMU 2.5.0 shows, the driver just works like a charm. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-08-20x86: Remove support for Advantech SOM-6896Bin Meng
Now that we have generic coreboot payload support, remove the dedicated support for Advantech SOM-6896. Signed-off-by: Bin Meng <bmeng.cn@gmail.com>