- Jul 23, 2021
-
-
CNTFRQ_EL0 is only writable from the highest supported exception level on the platform. For Armv8-A, this is typically EL3, but technically EL2 and EL3 are optional so it may need to be initialized at EL2 or EL1. For Armv8-R, the highest exception level is always EL2. This patch moves the initialization outside of the switch_el block and uses a new macro branch_if_not_highest_el which dynamically detects whether it is at the highest supported exception level. Linux's docs state that CNTFRQ_EL0 should be initialized by the bootloader. If not set, the the U-Boot prompt countdown hangs. Signed-off-by:
Peter Hoyes <Peter.Hoyes@arm.com>
-
For some reason, the DragonBoard 410c aborts autoboot immediately if U-Boot is started without LK. It looks like it picks up a single broken character via serial and therefore believes a key was pressed to abort autoboot. After some debugging, it seems like adding some delay after pinctrl setup but before UART initialization fixes the issue. It's also worth mentioning that unlike when booting from LK, the pinctrl setup is actually necessary when booting U-Boot without LK since UART is broken if the pinctrl line is removed. I suspect that reconfiguring the pins might take some time to stabilize and if the UART controller is enabled too quickly it will pick up some random noise. Adding a few milliseconds of delay fixes the issue and shouldn't have any other negative side effects. 3ms seems to be the minimum delay required in my tests, use 5ms instead just to be sure. Signed-off-by:
Stephan Gerhold <stephan@gerhold.net>
-
At the moment pressing the volume down key does not actually launch fastboot. This is because setting "bootdelay" to "-1" actually disables autoboot and drops to the U-Boot console. It does not execute the "bootcmd". The correct value for "bootdelay" here would be "-2", which disables the delay and key checking and would immediately execute the "bootcmd". However, even better in this case is using "preboot" to trigger Fastboot. The advantage is that running "fastboot continue" will actually continue the autoboot process instead of ending up in the U-Boot shell. Also make sure to unset "preboot" again immediately in case the user saves the environment after triggering fastboot. Cc: Ramon Fried <rfried.dev@gmail.com> Fixes: aa043ee9 ("db410c: automatically launch fastboot") Signed-off-by:
Stephan Gerhold <stephan@gerhold.net> Reviewed-by:
Ramon Fried <rfried.dev@gmail.com>
-
The DragonBoard 410c has proprietary firmware from Qualcomm that reserves 8 MiB of memory for tz/smem/hyp/rmtfs/rfsa from 0x86000000 to 0x86800000. I'm not aware of any ATF (ARM Trusted Firmware) port for DB410c that would reserve 30 MiB of memory at the end of RAM. I suspect the comment might have been copied from hikey.h which has a very similar comment (and which actually does have an ATF port). Reducing the memory size just prevents U-Boot from using the end of the RAM, not the reserved region inbetween. Therefore we might as well display the correct DRAM size (1 GiB) instead of strange 986 MiB. Fixes: 626f048b ("board: Add Qualcomm Dragonboard 410C support") Signed-off-by:
Stephan Gerhold <stephan@gerhold.net> Reviewed-by:
Ramon Fried <rfried.dev@gmail.com>
-
At the moment the U-Boot port for the DragonBoard 410c is designed to be loaded as an Android boot image after Qualcomm's Little Kernel (LK) bootloader. This is simple to set up but LK is redundant in this case, since everything done by LK can be also done directly by U-Boot. Dropping LK entirely has at least the following advantages: - Easier installation/board code (no need for Android boot images) - (Slightly) faster boot - Boot directly in 64-bit without a round trip to 32-bit for LK So far this was not possible yet because of unsolved problems: 1. Signing tool: The firmware expects a "signed" ELF image with extra (Qualcomm-specific) ELF headers, usually used for secure boot. The DragonBoard 410c does not have secure boot by default but the extra ELF headers are still required. 2. PSCI bug: There seems to be a bug in the PSCI implementation (part of the TrustZone/tz firmware) that causes all other CPU cores to be started in 32-bit mode if LK is missing in the boot chain. This causes Linux to hang early during boot. There is a solution for both problems now: 1. qtestsign (https://github.com/msm8916-mainline/qtestsign) can be used as a "signing" tool for U-Boot and other firmware. 2. A workaround for the "PSCI bug" is to execute the TZ syscall when entering U-Boot. That way PSCI is made aware of the 64-bit switch and starts all other CPU cores in 64-bit mode as well. Simplify the dragonboard410c board by removing all the extra code that is only used to build an Android boot image that can be loaded by LK. This allows dropping the custom linker script, special image magic, as well as most of the special build/installation instructions. CONFIG_REMAKE_ELF is used to build a new ELF image that has both U-Boot and the appended DTB combined. The resulting u-boot.elf can then be passed to the "signing" tool (e.g. qtestsign). The PSCI workaround is placed in the "boot0" hook that is enabled with CONFIG_ENABLE_ARM_SOC_BOOT0_HOOK. The extra check for EL1 allows compatibility with custom firmware that enters U-Boot in EL2 or EL3, e.g. qhypstub (https://github.com/msm8916-mainline/qhypstub ). As a first step these changes apply only to DragonBoard410c. Similar changes could likely also work for the DragonBoard 820c. Note that removing LK wouldn't be possible that easily without a lot of work already done three years ago by Ramon Fried. A lot of missing initialization, pinctrl etc was already added back then even though it was not strictly needed yet. Cc: Ramon Fried <rfried.dev@gmail.com> Signed-off-by:
Stephan Gerhold <stephan@gerhold.net>
-
Since we can not set OsIndications from Runtime Services SetVariables at this moment, it is better to ignore the OsIndications if there is any capsule file in the correct place. Signed-off-by:
Masami Hiramatsu <masami.hiramatsu@linaro.org>
-
Since the recent commit; commit b891ff18 ("efi_loader: Force a single FMP instance per hardware store") forces a single FMP instances for a storage, we can not enable both RAW and FIT capsule image support at once. Since RAW capsule image support is simpler than FIT, enable RAW capsule image instead of FIT by default. Signed-off-by:
Masami Hiramatsu <masami.hiramatsu@linaro.org>
-
Enable UEFI secure boot on synquacer. Note that unless user setup their keys, the secure boot will not work. Signed-off-by:
Masami Hiramatsu <masami.hiramatsu@linaro.org>
-
Since the U-Boot for the SynQuacer DeveloperBox is designed for compatible with EDK2 boot, we don't need to support Ext2/4 fs support by default. Drop it. Signed-off-by:
Masami Hiramatsu <masami.hiramatsu@linaro.org>
-
Since MTD partitions are based on the devicetree name, remove unneeded mtdparts settings and update DFU setting. Signed-off-by:
Masami Hiramatsu <masami.hiramatsu@linaro.org>
-
Add partition information to the spi-nor flash. This is required for accessing NOR flash via mtdparts. Signed-off-by:
Masami Hiramatsu <masami.hiramatsu@linaro.org> Reviewed-by:
Marek Behún <marek.behun@nic.cz>
-
Make the U-Boot binary for SynQuacer position independent so that the previous bootloader (SCP firmware or BL2) can load the U-Boot anywhere. Signed-off-by:
Masami Hiramatsu <masami.hiramatsu@linaro.org>
-
Since the SCBM SMMU is not only connected to the NETSEC but also shared with the F_SDH30 (eMMC controller), that should be initialized at board level instead of NETSEC. Move the SMMU initialization code into board support and call it from board_init(). Without this fix, if the NETSEC is disabled, the Linux eMMC ADMA cause an error because SMMU is not initialized. Signed-off-by:
Masami Hiramatsu <masami.hiramatsu@linaro.org>
-
Tom Rini authored
- A new driver uclass is created to handle the reboot mode control. - Add support for libcrypt-style passwords for autoboot
-
This adds tests for the crypt-based and plain SHA256-based password hashing algorithms in the autoboot flow. Signed-off-by:
Steffen Jaeckel <jaeckel-floss@eyet-services.de> Reviewed-by:
Simon Glass <sjg@chromium.org>
-
In case crypt-based hashing is enabled this will be the default mechanism that is used. If a user wants to have support for both, the environment variable `bootstopusesha256` can be set to `true` to allow plain SHA256 based hashing of the password. Signed-off-by:
Steffen Jaeckel <jaeckel-floss@eyet-services.de> Reviewed-by:
Simon Glass <sjg@chromium.org>
-
The key-sequence based unlock mechanisms are sensitive to junk symbols that could have been sent to stdin and are still waiting to be retrieved. Enabling this option will read all symbols off stdin before displaying the autoboot prompt (and starting to read the password from stdin). Signed-off-by:
Steffen Jaeckel <jaeckel-floss@eyet-services.de> Reviewed-by:
Simon Glass <sjg@chromium.org>
-
In case a user has to enter a complicated password it is sometimes desireable to give the user more time than the default timeout. Enabling this feature will disable the timeout entirely in case the user presses the <Enter> key before entering any other character. Signed-off-by:
Steffen Jaeckel <jaeckel-floss@eyet-services.de> Reviewed-by:
Simon Glass <sjg@chromium.org>
-
While doing code-review internally this got nitpicked by 2 reviewers, so I decided to include this here. Signed-off-by:
Steffen Jaeckel <jaeckel-floss@eyet-services.de> Reviewed-by:
Simon Glass <sjg@chromium.org> Reviewed-by:
Heiko Schocher <hs@denx.de>
-
Hook into the autoboot flow as an alternative to the existing mechanisms. Signed-off-by:
Steffen Jaeckel <jaeckel-floss@eyet-services.de> Reviewed-by:
Simon Glass <sjg@chromium.org> Reviewed-by:
Heiko Schocher <hs@denx.de>
-
In order to prevent using the global errno, replace it with a static version and create a wrapper function which returns the error value. Signed-off-by:
Steffen Jaeckel <jaeckel-floss@eyet-services.de> Reviewed-by:
Simon Glass <sjg@chromium.org> Reviewed-by:
Heiko Schocher <hs@denx.de>
-
Add the basic functionality required to support the standard crypt format. The files crypt-sha256.c and crypt-sha512.c originate from libxcrypt and their formatting is therefor retained. The integration is done via a crypt_compare() function in crypt.c. ``` libxcrypt $ git describe --long --always --all tags/v4.4.17-0-g6b110bc ``` Signed-off-by:
Steffen Jaeckel <jaeckel-floss@eyet-services.de> Reviewed-by:
Simon Glass <sjg@chromium.org> Reviewed-by:
Heiko Schocher <hs@denx.de>
-
RTC devices could provide battery-backed memory that can be used for storing the reboot mode magic value. Add a new reboot-mode back-end that uses RTC to store the reboot-mode magic value. The driver also supports both endianness modes. Signed-off-by:
Nandor Han <nandor.han@vaisala.com> Reviewed-by:
Simon Glass <sjg@chromium.org>
-
A use case for controlling the boot mode is when the user wants to control the device boot by pushing a button without needing to go in user-space. Add a new backed for reboot mode where GPIOs are used to control the reboot-mode. The driver is able to scan a predefined list of GPIOs and return the magic value. Having the modes associated with the magic value generated based on the GPIO values, allows the reboot mode uclass to select the proper mode. Signed-off-by:
Nandor Han <nandor.han@vaisala.com> Reviewed-by:
Simon Glass <sjg@chromium.org>
-
A new driver uclass is created to handle the reboot mode control. The new uclass driver is updating an environment variable with the configured reboot mode. The mode is extracted from a map provided at initialization time. The map contains a list of modes and associated ids. Signed-off-by:
Nandor Han <nandor.han@vaisala.com> Reviewed-by:
Simon Glass <sjg@chromium.org>
-
Tom Rini authored
- Assorted FIT, optee, pcf8575, mux, vexpress64 and distro bootcmd fixes. - Allow pinmux status to take pin names
-
CONFIG_NET_MULTI has been removed long time ago by commit 795428fc ("net: remove CONFIG_NET_MULTI") but 4 boards were added later which wasn't found. The patch is removing this reference from 4 boards. Signed-off-by:
Michal Simek <michal.simek@xilinx.com> Reviewed-by:
Chris Packham <chris.packham@alliedtelesis.co.nz>
-
The macro should be passed a state, which should be passed to the actual function. Otherwise using that macro would yield a build error. Signed-off-by:
Patrick Wildt <patrick@blueri.se> Reviewed-by:
Pratyush Yadav <p.yadav@ti.com>
-
The ARM Juno boards can be used as somewhat decent machines to run off-the-shelf distributions, with USB, SATA, GBit Ethernet and 8GB of DRAM. With stable DTs in the board's NOR flash this would work really nicely, however the default boot command is to fetch a kernel and an initrd from the on-board NOR flash, which sounds somewhat embedded. Include the config_distro_bootcmd.h header and define the available devices (starting with USB, to catch USB installer sticks) to make distributions and UEFI work out of the box. The NOR flash kernel functionality is still preserved as the last resort, should all other methods fail. Signed-off-by:
Andre Przywara <andre.przywara@arm.com> Reviewed-by:
Simon Glass <sjg@chromium.org> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org>
-
The generic distro boot sequence iterates over several types of devices, trying one after another. In doing do, it starts with setting the "devtype" variable, then uses this later in more generic commands. Now most (block) device types use a local variable for that, but DHCP puts the type into the environment, where it shadows any local variables. As a consequence any boot attempt after bootcmd_dhcp has been run fails: =========================== VExpress64# run bootcmd_dhcp ... VExpress64# run bootcmd_sata0 SATA#0: (3.0 Gbps) SATA#1: (No RDY) Device 0: Model: 16GB SATA Flash Drive .... ... is now current device Couldn't find partition dhcp 0:1 =========================== This problem typically doesn't show, because DHCP is mostly the last command to try, but is a problem when this order is different, or when distro_bootcmd or bootcmd_xxx are run separately or multiple times. Let bootcmd_dhcp use a local variable, as the other kids do, to make the order of boot commands irrelevant, and allow repeated calls. Signed-off-by:
Andre Przywara <andre.przywara@arm.com> Reviewed-by:
Simon Glass <sjg@chromium.org>
-
Tom Rini authored
When we build U-Boot with POSITION_INDEPENDENT we must have SYS_TEXT_BASE be set to zero. Make this the default in that case. Signed-off-by:
Tom Rini <trini@konsulko.com> Reviewed-by:
Mark Kettenis <kettenis@openbsd.org>
-
Switch to fit_image_get_data_and_size() for consistency with all other data loaded from FIT. Signed-off-by:
John Keeping <john@metanate.com> Reviewed-by:
Simon Glass <sjg@chromium.org>
-
As 'part_get_info_by_name' now returns more status codes than just -1 to indicate failure, we need to update the return value check. Signed-off-by:
Anders Dellien <anders.dellien@arm.com> Reviewed-by:
Sean Anderson <sean.anderson@seco.com>
-
This patch add support for using NXP's pca8574 I2C IO expander, which has only 8 IO lines. After this change the .data member's information from struct udevice_id are used to either sent one or two bytes. Moreover, the '_le16' suffix from pcf8575_i2c_{write|read}_le16() functions have been removed as now we also sent 8 bit data. Signed-off-by:
Lukasz Majewski <lukma@denx.de> Reviewed-by:
Heiko Schocher <hs@denx.de>
-
Those members are not used anymore as ones from gpio_dev_priv structure (when DM_GPIO support is enabled) are used instead. Signed-off-by:
Lukasz Majewski <lukma@denx.de> Reviewed-by:
Heiko Schocher <hs@denx.de>
-
Allow pin name parameter for pimux staus command, as gpio command to get status of one pin. The possible usage of the command is: > pinmux dev pinctrl > pinmux status > pinmux status -a > pinmux status <pin-name> Signed-off-by:
Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by:
Simon Glass <sjg@chromium.org>
-
Update the result of do_status and always returns a CMD_RET_ value (-ENOSYS was a possible result of show_pinmux). This patch also adds pincontrol name in error messages (dev->name) and treats correctly the status sub command when pin-controller device is not selected. Signed-off-by:
Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by:
Simon Glass <sjg@chromium.org>
-
This change ensures both U-Boot and OP-TEE see the same content from shared memory when OP-TEE is invoked prior U-Boot relocation. This change is required since U-Boot may execute with data cache off while OP-TEE always enables cache on memory shared with U-Boot. Signed-off-by:
Etienne Carriere <etienne.carriere@linaro.org> Reviewed-by:
Jens Wiklander <jens.wiklander@linaro.org> Acked-by:
Ilias Apalodimas <ilias.apalodimas@linaro.org>
-
It's possible that LOAD_FIT_FULL will have different values for TPL and SPL, in which case just checking CONFIG_SPL_LOAD_FIT_FULL causes this to be compiled in to the TPL even though functions and struct members it depends on are not. Use CONFIG_IS_ENABLED() to ensure the correct TPL/SPL variant is checked. Signed-off-by:
John Keeping <john@metanate.com> Reviewed-by:
Bin Meng <bmeng.cn@gmail.com> Reviewed-by:
Simon Glass <sjg@chromium.org>
-