Re: [U-Boot] [PATCH 5/8] spl: nand: sunxi: use PIO instead of DMA
Hi, On Wed, Jan 24, 2018 at 01:44:51AM +0100, Miquel Raynal wrote: > Because using DMA implementation is not generic and was not developped > to work on SoCs like A33, migrate the SPL to use PIO. > > Signed-off-by: Miquel Raynal I guess the issue is slightly different than what you're saying, or at least should be expressed differently. The issue is that the SPL support has be done to support only the earlier generations of Allwinner SoCs, and only really enabled on the A13 / GR8. However, those old SoCs had a DMA engine that has been replaced since the A31 by another DMA controller that is no longer compatible. Since the code directly uses that DMA controller, it cannot operate properly on the later SoCs, while the NAND controller hasn't changed. There's two pathes forward, the first one would be to add support for that DMA controller too, or you can just remove the DMA usage entirely and rely on PIO that will make the driver simpler. Explaining why you chose PIO would be great too. > --- > board/sunxi/board.c | 4 +- > drivers/mtd/nand/sunxi_nand_spl.c | 167 > +- > 2 files changed, 79 insertions(+), 92 deletions(-) > > diff --git a/board/sunxi/board.c b/board/sunxi/board.c > index 70e01437c4..512e2c17a6 100644 > --- a/board/sunxi/board.c > +++ b/board/sunxi/board.c > @@ -266,11 +266,13 @@ static void nand_clock_setup(void) > struct sunxi_ccm_reg *const ccm = > (struct sunxi_ccm_reg *)SUNXI_CCM_BASE; > > - setbits_le32(&ccm->ahb_gate0, (CLK_GATE_OPEN << AHB_GATE_OFFSET_NAND0)); > + setbits_le32(&ccm->ahb_gate0, (1 << AHB_GATE_OFFSET_NAND0)); > + setbits_le32(&ccm->ahb_reset0_cfg, (1 << AHB_GATE_OFFSET_NAND0)); That has nothing to do with PIO vs DMA. It should be in another patch. > #ifdef CONFIG_MACH_SUN9I > setbits_le32(&ccm->ahb_gate1, (1 << AHB_GATE_OFFSET_DMA)); > #else > setbits_le32(&ccm->ahb_gate0, (1 << AHB_GATE_OFFSET_DMA)); > + setbits_le32(&ccm->ahb_reset0_cfg, (1 << AHB_GATE_OFFSET_DMA)); So you're de-asserting the reset line for the DMA controller, while the commit is about removing the need for that DMA controller ? :) That whole block can actually be removed (in a separate patch) now that you're not using DMA anymore. > #endif > setbits_le32(&ccm->nand0_clk_cfg, CCM_NAND_CTRL_ENABLE | AHB_DIV_1); > } > diff --git a/drivers/mtd/nand/sunxi_nand_spl.c > b/drivers/mtd/nand/sunxi_nand_spl.c > index 2488d5cb51..5de6825994 100644 > --- a/drivers/mtd/nand/sunxi_nand_spl.c > +++ b/drivers/mtd/nand/sunxi_nand_spl.c > @@ -10,6 +10,7 @@ > #include > #include > #include > +#include > > /* registers */ > #define NFC_CTL0x > @@ -45,32 +46,22 @@ > #define NFC_CTL_PAGE_SIZE_MASK (0xf << 8) > #define NFC_CTL_PAGE_SIZE(a) ((fls(a) - 11) << 8) > > - > #define NFC_ECC_EN (1 << 0) > -#define NFC_ECC_PIPELINE (1 << 3) > #define NFC_ECC_EXCEPTION (1 << 4) > #define NFC_ECC_BLOCK_SIZE (1 << 5) > #define NFC_ECC_RANDOM_EN (1 << 9) > -#define NFC_ECC_RANDOM_DIRECTION (1 << 10) > - > > #define NFC_ADDR_NUM_OFFSET16 > -#define NFC_ACCESS_DIR (1 << 20) > #define NFC_SEND_ADDR (1 << 19) > #define NFC_DATA_TRANS (1 << 21) > #define NFC_SEND_CMD1 (1 << 22) > #define NFC_WAIT_FLAG (1 << 23) > #define NFC_SEND_CMD2 (1 << 24) > -#define NFC_SEQ(1 << 25) > -#define NFC_DATA_SWAP_METHOD (1 << 26) > -#define NFC_ROW_AUTO_INC (1 << 27) > -#define NFC_SEND_CMD3 (1 << 28) > -#define NFC_SEND_CMD4 (1 << 29) > #define NFC_RAW_CMD(0 << 30) > -#define NFC_PAGE_CMD (2 << 30) > +#define NFC_ECC_CMD(1 << 30) > > #define NFC_ST_CMD_INT_FLAG(1 << 1) > -#define NFC_ST_DMA_INT_FLAG(1 << 2) > +#define NFC_ST_CMD_FIFO_STAT (1 << 3) > > #define NFC_READ_CMD_OFFSET 0 > #define NFC_RANDOM_READ_CMD0_OFFSET 8 > @@ -80,22 +71,6 @@ > #define NFC_CMD_RNDOUT 0x05 > #define NFC_CMD_READSTART 0x30 > > -#define SUNXI_DMA_CFG_REG0 0x300 > -#define SUNXI_DMA_SRC_START_ADDR_REG0 0x304 > -#define SUNXI_DMA_DEST_START_ADDRR_REG0 0x308 > -#define SUNXI_DMA_DDMA_BC_REG0 0x30C > -#define SUNXI_DMA_DDMA_PARA_REG00x318 > - > -#define SUNXI_DMA_DDMA_CFG_REG_LOADING (1 << 31) > -#define SUNXI_DMA_DDMA_CFG_REG_DMA_DEST_DATA_WIDTH_32 (2 << 25) > -#define SUNXI_DMA_DDMA_CFG_REG_DDMA_DST_DRQ_TYPE_DRAM (1 << 16) > -#define SUNXI_DMA_DDMA_CFG_REG_DMA_SRC_DATA_WIDTH_32 (2 << 9) > -#define SUNXI_DMA_DDMA_CFG_REG_DMA_SRC_ADDR_MODE_IO (1 << 5) > -#define SUNXI_DMA_DDMA_CFG_REG_DDMA_SRC_DRQ_TYPE_NFC (3 << 0) > - > -#define SUNXI_DMA_DDMA_PARA_REG_SRC_WAIT_CYC (0x0F << 0) > -#define SUNXI_DMA_DDMA_PARA_REG_SRC_BLK_SIZE (0x7F << 8) > - We should probab
Re: [U-Boot] [PATCH 4/8] spl: nand: sunxi: Enhancements and cleaning
On Wed, 24 Jan 2018 01:44:50 +0100
Miquel Raynal wrote:
> Do some cleaning in sunxi NAND SPL driver like adding helpers and
> clearing flags at the right spot
>
> Signed-off-by: Miquel Raynal
> ---
> drivers/mtd/nand/sunxi_nand_spl.c | 64
> +--
> 1 file changed, 41 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/mtd/nand/sunxi_nand_spl.c
> b/drivers/mtd/nand/sunxi_nand_spl.c
> index 06695fc15f..2488d5cb51 100644
> --- a/drivers/mtd/nand/sunxi_nand_spl.c
> +++ b/drivers/mtd/nand/sunxi_nand_spl.c
> @@ -55,8 +55,8 @@
>
>
> #define NFC_ADDR_NUM_OFFSET16
> -#define NFC_SEND_ADR (1 << 19)
> #define NFC_ACCESS_DIR (1 << 20)
> +#define NFC_SEND_ADDR (1 << 19)
This typo fix probably deserves a separate patch.
> #define NFC_DATA_TRANS (1 << 21)
> #define NFC_SEND_CMD1 (1 << 22)
> #define NFC_WAIT_FLAG (1 << 23)
> @@ -155,6 +155,30 @@ static inline int check_value_negated(int offset, int
> unexpected_bits,
> return check_value_inner(offset, unexpected_bits, timeout_us, 1);
> }
>
> +static int nand_wait_cmd_fifo_empty(void)
> +{
> + if (!check_value_negated(SUNXI_NFC_BASE + NFC_ST, NFC_ST_CMD_FIFO_STAT,
> + DEFAULT_TIMEOUT_US)) {
> + printf("nand: timeout waiting for empty cmd FIFO\n");
> + return -ETIMEDOUT;
> + }
> +
> + return 0;
> +}
> +
> +static int nand_wait_int(void)
> +{
> + if (!check_value(SUNXI_NFC_BASE + NFC_ST, NFC_ST_CMD_INT_FLAG,
> + DEFAULT_TIMEOUT_US)) {
> + printf("nand: timeout waiting for interruption\n");
> + return -ETIMEDOUT;
> + }
> +
> + udelay(1);
I'm pretty sure this udelay() is not required. Probably some leftover
of your debug session ;-).
> +
> + return 0;
> +}
> +
> void nand_init(void)
> {
> uint32_t val;
> @@ -172,22 +196,21 @@ void nand_init(void)
> }
>
> /* reset NAND */
> + nand_wait_cmd_fifo_empty();
> +
> writel(NFC_ST_CMD_INT_FLAG, SUNXI_NFC_BASE + NFC_ST);
> writel(NFC_SEND_CMD1 | NFC_WAIT_FLAG | NAND_CMD_RESET,
> SUNXI_NFC_BASE + NFC_CMD);
>
> - if (!check_value(SUNXI_NFC_BASE + NFC_ST, NFC_ST_CMD_INT_FLAG,
> - DEFAULT_TIMEOUT_US)) {
> - printf("Error timeout waiting for nand reset\n");
> - return;
> - }
> - writel(NFC_ST_CMD_INT_FLAG, SUNXI_NFC_BASE + NFC_ST);
> + nand_wait_int();
I would go even further and create an helper that takes care of the
'wait_fifo_empty+clear_int+write_cmd+wait_int' sequence:
static int nand_exec_cmd(u32 cmd)
{
int ret;
ret = nand_wait_cmd_fifo_empty();
if (ret)
return ret;
writel(NFC_ST_CMD_INT_FLAG, SUNXI_NFC_BASE + NFC_ST);
writel(cmd, SUNXI_NFC_BASE + NFC_CMD);
return nand_wait_int();
}
> }
>
> static void nand_apply_config(const struct nfc_config *conf)
> {
> u32 val;
>
> + nand_wait_cmd_fifo_empty();
> +
> val = readl(SUNXI_NFC_BASE + NFC_CTL);
> val &= ~NFC_CTL_PAGE_SIZE_MASK;
> writel(val | NFC_CTL_RAM_METHOD | NFC_CTL_PAGE_SIZE(conf->page_size),
> @@ -200,6 +223,8 @@ static int nand_load_page(const struct nfc_config *conf,
> u32 offs)
> {
> int page = offs / conf->page_size;
>
> + nand_wait_cmd_fifo_empty();
> +
> writel((NFC_CMD_RNDOUTSTART << NFC_RANDOM_READ_CMD1_OFFSET) |
> (NFC_CMD_RNDOUT << NFC_RANDOM_READ_CMD0_OFFSET) |
> (NFC_CMD_READSTART << NFC_READ_CMD_OFFSET),
> @@ -208,38 +233,32 @@ static int nand_load_page(const struct nfc_config
> *conf, u32 offs)
> writel((page >> 16) & 0xFF, SUNXI_NFC_BASE + NFC_ADDR_HIGH);
> writel(NFC_ST_CMD_INT_FLAG, SUNXI_NFC_BASE + NFC_ST);
> writel(NFC_SEND_CMD1 | NFC_SEND_CMD2 | NFC_RAW_CMD | NFC_WAIT_FLAG |
> -((conf->addr_cycles - 1) << NFC_ADDR_NUM_OFFSET) | NFC_SEND_ADR,
> +((conf->addr_cycles - 1) << NFC_ADDR_NUM_OFFSET) | NFC_SEND_ADDR,
> SUNXI_NFC_BASE + NFC_CMD);
>
> - if (!check_value(SUNXI_NFC_BASE + NFC_ST, NFC_ST_CMD_INT_FLAG,
> - DEFAULT_TIMEOUT_US)) {
> - printf("Error while initializing dma interrupt\n");
> - return -EIO;
> - }
> -
> - return 0;
> + return nand_wait_int();
> }
>
> static int nand_reset_column(void)
> {
> + nand_wait_cmd_fifo_empty();
> +
> writel((NFC_CMD_RNDOUTSTART << NFC_RANDOM_READ_CMD1_OFFSET) |
> (NFC_CMD_RNDOUT << NFC_RANDOM_READ_CMD0_OFFSET) |
> (NFC_CMD_RNDOUTSTART << NFC_READ_CMD_OFFSET),
> SUNXI_NFC_BASE + NFC_RCMD_SET);
> + writel(NFC_ST_CMD_INT_FLAG, SUNXI_NFC_BASE + NFC_ST);
> writel(0, SUNXI_NFC_BASE + NFC_ADDR_LOW);
> writel(NFC_SEND_CMD1 | NFC_SEND_CMD2 | NFC_RAW_CMD |
> -(1 << NFC_ADDR_NUM_OFFSET) | NFC_SEND_ADR
Re: [U-Boot] [PATCH 6/8] configs: Add NAND support for NES Classic
Hi, On Wed, Jan 24, 2018 at 01:44:52AM +0100, Miquel Raynal wrote: > Add NAND parameters to the Nintendo NES Classic configuration file. > > Signed-off-by: Miquel Raynal > --- > configs/Nintendo_NES_Classic_Edition_defconfig | 4 > 1 file changed, 4 insertions(+) > > diff --git a/configs/Nintendo_NES_Classic_Edition_defconfig > b/configs/Nintendo_NES_Classic_Edition_defconfig > index d05375d0db..467055279c 100644 > --- a/configs/Nintendo_NES_Classic_Edition_defconfig > +++ b/configs/Nintendo_NES_Classic_Edition_defconfig > @@ -9,6 +9,10 @@ CONFIG_AXP_GPIO=y > CONFIG_DEFAULT_DEVICE_TREE="sun8i-r16-nintendo-nes-classic-edition" > # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set > CONFIG_SPL=y > +CONFIG_SPL_NAND_SUPPORT=y This could be selected (or implied) by NAND_SUNXI > +CONFIG_SYS_EXTRA_OPTIONS="SYS_NAND_BLOCK_SIZE=0x2,SYS_NAND_PAGE_SIZE=2048,SYS_NAND_OOBSIZE=64" Can you move this to Kconfig? > +CONFIG_NAND=y > +CONFIG_NAND_SUNXI=y And we can add a default ARCH_SUNXI on NAND_SUNXI here, which means that we'd only have the NAND parameters and the CONFIG_NAND in defconfig, reducing the boilerplate. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.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 7/8] sunxi: dts: Add NAND node to sun8i DTSI
Hi,
On Wed, Jan 24, 2018 at 01:44:53AM +0100, Miquel Raynal wrote:
> Add the NAND controller node, as well as the definition of the missing
> pins and clock.
>
> Signed-off-by: Miquel Raynal
> ---
> arch/arm/dts/sun8i-a23-a33.dtsi | 31 +++
> arch/arm/dts/sun8i-a33.dtsi | 8
> 2 files changed, 39 insertions(+)
>
> diff --git a/arch/arm/dts/sun8i-a23-a33.dtsi b/arch/arm/dts/sun8i-a23-a33.dtsi
> index f97c38f097..fe6ea82cb3 100644
> --- a/arch/arm/dts/sun8i-a23-a33.dtsi
> +++ b/arch/arm/dts/sun8i-a23-a33.dtsi
> @@ -325,6 +325,19 @@
> #size-cells = <0>;
> };
>
> + nfc: nand@01c03000 {
> + compatible = "allwinner,sun4i-a10-nand";
> + reg = <0x01c03000 0x1000>;
> + interrupts = ;
> + clocks = <&ahb1_gates 25>, <&nand_clk>;
> + clock-names = "ahb", "mod";
> + resets = <&ahb1_rst 10>;
> + reset-names = "ahb";
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
That node is already there so that patch shouldn't be needed.
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.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 5/8] spl: nand: sunxi: use PIO instead of DMA
On Wed, 24 Jan 2018 01:44:51 +0100
Miquel Raynal wrote:
> Because using DMA implementation is not generic and was not developped
> to work on SoCs like A33, migrate the SPL to use PIO.
>
> Signed-off-by: Miquel Raynal
> ---
> board/sunxi/board.c | 4 +-
> drivers/mtd/nand/sunxi_nand_spl.c | 167
> +-
> 2 files changed, 79 insertions(+), 92 deletions(-)
>
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index 70e01437c4..512e2c17a6 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -266,11 +266,13 @@ static void nand_clock_setup(void)
> struct sunxi_ccm_reg *const ccm =
> (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
>
> - setbits_le32(&ccm->ahb_gate0, (CLK_GATE_OPEN << AHB_GATE_OFFSET_NAND0));
> + setbits_le32(&ccm->ahb_gate0, (1 << AHB_GATE_OFFSET_NAND0));
> + setbits_le32(&ccm->ahb_reset0_cfg, (1 << AHB_GATE_OFFSET_NAND0));
> #ifdef CONFIG_MACH_SUN9I
> setbits_le32(&ccm->ahb_gate1, (1 << AHB_GATE_OFFSET_DMA));
> #else
> setbits_le32(&ccm->ahb_gate0, (1 << AHB_GATE_OFFSET_DMA));
> + setbits_le32(&ccm->ahb_reset0_cfg, (1 << AHB_GATE_OFFSET_DMA));
> #endif
> setbits_le32(&ccm->nand0_clk_cfg, CCM_NAND_CTRL_ENABLE | AHB_DIV_1);
> }
> diff --git a/drivers/mtd/nand/sunxi_nand_spl.c
> b/drivers/mtd/nand/sunxi_nand_spl.c
> index 2488d5cb51..5de6825994 100644
> --- a/drivers/mtd/nand/sunxi_nand_spl.c
> +++ b/drivers/mtd/nand/sunxi_nand_spl.c
> @@ -10,6 +10,7 @@
> #include
> #include
> #include
> +#include
>
> /* registers */
> #define NFC_CTL0x
> @@ -45,32 +46,22 @@
> #define NFC_CTL_PAGE_SIZE_MASK (0xf << 8)
> #define NFC_CTL_PAGE_SIZE(a) ((fls(a) - 11) << 8)
>
> -
> #define NFC_ECC_EN (1 << 0)
> -#define NFC_ECC_PIPELINE (1 << 3)
> #define NFC_ECC_EXCEPTION (1 << 4)
> #define NFC_ECC_BLOCK_SIZE (1 << 5)
> #define NFC_ECC_RANDOM_EN (1 << 9)
> -#define NFC_ECC_RANDOM_DIRECTION (1 << 10)
> -
>
> #define NFC_ADDR_NUM_OFFSET16
> -#define NFC_ACCESS_DIR (1 << 20)
> #define NFC_SEND_ADDR (1 << 19)
> #define NFC_DATA_TRANS (1 << 21)
> #define NFC_SEND_CMD1 (1 << 22)
> #define NFC_WAIT_FLAG (1 << 23)
> #define NFC_SEND_CMD2 (1 << 24)
> -#define NFC_SEQ(1 << 25)
> -#define NFC_DATA_SWAP_METHOD (1 << 26)
> -#define NFC_ROW_AUTO_INC (1 << 27)
> -#define NFC_SEND_CMD3 (1 << 28)
> -#define NFC_SEND_CMD4 (1 << 29)
> #define NFC_RAW_CMD(0 << 30)
> -#define NFC_PAGE_CMD (2 << 30)
> +#define NFC_ECC_CMD(1 << 30)
>
> #define NFC_ST_CMD_INT_FLAG(1 << 1)
> -#define NFC_ST_DMA_INT_FLAG(1 << 2)
> +#define NFC_ST_CMD_FIFO_STAT (1 << 3)
>
> #define NFC_READ_CMD_OFFSET 0
> #define NFC_RANDOM_READ_CMD0_OFFSET 8
> @@ -80,22 +71,6 @@
> #define NFC_CMD_RNDOUT 0x05
> #define NFC_CMD_READSTART 0x30
>
> -#define SUNXI_DMA_CFG_REG0 0x300
> -#define SUNXI_DMA_SRC_START_ADDR_REG0 0x304
> -#define SUNXI_DMA_DEST_START_ADDRR_REG0 0x308
> -#define SUNXI_DMA_DDMA_BC_REG0 0x30C
> -#define SUNXI_DMA_DDMA_PARA_REG00x318
> -
> -#define SUNXI_DMA_DDMA_CFG_REG_LOADING (1 << 31)
> -#define SUNXI_DMA_DDMA_CFG_REG_DMA_DEST_DATA_WIDTH_32 (2 << 25)
> -#define SUNXI_DMA_DDMA_CFG_REG_DDMA_DST_DRQ_TYPE_DRAM (1 << 16)
> -#define SUNXI_DMA_DDMA_CFG_REG_DMA_SRC_DATA_WIDTH_32 (2 << 9)
> -#define SUNXI_DMA_DDMA_CFG_REG_DMA_SRC_ADDR_MODE_IO (1 << 5)
> -#define SUNXI_DMA_DDMA_CFG_REG_DDMA_SRC_DRQ_TYPE_NFC (3 << 0)
> -
> -#define SUNXI_DMA_DDMA_PARA_REG_SRC_WAIT_CYC (0x0F << 0)
> -#define SUNXI_DMA_DDMA_PARA_REG_SRC_BLK_SIZE (0x7F << 8)
> -
> struct nfc_config {
> int page_size;
> int ecc_strength;
> @@ -254,7 +229,23 @@ static int nand_reset_column(void)
> SUNXI_NFC_BASE + NFC_CMD);
>
> return nand_wait_int();
> +}
>
> +static int nand_change_column(u16 column)
> +{
> + nand_wait_cmd_fifo_empty();
> +
> + writel((NFC_CMD_RNDOUTSTART << NFC_RANDOM_READ_CMD1_OFFSET) |
> +(NFC_CMD_RNDOUT << NFC_RANDOM_READ_CMD0_OFFSET) |
> +(NFC_CMD_RNDOUTSTART << NFC_READ_CMD_OFFSET),
> +SUNXI_NFC_BASE + NFC_RCMD_SET);
> + writel(NFC_ST_CMD_INT_FLAG, SUNXI_NFC_BASE + NFC_ST);
> + writel(column, SUNXI_NFC_BASE + NFC_ADDR_LOW);
> + writel(NFC_SEND_CMD1 | NFC_SEND_CMD2 | NFC_RAW_CMD |
> +(1 << NFC_ADDR_NUM_OFFSET) | NFC_SEND_ADDR | NFC_CMD_RNDOUT,
> +SUNXI_NFC_BASE + NFC_CMD);
> +
> + return nand_wait_int();
> }
nand_reset_column() and nand_change_column() are almost the same,
except one is taking an argument to specify where you want to place the
pointer. I'd recommend getting rid of nand_reset_column() entirely and
patching all call s
Re: [U-Boot] [PATCH 8/8] sunxi: dts: Enable NAND on NES classic
On Wed, 24 Jan 2018 01:44:54 +0100
Miquel Raynal wrote:
> Let the Nintendo NES Classic use the Macronix NAND chip on it.
>
> Signed-off-by: Miquel Raynal
> ---
> arch/arm/dts/sun8i-r16-nintendo-nes-classic-edition.dts | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/arch/arm/dts/sun8i-r16-nintendo-nes-classic-edition.dts
> b/arch/arm/dts/sun8i-r16-nintendo-nes-classic-edition.dts
> index dce688ec8e..b8535d3dac 100644
> --- a/arch/arm/dts/sun8i-r16-nintendo-nes-classic-edition.dts
> +++ b/arch/arm/dts/sun8i-r16-nintendo-nes-classic-edition.dts
> @@ -61,3 +61,17 @@
> pinctrl-0 = <&uart0_pins_a>;
> status = "okay";
> };
> +
> +&nfc {
> + pinctrl-names = "default";
> + pinctrl-0 = <&nand_pins_a &nand_cs0_pins_a &nand_rb0_pins_a>;
> + status = "okay";
> +
> + nand@0 {
> + #address-cells = <2>;
> + #size-cells = <2>;
I'm pretty sure size and address cells can be set to 1 (the NAND is
less 4GB).
> + reg = <0>;
> + allwinner,rb = <0>;
> + nand-ecc-mode = "hw";
> + };
> +};
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/8] spl: nand: sunxi: use PIO instead of DMA
On Wed, 24 Jan 2018 09:06:26 +0100 Maxime Ripard wrote: > Hi, > > On Wed, Jan 24, 2018 at 01:44:51AM +0100, Miquel Raynal wrote: > > Because using DMA implementation is not generic and was not developped > > to work on SoCs like A33, migrate the SPL to use PIO. > > > > Signed-off-by: Miquel Raynal > > I guess the issue is slightly different than what you're saying, or at > least should be expressed differently. > > The issue is that the SPL support has be done to support only the > earlier generations of Allwinner SoCs, and only really enabled on the > A13 / GR8. However, those old SoCs had a DMA engine that has been > replaced since the A31 by another DMA controller that is no longer > compatible. > > Since the code directly uses that DMA controller, it cannot operate > properly on the later SoCs, while the NAND controller hasn't changed. > > There's two pathes forward, the first one would be to add support for > that DMA controller too, or you can just remove the DMA usage entirely > and rely on PIO that will make the driver simpler. > > Explaining why you chose PIO would be great too. > > > --- > > board/sunxi/board.c | 4 +- > > drivers/mtd/nand/sunxi_nand_spl.c | 167 > > +- > > 2 files changed, 79 insertions(+), 92 deletions(-) > > > > diff --git a/board/sunxi/board.c b/board/sunxi/board.c > > index 70e01437c4..512e2c17a6 100644 > > --- a/board/sunxi/board.c > > +++ b/board/sunxi/board.c > > @@ -266,11 +266,13 @@ static void nand_clock_setup(void) > > struct sunxi_ccm_reg *const ccm = > > (struct sunxi_ccm_reg *)SUNXI_CCM_BASE; > > > > - setbits_le32(&ccm->ahb_gate0, (CLK_GATE_OPEN << AHB_GATE_OFFSET_NAND0)); > > + setbits_le32(&ccm->ahb_gate0, (1 << AHB_GATE_OFFSET_NAND0)); > > + setbits_le32(&ccm->ahb_reset0_cfg, (1 << AHB_GATE_OFFSET_NAND0)); > > That has nothing to do with PIO vs DMA. It should be in another patch. > > > #ifdef CONFIG_MACH_SUN9I > > setbits_le32(&ccm->ahb_gate1, (1 << AHB_GATE_OFFSET_DMA)); > > #else > > setbits_le32(&ccm->ahb_gate0, (1 << AHB_GATE_OFFSET_DMA)); > > + setbits_le32(&ccm->ahb_reset0_cfg, (1 << AHB_GATE_OFFSET_DMA)); > > So you're de-asserting the reset line for the DMA controller, while > the commit is about removing the need for that DMA controller ? :) > > That whole block can actually be removed (in a separate patch) now > that you're not using DMA anymore. > > > #endif > > setbits_le32(&ccm->nand0_clk_cfg, CCM_NAND_CTRL_ENABLE | AHB_DIV_1); > > } > > diff --git a/drivers/mtd/nand/sunxi_nand_spl.c > > b/drivers/mtd/nand/sunxi_nand_spl.c > > index 2488d5cb51..5de6825994 100644 > > --- a/drivers/mtd/nand/sunxi_nand_spl.c > > +++ b/drivers/mtd/nand/sunxi_nand_spl.c > > @@ -10,6 +10,7 @@ > > #include > > #include > > #include > > +#include > > > > /* registers */ > > #define NFC_CTL0x > > @@ -45,32 +46,22 @@ > > #define NFC_CTL_PAGE_SIZE_MASK (0xf << 8) > > #define NFC_CTL_PAGE_SIZE(a) ((fls(a) - 11) << 8) > > > > - > > #define NFC_ECC_EN (1 << 0) > > -#define NFC_ECC_PIPELINE (1 << 3) > > #define NFC_ECC_EXCEPTION (1 << 4) > > #define NFC_ECC_BLOCK_SIZE (1 << 5) > > #define NFC_ECC_RANDOM_EN (1 << 9) > > -#define NFC_ECC_RANDOM_DIRECTION (1 << 10) > > - > > > > #define NFC_ADDR_NUM_OFFSET16 > > -#define NFC_ACCESS_DIR (1 << 20) > > #define NFC_SEND_ADDR (1 << 19) > > #define NFC_DATA_TRANS (1 << 21) > > #define NFC_SEND_CMD1 (1 << 22) > > #define NFC_WAIT_FLAG (1 << 23) > > #define NFC_SEND_CMD2 (1 << 24) > > -#define NFC_SEQ(1 << 25) > > -#define NFC_DATA_SWAP_METHOD (1 << 26) > > -#define NFC_ROW_AUTO_INC (1 << 27) > > -#define NFC_SEND_CMD3 (1 << 28) > > -#define NFC_SEND_CMD4 (1 << 29) > > #define NFC_RAW_CMD(0 << 30) > > -#define NFC_PAGE_CMD (2 << 30) > > +#define NFC_ECC_CMD(1 << 30) > > > > #define NFC_ST_CMD_INT_FLAG(1 << 1) > > -#define NFC_ST_DMA_INT_FLAG(1 << 2) > > +#define NFC_ST_CMD_FIFO_STAT (1 << 3) Oh, I didn't notice you were removing some definitions. I agree what Maxime says below, it's definitely not a good move. > > > > #define NFC_READ_CMD_OFFSET 0 > > #define NFC_RANDOM_READ_CMD0_OFFSET 8 > > @@ -80,22 +71,6 @@ > > #define NFC_CMD_RNDOUT 0x05 > > #define NFC_CMD_READSTART 0x30 > > > > -#define SUNXI_DMA_CFG_REG0 0x300 > > -#define SUNXI_DMA_SRC_START_ADDR_REG0 0x304 > > -#define SUNXI_DMA_DEST_START_ADDRR_REG0 0x308 > > -#define SUNXI_DMA_DDMA_BC_REG0 0x30C > > -#define SUNXI_DMA_DDMA_PARA_REG00x318 > > - > > -#define SUNXI_DMA_DDMA_CFG_REG_LOADING (1 << 31) > > -#define SUNXI_DMA_DDMA_CFG_REG_DMA_DEST_DATA_WIDTH_32 (2 <<
Re: [U-Boot] mmc: disable UHS modes if Vcc cannot be switched on and off
On 01/23/2018 09:03 PM, Eugeniy Paltsev wrote:
> On Tue, 2018-01-23 at 10:44 +0900, Jaehoon Chung wrote:
>> On 01/23/2018 03:38 AM, Eugeniy Paltsev wrote:
>>> Hi Jean-Jacques,
>>>
>>> after commit "mmc: disable UHS modes if Vcc cannot be switched on and off"
>>> (04a2ea248f)
>>> we got MMC broken on several (at least two) platforms with DesignWare MMC
>>> controller.
>>>
>>> The error log (with debug enabled in drivers/mmc/mmc.c and
>>> drivers/mmc/dw_mmc.c) is next:
>>> --->8-
>>> MMC: Synopsys Mobile storage: 0
>>> Buswidth = 0, clock: 40
>>> selecting mode MMC legacy (freq : 0 MHz)
>>> Buswidth = 1, clock: 40
>>> Buswidth = 1, clock: 40
>>> Sending CMD0
>>> dwmci_send_cmd: Timeout.
>>> mmc_init: -110, time 19
>>> ** Bad device mmc 0 **
>>> --->8-
>>>
>>> Any ideas how to fix this?
>>
>> Could you share which git repository you use?
>
> I use u-boot master branch from git://git.denx.de/u-boot.git
>
> last commits:
> --->8-
> 485c13c Merge git://git.denx.de/u-boot-dm
> b79221a lib: fdtdec: Fix some style violations
> 2e38662 lib: fdtdec: Fix whitespace style violations
> 29d11b8 core: Make device_is_compatible live-tree compatible
> 147c607 core: Add {ofnode, dev}_translate_address functions
> --->8-
>
I guess that this issue has already been fixed.
http://patchwork.ozlabs.org/patch/862160/
http://patchwork.ozlabs.org/patch/864607/
Best Regards,
Jaehoon Chung
>> Best Regards,
>> Jaehoon Chung
>>
>>>
>>> Thanks.
>>>
>>
>>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [PATCH 3/7] sun50i: a64: Move ethernet nodes to SoC DTS
On Tue, Jan 23, 2018 at 04:46:43PM -0600, Kyle Evans wrote: > On Tue, Jan 23, 2018 at 4:18 PM, Samuel Holland wrote: > > These nodes were previously in an unused file specific to the Pine64. > > Move them to the base SoC device tree for use by other boards. Require > > individual boards to enable the emac and provide a pin configuration. > > > > Signed-off-by: Samuel Holland > > --- > > arch/arm/dts/sun50i-a64-pine64-plus-u-boot.dtsi | 50 > > - > > arch/arm/dts/sun50i-a64.dtsi| 28 ++ > > 2 files changed, 28 insertions(+), 50 deletions(-) > > delete mode 100644 arch/arm/dts/sun50i-a64-pine64-plus-u-boot.dtsi > > On that note, it seems like it would be a good idea to re-sync this > with mainline Linux now that emac bindings exist in-tree [1] and these > are generally becoming standard. Thoughts? > > [1] > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi#n508 Agreed. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.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 1/7] sunxi: binman: Fix U-Boot binary size check
Hi!
On Tue, Jan 23, 2018 at 04:18:13PM -0600, Samuel Holland wrote:
> If raw mode is disabled, CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR is not
> defined, which breaks compiling the device trees. Only enable the size
> check when it actually matters--that is, when MMC raw mode is enabled.
>
> Signed-off-by: Samuel Holland
> ---
> arch/arm/dts/sunxi-u-boot.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/dts/sunxi-u-boot.dtsi b/arch/arm/dts/sunxi-u-boot.dtsi
> index 72e95afd78..996f391030 100644
> --- a/arch/arm/dts/sunxi-u-boot.dtsi
> +++ b/arch/arm/dts/sunxi-u-boot.dtsi
> @@ -17,7 +17,7 @@
> filename = "spl/sunxi-spl.bin";
> };
> u-boot-img {
> -#ifdef CONFIG_MMC
> +#ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR
Why don't you change for ENV_IS_IN_MMC like your commit log would
suggest?
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.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 5/8] spl: nand: sunxi: use PIO instead of DMA
On Wed, Jan 24, 2018 at 09:26:37AM +0100, Boris Brezillon wrote: > > > > > > #define NFC_READ_CMD_OFFSET 0 > > > #define NFC_RANDOM_READ_CMD0_OFFSET 8 > > > @@ -80,22 +71,6 @@ > > > #define NFC_CMD_RNDOUT 0x05 > > > #define NFC_CMD_READSTART 0x30 > > > > > > -#define SUNXI_DMA_CFG_REG0 0x300 > > > -#define SUNXI_DMA_SRC_START_ADDR_REG0 0x304 > > > -#define SUNXI_DMA_DEST_START_ADDRR_REG0 0x308 > > > -#define SUNXI_DMA_DDMA_BC_REG0 0x30C > > > -#define SUNXI_DMA_DDMA_PARA_REG00x318 > > > - > > > -#define SUNXI_DMA_DDMA_CFG_REG_LOADING (1 << 31) > > > -#define SUNXI_DMA_DDMA_CFG_REG_DMA_DEST_DATA_WIDTH_32 (2 << 25) > > > -#define SUNXI_DMA_DDMA_CFG_REG_DDMA_DST_DRQ_TYPE_DRAM (1 << 16) > > > -#define SUNXI_DMA_DDMA_CFG_REG_DMA_SRC_DATA_WIDTH_32 (2 << 9) > > > -#define SUNXI_DMA_DDMA_CFG_REG_DMA_SRC_ADDR_MODE_IO (1 << 5) > > > -#define SUNXI_DMA_DDMA_CFG_REG_DDMA_SRC_DRQ_TYPE_NFC (3 << 0) > > > - > > > -#define SUNXI_DMA_DDMA_PARA_REG_SRC_WAIT_CYC (0x0F << 0) > > > -#define SUNXI_DMA_DDMA_PARA_REG_SRC_BLK_SIZE (0x7F << 8) > > > - > > > > We should probably keep those values. They're not used anymore, but > > the NAND controller has been under-documented on most of the datasheet > > we've had. It's good to keep it at least for reference. > > > > Hm, your statement is valid for the NFC_ defs, but these are purely DMA > engine related definitions, so I think we can get rid of them. Oh, right, we can totally remove those. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] arm: zynq: Remove ethernet alias for topic-miami
Ethernet is not enabled that's why this alias should be completely
unused.
Signed-off-by: Michal Simek
---
arch/arm/dts/zynq-topic-miami.dts | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/dts/zynq-topic-miami.dts
b/arch/arm/dts/zynq-topic-miami.dts
index 79a3671a8eb6..bf421f6653e9 100644
--- a/arch/arm/dts/zynq-topic-miami.dts
+++ b/arch/arm/dts/zynq-topic-miami.dts
@@ -13,7 +13,6 @@
compatible = "topic,miami", "xlnx,zynq-7000";
aliases {
- ethernet0 = &gem0;
serial0 = &uart0;
spi0 = &qspi;
i2c0 = &i2c0;
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/7] sun50i: a64: Fix USB clock/reset properties
On Tue, Jan 23, 2018 at 04:18:14PM -0600, Samuel Holland wrote: > Move the CLK_USB_OHCI0/1 clocks to the OHCI nodes where they belong, and > make the format consistent with the H3/H5 nodes. While here, also remove > leading zeros from the USB nodes' unit addresses. > > Signed-off-by: Samuel Holland I guess you just took the linux DTS? You can just mention that, along with which version of the kernel you used for that synchronization. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.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 7/7] sun50i: h5: Add support for the Orange Pi Zero Plus
On Tue, Jan 23, 2018 at 04:18:19PM -0600, Samuel Holland wrote: > diff --git a/arch/arm/dts/sun50i-h5-orangepi-zero-plus2.dts > b/arch/arm/dts/sun50i-h5-orangepi-zero-plus2.dts > index 3f4baba310..e44e75733e 100644 > --- a/arch/arm/dts/sun50i-h5-orangepi-zero-plus2.dts > +++ b/arch/arm/dts/sun50i-h5-orangepi-zero-plus2.dts > @@ -1,5 +1,6 @@ > /* > * Copyright (C) 2017 Jagan Teki > + * Copyright (C) 2017 Samuel Holland > * > * This file is dual-licensed: you can use it either under the terms > * of the GPL or the X11 license, at your option. Note that this dual You haven't touched that file. I guess this was meant for the Orange Pi Zero Plus and not the Plus2? Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] am33xx: board: Call spl_early_init() to support sdram_init()
With driver model enabled in SPL, sdram_init() requires device tree and malloc to be initialized. Therefore call spl_early_init() in early_system_init(). Signed-off-by: Faiz Abbas --- arch/arm/mach-omap2/am33xx/board.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/mach-omap2/am33xx/board.c b/arch/arm/mach-omap2/am33xx/board.c index ae86b69..ea0caba 100644 --- a/arch/arm/mach-omap2/am33xx/board.c +++ b/arch/arm/mach-omap2/am33xx/board.c @@ -353,6 +353,9 @@ void early_system_init(void) #ifdef CONFIG_TI_I2C_BOARD_DETECT do_board_detect(); #endif +#ifdef CONFIG_SPL_BUILD + spl_early_init(); +#endif #if defined(CONFIG_SPL_AM33XX_ENABLE_RTC32K_OSC) /* Enable RTC32K clock */ rtc32k_enable(); -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] samsung: board: init the s2mps11 pmic during booting time
Exynos5422 board has s2mps11 pmic.
If CONFIG_PMIC_S2MPS11 is enabled, it can initialize PMIC and Regulators
during booting time.
Signed-off-by: Jaehoon Chung
---
board/samsung/common/exynos5-dt.c | 4
1 file changed, 4 insertions(+)
diff --git a/board/samsung/common/exynos5-dt.c
b/board/samsung/common/exynos5-dt.c
index a4eb351405..9189bf59b9 100644
--- a/board/samsung/common/exynos5-dt.c
+++ b/board/samsung/common/exynos5-dt.c
@@ -93,7 +93,11 @@ int exynos_power_init(void)
struct udevice *dev;
int ret;
+#ifdef CONFIG_PMIC_S2MPS11
+ ret = pmic_get("s2mps11_pmic", &dev);
+#else
ret = pmic_get("max77686", &dev);
+#endif
if (!ret) {
/* TODO(s...@chromium.org): Move into the clock/pmic API */
ret = pmic_clrsetbits(dev, MAX77686_REG_PMIC_32KHZ, 0,
--
2.15.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] sunxi: remove allwinner prefix in pinctrl nodes
Hi, On Wed, Jan 24, 2018 at 11:01:51AM +0100, Nuno Goncalves wrote: > Signed-off-by: Nuno Goncalves I'd rather not do that without any particular reason. This will create needless conflicts. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.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/3] sunxi: add DM I2C support for H3/H5
Hi,
On Wed, Jan 24, 2018 at 11:01:52AM +0100, Nuno Goncalves wrote:
> Signed-off-by: Nuno Goncalves
Please write a commit log.
> ---
> arch/arm/dts/sun8i-h3.dtsi | 48
> ++
> arch/arm/include/asm/arch-sunxi/gpio.h | 2 ++
> board/sunxi/board.c| 10 ++-
> 3 files changed, 59 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/dts/sun8i-h3.dtsi b/arch/arm/dts/sun8i-h3.dtsi
> index df2742095e..da17dfa579 100644
> --- a/arch/arm/dts/sun8i-h3.dtsi
> +++ b/arch/arm/dts/sun8i-h3.dtsi
> @@ -396,6 +396,21 @@
> drive-strength = <10>;
> bias-disable;
> };
> +
> + i2c0_pins_a: i2c0@0 {
> + pins = "PA11", "PA12";
> + function = "i2c0";
> + };
> +
> + i2c1_pins_a: i2c1@0 {
> + pins = "PA18", "PA19";
> + function = "i2c1";
> + };
> +
> + i2c2_pins_a: i2c2@0 {
> + pins = "PE12", "PE13";
> + function = "i2c2";
> + };
> };
>
> timer@01c20c00 {
> @@ -464,6 +479,39 @@
> status = "disabled";
> };
>
> + i2c0: i2c@01c2ac00 {
> + compatible = "allwinner,sun6i-a31-i2c";
> + reg = <0x01c2ac00 0x400>;
> + interrupts = ;
> + clocks = <&ccu CLK_BUS_I2C0>;
> + resets = <&ccu RST_BUS_I2C0>;
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + i2c1: i2c@01c2b000 {
> + compatible = "allwinner,sun6i-a31-i2c";
> + reg = <0x01c2b000 0x400>;
> + interrupts = ;
> + clocks = <&ccu CLK_BUS_I2C1>;
> + resets = <&ccu RST_BUS_I2C1>;
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + i2c2: i2c@01c2b400 {
> + compatible = "allwinner,sun6i-a31-i2c";
> + reg = <0x01c2b400 0x400>;
> + interrupts = ;
> + clocks = <&ccu CLK_BUS_I2C2>;
> + resets = <&ccu RST_BUS_I2C2>;
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
Why don't you just synchronize the DT with Linux?
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.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 3/3] sunxi: add I2C nodes present on Orange Pi >ero
Hi,
On Wed, Jan 24, 2018 at 11:01:53AM +0100, Nuno Goncalves wrote:
> Signed-off-by: Nuno Goncalves
Commit log please.
> ---
> arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts
> b/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts
> index 20d489cb2a..f028d175f3 100644
> --- a/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts
> +++ b/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts
> @@ -138,6 +138,18 @@
> };
> };
>
> +&i2c0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c0_pins_a>;
> + status = "okay";
> +};
> +
> +&i2c1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c1_pins_a>;
> + status = "okay";
> +};
> +
In particular, you should describe what these i2c buses are used for.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.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] am33xx: board: Call spl_early_init() to support sdram_init()
On Wednesday 24 January 2018 02:44 PM, Faiz Abbas wrote: > With driver model enabled in SPL, sdram_init() requires device tree > and malloc to be initialized. > Therefore call spl_early_init() in early_system_init(). > > Signed-off-by: Faiz Abbas Reviewed-by: Lokesh Vutla Thanks and regards, Lokesh ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/3] arm: zynq: Moved ethernet PHY configs of Zynq boards to defconfig
From: Vipul Kumar This patch moved ethernet PHY configs of Zynq boards to respective defconfig. Signed-off-by: Vipul Kumar Signed-off-by: Michal Simek --- configs/syzygy_hub_defconfig | 3 +++ configs/zynq_cc108_defconfig | 3 +++ configs/zynq_microzed_defconfig| 3 +++ configs/zynq_picozed_defconfig | 3 +++ configs/zynq_z_turn_defconfig | 3 +++ configs/zynq_zc702_defconfig | 3 +++ configs/zynq_zc706_defconfig | 3 +++ configs/zynq_zc770_xm010_defconfig | 3 +++ configs/zynq_zc770_xm012_defconfig | 3 +++ configs/zynq_zc770_xm013_defconfig | 3 +++ configs/zynq_zed_defconfig | 3 +++ configs/zynq_zybo_defconfig| 3 +++ include/configs/zynq-common.h | 3 --- 13 files changed, 36 insertions(+), 3 deletions(-) diff --git a/configs/syzygy_hub_defconfig b/configs/syzygy_hub_defconfig index f4ae8e0f25eb..c4c1e9381232 100644 --- a/configs/syzygy_hub_defconfig +++ b/configs/syzygy_hub_defconfig @@ -36,6 +36,9 @@ CONFIG_FPGA_XILINX=y CONFIG_DM_GPIO=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ZYNQ=y +CONFIG_PHY_MARVELL=y +CONFIG_PHY_REALTEK=y +CONFIG_PHY_XILINX=y CONFIG_ZYNQ_GEM=y CONFIG_DEBUG_UART_ZYNQ=y CONFIG_DEBUG_UART_BASE=0xe000 diff --git a/configs/zynq_cc108_defconfig b/configs/zynq_cc108_defconfig index 02445ac4ab7d..5082208b9ce0 100644 --- a/configs/zynq_cc108_defconfig +++ b/configs/zynq_cc108_defconfig @@ -35,6 +35,9 @@ CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_SPI_FLASH_WINBOND=y +CONFIG_PHY_MARVELL=y +CONFIG_PHY_REALTEK=y +CONFIG_PHY_XILINX=y CONFIG_ZYNQ_GEM=y CONFIG_DEBUG_UART_ZYNQ=y CONFIG_DEBUG_UART_BASE=0xe000 diff --git a/configs/zynq_microzed_defconfig b/configs/zynq_microzed_defconfig index c9829ade0209..c1762b07c2db 100644 --- a/configs/zynq_microzed_defconfig +++ b/configs/zynq_microzed_defconfig @@ -42,6 +42,9 @@ CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_SPI_FLASH_WINBOND=y +CONFIG_PHY_MARVELL=y +CONFIG_PHY_REALTEK=y +CONFIG_PHY_XILINX=y CONFIG_ZYNQ_GEM=y CONFIG_ZYNQ_SERIAL=y CONFIG_ZYNQ_QSPI=y diff --git a/configs/zynq_picozed_defconfig b/configs/zynq_picozed_defconfig index 40befdaf8d43..0c7006a5e9d8 100644 --- a/configs/zynq_picozed_defconfig +++ b/configs/zynq_picozed_defconfig @@ -32,6 +32,9 @@ CONFIG_FPGA_XILINX=y CONFIG_DM_GPIO=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ZYNQ=y +CONFIG_PHY_MARVELL=y +CONFIG_PHY_REALTEK=y +CONFIG_PHY_XILINX=y CONFIG_ZYNQ_GEM=y CONFIG_ZYNQ_SERIAL=y CONFIG_USB=y diff --git a/configs/zynq_z_turn_defconfig b/configs/zynq_z_turn_defconfig index dd12f7c8155b..c315b917dc81 100644 --- a/configs/zynq_z_turn_defconfig +++ b/configs/zynq_z_turn_defconfig @@ -38,6 +38,9 @@ CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_SPI_FLASH_WINBOND=y +CONFIG_PHY_MARVELL=y +CONFIG_PHY_REALTEK=y +CONFIG_PHY_XILINX=y CONFIG_ZYNQ_GEM=y CONFIG_DEBUG_UART_ZYNQ=y CONFIG_DEBUG_UART_BASE=0xe0001000 diff --git a/configs/zynq_zc702_defconfig b/configs/zynq_zc702_defconfig index 09584db67cea..5fadf5074e02 100644 --- a/configs/zynq_zc702_defconfig +++ b/configs/zynq_zc702_defconfig @@ -48,6 +48,9 @@ CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_SPI_FLASH_WINBOND=y +CONFIG_PHY_MARVELL=y +CONFIG_PHY_REALTEK=y +CONFIG_PHY_XILINX=y CONFIG_ZYNQ_GEM=y CONFIG_DEBUG_UART_ZYNQ=y CONFIG_DEBUG_UART_BASE=0xe0001000 diff --git a/configs/zynq_zc706_defconfig b/configs/zynq_zc706_defconfig index e9f701dce7fa..f024147f2fba 100644 --- a/configs/zynq_zc706_defconfig +++ b/configs/zynq_zc706_defconfig @@ -48,6 +48,9 @@ CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_SPI_FLASH_WINBOND=y +CONFIG_PHY_MARVELL=y +CONFIG_PHY_REALTEK=y +CONFIG_PHY_XILINX=y CONFIG_ZYNQ_GEM=y CONFIG_DEBUG_UART_ZYNQ=y CONFIG_DEBUG_UART_BASE=0xe0001000 diff --git a/configs/zynq_zc770_xm010_defconfig b/configs/zynq_zc770_xm010_defconfig index 0503715768df..125f97d0044b 100644 --- a/configs/zynq_zc770_xm010_defconfig +++ b/configs/zynq_zc770_xm010_defconfig @@ -41,6 +41,9 @@ CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_SPI_FLASH_SST=y CONFIG_SPI_FLASH_WINBOND=y +CONFIG_PHY_MARVELL=y +CONFIG_PHY_REALTEK=y +CONFIG_PHY_XILINX=y CONFIG_ZYNQ_GEM=y CONFIG_DEBUG_UART_ZYNQ=y CONFIG_DEBUG_UART_BASE=0xe0001000 diff --git a/configs/zynq_zc770_xm012_defconfig b/configs/zynq_zc770_xm012_defconfig index 205d2c5f7bac..09ae04be3487 100644 --- a/configs/zynq_zc770_xm012_defconfig +++ b/configs/zynq_zc770_xm012_defconfig @@ -37,5 +37,8 @@ CONFIG_FPGA_XILINX=y CONFIG_DM_GPIO=y # CONFIG_MMC is not set CONFIG_MTD_NOR_FLASH=y +CONFIG_PHY_MARVELL=y +CONFIG_PHY_REALTEK=y +CONFIG_PHY_XILINX=y CONFIG_ZYNQ_GEM=y CONFIG_ZYNQ_SERIAL=y diff --git a/configs/zynq_zc770_xm013_defconfig b/configs/zynq_zc770_xm013_defconfig index 856470d4d188..36922ffcd4cd 100644 --- a/configs/zynq_zc770_xm013_defconfig +++ b/configs/zynq_zc7
[U-Boot] [PATCH 2/3] microblaze: Moved ethernet PHY configs of Microblaze board to defconfig
From: Vipul Kumar This patch moved ethernet PHY configs of Microblaze board to respective defconfig. Signed-off-by: Vipul Kumar Signed-off-by: Michal Simek --- configs/microblaze-generic_defconfig | 8 include/configs/microblaze-generic.h | 8 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/configs/microblaze-generic_defconfig b/configs/microblaze-generic_defconfig index 5254c0da790a..7c5a3f09cac0 100644 --- a/configs/microblaze-generic_defconfig +++ b/configs/microblaze-generic_defconfig @@ -44,8 +44,16 @@ CONFIG_ENV_IS_IN_FLASH=y CONFIG_NETCONSOLE=y CONFIG_SPL_DM=y CONFIG_MTD_NOR_FLASH=y +CONFIG_PHY_ATHEROS=y +CONFIG_PHY_BROADCOM=y +CONFIG_PHY_DAVICOM=y +CONFIG_PHY_LXT=y +CONFIG_PHY_MARVELL=y CONFIG_PHY_MICREL=y CONFIG_PHY_MICREL_KSZ90X1=y +CONFIG_PHY_NATSEMI=y +CONFIG_PHY_REALTEK=y +CONFIG_PHY_VITESSE=y CONFIG_DM_ETH=y CONFIG_XILINX_AXIEMAC=y CONFIG_XILINX_EMACLITE=y diff --git a/include/configs/microblaze-generic.h b/include/configs/microblaze-generic.h index 41e6790d68e1..16481cb7ce99 100644 --- a/include/configs/microblaze-generic.h +++ b/include/configs/microblaze-generic.h @@ -212,14 +212,6 @@ #if defined(CONFIG_XILINX_AXIEMAC) # define CONFIG_MII1 # define CONFIG_SYS_FAULT_ECHO_LINK_DOWN 1 -# define CONFIG_PHY_ATHEROS1 -# define CONFIG_PHY_BROADCOM 1 -# define CONFIG_PHY_DAVICOM1 -# define CONFIG_PHY_LXT1 -# define CONFIG_PHY_MARVELL1 -# define CONFIG_PHY_NATSEMI1 -# define CONFIG_PHY_REALTEK1 -# define CONFIG_PHY_VITESSE1 #else # undef CONFIG_MII #endif -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/3] arm64: zynqmp: Moved ethernet PHY configs of ZynqMP boards to defconfig
From: Vipul Kumar This patch moved ethernet PHY configs of ZynqMP boards to respective defconfig. Signed-off-by: Vipul Kumar Signed-off-by: Michal Simek --- configs/xilinx_zynqmp_ep_defconfig | 5 + configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig | 5 + configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig | 5 + configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig | 5 + configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig | 5 + configs/xilinx_zynqmp_zcu102_rev1_0_defconfig| 5 + configs/xilinx_zynqmp_zcu102_revA_defconfig | 5 + configs/xilinx_zynqmp_zcu102_revB_defconfig | 5 + include/configs/xilinx_zynqmp.h | 5 - 9 files changed, 40 insertions(+), 5 deletions(-) diff --git a/configs/xilinx_zynqmp_ep_defconfig b/configs/xilinx_zynqmp_ep_defconfig index 1fc0fabd9256..ce8bc0b0ec51 100644 --- a/configs/xilinx_zynqmp_ep_defconfig +++ b/configs/xilinx_zynqmp_ep_defconfig @@ -69,6 +69,11 @@ CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_SPI_FLASH_WINBOND=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set +CONFIG_PHY_MARVELL=y +CONFIG_PHY_NATSEMI=y +CONFIG_PHY_REALTEK=y +CONFIG_PHY_TI=y +CONFIG_PHY_VITESSE=y CONFIG_DM_ETH=y CONFIG_PHY_GIGE=y CONFIG_ZYNQ_GEM=y diff --git a/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig b/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig index 6914767187b9..814ff3805fe8 100644 --- a/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig +++ b/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig @@ -62,6 +62,11 @@ CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_SPI_FLASH_WINBOND=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set +CONFIG_PHY_MARVELL=y +CONFIG_PHY_NATSEMI=y +CONFIG_PHY_REALTEK=y +CONFIG_PHY_TI=y +CONFIG_PHY_VITESSE=y CONFIG_DM_ETH=y CONFIG_PHY_GIGE=y CONFIG_ZYNQ_GEM=y diff --git a/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig b/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig index 67a6d9ae9b60..67e659640dfb 100644 --- a/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig +++ b/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig @@ -58,6 +58,11 @@ CONFIG_NAND_ARASAN=y CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_BAR=y CONFIG_SPI_FLASH_SST=y +CONFIG_PHY_MARVELL=y +CONFIG_PHY_NATSEMI=y +CONFIG_PHY_REALTEK=y +CONFIG_PHY_TI=y +CONFIG_PHY_VITESSE=y CONFIG_DM_ETH=y CONFIG_PHY_GIGE=y CONFIG_ZYNQ_GEM=y diff --git a/configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig b/configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig index 15b301dca146..9bc0b77c2c8a 100644 --- a/configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig +++ b/configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig @@ -50,6 +50,11 @@ CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_SPI_FLASH_WINBOND=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set +CONFIG_PHY_MARVELL=y +CONFIG_PHY_NATSEMI=y +CONFIG_PHY_REALTEK=y +CONFIG_PHY_TI=y +CONFIG_PHY_VITESSE=y CONFIG_DM_ETH=y CONFIG_PHY_GIGE=y CONFIG_ZYNQ_GEM=y diff --git a/configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig b/configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig index ac565ecf8f9c..01a0ac0d762d 100644 --- a/configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig +++ b/configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig @@ -43,6 +43,11 @@ CONFIG_MISC=y CONFIG_DM_MMC=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ZYNQ=y +CONFIG_PHY_MARVELL=y +CONFIG_PHY_NATSEMI=y +CONFIG_PHY_REALTEK=y +CONFIG_PHY_TI=y +CONFIG_PHY_VITESSE=y CONFIG_DM_ETH=y CONFIG_DEBUG_UART_ZYNQ=y CONFIG_DEBUG_UART_BASE=0xff00 diff --git a/configs/xilinx_zynqmp_zcu102_rev1_0_defconfig b/configs/xilinx_zynqmp_zcu102_rev1_0_defconfig index c761d4948f5e..075508993e3b 100644 --- a/configs/xilinx_zynqmp_zcu102_rev1_0_defconfig +++ b/configs/xilinx_zynqmp_zcu102_rev1_0_defconfig @@ -64,6 +64,11 @@ CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_SPI_FLASH_WINBOND=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set +CONFIG_PHY_MARVELL=y +CONFIG_PHY_NATSEMI=y +CONFIG_PHY_REALTEK=y +CONFIG_PHY_TI=y +CONFIG_PHY_VITESSE=y CONFIG_DM_ETH=y CONFIG_PHY_GIGE=y CONFIG_ZYNQ_GEM=y diff --git a/configs/xilinx_zynqmp_zcu102_revA_defconfig b/configs/xilinx_zynqmp_zcu102_revA_defconfig index 43b533fdb908..404b15c54a37 100644 --- a/configs/xilinx_zynqmp_zcu102_revA_defconfig +++ b/configs/xilinx_zynqmp_zcu102_revA_defconfig @@ -64,6 +64,11 @@ CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_SPI_FLASH_WINBOND=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set +CONFIG_PHY_MARVELL=y +CONFIG_PHY_NATSEMI=y +CONFIG_PHY_REALTEK=y +CONFIG_PHY_TI=y +CONFIG_PHY_VITESSE=y CONFIG_DM_ETH=y CONFIG_PHY_GIGE=y CONFIG_ZYNQ_GEM=y diff --git a/configs/xilinx_zynqmp_zcu102_revB_defconfig b/configs/xilinx_zynqmp_zcu102_revB_defconfig index c2d0ddbcf9de..dbdda089b806 100644 --- a/configs/xilinx_zynqmp_zcu102_revB_defconfig +++ b/configs/xilinx_zynqmp_zcu102_revB_defconfig @@ -64,6 +64,11 @@ CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_SPI_FLASH_WINBOND=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
[U-Boot] [RFC PATCH] Allow providing default environment from file
It is sometimes useful to be able to define the entire default
environment in an external file. This implements a Kconfig option for
allowing that.
It is somewhat annoying to have two visible Kconfig options; it would
probably be more user-friendly to just have the string option (with
empty string obviously meaning not to use this feature). But then we'd
also need a hidden CONFIG that we can use in the #ifdef in
env_default.h, and I don't think one can set a def_bool based on
whether a string-valued config is empty or not.
I've tried to make the accepted format the same as the one the
mkenvimage tool accepts. I have no idea how portable the sed script
implementing the "allow embedded newlines in values" is. Nor do I know
if one can expect xxd to be available.
Signed-off-by: Rasmus Villemoes
---
Makefile | 16
env/Kconfig | 18 ++
include/env_default.h | 4
3 files changed, 38 insertions(+)
diff --git a/Makefile b/Makefile
index 4981a2ed6f..e5ba5213fd 100644
--- a/Makefile
+++ b/Makefile
@@ -423,6 +423,7 @@ endif
version_h := include/generated/version_autogenerated.h
timestamp_h := include/generated/timestamp_autogenerated.h
+defaultenv_h := include/generated/defaultenv_autogenerated.h
no-dot-config-targets := clean clobber mrproper distclean \
help %docs check% coccicheck \
@@ -1366,6 +1367,10 @@ ifeq ($(wildcard $(LDSCRIPT)),)
@/bin/false
endif
+ifeq ($(CONFIG_DEFAULT_ENV_FROM_FILE),y)
+prepare1: $(defaultenv_h)
+endif
+
archprepare: prepare1 scripts_basic
prepare0: archprepare FORCE
@@ -1413,12 +1418,23 @@ define filechk_timestamp.h
fi)
endef
+define filechk_defaultenv.h
+ (grep -v '^#' | \
+grep -v '^$$' | \
+tr '\n' '\0' | \
+sed -e 's/\\\x0/\n/' | \
+xxd -i ; echo ", 0x00" ; )
+endef
+
$(version_h): include/config/uboot.release FORCE
$(call filechk,version.h)
$(timestamp_h): $(srctree)/Makefile FORCE
$(call filechk,timestamp.h)
+$(defaultenv_h): $(CONFIG_DEFAULT_ENV_FILE:"%"=%) FORCE
+ $(call filechk,defaultenv.h)
+
# ---
quiet_cmd_cpp_lds = LDS $@
cmd_cpp_lds = $(CPP) -Wp,-MD,$(depfile) $(cpp_flags) $(LDPPFLAGS) \
diff --git a/env/Kconfig b/env/Kconfig
index a24370786b..1baebd743b 100644
--- a/env/Kconfig
+++ b/env/Kconfig
@@ -482,4 +482,22 @@ config ENV_SIZE
endif
+config DEFAULT_ENV_FROM_FILE
+ bool "Create default environment from file"
+ help
+ Normally, the default environment is automatically generated
+ based on the settings of various CONFIG_* options, as well
+ as the CONFIG_EXTRA_ENV_SETTINGS. By selecting this option,
+ you can instead define the entire default environment in an
+ external file.
+
+config DEFAULT_ENV_FILE
+ string "Path to default environment file"
+ depends on DEFAULT_ENV_FROM_FILE
+ help
+ The path containing the default environment. The format is
+ the same as accepted by the mkenvimage tool: lines
+ containing key=value pairs, blank lines and lines beginning
+ with # are ignored.
+
endmenu
diff --git a/include/env_default.h b/include/env_default.h
index b574345af2..656d202cc7 100644
--- a/include/env_default.h
+++ b/include/env_default.h
@@ -22,6 +22,7 @@ static char default_environment[] = {
#else
const uchar default_environment[] = {
#endif
+#ifndef CONFIG_DEFAULT_ENV_FROM_FILE
#ifdef CONFIG_ENV_CALLBACK_LIST_DEFAULT
ENV_CALLBACK_VAR "=" CONFIG_ENV_CALLBACK_LIST_DEFAULT "\0"
#endif
@@ -108,6 +109,9 @@ const uchar default_environment[] = {
CONFIG_EXTRA_ENV_SETTINGS
#endif
"\0"
+#else /* CONFIG_DEFAULT_ENV_FROM_FILE */
+#include "generated/defaultenv_autogenerated.h"
+#endif
#ifdef DEFAULT_ENV_INSTANCE_EMBEDDED
}
#endif
--
2.15.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [PATCH 3/7] sun50i: a64: Move ethernet nodes to SoC DTS
On Tue, Jan 23, 2018 at 4:18 PM, Samuel Holland wrote: > These nodes were previously in an unused file specific to the Pine64. > Move them to the base SoC device tree for use by other boards. Require > individual boards to enable the emac and provide a pin configuration. > > Signed-off-by: Samuel Holland > --- > arch/arm/dts/sun50i-a64-pine64-plus-u-boot.dtsi | 50 > - > arch/arm/dts/sun50i-a64.dtsi| 28 ++ > 2 files changed, 28 insertions(+), 50 deletions(-) > delete mode 100644 arch/arm/dts/sun50i-a64-pine64-plus-u-boot.dtsi On that note, it seems like it would be a good idea to re-sync this with mainline Linux now that emac bindings exist in-tree [1] and these are generally becoming standard. Thoughts? [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi#n508 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] U-boot can verify an HW signature?
Hi Breno Lima, Thank you very much, indeed this is the answer that i need. Perhaps could you give me some more details on realizing encrypted boot using the yocto project platform? All The Best, Saverio Il 20/01/2018 16:00, Breno Matheus Lima ha scritto: > Hi Saveiro, > > 2018-01-19 16:45 GMT-02:00 Saverio Mori : >> Hi Breno Lima, >> For the moment we have not secure boot, we use "plain" u-boot running on >> a module board equipped with an "open" i.MX6UL processor, and we are >> newbies in the field of secure boot. We wish that our firmware works >> only on approved hardware, and not on common one. From what we have >> read, secured boot allow that only approved FW works on prepared HW; our >> problem is just the reciprocal, i.e. allow running of our FW only on >> approved boards. In other words, a secured FW can works on a unsecured >> board (while a secured board requires a secured FW), we wish to block >> this situation. >> All The Best, > You can have more details about secure boot in doc/README.mxc_hab file. > > The application note AN4581 can be also helpful: > https://www.nxp.com/docs/en/application-note/AN4581.pdf > > The secure boot is intended to prepare your device to just run > authenticated SW, once your SRK Hash and SEC_CONFIG fuse are > programmed you can only execute authenticated bootloader on this > device. > > If you want that your SW can be only executed on approved hardware > you can refer to encrypted boot, which is supported on i.MX6UL. > > You can find more details in doc/README.mxc_hab file and also in NXP > community. Currently there is no application note provided by NXP > about encrypted boot: > https://community.nxp.com/docs/DOC-330622 > > Note that dek_blob command can be only executed in closed devices, so > you need to run an authenticated U-Boot to prepare an encrypted boot > image. > > Let us know if you have any questions during the process. > > Thanks, > Breno Lima > >> Saverio M. >> >> Il 19/01/2018 18:54, Breno Matheus Lima ha scritto: >>> Hi Saverio, >>> >>> 2018-01-19 11:12 GMT-02:00 Saverio Mori : Hi to the community. I have found a lot of material on secure booting and how to sign u-boot an uimage in order to that only trusted sw is load. This is good for my but i have also the opposite problem, that is i have to be sure that my sw is load on an hardware signed in some way. It is possible, and how, implement this feature in u-boot, at least running on iMX6 boards? Thanks!!! >>> Can you please share more details about this verification you want to >>> achieve? Are you currently running a signed U-Boot in a closed device >>> (eFuse SEC_CONFIG = 1)? >>> >>> Thanks, >>> Breno Lima >> >> signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/3] sunxi: add DM I2C support for H3/H5
Signed-off-by: Nuno Goncalves
---
arch/arm/dts/sun8i-h3.dtsi | 48 ++
arch/arm/include/asm/arch-sunxi/gpio.h | 2 ++
board/sunxi/board.c| 10 ++-
3 files changed, 59 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/sun8i-h3.dtsi b/arch/arm/dts/sun8i-h3.dtsi
index df2742095e..da17dfa579 100644
--- a/arch/arm/dts/sun8i-h3.dtsi
+++ b/arch/arm/dts/sun8i-h3.dtsi
@@ -396,6 +396,21 @@
drive-strength = <10>;
bias-disable;
};
+
+ i2c0_pins_a: i2c0@0 {
+ pins = "PA11", "PA12";
+ function = "i2c0";
+ };
+
+ i2c1_pins_a: i2c1@0 {
+ pins = "PA18", "PA19";
+ function = "i2c1";
+ };
+
+ i2c2_pins_a: i2c2@0 {
+ pins = "PE12", "PE13";
+ function = "i2c2";
+ };
};
timer@01c20c00 {
@@ -464,6 +479,39 @@
status = "disabled";
};
+ i2c0: i2c@01c2ac00 {
+ compatible = "allwinner,sun6i-a31-i2c";
+ reg = <0x01c2ac00 0x400>;
+ interrupts = ;
+ clocks = <&ccu CLK_BUS_I2C0>;
+ resets = <&ccu RST_BUS_I2C0>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c1: i2c@01c2b000 {
+ compatible = "allwinner,sun6i-a31-i2c";
+ reg = <0x01c2b000 0x400>;
+ interrupts = ;
+ clocks = <&ccu CLK_BUS_I2C1>;
+ resets = <&ccu RST_BUS_I2C1>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c2: i2c@01c2b400 {
+ compatible = "allwinner,sun6i-a31-i2c";
+ reg = <0x01c2b400 0x400>;
+ interrupts = ;
+ clocks = <&ccu CLK_BUS_I2C2>;
+ resets = <&ccu RST_BUS_I2C2>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
emac: ethernet@1c3 {
compatible = "allwinner,sun8i-h3-emac";
reg = <0x01c3 0x104>, <0x01c00030 0x4>;
diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h
b/arch/arm/include/asm/arch-sunxi/gpio.h
index 24f85206c8..52884886d7 100644
--- a/arch/arm/include/asm/arch-sunxi/gpio.h
+++ b/arch/arm/include/asm/arch-sunxi/gpio.h
@@ -149,6 +149,8 @@ enum sunxi_gpio_number {
#define SUN6I_GPA_SDC2 5
#define SUN6I_GPA_SDC3 4
#define SUN8I_H3_GPA_UART0 2
+#define SUN8I_H3_H5_GPA_TWI0 2
+#define SUN8I_H3_H5_GPA_TWI1 3
#define SUN4I_GPB_PWM 2
#define SUN4I_GPB_TWI0 2
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index dcacdf3e62..6b55aef202 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -93,6 +93,10 @@ void i2c_init_board(void)
sunxi_gpio_set_cfgpin(SUNXI_GPH(14), SUN6I_GPH_TWI0);
sunxi_gpio_set_cfgpin(SUNXI_GPH(15), SUN6I_GPH_TWI0);
clock_twi_onoff(0, 1);
+#elif defined(CONFIG_MACH_SUNXI_H3_H5)
+ sunxi_gpio_set_cfgpin(SUNXI_GPA(11), SUN8I_H3_H5_GPA_TWI0);
+ sunxi_gpio_set_cfgpin(SUNXI_GPA(12), SUN8I_H3_H5_GPA_TWI0);
+ clock_twi_onoff(0, 1);
#elif defined(CONFIG_MACH_SUN8I)
sunxi_gpio_set_cfgpin(SUNXI_GPH(2), SUN8I_GPH_TWI0);
sunxi_gpio_set_cfgpin(SUNXI_GPH(3), SUN8I_GPH_TWI0);
@@ -115,6 +119,10 @@ void i2c_init_board(void)
sunxi_gpio_set_cfgpin(SUNXI_GPH(16), SUN6I_GPH_TWI1);
sunxi_gpio_set_cfgpin(SUNXI_GPH(17), SUN6I_GPH_TWI1);
clock_twi_onoff(1, 1);
+#elif defined(CONFIG_MACH_SUNXI_H3_H5)
+ sunxi_gpio_set_cfgpin(SUNXI_GPA(18), SUN8I_H3_H5_GPA_TWI1);
+ sunxi_gpio_set_cfgpin(SUNXI_GPA(19), SUN8I_H3_H5_GPA_TWI1);
+ clock_twi_onoff(1, 1);
#elif defined(CONFIG_MACH_SUN8I)
sunxi_gpio_set_cfgpin(SUNXI_GPH(4), SUN8I_GPH_TWI1);
sunxi_gpio_set_cfgpin(SUNXI_GPH(5), SUN8I_GPH_TWI1);
@@ -137,7 +145,7 @@ void i2c_init_board(void)
sunxi_gpio_set_cfgpin(SUNXI_GPH(18), SUN6I_GPH_TWI2);
sunxi_gpio_set_cfgpin(SUNXI_GPH(19), SUN6I_GPH_TWI2);
clock_twi_onoff(2, 1);
-#elif defined(CONFIG_MACH_SUN8I)
+#elif defined(CONFIG_MACH_SUN8I) /* same for CONFIG_MACH_SUNXI_H3_H5 */
sunxi_gpio_set_cfgpin(SUNXI_GPE(12), SUN8I_GPE_TWI2);
sunxi_gpio_set_cfgpin(SUNXI_GPE(13), SUN8I
[U-Boot] [PATCH 3/3] sunxi: add I2C nodes present on Orange Pi >ero
Signed-off-by: Nuno Goncalves
---
arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts
b/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts
index 20d489cb2a..f028d175f3 100644
--- a/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts
+++ b/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts
@@ -138,6 +138,18 @@
};
};
+&i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins_a>;
+ status = "okay";
+};
+
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_pins_a>;
+ status = "okay";
+};
+
&ohci1 {
status = "okay";
};
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] sunxi: add DM I2C support for H3/H5
On Wed, Jan 24, 2018 at 11:57 AM, Maxime Ripard wrote: > Why don't you just synchronize the DT with Linux? Didn't know that was the usual approach. But in Linux the files have a different structure, for example there is sunxi-h3-h5.dtsi. Thanks, Nuno ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] sunxi: add I2C nodes present on Orange Pi >ero
On Wed, Jan 24, 2018 at 11:58 AM, Maxime Ripard wrote: > In particular, you should describe what these i2c buses are used for. They are available on the pins exclusively. I could add the pinout for this board for sure. But maybe it doesn't make sense in this case to activate them, as without external hardware they have no use. Thanks, Nuno ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] FW: u-boot v2016 vs v2013
Dear Estevam, Thank you very much; With your helps managed to use u-boot 2018, gcc 7.2 and SPL, generated u-boot.img image and downloaded into board. SD card and e-MMC working well. Ethernet Phy is also answering mii info as shown below: => mii info PHY 0x05: OUI = 0x0885, Model = 0x21, Rev = 0x01, 10baseT, HDX => setenv ipadr 10.0.0.10 => dhcp FEC Waiting for PHY auto negotiation to complete. TIMEOUT ! Could not initialize PHY FEC BOOTP broadcast 1 BOOTP broadcast 2 . . . BOOTP broadcast 17 Retry time exceeded; starting again. I would be grateful, if you Have any idea how can I test and solve the dhcp command? With my best regards. Mehmet Ali -Original Message- From: Fabio Estevam [mailto:feste...@gmail.com] Sent: Tuesday, January 16, 2018 5:57 PM To: Mehmet Ali İPİN Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] FW: u-boot v2016 vs v2013 Hi Mehmet, On Tue, Jan 16, 2018 at 11:40 AM, Mehmet Ali İPİN wrote: > Dear Estevam, > > Thank you for your helps. I finally managed to build u-boot-2018. With these > commands: > export > CROSS_COMPILE=/opt/gcc-arm-none-eabi-7-2017-q4-major/bin/arm-none-eabi > - > export ARCH=arm > make distclean > make mx6sabreauto_defconfig > make > > There are u-boot, u-boot.bin, u-boot.img, ... files, but I could not see > u-boot.imx file, which we use it to download to the DDR via USB, with > usb_loader program. > > I used u-boot-2016 lately, which was generating .imx file; Do you know if we > can generate it with 2018.1? mx6sabreauto has been converted to SPL, so the generated binaries are SPL and u-boot.img. You can flash them into the SD card like this: - Flash the SPL binary into the SD card: $ sudo dd if=SPL of=/dev/sdX bs=1K seek=1 && sync - Flash the u-boot.img binary into the SD card: $ sudo dd if=u-boot.img of=/dev/sdX bs=1K seek=69 && sync This is described in board/freescale/mx6sabreauto/README. You can also load SPL and u-boot.img via imx_usb_loader tool. Make sure you use their latest code and follow doc/README.sdp. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] U-boot can verify an HW signature?
Hi Saverio, 2018-01-24 5:35 GMT-02:00 Saverio Mori : > Hi Breno Lima, > Thank you very much, indeed this is the answer that i need. Perhaps > could you give me some more details on realizing encrypted boot using > the yocto project platform? Currently is not possible to sign or encrypt a U-Boot image using Yocto project, the CST (Code Signing Tool) is only available at NXP portal. You can build U-Boot using Yocto with the following configurations enabled and sign/encrypt this image with CST. CONFIG_SECURE_BOOT=y CONFIG_CMD_DEKBLOB=y This patch from Fabio Estevam can be also helpful: https://lists.denx.de/pipermail/u-boot/2018-January/317847.html Thanks, Breno Lima > All The Best, > > Saverio > > Il 20/01/2018 16:00, Breno Matheus Lima ha scritto: >> Hi Saveiro, >> >> 2018-01-19 16:45 GMT-02:00 Saverio Mori : >>> Hi Breno Lima, >>> For the moment we have not secure boot, we use "plain" u-boot running on >>> a module board equipped with an "open" i.MX6UL processor, and we are >>> newbies in the field of secure boot. We wish that our firmware works >>> only on approved hardware, and not on common one. From what we have >>> read, secured boot allow that only approved FW works on prepared HW; our >>> problem is just the reciprocal, i.e. allow running of our FW only on >>> approved boards. In other words, a secured FW can works on a unsecured >>> board (while a secured board requires a secured FW), we wish to block >>> this situation. >>> All The Best, >> You can have more details about secure boot in doc/README.mxc_hab file. >> >> The application note AN4581 can be also helpful: >> https://www.nxp.com/docs/en/application-note/AN4581.pdf >> >> The secure boot is intended to prepare your device to just run >> authenticated SW, once your SRK Hash and SEC_CONFIG fuse are >> programmed you can only execute authenticated bootloader on this >> device. >> >> If you want that your SW can be only executed on approved hardware >> you can refer to encrypted boot, which is supported on i.MX6UL. >> >> You can find more details in doc/README.mxc_hab file and also in NXP >> community. Currently there is no application note provided by NXP >> about encrypted boot: >> https://community.nxp.com/docs/DOC-330622 >> >> Note that dek_blob command can be only executed in closed devices, so >> you need to run an authenticated U-Boot to prepare an encrypted boot >> image. >> >> Let us know if you have any questions during the process. >> >> Thanks, >> Breno Lima >> >>> Saverio M. >>> >>> Il 19/01/2018 18:54, Breno Matheus Lima ha scritto: Hi Saverio, 2018-01-19 11:12 GMT-02:00 Saverio Mori : > Hi to the community. I have found a lot of material on secure booting and > how to sign u-boot an uimage in order to that only trusted sw is load. > This is good for my but i have also the opposite problem, that is i have > to be sure that my sw is load on an hardware signed in some way. It is > possible, and how, implement this feature in u-boot, at least running on > iMX6 boards? Thanks!!! Can you please share more details about this verification you want to achieve? Are you currently running a signed U-Boot in a closed device (eFuse SEC_CONFIG = 1)? Thanks, Breno Lima >>> >>> > > -- Breno Matheus Lima ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] FW: u-boot v2016 vs v2013
On Wed, Jan 24, 2018 at 9:57 AM, Mehmet Ali İPİN wrote: > Dear Estevam, > > Thank you very much; With your helps managed to use u-boot 2018, gcc 7.2 and > SPL, generated > u-boot.img image and downloaded into board. > > SD card and e-MMC working well. Ethernet Phy is also answering mii info as > shown below: > > => mii info > PHY 0x05: OUI = 0x0885, Model = 0x21, Rev = 0x01, 10baseT, HDX > => setenv ipadr 10.0.0.10 > => dhcp > FEC Waiting for PHY auto negotiation to complete. TIMEOUT ! > Could not initialize PHY FEC > BOOTP broadcast 1 > BOOTP broadcast 2 > . > . > . > BOOTP broadcast 17 > > Retry time exceeded; starting again. > > I would be grateful, if you Have any idea how can I test and solve the dhcp > command? It's hard to understand what could be wrong without seeing your code nor schematics. Are you able to get Ethernet working in Linux? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] FW: u-boot v2016 vs v2013
Dear Estevam, I am (in fact hardware engineer developed the PCB) not an experienced u-boot/linux developer, therefore sorry for my complex questions. I will check the forum, and google for this message, but you may help me to start the right path. May be, according to your experience you can advise me to check some (phy/mac) register, pin status, clock values, Or give the name of threads in u-boot or nxp imx6 forum which is about similar dhcp events, if you remember. Since its a new PCB board, so we did not load/run the linux yet. Thanks and best regards. Mehmet Ali -Original Message- From: Fabio Estevam [mailto:feste...@gmail.com] Sent: Wednesday, January 24, 2018 2:59 PM To: Mehmet Ali İPİN Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] FW: u-boot v2016 vs v2013 On Wed, Jan 24, 2018 at 9:57 AM, Mehmet Ali İPİN wrote: > Dear Estevam, > > Thank you very much; With your helps managed to use u-boot 2018, gcc > 7.2 and SPL, generated u-boot.img image and downloaded into board. > > SD card and e-MMC working well. Ethernet Phy is also answering mii info as > shown below: > > => mii info > PHY 0x05: OUI = 0x0885, Model = 0x21, Rev = 0x01, 10baseT, HDX => > setenv ipadr 10.0.0.10 => dhcp FEC Waiting for PHY auto negotiation to > complete. TIMEOUT ! > Could not initialize PHY FEC > BOOTP broadcast 1 > BOOTP broadcast 2 > . > . > . > BOOTP broadcast 17 > > Retry time exceeded; starting again. > > I would be grateful, if you Have any idea how can I test and solve the dhcp > command? It's hard to understand what could be wrong without seeing your code nor schematics. Are you able to get Ethernet working in Linux? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] FW: u-boot v2016 vs v2013
On Wed, Jan 24, 2018 at 10:26 AM, Mehmet Ali İPİN wrote: > Dear Estevam, > > I am (in fact hardware engineer developed the PCB) not an experienced > u-boot/linux developer, therefore sorry for my complex questions. > I will check the forum, and google for this message, but you may help me to > start the right path. > > May be, according to your experience you can advise me to check some > (phy/mac) register, pin status, clock values, > Or give the name of threads in u-boot or nxp imx6 forum which is about > similar dhcp events, if you remember. > > Since its a new PCB board, so we did not load/run the linux yet. Try looking at existing supported boards that use KSZ9021, such as board/boundary/nitrogen6x/nitrogen6x.c for example. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] FW: u-boot v2016 vs v2013
Thanks and best regards. -Original Message- From: Fabio Estevam [mailto:feste...@gmail.com] Sent: Wednesday, January 24, 2018 3:29 PM To: Mehmet Ali İPİN Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] FW: u-boot v2016 vs v2013 On Wed, Jan 24, 2018 at 10:26 AM, Mehmet Ali İPİN wrote: > Dear Estevam, > > I am (in fact hardware engineer developed the PCB) not an experienced > u-boot/linux developer, therefore sorry for my complex questions. > I will check the forum, and google for this message, but you may help me to > start the right path. > > May be, according to your experience you can advise me to check some > (phy/mac) register, pin status, clock values, Or give the name of threads in > u-boot or nxp imx6 forum which is about similar dhcp events, if you remember. > > Since its a new PCB board, so we did not load/run the linux yet. Try looking at existing supported boards that use KSZ9021, such as board/boundary/nitrogen6x/nitrogen6x.c for example. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] FW: u-boot v2016 vs v2013
On Wed, Jan 24, 2018 at 10:29 AM, Fabio Estevam wrote: > Try looking at existing supported boards that use KSZ9021, such as > board/boundary/nitrogen6x/nitrogen6x.c for example. Or also the mx6 udoo board (board/udoo/udoo.c) : http://download.udoo.org/files/schematics/UDOO_REV_D_schematics.pdf ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] samsung: board: init the s2mps11 pmic during booting time
Hi Jaehoon,
On 24 January 2018 at 15:23, Jaehoon Chung wrote:
> Exynos5422 board has s2mps11 pmic.
> If CONFIG_PMIC_S2MPS11 is enabled, it can initialize PMIC and Regulators
> during booting time.
>
> Signed-off-by: Jaehoon Chung
> ---
> board/samsung/common/exynos5-dt.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/board/samsung/common/exynos5-dt.c
> b/board/samsung/common/exynos5-dt.c
> index a4eb351405..9189bf59b9 100644
> --- a/board/samsung/common/exynos5-dt.c
> +++ b/board/samsung/common/exynos5-dt.c
> @@ -93,7 +93,11 @@ int exynos_power_init(void)
> struct udevice *dev;
> int ret;
>
> +#ifdef CONFIG_PMIC_S2MPS11
> + ret = pmic_get("s2mps11_pmic", &dev);
> +#else
> ret = pmic_get("max77686", &dev);
> +#endif
> if (!ret) {
> /* TODO(s...@chromium.org): Move into the clock/pmic API */
> ret = pmic_clrsetbits(dev, MAX77686_REG_PMIC_32KHZ, 0,
> --
> 2.15.1
>
Please add my.
Tested-by: Anand Moon
Best Regards
-Anand
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/9] log: Support control over the log output format
Hi Tom, On 19 January 2018 at 09:20, Tom Rini wrote: > > On Thu, Jan 18, 2018 at 01:40:51PM -0800, Simon Glass wrote: > > Hi, > > > > On 28 December 2017 at 12:14, Simon Glass wrote: > > > This adds a few more features to the log system: > > > > > > - 'log format' command to control the log output format > > > - 'log rec' command to output a log record manually > > > - log_ret() function to log error-return values > > > > > > With these we have more control over how log records are output as well > > > as the ability to log errors more easily. > > > > > > > > > Simon Glass (9): > > > dm: core: Add a function to look up a uclass by name > > > log: Add functions to convert IDs to/from names > > > log: Add control over log formatting > > > log: Update log_console to honour the log format > > > log: Add a command to control the log output format > > > log: Add a command to output a log record > > > log: Add tests for the new log features > > > log: Add documentation for commands and formatting > > > log: Add a way to log error-return values > > > > > > cmd/log.c | 82 > > > +++ > > > common/Kconfig| 13 +++ > > > common/log.c | 68 > > > common/log_console.c | 27 - > > > configs/sandbox_defconfig | 1 + > > > doc/README.log| 35 + > > > drivers/core/uclass.c | 14 +++ > > > include/asm-generic/global_data.h | 1 + > > > include/dm/uclass.h | 8 > > > include/log.h | 64 +- > > > test/dm/core.c| 9 + > > > test/py/tests/test_log.py | 32 +-- > > > 12 files changed, 348 insertions(+), 6 deletions(-) > > > > Are there any comments / reviews on this series, please? I'd like to > > apply it in this merge window. > > What's the size change in the cases where boards can't opt-out? There is no size change for boards which don't enable CONFIG_LOG. For sandbox (which does) the change is: sandbox: (for 4/4 boards) all +970.0 data +136.0 rodata +212.0 text +622.0 Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 7/7] sun50i: h5: Add support for the Orange Pi Zero Plus
On 01/24/18 02:45, Maxime Ripard wrote: > On Tue, Jan 23, 2018 at 04:18:19PM -0600, Samuel Holland wrote: >> diff --git a/arch/arm/dts/sun50i-h5-orangepi-zero-plus2.dts >> b/arch/arm/dts/sun50i-h5-orangepi-zero-plus2.dts >> index 3f4baba310..e44e75733e 100644 >> --- a/arch/arm/dts/sun50i-h5-orangepi-zero-plus2.dts >> +++ b/arch/arm/dts/sun50i-h5-orangepi-zero-plus2.dts >> @@ -1,5 +1,6 @@ >> /* >> * Copyright (C) 2017 Jagan Teki >> + * Copyright (C) 2017 Samuel Holland >> * >> * This file is dual-licensed: you can use it either under the terms >> * of the GPL or the X11 license, at your option. Note that this dual > > You haven't touched that file. I guess this was meant for the Orange > Pi Zero Plus and not the Plus2? Yes, it was, sorry. > Maxime Thanks, Samuel ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/7] sun50i: a64: Fix USB clock/reset properties
On 01/24/18 02:42, Maxime Ripard wrote: > On Tue, Jan 23, 2018 at 04:18:14PM -0600, Samuel Holland wrote: >> Move the CLK_USB_OHCI0/1 clocks to the OHCI nodes where they belong, and >> make the format consistent with the H3/H5 nodes. While here, also remove >> leading zeros from the USB nodes' unit addresses. >> >> Signed-off-by: Samuel Holland > > I guess you just took the linux DTS? No, actually the Linux DTS has the same issue with the clocks (the unit addresses there have been fixed). Should I send a patch there first? > You can just mention that, along with which version of the kernel you > used for that synchronization. And then once that's merged, send a patch for synchronization? > Thanks! > Maxime Thanks, Samuel ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] Fix CAAM for TrustZone enable for warp7
On 23 January 2018 at 21:10, Bryan O'Donoghue wrote: > This series is the u-boot fix to a problem we encountered when enabling > OPTEE/TrustZone on the WaRP7. The symptom is once TrustZone is activated > the first page of CAAM registers becomes read-only, read-zero from the > perspective of Linux and other non TrustZone contexts. > > Offlining the problem with Peng Fan[1] we eventually came to realise the > problem could be worked around by > > 1. Making Linux skip RNG initialisation - a set of patches should be >hitting LKML to do just that. > > 2. Initialising the RNG either from u-boot or OPTEE. In this case u-boot is >the right place to-do that because there's upstream code in u-boot that >just works. Patch #2 does that for the WaRP7. > > 3. Ensuring the job-ring registers are assigned to the non TrustZone mode. >On the i.MX7 after the BootROM runs the job-ring registers are assigned >to TrustZone. Patch #1 does that for all CAAM hardware. > > On point #3 this ordinarily isn't a problem because unless TrustZone is > activated the restrictions on the job-ring registers don't kick in, its > only after enabling TrustZone that Linux will loose access to the job-ring > registers. > > Finally should OPTEE or another TEE want to do things with the job-ring > registers it will have sufficient privilege to assign whichever job-ring > registers it wants to OPTEE/TEE but will naturally then have to arbitrate > with Linux to inform the Kernel CAAM driver which job-ring registers it can > and cannot access. > > That arbitration process is for a future putative OPTEE/TEE CAAM driver to > solve and is out of scope of this patchset. > > [1] Thanks for all of your help BTW - Peng, there's no way this would be > working without you giving direction on how. > > Bryan O'Donoghue (2): > drivers/crypto/fsl: assign job-rings to non-TrustZone > warp7 : run sec_init for CAAM RNG > This series: Tested-by: Ryan Harkin > > board/warp7/warp7.c | 6 +- > drivers/crypto/fsl/jr.c | 9 + > drivers/crypto/fsl/jr.h | 1 + > 3 files changed, 15 insertions(+), 1 deletion(-) > > -- > 2.7.4 > > ___ > 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 1/7] sunxi: binman: Fix U-Boot binary size check
On 01/24/18 02:38, Maxime Ripard wrote:
> Hi!
>
> On Tue, Jan 23, 2018 at 04:18:13PM -0600, Samuel Holland wrote:
>> If raw mode is disabled, CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR is not
>> defined, which breaks compiling the device trees. Only enable the size
>> check when it actually matters--that is, when MMC raw mode is enabled.
>>
>> Signed-off-by: Samuel Holland
>> ---
>> arch/arm/dts/sunxi-u-boot.dtsi | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/dts/sunxi-u-boot.dtsi b/arch/arm/dts/sunxi-u-boot.dtsi
>> index 72e95afd78..996f391030 100644
>> --- a/arch/arm/dts/sunxi-u-boot.dtsi
>> +++ b/arch/arm/dts/sunxi-u-boot.dtsi
>> @@ -17,7 +17,7 @@
>> filename = "spl/sunxi-spl.bin";
>> };
>> u-boot-img {
>> -#ifdef CONFIG_MMC
>> +#ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR
>
> Why don't you change for ENV_IS_IN_MMC like your commit log would
> suggest?
Because if the environment is in MMC but U-Boot isn't (e.g. it's in SPI), or
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION is in effect and the U-Boot image
is stored after the environment in MMC, then there's no chance of overlap and
the size doesn't matter.
> Thanks!
> Maxime
Thanks,
Samuel
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] ddr: altera: silence PHY calibration unless in debug mode
On 01/11/2018 12:28, Marek Vasut wrote:
> On 01/11/2018 08:19 AM, Goldschmidt Simon wrote:
>> This driver has been using printf() including filename since it was
>> added. Convert to using debug() instead.
>>
>> Signed-off-by: Simon Goldschmidt
>
> Applied, thanks.
I can't see this one in u-boot-socfpga. Anything wrong here?
Regards,
Simon
>> ---
>>
>> drivers/ddr/altera/sequencer.c | 8
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/ddr/altera/sequencer.c b/drivers/ddr/altera/sequencer.c
>> index 6c6bd90e94..42e87b50d3 100644
>> --- a/drivers/ddr/altera/sequencer.c
>> +++ b/drivers/ddr/altera/sequencer.c
>> @@ -3534,7 +3534,7 @@ static void debug_mem_calibrate(int pass)
>> u32 debug_info;
>>
>> if (pass) {
>> - printf("%s: CALIBRATION PASSED\n", __FILE__);
>> + debug("%s: CALIBRATION PASSED\n", __FILE__);
>>
>> gbl->fom_in /= 2;
>> gbl->fom_out /= 2;
>> @@ -3553,7 +3553,7 @@ static void debug_mem_calibrate(int pass)
>> writel(debug_info, &phy_mgr_cfg->cal_debug_info);
>> writel(PHY_MGR_CAL_SUCCESS, &phy_mgr_cfg->cal_status);
>> } else {
>> - printf("%s: CALIBRATION FAILED\n", __FILE__);
>> + debug("%s: CALIBRATION FAILED\n", __FILE__);
<>
>> debug_info = gbl->error_stage;
>> debug_info |= gbl->error_substage << 8;
>> @@ -3570,7 +3570,7 @@ static void debug_mem_calibrate(int pass)
>> writel(debug_info, &sdr_reg_file->failing_stage);
>> }
>>
>> - printf("%s: Calibration complete\n", __FILE__);
>> + debug("%s: Calibration complete\n", __FILE__);
>> }
>>
>> /**
>> @@ -3741,7 +3741,7 @@ int sdram_calibration_full(void)
>>
>> initialize_tracking();
>>
>> - printf("%s: Preparing to start memory calibration\n", __FILE__);
>> + debug("%s: Preparing to start memory calibration\n", __FILE__);
>>
>> debug("%s:%d\n", __func__, __LINE__);
>> debug_cond(DLEVEL >= 1,
>>
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 11/15] env: mmc: depends on the MMC framework
On 2018년 01월 24일 05:17, Maxime Ripard wrote: > The raw MMC environment directly calls into the MMC framework. Make sure > it's enabled before we can select it. > > Reviewed-by: Simon Glass > Signed-off-by: Maxime Ripard Reviewed-by: Jaehoon Chung > --- > env/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/env/Kconfig b/env/Kconfig > index bef6e89bfc3c..ad5ccc253762 100644 > --- a/env/Kconfig > +++ b/env/Kconfig > @@ -156,6 +156,7 @@ config ENV_IS_IN_FLASH > config ENV_IS_IN_MMC > bool "Environment in an MMC device" > depends on !CHAIN_OF_TRUST > + depends on MMC > help > Define this if you have an MMC device which you want to use for the > environment. > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 07/15] env: mmc: Make the debug messages play a little nicer
On 2018년 01월 24일 05:16, Maxime Ripard wrote:
> Since we have global messages to indicate what's going on, the custom
> messages in the environment drivers only make the output less readable.
>
> Make MMC play a little nicer by removing all the extra \n and formatting
> that is redundant with the global output.
>
> Reviewed-by: Andre Przywara
> Reviewed-by: Simon Glass
> Signed-off-by: Maxime Ripard
Reviewed-by: Jaehoon Chung
> ---
> env/mmc.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/env/mmc.c b/env/mmc.c
> index ed7bcf16ae0e..528fbf978162 100644
> --- a/env/mmc.c
> +++ b/env/mmc.c
> @@ -233,7 +233,6 @@ static int env_mmc_save(void)
> goto fini;
> }
>
> - puts("done\n");
> ret = 0;
>
> #ifdef CONFIG_ENV_OFFSET_REDUND
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] efi_loader: Always use EFIAPI instead of asmlinkage
EFI calls are usually defined as asmlinkage. That means we pass all parameters
to functions via the stack x86_32.
On x86_64 however, we need to also stick to the MS ABI calling conventions,
which the EFIAPI define conveniently handles for us. Most EFI functions were
also marked with EFIAPI, except for the entry call.
So this patch adjusts all entry calls to use EFIAPI instead of the manual
asmlinkage attribute.
While at it, we also change the prototype of the entry point to return
efi_status_t instead of ulong, as this is the correct prototype definition.
Signed-off-by: Alexander Graf
---
cmd/bootefi.c | 11 ++-
lib/efi_loader/efi_boottime.c | 4 ++--
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 51213c0293..545cfecc12 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -126,8 +126,9 @@ static void *copy_fdt(void *fdt)
static efi_status_t efi_do_enter(
efi_handle_t image_handle, struct efi_system_table *st,
- asmlinkage ulong (*entry)(efi_handle_t image_handle,
- struct efi_system_table *st))
+ EFIAPI efi_status_t (*entry)(
+ efi_handle_t image_handle,
+ struct efi_system_table *st))
{
efi_status_t ret = EFI_LOAD_ERROR;
@@ -138,7 +139,7 @@ static efi_status_t efi_do_enter(
}
#ifdef CONFIG_ARM64
-static efi_status_t efi_run_in_el2(asmlinkage ulong (*entry)(
+static efi_status_t efi_run_in_el2(EFIAPI efi_status_t (*entry)(
efi_handle_t image_handle, struct efi_system_table *st),
efi_handle_t image_handle, struct efi_system_table *st)
{
@@ -162,8 +163,8 @@ static efi_status_t do_bootefi_exec(void *efi, void *fdt,
struct efi_device_path *memdp = NULL;
ulong ret;
- ulong (*entry)(efi_handle_t image_handle, struct efi_system_table *st)
- asmlinkage;
+ EFIAPI efi_status_t (*entry)(efi_handle_t image_handle,
+struct efi_system_table *st);
ulong fdt_pages, fdt_size, fdt_start, fdt_end;
const efi_guid_t fdt_guid = EFI_FDT_GUID;
bootm_headers_t img = { 0 };
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 39d8511fe3..5b78740bff 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -1534,8 +1534,8 @@ static efi_status_t EFIAPI efi_start_image(efi_handle_t
image_handle,
unsigned long *exit_data_size,
s16 **exit_data)
{
- asmlinkage ulong (*entry)(efi_handle_t image_handle,
- struct efi_system_table *st);
+ EFIAPI ulong (*entry)(efi_handle_t image_handle,
+ struct efi_system_table *st);
struct efi_loaded_image *info = image_handle;
efi_status_t ret;
--
2.12.3
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] efi: Conflict efi_loader with different stub bitness
We have 2 users of the EFI headers: efi_loader and the EFI stub. Efi_loader always expects that the bitness of the definitions it uses is identical to the execution. The EFI stub however allows to run x86_64 U-Boot on 32bit EFI and the other way around, so it allows for different bitness of EFI definitions and U-Boot environment. This patch explicitly requests via Kconfig that efi_loader can only be enabled if the bitness is identical. Because we can run efi_loader on x86_64 without EFI stub enabled, it also ensures that this case propagates the correct ABI constraints. Signed-off-by: Alexander Graf --- include/efi.h | 2 +- lib/efi_loader/Kconfig | 4 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/include/efi.h b/include/efi.h index 2f0be9c86c..98bddbac1a 100644 --- a/include/efi.h +++ b/include/efi.h @@ -19,7 +19,7 @@ #include #include -#ifdef CONFIG_EFI_STUB_64BIT +#if CONFIG_EFI_STUB_64BIT || (!defined(CONFIG_EFI_STUB) && defined(__x86_64__)) /* EFI uses the Microsoft ABI which is not the default for GCC */ #define EFIAPI __attribute__((ms_abi)) #else diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig index d2b6327119..827c267b60 100644 --- a/lib/efi_loader/Kconfig +++ b/lib/efi_loader/Kconfig @@ -1,6 +1,10 @@ config EFI_LOADER bool "Support running EFI Applications in U-Boot" depends on (ARM || X86) && OF_LIBFDT + # We need EFI_STUB_64BIT to be set on x86_64 with EFI_STUB + depends on !EFI_STUB || !X86_64 || EFI_STUB_64BIT + # We need EFI_STUB_32BIT to be set on x86_32 with EFI_STUB + depends on !EFI_STUB || !X86 || X86_64 || EFI_STUB_32BIT default y help Select this option if you want to run EFI applications (like grub2) -- 2.12.3 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] ddr: altera: silence PHY calibration unless in debug mode
On 01/24/2018 02:19 PM, Goldschmidt Simon wrote: > On 01/11/2018 12:28, Marek Vasut wrote: >> On 01/11/2018 08:19 AM, Goldschmidt Simon wrote: >>> This driver has been using printf() including filename since it was >>> added. Convert to using debug() instead. >>> >>> Signed-off-by: Simon Goldschmidt >> >> Applied, thanks. > > I can't see this one in u-boot-socfpga. Anything wrong here? Please resend this one as well, sorry about that. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] efi_loader: Always use EFIAPI instead of asmlinkage
EFI calls are usually defined as asmlinkage. That means we pass all parameters
to functions via the stack x86_32.
On x86_64 however, we need to also stick to the MS ABI calling conventions,
which the EFIAPI define conveniently handles for us. Most EFI functions were
also marked with EFIAPI, except for the entry call.
So this patch adjusts all entry calls to use EFIAPI instead of the manual
asmlinkage attribute.
While at it, we also change the prototype of the entry point to return
efi_status_t instead of ulong, as this is the correct prototype definition.
Signed-off-by: Alexander Graf
---
v1 -> v2:
- Use efi_status_t in all occurences
---
cmd/bootefi.c | 11 ++-
lib/efi_loader/efi_boottime.c | 4 ++--
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 51213c0293..545cfecc12 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -126,8 +126,9 @@ static void *copy_fdt(void *fdt)
static efi_status_t efi_do_enter(
efi_handle_t image_handle, struct efi_system_table *st,
- asmlinkage ulong (*entry)(efi_handle_t image_handle,
- struct efi_system_table *st))
+ EFIAPI efi_status_t (*entry)(
+ efi_handle_t image_handle,
+ struct efi_system_table *st))
{
efi_status_t ret = EFI_LOAD_ERROR;
@@ -138,7 +139,7 @@ static efi_status_t efi_do_enter(
}
#ifdef CONFIG_ARM64
-static efi_status_t efi_run_in_el2(asmlinkage ulong (*entry)(
+static efi_status_t efi_run_in_el2(EFIAPI efi_status_t (*entry)(
efi_handle_t image_handle, struct efi_system_table *st),
efi_handle_t image_handle, struct efi_system_table *st)
{
@@ -162,8 +163,8 @@ static efi_status_t do_bootefi_exec(void *efi, void *fdt,
struct efi_device_path *memdp = NULL;
ulong ret;
- ulong (*entry)(efi_handle_t image_handle, struct efi_system_table *st)
- asmlinkage;
+ EFIAPI efi_status_t (*entry)(efi_handle_t image_handle,
+struct efi_system_table *st);
ulong fdt_pages, fdt_size, fdt_start, fdt_end;
const efi_guid_t fdt_guid = EFI_FDT_GUID;
bootm_headers_t img = { 0 };
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 39d8511fe3..27c94e4474 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -1534,8 +1534,8 @@ static efi_status_t EFIAPI efi_start_image(efi_handle_t
image_handle,
unsigned long *exit_data_size,
s16 **exit_data)
{
- asmlinkage ulong (*entry)(efi_handle_t image_handle,
- struct efi_system_table *st);
+ EFIAPI efi_status_t (*entry)(efi_handle_t image_handle,
+struct efi_system_table *st);
struct efi_loaded_image *info = image_handle;
efi_status_t ret;
--
2.12.3
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] mmc: disable UHS modes if Vcc cannot be switched on and off
On Wed, 2018-01-24 at 17:28 +0900, Jaehoon Chung wrote:
> On 01/23/2018 09:03 PM, Eugeniy Paltsev wrote:
> > On Tue, 2018-01-23 at 10:44 +0900, Jaehoon Chung wrote:
> > > On 01/23/2018 03:38 AM, Eugeniy Paltsev wrote:
> > > > Hi Jean-Jacques,
> > > >
> > > > after commit "mmc: disable UHS modes if Vcc cannot be switched on and
> > > > off" (04a2ea248f)
> > > > we got MMC broken on several (at least two) platforms with DesignWare
> > > > MMC controller.
> > > >
> > > > The error log (with debug enabled in drivers/mmc/mmc.c and
> > > > drivers/mmc/dw_mmc.c) is next:
> > > > --->8-
> > > > MMC: Synopsys Mobile storage: 0
> > > > Buswidth = 0, clock: 40
> > > > selecting mode MMC legacy (freq : 0 MHz)
> > > > Buswidth = 1, clock: 40
> > > > Buswidth = 1, clock: 40
> > > > Sending CMD0
> > > > dwmci_send_cmd: Timeout.
> > > > mmc_init: -110, time 19
> > > > ** Bad device mmc 0 **
> > > > --->8-
> > > >
> > > > Any ideas how to fix this?
> > >
> > > Could you share which git repository you use?
> >
> > I use u-boot master branch from git://git.denx.de/u-boot.git
> >
> > last commits:
> > --->8-
> > 485c13c Merge git://git.denx.de/u-boot-dm
> > b79221a lib: fdtdec: Fix some style violations
> > 2e38662 lib: fdtdec: Fix whitespace style violations
> > 29d11b8 core: Make device_is_compatible live-tree compatible
> > 147c607 core: Add {ofnode, dev}_translate_address functions
> > --->8-
> >
>
> I guess that this issue has already been fixed.
>
> http://patchwork.ozlabs.org/patch/862160/
>
Yep, this patch solves the problem.
Tested-by: Eugeniy Paltsev
Thanks.
> Best Regards,
> Jaehoon Chung
>
> > > Best Regards,
> > > Jaehoon Chung
> > >
> > > >
> > > > Thanks.
> > > >
> > >
> > >
>
>
--
Eugeniy Paltsev
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] mtd: nand: Kconfig Setup missing NAND dependencies based on ARCH
To avoid clutter in the NAND menu, let's make the NAND controllers dependent on which ARCH type uses them. This way, we cannot accidentally try to enable a NAND controller that doesn't exist. This is based on Convert CONFIG_SYS_MAX_NAND_DEVICE to Kconfig and add CONFIG_NAND that was just submitted. Signed-off-by: Adam Ford diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig index e991440..96c118f 100644 --- a/drivers/mtd/nand/Kconfig +++ b/drivers/mtd/nand/Kconfig @@ -9,6 +9,7 @@ config SYS_NAND_SELF_INIT This option, if enabled, provides more flexible and linux-like NAND initialization process. +if ARCH_UNIPHIER config NAND_DENALI bool select SYS_NAND_SELF_INIT @@ -31,6 +32,8 @@ config NAND_DENALI_SPARE_AREA_SKIP_BYTES of OOB area before last ECC sector data starts. This is potentially used to preserve the bad block marker in the OOB area. +endif + config NAND_OMAP_GPMC bool "Support OMAP GPMC NAND controller" depends on ARCH_OMAP2PLUS @@ -87,6 +90,7 @@ endchoice config NAND_PXA3XX bool "Support for NAND on PXA3xx and Armada 370/XP/38x" + depends on ARCH_MVEBU select SYS_NAND_SELF_INIT imply CMD_NAND help @@ -123,6 +127,7 @@ endif config NAND_ARASAN bool "Configure Arasan Nand" + depends on ARCH_ZYNQMP imply CMD_NAND help This enables Nand driver support for Arasan nand flash @@ -147,6 +152,7 @@ config NAND_MXS config NAND_ZYNQ bool "Support for Zynq Nand controller" + depends on ARCH_ZYNQ select SYS_NAND_SELF_INIT imply CMD_NAND help @@ -226,6 +232,7 @@ config SPL_NAND_AM33XX_BCH config SPL_NAND_DENALI bool "Support Denali NAND controller for SPL" + depends on ARCH_UNIPHIER help This is a small implementation of the Denali NAND controller for use on SPL. -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/9] log: Support control over the log output format
On Wed, Jan 24, 2018 at 05:52:37AM -0700, Simon Glass wrote: > Hi Tom, > On 19 January 2018 at 09:20, Tom Rini wrote: > > > > On Thu, Jan 18, 2018 at 01:40:51PM -0800, Simon Glass wrote: > > > Hi, > > > > > > On 28 December 2017 at 12:14, Simon Glass wrote: > > > > This adds a few more features to the log system: > > > > > > > > - 'log format' command to control the log output format > > > > - 'log rec' command to output a log record manually > > > > - log_ret() function to log error-return values > > > > > > > > With these we have more control over how log records are output as well > > > > as the ability to log errors more easily. > > > > > > > > > > > > Simon Glass (9): > > > > dm: core: Add a function to look up a uclass by name > > > > log: Add functions to convert IDs to/from names > > > > log: Add control over log formatting > > > > log: Update log_console to honour the log format > > > > log: Add a command to control the log output format > > > > log: Add a command to output a log record > > > > log: Add tests for the new log features > > > > log: Add documentation for commands and formatting > > > > log: Add a way to log error-return values > > > > > > > > cmd/log.c | 82 > > > > +++ > > > > common/Kconfig| 13 +++ > > > > common/log.c | 68 > > > > common/log_console.c | 27 - > > > > configs/sandbox_defconfig | 1 + > > > > doc/README.log| 35 + > > > > drivers/core/uclass.c | 14 +++ > > > > include/asm-generic/global_data.h | 1 + > > > > include/dm/uclass.h | 8 > > > > include/log.h | 64 +- > > > > test/dm/core.c| 9 + > > > > test/py/tests/test_log.py | 32 +-- > > > > 12 files changed, 348 insertions(+), 6 deletions(-) > > > > > > Are there any comments / reviews on this series, please? I'd like to > > > apply it in this merge window. > > > > What's the size change in the cases where boards can't opt-out? > > There is no size change for boards which don't enable CONFIG_LOG. For > sandbox (which does) the change is: > >sandbox: (for 4/4 boards) all +970.0 data +136.0 rodata +212.0 text +622.0 OK, that's my main concern taken care of, 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 0/2] Fix CAAM for TrustZone enable for warp7
On 24/01/18 12:52, Auer, Lukas wrote: On Tue, 2018-01-23 at 21:10 +, Bryan O'Donoghue wrote: This series is the u-boot fix to a problem we encountered when enabling OPTEE/TrustZone on the WaRP7. The symptom is once TrustZone is activated the first page of CAAM registers becomes read-only, read-zero from the perspective of Linux and other non TrustZone contexts. Offlining the problem with Peng Fan[1] we eventually came to realise the problem could be worked around by 1. Making Linux skip RNG initialisation - a set of patches should be hitting LKML to do just that. 2. Initialising the RNG either from u-boot or OPTEE. In this case u- boot is the right place to-do that because there's upstream code in u-boot that just works. Patch #2 does that for the WaRP7. 3. Ensuring the job-ring registers are assigned to the non TrustZone mode. On the i.MX7 after the BootROM runs the job-ring registers are assigned to TrustZone. Patch #1 does that for all CAAM hardware. I did have the same issue, not with booting OPTEE, but booting Linux in non-secure mode. #2 and #3 are required to handle this problem, but #1 is not needed. The CAAM kernel driver always tries to instantiate all RNG state handles directly using DEC0 (which is only accessible from secure mode). The u-boot driver however only instantiates the first state handle, which is why the kernel driver then goes on and tries to instantiate the second one. This is solved by simply instantiating all RNG state handles in the CAAM u-boot driver. I can prepare a patch to implement this, if there is interest. This is tested to work with the mainline kernel and I assume that it would work with the NXP kernel as well. Further patches are however needed to support the imx7 in the CAAM kernel driver. So I just sent out a patch-set for i.MX7 covering this - I added you to the CC list for that. The guidance from NXP (and my experience) is that the current kernel driver bugs-out when it can't touch the deco registers. I have a bunch of fixes around that. On point #3 this ordinarily isn't a problem because unless TrustZone is activated the restrictions on the job-ring registers don't kick in, its only after enabling TrustZone that Linux will loose access to the job-ring registers. Finally should OPTEE or another TEE want to do things with the job- ring registers it will have sufficient privilege to assign whichever job- ring registers it wants to OPTEE/TEE but will naturally then have to arbitrate with Linux to inform the Kernel CAAM driver which job-ring registers it can and cannot access. That arbitration process is for a future putative OPTEE/TEE CAAM driver to solve and is out of scope of this patchset. This is actually quite simple to solve, since each job ring has a separate device tree node. Simply disabling all job rings used by OPTEE / secure world software should be sufficient. Yes I agree. Then again there is currently no CAAM/OPTEE driver so nothing to-do. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] imx: mx25: Remove SION bit in all pin-mux
SION bit should be used in the situation that we need
to read back the value of a pin and should be set by
default. This can generate any kind of random malfunction
as described in this thread.
According to this thread:
https://www.spinics.net/lists/linux-usb/msg162574.html
We consider this an early bug so all the boards running imx25
with a minimimal set of functionalities can be affected.
As reported by this application note:
https://www.nxp.com/docs/en/application-note/AN5078.pdf
The software input on (SION) bit is an option to force an input
path to be active regardless of the value driven by the
corresponding module. It is used when the nature direction
of a pin depending on selected alternative function is an output,
but it is needed to read the real logic value on a pin.
The SION bit can be used in:
• Loopback: the module of a selected alternative function drives
the pad and also receives the pad value as an input
• GPIO capture: the module of a selected alternative function
drives the pin and the value is captured by the GPIO
Signed-off-by: Michael Trimarchi
---
Refer-to:
MX25 USB timeout on ID 0951:1665 Kingston Technology Digital
DataTraveler SE9 64GB
---
arch/arm/include/asm/arch-mx25/iomux-mx25.h | 680 ++--
1 file changed, 340 insertions(+), 340 deletions(-)
diff --git a/arch/arm/include/asm/arch-mx25/iomux-mx25.h
b/arch/arm/include/asm/arch-mx25/iomux-mx25.h
index 5b2863e..2fcaf60 100644
--- a/arch/arm/include/asm/arch-mx25/iomux-mx25.h
+++ b/arch/arm/include/asm/arch-mx25/iomux-mx25.h
@@ -30,481 +30,481 @@
/* PADMUXALT
INPSE PATH PADCTRL */
enum {
- MX25_PAD_A10__A10 = IOMUX_PAD(0x000, 0x008, 0x00,
0, 0, NO_PAD_CTRL),
- MX25_PAD_A10__GPIO_4_0 = IOMUX_PAD(0x000, 0x008, 0x05,
0, 0, NO_PAD_CTRL),
+ MX25_PAD_A10__A10 = IOMUX_PAD(0x000, 0x008, 0, 0,
0, NO_PAD_CTRL),
+ MX25_PAD_A10__GPIO_4_0 = IOMUX_PAD(0x000, 0x008, 5, 0,
0, NO_PAD_CTRL),
- MX25_PAD_A13__A13 = IOMUX_PAD(0x22C, 0x00c, 0x00,
0, 0, NO_PAD_CTRL),
- MX25_PAD_A13__GPIO_4_1 = IOMUX_PAD(0x22C, 0x00c, 0x05,
0, 0, NO_PAD_CTRL),
+ MX25_PAD_A13__A13 = IOMUX_PAD(0x22C, 0x00c, 0, 0,
0, NO_PAD_CTRL),
+ MX25_PAD_A13__GPIO_4_1 = IOMUX_PAD(0x22C, 0x00c, 5, 0,
0, NO_PAD_CTRL),
- MX25_PAD_A14__A14 = IOMUX_PAD(0x230, 0x010, 0x10,
0, 0, NO_PAD_CTRL),
- MX25_PAD_A14__GPIO_2_0 = IOMUX_PAD(0x230, 0x010, 0x15,
0, 0, NO_PAD_CTRL),
+ MX25_PAD_A14__A14 = IOMUX_PAD(0x230, 0x010, 0, 0,
0, NO_PAD_CTRL),
+ MX25_PAD_A14__GPIO_2_0 = IOMUX_PAD(0x230, 0x010, 5, 0,
0, NO_PAD_CTRL),
- MX25_PAD_A15__A15 = IOMUX_PAD(0x234, 0x014, 0x10,
0, 0, NO_PAD_CTRL),
- MX25_PAD_A15__GPIO_2_1 = IOMUX_PAD(0x234, 0x014, 0x15,
0, 0, NO_PAD_CTRL),
+ MX25_PAD_A15__A15 = IOMUX_PAD(0x234, 0x014, 0, 0,
0, NO_PAD_CTRL),
+ MX25_PAD_A15__GPIO_2_1 = IOMUX_PAD(0x234, 0x014, 5, 0,
0, NO_PAD_CTRL),
- MX25_PAD_A16__A16 = IOMUX_PAD(0x000, 0x018, 0x10,
0, 0, NO_PAD_CTRL),
- MX25_PAD_A16__GPIO_2_2 = IOMUX_PAD(0x000, 0x018, 0x15,
0, 0, NO_PAD_CTRL),
+ MX25_PAD_A16__A16 = IOMUX_PAD(0x000, 0x018, 0, 0,
0, NO_PAD_CTRL),
+ MX25_PAD_A16__GPIO_2_2 = IOMUX_PAD(0x000, 0x018, 5, 0,
0, NO_PAD_CTRL),
- MX25_PAD_A17__A17 = IOMUX_PAD(0x238, 0x01c, 0x10,
0, 0, NO_PAD_CTRL),
- MX25_PAD_A17__GPIO_2_3 = IOMUX_PAD(0x238, 0x01c, 0x15,
0, 0, NO_PAD_CTRL),
+ MX25_PAD_A17__A17 = IOMUX_PAD(0x238, 0x01c, 0, 0,
0, NO_PAD_CTRL),
+ MX25_PAD_A17__GPIO_2_3 = IOMUX_PAD(0x238, 0x01c, 5, 0,
0, NO_PAD_CTRL),
- MX25_PAD_A18__A18 = IOMUX_PAD(0x23c, 0x020, 0x10,
0, 0, NO_PAD_CTRL),
- MX25_PAD_A18__GPIO_2_4 = IOMUX_PAD(0x23c, 0x020, 0x15,
0, 0, NO_PAD_CTRL),
- MX25_PAD_A18__FEC_COL = IOMUX_PAD(0x23c, 0x020, 0x17,
0x504, 0, NO_PAD_CTRL),
+ MX25_PAD_A18__A18 = IOMUX_PAD(0x23c, 0x020, 0, 0,
0, NO_PAD_CTRL),
+ MX25_PAD_A18__GPIO_2_4 = IOMUX_PAD(0x23c, 0x020, 5, 0,
0, NO_PAD_CTRL),
+ MX25_PAD_A18__FEC_COL = IOMUX_PAD(0x23c, 0x020, 7,
0x504, 0, NO_PAD_CTRL),
- MX25_PAD_A19__A19 = IOMUX_PAD(0x240, 0x024, 0x10,
0, 0, NO_PAD_CTRL),
- MX25_PAD_A19__FEC_RX_ER = IOMUX_PAD(0x240, 0x024, 0x17,
0x518, 0, NO_PAD_CTRL),
- MX25_PAD_A19__GPIO_2_5 = IOMUX_PAD(0x240, 0x024, 0x1
Re: [U-Boot] [PATCH] imx: mx25: Remove SION bit in all pin-mux
Hi Michael,
On Wed, Jan 24, 2018 at 12:56 PM, Michael Trimarchi
wrote:
> SION bit should be used in the situation that we need
> to read back the value of a pin and should be set by
> default. This can generate any kind of random malfunction
> as described in this thread.
>
> According to this thread:
> https://www.spinics.net/lists/linux-usb/msg162574.html
>
> We consider this an early bug so all the boards running imx25
> with a minimimal set of functionalities can be affected.
>
> As reported by this application note:
> https://www.nxp.com/docs/en/application-note/AN5078.pdf
>
> The software input on (SION) bit is an option to force an input
> path to be active regardless of the value driven by the
> corresponding module. It is used when the nature direction
> of a pin depending on selected alternative function is an output,
> but it is needed to read the real logic value on a pin.
>
> The SION bit can be used in:
> • Loopback: the module of a selected alternative function drives
> the pad and also receives the pad value as an input
> • GPIO capture: the module of a selected alternative function
> drives the pin and the value is captured by the GPIO
>
> Signed-off-by: Michael Trimarchi
> ---
> Refer-to:
> MX25 USB timeout on ID 0951:1665 Kingston Technology Digital
> DataTraveler SE9 64GB
Glad you found a fix for the issue!
> ---
> arch/arm/include/asm/arch-mx25/iomux-mx25.h | 680
> ++--
> 1 file changed, 340 insertions(+), 340 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-mx25/iomux-mx25.h
> b/arch/arm/include/asm/arch-mx25/iomux-mx25.h
> index 5b2863e..2fcaf60 100644
> --- a/arch/arm/include/asm/arch-mx25/iomux-mx25.h
> +++ b/arch/arm/include/asm/arch-mx25/iomux-mx25.h
> @@ -30,481 +30,481 @@
>
> /* PADMUXALT
> INPSE PATH PADCTRL */
> enum {
> - MX25_PAD_A10__A10 = IOMUX_PAD(0x000, 0x008,
> 0x00, 0, 0, NO_PAD_CTRL),
> - MX25_PAD_A10__GPIO_4_0 = IOMUX_PAD(0x000, 0x008,
> 0x05, 0, 0, NO_PAD_CTRL),
> + MX25_PAD_A10__A10 = IOMUX_PAD(0x000, 0x008, 0,
> 0, 0, NO_PAD_CTRL),
> + MX25_PAD_A10__GPIO_4_0 = IOMUX_PAD(0x000, 0x008, 5,
> 0, 0, NO_PAD_CTRL),
In many places in this patch you are only changing things like 0x00
--> 0 or 0x05--> 5, which just makes it harder to review.
Please send a new version that only removes the SION bit.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] imx: mx25: Remove SION bit in all pin-mux
Hi Fabio
On Wed, Jan 24, 2018 at 4:14 PM, Fabio Estevam wrote:
> Hi Michael,
>
> On Wed, Jan 24, 2018 at 12:56 PM, Michael Trimarchi
> wrote:
>> SION bit should be used in the situation that we need
>> to read back the value of a pin and should be set by
>> default. This can generate any kind of random malfunction
>> as described in this thread.
>>
>> According to this thread:
>> https://www.spinics.net/lists/linux-usb/msg162574.html
>>
>> We consider this an early bug so all the boards running imx25
>> with a minimimal set of functionalities can be affected.
>>
>> As reported by this application note:
>> https://www.nxp.com/docs/en/application-note/AN5078.pdf
>>
>> The software input on (SION) bit is an option to force an input
>> path to be active regardless of the value driven by the
>> corresponding module. It is used when the nature direction
>> of a pin depending on selected alternative function is an output,
>> but it is needed to read the real logic value on a pin.
>>
>> The SION bit can be used in:
>> • Loopback: the module of a selected alternative function drives
>> the pad and also receives the pad value as an input
>> • GPIO capture: the module of a selected alternative function
>> drives the pin and the value is captured by the GPIO
>>
>> Signed-off-by: Michael Trimarchi
>> ---
>> Refer-to:
>> MX25 USB timeout on ID 0951:1665 Kingston Technology Digital
>> DataTraveler SE9 64GB
>
> Glad you found a fix for the issue!
>
The idea was to align to the other freescale architecture. I can
create two patches on it
Michael
>
>> ---
>> arch/arm/include/asm/arch-mx25/iomux-mx25.h | 680
>> ++--
>> 1 file changed, 340 insertions(+), 340 deletions(-)
>>
>> diff --git a/arch/arm/include/asm/arch-mx25/iomux-mx25.h
>> b/arch/arm/include/asm/arch-mx25/iomux-mx25.h
>> index 5b2863e..2fcaf60 100644
>> --- a/arch/arm/include/asm/arch-mx25/iomux-mx25.h
>> +++ b/arch/arm/include/asm/arch-mx25/iomux-mx25.h
>> @@ -30,481 +30,481 @@
>>
>> /* PADMUX
>> ALT INPSE PATH PADCTRL */
>> enum {
>> - MX25_PAD_A10__A10 = IOMUX_PAD(0x000, 0x008,
>> 0x00, 0, 0, NO_PAD_CTRL),
>> - MX25_PAD_A10__GPIO_4_0 = IOMUX_PAD(0x000, 0x008,
>> 0x05, 0, 0, NO_PAD_CTRL),
>> + MX25_PAD_A10__A10 = IOMUX_PAD(0x000, 0x008, 0,
>> 0, 0, NO_PAD_CTRL),
>> + MX25_PAD_A10__GPIO_4_0 = IOMUX_PAD(0x000, 0x008, 5,
>> 0, 0, NO_PAD_CTRL),
>
> In many places in this patch you are only changing things like 0x00
> --> 0 or 0x05--> 5, which just makes it harder to review.
>
> Please send a new version that only removes the SION bit.
--
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO - Founder Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
| [`as] http://www.amarulasolutions.com |
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] imx: mx25: Remove SION bit in all pin-mux
Hi Michael,
On 24/01/2018 at 16:26, Michael Nazzareno Trimarchi wrote:
> On Wed, Jan 24, 2018 at 4:14 PM, Fabio Estevam wrote:
>> On Wed, Jan 24, 2018 at 12:56 PM, Michael Trimarchi
>> wrote:
>>> SION bit should be used in the situation that we need
>>> to read back the value of a pin and should be set by
>>> default.
You remove this bit because it should be set by default? This sentence is
confusing.
>>> This can generate any kind of random malfunction
>>> as described in this thread.
>>>
>>> According to this thread:
>>> https://www.spinics.net/lists/linux-usb/msg162574.html
I can't find details about SION on a specific pin in this thread. Please
elaborate.
>>> We consider this an early bug so all the boards running imx25
>>> with a minimimal set of functionalities can be affected.
>>>
>>> As reported by this application note:
>>> https://www.nxp.com/docs/en/application-note/AN5078.pdf
>>>
>>> The software input on (SION) bit is an option to force an input
>>> path to be active regardless of the value driven by the
>>> corresponding module. It is used when the nature direction
>>> of a pin depending on selected alternative function is an output,
>>> but it is needed to read the real logic value on a pin.
>>>
>>> The SION bit can be used in:
>>> • Loopback: the module of a selected alternative function drives
>>> the pad and also receives the pad value as an input
>>> • GPIO capture: the module of a selected alternative function
>>> drives the pin and the value is captured by the GPIO
>>>
>>> Signed-off-by: Michael Trimarchi
>>> ---
>>> Refer-to:
>>> MX25 USB timeout on ID 0951:1665 Kingston Technology Digital
>>> DataTraveler SE9 64GB
>>
>> Glad you found a fix for the issue!
>>
>
> The idea was to align to the other freescale architecture. I can
> create two patches on it
>
> Michael
>
>>
>>> ---
>>> arch/arm/include/asm/arch-mx25/iomux-mx25.h | 680
>>> ++--
>>> 1 file changed, 340 insertions(+), 340 deletions(-)
>>>
>>> diff --git a/arch/arm/include/asm/arch-mx25/iomux-mx25.h
>>> b/arch/arm/include/asm/arch-mx25/iomux-mx25.h
>>> index 5b2863e..2fcaf60 100644
>>> --- a/arch/arm/include/asm/arch-mx25/iomux-mx25.h
>>> +++ b/arch/arm/include/asm/arch-mx25/iomux-mx25.h
>>> @@ -30,481 +30,481 @@
>>>
>>> /* PADMUX
>>> ALT INPSE PATH PADCTRL */
>>> enum {
>>> - MX25_PAD_A10__A10 = IOMUX_PAD(0x000, 0x008,
>>> 0x00, 0, 0, NO_PAD_CTRL),
>>> - MX25_PAD_A10__GPIO_4_0 = IOMUX_PAD(0x000, 0x008,
>>> 0x05, 0, 0, NO_PAD_CTRL),
>>> + MX25_PAD_A10__A10 = IOMUX_PAD(0x000, 0x008,
>>> 0, 0, 0, NO_PAD_CTRL),
>>> + MX25_PAD_A10__GPIO_4_0 = IOMUX_PAD(0x000, 0x008,
>>> 5, 0, 0, NO_PAD_CTRL),
>>
>> In many places in this patch you are only changing things like 0x00
>> --> 0 or 0x05--> 5, which just makes it harder to review.
>>
>> Please send a new version that only removes the SION bit.
Please make sure that these changes are not breaking anything for any board
(NEW_PAD_CTRL() can be used for these boards to restore SION if it really has to
be removed by default). SION is required in some cases, and it's unlikely to be
harmful, its main side effect being an increased power consumption.
Best regards,
Benoît
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] imx: mx25: Remove SION bit in all pin-mux
On 24/01/2018 at 16:34, Benoît Thébaudeau wrote:
> On 24/01/2018 at 16:26, Michael Nazzareno Trimarchi wrote:
>> On Wed, Jan 24, 2018 at 4:14 PM, Fabio Estevam wrote:
>>> On Wed, Jan 24, 2018 at 12:56 PM, Michael Trimarchi
>>> wrote:
SION bit should be used in the situation that we need
to read back the value of a pin and should be set by
default.
>
> You remove this bit because it should be set by default? This sentence is
> confusing.
>
This can generate any kind of random malfunction
as described in this thread.
According to this thread:
https://www.spinics.net/lists/linux-usb/msg162574.html
>
> I can't find details about SION on a specific pin in this thread. Please
> elaborate.
>
We consider this an early bug so all the boards running imx25
with a minimimal set of functionalities can be affected.
As reported by this application note:
https://www.nxp.com/docs/en/application-note/AN5078.pdf
The software input on (SION) bit is an option to force an input
path to be active regardless of the value driven by the
corresponding module. It is used when the nature direction
of a pin depending on selected alternative function is an output,
but it is needed to read the real logic value on a pin.
The SION bit can be used in:
• Loopback: the module of a selected alternative function drives
the pad and also receives the pad value as an input
• GPIO capture: the module of a selected alternative function
drives the pin and the value is captured by the GPIO
Signed-off-by: Michael Trimarchi
---
Refer-to:
MX25 USB timeout on ID 0951:1665 Kingston Technology Digital
DataTraveler SE9 64GB
>>>
>>> Glad you found a fix for the issue!
>>>
>>
>> The idea was to align to the other freescale architecture. I can
>> create two patches on it
>>
>> Michael
>>
>>>
---
arch/arm/include/asm/arch-mx25/iomux-mx25.h | 680
++--
1 file changed, 340 insertions(+), 340 deletions(-)
diff --git a/arch/arm/include/asm/arch-mx25/iomux-mx25.h
b/arch/arm/include/asm/arch-mx25/iomux-mx25.h
index 5b2863e..2fcaf60 100644
--- a/arch/arm/include/asm/arch-mx25/iomux-mx25.h
+++ b/arch/arm/include/asm/arch-mx25/iomux-mx25.h
@@ -30,481 +30,481 @@
/* PADMUX
ALT INPSE PATH PADCTRL */
enum {
- MX25_PAD_A10__A10 = IOMUX_PAD(0x000, 0x008,
0x00, 0, 0, NO_PAD_CTRL),
- MX25_PAD_A10__GPIO_4_0 = IOMUX_PAD(0x000, 0x008,
0x05, 0, 0, NO_PAD_CTRL),
+ MX25_PAD_A10__A10 = IOMUX_PAD(0x000, 0x008,
0, 0, 0, NO_PAD_CTRL),
+ MX25_PAD_A10__GPIO_4_0 = IOMUX_PAD(0x000, 0x008,
5, 0, 0, NO_PAD_CTRL),
>>>
>>> In many places in this patch you are only changing things like 0x00
>>> --> 0 or 0x05--> 5, which just makes it harder to review.
>>>
>>> Please send a new version that only removes the SION bit.
>
> Please make sure that these changes are not breaking anything for any board
> (NEW_PAD_CTRL() can be used for these boards to restore SION if it really has
> to
> be removed by default). SION is required in some cases, and it's unlikely to
> be
> harmful, its main side effect being an increased power consumption.
Actually, NEW_PAD_CTRL() cannot act upon SION, so removing it by default is all
the more risky.
Benoît
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] imx: mx25: Remove SION bit in all pin-mux
Hi
On Wed, Jan 24, 2018 at 4:39 PM, Benoît Thébaudeau wrote:
> On 24/01/2018 at 16:34, Benoît Thébaudeau wrote:
>> On 24/01/2018 at 16:26, Michael Nazzareno Trimarchi wrote:
>>> On Wed, Jan 24, 2018 at 4:14 PM, Fabio Estevam wrote:
On Wed, Jan 24, 2018 at 12:56 PM, Michael Trimarchi
wrote:
> SION bit should be used in the situation that we need
> to read back the value of a pin and should be set by
> default.
>>
>> You remove this bit because it should be set by default? This sentence is
>> confusing.
English is wrong ;)
SION bit as a specific purpose to read back value that is set in
output. You don't need
and it's not set in any freescale board. If you need to set you need
to add to your peripheral.
The only case you need maybe is the data[0] of sdcard.
Tihs is the reason that in this thread we have NXP people. We have 2
board with mx25 right now
so this will not an high risk break.
Michael
>>
> This can generate any kind of random malfunction
> as described in this thread.
>
> According to this thread:
> https://www.spinics.net/lists/linux-usb/msg162574.html
>>
>> I can't find details about SION on a specific pin in this thread. Please
>> elaborate.
>>
> We consider this an early bug so all the boards running imx25
> with a minimimal set of functionalities can be affected.
>
> As reported by this application note:
> https://www.nxp.com/docs/en/application-note/AN5078.pdf
>
> The software input on (SION) bit is an option to force an input
> path to be active regardless of the value driven by the
> corresponding module. It is used when the nature direction
> of a pin depending on selected alternative function is an output,
> but it is needed to read the real logic value on a pin.
>
> The SION bit can be used in:
> • Loopback: the module of a selected alternative function drives
> the pad and also receives the pad value as an input
> • GPIO capture: the module of a selected alternative function
> drives the pin and the value is captured by the GPIO
>
> Signed-off-by: Michael Trimarchi
> ---
> Refer-to:
> MX25 USB timeout on ID 0951:1665 Kingston Technology Digital
> DataTraveler SE9 64GB
Glad you found a fix for the issue!
>>>
>>> The idea was to align to the other freescale architecture. I can
>>> create two patches on it
>>>
>>> Michael
>>>
> ---
> arch/arm/include/asm/arch-mx25/iomux-mx25.h | 680
> ++--
> 1 file changed, 340 insertions(+), 340 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-mx25/iomux-mx25.h
> b/arch/arm/include/asm/arch-mx25/iomux-mx25.h
> index 5b2863e..2fcaf60 100644
> --- a/arch/arm/include/asm/arch-mx25/iomux-mx25.h
> +++ b/arch/arm/include/asm/arch-mx25/iomux-mx25.h
> @@ -30,481 +30,481 @@
>
> /* PADMUX
> ALT INPSE PATH PADCTRL */
> enum {
> - MX25_PAD_A10__A10 = IOMUX_PAD(0x000, 0x008,
> 0x00, 0, 0, NO_PAD_CTRL),
> - MX25_PAD_A10__GPIO_4_0 = IOMUX_PAD(0x000, 0x008,
> 0x05, 0, 0, NO_PAD_CTRL),
> + MX25_PAD_A10__A10 = IOMUX_PAD(0x000, 0x008,
> 0, 0, 0, NO_PAD_CTRL),
> + MX25_PAD_A10__GPIO_4_0 = IOMUX_PAD(0x000, 0x008,
> 5, 0, 0, NO_PAD_CTRL),
In many places in this patch you are only changing things like 0x00
--> 0 or 0x05--> 5, which just makes it harder to review.
Please send a new version that only removes the SION bit.
>>
>> Please make sure that these changes are not breaking anything for any board
>> (NEW_PAD_CTRL() can be used for these boards to restore SION if it really
>> has to
>> be removed by default). SION is required in some cases, and it's unlikely to
>> be
>> harmful, its main side effect being an increased power consumption.
>
> Actually, NEW_PAD_CTRL() cannot act upon SION, so removing it by default is
> all
> the more risky.
>
> Benoît
--
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO - Founder Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
| [`as] http://www.amarulasolutions.com |
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] imx: mx25: Remove SION bit in all pin-mux
On 24/01/2018 at 16:43, Michael Nazzareno Trimarchi wrote: > On Wed, Jan 24, 2018 at 4:39 PM, Benoît Thébaudeau wrote: >> On 24/01/2018 at 16:34, Benoît Thébaudeau wrote: >>> On 24/01/2018 at 16:26, Michael Nazzareno Trimarchi wrote: On Wed, Jan 24, 2018 at 4:14 PM, Fabio Estevam wrote: > On Wed, Jan 24, 2018 at 12:56 PM, Michael Trimarchi > wrote: >> SION bit should be used in the situation that we need >> to read back the value of a pin and should be set by >> default. >>> >>> You remove this bit because it should be set by default? This sentence is >>> confusing. > > English is wrong ;) > > SION bit as a specific purpose to read back value that is set in > output. You don't need > and it's not set in any freescale board. If you need to set you need > to add to your peripheral. Unless there is a NEW_PAD_CTRL()-like mechanism for SION, all these definitions should be kept in iomux-mx25.h in order not to redefine the register offsets everywhere. AFAIK, all the Freescale boards use the definitions from iomux-mx25.h too. > The only case you need maybe is the data[0] of sdcard. And eSDHC CMD, and I²C probably too. Yet, you are also removing SION in these cases. I have 3 i.M25-based boards working fine with SION. ;) Can you explain the precise issue that you are trying to fix (which pin)? Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] imx: mx25: Remove SION bit in all pin-mux
Hi On Wed, Jan 24, 2018 at 5:03 PM, Benoît Thébaudeau wrote: > On 24/01/2018 at 16:43, Michael Nazzareno Trimarchi wrote: >> On Wed, Jan 24, 2018 at 4:39 PM, Benoît Thébaudeau >> wrote: >>> On 24/01/2018 at 16:34, Benoît Thébaudeau wrote: On 24/01/2018 at 16:26, Michael Nazzareno Trimarchi wrote: > On Wed, Jan 24, 2018 at 4:14 PM, Fabio Estevam wrote: >> On Wed, Jan 24, 2018 at 12:56 PM, Michael Trimarchi >> wrote: >>> SION bit should be used in the situation that we need >>> to read back the value of a pin and should be set by >>> default. You remove this bit because it should be set by default? This sentence is confusing. >> >> English is wrong ;) >> >> SION bit as a specific purpose to read back value that is set in >> output. You don't need >> and it's not set in any freescale board. If you need to set you need >> to add to your peripheral. > > Unless there is a NEW_PAD_CTRL()-like mechanism for SION, all these > definitions > should be kept in iomux-mx25.h in order not to redefine the register offsets > everywhere. AFAIK, all the Freescale boards use the definitions from > iomux-mx25.h too. > >> The only case you need maybe is the data[0] of sdcard. > > And eSDHC CMD, and I²C probably too. Yet, you are also removing SION in these > cases. I have 3 i.M25-based boards working fine with SION. ;) Can you explain > the precise issue that you are trying to fix (which pin)? > Let me summarize for you: - was having a board with linux 2.6.x and uboot from 2009 working fine on a usb pen driver (look on thread in linux-usb) - was having the same board with any version of linux from 3.18 to 4.15 and fail with this pen drive - check back all the changes from linux 2.6.x to linux 4.15.x and compare every single register and all the usb code and was just confirm a better implementation of new kernel. but with a result of a usb stuck on the host port - swap the boot-loader and having a working board - go in deep in boot-loader and compare everything - Understand the difference was the SION bit that was enable on all the mux In general when a board start from reset it has default pin muxing. Each peripheral need to setup the pin muxing according to the real usage. SION by default is not the right way to do it. What is the concept of working board in your side? Just pass your testcase? Ok even this board was passing all test cases apart this usb pen drive. We was having in the field some customer with usb issue time to time and only this proof that somenthing was not real ok. Michael > Best regards, > Benoît -- | Michael Nazzareno Trimarchi Amarula Solutions BV | | COO - Founder Cruquiuskade 47 | | +31(0)851119172 Amsterdam 1018 AM NL | | [`as] http://www.amarulasolutions.com | ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PULL] efi patch queue 2018-01-23
On Tue, Jan 23, 2018 at 11:12:19AM +0100, Alexander Graf wrote: > Hi Tom, > > This is my current patch queue for efi. Please pull. > > Alex > > > The following changes since commit 485c13c7536731991c59f7b3432bc33c9dafb0f0: > > Merge git://git.denx.de/u-boot-dm (2018-01-21 20:13:29 -0500) > > are available in the git repository at: > > git://github.com/agraf/u-boot.git tags/signed-efi-next > > for you to fetch changes up to 003876d4694f1bfdfe6ff9ff0799fda9257cb652: > > efi_selftest: reduce noise in test output for device trees (2018-01-22 > 23:10:20 +0100) > Given the known issue on qemu-x86 that is being fixed, 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] Please pull u-boot-fsl-qoriq master
On Wed, Jan 24, 2018 at 02:00:58AM +, York Sun wrote: > Tom, > > The following changes since commit 485c13c7536731991c59f7b3432bc33c9dafb0f0: > > Merge git://git.denx.de/u-boot-dm (2018-01-21 20:13:29 -0500) > > are available in the git repository at: > > git://git.denx.de/u-boot-fsl-qoriq.git > 6c8945ec41cb7bff27fbacc88316e3e557c20240 > > for you to fetch changes up to 6c8945ec41cb7bff27fbacc88316e3e557c20240: > > armv8: ls1088a: Add IFC and eMMC as qixis boot sources (2018-01-23 > 11:26:21 -0800) > 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] [PATCH] imx: mx25: Remove SION bit in all pin-mux
Hi Fabio
On Wed, Jan 24, 2018 at 4:26 PM, Michael Nazzareno Trimarchi
wrote:
> Hi Fabio
>
> On Wed, Jan 24, 2018 at 4:14 PM, Fabio Estevam wrote:
>> Hi Michael,
>>
Can you check where SION bit is mandatory for mx25? I have on IMX51
some PINMUX where sion is enabled.
I can clean up a bit the patch to just minimize the change. We have for example:
arch/arm/include/asm/arch-mx5/iomux-mx51.h: MX51_PAD_SD1_CMD__SD1_CMD
= IOMUX_PAD(0x79c, 0x394, 0x10, __NA_, 0, MX51_SDHCI_PAD_CTRL),
arch/arm/include/asm/arch-mx5/iomux-mx51.h: MX51_PAD_SD1_CLK__SD1_CLK
= IOMUX_PAD(0x7a0, 0x398, 0x10, __NA_, 0, MX51_SDHCI_PAD_CTRL |
PAD_CTL_HYS),
arch/arm/include/asm/arch-mx5/iomux-mx51.h:
MX51_PAD_SD1_DATA0__SD1_DATA0 = IOMUX_PAD(0x7a4, 0x39c, 0x10, __NA_,
0, MX51_SDHCI_PAD_CTRL),
arch/arm/include/asm/arch-mx5/iomux-mx51.h:
MX51_PAD_SD1_DATA1__SD1_DATA1 = IOMUX_PAD(0x7a8, 0x3a0, 0x10, __NA_,
0, MX51_SDHCI_PAD_CTRL),
arch/arm/include/asm/arch-mx5/iomux-mx51.h:
MX51_PAD_SD1_DATA2__SD1_DATA2 = IOMUX_PAD(0x7ac, 0x3a4, 0x10, __NA_,
0, MX51_SDHCI_PAD_CTRL),
arch/arm/include/asm/arch-mx5/iomux-mx51.h:
MX51_PAD_SD1_DATA3__SD1_DATA3 = IOMUX_PAD(0x7b0, 0x3a8, 0x10, __NA_,
0, MX51_SDHCI_PAD_CTRL),
arch/arm/include/asm/arch-mx5/iomux-mx51.h: MX51_PAD_SD2_CMD__SD2_CMD
= IOMUX_PAD(0x7bc, 0x3b4, 0x10, __NA_, 0, MX51_SDHCI_PAD_CTRL),
arch/arm/include/asm/arch-mx5/iomux-mx51.h: MX51_PAD_SD2_CLK__SD2_CLK
= IOMUX_PAD(0x7c0, 0x3b8, 0x10, __NA_, 0, MX51_SDHCI_PAD_CTRL |
PAD_CTL_HYS),
arch/arm/include/asm/arch-mx5/iomux-mx51.h:
MX51_PAD_SD2_DATA0__SD2_DATA0 = IOMUX_PAD(0x7c4, 0x3bc, 0x10, __NA_,
0, MX51_SDHCI_PAD_CTRL),
arch/arm/include/asm/arch-mx5/iomux-mx51.h:
MX51_PAD_SD2_DATA1__SD2_DATA1 = IOMUX_PAD(0x7c8, 0x3c0, 0x10, __NA_,
0, MX51_SDHCI_PAD_CTRL),
arch/arm/include/asm/arch-mx5/iomux-mx51.h:
MX51_PAD_SD2_DATA2__SD2_DATA2 = IOMUX_PAD(0x7cc, 0x3c4, 0x10, __NA_,
0, MX51_SDHCI_PAD_CTRL),
arch/arm/include/asm/arch-mx5/iomux-mx51.h:
MX51_PAD_SD2_DATA3__SD2_DATA3 = IOMUX_PAD(0x7d0, 0x3c8, 0x10, __NA_,
0, MX51_SDHCI_PAD_CTRL),
In this way we can be sure that we have done in proper way
Michael
>> On Wed, Jan 24, 2018 at 12:56 PM, Michael Trimarchi
>> wrote:
>>> SION bit should be used in the situation that we need
>>> to read back the value of a pin and should be set by
>>> default. This can generate any kind of random malfunction
>>> as described in this thread.
>>>
>>> According to this thread:
>>> https://www.spinics.net/lists/linux-usb/msg162574.html
>>>
>>> We consider this an early bug so all the boards running imx25
>>> with a minimimal set of functionalities can be affected.
>>>
>>> As reported by this application note:
>>> https://www.nxp.com/docs/en/application-note/AN5078.pdf
>>>
>>> The software input on (SION) bit is an option to force an input
>>> path to be active regardless of the value driven by the
>>> corresponding module. It is used when the nature direction
>>> of a pin depending on selected alternative function is an output,
>>> but it is needed to read the real logic value on a pin.
>>>
>>> The SION bit can be used in:
>>> • Loopback: the module of a selected alternative function drives
>>> the pad and also receives the pad value as an input
>>> • GPIO capture: the module of a selected alternative function
>>> drives the pin and the value is captured by the GPIO
>>>
>>> Signed-off-by: Michael Trimarchi
>>> ---
>>> Refer-to:
>>> MX25 USB timeout on ID 0951:1665 Kingston Technology Digital
>>> DataTraveler SE9 64GB
>>
>> Glad you found a fix for the issue!
>>
>
> The idea was to align to the other freescale architecture. I can
> create two patches on it
>
> Michael
>
>>
>>> ---
>>> arch/arm/include/asm/arch-mx25/iomux-mx25.h | 680
>>> ++--
>>> 1 file changed, 340 insertions(+), 340 deletions(-)
>>>
>>> diff --git a/arch/arm/include/asm/arch-mx25/iomux-mx25.h
>>> b/arch/arm/include/asm/arch-mx25/iomux-mx25.h
>>> index 5b2863e..2fcaf60 100644
>>> --- a/arch/arm/include/asm/arch-mx25/iomux-mx25.h
>>> +++ b/arch/arm/include/asm/arch-mx25/iomux-mx25.h
>>> @@ -30,481 +30,481 @@
>>>
>>> /* PADMUX
>>> ALT INPSE PATH PADCTRL */
>>> enum {
>>> - MX25_PAD_A10__A10 = IOMUX_PAD(0x000, 0x008,
>>> 0x00, 0, 0, NO_PAD_CTRL),
>>> - MX25_PAD_A10__GPIO_4_0 = IOMUX_PAD(0x000, 0x008,
>>> 0x05, 0, 0, NO_PAD_CTRL),
>>> + MX25_PAD_A10__A10 = IOMUX_PAD(0x000, 0x008,
>>> 0, 0, 0, NO_PAD_CTRL),
>>> + MX25_PAD_A10__GPIO_4_0 = IOMUX_PAD(0x000, 0x008,
>>> 5, 0, 0, NO_PAD_CTRL),
>>
>> In many places in this patch you are only changing things like 0x00
>> --> 0 or 0x05--> 5, which just makes it harder to review.
>>
>> Please send a new version that only removes the SION bit.
>
>
>
> --
> | Michael Nazzareno Trimarchi Amarula Solutions BV |
> | COO - Founder Cruquiuskade 47 |
> | +31(0)
Re: [U-Boot] [PATCH] imx: mx25: Remove SION bit in all pin-mux
Hi, On 24/01/2018 at 17:17, Michael Nazzareno Trimarchi wrote: > On Wed, Jan 24, 2018 at 5:03 PM, Benoît Thébaudeau wrote: >> On 24/01/2018 at 16:43, Michael Nazzareno Trimarchi wrote: >>> On Wed, Jan 24, 2018 at 4:39 PM, Benoît Thébaudeau >>> wrote: On 24/01/2018 at 16:34, Benoît Thébaudeau wrote: > On 24/01/2018 at 16:26, Michael Nazzareno Trimarchi wrote: >> On Wed, Jan 24, 2018 at 4:14 PM, Fabio Estevam >> wrote: >>> On Wed, Jan 24, 2018 at 12:56 PM, Michael Trimarchi >>> wrote: SION bit should be used in the situation that we need to read back the value of a pin and should be set by default. > > You remove this bit because it should be set by default? This sentence is > confusing. >>> >>> English is wrong ;) >>> >>> SION bit as a specific purpose to read back value that is set in >>> output. You don't need >>> and it's not set in any freescale board. If you need to set you need >>> to add to your peripheral. >> >> Unless there is a NEW_PAD_CTRL()-like mechanism for SION, all these >> definitions >> should be kept in iomux-mx25.h in order not to redefine the register offsets >> everywhere. AFAIK, all the Freescale boards use the definitions from >> iomux-mx25.h too. >> >>> The only case you need maybe is the data[0] of sdcard. >> >> And eSDHC CMD, and I²C probably too. Yet, you are also removing SION in these >> cases. I have 3 i.M25-based boards working fine with SION. ;) Can you explain >> the precise issue that you are trying to fix (which pin)? >> > > Let me summarize for you: > - was having a board with linux 2.6.x and uboot from 2009 working fine > on a usb pen driver (look on thread in linux-usb) > - was having the same board with any version of linux from 3.18 to > 4.15 and fail with this pen drive > - check back all the changes from linux 2.6.x to linux 4.15.x and > compare every single register and all the usb code and was just > confirm a better implementation of new kernel. > but with a result of a usb stuck on the host port > - swap the boot-loader and having a working board > - go in deep in boot-loader and compare everything > - Understand the difference was the SION bit that was enable on all the mux > > In general when a board start from reset it has default pin muxing. > Each peripheral need to setup the pin muxing according to the real > usage. > SION by default is not the right way to do it. What is the concept of > working board in your side? Just pass your testcase? Ok even this > board > was passing all test cases apart this usb pen drive. We was having in > the field some customer with usb issue time to time and only this > proof that somenthing was not real ok. Thanks for these details. All the test cases should of course work. I'm just trying to figure out the root cause of your issue, and maybe it's not SION itself but a power issue triggered by SION, or maybe it's SION only for some specific pads and not for all the pads, or something else. So what I'm saying is that this change might be too large, and care should be taken. Some Freescale boards actually do use SION. E.g., see MX25_PAD_FEC_MDIO__FEC_MDIO in https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/imx25-pdk.dts?h=v4.15-rc9 . SION is required to read back the actual state of a GPIO in output mode. It is also required for some bidirectional alternate functions (such as I²C SDA/SCL, SD CMD/DATn, etc.) on some i.MXs (not all i.MXs behave in the same way for the same peripheral), but which ones are affected is not always documented, so please double check and test all these cases. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] imx: mx25: Remove SION bit in all pin-mux
Hi Michael, [Removed usb list as this is off-topic for them] On Wed, Jan 24, 2018 at 2:31 PM, Michael Nazzareno Trimarchi wrote: > Can you check where SION bit is mandatory for mx25? I have on IMX51 > some PINMUX where sion is enabled. > I can clean up a bit the patch to just minimize the change. We have for > example: I think it depends on the pin function per board design, no? Benoît brings a good point: what is the exact pin that causes the USB failure on your case? Let's try to understand the exact pin that is causing the problem on your board. Thanks ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 00/12] sunxi: arm64 binary size fixes
On Tue, Jan 16, 2018 at 2:14 PM, Maxime Ripard wrote: > Hi, > > As we discussed already, this is the list of options that we will need > to disable by default. > > I also added to the mix a size check, which even though it's not > really optimal, is temporary and will be removed in a future (and > hopefully close) release. > > Tom, is this still something we can merge for 2018.01? > > Thanks! > Maxime > > Changes from v1: > - Fixed a couple of nitpicks > - Rebased on top of current master > - Fixed a build error with boards using DFU > > Andre Heider (1): > sunxi: imply CONFIG_OF_LIBFDT_OVERLAY > > Maxime Ripard (11): > dfu: select HASH > cmd: crc32: Disable by default on sunXi > cmd: unzip: Disable by default on sunXi > cmd: loadb: Disable by default on sunXi > cmd: loads: Disable by default on sunXi > cmd: misc: Disable by default on sunXi > video: bpp8: Disable by default on sunXi > video: bpp16: Disable by default on sunXi > net: regex: Disable by default on sunXi > Makefile: Add size check to the u-boot.itb make target > sunxi: Add limit with the MMC environment Reviewed-by: Jagan Teki ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] gpio: sunxi: Add compatible string for H5 PIO
On Tue, Jan 16, 2018 at 3:58 AM, Chris Blake wrote:
> Due to the changes in
> https://github.com/linux-sunxi/u-boot-sunxi/commit/8faac0941cd409c6ff3738fbf658de2296f48e9a,
> allwinner,sun50i-h5-pinctrl needs to be defined otherwise PIO does not work
> on H5 based boards.
>
> Signed-off-by: Chris Blake
> ---
> drivers/gpio/sunxi_gpio.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpio/sunxi_gpio.c b/drivers/gpio/sunxi_gpio.c
> index b47cc66..856b7ef 100644
> --- a/drivers/gpio/sunxi_gpio.c
> +++ b/drivers/gpio/sunxi_gpio.c
> @@ -345,6 +345,7 @@ static const struct udevice_id sunxi_gpio_ids[] = {
> ID("allwinner,sun4i-a10-pinctrl", a_all),
> ID("allwinner,sun5i-a10s-pinctrl", a_all),
> ID("allwinner,sun5i-a13-pinctrl", a_all),
> + ID("allwinner,sun50i-h5-pinctrl", a_all),
Reviewed-by: Jagan Teki
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] imx: mx25: Remove SION bit in all pin-mux
Hi Fabio On Wed, Jan 24, 2018 at 5:38 PM, Fabio Estevam wrote: > Hi Michael, > > [Removed usb list as this is off-topic for them] > > On Wed, Jan 24, 2018 at 2:31 PM, Michael Nazzareno Trimarchi > wrote: > >> Can you check where SION bit is mandatory for mx25? I have on IMX51 >> some PINMUX where sion is enabled. >> I can clean up a bit the patch to just minimize the change. We have for >> example: > > I think it depends on the pin function per board design, no? > I don't have a pdk and it's difficult to find them so I need to check. Anyway some revision of the firmware on this pendrive are working but the latest one is not working. I have a lot of pen drives and all of them are fully working. > Benoît brings a good point: what is the exact pin that causes the USB > failure on your case? I have tested only with uart and already it does not let it work properly. So I can try to limit in my boot case but I don't think that having SION bit pre-defined it's valid at all. We have a limited number of pin mux with SION enable on any nxp architecture right now for every architecture. * Benoit * can you test them? I will provide a better changeset let sdcard and some ethernet pin in the right configuation (even ethernet was working without SION enable) > > Let's try to understand the exact pin that is causing the problem on your > board. > I will check it out. This was an initial patch proposal > Thanks -- | Michael Nazzareno Trimarchi Amarula Solutions BV | | COO - Founder Cruquiuskade 47 | | +31(0)851119172 Amsterdam 1018 AM NL | | [`as] http://www.amarulasolutions.com | ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] Fix CAAM for TrustZone enable for warp7
On Tue, 2018-01-23 at 21:10 +, Bryan O'Donoghue wrote: > This series is the u-boot fix to a problem we encountered when > enabling > OPTEE/TrustZone on the WaRP7. The symptom is once TrustZone is > activated > the first page of CAAM registers becomes read-only, read-zero from > the > perspective of Linux and other non TrustZone contexts. > > Offlining the problem with Peng Fan[1] we eventually came to realise > the > problem could be worked around by > > 1. Making Linux skip RNG initialisation - a set of patches should be >hitting LKML to do just that. > > 2. Initialising the RNG either from u-boot or OPTEE. In this case u- > boot is >the right place to-do that because there's upstream code in u-boot > that >just works. Patch #2 does that for the WaRP7. > > 3. Ensuring the job-ring registers are assigned to the non TrustZone > mode. >On the i.MX7 after the BootROM runs the job-ring registers are > assigned >to TrustZone. Patch #1 does that for all CAAM hardware. > I did have the same issue, not with booting OPTEE, but booting Linux in non-secure mode. #2 and #3 are required to handle this problem, but #1 is not needed. The CAAM kernel driver always tries to instantiate all RNG state handles directly using DEC0 (which is only accessible from secure mode). The u-boot driver however only instantiates the first state handle, which is why the kernel driver then goes on and tries to instantiate the second one. This is solved by simply instantiating all RNG state handles in the CAAM u-boot driver. I can prepare a patch to implement this, if there is interest. This is tested to work with the mainline kernel and I assume that it would work with the NXP kernel as well. Further patches are however needed to support the imx7 in the CAAM kernel driver. > On point #3 this ordinarily isn't a problem because unless TrustZone > is > activated the restrictions on the job-ring registers don't kick in, > its > only after enabling TrustZone that Linux will loose access to the > job-ring > registers. > > Finally should OPTEE or another TEE want to do things with the job- > ring > registers it will have sufficient privilege to assign whichever job- > ring > registers it wants to OPTEE/TEE but will naturally then have to > arbitrate > with Linux to inform the Kernel CAAM driver which job-ring registers > it can > and cannot access. > > That arbitration process is for a future putative OPTEE/TEE CAAM > driver to > solve and is out of scope of this patchset. This is actually quite simple to solve, since each job ring has a separate device tree node. Simply disabling all job rings used by OPTEE / secure world software should be sufficient. Thanks, Lukas > [1] Thanks for all of your help BTW - Peng, there's no way this would > be > working without you giving direction on how. > > Bryan O'Donoghue (2): > drivers/crypto/fsl: assign job-rings to non-TrustZone > warp7 : run sec_init for CAAM RNG > > board/warp7/warp7.c | 6 +- > drivers/crypto/fsl/jr.c | 9 + > drivers/crypto/fsl/jr.h | 1 + > 3 files changed, 15 insertions(+), 1 deletion(-) > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Manual is out of date, missing commands and information
This manual http://www.denx.de/wiki/DULG/Manual is out of date and missing a lot of info. I have been using it thinking it was the official manual. But then I learned many commands are not listed there. Please take down the manual so that people don't mistakenly use it thinking it is correct. -Nate This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing or copying of this email is strictly prohibited. If you have received this email in error, please immediately notify the Network Administrator by telephone at 336.615.8555. You will be reimbursed for reasonable costs incurred in notifying us. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Guide to hush shell in u-boot
Anyone know where a guide to hush shell in u-boot would be? -Nate This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing or copying of this email is strictly prohibited. If you have received this email in error, please immediately notify the Network Administrator by telephone at 336.615.8555. You will be reimbursed for reasonable costs incurred in notifying us. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] imx: mx25: Remove SION bit in all pin-mux
Hi Michael, On 24/01/2018 at 17:46, Michael Nazzareno Trimarchi wrote: > On Wed, Jan 24, 2018 at 5:38 PM, Fabio Estevam wrote: >> Hi Michael, >> >> [Removed usb list as this is off-topic for them] >> >> On Wed, Jan 24, 2018 at 2:31 PM, Michael Nazzareno Trimarchi >> wrote: >> >>> Can you check where SION bit is mandatory for mx25? I have on IMX51 >>> some PINMUX where sion is enabled. >>> I can clean up a bit the patch to just minimize the change. We have for >>> example: >> >> I think it depends on the pin function per board design, no? >> > > I don't have a pdk and it's difficult to find them so I need to check. Anyway > some revision of the firmware on this pendrive are working but the latest one > is not working. I have a lot of pen drives and all of them are fully working. > >> Benoît brings a good point: what is the exact pin that causes the USB >> failure on your case? > > I have tested only with uart and already it does not let it work > properly. So I can try > to limit in my boot case but I don't think that having SION bit > pre-defined it's valid > at all. We have a limited number of pin mux with SION enable on any nxp > architecture right now for every architecture. > > * Benoit * can you test them? I will provide a better changeset let > sdcard and some ethernet pin > in the right configuation (even ethernet was working without SION enable) Not sure I can find time for that. Perhaps in a few days. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] Fix build of socfpga targets when CONFIG_SPL is not set (i.e., you do not want to generate preloader image)
Disabling preloader generation on socfpga have issue with the Kconfig rules. Disabling it in the menuconfig gave error on console, and building with CONFIG_SPL=n resulted in compile error. Signed-off-by: Eric Hoffman --- arch/arm/Kconfig | 4 ++-- include/configs/socfpga_common.h | 2 ++ 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index f6d57f5505..0ffdf2ef7f 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -707,14 +707,14 @@ config ARCH_SOCFPGA select CPU_V7 select SUPPORT_SPL select OF_CONTROL - select SPL_OF_CONTROL + select SPL_OF_CONTROL if SPL select DM select DM_SPI_FLASH select DM_SPI select ENABLE_ARM_SOC_BOOT0_HOOK select ARCH_EARLY_INIT_R select ARCH_MISC_INIT - select SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION + select SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION if SPL select SYS_THUMB_BUILD imply CMD_MTDPARTS imply CRC32_VERIFY diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h index 66e7c4fc8b..b2fa30a59f 100644 --- a/include/configs/socfpga_common.h +++ b/include/configs/socfpga_common.h @@ -20,7 +20,9 @@ #define CONFIG_TIMESTAMP /* Print image info with timestamp */ /* add target to build it automatically upon "make" */ +#if defined(CONFIG_SPL) #define CONFIG_BUILD_TARGET"u-boot-with-spl.sfp" +#endif /* * Memory configurations -- 2.15.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] imx: mx25: Remove SION bit in all pin-mux
Hi On Wed, Jan 24, 2018 at 6:05 PM, Benoît Thébaudeau wrote: > Hi Michael, > > On 24/01/2018 at 17:46, Michael Nazzareno Trimarchi wrote: >> On Wed, Jan 24, 2018 at 5:38 PM, Fabio Estevam wrote: >>> Hi Michael, >>> >>> [Removed usb list as this is off-topic for them] >>> >>> On Wed, Jan 24, 2018 at 2:31 PM, Michael Nazzareno Trimarchi >>> wrote: >>> Can you check where SION bit is mandatory for mx25? I have on IMX51 some PINMUX where sion is enabled. I can clean up a bit the patch to just minimize the change. We have for example: >>> >>> I think it depends on the pin function per board design, no? >>> >> >> I don't have a pdk and it's difficult to find them so I need to check. Anyway >> some revision of the firmware on this pendrive are working but the latest one >> is not working. I have a lot of pen drives and all of them are fully working. >> >>> Benoît brings a good point: what is the exact pin that causes the USB >>> failure on your case? >> >> I have tested only with uart and already it does not let it work >> properly. So I can try >> to limit in my boot case but I don't think that having SION bit >> pre-defined it's valid >> at all. We have a limited number of pin mux with SION enable on any nxp >> architecture right now for every architecture. >> >> * Benoit * can you test them? I will provide a better changeset let >> sdcard and some ethernet pin >> in the right configuation (even ethernet was working without SION enable) > > Not sure I can find time for that. Perhaps in a few days. > From the datasheet I have: Software Input On Field. Force the selected mux mode Input path no matter of MUX_MODE functionality. 1: Force input path of pad A14. 0: Input Path is determined by functionality of the selected mux mode (regular). So i think that in case of some peripheral this is not relevant but I need confirmation Michael > Best regards, > Benoît -- | Michael Nazzareno Trimarchi Amarula Solutions BV | | COO - Founder Cruquiuskade 47 | | +31(0)851119172 Amsterdam 1018 AM NL | | [`as] http://www.amarulasolutions.com | ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] imx: mx25: Remove SION bit in all pin-mux
On 24/01/2018 at 18:12, Michael Nazzareno Trimarchi wrote: > On Wed, Jan 24, 2018 at 6:05 PM, Benoît Thébaudeau wrote: >> Hi Michael, >> >> On 24/01/2018 at 17:46, Michael Nazzareno Trimarchi wrote: >>> On Wed, Jan 24, 2018 at 5:38 PM, Fabio Estevam wrote: Hi Michael, [Removed usb list as this is off-topic for them] On Wed, Jan 24, 2018 at 2:31 PM, Michael Nazzareno Trimarchi wrote: > Can you check where SION bit is mandatory for mx25? I have on IMX51 > some PINMUX where sion is enabled. > I can clean up a bit the patch to just minimize the change. We have for > example: I think it depends on the pin function per board design, no? >>> >>> I don't have a pdk and it's difficult to find them so I need to check. >>> Anyway >>> some revision of the firmware on this pendrive are working but the latest >>> one >>> is not working. I have a lot of pen drives and all of them are fully >>> working. >>> Benoît brings a good point: what is the exact pin that causes the USB failure on your case? >>> >>> I have tested only with uart and already it does not let it work >>> properly. So I can try >>> to limit in my boot case but I don't think that having SION bit >>> pre-defined it's valid >>> at all. We have a limited number of pin mux with SION enable on any nxp >>> architecture right now for every architecture. >>> >>> * Benoit * can you test them? I will provide a better changeset let >>> sdcard and some ethernet pin >>> in the right configuation (even ethernet was working without SION enable) >> >> Not sure I can find time for that. Perhaps in a few days. >> > >>From the datasheet I have: > > Software Input On Field. Force the selected mux mode Input path no > matter of MUX_MODE functionality. > 1: Force input path of pad A14. > 0: Input Path is determined by functionality of the selected mux mode > (regular). > > So i think that in case of some peripheral this is not relevant but I > need confirmation I think I remember people on the U-Boot mailing list having had issues after having dropped SION for some bidirectional alternate functions on some i.MXs (maybe I²C SDA/SCL on i.MX51, which is very close to i.MX25). It is not possible to assume that all peripherals drive the input circuitry properly without SION for bidirectional signals. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] imx: mx25: Remove SION bit in all pin-mux
Hi Michael, On Wed, Jan 24, 2018 at 3:12 PM, Michael Nazzareno Trimarchi wrote: > From the datasheet I have: > > Software Input On Field. Force the selected mux mode Input path no > matter of MUX_MODE functionality. > 1: Force input path of pad A14. > 0: Input Path is determined by functionality of the selected mux mode > (regular). > > So i think that in case of some peripheral this is not relevant but I > need confirmation Looking at arch/arm/boot/dts/imx25-pinfunc.h I see that there is only one pin that sets the SION bit in the common pin definition: /* * Removing the SION bit from MX25_PAD_SD1_CMD__SD1_CMD breaks detecting an SD * card. According to the i.MX25 reference manual (e.g. Figure 23-2 in IMX25RM * Rev. 2 from 01/2011) this pin is bidirectional. So it seems to be a silicon * bug that configuring the SD1_CMD function doesn't enable the input path for * this pin. * This might have side effects for other hardware units that are connected to * that pin and use the respective function as input. */ #define MX25_PAD_SD1_CMD__SD1_CMD0x190 0x388 0x000 0x10 0x000 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] imx: mx25: Remove SION bit in all pin-mux
Hi Fabio, On 24/01/2018 at 18:21, Fabio Estevam wrote: > On Wed, Jan 24, 2018 at 3:12 PM, Michael Nazzareno Trimarchi > wrote: > >> From the datasheet I have: >> >> Software Input On Field. Force the selected mux mode Input path no >> matter of MUX_MODE functionality. >> 1: Force input path of pad A14. >> 0: Input Path is determined by functionality of the selected mux mode >> (regular). >> >> So i think that in case of some peripheral this is not relevant but I >> need confirmation > > Looking at arch/arm/boot/dts/imx25-pinfunc.h I see that there is only > one pin that sets the SION bit in the common pin definition: > > /* > * Removing the SION bit from MX25_PAD_SD1_CMD__SD1_CMD breaks detecting an SD > * card. According to the i.MX25 reference manual (e.g. Figure 23-2 in IMX25RM > * Rev. 2 from 01/2011) this pin is bidirectional. So it seems to be a silicon > * bug that configuring the SD1_CMD function doesn't enable the input path for > * this pin. > * This might have side effects for other hardware units that are connected to > * that pin and use the respective function as input. > */ > #define MX25_PAD_SD1_CMD__SD1_CMD0x190 0x388 0x000 0x10 0x000 In mainline Linux, SION is also set by some DTS files (MX25_PAD_* 0x4000 flag) for FEC MDIO and SD CMD/CLK/DATAn. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] imx: mx25: Remove SION bit in all pin-mux
Hi On Wed, Jan 24, 2018 at 6:29 PM, Benoît Thébaudeau wrote: > Hi Fabio, > > On 24/01/2018 at 18:21, Fabio Estevam wrote: >> On Wed, Jan 24, 2018 at 3:12 PM, Michael Nazzareno Trimarchi >> wrote: >> >>> From the datasheet I have: >>> >>> Software Input On Field. Force the selected mux mode Input path no >>> matter of MUX_MODE functionality. >>> 1: Force input path of pad A14. >>> 0: Input Path is determined by functionality of the selected mux mode >>> (regular). >>> >>> So i think that in case of some peripheral this is not relevant but I >>> need confirmation >> >> Looking at arch/arm/boot/dts/imx25-pinfunc.h I see that there is only >> one pin that sets the SION bit in the common pin definition: >> >> /* >> * Removing the SION bit from MX25_PAD_SD1_CMD__SD1_CMD breaks detecting an >> SD >> * card. According to the i.MX25 reference manual (e.g. Figure 23-2 in >> IMX25RM >> * Rev. 2 from 01/2011) this pin is bidirectional. So it seems to be a >> silicon >> * bug that configuring the SD1_CMD function doesn't enable the input path >> for >> * this pin. >> * This might have side effects for other hardware units that are connected >> to >> * that pin and use the respective function as input. >> */ >> #define MX25_PAD_SD1_CMD__SD1_CMD0x190 0x388 0x000 0x10 0x000 > > In mainline Linux, SION is also set by some DTS files (MX25_PAD_* 0x4000 > flag) for FEC MDIO and SD CMD/CLK/DATAn. Think that is not needed . I will check Michael > > Best regards, > Benoît -- | Michael Nazzareno Trimarchi Amarula Solutions BV | | COO - Founder Cruquiuskade 47 | | +31(0)851119172 Amsterdam 1018 AM NL | | [`as] http://www.amarulasolutions.com | ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] imx: mx25: Remove SION bit in all pin-mux
Hi Benoît, On Wed, Jan 24, 2018 at 3:29 PM, Benoît Thébaudeau wrote: > In mainline Linux, SION is also set by some DTS files (MX25_PAD_* 0x4000 > flag) for FEC MDIO and SD CMD/CLK/DATAn. Which I think it is fine as it is set on a per board basis. Maybe we could do the same in U-Boot. Thanks ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] Fix CAAM for TrustZone enable for warp7
On Wed, 2018-01-24 at 14:35 +, Bryan O'Donoghue wrote: > > On 24/01/18 12:52, Auer, Lukas wrote: > > On Tue, 2018-01-23 at 21:10 +, Bryan O'Donoghue wrote: > > > This series is the u-boot fix to a problem we encountered when > > > enabling > > > OPTEE/TrustZone on the WaRP7. The symptom is once TrustZone is > > > activated > > > the first page of CAAM registers becomes read-only, read-zero > > > from > > > the > > > perspective of Linux and other non TrustZone contexts. > > > > > > Offlining the problem with Peng Fan[1] we eventually came to > > > realise > > > the > > > problem could be worked around by > > > > > > 1. Making Linux skip RNG initialisation - a set of patches should > > > be > > > hitting LKML to do just that. > > > > > > 2. Initialising the RNG either from u-boot or OPTEE. In this case > > > u- > > > boot is > > > the right place to-do that because there's upstream code in > > > u-boot > > > that > > > just works. Patch #2 does that for the WaRP7. > > > > > > 3. Ensuring the job-ring registers are assigned to the non > > > TrustZone > > > mode. > > > On the i.MX7 after the BootROM runs the job-ring registers > > > are > > > assigned > > > to TrustZone. Patch #1 does that for all CAAM hardware. > > > > > > > I did have the same issue, not with booting OPTEE, but booting > > Linux in > > non-secure mode. #2 and #3 are required to handle this problem, but > > #1 > > is not needed. > > > > The CAAM kernel driver always tries to instantiate all RNG state > > handles directly using DEC0 (which is only accessible from secure > > mode). The u-boot driver however only instantiates the first state > > handle, which is why the kernel driver then goes on and tries to > > instantiate the second one. This is solved by simply instantiating > > all > > RNG state handles in the CAAM u-boot driver. > > > > I can prepare a patch to implement this, if there is interest. This > > is > > tested to work with the mainline kernel and I assume that it would > > work > > with the NXP kernel as well. Further patches are however needed to > > support the imx7 in the CAAM kernel driver. > > So I just sent out a patch-set for i.MX7 covering this - I added you > to > the CC list for that. > > The guidance from NXP (and my experience) is that the current kernel > driver bugs-out when it can't touch the deco registers. > > I have a bunch of fixes around that. Thanks for adding me to the CC list. I have experienced the same thing regarding the dec0 registers. However, I don't understand why you want to detect secure mode in the kernel driver to skip RNG instantiation instead of instantiating all RNG state handles in the u-boot driver. This way, the kernel driver would skip both state handles (instead of just the first one as with the current u-boot driver) in the probe call. The dec0 registers would therefore never be used. In addition, skipping RNG instantiation in the kernel driver means that the second state handle never gets instantiated. > > > > > On point #3 this ordinarily isn't a problem because unless > > > TrustZone > > > is > > > activated the restrictions on the job-ring registers don't kick > > > in, > > > its > > > only after enabling TrustZone that Linux will loose access to the > > > job-ring > > > registers. > > > > > > Finally should OPTEE or another TEE want to do things with the > > > job- > > > ring > > > registers it will have sufficient privilege to assign whichever > > > job- > > > ring > > > registers it wants to OPTEE/TEE but will naturally then have to > > > arbitrate > > > with Linux to inform the Kernel CAAM driver which job-ring > > > registers > > > it can > > > and cannot access. > > > > > > That arbitration process is for a future putative OPTEE/TEE CAAM > > > driver to > > > solve and is out of scope of this patchset. > > > > This is actually quite simple to solve, since each job ring has a > > separate device tree node. Simply disabling all job rings used by > > OPTEE > > / secure world software should be sufficient. > > Yes I agree. Then again there is currently no CAAM/OPTEE driver so > nothing to-do. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] imx: mx25: Remove SION bit in all pin-mux
Hi On Wed, Jan 24, 2018 at 6:36 PM, Fabio Estevam wrote: > Hi Benoît, > > On Wed, Jan 24, 2018 at 3:29 PM, Benoît Thébaudeau wrote: > >> In mainline Linux, SION is also set by some DTS files (MX25_PAD_* 0x4000 >> flag) for FEC MDIO and SD CMD/CLK/DATAn. > > Which I think it is fine as it is set on a per board basis. > > Maybe we could do the same in U-Boot. > This is exactly my initial propose. Can we give a try and manage on board level? Michael > Thanks -- | Michael Nazzareno Trimarchi Amarula Solutions BV | | COO - Founder Cruquiuskade 47 | | +31(0)851119172 Amsterdam 1018 AM NL | | [`as] http://www.amarulasolutions.com | ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] fdt: Implement weak arch_fixup_fdt()
Only ARM and in some configs MIPS really implement arch_fixup_fdt().
Others just use the same boilerplate which is not good by itself,
but what's worse if we try to build with disabled CONFIG_CMD_BOOTM
and enabled CONFIG_OF_LIBFDT we'll hit an unknown symbol which was
apparently implemented in arch/xxx/lib/bootm.c.
Now with weak arch_fixup_fdt() right in image-fdt.c where it is
used we get both items highlighted above fixed.
Signed-off-by: Alexey Brodkin
Cc: Daniel Schwierzeck
Cc: Simon Glass
Cc: York Sun
Cc: Stefan Roese
---
arch/arc/lib/bootm.c| 5 -
arch/microblaze/lib/bootm.c | 5 -
arch/mips/lib/bootm.c | 6 ++
arch/nds32/lib/bootm.c | 6 --
arch/powerpc/lib/bootm.c| 5 -
arch/sandbox/lib/bootm.c| 5 -
arch/x86/lib/bootm.c| 5 -
common/image-fdt.c | 5 +
8 files changed, 7 insertions(+), 35 deletions(-)
diff --git a/arch/arc/lib/bootm.c b/arch/arc/lib/bootm.c
index 9eef7070cf43..4d4acff239d4 100644
--- a/arch/arc/lib/bootm.c
+++ b/arch/arc/lib/bootm.c
@@ -37,11 +37,6 @@ void arch_lmb_reserve(struct lmb *lmb)
lmb_reserve(lmb, sp, (CONFIG_SYS_SDRAM_BASE + gd->ram_size - sp));
}
-int arch_fixup_fdt(void *blob)
-{
- return 0;
-}
-
static int cleanup_before_linux(void)
{
disable_interrupts();
diff --git a/arch/microblaze/lib/bootm.c b/arch/microblaze/lib/bootm.c
index 0a286e82c2be..f33ef087577d 100644
--- a/arch/microblaze/lib/bootm.c
+++ b/arch/microblaze/lib/bootm.c
@@ -17,11 +17,6 @@
DECLARE_GLOBAL_DATA_PTR;
-int arch_fixup_fdt(void *blob)
-{
- return 0;
-}
-
int do_bootm_linux(int flag, int argc, char * const argv[],
bootm_headers_t *images)
{
diff --git a/arch/mips/lib/bootm.c b/arch/mips/lib/bootm.c
index 5a9a2811ffb5..9dc47407684b 100644
--- a/arch/mips/lib/bootm.c
+++ b/arch/mips/lib/bootm.c
@@ -253,17 +253,15 @@ static int boot_reloc_fdt(bootm_headers_t *images)
#endif
}
+#if CONFIG_IS_ENABLED(MIPS_BOOT_FDT) && CONFIG_IS_ENABLED(OF_LIBFDT)
int arch_fixup_fdt(void *blob)
{
-#if CONFIG_IS_ENABLED(MIPS_BOOT_FDT) && CONFIG_IS_ENABLED(OF_LIBFDT)
u64 mem_start = virt_to_phys((void *)gd->bd->bi_memstart);
u64 mem_size = gd->ram_size;
return fdt_fixup_memory_banks(blob, &mem_start, &mem_size, 1);
-#else
- return 0;
-#endif
}
+#endif
static int boot_setup_fdt(bootm_headers_t *images)
{
diff --git a/arch/nds32/lib/bootm.c b/arch/nds32/lib/bootm.c
index 42b15dfcbfc0..0d7f57851739 100644
--- a/arch/nds32/lib/bootm.c
+++ b/arch/nds32/lib/bootm.c
@@ -15,12 +15,6 @@
DECLARE_GLOBAL_DATA_PTR;
-int arch_fixup_fdt(void *blob)
-{
- return 0;
-}
-
-
#if defined(CONFIG_SETUP_MEMORY_TAGS) || \
defined(CONFIG_CMDLINE_TAG) || \
defined(CONFIG_INITRD_TAG) || \
diff --git a/arch/powerpc/lib/bootm.c b/arch/powerpc/lib/bootm.c
index b9ae24dc98b6..6ef644d85ba3 100644
--- a/arch/powerpc/lib/bootm.c
+++ b/arch/powerpc/lib/bootm.c
@@ -40,11 +40,6 @@ static void set_clocks_in_mhz (bd_t *kbd);
#define CONFIG_SYS_LINUX_LOWMEM_MAX_SIZE (768*1024*1024)
#endif
-int arch_fixup_fdt(void *blob)
-{
- return 0;
-}
-
static void boot_jump_linux(bootm_headers_t *images)
{
void(*kernel)(bd_t *, ulong r4, ulong r5, ulong r6,
diff --git a/arch/sandbox/lib/bootm.c b/arch/sandbox/lib/bootm.c
index 4cdd18fe14b2..0c9a7979d231 100644
--- a/arch/sandbox/lib/bootm.c
+++ b/arch/sandbox/lib/bootm.c
@@ -50,11 +50,6 @@ int bootz_setup(ulong image, ulong *start, ulong *end)
return ret;
}
-int arch_fixup_fdt(void *blob)
-{
- return 0;
-}
-
int do_bootm_linux(int flag, int argc, char *argv[], bootm_headers_t *images)
{
if (flag & (BOOTM_STATE_OS_GO | BOOTM_STATE_OS_FAKE_GO)) {
diff --git a/arch/x86/lib/bootm.c b/arch/x86/lib/bootm.c
index e548cdbed592..8e76ba35aea5 100644
--- a/arch/x86/lib/bootm.c
+++ b/arch/x86/lib/bootm.c
@@ -28,11 +28,6 @@ DECLARE_GLOBAL_DATA_PTR;
#define COMMAND_LINE_OFFSET 0x9000
-int arch_fixup_fdt(void *blob)
-{
- return 0;
-}
-
__weak void board_quiesce_devices(void)
{
}
diff --git a/common/image-fdt.c b/common/image-fdt.c
index 1e946467e3c7..24e4c7c6c814 100644
--- a/common/image-fdt.c
+++ b/common/image-fdt.c
@@ -454,6 +454,11 @@ __weak int ft_verify_fdt(void *fdt)
return 1;
}
+__weak int arch_fixup_fdt(void *blob)
+{
+ return 0;
+}
+
int image_setup_libfdt(bootm_headers_t *images, void *blob,
int of_size, struct lmb *lmb)
{
--
2.14.3
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] efi_loader: fix comments indent_string()
Provide a better description for indent_string.
Fix a typo.
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_boottime.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index e7714bcbc6..8acd26a93b 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -111,8 +111,11 @@ void efi_restore_gd(void)
}
/*
- * Two spaces per indent level, maxing out at 10.. which ought to be
- * enough for anyone ;-)
+ * Return a string for indenting with two spaces per level. A maximum of ten
+ * indent levels is supported. Higher indent levels will be truncated.
+ *
+ * @level indent level
+ * @return indent string
*/
static const char *indent_string(int level)
{
@@ -1456,7 +1459,7 @@ error:
* for details.
*
* @boot_policytrue for request originating from the boot
manager
- * @parent_image the calles's image handle
+ * @parent_image the caller's image handle
* @file_path the path of the image to load
* @source_buffer memory location from which the image is installed
* @source_sizesize of the memory area from which the image is
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA
it worked! i applied the patches alone and it didn't work, but then i noticed simon's note to add compatible = "spi-flash" so i added it on the arria 5 dts file, and it worked. i think it should be added to the patches. thanks for the help! -- Sent from: http://u-boot.10912.n7.nabble.com/ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] cmd/bdinfo: print relocation info on X86
For debugging U-Boot in qemu-x86 the relocation address is needed.
Signed-off-by: Heinrich Schuchardt
---
Hello Bin, hello Simon,
could this be picked up via the X86 tree?
Best regards
Heinrich
---
cmd/bdinfo.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/cmd/bdinfo.c b/cmd/bdinfo.c
index c7ebad17d1..de6fc48987 100644
--- a/cmd/bdinfo.c
+++ b/cmd/bdinfo.c
@@ -377,6 +377,8 @@ int do_bdinfo(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
print_bi_dram(bd);
+ print_num("relocaddr", gd->relocaddr);
+ print_num("reloc off", gd->reloc_off);
#if defined(CONFIG_CMD_NET)
print_eth_ip_addr();
print_mhz("ethspeed", bd->bi_ethspeed);
--
2.14.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 1/3] drivers/ddr/fsl: Fix DDR4 RDIMM support
For DDR4, command/address delay in mode registers and parity latency
in timing config register are only needed for UDIMMs, but not RDIMMs.
Add additional register rcw_3 for DDR4 RDIMM. Fix mirrored bit for
dual rank RDIMMs. Set sdram_cfg_3[DIS_MRS_PAR] for RDIMMs. Use
hexadecimal format for printing RCW (register control word) registers.
Signed-off-by: York Sun
---
Changes in v3: None
Changes in v2: None
drivers/ddr/fsl/ctrl_regs.c| 32 +---
drivers/ddr/fsl/ddr4_dimm_params.c | 2 ++
drivers/ddr/fsl/interactive.c | 9 +++--
include/fsl_ddr_sdram.h| 1 +
4 files changed, 35 insertions(+), 9 deletions(-)
diff --git a/drivers/ddr/fsl/ctrl_regs.c b/drivers/ddr/fsl/ctrl_regs.c
index c0ee858..4a1f397 100644
--- a/drivers/ddr/fsl/ctrl_regs.c
+++ b/drivers/ddr/fsl/ctrl_regs.c
@@ -732,6 +732,7 @@ static void set_ddr_sdram_rcw(fsl_ddr_cfg_regs_t *ddr,
if (popts->rcw_override) {
ddr->ddr_sdram_rcw_1 = popts->rcw_1;
ddr->ddr_sdram_rcw_2 = popts->rcw_2;
+ ddr->ddr_sdram_rcw_3 = popts->rcw_3;
} else {
ddr->ddr_sdram_rcw_1 =
common_dimm->rcw[0] << 28 | \
@@ -752,8 +753,12 @@ static void set_ddr_sdram_rcw(fsl_ddr_cfg_regs_t *ddr,
common_dimm->rcw[14] << 4 | \
common_dimm->rcw[15];
}
- debug("FSLDDR: ddr_sdram_rcw_1 = 0x%08x\n",
ddr->ddr_sdram_rcw_1);
- debug("FSLDDR: ddr_sdram_rcw_2 = 0x%08x\n",
ddr->ddr_sdram_rcw_2);
+ debug("FSLDDR: ddr_sdram_rcw_1 = 0x%08x\n",
+ ddr->ddr_sdram_rcw_1);
+ debug("FSLDDR: ddr_sdram_rcw_2 = 0x%08x\n",
+ ddr->ddr_sdram_rcw_2);
+ debug("FSLDDR: ddr_sdram_rcw_3 = 0x%08x\n",
+ ddr->ddr_sdram_rcw_3);
}
}
@@ -1159,8 +1164,14 @@ static void set_ddr_sdram_mode_9(fsl_ddr_cfg_regs_t *ddr,
esdmode5 = 0x0400; /* Data mask enabled */
}
- /* set command/address parity latency */
- if (ddr->ddr_sdram_cfg_2 & SDRAM_CFG2_AP_EN) {
+ /*
+* For DDR3, set C/A latency if address parity is enabled.
+* For DDR4, set C/A latency for UDIMM only. For RDIMM the delay is
+* handled by register chip and RCW settings.
+*/
+ if ((ddr->ddr_sdram_cfg_2 & SDRAM_CFG2_AP_EN) &&
+ ((CONFIG_FSL_SDRAM_TYPE != SDRAM_TYPE_DDR4) ||
+!popts->registered_dimm_en)) {
if (mclk_ps >= 935) {
/* for DDR4-1600/1866/2133 */
esdmode5 |= DDR_MR5_CA_PARITY_LAT_4_CLK;
@@ -1193,7 +1204,9 @@ static void set_ddr_sdram_mode_9(fsl_ddr_cfg_regs_t *ddr,
esdmode5 = 0x0400;
}
- if (ddr->ddr_sdram_cfg_2 & SDRAM_CFG2_AP_EN) {
+ if ((ddr->ddr_sdram_cfg_2 & SDRAM_CFG2_AP_EN) &&
+ ((CONFIG_FSL_SDRAM_TYPE != SDRAM_TYPE_DDR4) ||
+!popts->registered_dimm_en)) {
if (mclk_ps >= 935) {
/* for DDR4-1600/1866/2133 */
esdmode5 |= DDR_MR5_CA_PARITY_LAT_4_CLK;
@@ -1965,6 +1978,7 @@ static void set_timing_cfg_6(fsl_ddr_cfg_regs_t *ddr)
static void set_timing_cfg_7(const unsigned int ctrl_num,
fsl_ddr_cfg_regs_t *ddr,
+const memctl_options_t *popts,
const common_timing_params_t *common_dimm)
{
unsigned int txpr, tcksre, tcksrx;
@@ -1975,7 +1989,9 @@ static void set_timing_cfg_7(const unsigned int ctrl_num,
tcksre = max(5U, picos_to_mclk(ctrl_num, 1));
tcksrx = max(5U, picos_to_mclk(ctrl_num, 1));
- if (ddr->ddr_sdram_cfg_2 & SDRAM_CFG2_AP_EN) {
+ if ((ddr->ddr_sdram_cfg_2 & SDRAM_CFG2_AP_EN) &&
+ ((CONFIG_FSL_SDRAM_TYPE != SDRAM_TYPE_DDR4) ||
+!popts->registered_dimm_en)) {
if (mclk_ps >= 935) {
/* parity latency 4 clocks in case of 1600/1866/2133 */
par_lat = 4;
@@ -2130,6 +2146,8 @@ static void set_ddr_sdram_cfg_3(fsl_ddr_cfg_regs_t *ddr,
rd_pre = popts->quad_rank_present ? 1 : 0;
ddr->ddr_sdram_cfg_3 = (rd_pre & 0x1) << 16;
+ /* Disable MRS on parity error for RDIMMs */
+ ddr->ddr_sdram_cfg_3 |= popts->registered_dimm_en ? 1 : 0;
debug("FSLDDR: ddr_sdram_cfg_3 = 0x%08x\n", ddr->ddr_sdram_cfg_3);
}
@@ -2535,7 +2553,7 @@ compute_fsl_memctl_config_regs(const unsigned int
ctrl_num,
#ifdef CONFIG_SYS_FSL_DDR4
set_ddr_sdram_cfg_3(ddr, popts);
set_timing_cfg_6(ddr);
- set_timing_cfg_7(ctrl_num, ddr, common_dimm);
+
[U-Boot] [PATCH v3 2/3] drivers/ddr/fsl: Fix workaround for A009803
Wrong field was masked in this workaround due to wrong endianness. The
impacted SoCs have big-endian.
Signed-off-by: York Sun
---
Changes in v3: None
Changes in v2: None
drivers/ddr/fsl/fsl_ddr_gen4.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/ddr/fsl/fsl_ddr_gen4.c b/drivers/ddr/fsl/fsl_ddr_gen4.c
index b3a27ec..7df9178 100644
--- a/drivers/ddr/fsl/fsl_ddr_gen4.c
+++ b/drivers/ddr/fsl/fsl_ddr_gen4.c
@@ -210,7 +210,7 @@ void fsl_ddr_set_memctl_regs(const fsl_ddr_cfg_regs_t *regs,
if (regs->ddr_sdram_cfg_2 & SDRAM_CFG2_AP_EN) {
if (regs->ddr_sdram_cfg & SDRAM_CFG_RD_EN) { /* for RDIMM */
ddr_out32(&ddr->ddr_sdram_rcw_2,
- regs->ddr_sdram_rcw_2 & ~0x0f00);
+ regs->ddr_sdram_rcw_2 & ~0xf0);
}
ddr_out32(&ddr->err_disable, regs->err_disable |
DDR_ERR_DISABLE_APED);
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 3/3] armv8: ls1046ardb: Add RDIMM support
This adds 2Rx8 RDIMM on LS1046ARDB board. Tested with address
parity enabled and disabled with RDIMM MTA18ASF2G72PDZ.
Signed-off-by: York Sun
---
Changes in v3:
Update register control words for different speeds.
Changes in v2:
Update timing table for lower speeds
board/freescale/ls1046ardb/ddr.c | 27 ---
board/freescale/ls1046ardb/ddr.h | 16
2 files changed, 40 insertions(+), 3 deletions(-)
diff --git a/board/freescale/ls1046ardb/ddr.c b/board/freescale/ls1046ardb/ddr.c
index fb4f6ab..ca48f28 100644
--- a/board/freescale/ls1046ardb/ddr.c
+++ b/board/freescale/ls1046ardb/ddr.c
@@ -29,7 +29,10 @@ void fsl_ddr_board_options(memctl_options_t *popts,
if (!pdimm->n_ranks)
return;
- pbsp = udimms[0];
+ if (popts->registered_dimm_en)
+ pbsp = rdimms[0];
+ else
+ pbsp = udimms[0];
/* Get clk_adjust, wrlvl_start, wrlvl_ctl, according to the board ddr
* freqency and n_banks specified in board_specific_parameters table.
@@ -66,8 +69,6 @@ found:
pbsp->n_ranks, pbsp->datarate_mhz_high, pbsp->rank_gb);
popts->data_bus_width = 0; /* 64-bit data bus */
- popts->otf_burst_chop_en = 0;
- popts->burst_length = DDR_BL8;
popts->bstopre = 0; /* enable auto precharge */
/*
@@ -93,6 +94,26 @@ found:
popts->ddr_cdr2 = DDR_CDR2_ODT(DDR_CDR_ODT_80ohm) |
DDR_CDR2_VREF_TRAIN_EN | DDR_CDR2_VREF_RANGE_2;
+ if (popts->registered_dimm_en) {
+ popts->rcw_1 = 0x000655f0;
+ if (ddr_freq > 3200)
+ popts->rcw_2 = 0xb0700c03;
+ else if (ddr_freq > 2933)
+ popts->rcw_2 = 0xb0600c02;
+ else if (ddr_freq > 2666)
+ popts->rcw_2 = 0xb0500c02;
+ else if (ddr_freq > 2400)
+ popts->rcw_2 = 0xb0400c02;
+ else if (ddr_freq > 2133)
+ popts->rcw_2 = 0xb0300c01;
+ else if (ddr_freq > 1866)
+ popts->rcw_2 = 0xb0100c00;
+ else
+ popts->rcw_2 = 0xbc00;
+
+ popts->rcw_3 = ((ddr_freq - 1260 + 19) / 20) << 8;
+ }
+
/* optimize cpo for erratum A-009942 */
popts->cpo_sample = 0x70;
}
diff --git a/board/freescale/ls1046ardb/ddr.h b/board/freescale/ls1046ardb/ddr.h
index 9e440f6..ffc2ef9 100644
--- a/board/freescale/ls1046ardb/ddr.h
+++ b/board/freescale/ls1046ardb/ddr.h
@@ -41,4 +41,20 @@ static const struct board_specific_parameters *udimms[] = {
udimm0,
};
+static const struct board_specific_parameters rdimm0[] = {
+ /*
+* memory controller 0
+* num| hi| rank| clk| wrlvl | wrlvl | wrlvl
+* ranks| mhz| GB |adjst| start | ctl2| ctl3
+*/
+ {2, 1666, 0, 0x8, 0x15, 0x14131110, 0x12131410,},
+ {2, 1900, 0, 0x8, 0x16, 0x15141311, 0x13141511,},
+ {2, 2300, 0, 0xa, 0x1A, 0x18171513, 0x15161814,},
+ {}
+};
+
+static const struct board_specific_parameters *rdimms[] = {
+ rdimm0,
+};
+
#endif
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v8 01/11] armv8: lsch3: Add serdes and DDR voltage setup
On 01/17/2018 02:42 AM, Rajesh Bhagat wrote: > Adds SERDES voltage and reset SERDES lanes API and makes > enable/disable DDR controller support 0.9V API common. > > Signed-off-by: Ashish Kumar > Signed-off-by: Rajesh Bhagat > --- > Changes in v8: > - Added a NULL entry prctl array > - Added balank line before return This set has been applied to fsl-qoriq master. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] ARM: dts: Freescale: re-license device tree files under GPLv2+/X11
On 01/17/2018 08:14 PM, Pankaj Bansal wrote: > The current GPL only licensing on the device trees makes it very > impractical for other software components licensed under another > license. > > To make it easier to reuse them, re-license the the device trees for > Freescale (now NXP) SoCs and boards under GPLv2+/X11 dual license. > > Same trend is followed in linux. > > Cc: Priyanka Jain > Cc: Mingkai Hu > Cc: York Sun > Signed-off-by: Pankaj Bansal > --- > > Notes: > V2: > - Change license from X11 only to GPL2.0+/X11 dual license. > - Updated the commit message accordingly. > > V1: > - Change the license of freescale (now nxp) dtsi/dts files from GPL2.0+ > to X11. > Applied to fsl-qoriq master. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] crypto/fsl: Fix HW accelerated hash commands
On 01/17/2018 04:02 AM, Breno Lima wrote:
> The hash command function were not flushing the dcache before passing data
> to CAAM/DMA and not invalidating the dcache when getting data back.
>
> Due the data cache incoherency, HW accelerated hash commands used to fail
> with CAAM errors like "Invalid KEY Command".
>
> Check if pbuf and pout buffers are properly aligned to the cache line size
> and flush/invalidate the memory regions to address this issue.
>
> This solution is based in a previous work from Clemens Gruber in
> commit 598e9dccc75d ("crypto/fsl: fix BLOB encapsulation and
> decapsulation")
>
> Reported-by: Anatolij Gustschin
> Signed-off-by: Breno Lima
> ---
Applied to fsl-qoriq master. Thanks.
York
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] fsl: common :qixis: Add ifc and emmc switching via qixis
On 01/16/2018 10:45 PM, Ashish Kumar wrote: > Previously only SD, NAND etc were secondary boot source and had > IFC-NOR as primary booting target. But for SoC like LS1088 > IFC-NOR can be secondary boot source, while QSPI-NOR is primary > booting target, So add options in qixis to switch to other targets > using new commands. > > E.g. > '=> qixis_reset ifc' : switch to ifc > '=> qixis_reset emmc' : switch to emmc > > Signed-off-by: Ashish Kumar > --- Rewrote commit message. Applied to fsl-qoriq master. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] armv8: ls1088: Add ifc, emmc lbmap and rcw_src entry for ls1088
On 01/16/2018 10:45 PM, Ashish Kumar wrote: > Signed-off-by: Ashish Kumar > --- Modified subject and add commit message. Applied to fsl-qoriq master. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] efi_loader: catch misspelled bootefi subcommand
If 'bootefi hello' or 'bootefi selftest' can be executed depends on the
configuration.
If an invalid non-numeric 1st argument is passed to bootefi, e.g.
'bootefi hola', this string is converted to 0 and U-Boot jumps to
this typically invalid address.
With the patch the online help is shown instead.
Signed-off-by: Heinrich Schuchardt
---
cmd/bootefi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 545cfecc12..4233d36b72 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -373,6 +373,9 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
saddr = argv[1];
addr = simple_strtoul(saddr, NULL, 16);
+ /* Check that a numeric value was passed */
+ if (!addr && *saddr != '0')
+ return CMD_RET_USAGE;
if (argc > 2) {
sfdt = argv[2];
--
2.14.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] Fix CAAM for TrustZone enable for warp7
On 24/01/18 17:41, Auer, Lukas wrote: Thanks for adding me to the CC list. I have experienced the same thing regarding the dec0 registers. However, I don't understand why you want to detect secure mode in the kernel driver to skip RNG instantiation instead of instantiating all RNG state handles in the u-boot driver. That's what we are doing though. This set instantiates everything in u-boot and then detects and skips in the kernel if-and-only if 1. Trust zone is detected 2. It looks to the Linux CAAM driver as if u-boot has initialised the h/w For #2 I actually have to variants 1. Which passes a DT parameter which indicates the kernel should skip RNG init 2. A module parameter which indicates the kernel should skip rng init Could we discuss the kernel changes in the kernel thread ? I believe we agree the u-boot side is right ? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/5] Convert CONFIG_NAND_ATMEL et al to Kconfig
This converts the following to Kconfig: CONFIG_NAND_ATMEL CONFIG_NAND_DAVINCI Signed-off-by: Adam Ford --- configs/at91sam9260ek_dataflash_cs0_defconfig | 3 ++- configs/at91sam9260ek_dataflash_cs1_defconfig | 3 ++- configs/at91sam9260ek_nandflash_defconfig | 3 ++- configs/at91sam9261ek_dataflash_cs0_defconfig | 3 ++- configs/at91sam9261ek_dataflash_cs3_defconfig | 3 ++- configs/at91sam9261ek_nandflash_defconfig | 3 ++- configs/at91sam9263ek_dataflash_cs0_defconfig | 3 ++- configs/at91sam9263ek_dataflash_defconfig | 3 ++- configs/at91sam9263ek_nandflash_defconfig | 3 ++- configs/at91sam9263ek_norflash_boot_defconfig | 3 ++- configs/at91sam9263ek_norflash_defconfig | 3 ++- configs/at91sam9g10ek_dataflash_cs0_defconfig | 3 ++- configs/at91sam9g10ek_dataflash_cs3_defconfig | 3 ++- configs/at91sam9g10ek_nandflash_defconfig | 3 ++- configs/at91sam9g20ek_2mmc_defconfig | 3 ++- configs/at91sam9g20ek_2mmc_nandflash_defconfig | 3 ++- configs/at91sam9g20ek_dataflash_cs0_defconfig | 3 ++- configs/at91sam9g20ek_dataflash_cs1_defconfig | 3 ++- configs/at91sam9g20ek_nandflash_defconfig | 3 ++- configs/at91sam9m10g45ek_mmc_defconfig | 3 ++- configs/at91sam9m10g45ek_nandflash_defconfig | 3 ++- configs/at91sam9n12ek_mmc_defconfig| 3 ++- configs/at91sam9n12ek_nandflash_defconfig | 3 ++- configs/at91sam9n12ek_spiflash_defconfig | 3 ++- configs/at91sam9rlek_dataflash_defconfig | 3 ++- configs/at91sam9rlek_mmc_defconfig | 3 ++- configs/at91sam9rlek_nandflash_defconfig | 3 ++- configs/at91sam9x5ek_dataflash_defconfig | 3 ++- configs/at91sam9x5ek_mmc_defconfig | 3 ++- configs/at91sam9x5ek_nandflash_defconfig | 3 ++- configs/at91sam9x5ek_spiflash_defconfig| 3 ++- configs/at91sam9xeek_dataflash_cs0_defconfig | 3 ++- configs/at91sam9xeek_dataflash_cs1_defconfig | 3 ++- configs/at91sam9xeek_nandflash_defconfig | 3 ++- configs/axm_defconfig | 3 ++- configs/corvus_defconfig | 3 ++- configs/ea20_defconfig | 3 ++- configs/ethernut5_defconfig| 3 ++- configs/gurnard_defconfig | 3 ++- configs/ipam390_defconfig | 3 ++- configs/k2e_evm_defconfig | 3 ++- configs/k2e_hs_evm_defconfig | 3 ++- configs/k2g_evm_defconfig | 3 ++- configs/k2g_hs_evm_defconfig | 3 ++- configs/k2hk_evm_defconfig | 3 ++- configs/k2hk_hs_evm_defconfig | 3 ++- configs/k2l_evm_defconfig | 3 ++- configs/meesc_defconfig| 3 ++- configs/omapl138_lcdk_defconfig| 1 + configs/pm9261_defconfig | 3 ++- configs/pm9263_defconfig | 3 ++- configs/pm9g45_defconfig | 3 ++- configs/sama5d2_ptc_ek_mmc_defconfig | 3 ++- configs/sama5d2_ptc_ek_nandflash_defconfig | 3 ++- configs/sama5d36ek_cmp_mmc_defconfig | 3 ++- configs/sama5d36ek_cmp_nandflash_defconfig | 3 ++- configs/sama5d36ek_cmp_spiflash_defconfig | 3 ++- configs/sama5d3_xplained_mmc_defconfig | 3 ++- configs/sama5d3_xplained_nandflash_defconfig | 3 ++- configs/sama5d3xek_mmc_defconfig | 3 ++- configs/sama5d3xek_nandflash_defconfig | 3 ++- configs/sama5d3xek_spiflash_defconfig | 3 ++- configs/sama5d4_xplained_mmc_defconfig | 3 ++- configs/sama5d4_xplained_nandflash_defconfig | 3 ++- configs/sama5d4_xplained_spiflash_defconfig| 3 ++- configs/sama5d4ek_mmc_defconfig| 3 ++- configs/sama5d4ek_nandflash_defconfig | 3 ++- configs/sama5d4ek_spiflash_defconfig | 3 ++- configs/smartweb_defconfig | 3 ++- configs/snapper9260_defconfig | 3 ++- configs/snapper9g20_defconfig | 3 ++- configs/taurus_defconfig | 3 ++- configs/usb_a9263_dataflash_defconfig | 3 ++- configs/wb45n_defconfig| 3 ++- configs/wb50n_defconfig| 3 ++- drivers/mtd/nand/Kconfig | 12 include/configs/at91sam9260ek.h| 1 - include/configs/at91sam9261ek.h| 1 - include/configs/at91sam9263ek.h| 1 - include/configs/at91sam9m10g45ek.h | 1 - include/configs/at91sam9n12ek.h| 1 - include/configs/at91sam9rlek.h | 1 - include/configs/at91sam9x5ek.h | 1 - include/configs/corvus.h | 1 - include/configs/da850evm.h | 1 - include/configs/ea20.h |
[U-Boot] [PATCH] Convert CONFIG_SYS_OMAP24_I2C_SLAVE et al to Kconfig
This converts the following to Kconfig: CONFIG_SYS_OMAP24_I2C_SLAVE CONFIG_SYS_OMAP24_I2C_SPEED Signed-off-by: Adam Ford --- configs/am335x_baltos_defconfig| 1 + configs/cm_t3517_defconfig | 1 + configs/eco5pk_defconfig | 1 + configs/kc1_defconfig | 1 + configs/mt_ventoux_defconfig | 1 + configs/sniper_defconfig | 1 + configs/twister_defconfig | 1 + drivers/i2c/Kconfig| 14 ++ include/configs/am3517_crane.h | 2 -- include/configs/am3517_evm.h | 2 -- include/configs/baltos.h | 2 -- include/configs/bur_am335x_common.h| 2 -- include/configs/cm_t35.h | 2 -- include/configs/cm_t3517.h | 2 -- include/configs/kc1.h | 2 -- include/configs/mcx.h | 2 -- include/configs/nokia_rx51.h | 2 -- include/configs/siemens-am33x-common.h | 2 -- include/configs/sniper.h | 2 -- include/configs/tam3517-common.h | 2 -- include/configs/tao3530.h | 2 -- include/configs/ti_armv7_omap.h| 2 -- include/configs/tricorder.h| 2 -- scripts/config_whitelist.txt | 2 -- 24 files changed, 21 insertions(+), 32 deletions(-) diff --git a/configs/am335x_baltos_defconfig b/configs/am335x_baltos_defconfig index 19ea684..a9d5f68 100644 --- a/configs/am335x_baltos_defconfig +++ b/configs/am335x_baltos_defconfig @@ -48,6 +48,7 @@ CONFIG_MTDIDS_DEFAULT="nand0=omap2-nand.0" CONFIG_MTDPARTS_DEFAULT="mtdparts=omap2-nand.0:128k(SPL),128k(SPL.backup1),128k(SPL.backup2),128k(SPL.backup3),1920k(u-boot),-(UBI)" CONFIG_CMD_UBI=y CONFIG_ISO_PARTITION=y +CONFIG_SYS_OMAP24_I2C_SPEED=1000 CONFIG_MMC_OMAP_HS=y CONFIG_NAND=y CONFIG_SPL_NAND_DRIVERS=y diff --git a/configs/cm_t3517_defconfig b/configs/cm_t3517_defconfig index fa78bde..c1e1153 100644 --- a/configs/cm_t3517_defconfig +++ b/configs/cm_t3517_defconfig @@ -31,6 +31,7 @@ CONFIG_CMD_MTDPARTS=y CONFIG_MTDIDS_DEFAULT="nand0=nand" CONFIG_MTDPARTS_DEFAULT="mtdparts=nand:512k(x-loader),1920k(u-boot),256k(u-boot-env),4m(kernel),-(fs)" CONFIG_ENV_IS_IN_NAND=y +CONFIG_SYS_OMAP24_I2C_SPEED=40 CONFIG_LED_STATUS=y CONFIG_LED_STATUS_GPIO=y CONFIG_LED_STATUS0=y diff --git a/configs/eco5pk_defconfig b/configs/eco5pk_defconfig index dac6aac..d0d82e9 100644 --- a/configs/eco5pk_defconfig +++ b/configs/eco5pk_defconfig @@ -27,6 +27,7 @@ CONFIG_MTDIDS_DEFAULT="nand0=omap2-nand.0" CONFIG_MTDPARTS_DEFAULT="mtdparts=omap2-nand.0:512k(xloader-nand),1024k(uboot-nand),256k(params-nand),5120k(kernel),-(ubifs)" CONFIG_CMD_UBI=y CONFIG_ENV_IS_IN_NAND=y +CONFIG_SYS_OMAP24_I2C_SPEED=40 CONFIG_MMC_OMAP_HS=y CONFIG_NAND=y CONFIG_SYS_NAND_BUSWIDTH_16BIT=y diff --git a/configs/kc1_defconfig b/configs/kc1_defconfig index eaf7112..b501dfe 100644 --- a/configs/kc1_defconfig +++ b/configs/kc1_defconfig @@ -35,6 +35,7 @@ CONFIG_CMD_FAT=y CONFIG_CMD_FS_GENERIC=y CONFIG_ISO_PARTITION=y CONFIG_EFI_PARTITION=y +CONFIG_SYS_OMAP24_I2C_SPEED=40 CONFIG_MMC_OMAP_HS=y CONFIG_SYS_NS16550=y CONFIG_USB=y diff --git a/configs/mt_ventoux_defconfig b/configs/mt_ventoux_defconfig index fc184d7..e5df51d 100644 --- a/configs/mt_ventoux_defconfig +++ b/configs/mt_ventoux_defconfig @@ -32,6 +32,7 @@ CONFIG_MTDIDS_DEFAULT="nand0=omap2-nand.0" CONFIG_MTDPARTS_DEFAULT="mtdparts=omap2-nand.0:512k(MLO),1m(u-boot),256k(env1),256k(env2),8m(ubisystem),-(rootfs)" CONFIG_CMD_UBI=y CONFIG_ENV_IS_IN_NAND=y +CONFIG_SYS_OMAP24_I2C_SPEED=40 CONFIG_MMC_OMAP_HS=y CONFIG_NAND=y CONFIG_SYS_NAND_BUSWIDTH_16BIT=y diff --git a/configs/sniper_defconfig b/configs/sniper_defconfig index 0761698..d06dfd6 100644 --- a/configs/sniper_defconfig +++ b/configs/sniper_defconfig @@ -36,6 +36,7 @@ CONFIG_CMD_FAT=y CONFIG_CMD_FS_GENERIC=y CONFIG_ISO_PARTITION=y CONFIG_EFI_PARTITION=y +CONFIG_SYS_OMAP24_I2C_SPEED=40 CONFIG_MMC_OMAP_HS=y CONFIG_SYS_NS16550=y CONFIG_USB=y diff --git a/configs/twister_defconfig b/configs/twister_defconfig index 34bd769..846e8c9 100644 --- a/configs/twister_defconfig +++ b/configs/twister_defconfig @@ -32,6 +32,7 @@ CONFIG_MTDIDS_DEFAULT="nand0=omap2-nand.0" CONFIG_MTDPARTS_DEFAULT="mtdparts=omap2-nand.0:512k(MLO),1m(u-boot),256k(env1),256k(env2),6m(kernel),-(rootfs)" CONFIG_CMD_UBI=y CONFIG_ENV_IS_IN_NAND=y +CONFIG_SYS_OMAP24_I2C_SPEED=40 CONFIG_MMC_OMAP_HS=y CONFIG_NAND=y CONFIG_SYS_NAND_BUSWIDTH_16BIT=y diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig index 0630712..17d21bb 100644 --- a/drivers/i2c/Kconfig +++ b/drivers/i2c/Kconfig @@ -162,6 +162,20 @@ config SYS_I2C_OMAP24XX help Add support for the OMAP2+ I2C driver. +if SYS_I2C_OMAP24XX +config SYS_OMAP24_I2C_SLAVE + int "I2C Slave addr channel 0" + default 1 + help + OMAP24xx I2C Slave address channel 0 + +config SYS_OMAP24_I2C_SPEED + int "I2C Slave ch
[U-Boot] [PATCH 1/2] ARM: dts: rmobile: Update DTS to match Linux 4.14
Import the RCar Gen3 DTS and headers from upstream Linux kernel v4.14,
commit bebc6082da0a9f5d47a1ea2edc099bf671058bd4 . This includes both M3
and H3 ULCB and Salvator-X boards.
Signed-off-by: Marek Vasut
Cc: Nobuhiro Iwamatsu
---
arch/arm/dts/r8a7795-h3ulcb.dts | 20 +-
arch/arm/dts/r8a7795-salvator-x.dts | 6 +-
arch/arm/dts/r8a7795.dtsi | 318 ++-
arch/arm/dts/r8a7796-m3ulcb.dts | 18 +-
arch/arm/dts/r8a7796-salvator-x.dts | 35 +++-
arch/arm/dts/r8a7796.dtsi | 361 +++-
arch/arm/dts/r8a77970-eagle.dts | 4 +-
arch/arm/dts/r8a77970.dtsi | 4 +-
arch/arm/dts/r8a77995-draak.dts | 4 +-
arch/arm/dts/r8a77995.dtsi | 4 +-
arch/arm/dts/salvator-common.dtsi | 15 +-
arch/arm/dts/ulcb.dtsi | 48 -
12 files changed, 786 insertions(+), 51 deletions(-)
diff --git a/arch/arm/dts/r8a7795-h3ulcb.dts b/arch/arm/dts/r8a7795-h3ulcb.dts
index 0426f41765..0089ea64d6 100644
--- a/arch/arm/dts/r8a7795-h3ulcb.dts
+++ b/arch/arm/dts/r8a7795-h3ulcb.dts
@@ -4,13 +4,9 @@
* Copyright (C) 2016 Renesas Electronics Corp.
* Copyright (C) 2016 Cogent Embedded, Inc.
*
- * This file is licensed under the terms of the GNU General Public License
- * version 2. This program is licensed "as is" without any warranty of any
- * kind, whether express or implied.
+ * SPDX-License-Identifier:GPL-2.0
*/
-#define CPG_AUDIO_CLK_IR8A7795_CLK_S0D4
-
/dts-v1/;
#include "r8a7795.dtsi"
#include "ulcb.dtsi"
@@ -40,3 +36,17 @@
reg = <0x7 0x 0x0 0x4000>;
};
};
+
+&du {
+ clocks = <&cpg CPG_MOD 724>,
+<&cpg CPG_MOD 723>,
+<&cpg CPG_MOD 722>,
+<&cpg CPG_MOD 721>,
+<&cpg CPG_MOD 727>,
+<&versaclock5 1>,
+<&versaclock5 3>,
+<&versaclock5 4>,
+<&versaclock5 2>;
+ clock-names = "du.0", "du.1", "du.2", "du.3", "lvds.0",
+ "dclkin.0", "dclkin.1", "dclkin.2", "dclkin.3";
+};
diff --git a/arch/arm/dts/r8a7795-salvator-x.dts
b/arch/arm/dts/r8a7795-salvator-x.dts
index 684fb3b9d1..63a3a46e5a 100644
--- a/arch/arm/dts/r8a7795-salvator-x.dts
+++ b/arch/arm/dts/r8a7795-salvator-x.dts
@@ -3,13 +3,9 @@
*
* Copyright (C) 2015 Renesas Electronics Corp.
*
- * This file is licensed under the terms of the GNU General Public License
- * version 2. This program is licensed "as is" without any warranty of any
- * kind, whether express or implied.
+ * SPDX-License-Identifier:GPL-2.0
*/
-#define CPG_AUDIO_CLK_IR8A7795_CLK_S0D4
-
/dts-v1/;
#include "r8a7795.dtsi"
#include "salvator-x.dtsi"
diff --git a/arch/arm/dts/r8a7795.dtsi b/arch/arm/dts/r8a7795.dtsi
index 405ae9c781..d9f556755e 100644
--- a/arch/arm/dts/r8a7795.dtsi
+++ b/arch/arm/dts/r8a7795.dtsi
@@ -3,15 +3,15 @@
*
* Copyright (C) 2015 Renesas Electronics Corp.
*
- * This file is licensed under the terms of the GNU General Public License
- * version 2. This program is licensed "as is" without any warranty of any
- * kind, whether express or implied.
+ * SPDX-License-Identifier:GPL-2.0
*/
#include
#include
#include
+#define CPG_AUDIO_CLK_IR8A7795_CLK_S0D4
+
/ {
compatible = "renesas,r8a7795";
#address-cells = <2>;
@@ -696,6 +696,126 @@
};
};
+ drif00: rif@e6f4 {
+ compatible = "renesas,r8a7795-drif",
+"renesas,rcar-gen3-drif";
+ reg = <0 0xe6f4 0 0x64>;
+ interrupts = ;
+ clocks = <&cpg CPG_MOD 515>;
+ clock-names = "fck";
+ dmas = <&dmac1 0x20>, <&dmac2 0x20>;
+ dma-names = "rx", "rx";
+ power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
+ resets = <&cpg 515>;
+ renesas,bonding = <&drif01>;
+ status = "disabled";
+ };
+
+ drif01: rif@e6f5 {
+ compatible = "renesas,r8a7795-drif",
+"renesas,rcar-gen3-drif";
+ reg = <0 0xe6f5 0 0x64>;
+ interrupts = ;
+ clocks = <&cpg CPG_MOD 514>;
+ clock-names = "fck";
+ dmas = <&dmac1 0x22>, <&dmac2 0x22>;
+ dma-names = "rx", "rx";
+ power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
+ resets = <&cpg 514>;
+ renesas,bonding = <&drif00>;
+ status = "disabled";
+ };
+
+ drif10: rif@e6f6 {
+ compatible = "renesas,r8a7795-drif",
+
