Simon Glass [Mon, 26 Nov 2018 03:14:38 +0000 (20:14 -0700)]
efi: Create a function to set up for running EFI code
There is still duplicated code in efi_loader for tests and normal
operation.
Add a new bootefi_run_prepare() function which holds common code used to
set up U-Boot to run EFI code. Make use of this from the existing
bootefi_test_prepare() function, as well as do_bootefi_exec().
Also shorten a few variable names.
Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
Simon Glass [Mon, 26 Nov 2018 03:14:37 +0000 (20:14 -0700)]
efi: Split out test init/uninit into functions
The functions in bootefi are very long because they mix high-level code
and control with the low-level implementation. To help with this, create
functions which handle preparing for running the test and cleaning up
afterwards.
Also shorten the awfully long variable names here.
Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
Simon Glass [Mon, 26 Nov 2018 03:14:36 +0000 (20:14 -0700)]
efi: Check for failure to create objects in selftest
At present a few error conditions are not checked. Before refactoring
this code, add some basic checks. Note that this code still leaks memory
in the event of error. This will be tackled after the refactor.
Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexander Graf <agraf@suse.de>
Alexander Graf [Fri, 30 Nov 2018 20:24:56 +0000 (21:24 +0100)]
efi_loader: Reserve unaccessible memory
On some systems, not all RAM may be usable within U-Boot. Maybe the
memory maps are incomplete, maybe it's used as workaround for broken
DMA. But whatever the reason may be, a platform can say that it does
not wish to have its RAM accessed above a certain address by defining
board_get_usable_ram_top().
In the efi_loader world, we ignored that hint, mostly because very few
boards actually have real restrictions around this.
So let's honor the board's wish to not access high addresses during
boot time. The best way to do so is by indicating the respective pages
as "allocated by firmware". That way, Operating Systems will still
use the pages after boot, but before boot no allocation will use them.
Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Baruch Siach <baruch@tkos.co.il>
The "Devicetree Specification 0.2" does not prescribe that memory
reservations must be EFI page aligned. So let's not make such an
assumption in our code.
Do not carve out the pages for the device tree. This memory area is
already marked as EFI_RUNTIME_SERVICES_DATA.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
In copy_fdt() we allocate EFI pages for the fdt plus extra 12 KiB as
EFI_RUNTIME_SERVICES_DATA. Afterwards in efi_install_fdt() we overwrite
part of this memory allocation by marking it as EFI_BOOT_SERVICES_DATA.
Remove the code marking the fdt as EFI_BOOT_SERVICES_DATA.
Cf. commit 17ff6f02f5ad ("efi_loader: store DT in EFI_RUNTIME_SERVICES_DATA
memory")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
Alexander Graf [Sun, 4 Nov 2018 23:30:46 +0000 (00:30 +0100)]
efi_loader: Ensure memory allocations are page aligned
When the max_addr parameter of efi_find_free_memory() is within bounds
of an existing map and fits the reservation, we just return that address
as allocation value.
That breaks however if max_addr is not page aligned. So ensure that it
always comes to us page aligned, simplifying the allocation logic.
Without this, I've seen breakage where we were allocating pages at -1U
(32bit) which fits into a region that spans beyond 0x100000000. In that
case, we would return 0xffffffff as a valid memory allocation, although
we usually do guarantee they are all page aligned.
Fix this by aligning the max address argument always.
With RELA absolute relocations, the relocation target contains our link
offset which we need to remove from the equation again. We did this
properly in the relative relocation path, but not in the absolute one.
So let's do this for the absolute one as well. That way, u-boot can have
a TEXT_OFFSET of != 0 and still relocate itself properly.
This fixes a bug where efi_loader did not work on the RISC-V QEMU port.
With this patch, I can successfully run UEFI applications on the RISC-V
QEMU port.
Reported-by: Auer, Lukas <lukas.auer@aisec.fraunhofer.de> Signed-off-by: Alexander Graf <agraf@suse.de> Tested-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>
Alexander Graf [Fri, 19 Oct 2018 12:41:01 +0000 (14:41 +0200)]
usb: Do not compile USB_STORAGE with BLK && !DM_USB
The USB storage driver does not compile when CONFIG_BLK is set,
but DM_USB is not set, as we're missing the DM device links for
CONFIG_BLK enabled code paths.
So far it looks like nobody fell into this trap, because no board
enabled CONFIG_BLK and CONFIG_USB_STORAGE while not enabling
CONFIG_DM_USB, but we should still reflect that dependency properly
in Kconfig so that implicit enabling of CONFIG_USB_STORAGE works.
When an operating system started via bootefi tries to reset or power off
this is done by calling the EFI runtime ResetSystem(). On most ARMv8 system
the actual reset relies on PSCI. Depending on whether the PSCI firmware
resides the hypervisor (EL2) or in the secure monitor (EL3) either an HVC
or an SMC command has to be issued.
The current implementation always uses SMC. This results in crashes on
systems where the PSCI firmware is implemented in the hypervisor, e.g.
qemu-arm64_defconfig.
The logic to decide which call is needed based on the device tree is
already implemented in the PSCI firmware driver. During the EFI runtime
the device driver model is not available. But we can minimize code
duplication by merging the EFI runtime reset and poweroff code with
the PSCI firmware driver.
As the same HVC/SMC problem is also evident for the ARMv8 do_poweroff
and reset_misc routines let's move them into the same code module.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Sumit Garg <sumit.garg@linaro.org> Tested-by: Sumit Garg <sumit.garg@linaro.org> Signed-off-by: Alexander Graf <agraf@suse.de>
Bin Meng [Tue, 2 Oct 2018 14:39:34 +0000 (07:39 -0700)]
riscv: efi: Generate Microsoft PE format compliant images
Per Microsoft PE Format documentation [1], PointerToSymbolTable and
NumberOfSymbols should be zero for an image in the COFF file header.
Currently the COFF file header is hardcoded on RISC-V and these two
members are not zero.
This updates the hardcoded structure to clear these two members, as
well as setting the flag IMAGE_FILE_LOCAL_SYMS_STRIPPED so that we
can generate compliant *.efi images.
Bin Meng [Tue, 2 Oct 2018 14:39:33 +0000 (07:39 -0700)]
arm: efi: Generate Microsoft PE format compliant images
Per Microsoft PE Format documentation [1], PointerToSymbolTable and
NumberOfSymbols should be zero for an image in the COFF file header.
Currently the COFF file header is hardcoded on ARM and these two
members are not zero.
This updates the hardcoded structure to clear these two members, as
well as setting the flag IMAGE_FILE_LOCAL_SYMS_STRIPPED so that we
can generate compliant *.efi images.
Bin Meng [Tue, 2 Oct 2018 14:39:31 +0000 (07:39 -0700)]
x86: efi: app: Generate Microsoft PE format compliant image
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.
Bin Meng [Tue, 2 Oct 2018 14:39:30 +0000 (07:39 -0700)]
x86: efi: payload: Generate Microsoft PE format compliant image
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.
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>
Bin Meng [Tue, 2 Oct 2018 14:39:29 +0000 (07:39 -0700)]
efi_loader: Generate Microsoft PE format compliant images
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 *.efi images (eg: helloworld.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.
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>
If UninstallMultipleProtocolInterfaces fails, we sometimes return the wrong
status code. The UEFI spec mandates to always return EFI_INVALID_PARAMETER.
Update unit test.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
All our handles point to a struct efi_object. So let's define the
efi_handle_t accordingly. This helps us to discover coding errors much
more easily. This becomes evident by the corrections to the usage of
handles in this patch.
Rename variable image_handle to image_obj where applicable.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
drivers: rtc: correctly convert seconds to time structure
Variable 'days' must be defined as signed int. Otherwise the conversion
fails for some dates, e.g. 2004-08-25. Cf function rtc_time64_to_tm() in
the Linux kernel source.
Fixes: 992c1db45591 "drivers: rtc: resolve year 2038 problem in rtc_to_tm" Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Tom Rini [Sat, 1 Dec 2018 19:17:27 +0000 (14:17 -0500)]
Merge tag 'for-master-20181130' of git://git.denx.de/u-boot-rockchip
Improvements:
- RK3188 USB-UART functionality
- errors triggering a hard-stop in SPL on the RK3399 are reported
- Rockchip RV1108 (SoC) support
- MicroCrystal RV3029 (RTC) DM driver
Fixes:
- RK3188 early UART setup
- limit SD-card frequency to 40MHz on the RK3399-Q7
- MIPI fixes
- RK3399 CPUB clock initialisation
Tom Rini [Fri, 30 Nov 2018 22:09:50 +0000 (17:09 -0500)]
Merge tag 'pull-30nov18' of git://git.denx.de/u-boot-dm
Fix sound on sandbox
Convert TPM fully to DM
Tidy up sandbox I2C emulation
Add a 'make qcheck' target for faster testing
A few other misc things
(dropped the final patch which breaks clang for some reason)
Philipp Tomsich [Tue, 27 Nov 2018 21:53:58 +0000 (22:53 +0100)]
rtc: rv3029: update to support DM and sync with Linux 4.17
The "Flamingo" carrier-board for the RK3399-Q7 has a RV3029 populated
and the application will use the off-module RV3029 RTC including the
battery backed SRAM.
To support this use case, this commit includes the following changes:
* updates the rv3029 driver to use DM
* implements the read8/write8 operations
This syncs the implementation with the Linux code (based on 4.17),
porting the trickle-charger support from there (with improvements to
avoid unnecessary EEPROM updates) and adheres to the Linux DTS
binding.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Tested-by: Klaus Goger <klaus.goger@theobroma-systems.com>
Otavio Salvador [Fri, 30 Nov 2018 13:34:13 +0000 (11:34 -0200)]
ARM: rockchip: rv1108: Enable BOUNCE_BUFFER
In order to be able to build the Rockchip eMMC driver on rv1108, the
BOUNCE_BUFFER option needs to be selected. Select it like it is done
on the other Rockchip SoC common files.
Reviewed-by: Andy Yan <andy.yan@rock-chips.com> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Philipp Tomsich [Fri, 30 Nov 2018 17:58:58 +0000 (18:58 +0100)]
rockchip: rk3399-puma: reduce sd card max-frequency to 40MHz
Some SanDisk Ultra cards trigger intermittent errors on detection
resulting in an -EOPNOTSUPP, when running at 50MHz.
Waveform analysis suggest that the level shifters that are used on the
RK3399-Q7 module (for voltage translation between the on-module
voltages and the 3.3V required on the card-edge) don't handle clock
rates at or above 48MHz properly. This change reduces the maximum
frequency on the external SD-interface to 40MHz (for a safety margin
of 20%).
Reported-by: Jakob Unterwurzacher <jakob.unterwurzacher@theobroma-systems.com> Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Tested-by: Christoph Muellner <christoph.muellner@theobroma-systems.com>
Kever Yang [Thu, 29 Nov 2018 01:59:41 +0000 (09:59 +0800)]
rockchip: rock: remove TPL_TINY_MEMSET
The RK3188 rock board does not need TPL: remove TPL_TINY_MEMSET from
config.
Signed-off-by: Kever Yang <kever.yang@rock-chips.com> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
[Fixed up commit message:] Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Philipp Tomsich [Mon, 19 Nov 2018 12:03:51 +0000 (13:03 +0100)]
rockchip: rk3399: spl: always report errors triggering a hard stop
The RK3399 SPL has two cases that may end in a hard-stop: if either
the pinctrl can not be initialised or if the DRAM fails to initialise.
Both have previously not triggered an error message unless DEBUG was
defined (i.e. both used debug() to print the error).
This converts both error messages to be printed using pr_err() to
ensure that some output points to the cause of the hard-stop.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Richard Röjfors [Wed, 14 Nov 2018 13:13:53 +0000 (14:13 +0100)]
rockchip: video: mipi: Fix phy frequency setting
There was an incorrect check when looping and finding the first
fast enough frequency in the freq_rang table. The code did
actually return the first that was either exactly correct or
too slow.
Signed-off-by: Richard Röjfors <richard@puffinpack.se> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Heiko Stuebner [Mon, 8 Oct 2018 11:01:57 +0000 (13:01 +0200)]
rockchip: rk3188: fix early uart setup
Commit 7a6d7d3e1279 ("rockchip: pinctrl: rk3188: Move the iomux definitions
into pinctrl-driver") moved the iomux settings out of the grf header
to prevent conflicts with the iomux definitions of other rockchip socs.
This also breaks the early uart setup, as the iomux for uart2 are needed.
To fix that just put the tiny amount of needed iomux definitions next to
the early uart code.
Fixes: 7a6d7d3e1279 ("rockchip: pinctrl: rk3188: Move the iomux definitions into pinctrl-driver") Signed-off-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Heiko Stuebner [Mon, 8 Oct 2018 11:01:56 +0000 (13:01 +0200)]
rockchip: rk3188: add support for usb-uart functionality
Rockchip socs can route the debug uart pins through the d+ and d- pins
of one specific usbphy per soc. Add a config option and implement the
setting on the rk3188.
Signed-off-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
[Fixed up to mark grf as maybe unused:] Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Stefan Roese [Fri, 30 Nov 2018 06:46:30 +0000 (07:46 +0100)]
mips: mt76xx: gardena-smart-gateway: Add factory data variable handling
Some factory data is stored in the SPI NOR and needs to get extracted
from there into U-Boot environment variables.
This patch also includes a board-specific command "fd_write" to
provide some dummy / default values for this factory-data in the SPI
NOR flash. This should only be necessary for testing purposes though.
Signed-off-by: Stefan Roese <sr@denx.de> Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Tom Rini [Fri, 30 Nov 2018 16:20:03 +0000 (11:20 -0500)]
Merge git://git.denx.de/u-boot-marvell
- Some Kirkwood boards converted to DM_SPI by Chris
- New Armada-385 SoC revision printed by Chris
- Ethernet enable on mcbin by Baruch
- Support 2 DRAM banks on Armada-8k boards by Baruch
Chris Packham [Tue, 27 Nov 2018 21:32:00 +0000 (10:32 +1300)]
ARM: mvebu: add revision id for Armada-385 B0
Marvell have release a B0 revision of the Armada-385 SoC. This fixes a
hardware errata enabling RGMII to work when the Ethernet voltage is
configured to 3.3V.
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 [Wed, 21 Nov 2018 07:59:32 +0000 (09:59 +0200)]
arm: mvebu: configs: armada8k: use 2 DRAM banks
Commit 2b4d964718c0 ("arm64: mvebu: a8k: autodetect RAM size") added an
ATF query to get the detected RAM size on Armada 8K platforms. To be
usable we must have 2 DRAM banks. Set Armada 8K configurations to 2
banks.
Cc: Konstantin Porotchkin <kostap@marvell.com> Signed-off-by: Baruch Siach <baruch@tkos.co.il> Reviewed-by: Stefan Roese <sr@denx.de> Signed-off-by: Stefan Roese <sr@denx.de>
Keerthy [Mon, 19 Nov 2018 06:14:47 +0000 (11:44 +0530)]
core: ofnode: Fix ofnode_get_addr_index function
Currently the else part of ofnode_get_addr_index function
does not fetch addresses based on the index but rather just
returns the base address. Fix that.
Simon Glass [Sun, 18 Nov 2018 21:22:27 +0000 (14:22 -0700)]
tpm: Convert to use a device parameter
At present many TPM calls assume there is only one TPM in the system and
look up this TPM themselves. This is inconsistent with driver model, which
expects all driver methods to have a device parameter. Update the code to
correct this.
Simon Glass [Sun, 18 Nov 2018 21:22:26 +0000 (14:22 -0700)]
tpm: Export the open/close functions
At present these functions are not accessible outside the TPM library, but
in some cases we need to call them. Export them in the header file and add
a define for the SHA1 digest size.
Also adjust tpm_open() to call tpm_close() first so that the TPM is in a
known state before opening (e.g. by a previous phase of U-Boot).
Simon Glass [Tue, 13 Nov 2018 22:55:20 +0000 (15:55 -0700)]
sandbox: Use memmove() to move overlapping regions
The use of strcpy() to remove characters at the start of a string is safe
in U-Boot, since we know the implementation. But in os.c we are using the
C library's strcpy() function, where this behaviour is not permitted.
Update the code to use memmove() instead.
Reported-by: Coverity (CID: 173279) Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Alexander Graf <agraf@suse.de>
Simon Glass [Fri, 16 Nov 2018 02:56:14 +0000 (19:56 -0700)]
sound: sandbox: Use the correct frequency
At present we request a particular frequency but we may not get the exact
same frequency in response. So use the actual frequency for generation of
the square wave. This ensures that the pitch remains accurate on all host
machines.
Simon Glass [Fri, 16 Nov 2018 02:56:13 +0000 (19:56 -0700)]
sound: Add sample rate as a parameter for square wave
At present this value is hard-coded in the function that generates a
square wave. Since sample rates vary between different hardware, it makes
more sense to have this as a parameter.
In this case the emulation device is attached to i2c bus on address 0x43
and provides the Real-Time-Clock (RTC) functionality.
However this is not ideal, since every device on an I2C bus has a child
device. This is only really the case for sandbox, but we want to avoid
special-case code for sandbox.
A better approach seems to be to add a separate node on the bus, an
'emulation parent'. This can be given a bogus address (such as 0xff) and
hides all the emulators away. Then we can use a phandle to point from the
device to the correct emualtor, and only on sandbox. The code to find an
emulator does not interfere with normal i2c operation.
Add a new UCLASS_I2C_EMUL_PARENT uclass which allows finding an emulator
given a bus, and finding a bus given an emulator. This will be used in a
follow-on patch.
Simon Glass [Sun, 18 Nov 2018 15:14:32 +0000 (08:14 -0700)]
dm: core: Put UCLASS_SIMPLE_BUS in order
This is currently at the top in the space for internal use. But this
uclass is used outside driver model and test code. Move it into the
correct alpha order.
Simon Glass [Sun, 18 Nov 2018 15:14:31 +0000 (08:14 -0700)]
dm: core: Add a few more specific child-finding functions
Add two functions which can find a child device by uclass or by name.
The first is useful with Multi-Function-Devices (MFDs) to find one of a
particular type. The second is useful when only the name is known.
Simon Glass [Sun, 18 Nov 2018 15:14:29 +0000 (08:14 -0700)]
test: Add a 'make qcheck' target for quicker testing
At present tests are quite slow to run, over a minute on my machine. This
presents a considerable barrier to bisecting for failures.
The slowest tests are the filesystem ones and the buildman --fetch-arch
test. Add a new 'qcheck' target that skips these tests. This reduces test
time down to about 40 second, still too long, but bearable.
dts: arm: socfpga: merge gen5 devicetrees from linux
Add -u-boot.dtsi files to keep the current U-Boot behaviour:
- add u-boot,dm-pre-reloc where required
- disable watchdog
- set uart clock frequency
- add gpio bank-name properties
where appropriate:
- make qspi work (add alias for spi0, fix compatible for flash)
- enable usb (status okay, add alias for udc0)
Adapt board dts files that are not in Linux to keep their old
behaviour.
Change licenses to SPDX.
(Patman warnings/errors are in 1:1 copied files from Linux)
Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
projects / u-boot.git / log
