Syscon register is required in dts to select correct
PHY interface.
Fix error below:
Net: Failed to get syscon: -2
Signed-off-by: Ley Foon Tan <ley.foon.tan@intel.com>
spba-bus has a few nodes under it including the UART1 and
some ESPI buses. In order to use them in SPL, the
u-boot,dm-spl flag needs to be added to the spba-bus@2000000
container.
Signed-off-by: Adam Ford <aford173@gmail.com>
Currently the CPU frequency is incorrectly reported:
CPU: NXP i.MX8QXP RevB A35 at 147228 MHz
Fix this problem by using a direct call to the SCU firmware to
retrieve the Cortex A35 CPU frequency.
With this change applied the CPU frequency is displayed correctly:
CPU: NXP i.MX8QXP RevB A35 at 1200 MHz
Tested-by: Marcelo Macedo <marcelo.macedo@nxp.com>
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Tested-by: Andrejs Cainikovs <andrejs.cainikovs@netmodule.com>
Select CONFIG_DM_MMC=y in order to support MMC driver model.
This allows the MMC board related code to be removed.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Acked-by: Otavio Salvador <otavio@ossystems.com.br>
Import the device tree files from kernel 5.0-rc6 in preparation
for driver model conversion.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Acked-by: Otavio Salvador <otavio@ossystems.com.br>
Just add spaces around '=' sign for clarity.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Add startup time to LDO regulators of S2MPS11 PMIC on Odroid XU3/XU4/HC1
family of boards to be sure the voltage is proper before relying on the
regulator.
The datasheet for all the S2MPS1x family is inconsistent here and does
not specify unambiguously the value of ramp delay for LDO. It mentions
30 mV/us in one timing diagram but then omits it completely in LDO
regulator characteristics table (it is specified for bucks).
However the vendor kernels for Galaxy S5 and Odroid XU3 use values of 12
mV/us or 24 mV/us.
Without the ramp delay value the consumers do not wait for voltage
settle after changing it. Although the proper value of ramp delay for
LDOs is unknown, it seems safer to use at least some value from
reference kernel than to leave it unset.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Tested-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
The ADC block requires VDD supply to be on so provide one.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Tested-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
The bootrom seems to leave the D-cache in messed up state, make sure
the SPL disables it so it can not interfere with operation.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Chin Liang See <chin.liang.see@intel.com>
Cc: Dinh Nguyen <dinguyen@kernel.org>
Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Cc: Tien Fong Chee <tien.fong.chee@intel.com>
The values for the data and tag latency settings on the PL310 caches
controller is an (n-1). For example, the "arm,tag-latency" is specified
as <1 1 1>, so the values that should be written to register should be
0x000. And for the "arm,data-latency" specified as <2 1 1>, the register
value should be 0x010.
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
v2019.01 commit cbff9f80ce ("ARM: dts: rmobile: Sync Gen3 DTs with
Linux 4.19.6") made the sdhi/usb nodes available in r8a77965.dtsi.
Hence, remove the SDHI/USB nodes from r8a77965-u-boot.dtsi. This is
equivalent to partially reverting below v2019.01 commits:
- f529bc551b ("ARM: dts: rmobile: Extract USB nodes on M3N")
- 830b94f768 ("ARM: dts: rmobile: Extract SDHI nodes on M3N")
Duplicating the nodes from <soc>.dtsi to <soc>-u-boot.dtsi is obviously:
- not needed if no U-boot-specific changes are needed in those nodes.
- potentially dangerous/error-prone, since the duplicated properties
override the properties originally defined in <soc>.dtsi. One
possible consequence is that <soc>.dtsi is getting an update from
Linux, while <soc>-u-boot.dtsi stays unchanged. In this situation,
the obsolete property values from <soc>-u-boot.dtsi will take
precedence masking some of the <soc>.dtsi updates, potentially
leading to all kind of obscure issues.
Below is the dtdiff of r8a77965-salvator-x-u-boot.dtb (the only "user"
of r8a77965-u-boot.dtsi) before and after the patch (slightly
reformatted to avoid 'git am/apply' issues and to reduce the width).
What below output means is there is already a mismatch in some of
SDHI/USB nodes between r8a77965.dtsi and r8a77965-u-boot.dtsi. Since no
U-Boot customization is needed in SDHI/USB DT nodes, get rid of them in
r8a77965-u-boot.dtsi.
$> dtdiff before-r8a77965-salvator-x-u-boot.dtb \
after-r8a77965-salvator-x-u-boot.dtb
--- /dev/fd/63 2019-03-09 12:57:40.877963983 +0100
+++ /dev/fd/62 2019-03-09 12:57:40.877963983 +0100
@@ -1471,7 +1471,7 @@
bus-width = <0x4>;
cd-gpios = <0x51 0xc 0x1>;
clocks = <0x6 0x1 0x13a>;
- compatible = "renesas,sdhi-r8a77965";
+ compatible = "renesas,sdhi-r8a77965", "renesas,rcar-gen3-sdhi";
interrupts = <0x0 0xa5 0x4>;
max-frequency = <0xc65d400>;
pinctrl-0 = <0x4d>;
@@ -1492,7 +1492,7 @@
sd@ee120000 {
clocks = <0x6 0x1 0x139>;
- compatible = "renesas,sdhi-r8a77965";
+ compatible = "renesas,sdhi-r8a77965", "renesas,rcar-gen3-sdhi";
interrupts = <0x0 0xa6 0x4>;
max-frequency = <0xbebc200>;
power-domains = <0x1 0x20>;
@@ -1504,7 +1504,7 @@
sd@ee140000 {
bus-width = <0x8>;
clocks = <0x6 0x1 0x138>;
- compatible = "renesas,sdhi-r8a77965";
+ compatible = "renesas,sdhi-r8a77965", "renesas,rcar-gen3-sdhi";
fixed-emmc-driver-type = <0x1>;
interrupts = <0x0 0xa7 0x4>;
max-frequency = <0xbebc200>;
@@ -1526,7 +1526,7 @@
bus-width = <0x4>;
cd-gpios = <0x5a 0xf 0x1>;
clocks = <0x6 0x1 0x137>;
- compatible = "renesas,sdhi-r8a77965";
+ compatible = "renesas,sdhi-r8a77965", "renesas,rcar-gen3-sdhi";
interrupts = <0x0 0xa8 0x4>;
max-frequency = <0xc65d400>;
pinctrl-0 = <0x56>;
@@ -1868,14 +1868,14 @@
usb-phy@ee0a0200 {
#phy-cells = <0x0>;
- clocks = <0x6 0x1 0x2be>;
+ clocks = <0x6 0x1 0x2bf>;
compatible = "renesas,usb2-phy-r8a77965", "renesas,rcar-gen3-usb2-phy";
phandle = <0x47>;
pinctrl-0 = <0x4c>;
pinctrl-names = "default";
power-domains = <0x1 0x20>;
reg = <0x0 0xee0a0200 0x0 0x700>;
- resets = <0x6 0x2be>;
+ resets = <0x6 0x2bf>;
status = "okay";
};
Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
U-Boot currently uses Gen2 QSPI in 1-bit mode, enforce it until
we can do better using the new SPI NOR framework.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
sec_firmware reserves JR3 for it's own usage and deletes the JR3 node
from the device tree. This causes this warning to be issued when doing
the device tree fixup:
WARNING could not find node fsl,sec-v4.0-job-ring: FDT_ERR_NOTFOUND.
Fix it by excluding the device tree fixup for the JR reserved by
sec_firmware.
Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
Reviewed-by: Horia Geanta <horia.geanta@nxp.com>
Reviewed-by: Bharat Bhushan <bharat.bhushan@nxp.com>
Reviewed-by: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
The SEC QI ICID setup in the QIIC_LS register is actually an offset
that is being added to the ICID coming from the qman portal. Setting
it with a non-zero value breaks SMMU setup as the resulting ICID is
not known. On top of that, the SEC QI ICID must match the qman portal
ICIDs in order to share the isolation context.
Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
Reviewed-by: Horia Geanta <horia.geanta@nxp.com>
Reviewed-by: Bharat Bhushan <bharat.bhushan@nxp.com>
Reviewed-by: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
The loop implemented in the code is supposed to check whether the
PL310 operation register has any bit from the mask set. Currently,
the code checks whether the PL310 operation register has any bit
set AND whether the mask is non-zero, which is incorrect. Fix the
conditional.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Dalon Westergreen <dwesterg@gmail.com>
Cc: Dinh Nguyen <dinguyen@kernel.org>
Cc: Tom Rini <trini@konsulko.com>
Fixes: 93bc21930a ("armv7: add PL310 support to u-boot")
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Dinh Nguyen <dinguyen@kernel.org>
Imply all SoCs supported by a given board. This allows building single
U-Boot binary for boards which can have multiple SoCs.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Imply preferred pin control driver per SoC, no functional change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
On SoCFPGA Gen5 systems, it can rarely happen that a reboot from Linux
will result in stale data in PL310 L2 cache controller. Even if the L2
cache controller is disabled via the CTRL register CTRL_EN bit, those
data can interfere with operation of devices using DMA, like e.g. the
DWMMC controller. This can in turn cause e.g. SPL to fail reading data
from SD/MMC.
The obvious solution here would be to fully reset the L2 cache controller
via the reset manager MPUMODRST L2 bit, however this causes bus hang even
if executed entirely from L1 I-cache to avoid generating any bus traffic
through the L2 cache controller.
This patch thus configures and enables the L2 cache controller very early
in the SPL boot process, clears the L2 cache and disables the L2 cache
controller again.
The reason for doing it in SPL is because we need to avoid accessing any
of the potentially stale data in the L2 cache, and we are certain any of
the stale data will be below the OCRAM address range. To further reduce
bus traffic during the L2 cache invalidation, we enable L1 I-cache and
run the invalidation code entirely out of the L1 I-cache.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Dalon Westergreen <dwesterg@gmail.com>
Cc: Dinh Nguyen <dinguyen@kernel.org>
Configure the PL310 tag and data latency registers, which slightly
improves performance and aligns the behavior with Linux.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Dalon Westergreen <dwesterg@gmail.com>
Cc: Dinh Nguyen <dinguyen@kernel.org>
The loop implemented in the code is supposed to check whether the
PL310 operation register has any bit from the mask set. Currently,
the code checks whether the PL310 operation register has any bit
set AND whether the mask is non-zero, which is incorrect. Fix the
conditional.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Dalon Westergreen <dwesterg@gmail.com>
Cc: Dinh Nguyen <dinguyen@kernel.org>
Cc: Tom Rini <trini@konsulko.com>
Fixes: 93bc21930a ("armv7: add PL310 support to u-boot")
This patch enables UMS on the nyan devices like the nyan-big.
A patch like this has been sent in by Stephen Warren some time ago for
other tegra devices: commit e6607cffef.
But the nyan devices never received that functionality.
Signed-off-by: Tristan Bastian <tristan-c.bastian@gmx.de>
Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Internal keyboard of nyan-big is only working when cold booting by pressing [reload/refresh]+[power] button.
With this patch keyboard is working by only pressing [power] button.
Signed-off-by: Tristan Bastian <tristan-c.bastian@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
- Switch to using the omap3-u-boot.dtsi file for needed properties.
- Remove a few SPL features to free up more SRAM space.
- Switch CONFIG_SYS_TEXT_BASE to the normal default, we don't need to
worry about X-Loader at this point anymore.
- A few related updates to SPL options as part of switching to DM SPL.
Signed-off-by: Tom Rini <trini@konsulko.com>
Tested-by: Derald D. Woods <woods.technical@gmail.com>
With the generic omap3-u-boot.dtsi file available, this patch
increased the memory of the various incarnations of the omap3_logic
board, and points their respective u-boot.dtsi files to the newly
created generic one, and removes the PLATDATA from the board file.
These are all done at once because the're all utilizing the same
omap3logic.c board file.
Signed-off-by: Adam Ford <aford173@gmail.com>
Create generic omap3-u-boot.dtsi file that omap3 based boards
can include to generate device tree in SPL for booting MLO.
Credit should go to Tom Rini.
Signed-off-by: Adam Ford <aford173@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Tested-by: Derald D. Woods <woods.technical@gmail.com>
This commit converts the brxre1 board to DM,
for this we have todo following things:
- add a devicetree-file for this board
- drop all obsolete settings from board header-file
- use dm_i2c_xxx calls for read/write to the resetcontroller
- request gpios before operate them
Serues-cc: trini@konsulko.com
Signed-off-by: Hannes Schmelzer <hannes.schmelzer@br-automation.com>
remove SCSI and SCSI_AHCI configs for ls1043ardb due to no sata interface
support.
this changed is to fixed the ls1043ardb compile warning as fallows:
===================== WARNING ======================
This board does not use CONFIG_DM_SCSI. Please update
the storage controller to use CONFIG_DM_SCSI 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.
====================================================
Signed-off-by: Peng Ma <peng.ma@nxp.com>
[PK: reword the patch subject]
Reviewed-by: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
Moves FSL_TZASC_400 and FSL_TZPC_BP147 configs to Kconfig
for LS1088A and LS2088A platforms.
Signed-off-by: Rajesh Bhagat <rajesh.bhagat@nxp.com>
Reviewed-by: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
LX2160AQDS is a development board that supports LX2160A
family SoCs. This patch add base support for this board.
Signed-off-by: Wasim Khan <wasim.khan@nxp.com>
Signed-off-by: Sriram Dash <sriram.dash@nxp.com>
Signed-off-by: Pankaj Bansal <pankaj.bansal@nxp.com>
Signed-off-by: Udit Agarwal <udit.agarwal@nxp.com>
[PK: Sqaush patch for "secure boot defconfig" & add maintainer]
Signed-off-by: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
some dpmacs in armv8a based freescale layerscape SOCs can be
configured via both serdes(sgmii, xfi, xlaui etc) bits and via
EC*_PMUX(rgmii) bits in RCW.
e.g. dpmac 17 and 18 in LX2160A can be configured as SGMII from
serdes bits and as RGMII via EC1_PMUX/EC2_PMUX bits
Now if a dpmac is enabled by serdes bits then it takes precedence
over EC*_PMUX bits. i.e. in LX2160A if we select serdes protocol
that configures dpmac17 as SGMII and set the EC1_PMUX as RGMII,
then the dpmac is SGMII and not RGMII.
Therefore, move the fsl_rgmii_init after fsl_serdes_init. in
fsl_rgmii_init function of SOC, we will check if the dpmac is enabled
or not? if it is (fsl_serdes_init has already enabled the dpmac), then
don't enable it.
Signed-off-by: Pankaj Bansal <pankaj.bansal@nxp.com>
Reviewed-by: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
Add code to initial ethernet interface arrays
with corresponding dpmac-id values in serdes_init function
for LX2160A.
Signed-off-by: Priyanka Jain <priyanka.jain@nxp.com>
Reviewed-by: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
As per hardware documentation,
CONFIG_SYS_FSL_PEBUF_BASE for lx2160a is 0x1c00000000
Signed-off-by: Priyanka Jain <priyanka.jain@nxp.com>
Reviewed-by: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
The 'dwmac_socfpga' ETH driver can now get the MACs out of reset
via the socfpga reset driver and can set PHY mode via syscon.
This means we can now remove the ad-hoc code to do this from
arch/arm/mach-socfpga.
Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
As the H5 is pin compatible with the H3, vendors tend to upgrade their
existing H3 products with an H5 SoC swap. This is the case with the
Bananapi M2+ H5.
Add the following to support it:
- device tree file: synced from Linux v5.0-rc1,
- defconfig: copy of bananapi_m2_plus_h3_defconfig with only SoC
family and default device tree file name changed
- MAINTAINERS entry
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Reviewed-by: Jagan Teki <jagan@openedev.com>
As of commit aa8fee415f46 ("ARM: dts: sun8i: h3: Split out
non-SoC-specific parts of Bananapi M2 Plus") in the Linux kernel, the
device tree for the Bananapi M2+ has been split into a common dtsi file,
and an SoC-specific board device tree file that includes both the shared
dtsi file and the soc dtsi file. This was done to support both the H3
and H5 variants of the same board. This is similar to what was done for
the Libre Computer ALL-H3-CC in U-boot commit d7b17f1c24 ("sunxi: Split
out common board design for ALL-H3-CC device tree").
The newly split files are directly synced from Linux tag v5.0-rc1.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Reviewed-by: Jagan Teki <jagan@openedev.com>
