summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2016-10-19Merge tag 'signed-efi-next' of git://github.com/agraf/u-bootTom Rini
Patch queue for efi - 2016-10-19 Highlights this time around: - Add run time service (power control) support for PSCI (fixed in v3) - Add efi gop pointer exposure - SMBIOS support for EFI (on ARM) - efi pool memory unmap support (needed for 4.8) - initial x86 efi payload support (fixed up in v2) - various bug fixes Signed-off-by: Tom Rini <trini@konsulko.com> Conflicts: include/tables_csum.h
2016-10-19efi_loader: Revert device_handle to disk after net bootAlexander Graf
When you boot an efi payload from network, then exit that payload and load another payload from disk afterwords, the disk payload will currently see the network device as its boot path. This breaks grub2 for example which tries to find its modules based on the path it was loaded from. This patch fixes that issue by always reverting to disk paths if we're not in the network boot. That way the data structures after a network boot look the same as before. Signed-off-by: Alexander Graf <agraf@suse.de>
2016-10-19efi_loader: Rename EFI_RUNTIME_{TEXT, DATA} to __efi_runtime{, _data}Alexander Graf
Compiler attributes are more commonly __foo style tags rather than big upper case eye sores like EFI_RUNTIME_TEXT. Simon Glass felt quite strongly about this, so this patch converts our existing defines over to more eye friendly ones. Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Simon Glass <sjg@chromium.org>
2016-10-19x86: efi: Add EFI loader support for x86Simon Glass
Add the required pieces to support the EFI loader on x86. Since U-Boot only builds for 32-bit on x86, only a 32-bit EFI application is supported. If a 64-bit kernel must be booted, U-Boot supports this directly using FIT (see doc/uImage.FIT/kernel.its). U-Boot can act as a payload for both 32-bit and 64-bit EFI. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Signed-off-by: Alexander Graf <agraf@suse.de>
2016-10-19efi: Fix missing EFIAPI specifiersSimon Glass
These are missing in some functions. Add them to keep things consistent. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de>
2016-10-19efi: Use asmlinkage for EFIAPISimon Glass
This is required for x86 and is also correct for ARM (since it is empty). Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Signed-off-by: Alexander Graf <agraf@suse.de>
2016-10-19smbios: Provide serial numberAlexander Graf
If the system has a valid "serial#" environment variable set (which boards that can find it out programatically set automatically), use that as input for the serial number and UUID fields in the SMBIOS tables. Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2016-10-19efi_loader: Fix efi_install_configuration_tableAlexander Graf
So far we were only installing the FDT table and didn't have space to store any other. Hence nobody realized that our efi table allocation was broken in that it didn't set the indicator for the number of tables plus one. This patch fixes it, allowing code to allocate new efi tables. Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Simon Glass <sjg@chromium.org>
2016-10-19smbios: Expose in efi_loader as tableAlexander Graf
We can pass SMBIOS easily as EFI configuration table to an EFI payload. This patch adds enablement for that case. While at it, we also enable SMBIOS generation for ARM systems, since they support EFI_LOADER. Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2016-10-19smbios: Generate type 4 on non-x86 systemsAlexander Graf
The type 4 table generation code is very x86 centric today. Refactor things out into the device model cpu class to allow the tables to get generated for other architectures as well. Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2016-10-19cpu: Add get_vendor callbackAlexander Graf
The CPU udevice already has a few callbacks to retreive information about the currently running CPUs. This patch adds a new get_vendor() call that returns the vendor of the main CPUs. Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2016-10-19cpu: Add DMTF id and family fieldsAlexander Graf
For SMBIOS tables we need to know the CPU family as well as CPU IDs. This patches allocates some space for them in the cpu device and populates it on x86. Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2016-10-19smbios: Allow compilation on 64bit systemsAlexander Graf
The SMBIOS generation code passes pointers as u32. That causes the compiler to warn on casts to pointers. This patch moves all address pointers to uintptr_t instead. Technically u32 would be enough for the current SMBIOS2 style tables, but we may want to extend the code to SMBIOS3 in the future which is 64bit address capable. Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2016-10-19efi_loader: Expose efi_install_configuration_tableAlexander Graf
We want to be able to add configuration table entries from our own code as well as from EFI payload code. Export the boot service function internally too, so that we can reuse it. Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Simon Glass <sjg@chromium.org>
2016-10-19x86: Move smbios generation into arch independent directoryAlexander Graf
We will need the SMBIOS generation function on ARM as well going forward, so let's move it into a non arch specific location. Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2016-10-19x86: Move table csum into separate fileAlexander Graf
We need the checksum function without all the other table functionality soon, so let's split it out into its own C file. Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2016-10-19efi_loader: gop: Expose fb when 32bppAlexander Graf
When we're running in 32bpp mode, expose the frame buffer address to our payloads so that Linux efifb can pick it up. Signed-off-by: Alexander Graf <agraf@suse.de>
2016-10-19efi_loader: Allow bouncing for networkAlexander Graf
So far bounce buffers were only used for disk I/O, but network I/O may suffer from the same problem. On platforms that have problems doing DMA on high addresses, let's also bounce outgoing network packets. Incoming ones always already get bounced. This patch fixes EFI PXE boot on ZynqMP for me. Signed-off-by: Alexander Graf <agraf@suse.de>
2016-10-19efi_loader: Add generic PSCI RTSAlexander Graf
Now that we have generic PSCI reset and shutdown support in place, we can advertise those as EFI Run Time Services, allowing efi applications and OSs to reset and shut down systems. Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Simon Glass <sjg@chromium.org>
2016-10-19arm: Provide common PSCI based reset handlerAlexander Graf
Most armv8 systems have PSCI support enabled in EL3, either through ARM Trusted Firmware or other firmware. On these systems, we do not need to implement system reset manually, but can instead rely on higher level firmware to deal with it. The exclude list seems excessive right now, but NXP is working on providing an in-tree PSCI implementation, so that all NXP systems can eventually use PSCI as well. Signed-off-by: Alexander Graf <agraf@suse.de> [agraf: fix meson] Reviewed-by: Simon Glass <sjg@chromium.org>
2016-10-18Merge branch 'master' of git://git.denx.de/u-boot-uniphierTom Rini
2016-10-18Merge git://git.denx.de/u-boot-x86Tom Rini
2016-10-18x86: Add implementations of setjmp() and longjmp()Simon Glass
Bring in these functions from Linux v4.4. They will be needed for EFI loader support. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2016-10-18x86: Move table csum into separate headerAlexander Graf
We need the checksum function without all the other table functionality soon, so let's split it out into its own header file. Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2016-10-18arm: Add PSCI shutdown functionAlexander Graf
Using PSCI you can not only reset the system, you can also shut it down! This patch exposes a function to do exactly that to whatever code wants to make use of it. Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Simon Glass <sjg@chromium.org>
2016-10-18arm: Disable HVC PSCI calls by defaultAlexander Graf
All systems that are running on armv8 are running bare metal with firmware that implements PSCI running in EL3. That means we don't really need to expose the hypercall variants of them. This patch leaves the code in, but makes the code explicit enough to have the compiler optimize it out. With this we don't need to worry about hvc vs smc calling convention when calling psci helper functions. Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Simon Glass <sjg@chromium.org>
2016-10-18efi_loader: Allow boards to implement get_time and reset_systemAlexander Graf
EFI allows an OS to leverage firmware drivers while the OS is running. In the generic code we so far had to stub those implementations out, because we would need board specific knowledge about MMIO setups for it. However, boards can easily implement those themselves. This patch provides the framework so that a board can implement its own versions of get_time and reset_system which would actually do something useful. While at it we also introduce a simple way for code to reserve MMIO pointers as runtime available. Signed-off-by: Alexander Graf <agraf@suse.de>
2016-10-18efi_loader: Do not leak memory when unlinking a mappingStefan Brüns
As soon as a mapping is unlinked from the list, there are no further references to it, so it should be freed. If it not unlinked, update the start address and length. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de>
2016-10-18efi_loader: Keep memory mapping sorted when splitting an entryStefan Brüns
The code assumes sorted mappings in descending address order. When splitting a mapping, insert the new part next to the current mapping. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de>
2016-10-18efi_loader: Readd freed pages to memory poolStefan Brüns
Currently each allocation creates a new mapping. Readding the mapping as free memory (EFI_CONVENTIONAL_MEMORY) potentially allows to hand out an existing mapping, thus limiting the number of mapping descriptors in the memory map. Mitigates a problem with current (4.8rc7) linux kernels when doing an efi_get_memory map, resulting in an infinite loop. Space for the memory map is reserved with allocate_pool (implicitly creating a new mapping) and filled. If there is insufficient slack space (8 entries) in the map, the space is freed and a new round is started, with space for one more entry. As each round increases requirement and allocation by exactly one, there is never enough slack space. (At least 32 entries are allocated, so as long as there are less than 24 entries, there is enough slack). Earlier kernels reserved no slack, and did less allocations, so this problem was not visible. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de>
2016-10-18efi_loader: Track size of pool allocations to allow freeingStefan Brüns
We need a functional free_pool implementation, as otherwise each allocate_pool causes growth of the memory descriptor table. Different to free_pages, free_pool does not provide the size for the to be freed allocation, thus we have to track the size ourselves. As the only EFI requirement for pool allocation is an alignment of 8 bytes, we can keep allocating a range using the page allocator, reserve the first 8 bytes for our bookkeeping and hand out the remainder to the caller. This saves us from having to use any independent data structures for tracking. To simplify the conversion between pool allocations and the corresponding page allocation, we create an auxiliary struct efi_pool_allocation. Given the allocation size free_pool size can handoff freeing the page range, which was indirectly allocated by a call to allocate_pool, to free_pages. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de>
2016-10-18efi_loader: Move efi_allocate_pool implementation to efi_memory.cStefan Brüns
We currently handle efi_allocate_pool() in our boot time service file. In the following patch, pool allocation will receive additional internal semantics that we should preserve inside efi_memory.c instead. As foundation for those changes, split the function into an externally facing efi_allocate_pool_ext() for use by payloads and an internal helper efi_allocate_pool() in efi_memory.c that handles the actual allocation. While at it, change the magic 0xfff / 12 constants to the more obvious EFI_PAGE_MASK/SHIFT defines. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de>
2016-10-18efi_loader: Fix crash on 32-bit systemsRobin Randhawa
A type mismatch in the efi_allocate_pool boot service flow causes hazardous memory scribbling on 32-bit systems. This is efi_allocate_pool's prototype: static efi_status_t EFIAPI efi_allocate_pool(int pool_type, unsigned long size, void **buffer); Internally, it invokes efi_allocate_pages as follows: efi_allocate_pages(0, pool_type, (size + 0xfff) >> 12, (void*)buffer); This is efi_allocate_pages' prototype: efi_status_t efi_allocate_pages(int type, int memory_type, unsigned long pages, uint64_t *memory); The problem: efi_allocate_pages does this internally: *memory = addr; This fix in efi_allocate_pool uses a transitional uintptr_t cast to ensure the correct outcome, irrespective of the system's native word size. This was observed when bootefi'ing the EFI instance of FreeBSD's first stage bootstrap (boot1.efi) on a 32-bit ARM platform (Qemu VExpress + Cortex-a9). Signed-off-by: Robin Randhawa <robin.randhawa@arm.com> Signed-off-by: Alexander Graf <agraf@suse.de>
2016-10-18efi_loader: Fix memory map size check to avoid out-of-bounds accessStefan Brüns
The current efi_get_memory_map() function overwrites the map_size property before reading its value. That way the sanity check whether our memory map fits into the given array always succeeds, potentially overwriting arbitrary payload memory. This patch moves the property update write after its sanity check, so that the check actually verifies the correct value. So far this has not triggered any known bugs, but we're better off safe than sorry. If the buffer is to small, the returned memory_map_size indicates the required size to the caller. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de>
2016-10-18efi_loader: Update description of internal efi_mem_carve_outStefan Brüns
In 74c16acce30bb882ad5951829d8dafef8eea564c the return values where changed, but the description was kept. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de>
2016-10-18ARM: uniphier: update doc/README.uniphierMasahiro Yamada
- Rephrase the toolchains section. Leave only Linaro toolchains since it is the most tested these days. - Add build instruction for ARMv8 SoC boards - Add information about "ddrmphy" command Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2016-10-18ARM: uniphier: remove unnecessary EHCI reset deassertionMasahiro Yamada
It is now deasserted by the reset controller driver. Drop the ad-hoc code. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2016-10-18ARM: dts: uniphier: sync DT with latest LinuxMasahiro Yamada
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2016-10-18clk: uniphier: rework UniPhier clk driverMasahiro Yamada
The initial design of the UniPhier clk driver for U-Boot was not very nice. Here is a re-work to sync it with Linux's clk and reset drivers, maximizing the code reuse from Linux's clk data. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2016-10-18ARM: uniphier: remove unneeded CONFIG_USB_MAX_CONTROLLER_COUNT defineMasahiro Yamada
ARCH_UNIPHIER selects DM_USB, where CONFIG_USB_MAX_CONTROLLER_COUNT is not used. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2016-10-18ARM: uniphier: fix addresses of Cortex-A72 gear setting macrosMasahiro Yamada
My mistake during copy-paste work. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2016-10-18pinctrl: uniphier: fix unused-const-variable warnings for GCC 6.xMasahiro Yamada
Marek reports warnings in UniPhier pinctrl drivers when compiled by GCC 6.x, like: drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c:58:18: warning: 'usb3_muxvals' defined but not used [-Wunused-const-variable=] static const int usb3_muxvals[] = {0, 0}; ^~~~~~~~~~~~ My intention here is to compile minimum set of pin data for SPL to save memory footprint, but GCC these days is clever enough to notice unused data arrays. We can fix it by sprinkling around __maybe_unused on those arrays, but I did not do that because they are counterparts of the pinctrl drivers in Linux. All the pin data were just copy-pasted from Linux and are kept in sync for maintainability. I chose a bit tricky way to fix the issue; calculate ARRAY_SIZE of *_pins and *_muxvals and set their sum to an unused struct member. This trick will satisfy GCC because the data arrays are used anyway, but such data arrays will be dropped from the final binary because the pointers to them are not used. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reported-by: Marek Vasut <marex@denx.de>
2016-10-18watchdog: Fix Watchdog Reset while in U-Boot PromptAndreas J. Reichel
Hardware: CM-FX6 Module from Compulab This patch fixes unwanted watchdog resets while the user enters a command at the U-Boot prompt. As found on the CM-FX6 board from Compulab, when having enabled the watchdog, a missing WATCHDOG_RESET call in common/console.c causes this and alike boards to reset when the watchdog's timeout has elapsed while waiting at the U-Boot prompt. Despite the user could press several keys within the watchdog timeout limit, the while loop in cli_readline.c, line 261, does only call WATCHDOG_RESET if first == 1, which gets set to 0 in the 1st loop iteration. This leads to a watchdog timeout no matter if the user presses keys or not. Although, this affects other boards as well as it touches common/console.c, the macro WATCHDOG_RESET expands to {} if watchdog support isn't configured. Hence, there's no harm caused and no need to surround it by #ifdef in this case. * Symptom: U-Boot resets after watchdog times out when in commandline prompt and watchdog is enabled. * Reasoning: When U-Boot shows the commandline prompt, the following function call stack is executed while waiting for a keypress: common/main.c: main_loop => common/cli.c: cli_loop() => common/cli_hush.c: parse_file_outer => parse_stream_outer => parse_stream => b_getch(i) => i->get(i) => file_get => get_user_input => cmdedit_read_input => uboot_cli_readline => common/cli_readline.c: cli_readline => cli_readline_into_buffer => cread_line => getcmd_getch (== getc) => common/console.c: fgetc => console_tstc common/console.c: (with CONFIG_CONSOLE_MUX is set) - in console_tstc line 181: If dev->tstc(dev) returns 0, the global tstcdev variable doesn't get set. This is the case if no character is in the serial buffer. - in fgetc(int file), line 297: Program flow keeps looping because tstcdev does not get set. Therefore WATCHDOG_RESET is not called, as mx_serial_tstc from drivers/serial/serial_mxc.c does not call it. * Solution: Add WATCHDOG_RESET into the loop of console_tstc. Note: Macro expands to {} if not configured, so no #ifdef is needed. * Comment: Signed-off-by: Christian Storm <christian.storm@tngtech.com> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Andreas J. Reichel <Andreas.Reichel@tngtech.com> Acked-by: Simon Glass <sjg@chromium.org>
2016-10-18Prepare v2016.11-rc2Tom Rini
Signed-off-by: Tom Rini <trini@konsulko.com>
2016-10-15Merge git://git.denx.de/u-boot-mpc85xxTom Rini
2016-10-15spl: move FDT_FIXUP_PARTITIONS to KconfigHeiko Schocher
Move FDT_FIXUP_PARTITIONS to Kconfig and cleanup existing uses. Signed-off-by: Heiko Schocher <hs@denx.de>
2016-10-15spl: move SYS_OS_BASE to KconfigHeiko Schocher
Move SYS_OS_BASE to Kconfig and cleanup existing uses. Signed-off-by: Heiko Schocher <hs@denx.de> [trini: Also migrate a4m2k] Signed-off-by: Tom Rini <trini@konsulko.com>
2016-10-15spl: move SPL_OS_BOOT to KconfigHeiko Schocher
Move SPL_OS_BOOT to Kconfig and cleanup existing uses. Signed-off-by: Heiko Schocher <hs@denx.de>
2016-10-14test/py/tests/test_sleep.py: Add check for CONFIG_CMD_MISCTom Rini
We can only run this command if the sleep command is enabled and that depends on CONFIG_CMD_MISC Signed-off-by: Tom Rini <trini@konsulko.com>
2016-10-14ARM: create .secure_stack section only for PSCIMasahiro Yamada
Jon Master reports that QEMU refuses to load a U-Boot image built with CONFIG_ARMV7_NONSEC, but without CONFIG_ARMV7_PSCI since commit 5a3aae68c74e ("ARM: armv7: guard memory reserve for PSCI with #ifdef CONFIG_ARMV7_PSCI"). It looks like only PSCI that needs the Secure stack, so move the #ifdef to guard the whole of .secure_stack allocation in order not to create the empty section. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reported-by: Jon Masters <jcm@redhat.com> Link: http://patchwork.ozlabs.org/patch/664025/