The IMX8M based Venice boards all have device-tree fec nodes that
use proper dt with a phy-handle pointing to a phy with reg assigned
to the proper phy address.
There is no need to keep using the CONFIG_FEC_MXC_PHYADDR hack when
a proper dt is used - remove it.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
All i.MX8M needs TZASC ID SWAP set and locked, no need the check to
waste cpu cycles.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Andrey Zhizhikin <andrey.zhizhikin@leica-geosystems.com>
To i.MX8, M core stack is pre-coded in source code, so need to get it
before kicking M core. The stack pointer is stored in the first word of
the first PT_LOAD section __isr_vector. So use a num to index the
section loading.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
I was trying to employ lpddr4_mr_read() to something similar to what
the imx8mm-cl-iot-gate board is doing for auto-detecting the RAM
type. However, the version in drivers/ddr/imx/imx8m/ddrphy_utils.c
differs from the private one used by that board in how it extracts the
byte value, and I was only getting zeroes. Adding a bit of debug
printf'ing gives me
tmp = 0x00ffff00
tmp = 0x00070700
tmp = 0x00000000
tmp = 0x00101000
and indeed I was expecting a (combined) value of 0xff070010 (0xff
being Manufacturer ID for Micron). I can't find any documentation that
says how the values are supposed to be read, but clearly the iot-gate
definition is the right one, both for its use case as well as my
imx8mp-based board.
So lift the private definition of lpddr4_mr_read() from the
imx8mm-cl-iot-gate board code to ddrphy_utils.c, and add a declaration
in the ddr.h header where e.g. get_trained_CDD() is already declared.
This has only been compile-tested for the imx8mm-cl-iot-gate
board (since I don't have the hardware), but since I've merely moved
its definition of lpddr4_mr_read(), I'd be surprised if it changed
anything for that board.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Tested-by: Ying-Chun Liu (PaulLiu) <paul.liu@linaro.org>
Reviewed-by: Fabio Estevam <festevam@denx.de>
Introduce helper macro UART_BASE_ADDR(n), which returns Nth UART base
address. Convert all board configurations to this new macro. This is the
first step toward switching CONFIG_MXC_UART_BASE to Kconfig. This is a
clean up, no functional change.
The new macro contains compile-time test to verify N is in suitable
range. The test works such that it multiplies constant N by constant
double-negation of size of a non-empty structure, i.e. it multiplies
constant N by constant 1 in each successful compilation case.
The non-empty structure may contain C11 _Static_assert(), make use of
this and place the kernel variant of static assert in there, so that
it performs the compile-time check for N in the correct range. Note
that it is not possible to directly use static_assert in compound
statements, hence this convoluted construct.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <festevam@denx.de>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Stefano Babic <sbabic@denx.de>
Introduce helper macro UART_BASE_ADDR(n), which returns Nth UART base
address. Convert all board configurations to this new macro. This is the
first step toward switching CONFIG_MXC_UART_BASE to Kconfig. This is a
clean up, no functional change.
The new macro contains compile-time test to verify N is in suitable
range. The test works such that it multiplies constant N by constant
double-negation of size of a non-empty structure, i.e. it multiplies
constant N by constant 1 in each successful compilation case.
The non-empty structure may contain C11 _Static_assert(), make use of
this and place the kernel variant of static assert in there, so that
it performs the compile-time check for N in the correct range. Note
that it is not possible to directly use static_assert in compound
statements, hence this convoluted construct.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <festevam@denx.de>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Stefano Babic <sbabic@denx.de>
Introduce helper macro UART_BASE_ADDR(n), which returns Nth UART base
address. Convert all board configurations to this new macro. This is the
first step toward switching CONFIG_MXC_UART_BASE to Kconfig. This is a
clean up, no functional change.
The new macro contains compile-time test to verify N is in suitable
range. The test works such that it multiplies constant N by constant
double-negation of size of a non-empty structure, i.e. it multiplies
constant N by constant 1 in each successful compilation case.
The non-empty structure may contain C11 _Static_assert(), make use of
this and place the kernel variant of static assert in there, so that
it performs the compile-time check for N in the correct range. Note
that it is not possible to directly use static_assert in compound
statements, hence this convoluted construct.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <festevam@denx.de>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Stefano Babic <sbabic@denx.de>
The I2C2 has SMBus device SMSC USB2514Bi connected to it, the device is
capable of up to 100 kHz operation. Reduce the bus frequency to 100 kHz
to guarantee this I2C device can work correctly.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <festevam@denx.de>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Stefano Babic <sbabic@denx.de>
When trying to boot via USB on i.MX8MN it is necessary to specify
the U-Boot environment location, otherwise the boot process simply
hangs.
Specify the environment location when booting from USB.
Tested on a imx8mn-evk.
Suggested-by: Michael Nazzareno Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Fabio Estevam <festevam@denx.de>
Tested-By: Tim Harvey <tharvey@gateworks.com>
RNG Hardware error is reported due to incorrect entropy delay
rng self test are run to determine the correct ent_dly.
test is executed with different voltage and temperature to identify the
worst case value for ent_dly. after adding a margin value(1000),
ent_dly should be at least 12000.
Signed-off-by: Gaurav Jain <gaurav.jain@nxp.com>
Reviewed-by: Fabio Estevam <festevam@denx.de>
Because mxs_nand_spl driver does not support DM, to use the minimum ECC
layout, it needs to handle the CONFIG_NAND_MXS_USE_MINIMUM_ECC.
Signed-off-by: Ye Li <ye.li@nxp.com>
Reviewed-by: Han Xu <han.xu@nxp.com>
Waiting for SR_BUSY bit when receiving a new command is not needed.
SR_BUSY bit is already managed in the previous command treatment.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Currently, SR_TCF flag is checked in case there is data, this criteria
is not correct.
SR_TCF flags is set when programmed number of bytes have been transferred
to the memory device ("bytes" comprised command and data send to the
SPI device).
So even if there is no data, we must check SR_TCF flag.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
The Avenger96 board comes in multiple regulator configurations.
- rev.100 or rev.200 have Buck3 preconfigured to 3V3 operation on
boot and contains extra Enpirion EP53A8LQI DCDC converter which
supplies the IO. Reduce Buck3 voltage to 2V9 to not waste power.
- rev.200L have Buck3 preconfigured to 1V8 operation and have no
Enpirion EP53A8LQI DCDC anymore, the IO is supplied from Buck3.
Configure the Buck3 voltage on this board per PMIC NVM settings and
update buck3 voltage limits in DT passed to OS before booting OS to
prevent potential hardware damage.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Patrice Chotard <patrice.chotard@foss.st.com>
Cc: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
BTN_MISC looks like the most reasonable option for this button.
Button is used by firmware to indicate (after reset, power up) that user
wants to do firmware upgrade via firmware update utility.
For bootloader or OS is this just user button which is worth to have it
mapped.
Also button can be used as a wakeup source and pressing it for more time
can generate more chars that's why also adding wakeup-source and autorepeat
properties.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Link: https://lore.kernel.org/r/7f6d627473632c3c3036ec9f6aaa36e00f4615e2.1652262769.git.michal.simek@amd.com
SGMII requires phy to be configured. The support for this has been added to
Linux and U-Boot already that's why also describe the phy via DT. Clock is
coming from si5332 chip (output 1) 125MHz which is only one GT line use on
this board.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/8ad8d0c2fc9690cc90f95feddf87b0e94a685a43.1652262769.git.michal.simek@amd.com
OPP table name now should start with "opp-table" and OPP entries
shouldn't contain commas and @ signs in accordance to the new schema
requirement.
The same change was done in Linux by commit c6d4a8977598 ("ARM: tegra:
Rename CPU and EMC OPP table device-tree nodes"), commit ffbe853a3f5a
("ARM: dts: sunxi: Fix OPPs node name") or commit b7072cc5704d ("arm64:
dts: qcom: qcs404: Rename CPU and CPR OPP tables").
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/a1176349448df35127dbac15c1eeb2229505bae7.1652262769.git.michal.simek@amd.com
This patch fixes the DP audio and video PLL configurations for the zynqmp-sm-k26-revA som.
The Linux DP driver expects the DP to be using the following PLL config:
- DP video PLL should use the VPLL (0x0)
- DP audio PLL should use the RPLL (0x3)
- DP system time clock PLL should use RPLL (0x3)
Register 0xFD1A0070 configures the DP video PLL.
Register 0xFD1A0074 configures the DP audio PLL.
Register 0xFD1A007C configures the DP system time clock PLL.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/fa7e9abc419c9d7648405d1c62367dbe701d09b8.1652709736.git.michal.simek@amd.com
Observing psgtr pll timeouts with some usb hubs and devices behind it.
Increase timeout to 10ms to take care of it.
Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma@xilinx.com>
Link: https://lore.kernel.org/r/20220510131234.2650-1-ashok.reddy.soma@xilinx.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
In all the ZynqMP boards dts files tx-buswidth is by default set to 1. Due
to this the framework only issues 1-1-1 write commands to the GQSPI driver.
But the GQSPI controller is capable of handling 1-4-4 write commands, so
updated the tx-buswidth to 4 in ZynqMP boards dts files. This would enable
the spi-nor framework to issue 1-4-4 write commands instead of 1-1-1. This
will increase the tx data transfer rate, as now the tx data will be
transferred on four lines instead on single line.
Signed-off-by: Amit Kumar Mahapatra <amit.kumar-mahapatra@xilinx.com>
Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/ad61199f55e5e00f29de6206d9d1872a52a7657e.1652193179.git.michal.simek@amd.com
This patch fixes two issues in the set_r5_reset function.
1. When in split mode, the lpd_amba_rst bit should only be set when
both r5 cpu cores are in reset. Otherwise, if one r5 core is still
running, setting the lpd_amba_rst bit will cause an error for the
running core. The set_r5_reset function has been modified to check
if the other r5 core is still running before setting the lpd_amba_rst
bit.
2. The cpu_disable function was always assuming that the r5 cores
are in split mode when resetting either core 4 or 5. This is
incorrect for lockstep functionality. This patch adds a function
check_r5_mode to handle the cpu_disable function correctly for
the r5 cores by checking the mode and handling the reset appropriately.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/d99cbd7f2394ac055ef27457298f554ff0747ba7.1651648344.git.michal.simek@amd.com
This patch fixes the DP audio and video PLL configurations for the
zynqmp-zcu102-revA evaluation board.
The Linux DP driver expects the DP to be using the following PLL config:
- DP video PLL should use the VPLL (0x0)
- DP audio PLL should use the RPLL (0x3)
Register 0xFD1A0070 configures the DP video PLL.
Register 0xFD1A0074 configures the DP audio PLL.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/b2eb87758e0cd4844e1754da8c58fce58d9cf683.1651740949.git.michal.simek@amd.com
This patch fixes the DP audio and video PLL configurations
for the zynqmp-zcu106-revA evaluation board.
The Linux DP driver expects the DP to be using the following PLL config:
- DP video PLL should use the VPLL (0x0)
- DP audio PLL should use the RPLL (0x3)
Register 0xFD1A0070 configures the DP video PLL.
Register 0xFD1A0074 configures the DP audio PLL.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/62538b4a04dee28a6fc8ac5b85f8c845a5a76aa4.1651740988.git.michal.simek@amd.com
This patch fixes the DP audio and video PLL configurations for the zynqmp-zcu106-rev1.0 evaluation board.
The Linux DP driver expects the DP to be using the following PLL config:
- DP video PLL should use the VPLL (0x0)
- DP audio PLL should use the RPLL (0x3)
Register 0xFD1A0070 configures the DP video PLL.
Register 0xFD1A0074 configures the DP audio PLL.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/ae42ad6185418713a473660c8d15903299af7764.1652192319.git.michal.simek@amd.com
Currently, pinctrl drivers only get probed if pinconf is actually being
used, however on SoC-s like Armada 3720 pinctrl driver is a also the GPIO
driver.
So, if the pinctrl driver doesn't get probed GPIO-s won't get registered
and thus they cannot be used.
This is a problem on the Methode eDPU as it just uses SB pins as GPIO-s
and without them being registered networking won't work as it only has
one SFP slot and the TX disable GPIO is on the SB controller.
So, probe the pinctrl drivers using DM_FLAG_PROBE_AFTER_BIND like LED
uclass does.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Reviewed-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
uDPU relies on using fixed-phy for the SFP support, and since the
fixed-phy parsing was moved to the generic driver instead of mvneta
networking stopped working on uDPU with:
uDPU>> dhcp
dm_eth_phy_connect failed
This is due to the conversion commit not enabling fixed-phy support
in defconfig like it did for other boards.
Fixes: 77fcf3cf12 ("net: mvneta: Convert to use PHY_FIXED for fixed-link")
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Reviewed-by: Stefan Roese <sr@denx.de>
UART base address is located in internal registers.
Internal registers for 32-bit mvebu boards in SPL are at address 0xd0000000
and in proper U-Boot at address 0xf1000000.
Fix DEBUG_UART_BASE option for all 32-bit mvebu boards.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Internal registers in SPL are at address 0xd0000000 and in proper U-Boot at
address 0xf1000000. UART base address is located in internal registers.
Fix DEBUG_UART_BASE option to correct value for both SPL and proper U-Boot.
This change fixes hangup of proper U-Boot when it is trying to print
something via debug UART.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Use CONFIG_VAL(DEBUG_UART_BASE) instead of CONFIG_DEBUG_UART_BASE, so
proper config value (CONFIG_DEBUG_UART_BASE or CONFIG_SPL_DEBUG_UART_BASE)
is used based on building target.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
TPL_DEBUG_UART_BASE is same as DEBUG_UART_BASE, but applies only for TPL.
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Stefan Roese <sr@denx.de>
SPL_DEBUG_UART_BASE is same as DEBUG_UART_BASE, but applies only for SPL.
In some cases base address of UART is different in SPL and proper U-Boot.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Moving of internal registers from INTREG_BASE_ADDR_REG to SOC_REGS_PHY_BASE
needs to be done very early, prior calling any function which may touch
internal registers, like debug_uart_init().
So do it earlier in arch_very_early_init() instead of arch_cpu_init().
Movement is done in proper U-Boot, not in SPL. SPL may return to bootrom
and bootrom requires internal registers at (old) expected location.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
When this option is set then ARM _main() function would call
arch_very_early_init() function at the beginning. It would be before
calling any other functions like debug_uart_init() and also before
initializing C runtime environment.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
