Samuel Holland [Mon, 19 Apr 2021 03:21:41 +0000 (22:21 -0500)]
sunxi: A23/A33/H3: Move sun8i secure monitor to SRAM A2
So far for the H3, A23, and A33 SoCs, we use DRAM to hold the secure
monitor code (providing PSCI runtime services). And while those SoCs do
not have the secure SRAM B like older SoCs, there is enough (secure)
SRAM A2 to put the monitor code and data in there instead.
Follow the design of 64-bit SoCs and use the first part for the monitor,
and the last 16 KiB for the SCP firmware. With this change, the monitor
no longer needs to reserve a region in DRAM.
Signed-off-by: Samuel Holland <samuel@sholland.org> Reviewed-by: Andre Przywara <andre.przywara@arm.com>
[Andre: amend commit message, fix R40 and V3s build] Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Samuel Holland [Mon, 19 Apr 2021 03:16:21 +0000 (22:16 -0500)]
sunxi: Select environment MMC based on boot device
Currently, the environment is always stored in eMMC if eMMC is enabled
in the config. This means images written to SD and eMMC will cross-
contaminate their environments unless the configuration is changed.
By dropping the device number from the environment location string and
implementing mmc_get_env_dev, we will always use the environment from
the boot device when booting from SD/eMMC.
Signed-off-by: Samuel Holland <samuel@sholland.org> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Roland Gaudig [Fri, 23 Jul 2021 12:29:21 +0000 (12:29 +0000)]
cmd: setexpr: add format string handling
Add format string handling operator to the setexpr command.
It allows to use C or Bash like format string expressions to be
evaluated with the result being stored inside the environment variable
name.
setexpr <name> fmt <format> [value]...
The following example
setexpr foo fmt "%d, 0x%x" 0x100 ff
will result in $foo being set to "256, 0xff".
Signed-off-by: Roland Gaudig <roland.gaudig@weidmueller.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Roland Gaudig [Fri, 23 Jul 2021 12:29:20 +0000 (12:29 +0000)]
cmd: printf: add helper functions from busybox
Import the following helper functions from Busybox-1.33.1 which are
required by printf.c:
process_escape_sequence from libbb/process_escape_sequence.c,
skip_whitespace from libbb/skip_whitespace.c,
overlapping_strcpy from libbb/safe_strncpy.c
src-url: https://git.busybox.net/busybox/
commit bcc5b0e6caca6c7602a6a41f "Bump version to 1.33.1"
version: 1.33.1
Signed-off-by: Roland Gaudig <roland.gaudig@weidmueller.com>
Tom Rini [Tue, 27 Jul 2021 15:42:31 +0000 (11:42 -0400)]
Merge tag 'u-boot-amlogic-20210727' of https://source.denx.de/u-boot/custodians/u-boot-amlogic
- Add SMBIOS info for Khadas VIM boards
- Fix meson-axg-mipi PHY build
- Fix VIM3 board phy-names property setup
- Return correct value for non emmc boot sources on VIM3
- add kernel compression vars
Tom Rini [Tue, 27 Jul 2021 13:11:25 +0000 (09:11 -0400)]
Merge tag 'u-boot-stm32-20210727' of https://source.denx.de/u-boot/custodians/u-boot-stm
- FIP Enable OP-TEE and TZC support in SPL for STM32MP15 SoC
- Add stm32mp15 missing SPI clock support
- Manage pull-up on gpio button STM32MP15 boards
- Correct STM32MP15 boot when TAMPER registers are invalid
- Fix EMMC pinmux on STM32MP15 Avenger96 board
phy: meson-axg-mipi: Access parent ofnode through dev_ofnode()
With commit 84a42ae36683 ("dm: core: Rename device node to indicate it
is private") and commit f10643cf8a4c ("dm: core: Access device ofnode
through functions") accesses to the "node" member were replaced with
dev_ofnode(). Also apply that replacement here.
Fixes: 4547551aa019 ("phy: Add Amlogic AXG MIPI PCIe Analog PHY driver") Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
phy: meson-axg-mipi: Rename "priv_auto_alloc_size" to "priv_auto"
With commit 41575d8e4c33 ("dm: treewide: Rename auto_alloc_size members
to be shorter") "priv_auto_alloc_size" was renamed to "priv_auto". Apply
the rename to these two drivers as well.
Artem Lapkin [Thu, 27 May 2021 07:35:28 +0000 (15:35 +0800)]
VIM3: mmc_get_env_dev correct non emmc boot sources
need return -1 if boot source is not EMMC or SD ( for example it will be
useful if we have multy env sources configuration and device was booted
from SPI flash and env need read from SPI not from mmc )
stm32mp1: spl: Configure TrustZone controller for OP-TEE
OP-TEE is very particular about how the TZC should be configured.
When booting an OP-TEE payload, an incorrect TZC configuration will
result in a panic.
Most information can be derived from the SPL devicetree. The only
information we don't have is the split between TZDRAM and shared
memory. This has to be hardcoded. The rest of the configuration is
fairly easy, and only requires 3 TZC regions. Configure them.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
arm: stm32mp: Implement support for TZC 400 controller
The purpose of this change is to allow configuring TrustZone (TZC)
memory permissions. For example, OP-TEE expects TZC regions to be
configured in a very particular way. The API presented here is
intended to allow exactly that.
UCLASS support is not implemented, because it would not be too useful.
Changing TZC permissions needs to be done with care, so as not to cut
off access to memory we are currently using. One place where we can
use this is at the end of SPL, right before jumping to OP-TEE.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
OP-TEE requires some particular setup, which is not needed for linux
or other payloads. Add a hook for platform-specific code to perform
any OP-TEE related configuration and initialization.
A weak function is used because it is symmetrical to other
spl_board_prepare_for_*() implementations. A solution to avoid the use
of weak functions would trivially apply to all these implementations.
However, re-designing this is beyond the scope of this patch.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
In general, Falcon mode means we're booting a linux kernel directly.
With FIT images, however, an OP-TEE secure kernel can be booted before
linux. Thus, if the next stage is an IH_OS_TEE, this isn't necessarily
a problem.
Of course, a general solution would involve mmc_load_image_raw_os()
only loading the binary, and leaving the decision of suitability to
someone else. However, a rework of the boot flow is beyond the scope
of this patch. Accept IH_OS_TEE as a valid OS value.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Marek Vasut [Tue, 20 Jul 2021 21:46:07 +0000 (23:46 +0200)]
ARM: dts: stm32: Fix AV96 eMMC pinmux
Commit 500327e2ea7 ("ARM: dts: stm32mp1: DT alignment with Linux kernel v5.8-rc1")
renamed sdmmc2_d47_pins_b phandle to sdmmc2_d47_pins_c, but without updating
the AV96 DT which uses that phandle. Linux missed similar update as well and
it was only added in commit 1ad6e36ec266 ("ARM: dts: stm32: Fix sdmmc2 pins
on AV96") .
Update the AV96 DT pinmux phandle, otherwise eMMC 8bit mode does not work
and access to eMMC takes a very long time to fall back to 4bit mode.
Signed-off-by: Marek Vasut <marex@denx.de> Cc: Patrick Delaunay <patrick.delaunay@foss.st.com> Cc: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Add the missing SPI clock even if these instances are not available
on STMicroelectronics boards: SPI2_K, SPI3_K, SPI4_K, SPI6_K.
With this patch, the SPI2 / SPI3 / SPI4 / SPI6 instances can be used on
customer design without the clock driver error:
stm32mp1_clk_get_id: clk id 131 not found
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
stm32mp1: add pull-up for gpio button PA13 and PA14
When a push-button is released and PA13/PA14 are defined as input (high-Z)
the LED should not be active as the circuit is open but a small current
leak through PCB or push-button close the circuit and allows a small LED
bias giving erroneous level voltage.
So it is recommended to activate an internal pull-up in order to clearly
fix the voltage at PA13/PA14 when button is released and to wait
a short delay before to read the GPIO value only when the pull-up is
correctly configured.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
arm: stm32mp1: force boot_device variable for invalid TAMP register value
When the TAMP register 20 have an invalid value (0x0 for example after
TAMPER error) the "boot_device" U-Boot env variable have no value and
no error is displayed in U-Boot log.
The STM32MP boot command bootcmd_stm32mp failed with strange trace:
"Boot over !"
and the next command in bootcmd_stm32mp failed with few indication:
if test ${boot_device} = serial || test ${boot_device} = usb;
then stm32prog ${boot_device} ${boot_instance};
As it is difficult to investigate, the current patch avoids this issue:
- change the debug message to error: "unexpected boot mode" is displayed
- display trace "Boot over invalid!" in bootcmd_stm32mp
- execute "run distro_bootcmd" to try all the possible target
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
arm64: zynqmp: Move USB3 PHY properties from DWC3 node to USB node
Move the PHY properties from DWC3 node to USB node in ZynqMP DTs as here
the USB3 PHY used is PSGTR, which is connected to Xilinx USB core. This
PHY initialization should be handled from Xilinx USB core as the
prerequisite register configurations are done here only.
Signed-off-by: Manish Narani <manish.narani@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Add kernel_comp_addr_r, kernel_comp_size env variables for zynqmp and
versal to be able to use the compressed kernel Image(.gz,.bz2,.lzma,.lzo)
using booti command.
Signed-off-by: Raju Kumar Pothuraju <raju.kumar-pothuraju@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Michal Simek [Wed, 14 Jul 2021 07:07:04 +0000 (09:07 +0200)]
arm64: versal: Drop default definitions of CONFIG_SYS_PBSIZE
It is default value which had been converted by commit 432e39806805
("include/configs: drop default definitions of CONFIG_SYS_PBSIZE"). That's
why also remove it.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Michal Simek [Tue, 13 Jul 2021 14:49:04 +0000 (16:49 +0200)]
arm64: zynqmp: Enable reset and poweroff via sysreset framework
reset and poweroff are called via hooks in psci driver which is going
around sysreset framework that's why enable sysreset drivers and do reset
and poweroff via this framework. Using this flow will allow us to call
SYSTEM_WARM_RESET based on psci 1.1 spec which can be calles with reset -w
command.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Michal Simek [Tue, 13 Jul 2021 14:39:26 +0000 (16:39 +0200)]
arm64: zynqmp: Do not define do_reset() if sysreset is enabled
The SPL can also be compiled with sysreset drivers just fine, so
update the condition to cater for that option.
The same change was done by commit efa1a62ad2dd ("ARM: imx8m: Do not define
do_reset() if sysreset is enabled").
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Michal Simek [Tue, 13 Jul 2021 14:53:46 +0000 (16:53 +0200)]
psci: Do not define do_poweroff() if CONFIG_SYSRESET_CMD_POWEROFF is enabled
CONFIG_SYSRESET_CMD_POWEROFF defines do_poweroff() in sysreset-uclass.c
that's why don't define it twice when both CONFIG_SYSRESET_CMD_POWEROFF and
CONFIG_CMD_POWEROFF are enabled. CONFIG_SYSRESET_CMD_POWEROFF depends on
CONFIG_CMD_POWEROFF.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Add support for xilinx multirate(MRMAC) ethernet driver.
This driver uses multichannel DMA(MCDMA) for data transfers of MRMAC.
Added support for 4 ports of MRMAC for speeds 10G and 25G.
MCDMA supports upto 16 channels but in this driver we have setup only
one channel which is enough.
Tested 10G and 25G on all 4 ports.
Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
net: ethtool: Add ethernet speed macros for higher speeds
Add speed macro's for higher ethernet speeds to be used in u-boot
networking drivers. Added Macros for speeds 14G, 20G, 25G, 40G, 50G,
56G, 100G and 200G inline with linux.
Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma@xilinx.com> Reviewed-by: Simon Glass <sjg@chromium.org> Acked-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Michal Simek [Thu, 1 Jul 2021 17:01:42 +0000 (19:01 +0200)]
clk: zynqmp: Add support for enabling clock on lpd_lsbus
lpd_lsbus is clock which is used by many IPs like dmas, gems, gpio, sdhcis,
spis, ttcs, uarts, watchdog that's why make sense to also enable access to
change this clock. For this clock you already get the rate.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Mike Looijmans [Fri, 2 Jul 2021 08:28:36 +0000 (10:28 +0200)]
xilinx: Return ENVL_NOWHERE instead of ENVL_UNKNOWN
The system refuses to boot without any environment, so return ENVL_NOWHERE when
there's nowhere to store the environment instead of ENVL_UNKNOWN.
This fixes that the board won't boot from eMMC when CONFIG_ENV_IS_IN_FAT is not
defined, for example. Similar for other combinations.
Fixes: 1025bd098aa8 "xilinx: zynqmp: Add support for saving variables" Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Michal Simek [Fri, 9 Jul 2021 11:53:44 +0000 (05:53 -0600)]
mmc: zynq_sdhci: Make variables/structure static
All these variables/structure are local and should be static.
Issues are reported by sparse:
drivers/mmc/zynq_sdhci.c:49:11: warning: symbol 'zynqmp_iclk_phases' was not declared. Should it be static?
drivers/mmc/zynq_sdhci.c:50:11: warning: symbol 'zynqmp_oclk_phases' was not declared. Should it be static?
drivers/mmc/zynq_sdhci.c:53:11: warning: symbol 'versal_iclk_phases' was not declared. Should it be static?
drivers/mmc/zynq_sdhci.c:54:11: warning: symbol 'versal_oclk_phases' was not declared. Should it be static?
drivers/mmc/zynq_sdhci.c:546:24: warning: symbol 'arasan_ops' was not declared. Should it be static?
Michal Simek [Fri, 9 Jul 2021 11:53:43 +0000 (05:53 -0600)]
mmc: zynq_sdhci: Fix kernel doc warnings
Fix these kernel doc warnings:
drivers/mmc/zynq_sdhci.c:181: warning: contents before sections
drivers/mmc/zynq_sdhci.c:236: warning: contents before sections
drivers/mmc/zynq_sdhci.c:291: warning: contents before sections
drivers/mmc/zynq_sdhci.c:297: warning: Function parameter or member 'degrees' not described in 'sdhci_versal_sdcardclk_set_phase'
drivers/mmc/zynq_sdhci.c:354: warning: contents before sections
drivers/mmc/zynq_sdhci.c:360: warning: Function parameter or member 'degrees' not described in 'sdhci_versal_sampleclk_set_phase'
drivers/mmc/zynq_sdhci.c:467: warning: contents before sections
mmc: zynq_sdhci: Split set_tapdelay function to in and out
Split arasan_zynqmp_set_tapdelay() to handle input and output tapdelays
separately. This is required to handle zero values for ITAP and OTAP
values. If we dont split, we will have to remove the if() in the
function, which makes ITAP values to be overwritten when OTAP values are
called to set and vice-versa.
Restrict tap_delay value calculated to max allowed 8 bits for ITAP and 6
bits for OTAP for ZynqMP.
mmc: zynq_sdhci: Allow configuring zero Tap values
Allow configuring ITAP and OTAP values with zero to avoid failures in
some cases (one of them is SD boot mode). Legacy, SDR12 modes require
to program the ITAP and OTAP values as zero, whereas for SDR50 and SDR104
modes ITAP value is zero.
In SD boot mode firmware configures the SD ITAP and OTAP values and
in this case u-boot has to re-configure required tap values(including zero)
based on the operating mode.
xilinx: zynqmp: increase CONFIG_SYS_SPL_MALLOC_SIZE to 16MB
commit 03f1f78a9b44 ("spl: fit: Prefer a malloc()'d buffer for loading
images")' changed the way buffer allocation worked for SPL to a more
flexible method.
For xilinx zynqmp the 1MB buffer is not necessarily enough when dealing
with complex fit images (e.g. containing FPGA/TF-A/OP-TEE/U-Boot
proper), which can easily reach up to 10MB, so increase the default
CONFIG_SYS_SPL_MALLOC_SIZE size to 16MB to cover more advanced
scenarios.
Signed-off-by: Ricardo Salveti <ricardo@foundries.io> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Commit b81406db51a6 ("arm: serial: Add debug UART capability to the
pl01x driver") add supports to use pl01x as a debug UART. However,
due to CONFIG_IS_ENABLED macro requires CONFIG_SPL_* prefix, the
_debug_uart_init() would not choose TYPE_PL011 in SPL build. This
patch fixes the bug by judging CONFIG_DEBUG_UART_PL011 explicitly.
Signed-off-by: Chen Baozi <chenbaozi@phytium.com.cn> Reviewed-by: Simon Glass <sjg@chromium.org>
In the commit c982874e930d ("efi_loader: refactor
efi_setup_loaded_image()"), setjmp-related definitions were moved to
efi_loaded_image_obj in efi_loader.h. So setjmp.h is no longer
refererenced in efi_api.h.
This also fixes some error when efi_api.h will be included in
mkeficapsule.c.
If capsule authentication is disabled and yet a capsule file is signed,
its signature must be removed from image data to flush.
Otherwise, the firmware will be corrupted after update.
Fixes: 04be98bd6bcf ("efi: capsule: Add support for uefi capsule
authentication") Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
BIOS Release Date must be in format mm/dd/yyyy and must be release date.
U-Boot currently sets BIOS Release Date from U_BOOT_DMI_DATE macro which is
generated from current build timestamp.
Fix this issue by setting U_BOOT_DMI_DATE macro to U-Boot version which is
better approximation of U-Boot release date than current build timestamp.
Current U-Boot versioning is in format yyyy.mm so as a day choose 01.
Some operating systems are using BIOS Release Date for detecting when was
SMBIOS table filled or if it could support some feature (e.g. BIOS from
1990 cannot support features invented in 2000). So this change also ensures
that recompiling U-Boot from same sources but in different year does not
change behavior of some operating systems.
Macro U_BOOT_DMI_DATE is not used in other file than lib/smbios.c
so remove it from global autogenerated files and also from Makefile.
Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Simon Glass <sjg@chromium.org>
* remove duplicate heading to avoid build error with 'make htmldocs'
* length of underlines must match header
* use appropriate header levels
* fix type %s/linux/Linux/
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
serial: pl011: Resend the character if FIFO is full in debug uart
pl01x_putc() might return -EAGAIN if there was no space in FIFO. In that
case, high-level caller should wait until there is space and resend the
character.
Signed-off-by: Chen Baozi <chenbaozi@phytium.com.cn> Reviewed-by: Stefan Roese <sr@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
Peter Hoyes [Mon, 12 Jul 2021 14:04:21 +0000 (15:04 +0100)]
armv8: Initialize CNTFRQ if at highest exception level
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.
Stephan Gerhold [Wed, 14 Jul 2021 08:56:26 +0000 (10:56 +0200)]
serial: serial_msm: Delay initialization to let pins stabilize
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>
Stephan Gerhold [Wed, 14 Jul 2021 08:56:25 +0000 (10:56 +0200)]
board: dragonboard410c: Fix fastboot
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: aa043ee91a47 ("db410c: automatically launch fastboot") Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Stephan Gerhold [Wed, 14 Jul 2021 08:56:24 +0000 (10:56 +0200)]
board: dragonboard410c: Fix PHYS_SDRAM_1_SIZE
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: 626f048bbc14 ("board: Add Qualcomm Dragonboard 410C support") Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Stephan Gerhold [Wed, 7 Jul 2021 09:06:02 +0000 (11:06 +0200)]
board: dragonboard410c: Load U-Boot directly without LK
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>
configs: synquacer: Ignore OsIndications on DeveloperBox
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.
configs: synquacer: Use RAW capsule image instead of FIT
Since the recent commit;
commit b891ff18f899 ("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.
configs: synquacer: Drop Ext2/4 support by default
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.
board: synquacer: Initialize SCBM SMMU at board_init()
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.
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>
common: allow disabling of timeout for password entry
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>
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.
Nandor Han [Thu, 10 Jun 2021 13:56:44 +0000 (16:56 +0300)]
reboot-mode: read the boot mode from GPIOs status
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>
Nandor Han [Thu, 10 Jun 2021 13:56:43 +0000 (16:56 +0300)]
reboot-mode: add support for reboot mode control
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>
Michal Simek [Wed, 14 Jul 2021 07:12:41 +0000 (09:12 +0200)]
net: remove CONFIG_NET_MULTI (again)
CONFIG_NET_MULTI has been removed long time ago by commit 795428fc679f
("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 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>
Andre Przywara [Sun, 11 Jul 2021 23:07:09 +0000 (00:07 +0100)]
distro_boot: Fix block device after DHCP boot sequence
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>
projects / u-boot.git / log