Marek Szyprowski [Thu, 16 Jan 2020 15:25:34 +0000 (16:25 +0100)]
arm: dts: exynos: Fix card-detect polarity for SD card on Odroid U3/X2
Card detect line for SD-card on Odroid U3/X2 boards are active low, so
add cd-inverted property to indicate this, as u-boot's GPIO driver doesn't
support specifying line polarity. This restores S5P_SDHCI driver operation
on Odroid U3/X2 boards.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Anand Moon <linux.amoon@gmail.com> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Marek Szyprowski [Thu, 16 Jan 2020 13:46:04 +0000 (14:46 +0100)]
arm: exynos: Use proper PMIC device names
Since commit 4213609cc7 ("drivers: core: use strcmp when find device by
name") one has to provide full name to get requested object. Fix the code
used to detect enable power regulators on the supported Exynos boards to
use proper PMIC device device name then.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Anand Moon <linux.amoon@gmail.com> Reviewed-by: Lukasz Majewski <lukma@denx.de> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Marek Szyprowski [Tue, 14 Jan 2020 14:04:20 +0000 (15:04 +0100)]
arm: exynos: Use proper ADC device name
Since commit 4213609cc7 ("drivers: core: use strcmp when find device by
name") one has to provide full name to get requested object. Fix the code
used to detect Odroid board revision to use proper ADC device name then.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Anand Moon <linux.amoon@gmail.com> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Baruch Siach [Mon, 20 Jan 2020 12:20:14 +0000 (14:20 +0200)]
ARM: mvebu: clearfog: add Clearfog GTR support
Select the serdes configuration table based on the platform identity
read from EEPROM TLV data. Clearfog GTR needs a slightly different
serdes configuration.
Reviewed-by: Stefan Roese <sr@denx.de> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Baruch Siach [Mon, 20 Jan 2020 12:20:11 +0000 (14:20 +0200)]
ARM: mvebu: clearfog: read basic TLV data
Read RAM die capacity from the EEPROM TLV.
Follow the ONIE standard that defines the Vendor Extension entry type
for vendor specific data. We have no Private Enterprise Number at the
moment as the standard requires. Use the dummy all 0xff value for now.
Signed-off-by: Baruch Siach <baruch@tkos.co.il> Reviewed-by: Stefan Roese <sr@denx.de>
Keep only I2C EEPROM support. Use the generic eeprom driver. Fix
checkpatch issues.
Add support for multiple EEPROM TLV stores on the same system. This is
useful in case of SOM and carrier that both provide ID and hardware
configuration information.
Add option to enable for SPL. This allows selection of RAM configuration
based on EEPROM stored board identification.
Baruch Siach [Mon, 20 Jan 2020 12:20:06 +0000 (14:20 +0200)]
ddr: marvell: a38x: allow board specific clock out setup
DDR clock out might be unrelated to the number of active chip-select.
For example, the board might have two DDR components, but only one
chip-select. The clk_enable mask allows the board to enable DDR clocks
regardless of active chip-selects.
Reviewed-by: Stefan Roese <sr@denx.de> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Alifer Moraes [Tue, 14 Jan 2020 18:54:59 +0000 (15:54 -0300)]
imx8m: clock_imx8mm: Staticize functions
Functions fracpll_configure(), decode_intpll(), decode_fracpll(),
get_root_src_clk() and get_root_clk() are used only in the scope of this
file, so make them static to fix the following sparse warnings:
arch/arm/mach-imx/imx8m/clock_imx8mm.c:50:5: warning: no previous
prototype for ‘fracpll_configure’ [-Wmissing-prototypes]
arch/arm/mach-imx/imx8m/clock_imx8mm.c:271:5: warning: no previous
prototype for ‘decode_intpll’ [-Wmissing-prototypes]
arch/arm/mach-imx/imx8m/clock_imx8mm.c:418:5: warning: no previous
prototype for ‘decode_fracpll’ [-Wmissing-prototypes]
arch/arm/mach-imx/imx8m/clock_imx8mm.c:483:5: warning: no previous
prototype for ‘get_root_src_clk’ [-Wmissing-prototypes]
arch/arm/mach-imx/imx8m/clock_imx8mm.c:527:5: warning: no previous
prototype for ‘get_root_clk’ [-Wmissing-prototypes]
arm: dts: imx7ulp-evk: remove mux value from pad configuration
The mux mode is embedded in the PAD definition and therefore there is
no need to repeat it in the PAD configuration value (more over since
this information will be masked out when the configuration value is
applied).
On SPL enabled systems, the current s_init code (wdog, clock and ldo
init) is executed twice (by SPL and u-boot). This is not necessary and
might lead to boot issues (ie, starting PMC1 when it is already running).
Fabio Estevam [Fri, 17 Jan 2020 11:58:46 +0000 (08:58 -0300)]
mx7ulp_evk_plugin: Disable CONFIG_NET
Currently the following build warning is seen:
===================== WARNING ======================
This board does not use CONFIG_DM_ETH (Driver Model
for Ethernet drivers). Please update the board to use
CONFIG_DM_ETH before the v2020.07 release. Failure to
update by the deadline may result in board removal.
See doc/driver-model/migration.rst for more info.
===================================================
Since the mx7ulp-evk board does not have networking support, explicitly
disable networking.
Fix dtb building warnings:
Warning (cooling_device_property): /thermal-zones/cpu-thermal0/cooling-maps/map0:
Missing property '#cooling-cells' in node /cpus/cpu@0 or bad phandle (referred from cooling-device[0])
Arkadiusz Karas [Thu, 2 Jan 2020 18:31:21 +0000 (19:31 +0100)]
ARM: imx: mx6ull: Add iMX6ULL VisionSOM SoM and EVK
Add iMX6ULL VisionSOM SoM and VisionCB-RT-STD evaluation board support.
The SoM has an iMX6ULL, 512 MiB of DRAM and microSD slot. The carrier
board has Ethernet, USB host port, USB OTG port.
Signed-off-by: Arkadiusz Karas <arkadiusz.karas@somlabs.com> Signed-off-by: Marek Vasut <marex@denx.de> Cc: Stefano Babic <sbabic@denx.de>
Lokesh Vutla [Fri, 17 Jan 2020 06:27:30 +0000 (11:57 +0530)]
clk: sci-clk: add slack to clk-set-rate passed to firmware
Add slack to the clock frequency parameters passed to firmware within
clk_set_rate. min-freq is changed to 0 and max-rate is changed to
ULONG_MAX. This fixes certain issues with pll clock rounding when the
firmware is not able to set the frequency exactly to the target, the
current implementation fails if the available frequency is even 1Hz off
the target. With the change, the firmware still tries its best to set
the frequency as close as possible to the target.
Add pinmux for USB1 and enable it as a peripheral port in U-Boot
specific dtsi since U-Boot does not support OTG.
Disable USB0 as its not available on the baseboard.
phy: omap-usb2-phy: Fix warnings when built for ARM64
Below warning is seen when this driver is built for devices with 64 bit
physical address space.
drivers/phy/omap-usb2-phy.c: In function ‘omap_usb2_phy_probe’:
drivers/phy/omap-usb2-phy.c:187:20: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
priv->phy_base = (void *)base;
^
Fix this by using dev_read_addr_ptr() instead of dev_read_addr().
Adam Ford [Sun, 12 Jan 2020 12:52:10 +0000 (06:52 -0600)]
ARM: dts: omap3/omap35 Torpedo and SOM-LV: Unify and shrink SPL dtb
None of these boards boot, but the solution appears to be the same.
All the boards have SPL that is too large. With a few defconfig
options removed, these corresponding options can be removed from
their respective SPL dtb files.
This patch unifies the DM37/OMAP35 boards' -u-boot.dtsi files
to remove gpio's, i2c, bandgap, thermal zones, unneeded uarts, and
unneeded MMC nodes.
Signed-off-by: Adam Ford <aford173@gmail.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Andrew F. Davis [Fri, 10 Jan 2020 19:35:23 +0000 (14:35 -0500)]
configs: Add configs for J721e High Security EVM
Add new defconfig files for the J721e High Security EVM.
These defconfigs are the same as for the non-secure part, except for:
CONFIG_TI_SECURE_DEVICE option set to 'y'
CONFIG_FIT_IMAGE_POST_PROCESS option set to 'y'
CONFIG_SPL_FIT_IMAGE_POST_PROCESS option set to 'y'
CONFIG_BOOTCOMMAND uses FIT images for booting
Signed-off-by: Andrew F. Davis <afd@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
The memory allocated to store the FIT image containing SYSFW and board
configuration data is statically defined to the largest size expected.
This was 276000 bytes but now needs to be grown to 277000 to make room
for the slightly larger SYSFW image used on J721e High-Security devices.
Signed-off-by: Andrew F. Davis <afd@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Andrew F. Davis [Fri, 10 Jan 2020 19:35:21 +0000 (14:35 -0500)]
arm: K3: Disable ROM configured firewalls
ROM configures certain firewalls based on its usage, which includes
the one in front of boot peripherals. In specific case of boot
peripherals, ROM does not open up the full address space corresponding
to the peripherals. Like in OSPI, ROM only configures the firewall region
for 32 bit address space and mark 64bit address space flash regions
as in-accessible.
When security-cfg is initialized by sysfw, all the non-configured
firewalls are kept in bypass state using a global setting. Since ROM
configured firewalls for certain peripherals, these will not be touched.
So when bootloader touches any of the address space that ROM marked as
in-accessible, system raises a firewall exception causing boot hang.
It would have been ideal if sysfw cleans up the ROM configured boot
peripheral firewalls. Given the memory overhead to store this
information provided by ROM and the boot time increase in re configuring
the firewalls, it is concluded to clean this up in bootloaders.
So disable all the firewalls that ROM doesn't open up the full address
space.
Signed-off-by: Andrew F. Davis <afd@ti.com> Signed-off-by: Venkateswara Rao Mandela <venkat.mandela@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Andrew F. Davis [Fri, 10 Jan 2020 19:35:20 +0000 (14:35 -0500)]
arm: K3: Fix header comment match AM6 specific file function
This file used to be the common location for K3 init when AM6 was the
only device, but common code was moved to common.c and this file became
AM6 specific, correct this header text.
Signed-off-by: Andrew F. Davis <afd@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Andrew F. Davis [Fri, 10 Jan 2020 19:35:19 +0000 (14:35 -0500)]
configs: ti: Factor out call to 'args_mmc' into MMC common environment
Both 'loadfit' and 'mmcloados' start with a call to 'args_mmc' so this
can be factored out to before eithers only call site. This also allows us
to remove that call from 'loadfit', which should not have been calling it
anyway as that command should not be MMC specific. Without the call to
'args_mmc' the command 'loadfit' becomes just a call to 'run_fit' so
remove the indirection and call 'run_fit' directly, this removes the need
for 'loadfit' command (which was misnamed anyway). Drop it.
Signed-off-by: Andrew F. Davis <afd@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Andrew F. Davis [Fri, 10 Jan 2020 19:35:18 +0000 (14:35 -0500)]
configs: j721e_evm.h: Sync J721e environment configuration with AM65x
Some of the environment configuration in AM65x is not available in
J721e due to additions on one but not the other. These two platforms
are similar enough these common definitions should be factored out
to a common area, prepare for this by synchronizing them.
Signed-off-by: Andrew F. Davis <afd@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Sam Protsenko [Fri, 10 Jan 2020 13:11:30 +0000 (15:11 +0200)]
arm: am57xx: env: Fix DFU variables
Commit 8502fe84a4fc ("configs: am57xx_evm: define
CONFIG_SPL_LOAD_FIT_ADDRESS for SPL-DFU") implements incorrect ifdef
logic, which leads to DFU variables absence in non-SPL environment. Fix
that in order to bring back DFU variables, by reflecting the logic in
include/configs/dra7xx_evm.h.
Lokesh Vutla [Fri, 10 Jan 2020 09:31:57 +0000 (15:01 +0530)]
arm: dts: k3-am654-r5-base-board: Fix power-domains for wkup_vtm0
wkup_vtm populates only 1 power-domain cell in it's node. But the
power-domain cell are defined as 2. Due to this the following warning
comes during build:
arch/arm/dts/k3-am654-r5-base-board.dtb: Warning (power_domains_property):
/interconnect@100000/interconnect@28380000/interconnect@42040000/
wkup_vtm@42050000:power-domains: property size (8) too small for cell size 2
Keerthy [Fri, 10 Jan 2020 09:22:05 +0000 (14:52 +0530)]
power: regulator: tps62360_regulator: Convert ofdata_to_platdata to the missing probe
commit 29f7d05a347a ("dm: core: Move ofdata_to_platdata() call earlier")
introduces changes in the order of device_probe execution.
ofdata_to_platdata now comes before the probe function which resulted in
a deadlock and caused boot hang on AM6 devices.
Andrew F. Davis [Tue, 7 Jan 2020 23:22:29 +0000 (18:22 -0500)]
arm: mach-k3: security: Clean image out of cache before authentication
On K3 systems U-Boot runs on both an R5 and a large ARM cores (usually
A53 or A72). The large ARMs are coherent with the DMA controllers and
the SYSFW that perform authentication. And previously the R5 core did
not enable caches. Now that R5 does enable caching we need to be sure
to clean out any of the image that may still only be in cache before we
read it using external DMA for authentication.
Although not expected to happen, it may be possible that the data was
read back into cache after the flush but before the external operation,
in this case we must invalidate our stale local cached version.
Signed-off-by: Andrew F. Davis <afd@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Andrew F. Davis [Tue, 7 Jan 2020 23:12:40 +0000 (18:12 -0500)]
arm: mach-k3: Warn when node to disable is not found
Not finding a node that we try to disable does not always need to be
fatal to boot but should at least print out a warning. Return error
from fdt_disable_node as it did fail to disable the node, but only
warn in the case of disabling the TRNG as this will not prevent boot.
Signed-off-by: Andrew F. Davis <afd@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
board: ti: j721e: Use EEPROM-based board detection
The TI J721E EVM system on module (SOM), the common processor board, and
the associated daughtercards have on-board I2C-based EEPROMs containing
board config data. Use the board detection infrastructure to do the
following:
1) Parse the J721E SOM EEPROM and populate items like board name, board
HW and SW revision as well as board serial number into the TI common
EEPROM data structure residing in SRAM scratch space
2) Check for presence of daughter card(s) by probing associated I2C
addresses used for on-board EEPROMs containing daughter card-specific
data. If such a card is found, parse the EEPROM data such as for
additional Ethernet MAC addresses and populate those into U-Boot
accordingly
3) Dynamically apply daughter card DTB overlays to the U-Boot (proper)
DTB during SPL execution
4) Dynamically create an U-Boot ENV variable called name_overlays
during U-Boot execution containing a list of daugherboard-specific
DTB overlays based on daughercards found to be used during Kernel
boot.
This patch adds support for the J721E system on module boards containing
the actual SoC ("J721EX-PM2-SOM", accessed via CONFIG_EEPROM_CHIP_ADDRESS),
the common processor board ("J7X-BASE-CPB"), the Quad-Port Ethernet
Expansion Board ("J7X-VSC8514-ETH"), the infotainment board
("J7X-INFOTAN-EXP") as well as for the gateway/Ethernet switch/industrial
expansion board ("J7X-GESI-EXP").
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
ti: common: board_detect: Handle EEPROM probe more gracefully
Use dm_i2c_probe() rather than i2c_get_chip() when trying to access
board-detection EEPROM devices. This has the advantage of more gracefully
handling the case when the EEPROM is not present by allowing to exit the
function early rather than failing and outputting an error message on the
I2C transactions that follow.
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Jason Kridner [Thu, 2 Jan 2020 14:17:28 +0000 (08:17 -0600)]
board: ti: beagleboneai: add dts file
BeagleBoard.org BeagleBone AI is an open source hardware single board
computer based on the Texas Instruments AM5729 SoC featuring dual-core
1.5GHz Arm Cortex-A15 processor, dual-core C66 digital signal
processor (DSP), quad-core embedded vision engine (EVE), Arm Cortex-M4
processors, dual programmable realtime unit industrial control
subsystems and more. The board features 1GB DDR3L, USB3.0 Type-C, USB
HS Type-A, microHDMI, 16GB eMMC flash, 1G Ethernet, 802.11ac 2/5GHz,
Bluetooth, and BeagleBone expansion headers.
For more information, refer to:
https://beaglebone.ai
The corresponding patch against the mainline linux kernel can be found
at: https://patchwork.kernel.org/patch/11254903/
This patch introduces the BeagleBone AI device tree.
Note that the device use the "ti,tpd12s016" component which is software
compatible with "ti,tpd12s015". Thus we only use the latter driver.
Signed-off-by: Jason Kridner <jdk@ti.com> Signed-off-by: Caleb Robey <c-robey@ti.com> Cc: Robert Nelson <robertcnelson@gmail.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Caleb Robey [Thu, 2 Jan 2020 14:17:27 +0000 (08:17 -0600)]
board: ti: beagleboneai: add initial support
These are necessities for beaglebone ai boot. There is the addition of
CONFIG_SUPPORT_EMMC_CONFIG to the Kconfig file. This is present upstream
but not in 19.01 yet.
Caleb Robey [Thu, 2 Jan 2020 14:17:25 +0000 (08:17 -0600)]
board: ti: beagleboneai: emmc read changes
BeagleBoard.org BeagleBone AI rev A1 does not include a board
identifier I2C EEPROM due to a design oversight. These boards have
been put into production and are generally available now.
The board identifier information, however, has been included in the
second eMMC linear boot partition (/dev/mmcblk1boot1).
This patch works by:
* First, looking for a board identifier I2C EEPROM and if not found,
* Then seeing if the boot mode matches BeagleBone AI with eMMC in the
boot chain to make sure we don't enable eMMC pinmuxes on boards
that don't support it, and
* Finally, initializes the eMMC pins and reading the header.
Signed-off-by: Jason Kridner <jdk@ti.com> Signed-off-by: Caleb Robey <c-robey@ti.com> Cc: Robert Nelson <robertcnelson@gmail.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Faiz Abbas [Thu, 16 Jan 2020 14:12:19 +0000 (19:42 +0530)]
mmc: am654_sdhci: Add Support for configuring PHY in J721e
Add Support for writing to PHY registers for J721e. There are number of
differences between the J721e 8 bit PHY, J721e 4 bit PHY and AM654 PHY.
Create a driver_data structure with an ops and flags field and use the
flags field to indicate these differences. The differences are as
follows:
1. The J721e 4 bit instance PHY does not have a DLL. Introduce a
DLL_PRESENT flag to make sure that DLL related registers are accessed
only where they are present. Also add a separate set_ios_post()
callback.
2. The J721e 8 bit instance is not muxed with anything else inside the
SoC and hence the IOMUX_ENABLE filed does not exist. Add a flag which is
used to indicate the presence of this field.
3. The register field used to select DLL frequency is 3 bit wide in
J721e as compared to 2 bits in AM65x. Add another flag that
distinguishes these fields.
4. The strobe select field is 8 bit wide as compared to 4 bit wide for
AM65x. Add yet another flag to indicate this difference. Strobe select
is used only for HS400 speed mode, support for which has not been added
in AM65x.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
dma: ti: k3-udma: Fix ring push operation for 32 bit cores
UDMA always expects 64 bit address pointer of the transfer descriptor in
the Ring. But on 32 bit cores like R5, pointer is always 32 bit in size.
Therefore copy over 32 bit pointer value to 64 bit variable before
pushing it over to the ring, so that upper 32 bits are 0s.
dma: ti: k3-udma: Remove coherency check for cache ops
Remove redundant coherency checks before calling cache ops in UDMA
driver. This is now handled in arch specific cache operation
implementation based on Kconfig option
soc: ti: k3-navss-ringacc: Get SYSFW reference from DT phandle
Instead of looking getting reference to SYSFW device using name which
is not guaranteed to be constant, use phandle supplied in the DT node to
get reference to SYSFW
soc: ti: k3-navss-ringacc: Flush/invalidate caches on ring push/pop
Flush caches when pushing an element to ring and invalidate caches when
popping an element from ring in Exposed Ring mode. Otherwise DMA
transfers don't work properly in R5 SPL (with caches enabled) where the
core is not in coherency domain.
dma: ti: k3-udma: Query DMA channels allocated from Resource Manager
On K3 SoCs, DMA channels are shared across multiple entities, therefore
U-Boot DMA driver needs to query resource range from centralised
resource management controller i.e SystemFirmware and use DMA channels
allocated for A72 host. Add support for the same.
Import few basic bitmap functions (bitmap_{weight,fill,set,clear,or}())
and their dependencies from Linux. These are required for upcoming DMA
resource allocation support for TI's K3 SoCs.
projects / u-boot.git / log