Re: [U-Boot] [PATCH] image-fdt: reserve lmb for fdt
ping
Andy Yan 于2018年8月7日周二 下午7:43写道：
> Memory region for fdt should be reserved, or they
> may be allocated by other module via lmb_alloc.
> Then the fdt data will be destroy.
>
> We found a case on a board with 64MB DRAM like bellow:
>
> No ethernet found.
> Hit any key to stop autoboot: 0
> ANDROID: reboot reason: "recovery"
> FDT load addr 0x10f0 size 41 KiB
> Booting kernel at 0x2008000 with fdt at 2c8ac00...
>
> lmb_add base:0x58000 size:0x3fa8000
> lmb_add base:0x0 size:0x0
> lmb_reserve base:0x34ca2a0 size:0xb35d60
> Booting Android Image at 0x02008000 ...
> Kernel load addr 0x02008800 size 3808 KiB
> RAM disk load addr 0x1100 size 9000 KiB
> * fdt: cmdline image address = 0x02c8ac00
> Checking for 'FDT'/'FDT Image' at 02c8ac00
> * fdt: raw FDT blob
>Flattened Device Tree blob at 02c8ac00
>Booting using the fdt blob at 0x2c8ac00
>of_flat_tree at 0x02c8ac00 size 0x9d6d
>XIP Kernel Image ... OK
> do_bootm_states reserve: 0x2008800 -- 0x3b7c30
> lmb_reserve base:0x2008800 size:0x3b7c30
> no initrd_high
> env_get_bootm_size size:66748416(0x3fa8000) tmp:360448(0x58000)
> start:360448(0x58000)
>initrd_high = 0x03fa8000, copy_to_ram = 1
>Loading Ramdisk to 02c0, end 034c9d09 ... OK
> ERROR: image is not a fdt - must RESET the board to recover.
> FDT creation failed! hanging...### ERROR ### Please RESET the board ###
>
> Signed-off-by: Andy Yan
> ---
>
> common/image-fdt.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/common/image-fdt.c b/common/image-fdt.c
> index 9b41f16248..56f6d7e26b 100644
> --- a/common/image-fdt.c
> +++ b/common/image-fdt.c
> @@ -422,6 +422,7 @@ int boot_get_fdt(int flag, int argc, char * const
> argv[], uint8_t arch,
>
> *of_flat_tree = fdt_blob;
> *of_size = fdt_totalsize(fdt_blob);
> + lmb_reserve(>lmb, (ulong)*of_flat_tree, *of_size);
> debug(" of_flat_tree at 0x%08lx size 0x%08lx\n",
> (ulong)*of_flat_tree, *of_size);
>
> --
> 2.17.1
>
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] driver: net: fsl-mc: Memset MC reserve red memory before usage
Thanks York, > -Original Message- > From: York Sun > Sent: Friday, August 24, 2018 8:24 PM > To: Prabhakar Kushwaha ; u- > b...@lists.denx.de > Cc: joe.hershber...@ni.com; Ashish Kumar ; > cristian.sovai...@nxp.co > Subject: Re: [PATCH] driver: net: fsl-mc: Memset MC reserve red memory before > usage > > On 08/23/2018 08:13 PM, Prabhakar Kushwaha wrote: > > Hi York > > > >> -Original Message- > >> From: York Sun > >> Sent: Thursday, August 23, 2018 8:41 PM > >> To: Prabhakar Kushwaha ; u- > >> b...@lists.denx.de > >> Cc: joe.hershber...@ni.com; Ashish Kumar ; > >> cristian.sovai...@nxp.co > >> Subject: Re: [PATCH] driver: net: fsl-mc: Memset MC reserve red > >> memory before usage > >> > >> On 08/15/2018 11:49 PM, Prabhakar Kushwaha wrote: > >>> It is not necessary for MC memory to be always clean. It may have > >>> garbage value causing indeterministic behavior during MC > >>> initialization and run. > >>> > >>> So memset memory reserved for MC before any usage. > >> > >> Your commit message seems wrong. If it is not necessary to be clean, > >> why it causes problems? I guess you mean the memory needs to be clean. > >> > > > > Yes. You are right. > > Commit message should be memory needs to be clean before passing to > management complex. > > > > May I send v2 version for the same. > > > > You can either send v2 patch. Or if you don't have other update, I can fix the > commit message when merging. > I will send v2 of this patch as I recently found one issue after applying this patch. --pk ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] board: advantech: dms-ba16:: add the Q7 DualLite support
Change the dms-ba16 configurations to support both Q7 Dual/Quad and DualLite modules Add the DDR3L parameters support for the DualLite Signed-off-by: Ken Lin --- arch/arm/mach-imx/mx6/Kconfig | 1 - board/advantech/dms-ba16/Kconfig| 7 +++ board/advantech/dms-ba16/ddr-setup-dl.cfg | 39 ++ board/advantech/dms-ba16/dms-ba16_2g_dl.cfg | 23 board/advantech/dms-ba16/samsung-2g-dl.cfg | 58 + configs/dms-ba16-2g-dl_defconfig| 54 +++ 6 files changed, 181 insertions(+), 1 deletion(-) create mode 100644 board/advantech/dms-ba16/ddr-setup-dl.cfg create mode 100644 board/advantech/dms-ba16/dms-ba16_2g_dl.cfg create mode 100644 board/advantech/dms-ba16/samsung-2g-dl.cfg create mode 100644 configs/dms-ba16-2g-dl_defconfig diff --git a/arch/arm/mach-imx/mx6/Kconfig b/arch/arm/mach-imx/mx6/Kconfig index a2799c436e..e3784d00fa 100644 --- a/arch/arm/mach-imx/mx6/Kconfig +++ b/arch/arm/mach-imx/mx6/Kconfig @@ -102,7 +102,6 @@ choice config TARGET_ADVANTECH_DMS_BA16 bool "Advantech dms-ba16" select BOARD_LATE_INIT - select MX6Q imply CMD_SATA config TARGET_APALIS_IMX6 diff --git a/board/advantech/dms-ba16/Kconfig b/board/advantech/dms-ba16/Kconfig index f5d9f61f13..c61fbabb31 100644 --- a/board/advantech/dms-ba16/Kconfig +++ b/board/advantech/dms-ba16/Kconfig @@ -6,13 +6,20 @@ choice config SYS_DDR_1G bool "1GiB" + select MX6Q config SYS_DDR_2G bool "2GiB" + select MX6Q + +config SYS_DDR3L_2G + bool "2GiB" + select MX6DL endchoice config IMX_CONFIG + default "board/advantech/dms-ba16/dms-ba16_2g_dl.cfg" if SYS_DDR3L_2G default "board/advantech/dms-ba16/dms-ba16_2g.cfg" if SYS_DDR_2G default "board/advantech/dms-ba16/dms-ba16_1g.cfg" if SYS_DDR_1G diff --git a/board/advantech/dms-ba16/ddr-setup-dl.cfg b/board/advantech/dms-ba16/ddr-setup-dl.cfg new file mode 100644 index 00..7f567c3f12 --- /dev/null +++ b/board/advantech/dms-ba16/ddr-setup-dl.cfg @@ -0,0 +1,39 @@ +/* DDR IO */ +DATA 4, MX6_IOM_GRP_DDR_TYPE, 0x000c +DATA 4, MX6_IOM_GRP_DDRPKE, 0x +DATA 4, MX6_IOM_DRAM_SDCLK_0, 0x0030 +DATA 4, MX6_IOM_DRAM_SDCLK_1, 0x0030 +DATA 4, MX6_IOM_DRAM_CAS, 0x0030 +DATA 4, MX6_IOM_DRAM_RAS, 0x0030 +DATA 4, MX6_IOM_GRP_ADDDS,0x0030 +DATA 4, MX6_IOM_DRAM_RESET, 0x0030 +DATA 4, MX6_IOM_DRAM_SDBA2, 0x +DATA 4, MX6_IOM_DRAM_SDODT0, 0x0030 +DATA 4, MX6_IOM_DRAM_SDODT1, 0x0030 +DATA 4, MX6_IOM_GRP_CTLDS,0x0030 +DATA 4, MX6_IOM_DDRMODE_CTL, 0x0002 +DATA 4, MX6_IOM_DRAM_SDQS0, 0x0028 +DATA 4, MX6_IOM_DRAM_SDQS1, 0x0028 +DATA 4, MX6_IOM_DRAM_SDQS2, 0x0028 +DATA 4, MX6_IOM_DRAM_SDQS3, 0x0028 +DATA 4, MX6_IOM_DRAM_SDQS4, 0x0028 +DATA 4, MX6_IOM_DRAM_SDQS5, 0x0028 +DATA 4, MX6_IOM_DRAM_SDQS6, 0x0028 +DATA 4, MX6_IOM_DRAM_SDQS7, 0x0028 +DATA 4, MX6_IOM_GRP_DDRMODE, 0x0002 +DATA 4, MX6_IOM_GRP_B0DS, 0x0028 +DATA 4, MX6_IOM_GRP_B1DS, 0x0028 +DATA 4, MX6_IOM_GRP_B2DS, 0x0028 +DATA 4, MX6_IOM_GRP_B3DS, 0x0028 +DATA 4, MX6_IOM_GRP_B4DS, 0x0028 +DATA 4, MX6_IOM_GRP_B5DS, 0x0028 +DATA 4, MX6_IOM_GRP_B6DS, 0x0028 +DATA 4, MX6_IOM_GRP_B7DS, 0x0028 +DATA 4, MX6_IOM_DRAM_DQM0,0x0028 +DATA 4, MX6_IOM_DRAM_DQM1,0x0028 +DATA 4, MX6_IOM_DRAM_DQM2,0x0028 +DATA 4, MX6_IOM_DRAM_DQM3,0x0028 +DATA 4, MX6_IOM_DRAM_DQM4,0x0028 +DATA 4, MX6_IOM_DRAM_DQM5,0x0028 +DATA 4, MX6_IOM_DRAM_DQM6,0x0028 +DATA 4, MX6_IOM_DRAM_DQM7,0x0028 diff --git a/board/advantech/dms-ba16/dms-ba16_2g_dl.cfg b/board/advantech/dms-ba16/dms-ba16_2g_dl.cfg new file mode 100644 index 00..6d09cd55f7 --- /dev/null +++ b/board/advantech/dms-ba16/dms-ba16_2g_dl.cfg @@ -0,0 +1,23 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ +/* + * + * Copyright 2018 Advantech Corporation. + * + * Refer doc/README.imximage for more details about how-to configure + * and create imximage boot image + * + * The syntax is taken as close as possible with the kwbimage + */ + +IMAGE_VERSION 2 +BOOT_FROM sd + +#define __ASSEMBLY__ +#include +#include "asm/arch/mx6-ddr.h" +#include "asm/arch/iomux.h" +#include "asm/arch/crm_regs.h" + +#include "ddr-setup-dl.cfg" +#include "samsung-2g-dl.cfg" +#include "clocks.cfg" diff --git a/board/advantech/dms-ba16/samsung-2g-dl.cfg b/board/advantech/dms-ba16/samsung-2g-dl.cfg new file mode 100644 index 00..280e9f01a3 --- /dev/null +++ b/board/advantech/dms-ba16/samsung-2g-dl.cfg @@ -0,0 +1,58 @@ +/* Calibrations */ +/* ZQ */ +DATA 4, MX6_MMDC_P0_MPZQHWCTRL, 0xa1390003 +/* write leveling */ +DATA 4, MX6_MMDC_P0_MPWLDECTRL0, 0x004B004E +DATA 4, MX6_MMDC_P0_MPWLDECTRL1, 0x003F003E +DATA 4, MX6_MMDC_P1_MPWLDECTRL0, 0x00230026 +DATA 4, MX6_MMDC_P1_MPWLDECTRL1, 0x002B0030 +/* Read DQS Gating
[U-Boot] [PATCH 1/2] board: advantech: dms-ba16: GBE MAC addr support in kernel bootargs
Add configurable support for loading the GBE MAC from the Q7 SPI-NOR
and add it to the kernel bootargs.
Signed-off-by: Ken Lin
---
board/advantech/dms-ba16/Kconfig | 3 +++
board/advantech/dms-ba16/dms-ba16.c | 19 +++
include/configs/advantech_dms-ba16.h | 13 +++--
3 files changed, 33 insertions(+), 2 deletions(-)
diff --git a/board/advantech/dms-ba16/Kconfig b/board/advantech/dms-ba16/Kconfig
index 040eb866b5..f5d9f61f13 100644
--- a/board/advantech/dms-ba16/Kconfig
+++ b/board/advantech/dms-ba16/Kconfig
@@ -28,4 +28,7 @@ config SYS_SOC
config SYS_CONFIG_NAME
default "advantech_dms-ba16"
+config QSPI_MACADDR
+ string "0xD"
+
endif
diff --git a/board/advantech/dms-ba16/dms-ba16.c
b/board/advantech/dms-ba16/dms-ba16.c
index 09620435d3..bfc4e2319e 100644
--- a/board/advantech/dms-ba16/dms-ba16.c
+++ b/board/advantech/dms-ba16/dms-ba16.c
@@ -26,6 +26,8 @@
#include
#include
#include
+#include
+#include
DECLARE_GLOBAL_DATA_PTR;
#define NC_PAD_CTRL (PAD_CTL_PUS_100K_UP | \
@@ -584,6 +586,21 @@ void pmic_init(void)
}
+int load_mac_addrs(void)
+{
+struct spi_flash *flash;
+char mac_addrs[31] = CONFIG_QSPI_MACADDR;
+
+flash = spi_flash_probe(CONFIG_ENV_SPI_BUS, CONFIG_ENV_SPI_CS,
+ CONFIG_ENV_SPI_MAX_HZ, CONFIG_ENV_SPI_MODE);
+
+if (strcmp(mac_addrs, "") && !spi_flash_read(flash,
simple_strtoul(mac_addrs, NULL, 16), sizeof(mac_addrs), mac_addrs)) {
+ env_set("fec_addr", mac_addrs);
+}
+
+return 0;
+}
+
int board_late_init(void)
{
#ifdef CONFIG_CMD_BMODE
@@ -609,6 +626,8 @@ int board_late_init(void)
pwm_enable(0);
#endif
+load_mac_addrs();
+
#ifdef CONFIG_SATA
setup_ba16_sata();
#endif
diff --git a/include/configs/advantech_dms-ba16.h
b/include/configs/advantech_dms-ba16.h
index 0c9de6125d..bffd9b50a9 100644
--- a/include/configs/advantech_dms-ba16.h
+++ b/include/configs/advantech_dms-ba16.h
@@ -15,8 +15,11 @@
#define CONFIG_MXC_UART_BASE UART4_BASE
#define CONSOLE_DEV"ttymxc3"
+#if defined(CONFIG_QSPI_MACADDR)
+#define CONFIG_EXTRA_BOOTARGS "panic=10 ${macaddrs}"
+#else
#define CONFIG_EXTRA_BOOTARGS "panic=10"
-
+#endif
#define CONFIG_BOOT_DIR""
#define CONFIG_LOADCMD "fatload"
#define CONFIG_RFSPART "2"
@@ -111,6 +114,12 @@
"sf write $loadaddr 0x400 $filesize; " \
"echo 'U-Boot upgraded. Please reset'; " \
"fi\0" \
+"safe_macaddrs=" \
+ "if test -n ${fec_addr}; then " \
+ "setenv macaddrs fec.macaddr=${fec_addr}; " \
+ "else " \
+ "setenv macaddrs; " \
+ "fi;\0" \
"setargs=setenv bootargs console=${console},${baudrate} " \
"root=/dev/${rootdev} rw rootwait " CONFIG_EXTRA_BOOTARGS "\0" \
"loadbootscript=" \
@@ -129,7 +138,7 @@
"fi; " \
"fi;\0" \
"doboot=echo Booting from ${dev}:${devnum}:${partnum} ...; " \
- "run setargs; " \
+ "run safe_macaddrs; run setargs; " \
"if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \
"if run loadfdt; then " \
"bootm ${loadaddr} - ${fdt_addr}; " \
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] ftgmac100: Add DM support to the current driver
The conversion is inspired by the FTMAC100 driver and the driver was
tested on QEMU with an Aspeed SoC machine. Some extra changes required
by the Aspeed SoCs will be proposed in a subsequent patch.
Signed-off-by: Cédric Le Goater
---
drivers/net/ftgmac100.c | 351 +++-
drivers/net/Kconfig | 6 +
2 files changed, 282 insertions(+), 75 deletions(-)
diff --git a/drivers/net/ftgmac100.c b/drivers/net/ftgmac100.c
index c996f5f4a167..e33c87ca02fa 100644
--- a/drivers/net/ftgmac100.c
+++ b/drivers/net/ftgmac100.c
@@ -16,8 +16,13 @@
#include
#include
#include
+#include
#include "ftgmac100.h"
+#ifdef CONFIG_DM_ETH
+#include
+DECLARE_GLOBAL_DATA_PTR;
+#endif
#define ETH_ZLEN 60
#define CFG_XBUF_SIZE 1536
@@ -36,15 +41,18 @@ struct ftgmac100_data {
int tx_index;
int rx_index;
int phy_addr;
+
+ const char *name;
+ phys_addr_t iobase;
};
/*
* struct mii_bus functions
*/
-static int ftgmac100_mdiobus_read(struct eth_device *dev, int phy_addr,
- int regnum)
+static int ftgmac100_mdiobus_read(struct ftgmac100_data *priv, int phy_addr,
+ int regnum)
{
- struct ftgmac100 *ftgmac100 = (struct ftgmac100 *)dev->iobase;
+ struct ftgmac100 *ftgmac100 = (struct ftgmac100 *)priv->iobase;
int phycr;
int i;
@@ -76,10 +84,10 @@ static int ftgmac100_mdiobus_read(struct eth_device *dev,
int phy_addr,
return -1;
}
-static int ftgmac100_mdiobus_write(struct eth_device *dev, int phy_addr,
- int regnum, u16 value)
+static int ftgmac100_mdiobus_write(struct ftgmac100_data *priv, int phy_addr,
+ int regnum, u16 value)
{
- struct ftgmac100 *ftgmac100 = (struct ftgmac100 *)dev->iobase;
+ struct ftgmac100 *ftgmac100 = (struct ftgmac100 *)priv->iobase;
int phycr;
int data;
int i;
@@ -114,9 +122,10 @@ static int ftgmac100_mdiobus_write(struct eth_device *dev,
int phy_addr,
return -1;
}
-int ftgmac100_phy_read(struct eth_device *dev, int addr, int reg, u16 *value)
+int ftgmac100_phy_read(struct ftgmac100_data *priv, int addr, int reg,
+ u16 *value)
{
- *value = ftgmac100_mdiobus_read(dev , addr, reg);
+ *value = ftgmac100_mdiobus_read(priv, addr, reg);
if (*value == -1)
return -1;
@@ -124,31 +133,31 @@ int ftgmac100_phy_read(struct eth_device *dev, int addr,
int reg, u16 *value)
return 0;
}
-int ftgmac100_phy_write(struct eth_device *dev, int addr, int reg, u16 value)
+int ftgmac100_phy_write(struct ftgmac100_data *priv, int addr, int reg,
+u16 value)
{
- if (ftgmac100_mdiobus_write(dev, addr, reg, value) == -1)
+ if (ftgmac100_mdiobus_write(priv, addr, reg, value) == -1)
return -1;
return 0;
}
-static int ftgmac100_phy_reset(struct eth_device *dev)
+static int ftgmac100_phy_reset(struct ftgmac100_data *priv)
{
- struct ftgmac100_data *priv = dev->priv;
int i;
u16 status, adv;
adv = ADVERTISE_CSMA | ADVERTISE_ALL;
- ftgmac100_phy_write(dev, priv->phy_addr, MII_ADVERTISE, adv);
+ ftgmac100_phy_write(priv, priv->phy_addr, MII_ADVERTISE, adv);
- printf("%s: Starting autonegotiation...\n", dev->name);
+ printf("%s: Starting autonegotiation...\n", priv->name);
- ftgmac100_phy_write(dev, priv->phy_addr,
- MII_BMCR, (BMCR_ANENABLE | BMCR_ANRESTART));
+ ftgmac100_phy_write(priv, priv->phy_addr,
+ MII_BMCR, (BMCR_ANENABLE | BMCR_ANRESTART));
for (i = 0; i < 10 / 100; i++) {
- ftgmac100_phy_read(dev, priv->phy_addr, MII_BMSR, );
+ ftgmac100_phy_read(priv, priv->phy_addr, MII_BMSR, );
if (status & BMSR_ANEGCOMPLETE)
break;
@@ -156,29 +165,30 @@ static int ftgmac100_phy_reset(struct eth_device *dev)
}
if (status & BMSR_ANEGCOMPLETE) {
- printf("%s: Autonegotiation complete\n", dev->name);
+ printf("%s: Autonegotiation complete\n", priv->name);
} else {
printf("%s: Autonegotiation timed out (status=0x%04x)\n",
- dev->name, status);
+ priv->name, status);
return 0;
}
return 1;
}
-static int ftgmac100_phy_init(struct eth_device *dev)
+static int ftgmac100_phy_init(struct ftgmac100_data *priv)
{
- struct ftgmac100_data *priv = dev->priv;
-
int phy_addr;
- u16 phy_id, status, adv, lpa, stat_ge;
+ u16 phy_id, status, adv, lpa;
int media, speed, duplex;
int i;
+#ifdef CONFIG_FTGMAC100_EGIGA
+ unsigned short stat_ge;
+#endif
/* Check if the PHY is up to snuff... */
- for (phy_addr = 0; phy_addr < CONFIG_PHY_MAX_ADDR; phy_addr++) {
+ for
Re: [U-Boot] env: ubi: Add missing ENV_NAME
On Tue, Aug 21, 2018 at 03:53:33PM +0200, Marek Vasut wrote: > Add missing environment name for UBI, to prevent this NULL in output: > Loading Environment from ... > and rather have a valid UBI there: > Loading Environment from UBI... > > Signed-off-by: Marek Vasut Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] board: arm: bcmstb: Declare get_ticks in timer.h
On Wed, Aug 15, 2018 at 09:33:49PM -0400, Thomas Fitzsimmons wrote: > In an earlier proposed patch, bcmstb.c implemented timer_read_counter, > but it was updated to implement get_ticks instead. This patch updates > the declaration in timer.h accordingly. > > Signed-off-by: Thomas Fitzsimmons Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v1] malloc_simple: calloc: don't call memset if malloc failed
On Thu, Aug 16, 2018 at 09:50:32AM +0200, Simon Goldschmidt wrote: > malloc_simple() can return 0 if out of memory. Don't call memset > from calloc() in this case but rely on the caller checking > the return value. > > Signed-off-by: Simon Goldschmidt > Reviewed-by: Marek Vasut Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] ARM: dts: am33xx: fix SLEWCTRL_FAST pinctrl binding
On Tue, Aug 21, 2018 at 05:04:09PM +0200, christian.am...@de.bosch.com wrote: > From: Christian Amann > > Copy missing Kernel patch to make SLEWCTRL_SLOW available in device tree > and to correct the value of SLEWCTRL_FAST. > After this patch, the Kernel and U-boot device tree settings for > SLEWCTRL have the same effect. > > Original Kernel patch message: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=424e0f039bfa8a51fb5c5178b6ece8baa4996469 > > " > According to AM335x TRM, Document spruh73l, Revised February 2015, > Section 9.2.2 Pad Control Registers, setting bit 6 of the pad control > registers actually sets the SLEWCTRL value to slow rather than fast as > the current macro indicates. Introduce a new macro, SLEWCTRL_SLOW, that > sets the bit, and modify SLEWCTRL_FAST to 0 but keep it for > completeness. Current users of the macro (i2c and mdio) are left > unmodified as SLEWCTRL_FAST was the macro used and actual desired state. > Tested on am335x-gp-evm with no difference in software performance seen. > Signed-off-by: Dave Gerlach > Signed-off-by: Tony Lindgren > " > > Signed-off-by: Christian Amann Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] ARM: display5: Remove "factory procedure" from display5 board config
On Mon, Aug 20, 2018 at 04:23:58PM +0200, Lukasz Majewski wrote: > This code now is regarded as dead one and hence shall be removed. > > Signed-off-by: Lukasz Majewski Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 7/7] common: avb_verify: Fix division by zero in mmc_byte_io()
On Tue, Aug 14, 2018 at 02:43:09AM +0200, Eugeniu Rosca wrote: > Compiling U-Boot with ubsan/asan libraries and running it in sandbox > may lead to below backtrace: > > => avb init 0 > => avb verify > ## Android Verified Boot 2.0 version 1.1.0 > read_is_device_unlocked not supported yet > common/avb_verify.c:407:31: runtime error: division by zero > AddressSanitizer:DEADLYSIGNAL > Reviewed-by: Igor Opaniuk > > = > ==9388==ERROR: AddressSanitizer: FPE on unknown address 0x004b467f \ > (pc 0x004b467f bp 0x sp 0x7ffd899fe150 T0) > #0 0x4b467e in mmc_byte_io common/avb_verify.c:407 > #1 0x4b4c47 in mmc_byte_io common/avb_verify.c:532 > #2 0x4b4c47 in read_from_partition common/avb_verify.c:533 > #3 0x69dc0d in load_and_verify_vbmeta lib/libavb/avb_slot_verify.c:560 > #4 0x6a1ee6 in avb_slot_verify lib/libavb/avb_slot_verify.c:1139 > #5 0x45dabd in do_avb_verify_part cmd/avb.c:245 > #6 0x4af77c in cmd_call common/command.c:499 > #7 0x4af77c in cmd_process common/command.c:538 > #8 0x46bafc in run_pipe_real common/cli_hush.c:1677 > #9 0x46bafc in run_list_real common/cli_hush.c:1875 > #10 0x46c780 in run_list common/cli_hush.c:2024 > #11 0x46c780 in parse_stream_outer common/cli_hush.c:3216 > #12 0x46d34b in parse_file_outer common/cli_hush.c:3299 > #13 0x4ad609 in cli_loop common/cli.c:217 > #14 0x4625ae in main_loop common/main.c:65 > #15 0x46f2d1 in run_main_loop common/board_r.c:648 > #16 0x640253 in initcall_run_list lib/initcall.c:30 > #17 0x46f9d0 in board_init_r common/board_r.c:879 > #18 0x40539b in main arch/sandbox/cpu/start.c:321 > #19 0x7fa94925f82f in __libc_start_main > (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) > #20 0x408908 in _start (/srv/R/u-boot-master/u-boot+0x408908) > > AddressSanitizer can not provide additional info. > SUMMARY: AddressSanitizer: FPE common/avb_verify.c:407 in mmc_byte_io > ==9388==ABORTING > > Signed-off-by: Eugeniu Rosca Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 6/7] common: avb_verify: Fix never-occurring avb_free(ops_data)
On Tue, Aug 14, 2018 at 02:43:08AM +0200, Eugeniu Rosca wrote: > Cppcheck (v1.85) reports w/o this patch: > > [common/avb_verify.c:738] -> [common/avb_verify.c:741]: (warning) \ > Either the condition 'ops' is redundant or there is possible null \ > pointer dereference: ops. > > Signed-off-by: Eugeniu Rosca > Reviewed-by: Igor Opaniuk Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] dm: test: Fix typo in test-main comment
On Mon, Aug 20, 2018 at 08:03:22AM +0200, Michal Simek wrote: > Trivial fix. > > Signed-off-by: Michal Simek > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] u-boot: align cache flushes in load_elf_image_shdr to line boundaries
On Mon, Aug 20, 2018 at 03:46:19PM +, Neil Stainton wrote: > Prevent cache warning messages when using the 'bootelf' command on an Arm > target. Round down each section start address and round up the respective > section end to the nearest cache line. Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 3/7] common: kconfig: Mark AVB_VERIFY as dependent on PARTITION_UUIDS
On Tue, Aug 14, 2018 at 02:43:05AM +0200, Eugeniu Rosca wrote:
> Avoid below compiler [1] errors, reproduced with configuration [2]:
>
> common/avb_verify.c: In function ‘get_unique_guid_for_partition’:
> common/avb_verify.c:692:31: error: ‘disk_partition_t {aka struct
> disk_partition}’ has no member named ‘uuid’
> uuid_size = sizeof(part->info.uuid);
>^
> common/avb_verify.c:696:29: error: ‘disk_partition_t {aka struct
> disk_partition}’ has no member named ‘uuid’
> memcpy(guid_buf, part->info.uuid, uuid_size);
> ^
> LD drivers/built-in.o
> make[2]: *** [scripts/Makefile.build:278: common/avb_verify.o] Error 1
>
> [1] aarch64-linux-gnu-gcc (Linaro GCC 7.2-2017.11)
> [2] r8a7795_ulcb_defconfig, plus:
> CONFIG_AVB_VERIFY=y
> CONFIG_PARTITION_UUIDS=y
> CONFIG_UDP_FUNCTION_FASTBOOT=y
> CONFIG_LIBAVB=y
>
> Signed-off-by: Eugeniu Rosca
> Reviewed-by: Igor Opaniuk
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 4/7] common: avb_verify: Make local data static
On Tue, Aug 14, 2018 at 02:43:06AM +0200, Eugeniu Rosca wrote: > Fix sparse complaint: > > common/avb_verify.c:14:21: warning: \ > symbol 'avb_root_pub' was not declared. Should it be static? > > Signed-off-by: Eugeniu Rosca > Reviewed-by: Igor Opaniuk Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, u-boot, 1/3] boards: amlogic: remove ethernet gpio reset code from boards
On Tue, Aug 14, 2018 at 03:07:52PM +0200, Beniamino Galvani wrote: > The reset is already handled by the designware driver using > information from device tree. > > Signed-off-by: Beniamino Galvani > Acked-by: Neil Armstrong Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,5/7] common: avb_verify: Fix memory leaks
On Tue, Aug 14, 2018 at 02:43:07AM +0200, Eugeniu Rosca wrote: > Cppcheck (v1.85) reports w/o this patch: > > [common/avb_verify.c:351]: (error) Memory leak: part > [common/avb_verify.c:356]: (error) Memory leak: part > [common/avb_verify.c:361]: (error) Memory leak: part > [common/avb_verify.c:366]: (error) Memory leak: part > > Signed-off-by: Eugeniu Rosca > Reviewed-by: Igor Opaniuk Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 2/7] common: avb_verify: Fix invalid 'for' loop condition
On Tue, Aug 14, 2018 at 02:43:04AM +0200, Eugeniu Rosca wrote:
> Fix below compiler [1] warning:
>
> common/avb_verify.c: In function ‘avb_find_dm_args’:
> common/avb_verify.c:179:30: warning: left-hand operand of comma expression
> has no effect [-Wunused-value]
> for (i = 0; i < AVB_MAX_ARGS, args[i]; ++i) {
>
> [1] aarch64-linux-gnu-gcc (Linaro GCC 7.2-2017.11)
>
> Signed-off-by: Eugeniu Rosca
> Reviewed-by: Igor Opaniuk
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/7] libavb: Handle wrong hashtree_error_mode in avb_append_options()
On Tue, Aug 14, 2018 at 02:43:03AM +0200, Eugeniu Rosca wrote:
> From: Ievgen Maliarenko
>
> Exit with AVB_SLOT_VERIFY_RESULT_ERROR_INVALID_ARGUMENT
> when hashtree_error_mode value passed to avb_append_options()
> is unknown (not from AvbHashtreeErrorMode enum).
>
> Otherwise, default value is not handled in the
> switch(hashtree_error_mode), which causes below compile warning:
>
> lib/libavb/avb_cmdline.c: In function ‘avb_append_options’:
> lib/libavb/avb_cmdline.c:354:13: warning: ‘dm_verity_mode’ may be used
> uninitialized in this function [-Wmaybe-uninitialized]
> new_ret = avb_replace(
> ^~
> slot_data->cmdline, "$(ANDROID_VERITY_MODE)", dm_verity_mode);
> ~
> lib/libavb/avb_cmdline.c:363:8: warning: ‘verity_mode’ may be used
> uninitialized in this function [-Wmaybe-uninitialized]
>if (!cmdline_append_option(
> ^~
>slot_data, "androidboot.veritymode", verity_mode)) {
>
> Signed-off-by: Ievgen Maliarenko
> Signed-off-by: Eugeniu Rosca
> Reviewed-by: Igor Opaniuk
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] usb: ohci: Add OHCI PCI driver
Add small OHCI PCI driver for USB 1.1 OHCI controllers on PCI bus.
This driver matches only on PCI class (serial-ohci) and requires
DM-USB ; any sort of deprecated legacy usage is not supported.
Signed-off-by: Marek Vasut
---
drivers/usb/host/Kconfig| 6 +
drivers/usb/host/Makefile | 1 +
drivers/usb/host/ohci-pci.c | 55 +
3 files changed, 62 insertions(+)
create mode 100644 drivers/usb/host/ohci-pci.c
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index b4dd005651..99ecf5bdd7 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -225,6 +225,12 @@ config USB_OHCI_GENERIC
---help---
Enables support for generic OHCI controller.
+config USB_OHCI_PCI
+ bool "Support for PCI-based OHCI USB controller"
+ depends on DM_USB
+ help
+ Enables support for the PCI-based OHCI controller.
+
endif # USB_OHCI_HCD
config USB_UHCI_HCD
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index cb8c315a15..b7c94cadcb 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_USB_OHCI_EP93XX) += ohci-ep93xx.o
obj-$(CONFIG_USB_OHCI_SUNXI) += ohci-sunxi.o
obj-$(CONFIG_USB_OHCI_LPC32XX) += ohci-lpc32xx.o
obj-$(CONFIG_USB_OHCI_GENERIC) += ohci-generic.o
+obj-$(CONFIG_USB_OHCI_PCI) += ohci-pci.o
# echi
obj-$(CONFIG_USB_EHCI_HCD) += ehci-hcd.o
diff --git a/drivers/usb/host/ohci-pci.c b/drivers/usb/host/ohci-pci.c
new file mode 100644
index 00..dd078f008e
--- /dev/null
+++ b/drivers/usb/host/ohci-pci.c
@@ -0,0 +1,55 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 Marek Vasut
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "ohci.h"
+
+/* Information about the USB port */
+struct ohci_pci_priv {
+ ohci_t ohci;
+};
+
+static int ohci_pci_probe(struct udevice *dev)
+{
+ struct ohci_regs *regs;
+ u32 cmd;
+
+ regs = dm_pci_map_bar(dev, PCI_BASE_ADDRESS_0, PCI_REGION_MEM);
+ if (!regs)
+ return -ENOMEM;
+
+ /* Enable busmaster */
+ dm_pci_read_config32(dev, PCI_COMMAND, );
+ cmd |= PCI_COMMAND_MASTER;
+ dm_pci_write_config32(dev, PCI_COMMAND, cmd);
+
+ debug("OHCI-PCI init regs %p\n", regs);
+
+ return ohci_register(dev, regs);
+}
+
+U_BOOT_DRIVER(ohci_pci) = {
+ .name = "ohci_pci",
+ .id = UCLASS_USB,
+ .probe = ohci_pci_probe,
+ .remove = ohci_deregister,
+ .ops= _usb_ops,
+ .platdata_auto_alloc_size = sizeof(struct usb_platdata),
+ .priv_auto_alloc_size = sizeof(struct ohci_pci_priv),
+ .flags = DM_FLAG_ALLOC_PRIV_DMA,
+};
+
+static struct pci_device_id ohci_pci_supported[] = {
+ { PCI_DEVICE_CLASS(PCI_CLASS_SERIAL_USB_OHCI, ~0) },
+ {},
+};
+
+U_BOOT_PCI_DEVICE(ohci_pci, ohci_pci_supported);
--
2.16.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] pci: rmobile: Filter out device 1 and 2
Only PCI device 1 and 2 is populated on the R-Car Gen2 internal PCIe controller. Ignore all other devices. This fix prevents a duplication of OHCI controller response on slot 0 and 1. Signed-off-by: Marek Vasut --- drivers/pci/pci-rcar-gen2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci/pci-rcar-gen2.c b/drivers/pci/pci-rcar-gen2.c index cbaba1986a..d913d53f3c 100644 --- a/drivers/pci/pci-rcar-gen2.c +++ b/drivers/pci/pci-rcar-gen2.c @@ -97,7 +97,7 @@ static int rcar_gen2_pci_addr_valid(pci_dev_t d, uint offset) /* Only one EHCI/OHCI device built-in */ slot = PCI_DEV(d); - if (slot > 2) + if (slot != 1 && slot != 2) return -EINVAL; /* bridge logic only has registers to 0x40 */ -- 2.16.2 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH V2 1/2] pci: Support parsing PCI controller DT subnodes
The PCI controller can have DT subnodes describing extra properties
of particular PCI devices, ie. a PHY attached to an EHCI controller
on a PCI bus. This patch parses those DT subnodes and assigns a node
to the PCI device instance, so that the driver can extract details
from that node and ie. configure the PHY using the PHY subsystem.
Signed-off-by: Marek Vasut
Cc: Simon Glass
Cc: Tom Rini
---
V2: Move the whole machinery to pci_bind_bus_devices(), right after
the driver instance platform data are updated. This reduces the
number of times the DT is traversed and works for both DT nodes
with and without compat string.
---
drivers/pci/pci-uclass.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index e9671d9b76..cf3e38a6f2 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -733,6 +733,7 @@ int pci_bind_bus_devices(struct udevice *bus)
ulong vendor, device;
ulong header_type;
pci_dev_t bdf, end;
+ ofnode node;
bool found_multi;
int ret;
@@ -803,6 +804,20 @@ int pci_bind_bus_devices(struct udevice *bus)
pplat->vendor = vendor;
pplat->device = device;
pplat->class = class;
+
+ /* Associate potention OF node */
+ dev_for_each_subnode(node, bus) {
+ phys_addr_t df, size;
+ df = ofnode_get_addr_size(node, "reg", );
+ if (df == FDT_ADDR_T_NONE)
+ continue;
+
+ if (PCI_FUNC(df) == PCI_FUNC(bdf) &&
+ PCI_DEV(df) == PCI_DEV(bdf)) {
+ dev->node = node;
+ break;
+ }
+ }
}
return 0;
--
2.16.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH V2 2/2] pci: Update documentation to make 'compatible' string optional
Reword the documentation to make it clear the compatible string is now optional, yet still matching on it takes precedence over PCI IDs and PCI classes. Signed-off-by: Marek Vasut Cc: Simon Glass Cc: Tom Rini --- V2: New patch --- doc/driver-model/pci-info.txt | 14 +- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/doc/driver-model/pci-info.txt b/doc/driver-model/pci-info.txt index e1701d1fbc..14364c5c75 100644 --- a/doc/driver-model/pci-info.txt +++ b/doc/driver-model/pci-info.txt @@ -34,11 +34,15 @@ under that bus. Note that this is all done on a lazy basis, as needed, so until something is touched on PCI (eg: a call to pci_find_devices()) it will not be probed. -PCI devices can appear in the flattened device tree. If they do this serves to -specify the driver to use for the device. In this case they will be bound at -first. Each PCI device node must have a compatible string list as well as a - property, as defined by the IEEE Std 1275-1994 PCI bus binding document -v2.1. Note we must describe PCI devices with the same bus hierarchy as the +PCI devices can appear in the flattened device tree. If they do, their node +often contains extra information which cannot be derived from the PCI IDs or +PCI class of the device. Each PCI device node must have a property, as +defined by the IEEE Std 1275-1994 PCI bus binding document v2.1. Compatible +string list is optional and generally not needed, since PCI is discoverable +bus, albeit there are justified exceptions. If the compatible string is +present, matching on it takes precedence over PCI IDs and PCI classes. + +Note we must describe PCI devices with the same bus hierarchy as the hardware, otherwise driver model cannot detect the correct parent/children relationship during PCI bus enumeration thus PCI devices won't be bound to their drivers accordingly. A working example like below: -- 2.16.2 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PULL] u-boot-socfpga/master
The following changes since commit 2418734ed429058b396d2aeb6b91f875cdc8e4ce: Merge branch 'master' of git://git.denx.de/u-boot-tegra (2018-08-22 22:36:08 -0400) are available in the Git repository at: git://git.denx.de/u-boot-socfpga.git master for you to fetch changes up to a029f540c54c39847c329fc70b1b2e0ab6dedbcd: ARM: dts: socfpga: Add missing NAND reset (2018-08-24 12:05:21 +0200) Ley Foon Tan (2): arm: socfpga: stratix10: Enable EMAC to FPGA bridge based on handoff arm: socfpga: stratix10: Fix mailbox urgent command with urgent register Marek Vasut (6): ARM: socfpga: Reorder Arria10 SPL timer: dw-apb: Add Designware APB timer driver ARM: dts: socfpga: Flag timer clock as pre-reloc ARM: socfpga: Convert Arria10 to timer framework ARM: dts: socfpga: Drop ad-hoc UART clock frequency encoding from DT ARM: dts: socfpga: Add missing NAND reset arch/arm/dts/socfpga_arria10.dtsi | 11 +++ arch/arm/dts/socfpga_arria10_socdk.dtsi| 13 - arch/arm/mach-socfpga/Makefile | 1 - arch/arm/mach-socfpga/board.c | 8 arch/arm/mach-socfpga/clock_manager_arria10.c | 11 --- arch/arm/mach-socfpga/include/mach/clock_manager_arria10.h | 3 ++- arch/arm/mach-socfpga/include/mach/misc.h | 5 + arch/arm/mach-socfpga/mailbox_s10.c| 15 +++ arch/arm/mach-socfpga/misc_arria10.c | 25 + arch/arm/mach-socfpga/spl_a10.c| 28 arch/arm/mach-socfpga/spl_s10.c| 2 +- configs/socfpga_arria10_defconfig | 3 +++ drivers/timer/Kconfig | 7 +++ drivers/timer/Makefile | 1 + drivers/timer/dw-apb-timer.c | 90 ++ include/configs/socfpga_common.h | 2 ++ 16 files changed, 158 insertions(+), 67 deletions(-) create mode 100644 drivers/timer/dw-apb-timer.c ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PULL] u-boot-usb/master
The following changes since commit 9f8cf76be256a83643ee05de6cffaeb452ed0931: Convert CONFIG_SYS_I2C_DAVINCI to Kconfig (2018-08-17 15:43:38 -0400) are available in the Git repository at: git://git.denx.de/u-boot-usb.git master for you to fetch changes up to 49c752c93a785b9bad9d3fbbd52a76bec003eac5: cmd: Add bind/unbind commands to bind a device to a driver from the command line (2018-08-21 16:21:37 +0200) Adam Ford (2): usb: musb-new: omap2430: Remove dead code usb: musb-new: omap2430: Enable DM_USB and OF support Jean-Jacques Hiblot (7): usb: gadget: Add bcdDevice for the DWC3 USB Gadget Controller net: eth-uclass: Fix for DM USB ethernet support uclass: Add dev_get_uclass_index() to get the uclass/index of a device dm: print the index of the device when dumping the dm tree dm: convert device_get_global_by_of_offset() to device_get_global_by_ofnode() device: expose the functions used to remove and unbind children of a device cmd: Add bind/unbind commands to bind a device to a driver from the command line Sam Protsenko (1): cmd: fastboot: Validate user input arch/arm/mach-rockchip/rk3188-board-spl.c | 2 +- arch/arm/mach-rockchip/rk3288-board-spl.c | 2 +- arch/sandbox/dts/test.dts | 11 +++ cmd/Kconfig | 9 +++ cmd/Makefile | 1 + cmd/bind.c| 255 ++ cmd/fastboot.c| 13 +++- configs/sandbox_defconfig | 1 + drivers/core/device-remove.c | 30 +++- drivers/core/device.c | 19 +++-- drivers/core/dump.c | 16 ++-- drivers/core/uclass.c | 21 ++ drivers/usb/gadget/gadget_chips.h | 2 + drivers/usb/musb-new/omap2430.c | 596 + include/dm/device-internal.h | 38 ++ include/dm/device.h | 23 +- include/dm/uclass-internal.h | 11 +++ net/eth-uclass.c | 3 +- test/py/tests/test_bind.py| 178 19 files changed, 712 insertions(+), 519 deletions(-) create mode 100644 cmd/bind.c create mode 100644 test/py/tests/test_bind.py ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1] arm: at91: wdt: Convert watchdog driver to dm
On 08/10/2018 07:53 AM, Tom Rini wrote: On Thu, Jul 26, 2018 at 02:56:27PM -0700, Prasanthi Chellakumar wrote: Convert the Watchdog driver for AT91SAM9x processors to support the driver model and device tree Signed-off-by: Prasanthi Chellakumar --- arch/arm/mach-at91/include/mach/at91_wdt.h | 12 +++- drivers/watchdog/Kconfig | 7 ++ drivers/watchdog/Makefile | 2 +- drivers/watchdog/at91sam9_wdt.c| 105 + 4 files changed, 95 insertions(+), 31 deletions(-) Thanks for doing the conversion. It's fine to rename the config option to match the rest of the WDT drivers but you need to update all of the existing users now too, thanks! Noted. Thanks for reviewing. Prasanthi ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] MMC: davinici_mmc: Enable CD and WP with DM and OF_CONTROL
On Thu, Aug 23, 2018 at 7:19 AM Peter Howard wrote:
>
> On Thu, 2018-08-16 at 23:26 -0500, Adam Ford wrote:
> > When used with a device tree, this will extract the card detect
> > and write protect pins from the device tree and configure them
> > accordingly. This assumes the GPIO_ACTIVE_LOW/HIGH is supported
> > byt da8xx_gpio.
> >
> > Signed-off-by: Adam Ford
> >
> > diff --git a/drivers/mmc/davinci_mmc.c b/drivers/mmc/davinci_mmc.c
> > index db950ea5ec..01d60f394f 100644
> > --- a/drivers/mmc/davinci_mmc.c
> > +++ b/drivers/mmc/davinci_mmc.c
> > @@ -15,6 +15,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #define DAVINCI_MAX_BLOCKS (32)
> > #define WATCHDOG_COUNT (10)
> > @@ -35,6 +36,8 @@ struct davinci_mmc_priv {
> > struct davinci_mmc_regs *reg_base; /* Register base
> > address */
> > uint input_clk; /* Input clock to MMC
> > controller */
> > uint version; /* MMC Controller version */
> > + struct gpio_desc cd_gpio; /* Card Detect GPIO */
> > + struct gpio_desc wp_gpio; /* Write Protect GPIO */
> > };
> >
> > struct davinci_mmc_plat
> > @@ -425,9 +428,38 @@ static const struct mmc_ops dmmc_ops = {
> > .init = dmmc_init,
> > };
> > #else
> > +
>
> The two new functions here - davinci_mmc_getcd() and
> davinci_mmc_getwp() - also need to be wrapped in a check for DM_GPIO
> being enabled, otherwise dm_gpio_get_value() isn't built.
Good catch. I'm on vacation now in London, but I'll be home Sept 4. I
should be able to post a V2 around then.
adam
>
>
> > +static int davinci_mmc_getcd(struct udevice *dev)
> > +{
> > + struct davinci_mmc_priv *priv = dev_get_priv(dev);
> > + int value;
> > +
> > + value = dm_gpio_get_value(>cd_gpio);
> > + /* if no CD return as 1 */
> > + if (value < 0)
> > + return 1;
> > +
> > + return value;
> > +}
> > +
> > +static int davinci_mmc_getwp(struct udevice *dev)
> > +{
> > + struct davinci_mmc_priv *priv = dev_get_priv(dev);
> > + int value;
> > +
> > + value = dm_gpio_get_value(>wp_gpio);
> > + /* if no WP return as 0 */
> > + if (value < 0)
> > + return 0;
> > +
> > + return value;
> > +}
> > +
> > static const struct dm_mmc_ops davinci_mmc_ops = {
> > .send_cmd = davinci_mmc_send_cmd,
> > .set_ios= davinci_mmc_set_ios,
> > + .get_cd = davinci_mmc_getcd,
> > + .get_wp = davinci_mmc_getwp,
>
> Again the assignment of .get_cd and .get_wp need to be wrapped in a
> check for DM_GPIO.
>
> > };
> > #endif
> >
> > @@ -475,6 +507,12 @@ static int davinci_mmc_probe(struct udevice
> > *dev)
> > priv->reg_base = (struct davinci_mmc_regs
> > *)dev_read_addr(dev);
> > priv->input_clk = clk_get(DAVINCI_MMCSD_CLKID);
> >
> > +#if CONFIG_IS_ENABLED(DM_GPIO)
> > + /* These GPIOs are optional */
> > + gpio_request_by_name(dev, "cd-gpios", 0, >cd_gpio,
> > GPIOD_IS_IN);
> > + gpio_request_by_name(dev, "wp-gpios", 0, >wp_gpio,
> > GPIOD_IS_IN);
> > +#endif
> > +
> > upriv->mmc = >mmc;
> >
> > return davinci_dm_mmc_init(dev);
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] Fix for rare beaglebone ethernet failures
On 08/23/2018 06:41 AM, Sekhar Nori wrote: There have been reports of ethernet network failures on beagle bone black. These have been root caused to ethernet PHY latching to a different address on boot than what is programmed in DT. See: https://groups.google.com/d/msg/beagleboard/9mctrG26Mc8/1FuI_i5KW10J This patch series tries to workaround this suitaiton by patching device-tree passed to kernel with the correct address. As well as updating the PHY address U-Boot drivers themselves use. Tested on beaglebone black rev A4 by simulating the error condition I was also able to hit the actual hardware error once in a while. Sekhar Nori (3): drivers: net: cpsw: add support to update phy address board: ti: am335x: add support to fixup phy address configs: am335x_evm: enable OF_BOARD_SETUP board/ti/am335x/board.c | 78 configs/am335x_evm_defconfig | 1 + drivers/net/cpsw.c | 29 include/cpsw.h | 1 + 4 files changed, 109 insertions(+) Reviewed-by: Grygorii Strashko -- regards, -grygorii ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 11/25] clk: Allow clock defaults to be set also during re-reloc state
Hi Philipp, On Fri, Aug 24, 2018 at 06:00:31PM +0200, Dr. Philipp Tomsich wrote: > >> If I remember correctly, David had a concern regarding an increase in > >> boottime if we ran this twice… adding Kever, as he was also involved > >> in the discussion. > >> > >> I settled on skipping it for pre-reloc, but it’s an imperfect solution: the > >> boottime increase comes from the fact that some devices have a large > >> number of assigned-clocks, that the device-tree processing has a cost, > >> and that we don’t have a way of synchronising between SPL and full > >> U-Boot to avoid redoing the complete init-flow. > > > > Good to know some of the background; when I did this patch initially it > > was not really clear why this was removed and it obviously was an issue > > for what I was doing that I had to overcome and re-adding this was the > > simpliest thing to do at that time. > > > >> Maybe we should have a SPL-specific property for the assigned-clocks > >> to be set pre-reloc? > > > > Need to think about this some more. Generally we probably want to do as > > little as possible before relocation. Unfortunately for the K3 family of > > SoCs much is dependent on loading/installing the system firmware (SYSFW) > > image including to get DDR operational which itself requires us to use a > > lot of DT/DM stuff pre-reloc. So a little bit of a chicken and egg > > problem… > > If you need someone to throw your thoughts at, feel free to share them with > me. With the newer Rockchip devices that I am focused on, we also do a lot > DT/DM stuff pre-reloc (I have a 100+KB SPL stage on the RK3399 at the > moment) and this trend is likely to increase … e.g. I may split the RK3399 > to use TPL for DRAM-init and will then have the SPL stage running from > DRAM which will remove the last remaining size constraints. Ok thanks for the offer. For what it's worth, I'm currently experimenting with not doing any relocation in SPL at all (which is really "only" stack/heap/bss/gd) as there is sufficient on-chip SRAM in our case to do so, if it works out this could be an alternative way to avoid the issue under discussion in the first place. Main reason however wanting to do that is that I started needing to use drivers that have globals and static variables which is when the wheels really came off trying to use those pre-reloc. I suppose should you use TPL for DDR init on RK devices there would also be no need for relocation in your SPL. -- Andreas Dannenberg Texas Instruments Inc ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 11/25] clk: Allow clock defaults to be set also during re-reloc state
> On 24 Aug 2018, at 17:54, Andreas Dannenberg wrote:
>
> Philipp,
>
> On Fri, Aug 24, 2018 at 04:42:15PM +0200, Dr. Philipp Tomsich wrote:
>> +Kever
>>
>>> On 24 Aug 2018, at 16:12, Tom Rini wrote:
>>>
>>> On Tue, Aug 21, 2018 at 08:01:49PM +0530, Lokesh Vutla wrote:
>>>
From: Andreas Dannenberg
The earlier commit f4fcba5c5ba ("clk: implement clk_set_defaults()")
which introduced the functionality for setting clock defaults such as
rates and parents will skip the processing when executing in a re-reloc
state. This for example can prevent the assigning of clock parents
when running in SPL code. Go ahead and remove this limitation.
Signed-off-by: Andreas Dannenberg
Signed-off-by: Lokesh Vutla
---
drivers/clk/clk-uclass.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
index 2b15978e14..04b369aa5a 100644
--- a/drivers/clk/clk-uclass.c
+++ b/drivers/clk/clk-uclass.c
@@ -243,10 +243,6 @@ int clk_set_defaults(struct udevice *dev)
{
int ret;
- /* If this is running pre-reloc state, don't take any action. */
- if (!(gd->flags & GD_FLG_RELOC))
- return 0;
-
debug("%s(%s)\n", __func__, dev_read_name(dev));
ret = clk_set_default_parents(dev);
>>>
>>> Philipp? David? Comments? Thanks!
>>
>> If I remember correctly, David had a concern regarding an increase in
>> boottime if we ran this twice… adding Kever, as he was also involved
>> in the discussion.
>>
>> I settled on skipping it for pre-reloc, but it’s an imperfect solution: the
>> boottime increase comes from the fact that some devices have a large
>> number of assigned-clocks, that the device-tree processing has a cost,
>> and that we don’t have a way of synchronising between SPL and full
>> U-Boot to avoid redoing the complete init-flow.
>
> Good to know some of the background; when I did this patch initially it
> was not really clear why this was removed and it obviously was an issue
> for what I was doing that I had to overcome and re-adding this was the
> simpliest thing to do at that time.
>
>> Maybe we should have a SPL-specific property for the assigned-clocks
>> to be set pre-reloc?
>
> Need to think about this some more. Generally we probably want to do as
> little as possible before relocation. Unfortunately for the K3 family of
> SoCs much is dependent on loading/installing the system firmware (SYSFW)
> image including to get DDR operational which itself requires us to use a
> lot of DT/DM stuff pre-reloc. So a little bit of a chicken and egg
> problem…
If you need someone to throw your thoughts at, feel free to share them with
me. With the newer Rockchip devices that I am focused on, we also do a lot
DT/DM stuff pre-reloc (I have a 100+KB SPL stage on the RK3399 at the
moment) and this trend is likely to increase … e.g. I may split the RK3399
to use TPL for DRAM-init and will then have the SPL stage running from
DRAM which will remove the last remaining size constraints.
--Philipp.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 11/25] clk: Allow clock defaults to be set also during re-reloc state
Philipp,
On Fri, Aug 24, 2018 at 04:42:15PM +0200, Dr. Philipp Tomsich wrote:
> +Kever
>
> > On 24 Aug 2018, at 16:12, Tom Rini wrote:
> >
> > On Tue, Aug 21, 2018 at 08:01:49PM +0530, Lokesh Vutla wrote:
> >
> >> From: Andreas Dannenberg
> >>
> >> The earlier commit f4fcba5c5ba ("clk: implement clk_set_defaults()")
> >> which introduced the functionality for setting clock defaults such as
> >> rates and parents will skip the processing when executing in a re-reloc
> >> state. This for example can prevent the assigning of clock parents
> >> when running in SPL code. Go ahead and remove this limitation.
> >>
> >> Signed-off-by: Andreas Dannenberg
> >> Signed-off-by: Lokesh Vutla
> >> ---
> >> drivers/clk/clk-uclass.c | 4
> >> 1 file changed, 4 deletions(-)
> >>
> >> diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
> >> index 2b15978e14..04b369aa5a 100644
> >> --- a/drivers/clk/clk-uclass.c
> >> +++ b/drivers/clk/clk-uclass.c
> >> @@ -243,10 +243,6 @@ int clk_set_defaults(struct udevice *dev)
> >> {
> >>int ret;
> >>
> >> - /* If this is running pre-reloc state, don't take any action. */
> >> - if (!(gd->flags & GD_FLG_RELOC))
> >> - return 0;
> >> -
> >>debug("%s(%s)\n", __func__, dev_read_name(dev));
> >>
> >>ret = clk_set_default_parents(dev);
> >
> > Philipp? David? Comments? Thanks!
>
> If I remember correctly, David had a concern regarding an increase in
> boottime if we ran this twice… adding Kever, as he was also involved
> in the discussion.
>
> I settled on skipping it for pre-reloc, but it’s an imperfect solution: the
> boottime increase comes from the fact that some devices have a large
> number of assigned-clocks, that the device-tree processing has a cost,
> and that we don’t have a way of synchronising between SPL and full
> U-Boot to avoid redoing the complete init-flow.
Good to know some of the background; when I did this patch initially it
was not really clear why this was removed and it obviously was an issue
for what I was doing that I had to overcome and re-adding this was the
simpliest thing to do at that time.
> Maybe we should have a SPL-specific property for the assigned-clocks
> to be set pre-reloc?
Need to think about this some more. Generally we probably want to do as
little as possible before relocation. Unfortunately for the K3 family of
SoCs much is dependent on loading/installing the system firmware (SYSFW)
image including to get DDR operational which itself requires us to use a
lot of DT/DM stuff pre-reloc. So a little bit of a chicken and egg
problem...
--
Andreas Dannenberg
Texas Instruments Inc
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/8] arm: K3: Add initial support for TI's K3 generation of SoCs
On Fri, Aug 24, 2018 at 08:44:50PM +0530, Lokesh Vutla wrote: > > > On Friday 24 August 2018 08:25 PM, Tom Rini wrote: > > On Fri, Aug 24, 2018 at 08:21:19PM +0530, Lokesh Vutla wrote: > >> > >> > >> On Friday 24 August 2018 07:40 PM, Tom Rini wrote: > >>> On Tue, Aug 21, 2018 at 08:00:48PM +0530, Lokesh Vutla wrote: > >>> > Add support for Texas Instruments' K3 Generation Processor > families. > >>> [snip] > diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c > index 9c80090aa7..f48d82f051 100644 > --- a/drivers/serial/ns16550.c > +++ b/drivers/serial/ns16550.c > @@ -175,7 +175,7 @@ void NS16550_init(NS16550_t com_port, int > baud_divisor) > ; > > serial_out(CONFIG_SYS_NS16550_IER, _port->ier); > -#if defined(CONFIG_ARCH_OMAP2PLUS) > +#if defined(CONFIG_ARCH_OMAP2PLUS) || defined(CONFIG_ARCH_K3) > serial_out(0x7, _port->mdr1); /* mode select reset > TL16C750*/ > #endif > > @@ -183,7 +183,8 @@ void NS16550_init(NS16550_t com_port, int > baud_divisor) > serial_out(ns16550_getfcr(com_port), _port->fcr); > if (baud_divisor != -1) > NS16550_setbrg(com_port, baud_divisor); > -#if defined(CONFIG_ARCH_OMAP2PLUS) || defined(CONFIG_SOC_DA8XX) > +#if defined(CONFIG_ARCH_OMAP2PLUS) || defined(CONFIG_SOC_DA8XX) || \ > +defined(CONFIG_ARCH_K3) > /* /16 is proper to hit 115200 with 48MHz */ > serial_out(0, _port->mdr1); > #endif > >>> > >>> K3 would also be using CONFIG_OMAP_SERIAL once > >>> https://patchwork.ozlabs.org/patch/956252/ is applied (which I'll do in > >>> the next release) yes? I think 956252 needs a follow-up that changes > >>> the above hunks to be testing off CONFIG_OMAP_SERIAL instead so this > >> > >> I did not make this change because ns16550 is also used by non-DM > >> platforms. Since OMAP_SERIAL is DM specific, converting this #ifdef to > >> OMAP_SERIAL would break non DM platforms. I guess I should still add || > >> OMAP_SERIAL. Ill post a v2 for 956252. > > > > What are the non-DM serial users at this point? > > > > omap4-evm and omap5-uevm are two TI boards which uses non-DM. I am not > sure about non-TI boards with omap SoCs. OK. I guess please just make sure updating omap4/5 are on your TODO list somewhere, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/8] arm: K3: Add initial support for TI's K3 generation of SoCs
On Friday 24 August 2018 08:25 PM, Tom Rini wrote: > On Fri, Aug 24, 2018 at 08:21:19PM +0530, Lokesh Vutla wrote: >> >> >> On Friday 24 August 2018 07:40 PM, Tom Rini wrote: >>> On Tue, Aug 21, 2018 at 08:00:48PM +0530, Lokesh Vutla wrote: >>> Add support for Texas Instruments' K3 Generation Processor families. >>> [snip] diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c index 9c80090aa7..f48d82f051 100644 --- a/drivers/serial/ns16550.c +++ b/drivers/serial/ns16550.c @@ -175,7 +175,7 @@ void NS16550_init(NS16550_t com_port, int baud_divisor) ; serial_out(CONFIG_SYS_NS16550_IER, _port->ier); -#if defined(CONFIG_ARCH_OMAP2PLUS) +#if defined(CONFIG_ARCH_OMAP2PLUS) || defined(CONFIG_ARCH_K3) serial_out(0x7, _port->mdr1); /* mode select reset TL16C750*/ #endif @@ -183,7 +183,8 @@ void NS16550_init(NS16550_t com_port, int baud_divisor) serial_out(ns16550_getfcr(com_port), _port->fcr); if (baud_divisor != -1) NS16550_setbrg(com_port, baud_divisor); -#if defined(CONFIG_ARCH_OMAP2PLUS) || defined(CONFIG_SOC_DA8XX) +#if defined(CONFIG_ARCH_OMAP2PLUS) || defined(CONFIG_SOC_DA8XX) || \ + defined(CONFIG_ARCH_K3) /* /16 is proper to hit 115200 with 48MHz */ serial_out(0, _port->mdr1); #endif >>> >>> K3 would also be using CONFIG_OMAP_SERIAL once >>> https://patchwork.ozlabs.org/patch/956252/ is applied (which I'll do in >>> the next release) yes? I think 956252 needs a follow-up that changes >>> the above hunks to be testing off CONFIG_OMAP_SERIAL instead so this >> >> I did not make this change because ns16550 is also used by non-DM >> platforms. Since OMAP_SERIAL is DM specific, converting this #ifdef to >> OMAP_SERIAL would break non DM platforms. I guess I should still add || >> OMAP_SERIAL. Ill post a v2 for 956252. > > What are the non-DM serial users at this point? > omap4-evm and omap5-uevm are two TI boards which uses non-DM. I am not sure about non-TI boards with omap SoCs. Thanks and regards, Lokesh ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 21/25] remoteproc: Introduce K3 system controller
On Friday 24 August 2018 07:42 PM, Tom Rini wrote:
> On Tue, Aug 21, 2018 at 08:01:59PM +0530, Lokesh Vutla wrote:
>
>> K3 specific SoCs have a dedicated microcontroller for doing
>> resource management. Any HLOS/firmware on compute clusters should
>> load a firmware to this microcontroller before accessing any resource.
>> Adding support for loading this firmware.
>>
>> After the K3 system controller got loaded with firmware and started
>> up it sends out a boot notification message through the secure proxy
>> facility using the TI SCI protocol. Intercept and receive this message
>> through the rproc start operation which will need to get invoked
>> explicitly after the firmware got loaded.
> [snip]
>> +/**
>> + * struct k3_sysctrler_msg_hdr - Generic Header for Messages and responses.
>> + * @cmd_id: Message ID. One of K3_MSG_*
>> + * @host_id:Host ID of the message
>> + * @seq_ne: Message identifier indicating a transfer sequence.
>> + * @flags: Flags for the message.
>> + */
>> +struct k3_sysctrler_msg_hdr {
>> +u16 cmd_id;
>> +u8 host_id;
>> +u8 seq_nr;
>> +u32 flags;
>> +} __attribute__ ((__packed__));
>
> Here and elsewhere please use __packed. Thanks!
>
Sure. Will fix it in v2.
Thanks and regards,
Lokesh
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 01/25] firmware: Add basic support for TI System Control Interface (TI SCI) protocol
On Friday 24 August 2018 07:41 PM, Tom Rini wrote: > On Tue, Aug 21, 2018 at 08:01:39PM +0530, Lokesh Vutla wrote: > >> Texas Instrument's System Control Interface (TI SCI) message protocol is >> used in Texas Instrument's System on Chip (SoC) such as those in the K3 >> family AM654 SoC to communicate between various compute processors with >> a central system controller entity. >> >> The TI SCI message protocol provides support for management of various >> hardware entities within the SoC. Add support driver to allow >> communication with system controller entity within the SoC using the >> mailbox client. >> >> This is mostly derived from the TI SCI driver in Linux located at >> drivers/firmware/ti_sci.c. > > Since K3 support for the kernel is also being posted now, please make > sure any feedback to ti_sci there for K3 is worked in here as well when > applicable, thanks! ti_sci linux driver is already upstreamed and this is a port of the upstream driver. > >> >> Signed-off-by: Lokesh Vutla >> Signed-off-by: Nishanth Menon >> Signed-off-by: Andreas Dannenberg > > Content wise, seems fine: > > Reviewed-by: Tom Rini > > [snip] >> +++ b/include/linux/soc/ti/ti_sci_protocol.h >> @@ -0,0 +1,69 @@ >> +/* >> + * Texas Instruments System Control Interface Protocol >> + * Based on include/linux/soc/ti/ti_sci_protocol.h from Linux. >> + * >> + * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/ >> + * Nishanth Menon >> + * Lokesh Vutla >> + * >> + * SPDX-License-Identifier: GPL-2.0+ >> + */ > > Since you've got one here, please run checkpatch.pl on the whole series > to check for other places where the SDPX header isn't in the right spot > (and of course other style/etc problems checkpatch complains about). > ahh my bad. Will fix it everywhere. Thanks and regards, Lokesh ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/8] arm: K3: Add support for AM654 SoC definition
On Fri, Aug 24, 2018 at 08:28:17PM +0530, Lokesh Vutla wrote: > > > On Friday 24 August 2018 07:41 PM, Tom Rini wrote: > > On Tue, Aug 21, 2018 at 08:00:49PM +0530, Lokesh Vutla wrote: > > > >> The AM654 device is designed for industrial automation and PLC > >> controller class platforms among other applications. Introduce > >> base support for AM654 SoC. > > [snip] > >> +config NON_SECURE_MSRAM_SIZE > >> + hex "Size of the MCU OC-MSRAM" > >> + default 0x8 > >> + help > >> +Describes the total size of the MCU MSRAM. This doesn't > >> +specify the total size of SPL as ROM can use some part > >> +of this RAM. Once ROM gives control to SPL then this > >> +complete size can be usable. > >> + > >> +config MAX_DOWNLODABLE_IMAGE_SIZE > >> + hex "Maximum size of the image" > >> + default 0x58000 > >> + help > >> +Describes the maximum size of the image that ROM can download > >> +from any boot media. > >> + > >> +config MCU_SCRATCHPAD_BASE > >> + hex "Base address of Scratchpad RAM" > >> + default 0x4028 if SOC_K3_AM6 > >> + help > >> +Describes the base address of MCU Scratchpad RAM. > >> + > >> +config MCU_SCRATCHPAD_SIZE > >> + hex "Size of Scratchpad RAM" > >> + default 0x200 if SOC_K3_AM6 > >> + help > >> +Describes the size of MCU Scratchpad RAM. > > > > These are very generic names. And are these really things that can be > > configured and changed by the user? MAX_DOWNLODABLE_IMAGE_SIZE is > > You are right. These are not configurable by user, but changes from SoC > to SoC within K3 family. Will fix it in v2 by dropping the prompt string. > Well, the names are also fairly generic. Why not just #define SYS_K3_xxx ? -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 7/8] armv8: K3: am654: Introduce FIT generator script
On Friday 24 August 2018 07:41 PM, Tom Rini wrote: > On Tue, Aug 21, 2018 at 08:00:54PM +0530, Lokesh Vutla wrote: > >> Add a script that is capable of generating a FIT image >> source file that combines ATF, SPL(64 bit) and DT. >> This combined image is used by R5 SPL and start ATF >> on ARMv8 core. >> >> Signed-off-by: Lokesh Vutla >> --- >> tools/k3/k3_fit_atf.sh | 98 ++ >> 1 file changed, 98 insertions(+) >> create mode 100755 tools/k3/k3_fit_atf.sh >> >> diff --git a/tools/k3/k3_fit_atf.sh b/tools/k3/k3_fit_atf.sh >> new file mode 100755 >> index 00..ef84e3d182 >> --- /dev/null >> +++ b/tools/k3/k3_fit_atf.sh > > I know we have one thing in tools/omap/ but I'd rather see this as just > tools/k3_fit_atf.sh will fix it in v2. > >> @@ -0,0 +1,98 @@ >> +#!/bin/sh >> +# > > Missing SPDX tag. > Oops. will add it. Thanks and regards, Lokesh ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/8] arm: K3: am654: Add support for boot device detection
On Friday 24 August 2018 07:41 PM, Tom Rini wrote:
> On Tue, Aug 21, 2018 at 08:00:51PM +0530, Lokesh Vutla wrote:
>
>> AM654 allows for booting from primary or backup boot media.
>> Both media can be chosen individually based on switch settings.
>> ROM looks for a valid image in primary boot media, if not found
>> then looks in backup boot media. In order to pass this boot media
>> information to boot loader, ROM stores a value at a particular
>> address. Add support for reading this information and determining
>> the boot media correctly.
> [snip]
>> diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
>> index c532fbd061..117e5b4e4a 100644
>> --- a/arch/arm/mach-k3/Kconfig
>> +++ b/arch/arm/mach-k3/Kconfig
>> @@ -40,4 +40,11 @@ config MCU_SCRATCHPAD_SIZE
>> help
>>Describes the size of MCU Scratchpad RAM.
>>
>> +config BOOT_PARAM_TABLE_INDEX
>> +hex "Address of Array Index to be used within BOOT_PARAM_TABLE"
>> +default 0x41c7fbfc if SOC_K3_AM6
>> +help
>> + Address at which ROM stores the value which determines if SPL
>> + is booted up by primary boot media or secondary boot media.
>> +
>
> I'm not sure this belongs in Kconfig. This isn't configurable really is
> it?
Agreed. Will drop the prompt string in v2.
>
>> +static u32 __get_backup_bootmedia(u32 devstat)
>> {
>> +u32 bkup_boot = (devstat & CTRLMMR_MAIN_DEVSTAT_BKUP_BOOTMODE_MASK) >>
>> +CTRLMMR_MAIN_DEVSTAT_BKUP_BOOTMODE_SHIFT;
>> +
>> +switch (bkup_boot) {
>> +#define __BKUP_BOOT_DEVICE(n) \
>> +case BACKUP_BOOT_DEVICE_##n:\
>> +return BOOT_DEVICE_##n;
>
> I really don't like defining the macro in the function like this. And
> in terms of style, I think I'd rather see it spelled out with
> case/return as is normally done.
Sure. Will fix it in v2.
Thanks and regards,
Lokesh
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3.3 14/58] musb-new: sunxi: Use CLK and RESET support
On Fri, Aug 24, 2018 at 01:53:40PM +0530, Jagan Teki wrote: > Now clock and reset drivers are available for respective > SoC's so use clk and reset ops on musb driver. > > Signed-off-by: Jagan Teki Acked-by: Maxime Ripard Thanks! Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/8] arm: K3: Add support for AM654 SoC definition
On Friday 24 August 2018 07:41 PM, Tom Rini wrote: > On Tue, Aug 21, 2018 at 08:00:49PM +0530, Lokesh Vutla wrote: > >> The AM654 device is designed for industrial automation and PLC >> controller class platforms among other applications. Introduce >> base support for AM654 SoC. > [snip] >> +config NON_SECURE_MSRAM_SIZE >> +hex "Size of the MCU OC-MSRAM" >> +default 0x8 >> +help >> + Describes the total size of the MCU MSRAM. This doesn't >> + specify the total size of SPL as ROM can use some part >> + of this RAM. Once ROM gives control to SPL then this >> + complete size can be usable. >> + >> +config MAX_DOWNLODABLE_IMAGE_SIZE >> +hex "Maximum size of the image" >> +default 0x58000 >> +help >> + Describes the maximum size of the image that ROM can download >> + from any boot media. >> + >> +config MCU_SCRATCHPAD_BASE >> +hex "Base address of Scratchpad RAM" >> +default 0x4028 if SOC_K3_AM6 >> +help >> + Describes the base address of MCU Scratchpad RAM. >> + >> +config MCU_SCRATCHPAD_SIZE >> +hex "Size of Scratchpad RAM" >> +default 0x200 if SOC_K3_AM6 >> +help >> + Describes the size of MCU Scratchpad RAM. > > These are very generic names. And are these really things that can be > configured and changed by the user? MAX_DOWNLODABLE_IMAGE_SIZE is You are right. These are not configurable by user, but changes from SoC to SoC within K3 family. Will fix it in v2 by dropping the prompt string. Thanks and regards, Lokesh > something we usually set in CONFIG_SPL_MAX_SIZE but I imagine the > overall architecture means that perhaps that's not the exact variable > we're talking about here. > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/8] arm: K3: Add initial support for TI's K3 generation of SoCs
On Fri, Aug 24, 2018 at 08:21:19PM +0530, Lokesh Vutla wrote: > > > On Friday 24 August 2018 07:40 PM, Tom Rini wrote: > > On Tue, Aug 21, 2018 at 08:00:48PM +0530, Lokesh Vutla wrote: > > > >> Add support for Texas Instruments' K3 Generation Processor > >> families. > > [snip] > >> diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c > >> index 9c80090aa7..f48d82f051 100644 > >> --- a/drivers/serial/ns16550.c > >> +++ b/drivers/serial/ns16550.c > >> @@ -175,7 +175,7 @@ void NS16550_init(NS16550_t com_port, int baud_divisor) > >>; > >> > >>serial_out(CONFIG_SYS_NS16550_IER, _port->ier); > >> -#if defined(CONFIG_ARCH_OMAP2PLUS) > >> +#if defined(CONFIG_ARCH_OMAP2PLUS) || defined(CONFIG_ARCH_K3) > >>serial_out(0x7, _port->mdr1); /* mode select reset TL16C750*/ > >> #endif > >> > >> @@ -183,7 +183,8 @@ void NS16550_init(NS16550_t com_port, int baud_divisor) > >>serial_out(ns16550_getfcr(com_port), _port->fcr); > >>if (baud_divisor != -1) > >>NS16550_setbrg(com_port, baud_divisor); > >> -#if defined(CONFIG_ARCH_OMAP2PLUS) || defined(CONFIG_SOC_DA8XX) > >> +#if defined(CONFIG_ARCH_OMAP2PLUS) || defined(CONFIG_SOC_DA8XX) || \ > >> + defined(CONFIG_ARCH_K3) > >>/* /16 is proper to hit 115200 with 48MHz */ > >>serial_out(0, _port->mdr1); > >> #endif > > > > K3 would also be using CONFIG_OMAP_SERIAL once > > https://patchwork.ozlabs.org/patch/956252/ is applied (which I'll do in > > the next release) yes? I think 956252 needs a follow-up that changes > > the above hunks to be testing off CONFIG_OMAP_SERIAL instead so this > > I did not make this change because ns16550 is also used by non-DM > platforms. Since OMAP_SERIAL is DM specific, converting this #ifdef to > OMAP_SERIAL would break non DM platforms. I guess I should still add || > OMAP_SERIAL. Ill post a v2 for 956252. What are the non-DM serial users at this point? -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] driver: net: fsl-mc: Memset MC reserve red memory before usage
On 08/23/2018 08:13 PM, Prabhakar Kushwaha wrote: > Hi York > >> -Original Message- >> From: York Sun >> Sent: Thursday, August 23, 2018 8:41 PM >> To: Prabhakar Kushwaha ; u- >> b...@lists.denx.de >> Cc: joe.hershber...@ni.com; Ashish Kumar ; >> cristian.sovai...@nxp.co >> Subject: Re: [PATCH] driver: net: fsl-mc: Memset MC reserve red memory >> before usage >> >> On 08/15/2018 11:49 PM, Prabhakar Kushwaha wrote: >>> It is not necessary for MC memory to be always clean. It may have >>> garbage value causing indeterministic behavior during MC >>> initialization and run. >>> >>> So memset memory reserved for MC before any usage. >> >> Your commit message seems wrong. If it is not necessary to be clean, why it >> causes problems? I guess you mean the memory needs to be clean. >> > > Yes. You are right. > Commit message should be memory needs to be clean before passing to > management complex. > > May I send v2 version for the same. > You can either send v2 patch. Or if you don't have other update, I can fix the commit message when merging. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Unaligned memory accesses exception
On Wed, Aug 22, 2018 at 09:44:16AM +0200, Fernando AE wrote: > Hello all, > > I'm bringing up U-Boot for an iMX6UL board, and I've encountered > unaligned memory accesses exceptions while I was trying to test the > ETH commands (e.g., 'ping'). > > After investigation, I found out that the iMX6UL processor traps > unaligned memory accesses by default. As a workaround, I disabled > theses checks, hoping for negligible performance loss. > > I'm wondering if it is a bad idea to disable unaligned memory accesses > during the U-Boot execution, regarding performance issues or other > drawbacks at the kernel level. What exactly do you mean by encountered? Can you post logs? Thanks. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/8] arm: K3: Add initial support for TI's K3 generation of SoCs
On Friday 24 August 2018 07:40 PM, Tom Rini wrote: > On Tue, Aug 21, 2018 at 08:00:48PM +0530, Lokesh Vutla wrote: > >> Add support for Texas Instruments' K3 Generation Processor >> families. > [snip] >> diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c >> index 9c80090aa7..f48d82f051 100644 >> --- a/drivers/serial/ns16550.c >> +++ b/drivers/serial/ns16550.c >> @@ -175,7 +175,7 @@ void NS16550_init(NS16550_t com_port, int baud_divisor) >> ; >> >> serial_out(CONFIG_SYS_NS16550_IER, _port->ier); >> -#if defined(CONFIG_ARCH_OMAP2PLUS) >> +#if defined(CONFIG_ARCH_OMAP2PLUS) || defined(CONFIG_ARCH_K3) >> serial_out(0x7, _port->mdr1); /* mode select reset TL16C750*/ >> #endif >> >> @@ -183,7 +183,8 @@ void NS16550_init(NS16550_t com_port, int baud_divisor) >> serial_out(ns16550_getfcr(com_port), _port->fcr); >> if (baud_divisor != -1) >> NS16550_setbrg(com_port, baud_divisor); >> -#if defined(CONFIG_ARCH_OMAP2PLUS) || defined(CONFIG_SOC_DA8XX) >> +#if defined(CONFIG_ARCH_OMAP2PLUS) || defined(CONFIG_SOC_DA8XX) || \ >> +defined(CONFIG_ARCH_K3) >> /* /16 is proper to hit 115200 with 48MHz */ >> serial_out(0, _port->mdr1); >> #endif > > K3 would also be using CONFIG_OMAP_SERIAL once > https://patchwork.ozlabs.org/patch/956252/ is applied (which I'll do in > the next release) yes? I think 956252 needs a follow-up that changes > the above hunks to be testing off CONFIG_OMAP_SERIAL instead so this I did not make this change because ns16550 is also used by non-DM platforms. Since OMAP_SERIAL is DM specific, converting this #ifdef to OMAP_SERIAL would break non DM platforms. I guess I should still add || OMAP_SERIAL. Ill post a v2 for 956252. Thanks and regards, Lokesh ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 11/25] clk: Allow clock defaults to be set also during re-reloc state
+Kever
> On 24 Aug 2018, at 16:12, Tom Rini wrote:
>
> On Tue, Aug 21, 2018 at 08:01:49PM +0530, Lokesh Vutla wrote:
>
>> From: Andreas Dannenberg
>>
>> The earlier commit f4fcba5c5ba ("clk: implement clk_set_defaults()")
>> which introduced the functionality for setting clock defaults such as
>> rates and parents will skip the processing when executing in a re-reloc
>> state. This for example can prevent the assigning of clock parents
>> when running in SPL code. Go ahead and remove this limitation.
>>
>> Signed-off-by: Andreas Dannenberg
>> Signed-off-by: Lokesh Vutla
>> ---
>> drivers/clk/clk-uclass.c | 4
>> 1 file changed, 4 deletions(-)
>>
>> diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
>> index 2b15978e14..04b369aa5a 100644
>> --- a/drivers/clk/clk-uclass.c
>> +++ b/drivers/clk/clk-uclass.c
>> @@ -243,10 +243,6 @@ int clk_set_defaults(struct udevice *dev)
>> {
>> int ret;
>>
>> -/* If this is running pre-reloc state, don't take any action. */
>> -if (!(gd->flags & GD_FLG_RELOC))
>> -return 0;
>> -
>> debug("%s(%s)\n", __func__, dev_read_name(dev));
>>
>> ret = clk_set_default_parents(dev);
>
> Philipp? David? Comments? Thanks!
If I remember correctly, David had a concern regarding an increase in
boottime if we ran this twice… adding Kever, as he was also involved
in the discussion.
I settled on skipping it for pre-reloc, but it’s an imperfect solution: the
boottime increase comes from the fact that some devices have a large
number of assigned-clocks, that the device-tree processing has a cost,
and that we don’t have a way of synchronising between SPL and full
U-Boot to avoid redoing the complete init-flow.
Maybe we should have a SPL-specific property for the assigned-clocks
to be set pre-reloc?
>
>> --
>> 2.18.0
>>
>> ___
>> U-Boot mailing list
>> U-Boot@lists.denx.de
>> https://lists.denx.de/listinfo/u-boot
>
> --
> Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] drivers: net: cpsw: add support to update phy address
On Thu, Aug 23, 2018 at 05:11:29PM +0530, Sekhar Nori wrote: > On some boards using TI CPSW, it may be possible that > PHY address was not latched correctly, and the actual > address that the phy responds on is different from that > set in device-tree. For example, see this problem report > on beaglebone black: > > https://groups.google.com/d/msg/beagleboard/9mctrG26Mc8/1FuI_i5KW10J > > Add support to check for this condition and use the > detected phy address when its safe to do so. > > Also, add a public API that exposes the phy address of > a given slave. This can be used to update device-tree that > is passed to Linux kernel. > > Signed-off-by: Sekhar Nori Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 23/25] spl: Allow remoteproc drivers to be used within SPL
On Tue, Aug 21, 2018 at 08:02:01PM +0530, Lokesh Vutla wrote: > Add an option for building remoteproc drivers within SPL. > > Signed-off-by: Lokesh Vutla Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 25/25] gpio: do not include for ARCH_K3
On Tue, Aug 21, 2018 at 08:02:03PM +0530, Lokesh Vutla wrote: > As no gpio.h is defined in arch/arm/mach-k3/include/, > to avoid compilation failure, do not include asm/arch/gpio.h. > > Signed-off-by: Lokesh Vutla Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6] arm64: dts: k3: Add u-boot specific nodes
On Tue, Aug 21, 2018 at 08:03:15PM +0530, Lokesh Vutla wrote: > Add the minimum dt nodes required to boot. These nodes > will get deleted as kernel gets these nodes added in the > main dts files. > > Signed-off-by: Lokesh Vutla Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] configs: am65x_evm_a53: Add initial support
On Tue, Aug 21, 2018 at 08:03:16PM +0530, Lokesh Vutla wrote: > Add initial defconfig support for AM65x that runs on A53. > > Signed-off-by: Lokesh Vutla > Signed-off-by: Andreas Dannenberg Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] arm64: dts: k3: Add Support for AM654 SoC
On Tue, Aug 21, 2018 at 08:03:14PM +0530, Lokesh Vutla wrote: > Add initial DT support for AM654 EVM that runs on A53. > > Signed-off-by: Lokesh Vutla Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 22/25] remoteproc: Introduce K3 remoteproc driver
On Tue, Aug 21, 2018 at 08:02:00PM +0530, Lokesh Vutla wrote: > Add support for K3 based remoteproc driver that > communicates with TISCI to start start a remote processor. > > Signed-off-by: Lokesh Vutla Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 09/25] reset: Extend reset control with an optional data field
On Tue, Aug 21, 2018 at 08:01:47PM +0530, Lokesh Vutla wrote: > From: Andreas Dannenberg > > Some systems require more than a single ID to identify and configure any > reset provider. For those scenarios add an optional data field to the > reset control structure. > > Signed-off-by: Andreas Dannenberg > Signed-off-by: Lokesh Vutla Tested-by: Tom Rini -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 15/25] power domain: Introduce TI System Control Interface (TI SCI) power domain driver
On Tue, Aug 21, 2018 at 08:01:53PM +0530, Lokesh Vutla wrote: > From: Andreas Dannenberg > > Some TI Keystone 2 and K3 family of SoCs contain a system controller > (like the Power Management Micro Controller (PMMC) on 66AK2G SoCs and > the Device Management and Security Controller on AM65x SoCs) that manage > the low-level device control (like clocks, resets etc) for the various > hardware modules present on the SoC. These device control operations are > provided to the host processor OS through a communication protocol > called the TI System Control Interface (TI SCI) protocol. > > This patch adds a power domain driver that communicates to the system > controller over the TI SCI protocol for performing power management of > various devices present on the SoC. Various power domain functionalities > are achieved by the means of different TI SCI device operations provided > by the TI SCI framework. > > This code is loosely based on the drivers/soc/ti/ti_sci_pm_domains.c > driver of the Linux kernel. > > Signed-off-by: Andreas Dannenberg > Signed-off-by: Lokesh Vutla Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 08/25] dm: reset: Update uclass to allow querying reset status
On Tue, Aug 21, 2018 at 08:01:46PM +0530, Lokesh Vutla wrote: > From: Andreas Dannenberg > > Add a reset operations function pointer to support querying the current > status of a reset control. > > Signed-off-by: Andreas Dannenberg > Signed-off-by: Lokesh Vutla Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 07/25] dm: firmware: Automatically bind child devices
On Tue, Aug 21, 2018 at 08:01:45PM +0530, Lokesh Vutla wrote: > From: Andreas Dannenberg > > To support scenarios where a firmware device node has subnodes that > have their own drivers automatically scan the DT and bind those when > the firmware device gets bound. > > Signed-off-by: Andreas Dannenberg > Signed-off-by: Lokesh Vutla Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 19/25] spl: Allow mailbox drivers to be used within SPL
On Tue, Aug 21, 2018 at 08:01:57PM +0530, Lokesh Vutla wrote: > Add an option for building mailbox drivers within SPL. > > Signed-off-by: Lokesh Vutla Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] include: am654_evm: Establish initial environment for SD card boot
On Tue, Aug 21, 2018 at 08:03:13PM +0530, Lokesh Vutla wrote: > From: Andreas Dannenberg > > Create a basic U-Boot environment that allows the automatic loading > of a Linux Kernel located at /boot/Image and an associated device tree > blob located at /boot/k3-am654-base-board.dtb from the secondary > partition of an ext4-formatted SD card on the AM654x EVM. Furthermore > the boot.scr and uEnv.txt detection and loading schemes are supported > in a manner already known from other TI platforms. > > Note that this is intended to be a starting point to enable initial > board use and will most certainly get extended and refactored as > different boot media become available. > > Signed-off-by: Andreas Dannenberg Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] configs: am335x_evm: enable OF_BOARD_SETUP
On Thu, Aug 23, 2018 at 05:11:31PM +0530, Sekhar Nori wrote: > Enable CONFIG_OF_BOARD_SETUP as it is needed for Beaglebone > black to overwrite the Ethernet phy address present in DT > in case the phy latches on to a different address. > > Signed-off-by: Sekhar Nori Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 13/25] clk: Introduce TI System Control Interface (TI SCI) clock driver
On Tue, Aug 21, 2018 at 08:01:51PM +0530, Lokesh Vutla wrote: > From: Andreas Dannenberg > > Some TI Keystone 2 and K3 family of SoCs contain a system controller > (like the Power Management Micro Controller (PMMC) on 66AK2G SoCs and > the Device Management and Security Controller on AM65x SoCs) that manage > the low-level device control (like clocks, resets etc) for the various > hardware modules present on the SoC. These device control operations are > provided to the host processor OS through a communication protocol > called the TI System Control Interface (TI SCI) protocol. > > This patch adds a clock driver that communicates to the system > controller over the TI SCI protocol for performing clock management of > various devices present on the SoC. Various clock functionality is > achieved by the means of different TI SCI device operations provided by > the TI SCI framework. > > This code is loosely based on the drivers/clk/keystone/sci-clk.c driver > of the Linux kernel. > > Signed-off-by: Andreas Dannenberg > Signed-off-by: Vignesh R > Signed-off-by: Lokesh Vutla Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] board: ti: am335x: add support to fixup phy address
On Thu, Aug 23, 2018 at 05:11:30PM +0530, Sekhar Nori wrote: > On beaglebone black, it can so happen that PHY address > is not latched correctly on reset and board boots with > PHY responding to a different address than that > programmed in device-tree. For example, see this report: > > https://groups.google.com/d/msg/beagleboard/9mctrG26Mc8/1FuI_i5KW10J > > Workaround this by fixing up device-tree passed to kernel > by using the PHY address detected in hardware. > > Beaglebone itself uses only one ethernet port and its DT > currently uses phy_id (obsoleted). But the function has > been written to handle multiple ports and phy_id as well > as phy-handle to make the function more generically useful. > > Signed-off-by: Sekhar Nori Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 04/25] firmware: ti_sci: Add support for clock control
On Tue, Aug 21, 2018 at 08:01:42PM +0530, Lokesh Vutla wrote: > In general, we expect to function at a device level of abstraction, > however, for proper operation of hardware blocks, many clocks directly > supplying the hardware block needs to be queried or configured. > > Introduce support for the set of SCI message protocol support that > provide us with this capability. > > Signed-off-by: Lokesh Vutla > Signed-off-by: Nishanth Menon Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 12/25] clk: Extend clock control with an optional data field
On Tue, Aug 21, 2018 at 08:01:50PM +0530, Lokesh Vutla wrote: > From: Andreas Dannenberg > > Some systems require more than a single ID to identify and configure any > clock provider. For those scenarios add an optional data field to the > clock control structure. > > Signed-off-by: Andreas Dannenberg > Signed-off-by: Lokesh Vutla Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 01/25] firmware: Add basic support for TI System Control Interface (TI SCI) protocol
On Tue, Aug 21, 2018 at 08:01:39PM +0530, Lokesh Vutla wrote: > Texas Instrument's System Control Interface (TI SCI) message protocol is > used in Texas Instrument's System on Chip (SoC) such as those in the K3 > family AM654 SoC to communicate between various compute processors with > a central system controller entity. > > The TI SCI message protocol provides support for management of various > hardware entities within the SoC. Add support driver to allow > communication with system controller entity within the SoC using the > mailbox client. > > This is mostly derived from the TI SCI driver in Linux located at > drivers/firmware/ti_sci.c. Since K3 support for the kernel is also being posted now, please make sure any feedback to ti_sci there for K3 is worked in here as well when applicable, thanks! > > Signed-off-by: Lokesh Vutla > Signed-off-by: Nishanth Menon > Signed-off-by: Andreas Dannenberg Content wise, seems fine: Reviewed-by: Tom Rini [snip] > +++ b/include/linux/soc/ti/ti_sci_protocol.h > @@ -0,0 +1,69 @@ > +/* > + * Texas Instruments System Control Interface Protocol > + * Based on include/linux/soc/ti/ti_sci_protocol.h from Linux. > + * > + * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/ > + * Nishanth Menon > + * Lokesh Vutla > + * > + * SPDX-License-Identifier: GPL-2.0+ > + */ Since you've got one here, please run checkpatch.pl on the whole series to check for other places where the SDPX header isn't in the right spot (and of course other style/etc problems checkpatch complains about). -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] board: ti: am654: a53: Add initial support for am654
On Tue, Aug 21, 2018 at 08:03:11PM +0530, Lokesh Vutla wrote: > Add initial support for AM654 based EVM running on A53. Enable > 4GB of DDR available on the EVM so that kernel DTB file > can be updated accordingly. > > Signed-off-by: Lokesh Vutla > [Andreas: Added 4GB ddr support] > Signed-off-by: Andreas Dannenberg Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 14/25] power domain: Add support for multiple powerdomains per device
On Tue, Aug 21, 2018 at 08:01:52PM +0530, Lokesh Vutla wrote: > There are cases where there are more than one power domain > attached to the device inorder to get the device functional. > So add support for enabling power domain based on the index. > > Signed-off-by: Lokesh Vutla Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 24/25] mmc: k3_arasan: Add sdhci driver support for K3 family SoCs
On Tue, Aug 21, 2018 at 08:02:02PM +0530, Lokesh Vutla wrote: > AM654 has an arasan sdhci controller and a mmc phy attached to it. > Add basic support for K3 specific arasan sdhci controller. > > Cc: Jaehoon Chung > Signed-off-by: Lokesh Vutla Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 06/25] firmware: ti_sci: Add support for processor control services
On Tue, Aug 21, 2018 at 08:01:44PM +0530, Lokesh Vutla wrote: > TI-SCI message protocol provides support for controlling of various > physical cores available in SoC. In order to control which host is > capable of controlling a physical processor core, there is a processor > access control list that needs to be populated as part of the board > configuration data. > > Introduce support for the set of TI-SCI message protocol apis that > provide us with this capability of controlling physical cores. > > ToDo: > - Create separate TISCI commands for control, config, status flags. > - Update Documentation. > > Signed-off-by: Lokesh Vutla Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/8] armv8: K3: am654: Add custom MMU support
On Tue, Aug 21, 2018 at 08:00:53PM +0530, Lokesh Vutla wrote: > Add MMU mappings for AM654 SoC. > > Signed-off-by: Lokesh Vutla Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 10/25] reset: Introduce TI System Control Interface (TI SCI) reset driver
On Tue, Aug 21, 2018 at 08:01:48PM +0530, Lokesh Vutla wrote: > From: Andreas Dannenberg > > Some TI Keystone 2 and K3 family of SoCs contain a system controller > (like the Power Management Micro Controller (PMMC) on 66AK2G SoCs and > the Device Management and Security Controller on AM65x SoCs) that manage > the low-level device control (like clocks, resets etc) for the various > hardware modules present on the SoC. These device control operations are > provided to the host processor OS through a communication protocol > called the TI System Control Interface (TI SCI) protocol. > > This patch adds a reset driver that communicates to the system > controller over the TI SCI protocol for performing reset management of > various devices present on the SoC. Various reset functionalities are > achieved by the means of different TI SCI device operations provided by > the TI SCI framework. > > This code is loosely based on the drivers/reset/reset-ti-sci.c driver of > the Linux kernel. > > Signed-off-by: Andreas Dannenberg > Signed-off-by: Lokesh Vutla Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 16/25] sysreset: Add TI System Control Interface (TI SCI) sysreset driver
On Tue, Aug 21, 2018 at 08:01:54PM +0530, Lokesh Vutla wrote: > From: Andreas Dannenberg > > Devices from the TI K3 family of SoCs like the AM654x contain a Device > Management and Security Controller (SYSFW) that manages the low-level > device control (like clocks, resets etc) for the various hardware > modules present on the SoC. These device control operations are provided > to the host processor OS through a communication protocol called the TI > System Control Interface (TI SCI) protocol. > > This patch adds a system reset driver that communicates to the system > controller over the TI SCI protocol for allowing to perform a system- > wide SoC reset. > > Signed-off-by: Andreas Dannenberg > Signed-off-by: Lokesh Vutla Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 17/25] mailbox: Allow attaching private data for mbox_chan
On Tue, Aug 21, 2018 at 08:01:55PM +0530, Lokesh Vutla wrote: > Sometimes mbox controllers wants to store private data in > mbox_chan so that it can be used at a later point of time. > Adding support for hooking private data. > > Signed-off-by: Lokesh Vutla Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 05/25] firmware: ti_sci: Add support for reboot core service
On Tue, Aug 21, 2018 at 08:01:43PM +0530, Lokesh Vutla wrote: > From: Andreas Dannenberg > > Since system controller now has control over SoC power management, it > needs to be explicitly requested to reboot the SoC. Add support for > it. > > Signed-off-by: Lokesh Vutla > Signed-off-by: Nishanth Menon Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 20/25] remoteproc: Allow for individual remoteproc initialization
On Tue, Aug 21, 2018 at 08:01:58PM +0530, Lokesh Vutla wrote: > Existing rproc_init() api tries to initialize all available > remoteproc devices. This will fail when there is dependency > among available remoteprocs. So introduce a separate api > that allows to initialize remoteprocs individually based > on id. > > Signed-off-by: Lokesh Vutla Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/6] board: ti: am65x: Add README
On Tue, Aug 21, 2018 at 08:03:12PM +0530, Lokesh Vutla wrote: > Add README file that describes the building and booting procedure. > > Signed-off-by: Lokesh Vutla Reviewed-by: Tom Rini But please just fold this into the first patch. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 18/25] mailbox: Introduce K3 Secure Proxy Driver
On Tue, Aug 21, 2018 at 08:01:56PM +0530, Lokesh Vutla wrote: > Secure Proxy module manages hardware threads that are meant > for communication between the processor entities. Adding > support for this driver. > > Signed-off-by: Lokesh Vutla > Signed-off-by: Andreas Dannenberg Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 21/25] remoteproc: Introduce K3 system controller
On Tue, Aug 21, 2018 at 08:01:59PM +0530, Lokesh Vutla wrote:
> K3 specific SoCs have a dedicated microcontroller for doing
> resource management. Any HLOS/firmware on compute clusters should
> load a firmware to this microcontroller before accessing any resource.
> Adding support for loading this firmware.
>
> After the K3 system controller got loaded with firmware and started
> up it sends out a boot notification message through the secure proxy
> facility using the TI SCI protocol. Intercept and receive this message
> through the rproc start operation which will need to get invoked
> explicitly after the firmware got loaded.
[snip]
> +/**
> + * struct k3_sysctrler_msg_hdr - Generic Header for Messages and responses.
> + * @cmd_id: Message ID. One of K3_MSG_*
> + * @host_id: Host ID of the message
> + * @seq_ne: Message identifier indicating a transfer sequence.
> + * @flags: Flags for the message.
> + */
> +struct k3_sysctrler_msg_hdr {
> + u16 cmd_id;
> + u8 host_id;
> + u8 seq_nr;
> + u32 flags;
> +} __attribute__ ((__packed__));
Here and elsewhere please use __packed. Thanks!
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 03/25] firmware: ti_sci: Add support for device control
On Tue, Aug 21, 2018 at 08:01:41PM +0530, Lokesh Vutla wrote: > From: Andreas Dannenberg > > TI-SCI message protocol provides support for management of various > hardware entitites within the SoC. Introduce the fundamental > device management capability support to the driver protocol > as part of this change. > > Signed-off-by: Lokesh Vutla > Signed-off-by: Nishanth Menon Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 02/25] firmware: ti_sci: Add support for board configuration
On Tue, Aug 21, 2018 at 08:01:40PM +0530, Lokesh Vutla wrote: > From: Andreas Dannenberg > > TI-SCI message protocol provides support for board configuration > to assign resources and other board related operations. > Introduce the board configuration capability support to the driver protocol > as part of this change. > > Signed-off-by: Andreas Dannenberg > Signed-off-by: Lokesh Vutla Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 11/25] clk: Allow clock defaults to be set also during re-reloc state
On Tue, Aug 21, 2018 at 08:01:49PM +0530, Lokesh Vutla wrote:
> From: Andreas Dannenberg
>
> The earlier commit f4fcba5c5ba ("clk: implement clk_set_defaults()")
> which introduced the functionality for setting clock defaults such as
> rates and parents will skip the processing when executing in a re-reloc
> state. This for example can prevent the assigning of clock parents
> when running in SPL code. Go ahead and remove this limitation.
>
> Signed-off-by: Andreas Dannenberg
> Signed-off-by: Lokesh Vutla
> ---
> drivers/clk/clk-uclass.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
> index 2b15978e14..04b369aa5a 100644
> --- a/drivers/clk/clk-uclass.c
> +++ b/drivers/clk/clk-uclass.c
> @@ -243,10 +243,6 @@ int clk_set_defaults(struct udevice *dev)
> {
> int ret;
>
> - /* If this is running pre-reloc state, don't take any action. */
> - if (!(gd->flags & GD_FLG_RELOC))
> - return 0;
> -
> debug("%s(%s)\n", __func__, dev_read_name(dev));
>
> ret = clk_set_default_parents(dev);
Philipp? David? Comments? Thanks!
> --
> 2.18.0
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 7/8] armv8: K3: am654: Introduce FIT generator script
On Tue, Aug 21, 2018 at 08:00:54PM +0530, Lokesh Vutla wrote: > Add a script that is capable of generating a FIT image > source file that combines ATF, SPL(64 bit) and DT. > This combined image is used by R5 SPL and start ATF > on ARMv8 core. > > Signed-off-by: Lokesh Vutla > --- > tools/k3/k3_fit_atf.sh | 98 ++ > 1 file changed, 98 insertions(+) > create mode 100755 tools/k3/k3_fit_atf.sh > > diff --git a/tools/k3/k3_fit_atf.sh b/tools/k3/k3_fit_atf.sh > new file mode 100755 > index 00..ef84e3d182 > --- /dev/null > +++ b/tools/k3/k3_fit_atf.sh I know we have one thing in tools/omap/ but I'd rather see this as just tools/k3_fit_atf.sh > @@ -0,0 +1,98 @@ > +#!/bin/sh > +# Missing SPDX tag. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 8/8] armv8: K3: am654: Add support for generating build targets
On Tue, Aug 21, 2018 at 08:00:55PM +0530, Lokesh Vutla wrote: > Update Makefile to generate > - tispl.bin: First stage bootloader on ARMv8 core > - u-boot.img: Second stage bootloader on ARMv8 core. > > Signed-off-by: Lokesh Vutla Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/8] arm: K3: am654: Unlock control module registers during init
On Tue, Aug 21, 2018 at 08:00:52PM +0530, Lokesh Vutla wrote: > From: Andreas Dannenberg > > By default the device control module registers are locked, > preventing any writes to its registers. > Unlock those registers as part of the init flow. > > Signed-off-by: Andreas Dannenberg > Signed-off-by: Lokesh Vutla Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/8] arm: K3: am654: Add support for boot device detection
On Tue, Aug 21, 2018 at 08:00:51PM +0530, Lokesh Vutla wrote:
> AM654 allows for booting from primary or backup boot media.
> Both media can be chosen individually based on switch settings.
> ROM looks for a valid image in primary boot media, if not found
> then looks in backup boot media. In order to pass this boot media
> information to boot loader, ROM stores a value at a particular
> address. Add support for reading this information and determining
> the boot media correctly.
[snip]
> diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
> index c532fbd061..117e5b4e4a 100644
> --- a/arch/arm/mach-k3/Kconfig
> +++ b/arch/arm/mach-k3/Kconfig
> @@ -40,4 +40,11 @@ config MCU_SCRATCHPAD_SIZE
> help
> Describes the size of MCU Scratchpad RAM.
>
> +config BOOT_PARAM_TABLE_INDEX
> + hex "Address of Array Index to be used within BOOT_PARAM_TABLE"
> + default 0x41c7fbfc if SOC_K3_AM6
> + help
> + Address at which ROM stores the value which determines if SPL
> + is booted up by primary boot media or secondary boot media.
> +
I'm not sure this belongs in Kconfig. This isn't configurable really is
it?
> +static u32 __get_backup_bootmedia(u32 devstat)
> {
> + u32 bkup_boot = (devstat & CTRLMMR_MAIN_DEVSTAT_BKUP_BOOTMODE_MASK) >>
> + CTRLMMR_MAIN_DEVSTAT_BKUP_BOOTMODE_SHIFT;
> +
> + switch (bkup_boot) {
> +#define __BKUP_BOOT_DEVICE(n)\
> + case BACKUP_BOOT_DEVICE_##n:\
> + return BOOT_DEVICE_##n;
I really don't like defining the macro in the function like this. And
in terms of style, I think I'd rather see it spelled out with
case/return as is normally done.
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/8] arm: K3: Add support for AM654 SoC definition
On Tue, Aug 21, 2018 at 08:00:49PM +0530, Lokesh Vutla wrote: > The AM654 device is designed for industrial automation and PLC > controller class platforms among other applications. Introduce > base support for AM654 SoC. [snip] > +config NON_SECURE_MSRAM_SIZE > + hex "Size of the MCU OC-MSRAM" > + default 0x8 > + help > + Describes the total size of the MCU MSRAM. This doesn't > + specify the total size of SPL as ROM can use some part > + of this RAM. Once ROM gives control to SPL then this > + complete size can be usable. > + > +config MAX_DOWNLODABLE_IMAGE_SIZE > + hex "Maximum size of the image" > + default 0x58000 > + help > + Describes the maximum size of the image that ROM can download > + from any boot media. > + > +config MCU_SCRATCHPAD_BASE > + hex "Base address of Scratchpad RAM" > + default 0x4028 if SOC_K3_AM6 > + help > + Describes the base address of MCU Scratchpad RAM. > + > +config MCU_SCRATCHPAD_SIZE > + hex "Size of Scratchpad RAM" > + default 0x200 if SOC_K3_AM6 > + help > + Describes the size of MCU Scratchpad RAM. These are very generic names. And are these really things that can be configured and changed by the user? MAX_DOWNLODABLE_IMAGE_SIZE is something we usually set in CONFIG_SPL_MAX_SIZE but I imagine the overall architecture means that perhaps that's not the exact variable we're talking about here. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/8] arm: K3: Add initial support for TI's K3 generation of SoCs
On Tue, Aug 21, 2018 at 08:00:48PM +0530, Lokesh Vutla wrote: > Add support for Texas Instruments' K3 Generation Processor > families. [snip] > diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c > index 9c80090aa7..f48d82f051 100644 > --- a/drivers/serial/ns16550.c > +++ b/drivers/serial/ns16550.c > @@ -175,7 +175,7 @@ void NS16550_init(NS16550_t com_port, int baud_divisor) > ; > > serial_out(CONFIG_SYS_NS16550_IER, _port->ier); > -#if defined(CONFIG_ARCH_OMAP2PLUS) > +#if defined(CONFIG_ARCH_OMAP2PLUS) || defined(CONFIG_ARCH_K3) > serial_out(0x7, _port->mdr1); /* mode select reset TL16C750*/ > #endif > > @@ -183,7 +183,8 @@ void NS16550_init(NS16550_t com_port, int baud_divisor) > serial_out(ns16550_getfcr(com_port), _port->fcr); > if (baud_divisor != -1) > NS16550_setbrg(com_port, baud_divisor); > -#if defined(CONFIG_ARCH_OMAP2PLUS) || defined(CONFIG_SOC_DA8XX) > +#if defined(CONFIG_ARCH_OMAP2PLUS) || defined(CONFIG_SOC_DA8XX) || \ > + defined(CONFIG_ARCH_K3) > /* /16 is proper to hit 115200 with 48MHz */ > serial_out(0, _port->mdr1); > #endif K3 would also be using CONFIG_OMAP_SERIAL once https://patchwork.ozlabs.org/patch/956252/ is applied (which I'll do in the next release) yes? I think 956252 needs a follow-up that changes the above hunks to be testing off CONFIG_OMAP_SERIAL instead so this part of the series just becomes changing the default y line for OMAP_SERIAL. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd: nand: denali_dt: Add reset support
On 08/24/2018 03:05 PM, Masahiro Yamada wrote:
> Hi Marek,
Hi,
> 2018-08-21 22:57 GMT+09:00 Marek Vasut :
>> Add optional reset support into the Denali NAND driver. In case there is
>> a valid reset entry in the DT, the reset gets deasserted before the NAND
>> controller gets used.
>>
>> Signed-off-by: Marek Vasut
>> Cc: Masahiro Yamada
>> ---
>> drivers/mtd/nand/denali_dt.c | 9 +
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/drivers/mtd/nand/denali_dt.c b/drivers/mtd/nand/denali_dt.c
>> index 65a7797f0f..6fcd7d3843 100644
>> --- a/drivers/mtd/nand/denali_dt.c
>> +++ b/drivers/mtd/nand/denali_dt.c
>> @@ -9,6 +9,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include "denali.h"
>>
>> @@ -64,6 +65,7 @@ static int denali_dt_probe(struct udevice *dev)
>> const struct denali_dt_data *data;
>> struct clk clk;
>> struct resource res;
>> + struct reset_ctl reset_ctl;
>> int ret;
>>
>> data = (void *)dev_get_driver_data(dev);
>> @@ -97,6 +99,13 @@ static int denali_dt_probe(struct udevice *dev)
>>
>> denali->clk_x_rate = clk_get_rate();
>>
>> + ret = reset_get_by_index(dev, 0, _ctl);
>> + if (!ret) {
>> + reset_assert(_ctl);
>> + udelay(2);
>> + reset_deassert(_ctl);
>> + }
>> +
>> return denali_init(denali);
>> }
>>
>
>
> I was testing this patch today
> because my SoC also has a reset line for NAND.
>
>
> This patch looks trivial enough,
> but if the NAND is reset here,
> my board fails to boot with
> "nand_base: timeout while waiting for chip to become ready"
>
>
> I do not know why.
> Please give me more time to figure out what is going on in my SoC.
Sure. Maybe you need to un-reset more stuff or the reset polarity is wrong ?
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd: nand: denali_dt: Add reset support
Hi Marek,
2018-08-21 22:57 GMT+09:00 Marek Vasut :
> Add optional reset support into the Denali NAND driver. In case there is
> a valid reset entry in the DT, the reset gets deasserted before the NAND
> controller gets used.
>
> Signed-off-by: Marek Vasut
> Cc: Masahiro Yamada
> ---
> drivers/mtd/nand/denali_dt.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/mtd/nand/denali_dt.c b/drivers/mtd/nand/denali_dt.c
> index 65a7797f0f..6fcd7d3843 100644
> --- a/drivers/mtd/nand/denali_dt.c
> +++ b/drivers/mtd/nand/denali_dt.c
> @@ -9,6 +9,7 @@
> #include
> #include
> #include
> +#include
>
> #include "denali.h"
>
> @@ -64,6 +65,7 @@ static int denali_dt_probe(struct udevice *dev)
> const struct denali_dt_data *data;
> struct clk clk;
> struct resource res;
> + struct reset_ctl reset_ctl;
> int ret;
>
> data = (void *)dev_get_driver_data(dev);
> @@ -97,6 +99,13 @@ static int denali_dt_probe(struct udevice *dev)
>
> denali->clk_x_rate = clk_get_rate();
>
> + ret = reset_get_by_index(dev, 0, _ctl);
> + if (!ret) {
> + reset_assert(_ctl);
> + udelay(2);
> + reset_deassert(_ctl);
> + }
> +
> return denali_init(denali);
> }
>
I was testing this patch today
because my SoC also has a reset line for NAND.
This patch looks trivial enough,
but if the NAND is reset here,
my board fails to boot with
"nand_base: timeout while waiting for chip to become ready"
I do not know why.
Please give me more time to figure out what is going on in my SoC.
U-Boot SPL 2018.09-rc2-00106-g5f0d7e5-dirty (Aug 24 2018 - 22:00:33 +0900)
Trying to boot from NOR
U-Boot 2018.09-rc2-00106-g5f0d7e5-dirty (Aug 24 2018 - 22:00:33 +0900)
SoC: LD4 (model 1, revision 3)
Model: UniPhier LD4 Reference Board
DRAM: 512 MiB
SC:Micro Support Card (CPLD version 3.6)
NAND: nand_base: timeout while waiting for chip to become ready
--
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 4/4] board: topic-miamiplus: Run IO PLL at 1000 MHz
The miamiplus can use GEM0 through MIO pins, which requires a 125 MHz TX
clock to be generated. With the IO PLL at 1200 MHz this isn't possible, so
change it to run at 1000 and adjust the divisors accordingly. Also set the
GEM0 clock source to MIO instead of EMIO.
Signed-off-by: Mike Looijmans
---
.../topic/zynq/zynq-topic-miamiplus/ps7_init_gpl.c | 30 ++
1 file changed, 14 insertions(+), 16 deletions(-)
diff --git a/board/topic/zynq/zynq-topic-miamiplus/ps7_init_gpl.c
b/board/topic/zynq/zynq-topic-miamiplus/ps7_init_gpl.c
index fd5846a..d90a350 100644
--- a/board/topic/zynq/zynq-topic-miamiplus/ps7_init_gpl.c
+++ b/board/topic/zynq/zynq-topic-miamiplus/ps7_init_gpl.c
@@ -24,8 +24,8 @@ static unsigned long ps7_pll_init_data_3_0[] = {
EMIT_MASKPOLL(0XF800010C, 0x0002U),
EMIT_MASKWRITE(0XF8000104, 0x0010U, 0xU),
EMIT_MASKWRITE(0XF8000124, 0xFFF3U, 0x0C23U),
- EMIT_MASKWRITE(0XF8000118, 0x0030U, 0x00113220U),
- EMIT_MASKWRITE(0XF8000108, 0x0007F000U, 0x00024000U),
+ EMIT_MASKWRITE(0XF8000118, 0x0030U, 0x001452C0U),
+ EMIT_MASKWRITE(0XF8000108, 0x0007F000U, 0x0001E000U),
EMIT_MASKWRITE(0XF8000108, 0x0010U, 0x0010U),
EMIT_MASKWRITE(0XF8000108, 0x0001U, 0x0001U),
EMIT_MASKWRITE(0XF8000108, 0x0001U, 0xU),
@@ -37,20 +37,18 @@ static unsigned long ps7_pll_init_data_3_0[] = {
static unsigned long ps7_clock_init_data_3_0[] = {
EMIT_MASKWRITE(0XF808, 0xU, 0xDF0DU),
- EMIT_MASKWRITE(0XF8000128, 0x03F03F01U, 0x00302301U),
- EMIT_MASKWRITE(0XF8000138, 0x0011U, 0x0011U),
+ EMIT_MASKWRITE(0XF8000128, 0x03F03F01U, 0x00700F01U),
+ EMIT_MASKWRITE(0XF8000138, 0x0011U, 0x0001U),
EMIT_MASKWRITE(0XF800013C, 0x0011U, 0x0011U),
- EMIT_MASKWRITE(0XF8000140, 0x03F03F71U, 0x00100141U),
- EMIT_MASKWRITE(0XF8000144, 0x03F03F71U, 0x00100141U),
- EMIT_MASKWRITE(0XF8000148, 0x3F31U, 0x0C01U),
- EMIT_MASKWRITE(0XF800014C, 0x3F31U, 0x0601U),
- EMIT_MASKWRITE(0XF8000150, 0x3F33U, 0x1803U),
- EMIT_MASKWRITE(0XF8000154, 0x3F33U, 0x0C03U),
- EMIT_MASKWRITE(0XF8000158, 0x3F33U, 0x0601U),
- EMIT_MASKWRITE(0XF8000168, 0x3F31U, 0x0601U),
- EMIT_MASKWRITE(0XF8000170, 0x03F03F30U, 0x00100C00U),
- EMIT_MASKWRITE(0XF8000180, 0x03F03F30U, 0x00100C00U),
- EMIT_MASKWRITE(0XF8000190, 0x03F03F30U, 0x00100600U),
+ EMIT_MASKWRITE(0XF8000140, 0x03F03F71U, 0x00100801U),
+ EMIT_MASKWRITE(0XF800014C, 0x3F31U, 0x0501U),
+ EMIT_MASKWRITE(0XF8000150, 0x3F33U, 0x0A01U),
+ EMIT_MASKWRITE(0XF8000154, 0x3F33U, 0x0A03U),
+ EMIT_MASKWRITE(0XF8000158, 0x3F33U, 0x0501U),
+ EMIT_MASKWRITE(0XF8000168, 0x3F31U, 0x0501U),
+ EMIT_MASKWRITE(0XF8000170, 0x03F03F30U, 0x00200500U),
+ EMIT_MASKWRITE(0XF8000180, 0x03F03F30U, 0x00100700U),
+ EMIT_MASKWRITE(0XF8000190, 0x03F03F30U, 0x00100500U),
EMIT_MASKWRITE(0XF80001A0, 0x03F03F30U, 0x00101800U),
EMIT_MASKWRITE(0XF80001C4, 0x0001U, 0x0001U),
EMIT_MASKWRITE(0XF800012C, 0x01FFCCCDU, 0x01FC4C4DU),
@@ -88,7 +86,7 @@ static unsigned long ps7_ddr_init_data_3_0[] = {
EMIT_MASKWRITE(0XF8006078, 0x03FFU, 0x00466111U),
EMIT_MASKWRITE(0XF800607C, 0x000FU, 0x0003U),
EMIT_MASKWRITE(0XF80060A4, 0xU, 0x10200802U),
- EMIT_MASKWRITE(0XF80060A8, 0x0FFFU, 0x0690CB73U),
+ EMIT_MASKWRITE(0XF80060A8, 0x0FFFU, 0x0690CB52U),
EMIT_MASKWRITE(0XF80060AC, 0x01FFU, 0x01FEU),
EMIT_MASKWRITE(0XF80060B0, 0x1FFFU, 0x1CFFU),
EMIT_MASKWRITE(0XF80060B4, 0x0200U, 0x0200U),
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/4] board: topic_miamilite: Support cost-reduced version
To reduce board cost, the topic-miamilite board hardware was adapted. It now
only has single QSPI NOR flash and a single DDR RAM chip. This reduces the
memory interface to 16-bit and halves the available RAM and flash.
Signed-off-by: Mike Looijmans
---
arch/arm/dts/zynq-topic-miamilite.dts| 7 ---
board/topic/zynq/zynq-topic-miamilite/ps7_init_gpl.c | 14 +++---
board/topic/zynq/zynq-topic-miamilite/ps7_regs.txt | 14 +++---
include/configs/topic_miami.h| 7 +--
include/configs/topic_miamilite.h| 11 +++
5 files changed, 34 insertions(+), 19 deletions(-)
create mode 100644 include/configs/topic_miamilite.h
diff --git a/arch/arm/dts/zynq-topic-miamilite.dts
b/arch/arm/dts/zynq-topic-miamilite.dts
index 366fd5b..c06549c 100644
--- a/arch/arm/dts/zynq-topic-miamilite.dts
+++ b/arch/arm/dts/zynq-topic-miamilite.dts
@@ -9,8 +9,9 @@
/ {
model = "Topic Miami Lite Zynq Board";
compatible = "topic,miamilite", "xlnx,zynq-7000";
-};
- {
- is-dual = <1>;
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x2000>;
+ };
};
diff --git a/board/topic/zynq/zynq-topic-miamilite/ps7_init_gpl.c
b/board/topic/zynq/zynq-topic-miamilite/ps7_init_gpl.c
index afec403..28670bd 100644
--- a/board/topic/zynq/zynq-topic-miamilite/ps7_init_gpl.c
+++ b/board/topic/zynq/zynq-topic-miamilite/ps7_init_gpl.c
@@ -59,7 +59,7 @@ static unsigned long ps7_clock_init_data_3_0[] = {
};
static unsigned long ps7_ddr_init_data_3_0[] = {
- EMIT_MASKWRITE(0xF8006000, 0x0001U, 0x0080U),
+ EMIT_MASKWRITE(0xF8006000, 0x0001U, 0x0084U),
EMIT_MASKWRITE(0xF8006004, 0x0007U, 0x1081U),
EMIT_MASKWRITE(0xF8006008, 0x03FFU, 0x03C0780FU),
EMIT_MASKWRITE(0xF800600C, 0x03FFU, 0x02001001U),
@@ -74,9 +74,9 @@ static unsigned long ps7_ddr_init_data_3_0[] = {
EMIT_MASKWRITE(0xF8006030, 0xU, 0x00040930U),
EMIT_MASKWRITE(0xF8006034, 0x13FF3FFFU, 0x000116D4U),
EMIT_MASKWRITE(0xF8006038, 0x0003U, 0xU),
- EMIT_MASKWRITE(0xF800603C, 0x000FU, 0x0777U),
- EMIT_MASKWRITE(0xF8006040, 0xU, 0xFFF0U),
- EMIT_MASKWRITE(0xF8006044, 0x0FFFU, 0x0F66U),
+ EMIT_MASKWRITE(0xF800603C, 0x000FU, 0x0666U),
+ EMIT_MASKWRITE(0xF8006040, 0xU, 0xU),
+ EMIT_MASKWRITE(0xF8006044, 0x0FFFU, 0x0F55U),
EMIT_MASKWRITE(0xF8006048, 0x0003F03FU, 0x0003C008U),
EMIT_MASKWRITE(0xF8006050, 0xFF0F8FFFU, 0x77010800U),
EMIT_MASKWRITE(0xF8006058, 0x0001U, 0xU),
@@ -102,8 +102,8 @@ static unsigned long ps7_ddr_init_data_3_0[] = {
EMIT_MASKWRITE(0xF8006114, 0x00FFU, 0xU),
EMIT_MASKWRITE(0xF8006118, 0x7FCFU, 0x4001U),
EMIT_MASKWRITE(0xF800611C, 0x7FCFU, 0x4001U),
- EMIT_MASKWRITE(0xF8006120, 0x7FCFU, 0x4001U),
- EMIT_MASKWRITE(0xF8006124, 0x7FCFU, 0x4001U),
+ EMIT_MASKWRITE(0xF8006120, 0x7FCFU, 0x4000U),
+ EMIT_MASKWRITE(0xF8006124, 0x7FCFU, 0x4000U),
EMIT_MASKWRITE(0xF800612C, 0x000FU, 0x0003482CU),
EMIT_MASKWRITE(0xF8006130, 0x000FU, 0x00033032U),
EMIT_MASKWRITE(0xF8006134, 0x000FU, 0x0002E81FU),
@@ -140,7 +140,7 @@ static unsigned long ps7_ddr_init_data_3_0[] = {
EMIT_MASKWRITE(0xF80062B0, 0x003FU, 0x5125U),
EMIT_MASKWRITE(0xF80062B4, 0x0003U, 0x12A8U),
EMIT_MASKPOLL(0xF8000B74, 0x2000U),
- EMIT_MASKWRITE(0xF8006000, 0x0001U, 0x0081U),
+ EMIT_MASKWRITE(0xF8006000, 0x0001U, 0x0085U),
EMIT_MASKPOLL(0xF8006054, 0x0007U),
EMIT_EXIT(),
};
diff --git a/board/topic/zynq/zynq-topic-miamilite/ps7_regs.txt
b/board/topic/zynq/zynq-topic-miamilite/ps7_regs.txt
index db6e642..08d5344 100644
--- a/board/topic/zynq/zynq-topic-miamilite/ps7_regs.txt
+++ b/board/topic/zynq/zynq-topic-miamilite/ps7_regs.txt
@@ -1,5 +1,5 @@
0xF8000120 0x1F000200 // ARM_CLK_CTRL - divisor = 2 433 MHz (?)
-0xf8000700 0x202
+0xf8000700 0x200
0xf8000704 0x202
0xf8000708 0x202
0xf800070c 0x202
@@ -8,11 +8,11 @@
0xf8000718 0x202
0xf800071c 0x200
0xf8000720 0x202
-0xf8000724 0x202
-0xf8000728 0x202
-0xf800072c 0x202
-0xf8000730 0x202
-0xf8000734 0x202
+0xf8000724 0x200
+0xf8000728 0x200
+0xf800072c 0x200
+0xf8000730 0x200
+0xf8000734 0x200
0xf8000738 0x12e1
0xf800073c 0x12e0
0xf8000740 0x1200
@@ -58,4 +58,4 @@
0xF800014C 0x0621 // LQSPI_CLK_CTRL - ARMPLL/6 (200 MHz)
0xE000D000 0x800238C1 // QSPI config - divide-by-2
0xE000D038 0x0020 // QSPI loopback - internal, 0 delay
-0xE000D0A0 0xE2FF06EB // LQSPI_CFG - Quad read, dual flash
+0xE000D0A0 0x82FF04EB // LQSPI_CFG - QIOREAD mode, Numonyx/Micron
diff --git a/include/configs/topic_miami.h b/include/configs/topic_miami.h
index
[U-Boot] [PATCH 1/4] topic-miamiplus: Run CPU at 800MHz for speedgrade-2
The miamiplus contains a speedgrade-2 device, which may run the CPU at 800MHz.
Change the PLL setting to 800MHz, and adapt the setpoints in the devicetree.
Signed-off-by: Mike Looijmans
---
arch/arm/dts/zynq-topic-miamiplus.dts| 9 +
board/topic/zynq/zynq-topic-miamiplus/ps7_init_gpl.c | 4 ++--
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/zynq-topic-miamiplus.dts
b/arch/arm/dts/zynq-topic-miamiplus.dts
index c0ccea9..df53886 100644
--- a/arch/arm/dts/zynq-topic-miamiplus.dts
+++ b/arch/arm/dts/zynq-topic-miamiplus.dts
@@ -11,6 +11,15 @@
compatible = "topic,miamiplus", "xlnx,zynq-7000";
};
+/* The miamiplus contains a speedgrade-2 device and runs at 800MHz */
+ {
+ operating-points = <
+ /* kHzuV */
+ 80 100
+ 40 100
+ >;
+};
+
{
is-dual = <1>;
};
diff --git a/board/topic/zynq/zynq-topic-miamiplus/ps7_init_gpl.c
b/board/topic/zynq/zynq-topic-miamiplus/ps7_init_gpl.c
index c1cc1df..fd5846a 100644
--- a/board/topic/zynq/zynq-topic-miamiplus/ps7_init_gpl.c
+++ b/board/topic/zynq/zynq-topic-miamiplus/ps7_init_gpl.c
@@ -8,8 +8,8 @@
static unsigned long ps7_pll_init_data_3_0[] = {
EMIT_MASKWRITE(0XF808, 0xU, 0xDF0DU),
- EMIT_MASKWRITE(0XF8000110, 0x0030U, 0x000FA220U),
- EMIT_MASKWRITE(0XF8000100, 0x0007F000U, 0x00028000U),
+ EMIT_MASKWRITE(0XF8000110, 0x0030U, 0x000FA240U),
+ EMIT_MASKWRITE(0XF8000100, 0x0007F000U, 0x0003U),
EMIT_MASKWRITE(0XF8000100, 0x0010U, 0x0010U),
EMIT_MASKWRITE(0XF8000100, 0x0001U, 0x0001U),
EMIT_MASKWRITE(0XF8000100, 0x0001U, 0xU),
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/4] configs/topic_miami.h: Use same partitioning for USB boot as for SD
Use the same partitioning as the SD card by default. This allows to
insert an SD card into a USB reader or use an USB drive with the same
partitioning and boot using that instead of requiring a ramdisk image.
Signed-off-by: Mike Looijmans
---
include/configs/topic_miami.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/configs/topic_miami.h b/include/configs/topic_miami.h
index c32c63c..6f8f2b4 100644
--- a/include/configs/topic_miami.h
+++ b/include/configs/topic_miami.h
@@ -63,15 +63,15 @@
# endif
# define EXTRA_ENV_USB \
"usbreset=" ENV_USB_RESET "\0" \
- "usbboot=run usbreset && if usb start; then " \
+ "usbboot=run usbreset; if usb start; then " \
"echo Booting from USB... && " \
"if load usb 0 0x190 ${bootscript}; then "\
"source 0x190; fi; " \
- "load usb 0 ${kernel_addr} ${kernel_image} && " \
- "load usb 0 ${devicetree_addr} ${devicetree_image} && " \
- "load usb 0 ${ramdisk_load_address} ${ramdisk_image} && " \
- "bootm ${kernel_addr} ${ramdisk_load_address} "\
- "${devicetree_addr}; " \
+ "setenv bootargs console=ttyPS0,115200 " \
+ "root=/dev/sda2 rw rootfstype=ext4 rootwait quiet; " \
+ "load usb 0 ${kernel_addr} ${kernel_image}&& " \
+ "load usb 0 ${devicetree_addr} ${devicetree_image}&& " \
+ "bootm ${kernel_addr} - ${devicetree_addr}; " \
"fi\0"
/* Note that addresses here should match the addresses in the env */
# undef DFU_ALT_INFO
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/4] Topic board support updates
There have been hardware changes to a few topic-miami boards, these are included in these commits (the production version of the "lite" became cheaper, the "plus" was made faster). Also improvements for usability. @Michal: These also apply cleanly to u-boot-xlnx, it'd be great if they could be included there as well. Mike Looijmans (4): topic-miamiplus: Run CPU at 800MHz for speedgrade-2 board: topic_miamilite: Support cost-reduced version configs/topic_miami.h: Use same partitioning for USB boot as for SD board: topic-miamiplus: Run IO PLL at 1000 MHz arch/arm/dts/zynq-topic-miamilite.dts | 7 +++-- arch/arm/dts/zynq-topic-miamiplus.dts | 9 ++ .../topic/zynq/zynq-topic-miamilite/ps7_init_gpl.c | 14 - board/topic/zynq/zynq-topic-miamilite/ps7_regs.txt | 14 - .../topic/zynq/zynq-topic-miamiplus/ps7_init_gpl.c | 34 ++ include/configs/topic_miami.h | 19 +++- include/configs/topic_miamilite.h | 11 +++ 7 files changed, 65 insertions(+), 43 deletions(-) create mode 100644 include/configs/topic_miamilite.h -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC] cmd: add bootslot command to select/boot slot based on boot counts
With RAUC bootslot's is specified with uppercase letters, uppercase is not preserved. We end up with BOOT_b_LEFT=2... botocmd_* is with lowercase, just to make things easier. I cannot reproduce the lowercase issue. Can you send me your (def)config and environment? % grep BOOTSLOT .config CONFIG_CMD_BOOTSLOT=y CONFIG_CMD_BOOTSLOT_ENV_SLOTS="BOOTORDER" CONFIG_CMD_BOOTSLOT_ENV_COUNT="BOOT_%s_LEFT" CONFIG_CMD_BOOTSLOT_ENV_CMD="BOOTCMD_%s" CONFIG_CMD_BOOTSLOT_DEFAULT_COUNT=3 % grep -i boot board/raspberrypi/rpi/env.txt BOOTORDER=A B bootargs_all=console=ttyS0,115200n8 rootfstype=squashfs rootwait bootargs_a=root=/dev/mmcblk0p2 bootslot=A bootargs_b=root=/dev/mmcblk0p3 bootslot=B set_bootargs_a=setenv bootargs $bootargs_all $bootargs_a set_bootargs_b=setenv bootargs $bootargs_all $bootargs_b bootcmd_common=run load_kernel; booti $loadaddr - $fdtcontroladdr BOOTCMD_A=run set_bootargs_a bootcmd_common BOOTCMD_B=run set_bootargs_b bootcmd_common bootcmd=bootslot boot Hi, I'm not able to reproduce the lowercase issue, I must have got the config wrong :-) Please submit a [PATCH] for this as it could be very useful. /Sean ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] Make kmalloc'ed memory really DMA-safe
In Linux, the memory returned by kmalloc() is DMA-capable.
However, it is not true in U-Boot.
At a glance, kmalloc() in U-Boot returns address aligned with
ARCH_DMA_MINALIGN. However, it never pads the allocated memory.
This half-way house is completely useless because calling kmalloc()
and malloc() in this order causes a cache sharing problem.
Change the implementation to call malloc_cache_aligned(), which
allocates really DMA-capable memory.
Signed-off-by: Masahiro Yamada
---
lib/linux_compat.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/lib/linux_compat.c b/lib/linux_compat.c
index a936a7e..6373b44 100644
--- a/lib/linux_compat.c
+++ b/lib/linux_compat.c
@@ -1,5 +1,6 @@
#include
+#include
#include
struct p_current cur = {
@@ -18,7 +19,7 @@ void *kmalloc(size_t size, int flags)
{
void *p;
- p = memalign(ARCH_DMA_MINALIGN, size);
+ p = malloc_cache_aligned(size);
if (flags & __GFP_ZERO)
memset(p, 0, size);
@@ -37,5 +38,5 @@ struct kmem_cache *get_mem(int element_sz)
void *kmem_cache_alloc(struct kmem_cache *obj, int flag)
{
- return memalign(ARCH_DMA_MINALIGN, obj->sz);
+ return malloc_cache_aligned(obj->sz);
}
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] x86: zimage: Remove acpi_rsdp_addr propagation to kernel boot parameters
On Thu, 2018-08-23 at 21:28 -0700, Bin Meng wrote:
> As of today, the proposal of adding "acpi_rsdp_addr" to the kernel
> boot protocol does not make its way to the kernel mainline. This
> creates some confusion if we leave it in the U-Boot code base.
> Remove it for now until we have a clear picture with kernel upstream.
>
> Note this eventually does a partial revert to commit 3469bf427454
> ("x86: zImage: Propagate acpi_rsdp_addr to kernel via boot
> parameters")
>
Acked-by: Andy Shevchenko
> Signed-off-by: Bin Meng
> ---
>
> arch/x86/include/asm/bootparam.h | 1 -
> arch/x86/lib/zimage.c| 5 -
> 2 files changed, 6 deletions(-)
>
> diff --git a/arch/x86/include/asm/bootparam.h
> b/arch/x86/include/asm/bootparam.h
> index 0386cbe..dfbd4b4 100644
> --- a/arch/x86/include/asm/bootparam.h
> +++ b/arch/x86/include/asm/bootparam.h
> @@ -69,7 +69,6 @@ struct setup_header {
> __u64 pref_address;
> __u32 init_size;
> __u32 handover_offset;
> - __u64 acpi_rsdp_addr;
> } __attribute__((packed));
>
> struct sys_desc_table {
> diff --git a/arch/x86/lib/zimage.c b/arch/x86/lib/zimage.c
> index 0442fda..230b38e 100644
> --- a/arch/x86/lib/zimage.c
> +++ b/arch/x86/lib/zimage.c
> @@ -287,11 +287,6 @@ int setup_zimage(struct boot_params *setup_base,
> char *cmd_line, int auto_boot,
> hdr->hardware_subarch = X86_SUBARCH_INTEL_MID;
> #endif
>
> -#ifdef CONFIG_GENERATE_ACPI_TABLE
> - if (bootproto >= 0x020e)
> - hdr->acpi_rsdp_addr = acpi_get_rsdp_addr();
> -#endif
> -
> setup_device_tree(hdr, (const void *)env_get_hex("fdtaddr", 0));
> setup_video(_base->screen_info);
>
--
Andy Shevchenko
Intel Finland Oy
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] Pull request: u-boot-sunxi/master
Hi Tom, Please pull this PR. thanks, Jagan. The following changes since commit b71d9e8b3805305ea4116733f515061710ad7081: Merge branch 'master' of git://git.denx.de/u-boot-sunxi (2018-08-20 13:41:56 -0400) are available in the Git repository at: git://git.denx.de/u-boot-sunxi.git master for you to fetch changes up to 12069bd0466a87015dd40bb25c6b2571ee5f0851: usb: musb-new: Call musb_platform_exit from musb_stop (2018-08-23 17:31:24 +0530) Jagan Teki (5): usb: musb-new: Fix improper musb host pointer usb: musb-new: sunxi: Allocate struct phy in private musb-new: sunxi: Access ahb_reset0_cfg via ccm offset usb: musb-new: sunxi: Add proper musb exit support usb: musb-new: Call musb_platform_exit from musb_stop board/compulab/cm_t3517/cm_t3517.c | 4 +- drivers/usb/musb-new/musb_core.c | 1 + drivers/usb/musb-new/musb_uboot.c | 12 ++--- drivers/usb/musb-new/pic32.c | 6 ++- drivers/usb/musb-new/sunxi.c | 107 ++--- include/linux/usb/musb.h | 4 +- 6 files changed, 80 insertions(+), 54 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3.3 14/58] musb-new: sunxi: Use CLK and RESET support
Now clock and reset drivers are available for respective
SoC's so use clk and reset ops on musb driver.
Signed-off-by: Jagan Teki
---
Changes for v3.3:
- drop flags, use has_reset
Changes for v3.2:
- add has_reset bool in existing driver data
Changes for v3.1:
- droped unused variables
- add flags for checking reset require or not
- handle clk and reset errors properly
drivers/usb/musb-new/sunxi.c | 94
1 file changed, 62 insertions(+), 32 deletions(-)
diff --git a/drivers/usb/musb-new/sunxi.c b/drivers/usb/musb-new/sunxi.c
index 9f71b84fd1..7126152a21 100644
--- a/drivers/usb/musb-new/sunxi.c
+++ b/drivers/usb/musb-new/sunxi.c
@@ -16,9 +16,11 @@
* This file is part of the Inventra Controller Driver for Linux.
*/
#include
+#include
#include
#include
#include
+#include
#include
#include
#include
@@ -78,16 +80,16 @@
struct sunxi_musb_config {
struct musb_hdrc_config *config;
- u8 rst_bit;
- u8 clkgate_bit;
+ bool has_reset;
};
struct sunxi_glue {
struct musb_host_data mdata;
- struct sunxi_ccm_reg *ccm;
struct sunxi_musb_config *cfg;
struct device dev;
struct phy phy;
+ struct clk clk;
+ struct reset_ctl rst;
};
#define to_sunxi_glue(d) container_of(d, struct sunxi_glue, dev)
@@ -291,25 +293,28 @@ static int sunxi_musb_init(struct musb *musb)
pr_debug("%s():\n", __func__);
+ ret = clk_enable(>clk);
+ if (ret) {
+ dev_err(dev, "failed to enable clock\n");
+ return ret;
+ }
+
+ if (glue->cfg->has_reset) {
+ ret = reset_deassert(>rst);
+ if (ret) {
+ dev_err(dev, "failed to deassert reset\n");
+ goto err_clk;
+ }
+ }
+
ret = generic_phy_init(>phy);
if (ret) {
pr_err("failed to init USB PHY\n");
- return ret;
+ goto err_rst;
}
musb->isr = sunxi_musb_interrupt;
- setbits_le32(>ccm->ahb_gate0, BIT(AHB_GATE_OFFSET_USB0));
- if (glue->cfg->clkgate_bit)
- setbits_le32(>ccm->ahb_gate0,
-BIT(glue->cfg->clkgate_bit));
-#ifdef CONFIG_SUNXI_GEN_SUN6I
- setbits_le32(>ccm->ahb_reset0_cfg, BIT(AHB_GATE_OFFSET_USB0));
- if (glue->cfg->rst_bit)
- setbits_le32(>ccm->ahb_reset0_cfg,
-BIT(glue->cfg->rst_bit));
-#endif
-
USBC_ConfigFIFO_Base();
USBC_EnableDpDmPullUp(musb->mregs);
USBC_EnableIdPullUp(musb->mregs);
@@ -324,6 +329,13 @@ static int sunxi_musb_init(struct musb *musb)
USBC_ForceVbusValidToHigh(musb->mregs);
return 0;
+
+err_rst:
+ if (glue->cfg->has_reset)
+ reset_assert(>rst);
+err_clk:
+ clk_disable(>clk);
+ return ret;
}
static int sunxi_musb_exit(struct musb *musb)
@@ -339,16 +351,19 @@ static int sunxi_musb_exit(struct musb *musb)
}
}
-#ifdef CONFIG_SUNXI_GEN_SUN6I
- clrbits_le32(>ccm->ahb_reset0_cfg, BIT(AHB_GATE_OFFSET_USB0));
- if (glue->cfg->rst_bit)
- clrbits_le32(>ccm->ahb_reset0_cfg,
-BIT(glue->cfg->rst_bit));
-#endif
- clrbits_le32(>ccm->ahb_gate0, BIT(AHB_GATE_OFFSET_USB0));
- if (glue->cfg->clkgate_bit)
- clrbits_le32(>ccm->ahb_gate0,
-BIT(glue->cfg->clkgate_bit));
+ if (glue->cfg->has_reset) {
+ ret = reset_assert(>rst);
+ if (ret) {
+ dev_err(dev, "failed to deassert reset\n");
+ return ret;
+ }
+ }
+
+ ret = clk_disable(>clk);
+ if (ret) {
+ dev_err(dev, "failed to enable clock\n");
+ return ret;
+ }
return 0;
}
@@ -442,9 +457,19 @@ static int musb_usb_probe(struct udevice *dev)
if (!glue->cfg)
return -EINVAL;
- glue->ccm = (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
- if (IS_ERR(glue->ccm))
- return PTR_ERR(glue->ccm);
+ ret = clk_get_by_index(dev, 0, >clk);
+ if (ret) {
+ dev_err(dev, "failed to get clock\n");
+ return ret;
+ }
+
+ if (glue->cfg->has_reset) {
+ ret = reset_get_by_index(dev, 0, >rst);
+ if (ret) {
+ dev_err(dev, "failed to get reset\n");
+ return ret;
+ }
+ }
ret = generic_phy_get_by_name(dev, "usb", >phy);
if (ret) {
@@ -495,21 +520,26 @@ static int musb_usb_remove(struct udevice *dev)
static const struct sunxi_musb_config sun4i_a10_cfg = {
.config = _config,
+ .has_reset = false,
+};
+
+static const struct sunxi_musb_config sun6i_a31_cfg = {
+ .config = _config,
+ .has_reset = true,
};
static
[U-Boot] [PATCH] armv8: lsch3: Add support of serdes3 module
Some lsch3 based SoCs like lx2160a contains three
serdes modules.
Add support for third serdes protocol in lsch3
Signed-off-by: Priyanka Jain
---
arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 3 +
.../cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c| 71 ++
.../include/asm/arch-fsl-layerscape/fsl_serdes.h | 2 +
3 files changed, 76 insertions(+)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
index f2111fa..fd31ae1 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
@@ -348,6 +348,9 @@ config SYS_FSL_SRDS_1
config SYS_FSL_SRDS_2
bool
+config SYS_FSL_SRDS_3
+ bool
+
config SYS_HAS_SERDES
bool
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c
b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c
index 2bef841..bfd2868 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c
@@ -1,5 +1,6 @@
// SPDX-License-Identifier: GPL-2.0+
/*
+ * Copyright 2018 NXP
* Copyright 2014-2015 Freescale Semiconductor, Inc.
*/
@@ -16,6 +17,9 @@ static u8 serdes1_prtcl_map[SERDES_PRCTL_COUNT];
#ifdef CONFIG_SYS_FSL_SRDS_2
static u8 serdes2_prtcl_map[SERDES_PRCTL_COUNT];
#endif
+#ifdef CONFIG_SYS_FSL_SRDS_3
+static u8 serdes3_prtcl_map[SERDES_PRCTL_COUNT];
+#endif
#if defined(CONFIG_FSL_MC_ENET) && !defined(CONFIG_SPL_BUILD)
int xfi_dpmac[XFI8 + 1];
@@ -57,6 +61,12 @@ int is_serdes_configured(enum srds_prtcl device)
ret |= serdes2_prtcl_map[device];
#endif
+#ifdef CONFIG_SYS_FSL_SRDS_3
+ if (!serdes3_prtcl_map[NONE])
+ fsl_serdes_init();
+
+ ret |= serdes3_prtcl_map[device];
+#endif
return !!ret;
}
@@ -82,6 +92,13 @@ int serdes_get_first_lane(u32 sd, enum srds_prtcl device)
cfg >>= FSL_CHASSIS3_SRDS2_PRTCL_SHIFT;
break;
#endif
+#ifdef CONFIG_SYS_FSL_SRDS_3
+ case FSL_SRDS_3:
+ cfg = gur_in32(>rcwsr[FSL_CHASSIS3_SRDS3_REGSR - 1]);
+ cfg &= FSL_CHASSIS3_SRDS3_PRTCL_MASK;
+ cfg >>= FSL_CHASSIS3_SRDS3_PRTCL_SHIFT;
+ break;
+#endif
default:
printf("invalid SerDes%d\n", sd);
break;
@@ -201,6 +218,12 @@ struct serdes_prctl_info srds_prctl_info[] = {
.shift = FSL_CHASSIS3_SRDS2_PRTCL_SHIFT
},
#endif
+#ifdef CONFIG_SYS_FSL_SRDS_3
+ {.id = 3,
+.mask = FSL_CHASSIS3_SRDS3_PRTCL_MASK,
+.shift = FSL_CHASSIS3_SRDS3_PRTCL_SHIFT
+ },
+#endif
{} /* NULL ENTRY */
};
@@ -341,6 +364,11 @@ int setup_serdes_volt(u32 svdd)
(void *)(CONFIG_SYS_FSL_LSCH3_SERDES_ADDR + 0x1);
u32 cfg_rcwsrds2 = gur_in32(>rcwsr[FSL_CHASSIS3_SRDS2_REGSR - 1]);
#endif
+#ifdef CONFIG_SYS_FSL_SRDS_3
+ struct ccsr_serdes __iomem *serdes3_base =
+ (void *)(CONFIG_SYS_FSL_LSCH3_SERDES_ADDR + 0x2);
+ u32 cfg_rcwsrds3 = gur_in32(>rcwsr[FSL_CHASSIS3_SRDS3_REGSR - 1]);
+#endif
u32 cfg_tmp;
int svdd_cur, svdd_tar;
int ret = 1;
@@ -370,6 +398,9 @@ int setup_serdes_volt(u32 svdd)
#ifdef CONFIG_SYS_FSL_SRDS_2
do_enabled_lanes_reset(2, cfg_rcwsrds2, serdes2_base, false);
#endif
+#ifdef CONFIG_SYS_FSL_SRDS_3
+ do_enabled_lanes_reset(3, cfg_rcwsrds3, serdes3_base, false);
+#endif
/* Put the all enabled PLL in reset */
#ifdef CONFIG_SYS_FSL_SRDS_1
@@ -383,6 +414,12 @@ int setup_serdes_volt(u32 svdd)
do_pll_reset(cfg_tmp, serdes2_base);
#endif
+#ifdef CONFIG_SYS_FSL_SRDS_3
+ cfg_tmp = cfg_rcwsrds3 & 0x30;
+ cfg_tmp >>= 4;
+ do_pll_reset(cfg_tmp, serdes3_base);
+#endif
+
/* Put the Rx/Tx calibration into reset */
#ifdef CONFIG_SYS_FSL_SRDS_1
do_rx_tx_cal_reset(serdes1_base);
@@ -392,6 +429,10 @@ int setup_serdes_volt(u32 svdd)
do_rx_tx_cal_reset(serdes2_base);
#endif
+#ifdef CONFIG_SYS_FSL_SRDS_3
+ do_rx_tx_cal_reset(serdes3_base);
+#endif
+
ret = set_serdes_volt(svdd);
if (ret < 0) {
printf("could not change SVDD\n");
@@ -408,6 +449,11 @@ int setup_serdes_volt(u32 svdd)
cfg_tmp >>= 2;
do_serdes_enable(cfg_tmp, serdes2_base);
#endif
+#ifdef CONFIG_SYS_FSL_SRDS_3
+ cfg_tmp = cfg_rcwsrds3 & 0x30;
+ cfg_tmp >>= 4;
+ do_serdes_enable(cfg_tmp, serdes3_base);
+#endif
/* Wait for at at least 625us, ensure the PLLs being reset are locked */
udelay(800);
@@ -422,6 +468,13 @@ int setup_serdes_volt(u32 svdd)
cfg_tmp >>= 2;
do_pll_lock(cfg_tmp, serdes2_base);
#endif
+
+#ifdef CONFIG_SYS_FSL_SRDS_3
+ cfg_tmp = cfg_rcwsrds3 & 0x30;
+ cfg_tmp >>= 4;
+ do_pll_lock(cfg_tmp, serdes3_base);
+#endif
+
/* Take the all enabled lanes out of reset */
#ifdef CONFIG_SYS_FSL_SRDS_1
do_enabled_lanes_reset(1,
