We need to implement to different functions for the
EFI_DEVICE_PATH_TO_TEXT_PROTOCOL:
ConvertDeviceNodeToText
ConvertDevicePathToText
A recent patch screwed up efi_convert_device_node_to_text
to expect a device path and not a node.
The patch makes both service functions work again.
efi_convert_device_node_to_text is renamed to
efi_convert_single_device_node_to_text and
efi_convert_device_node_to_text_ext is renamed to
efi_convert_device_node_to_text to avoid future
confusion.
A test of ConvertDeviceNodeToText will be provided in
a follow-up patch.
Fixes: adae4313cdd efi_loader: flesh out device-path to text Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
This used to work in v2017.09. Testing has shown, that this bug was
introduced with patch 95c5553e [efi_loader: refactor boot device and
loaded_image handling].
This patch now checks if a valid "desc" is returned from blk_get_dev()
and only continues when "desc" is available. Resulting in this cmd
output (again):
=> load usb 0:1 03000000 abc
** Bad device usb 0 **
Signed-off-by: Stefan Roese <sr@denx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
Jonathan Gray [Wed, 22 Nov 2017 03:18:59 +0000 (14:18 +1100)]
efi_loader: initialise partition_signature memory
Zero partition_signature in the efi_device_path_hard_drive_path
structure when signature_type is 0 (no signature) as required by the
UEFI specification.
This is required so that efi_dp_match() will work as expected
when doing memcmp() comparisons. Previously uninitialised memory
would cause it not match nodes when it should have when the signature
type was not GUID.
Corrects a problem where the loaded image protocol would not return a
device path with MEDIA_DEVICE causing the OpenBSD bootloader to fail
on rpi_3 and other targets.
v2: Also handle signature_type 1 (MBR) as described in the specification
Signed-off-by: Jonathan Gray <jsg@jsg.id.au> Tested-by: Artturi Alm <artturi.alm@gmail.com> Signed-off-by: Alexander Graf <agraf@suse.de>
efi_loader: helper functions for protocol management
This patch provides helper functions to manage protocols.
efi_search_protocol - find a protocol on a handle
efi_add_protocol - install a protocol on a handle
efi_remove_protocol - remove a protocol from a handle
efi_remove_all_protocols - remove all protocols from a handle
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
Implement UninstallMultipleProtocolInterfaces.
The efi_uninstall_multipled_protocol_interfaces tries to
uninstall protocols one by one. If an error occurs all
uninstalled protocols are reinstalled.
As the implementation efi_uninstall_protocol_interface is
still incomplete the function will fail.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
EFI_HANDLEs are used both in boottime and in runtime services.
efi_search_obj is a function that can be used to validate
handles. So let's make it accessible via efi_loader.h.
We can simplify the coding using list_for_each_entry.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
UINTN is used in the UEFI specification for unsigned integers
matching the bitness of the CPU.
Types in U-Boot should be lower case. The patch replaces it
by efi_uintn_t.
Suggested-by: Simon Glass <sjg@chromium.org> Suggested-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
This unit test checks the following protocol services:
InstallProtocolInterface, UninstallProtocolInterface,
InstallMultipleProtocolsInterfaces,
UninstallMultipleProtocolsInterfaces,
HandleProtocol, ProtocolsPerHandle,
LocateHandle, LocateHandleBuffer.
As UninstallProtocolInterface and UninstallMultipleProtocolsInterfaces
are not completely implemented a TODO message will shown for
their failure.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
Currently we pass bootefi_device_path and bootefi_image_path as
device and image path without initializing them. They may carry
values from previous calls to bootefi.
With the patch the variables are initialized valid dummy values.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
Chris Packham [Tue, 28 Nov 2017 21:38:34 +0000 (10:38 +1300)]
arm: mvebu: correct comments around cas_wl/cas_l
The order of members in struct hws_topology_map is cas_wl, cas_l. The
comments in the original db-88f6820-gp.c had this wrong and have been
copied to other Armada-385 based boards. Practically this hasn't made a
difference since all these boards set both cas_wl and cas_l to 0
(autodetect) but if there were ever a board that did need to set these
explicitly they would run into unexpected issued.
Update the comments to reflect the correct order of structure members.
Reported-by: Tobi Wulff <tobi.wulff@alliedtelesis.co.nz> Signed-off-by: Chris Packham <judge.packham@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de> Signed-off-by: Stefan Roese <sr@denx.de>
Baruch Siach [Sun, 26 Nov 2017 07:21:23 +0000 (09:21 +0200)]
arm64: mvebu: armada-7k/8k: drop useless #ifdef
CONFIG_ENV_IS_IN_NAND has been removed in commit 2be296538e2e (Convert
CONFIG_ENV_IS_IN_MMC/NAND/UBI and NOWHERE to Kconfig).
CONFIG_ENV_IS_IN_SPI_FLASH has been removed in commit 91c868fe7cd
(Convert CONFIG_ENV_IS_IN_SPI_FLASH to Kconfig). The environment #ifdef
is now empty. Remove it.
Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Stefan Roese <sr@denx.de>
Stefan Roese [Wed, 29 Nov 2017 15:23:31 +0000 (16:23 +0100)]
x86: lib: Implement standalone __udivdi3 etc instead of libgcc ones
This patch removes the inclusion of the libgcc math functions and
replaces them by functions coded in C, taken from the coreboot
project. This makes U-Boot building more independent from the toolchain
installed / available on the build system.
The code taken from coreboot is authored from Vadim Bendebury
<vbendeb@chromium.org> on 2014-11-28 and committed with commit
ID e63990ef [libpayload: provide basic 64bit division implementation]
(coreboot git repository located here [1]).
I modified the code so that its checkpatch clean without any
functional changes.
[1] git://github.com/coreboot/coreboot.git
Signed-off-by: Stefan Roese <sr@denx.de> Cc: Simon Glass <sjg@chromium.org> Cc: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
The error message with FIT style image mentioned in the above commit
only happens when booting using FIT image containing bzImage kernel
and without setup node (setup.bin). The current documentation for
x86 FIT support in doc/uImage.FIT/x86-fit-boot.txt mentions that
kernel's setup.bin file is required for building x86 FIT images.
The above commit breaks FIT images generated as described in the
documentation. Revert it to allow booting with images built in the
documented way.
Signed-off-by: Anatolij Gustschin <agust@denx.de> Reviewed-by: Stefan Roese <sr@denx.de> Acked-by: Bin Meng <bmeng.cn@gmail.com>
Anton Gerasimov [Tue, 14 Nov 2017 17:47:16 +0000 (18:47 +0100)]
x86: qemu: Move Cache-As-RAM memory from area mapped to ROM
ROM has been made read-only in qemu recently (namely commit 208fa0e4:
"pc: make 'pc.rom' readonly when machine has PCI enabled"). So this
patch restores compatibility between U-Boot and qemu.
Signed-off-by: Anton Gerasimov <anton@advancedtelematic.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
[bmeng: mention qemu commit title in the commit message] Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Neil Armstrong [Fri, 24 Nov 2017 08:54:41 +0000 (09:54 +0100)]
fat: Use cache aligned buffers for fat_opendir
Before this patch one could receive following errors when executing "fatls"
command on machine with cache enabled (ex i.MX6Q) :
=> fatls mmc 0:1
CACHE: Misaligned operation at range [4f59dfc8, 4f59e7c8]
CACHE: Misaligned operation at range [4f59dfc8, 4f59e7c8]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x4f59dfc8
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x4f59e7c8
CACHE: Misaligned operation at range [4f59dfc8, 4f59e7c8]
CACHE: Misaligned operation at range [4f59dfc8, 4f59e7c8]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x4f59dfc8
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x4f59e7c8
To alleviate this problem - the calloc()s have been replaced with
malloc_cache_aligned() and memset().
After those changes the buffers are properly aligned (with both start
address and size) to SoC cache line.
Philipp Tomsich [Tue, 21 Nov 2017 22:29:40 +0000 (23:29 +0100)]
env: suppress a spurious warning with GCC 7.1
GCC 7.1 seems to be smart enough to track val through the various
static inline functions, but not smart enough to see that val will
always be initialised when no error is returned. This triggers
the following warning:
env/mmc.c: In function 'mmc_get_env_addr':
env/mmc.c:121:12: warning: 'val' may be used uninitialized in this function [-Wmaybe-uninitialized]
To make it easier for compiler to understand what is going on, let's
initialise val.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
spl: make CONFIG_OF_EMBED pass dts through fdtgrep
Building spl with CONFIG_OF_EMBED enabled results in an error message
on my board: "SPL image too big". This is because the fdtgrep build
step is only executed for CONFIG_OF_SEPARATE.
Fix this by moving the fdtgrep build step ('cmd_fdtgreo') from
scripts/Makefile.spl to dts/Makefile so that the reduced dtb is
available for all kinds of spl builds.
The resulting variable name for the embedded device tree blob changes,
too, which is why common.h and fdtdec.c have tiny changes.
Signed-off-by: Simon Goldschmidt <sgoldschmidt@de.pepperl-fuchs.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Adam Ford [Mon, 20 Nov 2017 15:56:03 +0000 (09:56 -0600)]
ARM: dts: Rename logicpd-toredp-37xx-devkit in U-Boot
In U-Boot, this device tree is compatible with both the Torpedo and
SOM-LV kits. Let's rename it in the device tree since the U-Boot code and
show a more generic OMAP3 name. The code auto detects between the two and
loads the proper DTB file for Linux. This would eliminate the SOM-LV showing
the name Torpedo during boot and hopefully eliminate some confusion.
Add a header for SAMA5D2 SMC since it's not compatible with
SAMA5D3 one.
Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
[wenyou: fix the wrong base address of the SMC register] Signed-off-by: Wenyou Yang <wenyou.yang@microchip.com>
mmc: atmel_sdhci: not on capabilities to set gck rate
The capabilities have default values which doesn't reflect the reality
when it concerns the base clock and the mul value. Use a fixe rate
for the gck. 240 MHz is an arbitrary choice, it is a multiple of the
maximum SD clock frequency handle by the controller and it allows to
get a 400 kHz clock for the card initialisation.
Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com> Signed-off-by: Wenyou Yang <wenyou.yang@microchip.com>
Wenyou Yang [Fri, 17 Nov 2017 06:50:22 +0000 (14:50 +0800)]
clk: at91: clk-generated: fix incorrect index of clk source
Differentiate the generic clock source selection value from the parent
clock index to fix the incorrect assignment of the generic clock
source selection.
Signed-off-by: Wenyou Yang <wenyou.yang@microchip.com>
Patrice Chotard [Wed, 15 Nov 2017 12:14:52 +0000 (13:14 +0100)]
clk: clk_stm32fx: add clock configuration for mmc usage
MMC block needs 48Mhz source clock, for that we choose
to select the SAI PLL.
Update also stm32_clock_get_rate() to retrieve the MMC
clock source needed in MMC driver.
STM32F4 uses a different RCC variant than STM32F7. For STM32F4
sdmmc clocks bit are located into dckcfgr register whereas there
are located into dckcfgr2 registers on STM32F7.
In both registers, bits CK48MSEL and SDMMC1SEL are located at
the same position.
Patrice Chotard [Wed, 15 Nov 2017 12:14:51 +0000 (13:14 +0100)]
dm: misc: bind STM32F4/F7 clock from rcc MFD driver
Like STM32H7, now STM32F4/F7 clock drivers are binded by
MFD stm32_rcc driver.
This also allows to add reset support to STM32F4/F7 SoCs family.
As Reset driver is not part of SPL supported drivers, don't bind it
in case of SPL to avoid that stm32_rcc_bind() returns an error.
Patrice Chotard [Wed, 15 Nov 2017 12:14:47 +0000 (13:14 +0100)]
clk: stm32f7: add STM32F4 support
STM32F4 and STM32F7 RCC clock IP are very similar.
Same driver can be used to managed RCC clock for
these 2 SoCs.
Differences between STM32F4 and F7 will be managed using
different compatible string :
_ overdrive clock is only supported by STM32F7
_ different sys_pll_psc parameters can be used between STM32F4
and STM32F7.
Patrice Chotard [Wed, 15 Nov 2017 12:14:46 +0000 (13:14 +0100)]
ARM: DTS: stm32: update rcc compatible for STM32F746
Align the RCC compatible string with the one used by kernel.
It will allow to use the same clock driver for STM32F4
and STM32F7 and to manage the differences between the 2 SoCs
Add a dedicated stm32f7 compatible string to use clk_stm32f7
driver with both STM32F4 and STM32F7 SoCs.
It will be needed to manage differences between these 2 SoCs.
tools: env: Add support for direct read/write UBI volumes
Up to now we were able to read/write environment data from/to UBI
volumes only indirectly by gluebi driver. This driver creates NAND MTD
on top of UBI volumes, which is quite a workaroung for this use case.
Add support for direct read/write UBI volumes in order to not use
obsolete gluebi driver.
Forward-ported from this patch:
http://patchwork.ozlabs.org/patch/619305/
Original patch: Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
Forward port: Signed-off-by: S. Lockwood-Childs <sjl@vctlabs.com>
projects / u-boot / log