As part of copying the logic from Travis to GitLab I kept the TOOLCHAIN
variable. However we don't use that now as the Docker container already
has all toolchains so we don't need to do any downloading. Remove this
variable.
Simon Glass [Sun, 21 Jul 2019 02:51:21 +0000 (20:51 -0600)]
autoboot: Rename CONFIG_MENUKEY to CONFIG_AUTOBOOT_MENUKEY
Since this is part of the autoboot functionality, it makes sense to name
it with an AUTOBOOT prefix. No mainline boards use it so this should be
safe, and downstream boards will need to adjust.
Since this option is just an integer value, it really needs another option
to control whether the feature is enabled or not. Add a new
CONFIG_USE_AUTOBOOT_MENUKEY for that. This fits better with how things are
done with Kconfig, avoiding the need to use a specific value to disable
the feature.
Simon Glass [Sun, 21 Jul 2019 02:51:20 +0000 (20:51 -0600)]
autoboot: Drop unused CONFIG_MENUPROMPT
This is not defined by any board. We could use CONFIG_AUTOBOOT_PROMPT
instead perhaps, but this depends on CONFIG_AUTOBOOT_KEYED which is not
used for the single-key case.
Simon Glass [Sun, 21 Jul 2019 02:51:19 +0000 (20:51 -0600)]
autoboot: Drop #ifdef CONFIG_AUTOBOOT_KEYED
At present we have two functions named __autoboot() which do different
things. This is confusing. Fix it by using if() instead of #ifdef for
selecting the functions, and renaming them to meaningful names.
Simon Glass [Sun, 21 Jul 2019 02:51:15 +0000 (20:51 -0600)]
autoboot: Use CONFIG_AUTOBOOT_STOP_STR_SHA256 indirectly
This CONFIG option is only present if CONFIG_AUTOBOOT_ENCRYPTION is
enabled so it cannot be used in code without that #ifdef. But we want to
reduce the use of #ifdef in this file and in particular to avoid having
two different functions both named passwd_abort() but which do different
things.
In preparation for this, create an intermediate value which is set to an
empty string if there is no value for CONFIG_AUTOBOOT_STOP_STR_SHA256.
Simon Glass [Sun, 21 Jul 2019 02:51:11 +0000 (20:51 -0600)]
main: Use conditional run_preboot_environment_command()
The function name indicates that it does something, but its entire
operation is actually condition on a CONFIG. Move the condition outside
the function so this is clearer, and use if() instead of #ifdef, like the
reset of the file.
Tom Rini [Wed, 31 Jul 2019 20:06:24 +0000 (16:06 -0400)]
Merge tag 'u-boot-amlogic-20190731' of https://gitlab.denx.de/u-boot/custodians/u-boot-amlogic
- sync Amlogic G12A DT with linux 5.3-rc1
- add support for 4GiB DRAM memory
- add support for Amlogic G12B based Odroid-N2
- small duplicate logic fix for gxbb clock driver
The above patch was designed to shrink code by only pin-muxing items
needed for SPL in SPL and relying on driver model or SPL to mux other
items. Unfortunately, da850evm_direct_nor doesn't use SPL so items
that were only muxed during SPL are not muxed causing the board
to no longer boot.
Adam Ford [Tue, 30 Jul 2019 13:58:58 +0000 (08:58 -0500)]
ARM: da850-evm: Remove references to CONFIG_DA850_AM18X_EVM
With the removal of da850_am18xxevm, there is at least one
whitelisted CONFIG option that can be deleted. This patch
removes CONFIG_DA850_AM18X_EVM since it's not required any more
Adam Ford [Tue, 30 Jul 2019 13:32:37 +0000 (08:32 -0500)]
ARM: dts: da850-evm: Fix MDIO pinmux
In attempts to speed up SPL and reduce size, the MDIO pin muxing
was inadvertently affected. Since the ethernet driver will setup
the pin muxing when ethernet is loaded, this patch will also
pinmux the MDIO pins at the same time. Once an DM compatible
MDIO driver is available, this can be removed.
Fixes: 877ab2423bc2 ("ARM: davinci: da850: Manual pinmux only
when PINCTRL not available")
configs: am335x_boneblack_vboot_defconfig: Add DM for SPI and Flash devices
This patch adds SPI and SPI_FLASH DM support for verified boot on
TI AM335 chipsets. The following compile warning is removed:
===================== WARNING ======================
This board does not use CONFIG_DM_SPI_FLASH. Please update
the board to use CONFIG_SPI_FLASH before the v2019.07 release.
Failure to update by the deadline may result in board removal.
See doc/driver-model/MIGRATION.txt for more info.
====================================================
Built and tested on AM335x device (BeagleboneBlack).
configs: am335x_boneblack_vboot_defconfig: Fix regression by enabling BLK and DM support, disable in SPL
This patch adds BLK and DM support for verified boot on TI AM335x
chipsets. The following compile warnings are removed:
===================== WARNING ======================
This board does not use CONFIG_DM_MMC. Please update
the board to use CONFIG_DM_MMC before the v2019.04 release.
Failure to update by the deadline may result in board removal.
See doc/driver-model/MIGRATION.txt for more info.
====================================================
===================== WARNING ======================
This board does not use CONFIG_DM_USB. Please update
the board to use CONFIG_DM_USB before the v2019.07 release.
Failure to update by the deadline may result in board removal.
See doc/driver-model/MIGRATION.txt for more info.
====================================================
BLK and DM_MMC are enabled by default in SPL as well, which is
making the build to break with an overflow(spl image doesn't
fit into SRAM because of size constraints).
LD spl/drivers/built-in.o
LD spl/u-boot-spl
arm-linux-ld.bfd: u-boot-spl section .u_boot_list will not fit in region .sram
arm-linux-ld.bfd: region .sram overflowed by 116 bytes
make[1]: *** [spl/u-boot-spl] Error 1
make: *** [spl/u-boot-spl] Error 2
For the above reason BLK and DM_MMC is disabled in SPL.
Built and tested on AM335x device (BeagleboneBlack).
The K3 System Controller driver is used for loading and starting
the System Firmware, and is used only on R5 SPL. It need not be
enabled and built for the A72 U-Boot and SPL, so disable it from
the j721e_evm_a72 defconfig.
While at this, also remove the unneeded CONFIG_SPL_REMOTEPROC and
CONFIG_CMD_REMOTEPROC as no remoteprocs are now loaded from A72 SPL.
The K3 System Controller driver is used for loading and starting
the System Firmware, and is used only on R5 SPL. It need not be
enabled and built for the A53 U-Boot and SPL, so disable it from
both the GP and HS AM65x A53 defconfigs.
While at this, also remove the unneeded CONFIG_SPL_REMOTEPROC and
CONFIG_CMD_REMOTEPROC as no remoteprocs are now loaded from A53 SPL.
Signed-off-by: Suman Anna <s-anna@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
The commit 355be915ed08 ("arm: dts: k3-am654: Update power-domains
property for each node") has updated the power-domain cells value
and updated power-domains property in various existing dts nodes but
missed updating the cpsw_nuss node. This results in the following
build warning, fix this.
arch/arm/dts/k3-am654-base-board.dtb: Warning (power_domains_property): /interconnect@100000/interconnect@28380000/cpsw_nuss@046000000:power-domains: property size (8) too small for cell size 2
arch/arm/dts/k3-am654-r5-base-board.dtb: Warning (power_domains_property): /interconnect@100000/interconnect@28380000/cpsw_nuss@046000000:power-domains: property size (8) too small for cell size 2
Fixes: 355be915ed08 ("arm: dts: k3-am654: Update power-domains property for each node") Signed-off-by: Suman Anna <s-anna@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Adam Ford [Fri, 26 Jul 2019 22:53:45 +0000 (17:53 -0500)]
ARM: da850evm: Split MTDPARTS into SPL and u-boot
The MTDPARTS currently lists just u-boot.ais as 512k in size.
This works when loading the ais file via serial port, but if one
wanted to update just the u-boot portion, it's not really possible.
This patch splits the MTDPARTS into a 32k SPL partiion and a 480k
u-boot partition which allows u-boot.img to be burned to the u-boot
partition. The remaining partitions are left with the same sizes
and offsets to not break backwards compatibility.
It is essential to have an access to BCB area of 'misc' partition on
Android devices [1]. For BeagleBoard X15 the 'bcb' command will be
further used for reboot reason implementation and booting to recovery.
It can be also used for debugging reasons, like checking RescueParty
messages in BCB area.
[1] doc/android/bcb.txt
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Sam Protsenko [Thu, 25 Jul 2019 17:11:53 +0000 (20:11 +0300)]
omap: Correct the fastboot product var
"fastboot flashall" expects "fastboot getvar product" value to be one of
values provided in android-info.txt file (in AOSP), from "require
board=" list. Before this patch, "am57xx" is returned for all AM57xx
based boards, as it's set in $board env var from SYS_BOARD in
board/ti/am57xx/Kconfig file, which is used for default implementation
of "fastboot getvar product".
In order to fix that inconsistency, let's do next:
1. In U-Boot: override fastboot.product, reusing the value from
$board_name
2. In AOSP: provide values for all AM57xx boards we can use to
device/ti/beagle_x15/board-info.txt file
This way requirements check in "fastboot flashall" will work as
expected, verifying that user tries to flash images to the board which
those images were built for.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Acked-by: Andrew F. Davis <afd@ti.com>
Sam Protsenko [Thu, 25 Jul 2019 13:20:41 +0000 (16:20 +0300)]
env: ti: boot: Handle reboot reason from BCB
In case of Android boot, reboot reason can be written into BCB (usually
it's an area in 'misc' partition). U-Boot then can obtain that reboot
reason from BCB and handle it accordingly to achieve correct Android
boot flow, like it was suggested in [1]:
- if it's empty: perform normal Android boot from eMMC
- if it contains "bootonce-bootloader": get into fastboot mode
- if it contains "boot-recovery": perform recovery boot
The latter is not implemented yet, as it depends on some features that
are not implemented on TI platforms yet (in AOSP and in U-Boot).
First thing we check in meson_clk_set_rate_by_id() is current_rate == rate.
There is not need to check it again.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Acked-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
The comment about init op being NULL used to be next to the NULL check
code. Commit 8ca51e51c182 ("dm: mmc: Add a way to use driver model for
MMC operations") separated the comment from the code. Put them back
together.
Fixes: 8ca51e51c182 ("dm: mmc: Add a way to use driver model for MMC operations") Signed-off-by: Baruch Siach <baruch@tkos.co.il> Reviewed-by: Peng Fan <peng.fan@nxp.com>
mmc: mv_sdhci: fix uninitialized pointer deref on probe
Since commit 3d296365e4e8 ("mmc: sdhci: Add support for
sdhci-caps-mask") sdhci_setup_cfg() expects a valid sdhci_host mmc
field. Move the mmc field initialization before sdhci_setup_cfg()
call to avoid crash on mmc pointer dereference.
Fixes: 3d296365e4e8 ("mmc: sdhci: Add support for sdhci-caps-mask") Cc: Faiz Abbas <faiz_abbas@ti.com> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Add a standalone MMC block write test. This allows direct testing of MMC
access rather than relying on doing so as a side-effect of e.g. DFU or
UMS testing, which may not be enabled on all platforms.
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Stephen Warren <swarren@nvidia.com>
Peng Fan [Wed, 31 Jul 2019 07:01:49 +0000 (07:01 +0000)]
dm: clk: ignore default settings when node not valid
When the device not binded with a node, we need ignore
the parents and rate settings.
Cc: Simon Glass <sjg@chromium.org> Cc: Jagan Teki <jagan@amarulasolutions.com> Cc: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Andreas Dannenberg <dannenberg@ti.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Peng Fan [Wed, 31 Jul 2019 07:01:23 +0000 (07:01 +0000)]
clk: introduce clk_dev_binded
When support Clock Common Framework, U-Boot use dev for
clk tree information, there is no clk->parent. When
support composite clk, it contains mux/gate/divider,
but the mux/gate/divider is not binded with device.
So we could not use dev_get_uclass_priv to get the correct
clk_mux/gate/divider. So add clk_dev_binded to let
choose the correct method.
Tom Rini [Tue, 30 Jul 2019 23:19:54 +0000 (19:19 -0400)]
Merge tag 'video-for-2019.10-rc1' of https://gitlab.denx.de/u-boot/custodians/u-boot-video
- fix EDID mode filtering
- extend mxc_ipuv3_fb to enable backlight/display
- include fb_base in global_data for DM_VIDEO
- show frame buffer address via board info
as used to be with legacy VIDEO support
Michal Simek [Tue, 30 Jul 2019 15:07:27 +0000 (17:07 +0200)]
arm64: zynqmp: Do not include pm_cfg_obj.o when SPL is disabled
xilinx_zynqmp_mini configuration is throwing build error:
readlink: missing operand
Try 'readlink --help' for more information.
because CONFIG_ZYNQMP_SPL_PM_CFG_OBJ_FILE is not defined at all and
Makefile pass ifneq condition. Add SPL_BUILD dependency which is also
reflected in Kconfig.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Alexander Dahl [Fri, 28 Jun 2019 12:41:24 +0000 (14:41 +0200)]
cmd: fpga: Change return value to avoid printing usage text
In cmd/fpga.c the commands should return enum command_ret_t, e.g.
CMD_RET_USAGE, CMD_RET_SUCCESS, or CMD_RET_FAILURE. What they actually
do is passing a return value from different 'fpga_' functions.
Passing on a return value of -1 from a called function leads to printing
out usage text. In case of actually correct usage with correctly
specified parameters but some fail at runtime printing out that usage
text is distracting.
The reason is most 'fpga_' functions return either FPGA_SUCCESS or
FPGA_FAIL, the latter was equal to -1 which is the same value as
CMD_RET_USAGE. So just passing on FPGA_FAIL lead to printing out usage.
We should only return CMD_RET_USAGE in cases, where the user sent wrong
input. Every other case should return CMD_RET_SUCCESS or
CMD_RET_FAILURE, and not simply pass an error code.
Simply changing FPGA_FAIL from -1 to 1 gets the job done.
Suggested-by: Michal Simek <michal.simek@xilinx.com> Signed-off-by: Alexander Dahl <ada@thorsis.com>
Alexander Dahl [Fri, 28 Jun 2019 12:41:20 +0000 (14:41 +0200)]
fpga: altera: Add some more device sizes
There seems to be only one place, where this is checked against:
`altera_validate()`. It should be non zero. Otherwise it is only used to
display it, so it probably does not really matter at the moment. But we
had the datasheet open anyway …
Sizes in datasheet are bit counts, display here is in bytes.
Luca Ceresoli [Thu, 20 Jun 2019 16:18:16 +0000 (18:18 +0200)]
arm64: zynqmp: add MAINTAINERS entry for Avnet UltraZed-EV
The board was added without adding a MAINTAINERS entry.
Fixes:
$ ./tools/genboardscfg.py -f
WARNING: no status info for 'avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0'
WARNING: no maintainers for 'avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0'
$
Reported-by: Michal Simek <michal.simek@xilinx.com> Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Robert Hancock [Tue, 18 Jun 2019 15:47:16 +0000 (09:47 -0600)]
fpga: virtex2: Add slave serial programming support
This adds support for slave serial programming, in addition to the
previously supported slave SelectMAP mode. There are two ways that this
can be used:
-Using the clk and wdata callbacks in order to write image data one bit
at a time using pure bit-banging. This works, but is rather painfully
slow with typical image sizes.
-By specifying the wbulkdata callback instead, the image loading process
can be offloaded to SPI hardware. In this mode the clk and wdata
callbacks do not need to be specified. This allows the image to be
loaded much faster, taking only a few seconds with even relatively large
images.
Slave serial programming has been tested on the Kintex-7 series of
FPGAs.
Signed-off-by: Robert Hancock <hancock@sedsystems.ca> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Robert Hancock [Tue, 18 Jun 2019 15:47:15 +0000 (09:47 -0600)]
fpga: virtex2: Add additional clock cycles after DONE assertion
Some Xilinx FPGA configuration options can result in the startup
sequence extending past the end of the FPGA bitstream. Continue applying
CCLK clock cycles for 8 cycles after DONE is asserted in order to ensure
the startup sequence is complete, as recommended by Xilinx.
Signed-off-by: Robert Hancock <hancock@sedsystems.ca> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Robert Hancock [Tue, 18 Jun 2019 15:47:14 +0000 (09:47 -0600)]
fpga: virtex2: Split out image writing from pre/post operations
This is in preparation for adding slave serial programming support,
which uses the same pre/post operations as slave SelectMAP, to avoid
duplicating code.
Signed-off-by: Robert Hancock <hancock@sedsystems.ca> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Robert Hancock [Tue, 18 Jun 2019 15:47:13 +0000 (09:47 -0600)]
fpga: virtex2: added Kconfig option
Add an option to allow this driver to be selected with Kconfig. As noted
in the description, this driver should also work with many newer Xilinx
FPGA families as the programming methods are essentially the same.
Also added a missing FPGA_XILINX dependency to the similar Spartan 3
driver.
Signed-off-by: Robert Hancock <hancock@sedsystems.ca> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Luca Ceresoli [Tue, 11 Jun 2019 16:39:41 +0000 (18:39 +0200)]
arm64: zynqmp: add support for Avnet UltraZed-EV Starter Kit
Avnet UltraZed-EV Starter Kit is composed by the UltraZed-EV SoM and the
only publicly-available compatible carrier card. The SoM is based on the EV
version of the Xilinx ZynqMP SoC+FPGA.
The psu_init_gpl.c file has been generated from the board definition files
at [0] using Vivado 2018.3 and then minimized by
tools/zynqmp_psu_init_minimize.sh. Manually removed serdes init code since
it is not mentioned in device tree and fixed a checkpatch error.
Luca Ceresoli [Fri, 24 May 2019 13:40:02 +0000 (15:40 +0200)]
arm64: zynqmp: add tool to minimize psu_init_gpl.c files
This script transforms a pair of psu_init_gpl.c and .h files produced by
the Xilinx Vivado tool for ZynqMP into a smaller psu_init_gpl.c file that
is almost checkpatch compliant.
Based on a script by Michal Simek.
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Luca Ceresoli [Fri, 24 May 2019 13:40:01 +0000 (15:40 +0200)]
arm64: zynqmp: xil_io.h: declare functions as static
Fixes sparse warnings when building zynqmp defconfigs:
./board/xilinx/zynqmp/xil_io.h:12:6: warning: symbol 'Xil_Out32' was not declared. Should it be static?
./board/xilinx/zynqmp/xil_io.h:17:5: warning: symbol 'Xil_In32' was not declared. Should it be static?
./board/xilinx/zynqmp/xil_io.h:22:6: warning: symbol 'usleep' was not declared. Should it be static?
Also add __maybe_unused to usleep() since it is not used by minimized
psu_init_gpl.c files, so it would warn as "defined but not used".
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Luca Ceresoli [Tue, 21 May 2019 16:06:44 +0000 (18:06 +0200)]
arm64: zynqmp: add tool to convert PMU config object .c to binary
The recently-added ZYNQMP_SPL_PM_CFG_OBJ_FILE option allows SPL to load a
PMUFW configuration object from a binary blob. However the configuration
object is produced by Xilinx proprietary tools as a C source file and no
tool exists to easily convert it to a binary blob in an embedded Linux
build system for U-Boot to use.
Add a simple Python script to do the conversion.
It is definitely not a complete C language parser, but it is enough to
parse the known patterns generated by Xilinx tools, including:
- defines
- literal integers, optionally with a 'U' suffix
- bitwise OR between them
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Luca Ceresoli [Tue, 21 May 2019 16:06:43 +0000 (18:06 +0200)]
arm64: zynqmp: spl: install a PMU firmware config object at runtime
Optionally allow U-Boot to load a configuration object into the Power
Management Unit (PMU) firmware on Xilinx ZynqMP.
The configuration object is required by the PMU FW to enable most SoC
peripherals. So far the only way to boot using U-Boot SPL was to hard-code
the configuration object in the PMU firmware. Allow a different boot
process, where the PMU FW is equal for any ZynqMP chip and its
configuration is passed at runtime by U-Boot SPL.
All the code for Inter-processor communication with the PMU is isolated in
a new file (pmu_ipc.c). The code is inspired by the same feature as
implemented in the Xilinx First Stage Bootloader (FSBL) and Arm Trusted
Firmware:
projects / u-boot.git / log