[PATCH 2/2] ARM: Layerscape: Add LS1021A IOT board support
Sascha Hauer
sha at pengutronix.de
Fri Feb 10 04:23:06 PST 2023
On Wed, Feb 08, 2023 at 01:26:30PM +0000, Renaud Barbier wrote:
> The LS1021A-IOR is a NXP reference board.
> Currently supported:
>
> - DDR3 RAM fixed settings
> - UART
> - SPI boot
> - One SGMII network ports
>
> Signed-off-by: Renaud Barbier <renaud.barbier at abaco.com>
> ---
> arch/arm/boards/Makefile | 1 +
> arch/arm/boards/ls1021aiot/Makefile | 3 +
> arch/arm/boards/ls1021aiot/board.c | 83 +++++++
> arch/arm/boards/ls1021aiot/lowlevel.c | 121 ++++++++++
> arch/arm/boards/ls1021aiot/ls102xa_pbi.cfg | 11 +
> .../boards/ls1021aiot/ls102xa_rcw_sd_qspi.cfg | 8 +
> arch/arm/boards/ls1021aiot/start.S | 11 +
> arch/arm/configs/layerscape_v7_defconfig | 100 +++++++++
> arch/arm/dts/fsl-ls1021a-iot.dts | 124 ++++++++++
> arch/arm/lib32/Makefile | 1 +
> arch/arm/lib32/pbl.c | 21 ++
> drivers/net/Kconfig | 2 +-
> drivers/net/gianfar.c | 211 ++++++++++++++++--
> drivers/net/gianfar.h | 16 +-
> 14 files changed, 690 insertions(+), 23 deletions(-)
> create mode 100644 arch/arm/boards/ls1021aiot/Makefile
> create mode 100644 arch/arm/boards/ls1021aiot/board.c
> create mode 100644 arch/arm/boards/ls1021aiot/lowlevel.c
> create mode 100644 arch/arm/boards/ls1021aiot/ls102xa_pbi.cfg
> create mode 100644 arch/arm/boards/ls1021aiot/ls102xa_rcw_sd_qspi.cfg
> create mode 100644 arch/arm/boards/ls1021aiot/start.S
> create mode 100644 arch/arm/configs/layerscape_v7_defconfig
> create mode 100644 arch/arm/dts/fsl-ls1021a-iot.dts
> create mode 100644 arch/arm/lib32/pbl.c
>
> diff --git a/arch/arm/boards/Makefile b/arch/arm/boards/Makefile
> index f47aea6602..b148c8c1c1 100644
> --- a/arch/arm/boards/Makefile
> +++ b/arch/arm/boards/Makefile
> @@ -192,6 +192,7 @@ obj-$(CONFIG_MACH_ZII_IMX7D_DEV) += zii-imx7d-dev/
> obj-$(CONFIG_MACH_WAGO_PFC_AM35XX) += wago-pfc-am35xx/
> obj-$(CONFIG_MACH_LS1046ARDB) += ls1046ardb/
> obj-$(CONFIG_MACH_TQMLS1046A) += tqmls1046a/
> +obj-$(CONFIG_MACH_LS1021AIOT) += ls1021aiot/
> obj-$(CONFIG_MACH_MNT_REFORM) += mnt-reform/
> obj-$(CONFIG_MACH_SKOV_ARM9CPU) += skov-arm9cpu/
> obj-$(CONFIG_MACH_RK3568_EVB) += rockchip-rk3568-evb/
> diff --git a/arch/arm/boards/ls1021aiot/Makefile b/arch/arm/boards/ls1021aiot/Makefile
> new file mode 100644
> index 0000000000..df69ce814b
> --- /dev/null
> +++ b/arch/arm/boards/ls1021aiot/Makefile
> @@ -0,0 +1,3 @@
> +lwl-y += lowlevel.o
> +obj-y += board.o
> +lwl-y += start.o
> diff --git a/arch/arm/boards/ls1021aiot/board.c b/arch/arm/boards/ls1021aiot/board.c
> new file mode 100644
> index 0000000000..8f99f1a996
> --- /dev/null
> +++ b/arch/arm/boards/ls1021aiot/board.c
> @@ -0,0 +1,83 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +// SPDX-FileCopyrightText: (C) Copyright 2021 Ametek Inc.
> +// SPDX-FileCopyrightText: 2021 Renaud Barbier <renaud.barbier at abaco.com>,
> +
> +#include <common.h>
> +#include <init.h>
> +#include <bbu.h>
> +#include <net.h>
> +#include <crc.h>
> +#include <fs.h>
> +#include <io.h>
> +#include <envfs.h>
> +#include <libfile.h>
> +#include <asm/memory.h>
> +#include <linux/sizes.h>
> +#include <linux/clk.h>
> +#include <linux/clkdev.h>
> +#include <asm/system.h>
> +#include <mach/layerscape.h>
> +#include <of_address.h>
> +#include <soc/fsl/immap_ls102xa.h>
> +
> +
> +/* Currently 1000FD is not working. Below is a bit of guess work
> + * from reading MMD3/MMD7 of the AR8033
> + */
> +static int phy_fixup(struct phy_device *phydev)
> +{
> + unsigned short val;
> + int advertise = SUPPORTED_1000baseT_Full | SUPPORTED_1000baseT_Half;
> +
> + phydev->advertising &= ~advertise;
> +
> + /* Ar8031 phy SmartEEE feature cause link status generates glitch,
> + * which cause ethernet link down/up issue, so disable SmartEEE
> + */
> + phy_write(phydev, 0xd, 0x3);
> + phy_write(phydev, 0xe, 0x805d);
> + phy_write(phydev, 0xd, 0x4003);
> + val = phy_read(phydev, 0xe);
> + val &= ~(0x1 << 8);
> + phy_write(phydev, 0xe, val);
> +
> + /* Use XTAL */
> + phy_write(phydev, 0xd, 0x7);
> + phy_write(phydev, 0xe, 0x8016);
> + phy_write(phydev, 0xd, 0x4007);
> + val = phy_read(phydev, 0xe);
> + val &= 0xffe3;
> + phy_write(phydev, 0xe, val);
> +
> + return 0;
> +}
We have a phy driver for the AR8033. Can you use it instead of putting
this into board code?
> +
> +static int iot_mem_init(void)
> +{
> + if (!of_machine_is_compatible("fsl,ls1021a"))
> + return 0;
> +
> + arm_add_mem_device("ram0", 0x80000000, 0x40000000);
> +
> + return 0;
> +}
> +mem_initcall(iot_mem_init);
> +
> +#define PHY_ID_AR8031 0x004dd074
> +static int iot_postcore_init(void)
> +{
> + struct ccsr_scfg *scfg = IOMEM(LS102XA_SCFG_ADDR);
> +
> + if (!of_machine_is_compatible("fsl,ls1021a"))
> + return 0;
> +
> + /* clear BD & FR bits for BE BD's and frame data */
> + clrbits_be32(&scfg->etsecdmamcr, SCFG_ETSECDMAMCR_LE_BD_FR);
> + out_be32(&scfg->etsecmcr, SCFG_ETSECCMCR_GE2_CLK125);
> +
> + phy_register_fixup_for_uid(PHY_ID_AR8031, 0xffffffff, phy_fixup);
> +
> + return 0;
> +}
> +
> +coredevice_initcall(iot_postcore_init);
> +static struct fsl_ddr_controller ddrc[] = {
> + {
> + .memctl_opts.ddrtype = SDRAM_TYPE_DDR3,
> + .base = IOMEM(LS102XA_DDR_ADDR),
> + .ddr_freq = LS1021A_DDR_FREQ,
> + .erratum_A009942 = 1,
> + .chip_selects_per_ctrl = 4,
> + .fsl_ddr_config_reg = {
> + .cs[0].bnds = 0x008000bf,
> + .cs[0].config = 0x80014302,
> + .cs[0].config_2 = 0x00000000,
> + .cs[1].bnds = 0x00000000,
> + .cs[1].config = 0x00000000,
> + .cs[1].config_2 = 0x00000000,
> + .cs[2].bnds = 0x00000000,
> + .cs[2].config = 0x00000000,
> + .cs[2].config_2 = 0x00000000,
> + .cs[3].bnds = 0x00000000,
> + .cs[3].config = 0x00000000,
> + .cs[3].config_2 = 0x00000000,
> + .timing_cfg_3 = 0x010e1000,
> + .timing_cfg_0 = 0x50550004,
> + .timing_cfg_1 = 0xbcb38c56,
> + .timing_cfg_2 = 0x0040d120,
> + .ddr_sdram_cfg = 0x470c0008,
> + .ddr_sdram_cfg_2 = 0x00401010,
> + .ddr_sdram_mode = 0x00061c60,
> + .ddr_sdram_mode_2 = 0x00180000,
> + .ddr_sdram_interval = 0x18600618,
> + .ddr_data_init = 0xDEADBEEF,
> + .ddr_sdram_clk_cntl = 0x02000000,
> + .ddr_init_addr = 0x00000000,
> + .ddr_init_ext_addr = 0x00000000,
> + .timing_cfg_4 = 0x00000001,
> + .timing_cfg_5 = 0x03401400,
> + .ddr_zq_cntl = 0x89080600,
> + .ddr_wrlvl_cntl = 0x8655f605,
> + .ddr_wrlvl_cntl_2 = 0x05060607,
> + .ddr_wrlvl_cntl_3 = 0x05050505,
> + .ddr_sr_cntr = 0x00000000,
> + .ddr_sdram_rcw_1 = 0x00000000,
> + .ddr_sdram_rcw_2 = 0x00000000,
> + .ddr_sdram_rcw_3 = 0x00000000,
> + .ddr_cdr1 = 0x80040000,
> + .ddr_cdr2 = 0x000000C0,
> + .dq_map_0 = 0x00000000,
> + .dq_map_1 = 0x00000000,
> + .dq_map_2 = 0x00000000,
> + .dq_map_3 = 0x00000000,
> + .debug[28] = 0x00700046,
> + },
> + },
> +};
Indentation seems a bit broken here.
> +
> +extern char __dtb_fsl_ls1021a_iot_start[];
> +
> diff --git a/arch/arm/dts/fsl-ls1021a-iot.dts b/arch/arm/dts/fsl-ls1021a-iot.dts
> new file mode 100644
> index 0000000000..5d50829313
> --- /dev/null
> +++ b/arch/arm/dts/fsl-ls1021a-iot.dts
> @@ -0,0 +1,124 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Freescale ls1021a IOT board device tree source
> + *
> + * Copyright 2016 Freescale Semiconductor, Inc.
> + */
> +
> +/dts-v1/;
> +
> +#include <arm/ls1021a-iot.dts>
> +
> +/ {
> + model = "LS1021A IOT Board";
The upstream dts already has this.
> +&i2c1 {
> + status = "okay";
> + eeprom at 51 {
> + compatible = "atmel,24c512";
> + reg = <0x51>;
> + };
> +};
> +
> +/* I2C1 and I2C1 are connected due to Errata on rev1 board */
Should this be I2C1 and I2C2?
> +&i2c2 {
> + status = "disabled";
> +};
> +
> +&enet0 {
> + phy-handle = <&sgmii_phy2>;
> + phy-mode = "sgmii";
> + status = "disabled";
> +};
What's the point in modifying this node when the status is set to
disabled at the same time?
Upstream dts has phy-connection-type. Decide for one property
consistently.
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index 30de1f544c..19709b0163 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -189,7 +189,7 @@ config DRIVER_NET_FSL_FMAN
>
> config DRIVER_NET_GIANFAR
> bool "Gianfar Ethernet"
> - depends on ARCH_MPC85XX
> + depends on ARCH_MPC85XX || ARCH_LS102XA
> select PHYLIB
>
> config DRIVER_NET_KS8851_MLL
> diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
The changes to the network driver should be an extra patch, or better
multiple patches as there seem to be multiple types of changes squashed
together.
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
More information about the barebox
mailing list