aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-09-07arm: Finish migration of CONFIG_MACH_TYPEWIP/2021-09-07-ATAGs-and-related-migrationTom Rini83-249/+7
As this is only useful when booting with ATAGs, which are now largely disabled, remove this value for the remaining platforms. Cc: Phil Sutter <phil@nwl.cc> Signed-off-by: Tom Rini <trini@konsulko.com>
2021-09-07arm: Add Kconfig entry for MACH_TYPETom Rini6-2/+22
As part of migrating support for ATAGs to Kconfig, add an option for setting and passing MACH_TYPE. Signed-off-by: Tom Rini <trini@konsulko.com>
2021-09-07arm: Disable ATAGs supportTom Rini151-563/+114
With the exceptions of ds109, ds414, icnova-a20-swac, nokia_rx51 and stemmy, disable ATAG support. A large number of platforms had enabled support but never supported a kernel so old as to require it. Further, some platforms are old enough to support both, but are well supported by devicetree booting, and have been for a number of years. This is because some of the ATAGs related functions have been re-used to provide the same kind of information, but for devicetree or just generally to inform the user. When needed still, rename these functions to get_board_revision() instead, to avoid conflicts. In other cases, these functions were simply unused, so drop them. Cc: Andre Przywara <andre.przywara@arm.com> Cc: Jagan Teki <jagan@amarulasolutions.com> Cc: Phil Sutter <phil@nwl.cc> Cc: Stefan Bosch <stefan_b@posteo.net> Signed-off-by: Tom Rini <trini@konsulko.com>
2021-09-07imx: Convert SERIAL_TAG support to ENV_VARS_UBOOT_RUNTIME_CONFIGTom Rini19-20/+27
No iMX platforms have supported ATAG-based booting. They have however re-used the CONFIG_SERIAL_TAG option as a way to enable support of reading the OTP fuses and setting the serial# environment variable in some cases. Change the warp7 support to use this symbol, use this for updating the rest of the imx7 code, and update the imx8 conditionals. Cc: Stefano Babic <sbabic@denx.de> Cc: Fabio Estevam <festevam@gmail.com> Cc: NXP i.MX U-Boot Team <uboot-imx@nxp.com> Signed-off-by: Tom Rini <trini@konsulko.com>
2021-09-07Convert CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG to KconfigTom Rini19-21/+8
This converts the following to Kconfig: CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG Signed-off-by: Tom Rini <trini@konsulko.com>
2021-09-04configs: Resync with savedefconfigTom Rini57-86/+20
Rsync all defconfig files using moveconfig.py Signed-off-by: Tom Rini <trini@konsulko.com>
2021-09-04Merge branch '2021-09-04-makefile-cleanups-part-b' into nextTom Rini463-973/+1131
- Further Makefile/Kconfig namespace cleanups from Simon. This migrates a number of symbols to Kconfig and replaces some inconsistencies between CONFIG_FOO and CONFIG_SPL_FOO_SUPPORT/CONFIG_TPL_FOO_SUPPORT.
2021-09-04net: Move network rules to drivers/netSimon Glass7-7/+12
The code under drivers/net is related to ethernet networking drivers, in some fashion or another. Drop these from the top-level Makefile and also move the phy rule into drivers/net/Makefile which is where it belongs. Make the new rule for drivers/net check for the build-stage relevant ETH symbol. Fix up some Kconfig dependencies while we're here to mirror how the Makefile logic now works. Signed-off-by: Simon Glass <sjg@chromium.org> [trini: Introduce ETH, Kconfig dependency changes, am43xx fix] Signed-off-by: Tom Rini <trini@konsulko.com>
2021-09-04net: Rename SPL_NET_SUPPORT to SPL_NETSimon Glass16-25/+25
Rename this option so that CONFIG_IS_ENABLED can be used with it. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-09-04power: Refactor Makefile rulesSimon Glass6-12/+25
Move the power/ rules into drivers/power to avoid clutter in the Makefile and drivers/Makefile files. We must select SPL_POWER if SPL_POWER_DOMAIN is used, since the two are currently independent and boards do not necessarily enable SPL_POWER. Add a TPL_POWER as well, as that is used by one board. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
2021-09-04power: Add a POWER configSimon Glass2-2/+16
At present we have SPL_POWER but not piain POWER. This works because there is a special build rule in Makefile that always includes the drivers/power directory. It is better to have all driver directories included by drivers/Makefile and there is already a rule in there for this purpose. It just needs a Kconfig for U-Boot proper, so add one. Update the pmic.h header file so that it defines the old pmic struct always, when driver model is not in use. That will avoid build errors for boards which enable POWER but not DM_PMIC. Enable this option always. That seems strange at first sight, but it actually but mimics the current Makefile behaviour. Once we can drop the old PMICs it should be easy enough to rename DM_PMIC to POWWER, or something similar. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-09-04i2c: Convert CONFIG_POWER_I2C et al to KconfigSimon Glass68-65/+131
This converts the following to Kconfig: CONFIG_POWER_I2C CONFIG_POWER_LEGACY They are handled at the same time due to a dependency between them. Update the Makefile rule to use legacy power only in U-Boot proper. Unfortunately a separate rule is needed in SPL to be able to build legacy power. Add SPL related symbols for both, to allow for SPL-only usage. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com> [trini: More SPL related cleanups, reword commit message] Signed-off-by: Tom Rini <trini@konsulko.com>
2021-09-04power: Rename CONFIG_POWER to CONFIG_POWER_LEGACYSimon Glass34-40/+45
This option is used in pre-driver model code and much of it has never been converted to driver model. We want to add a new option to enable power support, so we can use a simple rule in the Makefile. Rename this one, which is really about a particular implementation of power. Also update the pmic.h header file so it either includes the legacy API or the driver model one. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
2021-09-04power: Tidy up #undef of CONFIG_DM_PMICSimon Glass20-21/+38
Add a proper Kconfig option for SPL so we can remove the hack in some of the board config files. This involves adding CONFIG_SPL_DM_PMIC to some of the configs as well as updateing the Makefile rule for PMIC_RK8XX to exclude SPL. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com> [trini: Add SPL_PMIC_RK8XX, enable when needed, handle undef of CONFIG_DM_PMIC_PFUZE100 as well] Signed-off-by: Tom Rini <trini@konsulko.com>
2021-09-04gpio: Add a GPIO configSimon Glass2-3/+14
At present we have SPL_GPIO and TPL_GPIO but not piain GPIO. This works because there is a special build rule in Makefile that always includes the drivers/gpio directory. It is better to have all driver directories included by drivers/Makefile and there is already a rule in there for this purpose. It just needs a Kconfig for U-Boot proper, so add one. Enable the option always for now, since this mimics current behaviour. This can be updated once DM_GPIO is used everywhere. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-09-04tegra: gpio: Drop use of CONFIG_xxx variablesSimon Glass1-5/+5
It is not a good idea to use things called CONFIG_xxx in the source code since this prefix is reserved for use by Kconfig. Rename these variables. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-09-04Makefile: Move drivers/dma/ into drivers/MakefileSimon Glass3-2/+3
This rule should not be in the top-level Makefile. Move it, making use of the new LEGACY_DMA Kconfig. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-09-04Convert CONFIG_DMA_LPC32XX to KconfigSimon Glass4-4/+12
This converts the following to Kconfig: CONFIG_DMA_LPC32XX Signed-off-by: Simon Glass <sjg@chromium.org>
2021-09-04ti: Convert CONFIG_TI_EDMA3 to KconfigSimon Glass9-1/+8
This converts the following to Kconfig: CONFIG_TI_EDMA3 Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2021-09-04dma: Add a Kconfig for legacy DMASimon Glass1-0/+10
We cannot use the existing DMA config for the MCD driver because it is not migrated to driver model. In order to move it to drivers/Makefile we need some sort of option for it. Add a new DMA_LEGACY option, which also acts as a signal that it should be migrated. Enable this for devkit3250 which uses CONFIG_DMA_LPC32XX which is not converted to Kconfig. For now this is not used in the Makefile. That update happens in a following patch. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-09-04Makefile: Unify the rules for BOOTCOUNT_LIMITSimon Glass1-3/+1
Use a single rule that works for all phases. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-09-04sata: Rename SATA_SUPPORT to SATASimon Glass9-16/+16
Rename this options so that CONFIG_IS_ENABLED can be used with it. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-09-04ppc: Rename MPC8XXX_INIT_DDR_SUPPORT to MPC8XXX_INIT_DDRSimon Glass75-78/+78
Rename these options so that CONFIG_IS_ENABLED can be used with them. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-09-04Rename CACHE_SUPPORT to CACHESimon Glass2-8/+1
Rename this option so that CONFIG_IS_ENABLED can be used with it. Oddly there is already an SPL_CACHE option. Drop it in favour of this one. Drop the special SPL Makefile rule which is now superfluous. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-09-04spi: Rename SPI_SUPPORT to SPISimon Glass110-117/+116
Rename these options so that CONFIG_IS_ENABLED can be used with them. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-09-04serial: Add a SERIAL configSimon Glass2-3/+13
At present we have SPL_SERIAL and TPL_SERIAL but not piain SERIAL. This works because there is a special build rule in Makefile that always includes the drivers/serial directory. It is better to have all driver directories included by drivers/Makefile and there is already a rule in there for this purpose. It just needs a Kconfig for U-Boot proper, so add one. It is always enabled, for now, since that mimics the current behaviour. It should be possible to drop the strange 'SERIAL_PRESENT' option at some point and use SERIAL instead. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-09-04serial: Rename SERIAL_SUPPORT to SERIALSimon Glass313-353/+353
Rename these options so that CONFIG_IS_ENABLED can be used with them. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-09-04rtc: Rename RTC_SUPPORT to RTCSimon Glass7-8/+8
Rename these options so that CONFIG_IS_ENABLED can be used with them. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-09-04pch: Rename PCH_SUPPORT to PCHSimon Glass6-10/+10
Rename these options so that CONFIG_IS_ENABLED can be used with them. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-09-04mmc: Rename MMC_SUPPORT to MMCSimon Glass212-232/+233
Rename these options so that CONFIG_IS_ENABLED can be used with them. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com> [trini: Fixup some incorrect renames] Signed-off-by: Tom Rini <trini@konsulko.com>
2021-09-03Merge branch '2021-09-03-xyz-modem-fixes' into nextTom Rini2-6/+38
- Assorted x/y/z modem fixes from Pali
2021-09-03xyz-modem: Allow to cancel transfer also by CTRL+CWIP/2021-09-03-xyz-modem-fixesPali Rohár1-0/+2
Currently it is possible to cancel loadx and loady commands by pressing CTRL+X (CAN character) at least 3 times quickly. All other U-Boot commands, including loadb and loads can be cancelled by CTRL+C. So allow it also in xyz-modem code used by loadx and loady commands. Implement it by handling CTRL+C (ETX character) in the same way as CTRL+X (CAN character). Due to how x/y-modem protocol works, it is required to press CTRL+C or CTRL+X at least 3 times quickly. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-09-03xyz-modem: Show information about finished transferPali Rohár1-0/+16
Show "## Start Addr" or "## Binary (...) download aborted" information like in Kermit "loadb" command. Signed-off-by: Pali Rohár <pali@kernel.org>
2021-09-03xyz-modem: Properly abort/terminate transfer on errorPali Rohár1-1/+13
Transfer termination tries to instruct sender that transfer was terminated. Print error message and indicates aborted transfer in return value. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-09-03xyz-modem: Close stream after processing/sending terminate sequencePali Rohár1-1/+1
Obviously it is not possible to send terminate sequence over stream after closing stream. Signed-off-by: Pali Rohár <pali@kernel.org>
2021-09-03xyz-modem: Put xyzModem_stream_close debug diagnostic message into ZM_DEBUG()Pali Rohár1-2/+2
This is how all other debug / diagnostic messages are handled. Signed-off-by: Pali Rohár <pali@kernel.org>
2021-09-03xyz-modem: Fix x-modem "xyzModem_eof error" at the end of filePali Rohár1-0/+2
In x-modem protocol EOF is not an error state at the end of file. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-09-03xyz-modem: Fix crash after cancelling transferPali Rohár1-2/+2
Variable xyz.len is set to -1 on error. At the end xyzModem_stream_read() function calls memcpy() with length from variable xyz.len. If this variable is set to -1 then value passed to memcpy is casted to unsigned value, which means to copy whole address space. Which then cause U-Boot crash. E.g. on arm64 it cause CPU crash: "Synchronous Abort" handler, esr 0x96000006 Fix this issue by checking that value stored in xyz.len is valid prior trying to use it. Signed-off-by: Pali Rohár <pali@kernel.org> Acked-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2021-09-03Revert most of the series for adding vexpress_aemv8r supportWIP/03Sep2021-nextTom Rini16-383/+43
Per a request from Andre Przywara and agreed with by Peter Hoyes, the vexpress aemv8r support wasn't quite ready to be merged, but the discussion had moved off list. We should keep the first patch in the series for now, but revert the rest. This reverts the following commits: e0bd6f31ce41 doc: Add documentation for the Arm vexpress board configs 30e5a449e8c7 arm: Use armv8_switch_to_el1 env to switch to EL1 b53bbca63bf4 vexpress64: Add BASER_FVP vexpress board variant 2f5b7b74903f armv8: Add ARMv8 MPU configuration logic 37a757e227cc armv8: Ensure EL1&0 VMSA is enabled Signed-off-by: Tom Rini <trini@konsulko.com>
2021-09-02Merge branch '2021-09-02-assorted-platform-and-bugfixes' into nextTom Rini31-91/+527
- Add position independent execution support for ARMv7 - Snapdragon, synquacer, vexpress64 fixes / improvements - Prevent NEON register use on ARMv8 - Other assorted fixes
2021-09-02tools: env: Handle shorter read callsThibault Ferrante1-10/+12
On some cases, the actual number of bytes read can be shorter than what was requested. This can be handled gracefully by taking this difference into account instead of exiting. Signed-off-by: Thibault Ferrante <thibault.ferrante@gmail.com>
2021-09-02psci: fix double declarationOleksandr Suvorov1-1/+0
The prototype of psci_features() duplicated. Remove extra declaration. Fixed: e21e3ffdd1 ("psci: Fix warnings when compiling with W=1") Reported-by: Michael Scott <mike@foundries.io> Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@foundries.io>
2021-09-02pci: iproc: fix compilation errors and warningsBharat Gooty1-3/+4
Signed-off-by: Bharat Gooty <bharat.gooty@broadcom.com>
2021-09-02mailmap: Update e-mail for Jernej SkrabecJernej Skrabec1-0/+1
Old address doesn't exist anymore. Map it to new one. Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Acked-by: Andre Przywara <andre.przywara@arm.com>
2021-09-02ARM: Prevent the compiler from using NEON registersSamuel Holland1-0/+1
For ARMv8-A, NEON is standard, so the compiler can use it even when no special target flags are provided. For example, it can use stores from NEON registers to zero-initialize large structures. GCC 11 decides to do this inside the DRAM init code for the Allwinner H6. However, GCC 11 has a bug where it generates misaligned NEON register stores even with -mstrict-align. Since the MMU is not enabled this early in SPL, the misaligned store causes an exception and breaks booting. Work around this issue by restricting the compiler to using GPRs only, not vector registers. This prevents any future surprises relating to NEON use as well. Signed-off-by: Samuel Holland <samuel@sholland.org> Acked-by: Andre Przywara <andre.przywara@arm.com>
2021-09-02doc: Add documentation for the Arm vexpress board configsPeter Hoyes4-1/+69
Create a new documentation section for Arm Ltd boards with a sub-page for the vexpress board (FVP-A, FVP-R and Juno). Document how the armv8_switch_to_el1 environment variable can be used to switch between booting from S-EL2/S-EL1 at runtime on the BASER_FVP. Signed-off-by: Peter Hoyes <Peter.Hoyes@arm.com>
2021-09-02arm: Use armv8_switch_to_el1 env to switch to EL1Peter Hoyes1-15/+25
Use the environment variable armv8_switch_to_el1 to determine whether to switch to EL1 at runtime. This is an alternative to the CONFIG_ARMV8_SWITCH_TO_EL1 compile-time option. The environment variable will be ineffective if the ARMV8_MULTIENTRY config is used. This is required by the Armv8r64 architecture, which must be able to boot at S-EL1 for Linux but may need to boot at other ELs for other systems. Signed-off-by: Peter Hoyes <Peter.Hoyes@arm.com>
2021-09-02vexpress64: Add BASER_FVP vexpress board variantPeter Hoyes7-24/+94
The BASER_FVP board variant is implemented on top of the BASE_FVP board config (which, in turn, is based on the Juno Versatile Express board config). They all share a similar memory map - for BASER_FVP the map is inverted from the BASE_FVP (https://developer.arm.com/documentation/100964/1114/Base-Platform/Base---memory/BaseR-Platform-memory-map) * Create new TARGET_VEXPRESS64_BASER_FVP target, which uses the same board config as BASE_FVP and JUNO * Adapt vexpress_aemv8a.h header file to support BASER_FVP (and rename to vexpress_aemv8.h) * Enable config to switch to EL1 for the BASER_FVP * Create vexpress_aemv8r defconfig * Provide an MPU memory map for the BASER_FVP For now, only single core boot is supported. Signed-off-by: Peter Hoyes <Peter.Hoyes@arm.com> [trini: Add MAINTAINERS, move BOOTCOMMAND to defconfig] Signed-off-by: Tom Rini <trini@konsulko.com>
2021-09-02armv8: Add ARMv8 MPU configuration logicPeter Hoyes2-3/+154
Armv8r64 is the first Armv8 platform that only has a PMSA at the current exception level. The architecture supplement for Armv8r64 describes new fields in ID_AA64MMFR0_EL1 which can be used to detect whether a VMSA or PMSA is present. These fields are RES0 on Armv8a. Add logic to read these fields and, for the protection of the memory used by U-Boot, initialize the MPU instead of the MMU during init, then clear the MPU regions before transition to the next stage. Provide a default (blank) MPU memory map, which can be overridden by board configurations. Signed-off-by: Peter Hoyes <Peter.Hoyes@arm.com>
2021-09-02armv8: Ensure EL1&0 VMSA is enabledPeter Hoyes2-0/+41
On Armv8-R, the EL1&0 memory system architecture is configurable as a VMSA or PMSA, and resets to an "architecturally unknown" value. Add code to armv8_switch_to_el1_m which detects whether the MSA at EL1&0 is configurable using the id_aa64mmfr0_el1 register MSA fields. If it is we must ensure the VMSA is enabled so that a rich OS can boot. The MSA and MSA_FRAC fields are described in the Armv8-R architecture profile supplement (section G1.3.7): https://developer.arm.com/documentation/ddi0600/latest/ Signed-off-by: Peter Hoyes <Peter.Hoyes@arm.com>
generated by cgit v1.1 at 2024-08-05 16:31:36 +0000