Re: [U-Boot] Booting armv8 Kernel on UBoot

[Rajkumar Ramasamy]

Hi, I did a few more debugging and wanted to share few more information which 
are below:

1) I think QEMU does support EL2, because, the following code is working fine.
mov\xreg1, #0x33ff
msrcptr_el2, \xreg1/* Disable coprocessor traps to EL2 */
2) The machine is still in EL3, when its trying to write to SP_EL2. As SP_EL2 
can be written from EL3 or EL2, I think there is no permission violation 
happening due to this.
mrs \xreg, CurrentEL   /* xreg is 0xc after this line*/
mov\xreg1, sp
msr sp_el2, \xreg1/* Migrate SP */

Please correct me if I am wrong.

--- Original Message ---
Sender : Rajkumar Ramasamy Technical 
Lead/SRI-Bangalore-IoTivity/Samsung Electronics
Date : Jul 21, 2016 09:41 (GMT+05:30)
Title : Booting armv8 Kernel on UBoot

Hi, 
I am trying to boot ARMv8 Linux kernel using U-Boot. I have built the latest 
mainline kernel and U-Boot for aarch64 using defconfig. I am testing this build 
on QEMU V2.6.0.  I have loaded the Image file at 0x8008
"loaded file 
/home/shingu/workspace/linux/linux_mainline_aarch64/arch/arm64/boot/Image from 
8008 to 80B175FF, 00A97600 bytes"
Just before transfering the control to the kernel, U-Boot is trying to switch 
the exception level to EL2 from EL3, since I have "-machine secure=on" in QEMU 
parameters. 
As soon as the stack pointer is migrated, (  mov x0, sp; msr sp_el2, x0)  there 
is an exception occurring, [transferring control to 
arch/arm/cpu/armv8/exceptions.S:102]  which is aborting the boot process with 
following message:
"Synchronous Abort" handler, esr 0x0200
ELR: fef7caa4
LR:  fef7d60c
x0 : fe6fa820 x1 : 
x2 : fef94a88 x3 : 0001
x4 : fe6fa4e0 x5 : 0020
x6 : ff80ffc8 x7 : 
x8 : fe6fa6e0 x9 : 0002
x10: fe6fa55b x11: 0002
x12: 0002 x13: 
x14: 83006fff x15: fef7c8e4
x16: fef7cb68 x17: 
x18: fe6fae00 x19: fefb7b40
x20:  x21: 8008
x22: 0003 x23: fe6fe058
x24:  x25: fefb0918
x26:  x27: fef7d6d8
x28: fe6fe080 x29: fef7d5ec
Resetting CPU ...
resetting ...
Can anyone please help me to understand what I am doing wrong?

The total process is in the following code: [ 
http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/cpu/armv8/transition.S#l16, 
http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/include/asm/macro.h#138]

Have a pleasant day! :)
With Thanks and Regards,
Rajkumar R

Have a pleasant day! :)
With Thanks and Regards,
Rajkumar R
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/5] fsl: csu: add an API to set individual device access permission

[Prabhakar Kushwaha]

> -Original Message-
> From: Zhiqiang Hou [mailto:zhiqiang@nxp.com]
> Sent: Monday, July 04, 2016 11:58 AM
> To: u-boot@lists.denx.de; albert.u.b...@aribaud.net; york sun
> ; w...@denx.de; Prabhakar Kushwaha
> ; alison.w...@freescale.com;
> mingkai...@freescale.com
> Cc: yao.y...@freescale.com; qianyu.g...@freescale.com;
> bmeng...@gmail.com; Shengzhou Liu ; Zhiqiang Hou
> 
> Subject: [PATCH 3/5] fsl: csu: add an API to set individual device access
> permission
> 
> From: Hou Zhiqiang 
> 
> Add this API to make the individual device is able to be set to
> the specified permission.
> 

I am curious about requirement of devices to configure CSU in their driver. 
Why cannot it be done during early boot sequence as part of normal boot-flow 
for all devices

--prabhakar 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [Patch v3] armv8: ls1043aqds: add IFC fixup in case QSPI is enabled

[Gong Qianyu]

QSPI and IFC are pin-multiplexed on LS1043AQDS board. If QSPI is
enabled, IFC would not be initialized correctly. So disable the IFC
node for Linux.

Signed-off-by: Gong Qianyu 
---
v3:
 - Moved the fixup to board file.
 - Detected the muxing through QIXIS at runtime.
 - Tested on LS1043AQDS board.

 board/freescale/ls1043aqds/ls1043aqds.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/board/freescale/ls1043aqds/ls1043aqds.c 
b/board/freescale/ls1043aqds/ls1043aqds.c
index b7e9c21..941dfbc 100644
--- a/board/freescale/ls1043aqds/ls1043aqds.c
+++ b/board/freescale/ls1043aqds/ls1043aqds.c
@@ -327,6 +327,7 @@ int ft_board_setup(void *blob, bd_t *bd)
 {
u64 base[CONFIG_NR_DRAM_BANKS];
u64 size[CONFIG_NR_DRAM_BANKS];
+   u8 reg;
 
/* fixup DT for the two DDR banks */
base[0] = gd->bd->bi_dram[0].start;
@@ -341,6 +342,15 @@ int ft_board_setup(void *blob, bd_t *bd)
fdt_fixup_fman_ethernet(blob);
fdt_fixup_board_enet(blob);
 #endif
+
+   reg = QIXIS_READ(brdcfg[0]);
+   reg = (reg & QIXIS_LBMAP_MASK) >> QIXIS_LBMAP_SHIFT;
+
+   /* Disable IFC if QSPI is enabled */
+   if (reg == 0xF)
+   do_fixup_by_compat(blob, "fsl,ifc",
+  "status", "disabled", 8 + 1, 1);
+
return 0;
 }
 #endif
-- 
2.1.0.27.g96db324

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v3] colibri_imx7: add Colibri iMX7S/iMX7D module support

[Stefan Agner]

From: Stefan Agner 

This commit adds support for the Toradex Computer on Modules
Colibri iMX7S/iMX7D. The two modules/SoC's are very similar hence
can be easily supported by one board. The board code detects RAM
size at runtime which is one of the differences between the two
boards. The board also uses the UART's in DTE mode, hence making
use of the new DTE support via serial DM.

Signed-off-by: Stefan Agner 
---
Hi Stefano,

As discussed, only Patch 9/9 from the previous  mx7: add Colibri
iMX7S/iMX7D support series.

Changes since v2:
- Renamed config COLIBRI_IMX7_EXT_PHYCLK and moved to Kconfig

--
Stefan

 arch/arm/cpu/armv7/mx7/Kconfig|   7 +
 board/toradex/colibri_imx7/Kconfig|  20 ++
 board/toradex/colibri_imx7/MAINTAINERS|   6 +
 board/toradex/colibri_imx7/Makefile   |   6 +
 board/toradex/colibri_imx7/colibri_imx7.c | 420 ++
 board/toradex/colibri_imx7/imximage.cfg   | 150 +++
 configs/colibri_imx7_defconfig|  40 +++
 include/configs/colibri_imx7.h| 247 ++
 8 files changed, 896 insertions(+)
 create mode 100644 board/toradex/colibri_imx7/Kconfig
 create mode 100644 board/toradex/colibri_imx7/MAINTAINERS
 create mode 100644 board/toradex/colibri_imx7/Makefile
 create mode 100644 board/toradex/colibri_imx7/colibri_imx7.c
 create mode 100644 board/toradex/colibri_imx7/imximage.cfg
 create mode 100644 configs/colibri_imx7_defconfig
 create mode 100644 include/configs/colibri_imx7.h

diff --git a/arch/arm/cpu/armv7/mx7/Kconfig b/arch/arm/cpu/armv7/mx7/Kconfig
index dd51384..5fdc8dd 100644
--- a/arch/arm/cpu/armv7/mx7/Kconfig
+++ b/arch/arm/cpu/armv7/mx7/Kconfig
@@ -27,12 +27,19 @@ config TARGET_WARP7
select DM
select DM_THERMAL
 
+config TARGET_COLIBRI_IMX7
+   bool "Support Colibri iMX7S/iMX7D modules"
+   select DM
+   select DM_SERIAL
+   select DM_THERMAL
+
 endchoice
 
 config SYS_SOC
default "mx7"
 
 source "board/freescale/mx7dsabresd/Kconfig"
+source "board/toradex/colibri_imx7/Kconfig"
 source "board/warp7/Kconfig"
 
 endif
diff --git a/board/toradex/colibri_imx7/Kconfig 
b/board/toradex/colibri_imx7/Kconfig
new file mode 100644
index 000..7bba26b
--- /dev/null
+++ b/board/toradex/colibri_imx7/Kconfig
@@ -0,0 +1,20 @@
+if TARGET_COLIBRI_IMX7
+
+config SYS_BOARD
+   default "colibri_imx7"
+
+config SYS_VENDOR
+   default "toradex"
+
+config SYS_CONFIG_NAME
+   default "colibri_imx7"
+
+config COLIBRI_IMX7_EXT_PHYCLK
+   bool "External oscillator for Ethernet PHY clock provided"
+   help
+ Select this if your module provides a external Ethernet PHY
+ clock source.
+   default y
+
+
+endif
diff --git a/board/toradex/colibri_imx7/MAINTAINERS 
b/board/toradex/colibri_imx7/MAINTAINERS
new file mode 100644
index 000..5ffb241
--- /dev/null
+++ b/board/toradex/colibri_imx7/MAINTAINERS
@@ -0,0 +1,6 @@
+Colibri iMX7
+M: Stefan Agner 
+S: Maintained
+F: board/toradex/colibri_imx7/
+F: include/configs/colibri_imx7.h
+F: configs/colibri_imx7_defconfig
diff --git a/board/toradex/colibri_imx7/Makefile 
b/board/toradex/colibri_imx7/Makefile
new file mode 100644
index 000..ea597de
--- /dev/null
+++ b/board/toradex/colibri_imx7/Makefile
@@ -0,0 +1,6 @@
+# Copyright (C) 2016 Toradex AG
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y  := colibri_imx7.o
diff --git a/board/toradex/colibri_imx7/colibri_imx7.c 
b/board/toradex/colibri_imx7/colibri_imx7.c
new file mode 100644
index 000..8eedd65
--- /dev/null
+++ b/board/toradex/colibri_imx7/colibri_imx7.c
@@ -0,0 +1,420 @@
+/*
+ * Copyright (C) 2016 Toradex AG
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define UART_PAD_CTRL  (PAD_CTL_DSE_3P3V_49OHM | \
+   PAD_CTL_PUS_PU100KOHM | PAD_CTL_HYS)
+
+#define USDHC_PAD_CTRL (PAD_CTL_DSE_3P3V_32OHM | PAD_CTL_SRE_SLOW | \
+   PAD_CTL_HYS | PAD_CTL_PUE | PAD_CTL_PUS_PU47KOHM)
+
+#define ENET_PAD_CTRL  (PAD_CTL_PUS_PU100KOHM | PAD_CTL_DSE_3P3V_49OHM)
+#define ENET_PAD_CTRL_MII  (PAD_CTL_DSE_3P3V_32OHM)
+
+#define ENET_RX_PAD_CTRL  (PAD_CTL_PUS_PU100KOHM | PAD_CTL_DSE_3P3V_49OHM)
+
+#define I2C_PAD_CTRL(PAD_CTL_DSE_3P3V_32OHM | PAD_CTL_SRE_SLOW | \
+   PAD_CTL_HYS | PAD_CTL_PUE | PAD_CTL_PUS_PU100KOHM)
+
+#define LCD_PAD_CTRL(PAD_CTL_HYS | PAD_CTL_PUS_PU100KOHM | \
+   PAD_CTL_DSE_3P3V_49OHM)
+
+#define NAND_PAD_CTRL (PAD_CTL_DSE_3P3V_49OHM | PAD_CTL_SRE_SLOW | PAD_CTL_HYS)
+
+#define NAND_PAD_READY0_CTRL (PAD_CTL_DSE_3P3V_49OHM | PAD_CTL_PUS_PU5KOHM)
+
+#ifdef CONFIG_SYS_I2C_MXC
+#define PC MUX_PAD_CTRL(I2C_PAD_CTRL)
+/* I2C1 for PMIC */
+static 

Re: [U-Boot] [PATCH v5 0/8] ARMv7: PSCI: add PSCI v1.0 support

[Hongbo Zhang]

Hi York,
I saw sunxi's patches were merged, so I am preparing my patches, will
send it out soon.

On Wed, Jul 20, 2016 at 4:34 AM, york sun  wrote:
> On 07/04/2016 07:26 PM, Hongbo Zhang wrote:
>> On Mon, Jul 4, 2016 at 9:11 PM, Hans de Goede  wrote:
>>> Hi,
>>>
>>> On 04-07-16 09:20, Hongbo Zhang wrote:

 I said I would send a new iteration of this series, but there are code
 dependencies/conflicts with Chenyu's work, so I'd like to wait for a
 few more days to see his v2 sent out or even been merged.
 During this stage, any review comments are still appreciated, I am
 always looking at this.
>>>
>>>
>>> In that case you can probably best base your work on the u-boot-sunxi next
>>> branch, that currently still has v1 of Chen-Yu's patches, but I do not think
>>> things will change that much:
>>>
>>> http://git.denx.de/?p=u-boot/u-boot-sunxi.git;a=shortlog;h=refs/heads/next
>>>
>> OK, I see
>>
>>> Regards,
>>>
>>> Hans
>>>
>>>
>>>
 Thanks.

 On Thu, Jun 30, 2016 at 1:28 PM, Hongbo Zhang 
 wrote:
>
> On Fri, Jun 24, 2016 at 11:26 PM, york sun  wrote:
>>
>> On 06/15/2016 12:16 AM, Chen-Yu Tsai wrote:
>>>
>>> Hi,
>>>
>>> On Tue, Jun 14, 2016 at 3:01 PM,   wrote:

 From: Hongbo Zhang 

 v5 changes:
 - Give up fixing the potential bug of PSCI stack overlap with secure
 text end
 when there is more CPUs in system. Because I just want to keep this
 series as
 simple as it could be: adding basic PSCI v1.0 support and adding more
 PSCI
 v1.0 implements of our platform.
 While too compplicated patches in assembly language won't call for
 effective
 reviews, even I think there is potential bug of PSCI stack, let's fix
 it in
 sepetated patch later.
>>>
>>>
>>> I've done some patches fixing the stack allocation issue:
>>>
>>> https://github.com/wens/u-boot-sunxi/commits/c-psci-part2
>>>
>>> These patches are ready, but I want to add a secure data section still.
>>> The data section will be for variables such as target PC, core/cluster
>>> power status, context ID, etc.. IMHO this is better than putting stuff
>>> at the top or bottom of the stack, and can also be referenced directly.
>>>
>>
>>
>> Chenyu,
>>
>> I see you have been working on PSCI for ARMv7. Can you review Hongbo's
>> patch set and give your comment or ack?
>>
>> York
>>
>>
> Thank Chenyu for valuable review comments, thank you York.
> Will send another version soon.
>>
>
> Hongbo,
>
> Where are we on this thread? Do you have an update?
>
> York
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v7] mmc: atmel_sdhci: Convert to the driver model support

[Jaehoon Chung]

Hi Wenyuo,

On 07/20/2016 07:04 PM, Wenyou Yang wrote:
> Convert the driver to the driver model while retaining the existing
> legacy code. This allows the driver to support boards that have
> converted to driver model as well as those that have not.
> 
> Signed-off-by: Wenyou Yang 
> Reviewed-by: Simon Glass 
> ---
> 
> Changes in v7:
>  - Add support for using driver model for block devices and MMC operations.
>  - Change clk_client.h -> clk.h to adapt to clk API conversion.
> 
> Changes in v6:
>  - Remove unnecessary white space.
>  - Use sdhci_read(), instead of readl().
>  - Remove the local variables min_clk.
> 
> Changes in v5:
>  - Add Reviewed-by tag.
> 
> Changes in v4:
>  - Update the clk API based on [PATCH] clk: convert API to match
>reset/mailbox fstyle (http://patchwork.ozlabs.org/patch/625342/).
>  - Remove check on dev_get_parent() return.
>  - Fixed the return value, such as -ENODEV->-EINVAL.
> 
> Changes in v3:
>  - Remove the redundant log print.
> 
> Changes in v2:
>  - Add clock support, include enabling peripheral clock and
>generated clock.
>  - Retain the existing legacy code to support boards which have not
>converted to driver model.
> 
>  drivers/mmc/Kconfig   |  10 
>  drivers/mmc/atmel_sdhci.c | 125 
> ++
>  include/sdhci.h   |   2 +
>  3 files changed, 137 insertions(+)
> 
> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
> index 79cf18f..49b325e 100644
> --- a/drivers/mmc/Kconfig
> +++ b/drivers/mmc/Kconfig
> @@ -34,6 +34,16 @@ config MSM_SDHCI
>SD 3.0 specifications. Both SD and eMMC devices are supported.
> Card-detect gpios are not supported.
>  
> +config ATMEL_SDHCI
> + bool "Atmel SDHCI controller support"
> + depends on DM_MMC && BLK && DM_MMC_OPS && ARCH_AT91
> + help
> +   This enables support for the Atmel SDHCI controller, which supports
> +   the embedded MultiMedia Card (e.MMC) Specification V4.51, the SD
> +   Memory Card Specification V3.0, and the SDIO V3.0 specification.
> +   It is compliant with the SD Host Controller Standard V3.0
> +   specification.
> +
>  config ROCKCHIP_DWMMC
>   bool "Rockchip SD/MMC controller support"
>   depends on DM_MMC && OF_CONTROL
> diff --git a/drivers/mmc/atmel_sdhci.c b/drivers/mmc/atmel_sdhci.c
> index 24b68b6..977f6ef 100644
> --- a/drivers/mmc/atmel_sdhci.c
> +++ b/drivers/mmc/atmel_sdhci.c
> @@ -6,12 +6,15 @@
>   */
>  
>  #include 
> +#include 
> +#include 

If it doesn't use DM_MMC, then doesn't it need to include dm.h?

>  #include 
>  #include 
>  #include 
>  
>  #define ATMEL_SDHC_MIN_FREQ  40
>  
> +#ifndef CONFIG_DM_MMC
>  int atmel_sdhci_init(void *regbase, u32 id)
>  {
>   struct sdhci_host *host;
> @@ -38,3 +41,125 @@ int atmel_sdhci_init(void *regbase, u32 id)
>  
>   return 0;
>  }
> +
> +#else
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +struct atmel_sdhci_plat {
> + struct mmc_config cfg;
> + struct mmc mmc;
> +};
> +
> +static int atmel_sdhci_probe(struct udevice *dev)
> +{
> + struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
> + struct atmel_sdhci_plat *plat = dev_get_platdata(dev);
> + struct sdhci_host *host = dev_get_priv(dev);
> + u32 max_clk;
> + u32 caps, caps_1;
> + u32 clk_base, clk_mul;
> + u32 gck_rate;
> + struct udevice *dev_clk;
> + struct clk clk;
> + int periph, ret;
> +
> + ret = clk_get_by_index(dev, 0, );
> + if (ret)
> + return ret;
> +
> + periph = fdtdec_get_uint(gd->fdt_blob, clk.dev->of_offset, "reg", -1);
> + if (periph < 0)
> + return -EINVAL;

periph is just used to pass to clk.id. it looks meaningless.
As i already mentioned, you can make more cleaner than now.

> +
> + dev_clk = dev_get_parent(clk.dev);
> + ret = clk_request(dev_clk, );
> + if (ret)
> + return ret;
> +
> + clk.id = periph;
> + ret = clk_enable();
> + if (ret)
> + return ret;
> +
> + host->name = (char *)dev->name;

Needs the type casting?

> + host->ioaddr = (void *)dev_get_addr(dev);
> +
> + host->quirks = 0;
> + host->version = sdhci_readw(host, SDHCI_HOST_VERSION);
> +
> + host->bus_width = fdtdec_get_int(gd->fdt_blob, dev->of_offset,
> +  "bus-width", 4);
> +
> + caps = sdhci_readl(host, SDHCI_CAPABILITIES);
> + clk_base = (caps & SDHCI_CLOCK_V3_BASE_MASK) >> SDHCI_CLOCK_BASE_SHIFT;
> + caps_1 = sdhci_readl(host, SDHCI_CAPABILITIES_1);
> + clk_mul = (caps_1 & SDHCI_CLOCK_MUL_MASK) >> SDHCI_CLOCK_MUL_SHIFT;
> + gck_rate = clk_base * 100 * (clk_mul + 1);

gck_rate can be over u32 boundary, doesn't?

> +
> + ret = clk_get_by_index(dev, 1, );
> + if (ret)
> + return ret;

It can reuse the above clock get sequence.

If reuse this sequence, lines can be reduced.

My suggestion is 

1. 

[U-Boot] Booting armv8 Kernel on UBoot

[Rajkumar Ramasamy]

Hi, 
I am trying to boot ARMv8 Linux kernel using U-Boot. I have built the latest 
mainline kernel and U-Boot for aarch64 using defconfig. I am testing this build 
on QEMU V2.6.0.  I have loaded the Image file at 0x8008
"loaded file 
/home/shingu/workspace/linux/linux_mainline_aarch64/arch/arm64/boot/Image from 
8008 to 80B175FF, 00A97600 bytes"
Just before transfering the control to the kernel, U-Boot is trying to switch 
the exception level to EL2 from EL3, since I have "-machine secure=on" in QEMU 
parameters. 
As soon as the stack pointer is migrated, (  mov x0, sp; msr sp_el2, x0)  there 
is an exception occurring, [transferring control to 
arch/arm/cpu/armv8/exceptions.S:102]  which is aborting the boot process with 
following message:
"Synchronous Abort" handler, esr 0x0200
ELR: fef7caa4
LR:  fef7d60c
x0 : fe6fa820 x1 : 
x2 : fef94a88 x3 : 0001
x4 : fe6fa4e0 x5 : 0020
x6 : ff80ffc8 x7 : 
x8 : fe6fa6e0 x9 : 0002
x10: fe6fa55b x11: 0002
x12: 0002 x13: 
x14: 83006fff x15: fef7c8e4
x16: fef7cb68 x17: 
x18: fe6fae00 x19: fefb7b40
x20:  x21: 8008
x22: 0003 x23: fe6fe058
x24:  x25: fefb0918
x26:  x27: fef7d6d8
x28: fe6fe080 x29: fef7d5ec
Resetting CPU ...
resetting ...
Can anyone please help me to understand what I am doing wrong?
 
The total process is in the following code: [ 
http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/cpu/armv8/transition.S#l16, 
http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/include/asm/macro.h#138]
 
Have a pleasant day! :)
With Thanks and Regards,
Rajkumar R
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A with QSPI enabled

[Qianyu Gong]

Hi York,

> -Original Message-
> From: york sun
> Sent: Thursday, July 21, 2016 5:25 AM
> To: Qianyu Gong ; Scott Wood ; u-
> b...@lists.denx.de
> Cc: Mingkai Hu ; Huan Wang 
> Subject: Re: [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A with QSPI
> enabled
> 
> On 07/19/2016 11:39 PM, Qianyu Gong wrote:
> > Hi York,
> >
> >> -Original Message-
> >> From: york sun
> >> Sent: Wednesday, July 20, 2016 5:58 AM
> >> To: Scott Wood ; Qianyu Gong ;
> >> u- b...@lists.denx.de
> >> Cc: Mingkai Hu 
> >> Subject: Re: [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A
> >> with QSPI enabled
> >>
> >> On 03/30/2016 07:39 PM, Scott Wood wrote:
> >>> On Wed, 2016-03-30 at 06:20 +, Qianyu Gong wrote:
> >>
> >> 
> >>
> 
>  Because this muxing can't be changed at runtime.
>  Two ways so far to configure it:
>  1. SW6[1-4] switches on ls1043aqds board.
>  2. Modify QIXIS board config registers and reset the board.
> >>>
> >>> These sound like runtime to me -- not compile time.
> >>>
> >>
> >> Qianyu,
> >>
> >> If one can change mux by either changing switches, or setting QIXIS
> >> registers, you should be able to read those status and run the fixup, 
> >> agree?
> >>
> >> York
> >
> > Yes, we could read QIXIS registers at runtime. But the current
> > argument is that if we need to build two rcw images to support
> > IFC or QSPI, which is already done on LS1021AQDS and LS1043AQDS. This is
> made at compile time and I just have no idea to solve the rcw issue.
> > So.. how do you think about it?
> >
> 
> Having different SPL builds is not ideal, but that's what we have.
> Without introducing another mechanism, we cannot concatenate SPL with
> different RCW files.
> 
> On the other side, if condition can be detected at run time, please do so, 
> even
> when the condition only applies to one of SPL boot method. We should reduce
> compile option as much as we can so we have less options to test.
> 
> York

OK, thanks. I'll have a try. 
Since the muxing is board-specific, I'd also like to move it to 
ft_board_setup().


Regards,
Qianyu

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] mmc: display mmc list information like mmc_legacy type

[Jaehoon Chung]

Hi Ziyuan,

On 07/19/2016 11:21 PM, Ziyuan Xu wrote:
> From: Xu Ziyuan 
> 
> It's nicer to see this:
> 
> => mmc list
> dwmmc@ff0c: 0
> dwmmc@ff0f: 1 (eMMC)
> 
> than this:
> 
> => mmc list
> dwmmc@ff0c: 0dwmmc@ff0f: 1 (eMMC)
> 
> With the latter, it's much clearer which mmc devices are on.

Right? "With latter"?

> 
> Signed-off-by: Ziyuan Xu 
> 
> Serise-changes: 2
> - Update commit from Jaehoon

Could you add the Changelog to the below line?

> 
> Signed-off-by: Ziyuan Xu 
> ---

Locate the Changelog at here.

Best Regards,
Jaehoon Chung

> 
>  drivers/mmc/mmc-uclass.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mmc/mmc-uclass.c b/drivers/mmc/mmc-uclass.c
> index 38ced41..beebc70 100644
> --- a/drivers/mmc/mmc-uclass.c
> +++ b/drivers/mmc/mmc-uclass.c
> @@ -169,7 +169,7 @@ void print_mmc_devices(char separator)
>  
>   for (uclass_first_device(UCLASS_MMC, );
>dev;
> -  uclass_next_device()) {
> +  uclass_next_device(), first = false) {
>   struct mmc *m = mmc_get_mmc_dev(dev);
>  
>   if (!first) {
> 

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3] mmc-uclass: correct the device number

[Jaehoon Chung]

Hi Kever,

On 07/19/2016 10:28 PM, Kever Yang wrote:
> Not like the mmc-legacy which the devnum starts from 1, it starts from 0
> in mmc-uclass, so the device number should be (devnum + 1) in get_mmc_num().

Looks good to me. I had already sent the similar patch for this.
(http://patchwork.ozlabs.org/patch/643921/)

But I think this patch is better than mine.

> 
> Signed-off-by: Kever Yang 

Reviewed-by: Jaehoon Chung 
Tested-by: Jaehoon Chung 
(On Exynos4 SoCs with eMMC/SD interface.)

Best Regards,
Jaehoon Chung

> ---
> 
> Changes in v3:
> - apply comments from Jaehoon Chung
> 
> Changes in v2:
> - add comment for get_mmc_num() in mmc.h
> - update mmc_get_next_devnum()
> 
>  drivers/mmc/mmc-uclass.c | 4 ++--
>  include/mmc.h| 6 ++
>  2 files changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mmc/mmc-uclass.c b/drivers/mmc/mmc-uclass.c
> index 38ced41..d0ca91b 100644
> --- a/drivers/mmc/mmc-uclass.c
> +++ b/drivers/mmc/mmc-uclass.c
> @@ -111,7 +111,7 @@ struct mmc *find_mmc_device(int dev_num)
>  
>  int get_mmc_num(void)
>  {
> - return max(blk_find_max_devnum(IF_TYPE_MMC), 0);
> + return max((blk_find_max_devnum(IF_TYPE_MMC) + 1), 0);
>  }
>  
>  int mmc_get_next_devnum(void)
> @@ -122,7 +122,7 @@ int mmc_get_next_devnum(void)
>   if (ret < 0)
>   return ret;
>  
> - return ret + 1;
> + return ret;
>  }
>  
>  struct blk_desc *mmc_get_blk_desc(struct mmc *mmc)
> diff --git a/include/mmc.h b/include/mmc.h
> index 8f309f1..dd47f34 100644
> --- a/include/mmc.h
> +++ b/include/mmc.h
> @@ -503,6 +503,12 @@ void mmc_set_clock(struct mmc *mmc, uint clock);
>  struct mmc *find_mmc_device(int dev_num);
>  int mmc_set_dev(int dev_num);
>  void print_mmc_devices(char separator);
> +
> +/**
> + * get_mmc_num() - get the total MMC device number
> + *
> + * @return 0 if there is no MMC device, else the number of devices
> + */
>  int get_mmc_num(void);
>  int mmc_hwpart_config(struct mmc *mmc, const struct mmc_hwpart_conf *conf,
> enum mmc_hwpart_conf_mode mode);
> 

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] rockchip: fix rk3036 SPL build

[Kever Yang]

Hi Heiko,

Simon apply my V4 patch which still have some problem, he said that 
he will rebase
with a new patch set either if I send a new version or send fixes, but 
he won't be available till next week.


I have send out my V5 patch which including the code of this patch.

Thanks,
- Kever
On 07/21/2016 05:41 AM, Heiko Stuebner wrote:

Commit c7db6abf534d ("ARM64: rockchip: add support for rk3399 SoC based evb")
moved the SPL Kconfig selects into the individual soc-specific options.
But it only did it for the rk3288 and not for the rk3036 thus disabling
SPL builds for it. Add the necessary options for the rk3036 as well.

Fixes: c7db6abf534d ("ARM64: rockchip: add support for rk3399 SoC based evb")
Signed-off-by: Heiko Stuebner 
---
  arch/arm/mach-rockchip/Kconfig | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index 2817c0f..c47e16c 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -8,6 +8,8 @@ config ROCKCHIP_RK3036
  including NEON and GPU, Mali-400 graphics, several DDR3 options
  and video codec support. Peripherals include Gigabit Ethernet,
  USB2 host and OTG, SDIO, I2S, UART, SPI, I2C and PWMs.
+   select SUPPORT_SPL
+   select SPL
  
  config ROCKCHIP_RK3188

bool "Support Rockchip RK3188"



___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] efi_loader: Make exposed image loader path absolute

[Alexander Graf]

When loading an efi image, we pass it the location it was loaded from.

On file system backends, there are no relative paths, so we should always
pass in absolute ones. For network paths, we may be relative.

This fixes distro booting with grub2 for me when it fetches the grub2 config
file from the loader partition.

Reported-by: york sun 
Signed-off-by: Alexander Graf 
---
 cmd/bootefi.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 011f62c..d66892e 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -290,6 +290,11 @@ void efi_set_bootdev(const char *dev, const char *devnr, 
const char *path)
 
/* Patch bootefi_image_path to the target file path */
memset(bootefi_image_path[0].str, 0, sizeof(bootefi_image_path[0].str));
-   snprintf(devname, sizeof(devname), "%s", path);
+   if (strcmp(dev, "Net")) {
+   /* Add leading / to fs paths, because they're absolute */
+   snprintf(devname, sizeof(devname), "/%s", path);
+   } else {
+   snprintf(devname, sizeof(devname), "%s", path);
+   }
ascii2unicode(bootefi_image_path[0].str, devname);
 }
-- 
1.8.5.6

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] ARM64: zynqmp: Enable AHCI on EP platform

[Alexander Graf]

The EP platform also has working AHCI emulation, so I see little reason
not to implement the plumbing for it that enables us to boot from AHCI.

Signed-off-by: Alexander Graf 
---
 include/configs/xilinx_zynqmp_ep.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/xilinx_zynqmp_ep.h 
b/include/configs/xilinx_zynqmp_ep.h
index c5bd5da..44434aa 100644
--- a/include/configs/xilinx_zynqmp_ep.h
+++ b/include/configs/xilinx_zynqmp_ep.h
@@ -17,6 +17,7 @@
 #define CONFIG_ZYNQ_SDHCI_MIN_FREQ (CONFIG_ZYNQ_SDHCI_MAX_FREQ << 9)
 #define CONFIG_ZYNQ_EEPROM
 #define CONFIG_AHCI
+#define CONFIG_SATA_CEVA
 #define CONFIG_ZYNQMP_XHCI_LIST {ZYNQMP_USB0_XHCI_BASEADDR, \
 ZYNQMP_USB1_XHCI_BASEADDR}
 
-- 
1.8.5.6

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] iso: Fix part info command

[Alexander Graf]

Partitions on the iso el torito partition table interpreter
only start from partition 1. So when printing out the tables,
let's also start counting at 1.

Signed-off-by: Alexander Graf 
---
 disk/part_iso.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/disk/part_iso.c b/disk/part_iso.c
index 9f5c50c..f9a741d 100644
--- a/disk/part_iso.c
+++ b/disk/part_iso.c
@@ -233,13 +233,13 @@ static void part_print_iso(struct blk_desc *dev_desc)
disk_partition_t info;
int i;
 
-   if (part_get_info_iso_verb(dev_desc, 0, , 0) == -1) {
+   if (part_get_info_iso_verb(dev_desc, 1, , 0) == -1) {
printf("** No boot partition found on device %d **\n",
   dev_desc->devnum);
return;
}
printf("Part   Start Sect x Size Type\n");
-   i=0;
+   i=1;
do {
printf(" %2d " LBAFU " " LBAFU " %6ld %.32s\n",
   i, info.start, info.size, info.blksz, info.type);
-- 
1.8.5.6

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2 00/22] DM: Cmd: GPIO/LED/STM32/CLK: provide command-line support for device-tree configured gpios and leds

[Vikas MANOCHA]

Hi Benjamin,

Please let us know if you are working on this patchset.
I just saw another patchset but not using device tree & clock framework but 
would like to have DT and clock framework in place for stm32.

Cheers,
Vikas

> -Original Message-
> From: Vikas MANOCHA
> Sent: Friday, July 01, 2016 4:35 PM
> To: 'Benjamin Tietz' ; u-
> b...@lists.denx.de
> Subject: RE: [U-Boot] [PATCH 2 00/22] DM: Cmd: GPIO/LED/STM32/CLK:
> provide command-line support for device-tree configured gpios and leds
> 
> Hi Benjamin,
> 
> Please keep all the involved developers in the "To" of the e-mail & resend
> the patchset for review comments (checkout scripts/get_maintainer.pl).
> Also separate the generic stuff (dts/led) from platform specific in another
> patchset.
> 
> Cheers,
> Vikas
> 
> > -Original Message-
> > From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of
> > Benjamin Tietz
> > Sent: Monday, June 20, 2016 11:26 AM
> > To: u-boot@lists.denx.de
> > Subject: [U-Boot] [PATCH 2 00/22] DM: Cmd: GPIO/LED/STM32/CLK:
> provide
> > command-line support for device-tree configured gpios and leds
> >
> > This series begins to provide device-tree support on stm32 devices,
> > starting with a the stack of a simple clock-driver (at least
> > enabling/disabling peripheral clocks), the gpio driver and leds.
> >
> > As the current led command-line interface isn't aware of any
> > device-tree configured led, the command gets rewritten and extended
> > for device-tree LEDs on the way. These changes are architecture
> indipendent.
> >
> > To accomplish these changes the led-uclass driver had to be extended, too.
> >
> > Changes in v2:
> > * more verbose commit messages
> > * correct clock calculation in stm32_clk
> > * minor adjustments
> >
> >
> > ---
> >
> > Benjamin Tietz (22):
> >   stm32: gpio: fix otype access
> >   stm32: gpio_direction_output: make sure, output is set to push-pull
> >   stm32: gpio_get_value: always return 0 or 1
> >   stm32f429-discovery: config: enable status leds
> >   Cmd: led: provide a selector in kconfig
> >   DTS: stm32f429: provide device-tree files (from linux kernel)
> >   clock-uclass: allow disabling a peripheral clock
> >   STM32: clock: provide dts-accessible clock driver
> >   DTS: STM32f429: add gpio-banks
> >   STM32: gpio: group SOC-specific code to one ifdef/elif construct
> >   GPIO: STM32: make DTS-aware
> >   STM32F429-discovery: led: disable board-specific code, if DM is
> selected
> >   GPIO/LED: make more robust, if STATUS_LED isn't selected
> >   Cmd: LED: rewrite to prepare non-static access
> >   DTS: STM32F429-disco: add board leds and enable rcc
> >   LED: add function to retrieve a device's label
> >   LED: provide function to count and get all (DM-)LEDs
> >   cmd: LED: be aware of DTS-configured leds
> >   LED: provide functionality to get led status
> >   LED: GPIO: provide get_on() op
> >   LED: provide toggling interface
> >   Cmd: LED: make DM-leds toggle
> >
> >
> >  arch/arm/dts/Makefile |2
> >  arch/arm/dts/armv7-m.dtsi |   24 ++
> >  arch/arm/dts/stm32429i-eval.dts   |   75 ++
> >  arch/arm/dts/stm32f429-disco.dts  |   97 
> >  arch/arm/dts/stm32f429.dtsi   |  282 +++
> >  board/st/stm32f429-discovery/Makefile |3
> >  cmd/Kconfig   |4
> >  cmd/led.c |  401 
> > -
> >  drivers/clk/Kconfig   |4
> >  drivers/clk/Makefile  |1
> >  drivers/clk/clk-uclass.c  |   10 +
> >  drivers/clk/clk_stm32.c   |  112 +
> >  drivers/gpio/stm32_gpio.c |  202 ++---
> >  drivers/led/led-uclass.c  |   83 +++
> >  drivers/led/led_gpio.c|   11 +
> >  drivers/misc/gpio_led.c   |4
> >  drivers/misc/status_led.c |2
> >  include/clk.h |   18 +
> >  include/configs/stm32f429-discovery.h |   14 +
> >  include/led.h |   65 +
> >  include/status_led.h  |4
> >  21 files changed, 1277 insertions(+), 141 deletions(-)  create mode
> > 100644 arch/arm/dts/armv7-m.dtsi  create mode 100644
> > arch/arm/dts/stm32429i- eval.dts  create mode 100644
> > arch/arm/dts/stm32f429-disco.dts  create mode 100644
> > arch/arm/dts/stm32f429.dtsi  create mode 100644
> > drivers/clk/clk_stm32.c
> >
> > --
> >
> > best regards
> > Benjamin Tietz
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] fatwrite issue in sub-directories

[Nicolas le bayon]

Hi Benoît,


2016-07-20 21:42 GMT+02:00 Benoît Thébaudeau <
benoit.thebaudeau@gmail.com>:

> Hi Nicolas,
>
> On Wed, Jul 20, 2016 at 6:21 PM, Nicolas le bayon 
> wrote:
> > Hi all,
> >
> > With a quite old u-boot release (October 2015 more or less), I has some
> > different issues around fatwrite operations. I realigned a few things
> > around FAT with latest release, and now I observe only one issue. Maybe
> > this has been discussed here before, I searched but no success.
> >
> > I'd like to save a file on an external device (sd card or usb stick), but
> > not on the root, in a sub-directory. I made the implementation with EXT4
> > and it works fine. But no way (for the moment) with FAT.
> >
> > Here is the behaviour, let's imagine the device contains only a "mydir"
> > directory.
> >> fatls 
> > mydir/
> >> fatwrite   myfile.txt 
> >> fatls 
> > mydir/
> > myfile.txt
> >> fatwrite   mydir/myfile2.txt 
> >> fatls 
> >  mydir/
> >  myfile.txt
> >  mydir/myfile2.txt
> > In fact, data is stored in a file strangely named with a '/' character.
> >
> > And when I put the device back on my Linux PC, I can see myfile.txt,
> > nothing special in mydir directory, and no "mydir/myfile2.txt" file.
> >
> > Does someone have already observed this?
>
> Yes. The issue is that do_fat_write() only supports filenames, and not
> full paths, so whatever you give it ends up as a filename in the root
> directory. There is no workaround.
>
> Best regards,
> Benoît
>

OK, so I'm gonna re-construct my implementation in order to place
systematically this file in the root of my device, and this shoud
workaround the issue. Good to learn that it's a known issue.
Thanks a lot for your feedback!
Best Regards
Nicolas
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A with QSPI enabled

[york sun]

On 07/19/2016 11:39 PM, Qianyu Gong wrote:
> Hi York,
>
>> -Original Message-
>> From: york sun
>> Sent: Wednesday, July 20, 2016 5:58 AM
>> To: Scott Wood ; Qianyu Gong ; u-
>> b...@lists.denx.de
>> Cc: Mingkai Hu 
>> Subject: Re: [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A with 
>> QSPI
>> enabled
>>
>> On 03/30/2016 07:39 PM, Scott Wood wrote:
>>> On Wed, 2016-03-30 at 06:20 +, Qianyu Gong wrote:
>>
>> 
>>

 Because this muxing can't be changed at runtime.
 Two ways so far to configure it:
 1. SW6[1-4] switches on ls1043aqds board.
 2. Modify QIXIS board config registers and reset the board.
>>>
>>> These sound like runtime to me -- not compile time.
>>>
>>
>> Qianyu,
>>
>> If one can change mux by either changing switches, or setting QIXIS 
>> registers, you
>> should be able to read those status and run the fixup, agree?
>>
>> York
>
> Yes, we could read QIXIS registers at runtime. But the current argument is 
> that if we need to
> build two rcw images to support IFC or QSPI, which is already done on 
> LS1021AQDS
> and LS1043AQDS. This is made at compile time and I just have no idea to solve 
> the rcw issue.
> So.. how do you think about it?
>

Having different SPL builds is not ideal, but that's what we have. 
Without introducing another mechanism, we cannot concatenate SPL with 
different RCW files.

On the other side, if condition can be detected at run time, please do 
so, even when the condition only applies to one of SPL boot method. We 
should reduce compile option as much as we can so we have less options 
to test.

York

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, 3/3] stm32: Change USART port to USART6 for stm32f746 discovery board

[Vikas MANOCHA]

Hi Tom,

> -Original Message-
> From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Tom Rini
> Sent: Saturday, July 16, 2016 6:51 AM
> To: tnishinaga@gmail.com
> Cc: u-boot@lists.denx.de; gre...@linuxfoundation.org
> Subject: Re: [U-Boot] [U-Boot, 3/3] stm32: Change USART port to USART6 for
> stm32f746 discovery board
> 
> On Fri, Jul 08, 2016 at 01:02:26AM +0900, tnishinaga@gmail.com wrote:
> 
> > From: Toshifumi NISHINAGA 
> >
> > This change is to remove a halt at about 200KiB while sending a
> > large(1MiB) binary to a micro controller using USART1.
> > USART1 is connected to a PC via an on-board ST-Link debugger that also
> > functions as a USB-Serial converter.
> > However, it seems to loss some data occasionally.
> > So I changed the serial port to USART6 and connected it to the PC
> > using an FTDI USB-Serial cable, therefore the transmission was
> > successfully completed.
> >
> > Signed-off-by: Toshifumi NISHINAGA 
> 
> Applied to u-boot/master, thanks!

There is no serial/usb connector on discovery board to use USART6 signals.
With this patch, it is not possible to get discovery console without additional 
circuit. Please revert this patch.
Also I did a quick check on transferring 2.6MB binary using usart1 without any 
issue.

Hi Toshifumi,
Please keep all involved developers in the "To" of the patch e-mails (checkout 
scripts/get_maintainer.pl).

Cheers,
Vikas

> 
> --
> Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] rockchip: fix rk3036 SPL build

[Heiko Stuebner]

Commit c7db6abf534d ("ARM64: rockchip: add support for rk3399 SoC based evb")
moved the SPL Kconfig selects into the individual soc-specific options.
But it only did it for the rk3288 and not for the rk3036 thus disabling
SPL builds for it. Add the necessary options for the rk3036 as well.

Fixes: c7db6abf534d ("ARM64: rockchip: add support for rk3399 SoC based evb")
Signed-off-by: Heiko Stuebner 
---
 arch/arm/mach-rockchip/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index 2817c0f..c47e16c 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -8,6 +8,8 @@ config ROCKCHIP_RK3036
  including NEON and GPU, Mali-400 graphics, several DDR3 options
  and video codec support. Peripherals include Gigabit Ethernet,
  USB2 host and OTG, SDIO, I2S, UART, SPI, I2C and PWMs.
+   select SUPPORT_SPL
+   select SPL
 
 config ROCKCHIP_RK3188
bool "Support Rockchip RK3188"
-- 
2.8.0.rc3

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/5] fsl: serdes: ensure accessing the initialized maps of serdes protocol

[york sun]

On 07/20/2016 02:38 AM, Zhiqiang Hou wrote:
> Hi York,
>
> Thanks for your comments!
>
>> -Original Message-
>> From: york sun
>> Sent: 2016年7月19日 23:46
>> To: Zhiqiang Hou ; u-boot@lists.denx.de;
>> albert.u.b...@aribaud.net; w...@denx.de; Prabhakar Kushwaha
>> ; alison.w...@freescale.com;
>> mingkai...@freescale.com
>> Cc: yao.y...@freescale.com; qianyu.g...@freescale.com;
>> bmeng...@gmail.com; Shengzhou Liu 
>> Subject: Re: [PATCH 1/5] fsl: serdes: ensure accessing the initialized maps 
>> of serdes
>> protocol
>>
>> On 07/03/2016 11:39 PM, Zhiqiang Hou wrote:
>>> From: Hou Zhiqiang 
>>>
>>> Up to now, the function is_serdes_configed() doesn't check if the map
>>> of serdes protocol is initialized before accessing it. The function
>>> is_serdes_configed() will get wrong result when it was called before
>>> the serdes protocol maps initialized. As the first eliment of the map
>>
>> s/eliment/element
>
> Will fix my spelling mistakes next version, thanks a lot!
>
>>> isn't used for any device, so use it as the flag to indicate if the
>>> map has been initialized.
>>
>> I am not sure it is safe to presume the first element is always not used. 
>> Take
>> LS2080A as an example, the serdes map array is initialized by serdes_init(), 
>> which
>> calls serdes_get_prtcl() to get the index of the array. With normal 
>> condition, the
>> index shouldn't be zero. Zero is used as an error but it is not checked 
>> before setting
>>
>> serdes_prtcl_map[lane_prtcl] = 1;
>>
>
> The first element of enum srds_prtcl 'NONE' is aim to describe a lane isn't 
> assigned to
> any device, and the array serdesn_prtcl_map is used to check if the specified 
> device
> selected by the current serdes protocol, right? Nobody will check if the 
> device 'NONE'
> has been configured, right? So it can be used to indicate if the 
> serdes_prtcl_map has
> been initialized.
> Don't care whether the function serdes_get_prtcl() will return zero, just 
> focus if the
> serdes protocol map has been filled. For example, if the serdes protocol 
> value read from
> RCW doesn't match with any entry of the serdes_cfg_tbl, then all lane will be 
> assigned to
> 'NONE'. It still means the serdes protocol map has been filled, even if there 
> is only the
> serdesn_prtcl_map[NONE] was set to 1.
>
>> If you presumption is correct, and you want to use the first one as a flag, 
>> you
>> probably need to check all of them to make sure errors are handled correctly,
>> instead of setting the flag unexpected. Also it is important to document 
>> this idea
>> so future platform code follows the same.
>>
>
> Is it necessary to add it to a document, if add a comment to the 
> serdesn_prtcl_map make it?
>

If you don't want to add a document, please at least put some comments, 
in case we need to change some code in the future.

York

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] armv8/ls1043a: Add MTD partition scheme

[york sun]

On 07/19/2016 08:02 PM, Wenbin Song wrote:
> Hi: York
>
> I'm sorry to have misunderstood you mean.
> I think it is a good idea that modify/remove the wrong/useless variables  in 
> a new patch.
> And I will make it later.
> Do you have any suggestion?

Yes, please make a cleanup patch first, then your change of MTD partition.

York

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arch-mx6: fix MX6_PAD_DECLARE macro to work with MX6 duallite

[Hannes Schmelzer]

On 07/20/2016 09:30 AM, Stefano Babic wrote:

Hi Hannes,

Hi Stefano,

this patch breaks most i.MX6 boards (the not DL) and I revert it. Maybe
I had to ask better before, anyway:

sorry for inconvenience, i should have done more testing on this.
I just tried to compile several i.mx6 boards and found out that I did 
not covered the MX6S which are in trouble now.

On 22/06/2016 12:07, Hannes Schmelzer wrote:

if we build for an i.mx6 (d)ual(l)ite CONFIC_MX6DL we shall use
MX6DL_PAD instead the common MX6_PAD.

Signed-off-by: Hannes Schmelzer
---

  arch/arm/include/asm/arch-mx6/mx6-pins.h | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/arch-mx6/mx6-pins.h 
b/arch/arm/include/asm/arch-mx6/mx6-pins.h
index 4b6bb18..3465205 100644
--- a/arch/arm/include/asm/arch-mx6/mx6-pins.h
+++ b/arch/arm/include/asm/arch-mx6/mx6-pins.h
@@ -18,7 +18,7 @@ enum {
  #include "mx6q_pins.h"
  #undef MX6_PAD_DECL
  #define MX6_PAD_DECL(name, pco, mc, mm, sio, si, pc) \
-   MX6_PAD_DECLARE(MX6DL_PAD_,name, pco, mc, mm, sio, si, pc),
+   MX6_PAD_DECLARE(MX6DL_PAD_, name, pco, mc, mm, sio, si, pc),
  #include "mx6dl_pins.h"
  };
  #elif defined(CONFIG_MX6Q)
@@ -30,7 +30,7 @@ enum {
  #elif defined(CONFIG_MX6DL) || defined(CONFIG_MX6S)
  enum {
  #define MX6_PAD_DECL(name, pco, mc, mm, sio, si, pc) \
-   MX6_PAD_DECLARE(MX6_PAD_,name, pco, mc, mm, sio, si, pc),
+   MX6_PAD_DECLARE(MX6DL_PAD_, name, pco, mc, mm, sio, si, pc),
  #include "mx6dl_pins.h"
  };

Can you better explain the problem you had ? The name is not decisive -
the important thing is that the correct include file with the right
layout is included, that means mx6dl_pins.h. And this was mainlined
since a lot of time.
Maybe all the time nobody had to use I2C #4 on an i.mx6 duallite chip, 
doing so i encountered this problem.


The name is decisive for sure, have a closer look to the 
"MX6_PAD_DECLARE" macro,
In conjunction with the correct include file the prefix used to form the 
final register table declaration.


Next the iomux-v3.h is from interest,
the "#define IOMUX_PADS" has dependency on CONFIG_MX6nn, here the 
previous definition out from mx6-pins.h is used.


I will send some V2 to address this topic fully, ok?

We have several boards with 6DL into mainline, so I am missing which is
your problem.

Best regards,
Stefano Babic

cheers,
Hannes
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Revert "imx_common: Return MMCSD_MODE_FS in spl_boot_mode() also for EXTFS"

[Fabio Estevam]

On Wed, Jul 20, 2016 at 4:55 PM, Breno Lima  wrote:
> Commit c1ebf54868359005 ("imx_common: Return MMCSD_MODE_FS in spl_boot_mode()
> also for EXTFS") causes SPL breakage on wandboard:
>
> ERROR: v7_dcache_inval_range - start address is not aligned - 0x1820006c
> ERROR: v7_dcache_inval_range - stop address is not aligned - 0x1820086c
> ERROR: v7_dcache_inval_range - start address is not aligned - 0x1820006c
> ERROR: v7_dcache_inval_range - stop address is not aligned - 0x1820086c
> ** First descriptor is NOT a primary desc on 0:1 **
> spl: no partition table found
> SPL: failed to boot from all boot devices
> ### ERROR ### Please RESET the board ###
>
> This error is seen when SPL and u-boot.img are stored in the raw SD card
> partition.
>
> This reverts commit c1ebf54868359005c32944c1473668d5fcaca158.
>
> Signed-off-by: Breno Lima 

Thanks for the fix:

Reviewed-by: Fabio Estevam 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] serial_mxc: Remove unconditional DCE setting

[Fabio Estevam]

On Wed, Jul 20, 2016 at 4:34 PM, Breno Lima  wrote:
> Commit 83fd908f28c ("dm: imx: serial: Support DTE mode when using driver
> model") breaks the serial output for the imx boards that do not use
> the serial driver model.
>
> The reason for the breakage is that it's setting UFCR_DCEDTE
> unconditionally for the non-dm case.
>
> So keep the original behavior by removing UFCR_DCEDTE setting in the
> non-dm case.
>
> Tested on mx7sabresd and mx6wandboard.
>
> Signed-off-by: Breno Lima 

Thanks for the fix:

Reviewed-by: Fabio Estevam 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] serial_mxc: Remove unconditional DCE setting

[Breno Lima]

Commit 83fd908f28c ("dm: imx: serial: Support DTE mode when using driver
model") breaks the serial output for the imx boards that do not use
the serial driver model.

The reason for the breakage is that it's setting UFCR_DCEDTE
unconditionally for the non-dm case.

So keep the original behavior by removing UFCR_DCEDTE setting in the
non-dm case.

Tested on mx7sabresd and mx6wandboard.

Signed-off-by: Breno Lima 
---
 drivers/serial/serial_mxc.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/serial/serial_mxc.c b/drivers/serial/serial_mxc.c
index 1960bbc..8545714 100644
--- a/drivers/serial/serial_mxc.c
+++ b/drivers/serial/serial_mxc.c
@@ -151,7 +151,6 @@ static void mxc_serial_setbrg(void)
__REG(UART_PHYS + UFCR) = (RFDIV << UFCR_RFDIV_SHF)
| (TXTL << UFCR_TXTL_SHF)
| (RXTL << UFCR_RXTL_SHF);
-   __REG(UART_PHYS + UFCR) |= UFCR_DCEDTE;
__REG(UART_PHYS + UBIR) = 0xf;
__REG(UART_PHYS + UBMR) = clk / (2 * gd->baudrate);
 
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] Revert "imx_common: Return MMCSD_MODE_FS in spl_boot_mode() also for EXTFS"

[Breno Lima]

Commit c1ebf54868359005 ("imx_common: Return MMCSD_MODE_FS in spl_boot_mode()
also for EXTFS") causes SPL breakage on wandboard:

ERROR: v7_dcache_inval_range - start address is not aligned - 0x1820006c
ERROR: v7_dcache_inval_range - stop address is not aligned - 0x1820086c
ERROR: v7_dcache_inval_range - start address is not aligned - 0x1820006c
ERROR: v7_dcache_inval_range - stop address is not aligned - 0x1820086c
** First descriptor is NOT a primary desc on 0:1 **
spl: no partition table found
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

This error is seen when SPL and u-boot.img are stored in the raw SD card
partition.

This reverts commit c1ebf54868359005c32944c1473668d5fcaca158.

Signed-off-by: Breno Lima 
---
 arch/arm/imx-common/spl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/imx-common/spl.c b/arch/arm/imx-common/spl.c
index 0c1e401..bdcda7d 100644
--- a/arch/arm/imx-common/spl.c
+++ b/arch/arm/imx-common/spl.c
@@ -76,7 +76,7 @@ u32 spl_boot_mode(const u32 boot_device)
/* for MMC return either RAW or FAT mode */
case BOOT_DEVICE_MMC1:
case BOOT_DEVICE_MMC2:
-#if defined(CONFIG_SPL_FAT_SUPPORT) || defined(CONFIG_SPL_EXT_SUPPORT)
+#if defined(CONFIG_SPL_FAT_SUPPORT)
return MMCSD_MODE_FS;
 #elif defined(CONFIG_SUPPORT_EMMC_BOOT)
return MMCSD_MODE_EMMCBOOT;
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] fatwrite issue in sub-directories

[Benoît Thébaudeau]

Hi Nicolas,

On Wed, Jul 20, 2016 at 6:21 PM, Nicolas le bayon  wrote:
> Hi all,
>
> With a quite old u-boot release (October 2015 more or less), I has some
> different issues around fatwrite operations. I realigned a few things
> around FAT with latest release, and now I observe only one issue. Maybe
> this has been discussed here before, I searched but no success.
>
> I'd like to save a file on an external device (sd card or usb stick), but
> not on the root, in a sub-directory. I made the implementation with EXT4
> and it works fine. But no way (for the moment) with FAT.
>
> Here is the behaviour, let's imagine the device contains only a "mydir"
> directory.
>> fatls 
> mydir/
>> fatwrite   myfile.txt 
>> fatls 
> mydir/
> myfile.txt
>> fatwrite   mydir/myfile2.txt 
>> fatls 
>  mydir/
>  myfile.txt
>  mydir/myfile2.txt
> In fact, data is stored in a file strangely named with a '/' character.
>
> And when I put the device back on my Linux PC, I can see myfile.txt,
> nothing special in mydir directory, and no "mydir/myfile2.txt" file.
>
> Does someone have already observed this?

Yes. The issue is that do_fat_write() only supports filenames, and not
full paths, so whatever you give it ends up as a filename in the root
directory. There is no workaround.

Best regards,
Benoît
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] rockchip: fix rk3036 Kconfig inclusion

[Heiko Stuebner]

Commit c7db6abf534d ("ARM64: rockchip: add support for rk3399 SoC based evb")
accidentially removed the include of the rk3036 Kconfig from
arch/arm/mach-rockchip/Kconfig. Readd it to let the rk3036 boards
compile again.

Fixes: c7db6abf534d ("ARM64: rockchip: add support for rk3399 SoC based evb")
Signed-off-by: Heiko Stuebner 
---
 arch/arm/mach-rockchip/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index acde487..d8723bb 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -40,6 +40,7 @@ config ROCKCHIP_RK3399
  USB2 host and OTG, SDIO, I2S, UARTs, SPI, I2C and PWMs.
select ARM64
 
+source "arch/arm/mach-rockchip/rk3036/Kconfig"
 source "arch/arm/mach-rockchip/rk3288/Kconfig"
 source "arch/arm/mach-rockchip/rk3399/Kconfig"
 endif
-- 
2.8.0.rc3

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Pull request: u-boot-sh master

[Nobuhiro Iwamatsu]

Hi Tom,

Please pull u-boot-sh master branch.

The following changes since commit 59d07ee08e858bf2c121d0cdc6c8ddd3b26ee5b1:

  SPL: tiny-printf: avoid any BSS usage (2016-07-08 12:50:34 -0400)

are available in the git repository at:

  git://git.denx.de/u-boot-sh.git master

for you to fetch changes up to 747431b9d54d3ebdef87352006218ed948011612:

  serial_sh: Add standrad SCI (w/o FIFO) support (2016-07-09 05:51:57 +0900)


Yoshinori Sato (2):
  serial_sh: Device Tree support
  serial_sh: Add standrad SCI (w/o FIFO) support

 doc/device-tree-bindings/serial/sh.txt |  6 ++
 drivers/serial/serial_sh.c | 31 +++
 2 files changed, 37 insertions(+)
 create mode 100644 doc/device-tree-bindings/serial/sh.txt


-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Pull request: u-boot-sh/rmobile

[Nobuhiro Iwamatsu]

Hi Tom,

Please pull u-boot-sh rmobile branch.

The following changes since commit 59d07ee08e858bf2c121d0cdc6c8ddd3b26ee5b1:

  SPL: tiny-printf: avoid any BSS usage (2016-07-08 12:50:34 -0400)

are available in the git repository at:

  git://git.denx.de/u-boot-sh.git rmobile

for you to fetch changes up to 997660af470f68e9d3fa7c06271d35b40bbe3833:

  arm: rmobile: Update defconfig (2016-07-09 05:50:53 +0900)


Hiroyuki Yokoyama (1):
  serial: sh: Add support R8A7795

Nobuhiro Iwamatsu (11):
  ARM: rmobile: Move SoC sources to mach-rmobile
  ARM: rmobile: Move SoC headers to mach-rmobile/include/mach
  ARM: Rmobile: Rename CONFIG_RMOBILE to CONFIG_ARCH_RMOBILE
  MAINTAINERS: Add maintainer entry of RMOBILE
  ARM: rmobile: Create R-Car 32bit (Gen1 and Gen2) for Kconfig
  ARM: rmobile: Move rcar-gen2-common to rcar-common
  ARM: rmobile: Add support R-Car Generation 3
  ARM: rmobile: Add support R8A7795
  ARM: rmobile: Add support salvator-x board
  ARM: rmobile: rcar-common: Fix warning of type difference
  arm: rmobile: Update defconfig

Yannick Gicquel (1):
  mmc: rmobile: add a compiler barrier

masakazu.mochizuki...@hitachi.com (2):
  arm: rmobile: Add BLANCHE board support
  arm: rmobile: Fix HDMI output for BLANCHE board

 MAINTAINERS
  |6 +
 arch/arm/Kconfig
  |7 +-
 arch/arm/Makefile
  |1 +
 arch/arm/cpu/armv7/Makefile
  |1 +
 arch/arm/mach-rmobile/Kconfig
  |   20 +
 arch/arm/{cpu/armv7/rmobile/Kconfig => mach-rmobile/Kconfig.32}
  |   12 +-
 arch/arm/mach-rmobile/Kconfig.64
  |   28 +
 arch/arm/{cpu/armv7/rmobile => mach-rmobile}/Makefile
  |4 +-
 arch/arm/{cpu/armv7/rmobile => mach-rmobile}/board.c
  |0
 arch/arm/{cpu/armv7/rmobile => mach-rmobile}/cpu_info-r8a7740.c
  |0
 arch/arm/{cpu/armv7/rmobile => mach-rmobile}/cpu_info-rcar.c
  |0
 arch/arm/{cpu/armv7/rmobile => mach-rmobile}/cpu_info-sh73a0.c
  |0
 arch/arm/{cpu/armv7/rmobile => mach-rmobile}/cpu_info.c
  |1 +
 arch/arm/{cpu/armv7/rmobile => mach-rmobile}/emac.c
  |0
 arch/arm/{include/asm/arch-rmobile =>
mach-rmobile/include/mach}/ehci-rmobile.h |0
 arch/arm/{include/asm/arch-rmobile =>
mach-rmobile/include/mach}/gpio.h |6 +
 arch/arm/{include/asm/arch-rmobile =>
mach-rmobile/include/mach}/irqs.h |0
 arch/arm/{include/asm/arch-rmobile =>
mach-rmobile/include/mach}/mmc.h  |0
 arch/arm/{include/asm/arch-rmobile =>
mach-rmobile/include/mach}/r8a7740-gpio.h |0
 arch/arm/{include/asm/arch-rmobile =>
mach-rmobile/include/mach}/r8a7740.h  |0
 arch/arm/{include/asm/arch-rmobile =>
mach-rmobile/include/mach}/r8a7790-gpio.h |0
 arch/arm/{include/asm/arch-rmobile =>
mach-rmobile/include/mach}/r8a7790.h  |0
 arch/arm/{include/asm/arch-rmobile =>
mach-rmobile/include/mach}/r8a7791-gpio.h |0
 arch/arm/{include/asm/arch-rmobile =>
mach-rmobile/include/mach}/r8a7791.h  |0
 arch/arm/mach-rmobile/include/mach/r8a7792-gpio.h
  |  220 
 arch/arm/mach-rmobile/include/mach/r8a7792.h
  |   34 +
 arch/arm/{include/asm/arch-rmobile =>
mach-rmobile/include/mach}/r8a7793-gpio.h |0
 arch/arm/{include/asm/arch-rmobile =>
mach-rmobile/include/mach}/r8a7793.h  |0
 arch/arm/{include/asm/arch-rmobile =>
mach-rmobile/include/mach}/r8a7794-gpio.h |0
 arch/arm/{include/asm/arch-rmobile =>
mach-rmobile/include/mach}/r8a7794.h  |0
 arch/arm/mach-rmobile/include/mach/r8a7795-gpio.h
  |  988 ++
 arch/arm/mach-rmobile/include/mach/r8a7795.h
  |   36 +
 arch/arm/{include/asm/arch-rmobile =>
mach-rmobile/include/mach}/rcar-base.h|  387 +-
 arch/arm/mach-rmobile/include/mach/rcar-gen3-base.h
  |  100 ++
 arch/arm/{include/asm/arch-rmobile =>
mach-rmobile/include/mach}/rcar-mstp.h|0
 arch/arm/{include/asm/arch-rmobile =>
mach-rmobile/include/mach}/rmobile.h  |8 +-
 arch/arm/{include/asm/arch-rmobile =>
mach-rmobile/include/mach}/sh73a0-gpio.h  |0
 arch/arm/{include/asm/arch-rmobile =>
mach-rmobile/include/mach}/sh73a0.h   |0
 arch/arm/{include/asm/arch-rmobile =>
mach-rmobile/include/mach}/sh_sdhi.h  |0
 arch/arm/{include/asm/arch-rmobile =>
mach-rmobile/include/mach}/sys_proto.h|0
 arch/arm/{cpu/armv7/rmobile => mach-rmobile}/lowlevel_init.S
  |0
 arch/arm/{cpu/armv7/rmobile => mach-rmobile}/lowlevel_init_ca15.S
  |0
 arch/arm/mach-rmobile/lowlevel_init_gen3.S
  |   76 ++
 arch/arm/{cpu/armv7/rmobile => mach-rmobile}/pfc-r8a7740.c
  |0
 arch/arm/{cpu/armv7/rmobile => mach-rmobile}/pfc-r8a7790.c
  |0
 arch/arm/{cpu/armv7/rmobile => mach-rmobile}/pfc-r8a7790.h
  |   48 +
 arch/arm/{cpu/armv7/rmobile => mach-rmobile}/pfc-r8a7791.c
  

[U-Boot] [PATCH 0/2] fix build dependency for TI secure devices

[Andreas Dannenberg]

The recent "Secure Boot by Authenticating/Decrypting SPL FIT blobs"
patch series [1] introduced an undesired dependency on
CONFIG_SPL_LOAD_FIT for TI secure devices, breaking the build when
that option is not active. While this is not an immediately visible
issue as we migrated all applicable device defconfig files to use
CONFIG_SPL_LOAD_FIT, it does create an issue if someone choses to
disable that option

[1] https://www.mail-archive.com/u-boot%40lists.denx.de/msg217284.html

Andreas Dannenberg (2):
  arm: am4x: fix build dependency for secure devices
  arm: omap5: fix build dependency for secure devices

 arch/arm/cpu/armv7/am33xx/config.mk | 2 +-
 arch/arm/cpu/armv7/omap5/config.mk  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

-- 
2.7.2

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 1/2] arm: am4x: fix build dependency for secure devices

[Andreas Dannenberg]

Commit e29878f introduces an undesired dependency on CONFIG_SPL_LOAD_FIT
when building U-Boot for AM43xx high-security (HS) devices that causes the
build to break when that option is not active. Fix this issue by only
building the u-boot_HS.img target when building U-Boot into an actual
FIT image.

Signed-off-by: Andreas Dannenberg 
---
 arch/arm/cpu/armv7/am33xx/config.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv7/am33xx/config.mk 
b/arch/arm/cpu/armv7/am33xx/config.mk
index ab94708..d4eb21c 100644
--- a/arch/arm/cpu/armv7/am33xx/config.mk
+++ b/arch/arm/cpu/armv7/am33xx/config.mk
@@ -26,7 +26,7 @@ endif
 else
 ifeq ($(CONFIG_TI_SECURE_DEVICE),y)
 ALL-$(CONFIG_QSPI_BOOT) += u-boot_HS_XIP_X-LOADER
-ALL-y  += u-boot_HS.img
+ALL-$(CONFIG_SPL_LOAD_FIT) += u-boot_HS.img
 endif
 ALL-y  += u-boot.img
 endif
-- 
2.7.2

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 2/2] arm: omap5: fix build dependency for secure devices

[Andreas Dannenberg]

Commit 17c2987 introduces an undesired dependency on CONFIG_SPL_LOAD_FIT
when building U-Boot for AM57xx and DRA7xx high-security (HS) devices that
causes the build to break when that option is not active. Fix this issue
by only building the u-boot_HS.img target when building U-Boot into an
actual FIT image.

Signed-off-by: Andreas Dannenberg 
---
 arch/arm/cpu/armv7/omap5/config.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv7/omap5/config.mk 
b/arch/arm/cpu/armv7/omap5/config.mk
index d245572..286ca86 100644
--- a/arch/arm/cpu/armv7/omap5/config.mk
+++ b/arch/arm/cpu/armv7/omap5/config.mk
@@ -16,7 +16,7 @@ ALL-y += MLO
 endif
 else
 ifeq ($(CONFIG_TI_SECURE_DEVICE),y)
-ALL-y   += u-boot_HS.img
+ALL-$(CONFIG_SPL_LOAD_FIT) += u-boot_HS.img
 endif
 ALL-y  += u-boot.img
 endif
-- 
2.7.2

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 0/9] Secure Boot by Authenticating/Decrypting SPL FIT blobs

[Andreas Dannenberg]

On Mon, Jun 27, 2016 at 09:19:15AM -0500, Andreas Dannenberg wrote:
> This is an updated version of a patch series that introduces a generic way
> to optionally post-process blobs as they get extracted by the SPL from the
> u-boot.img FIT image, and uses this scheme to perform some authentication/
> decryption related processing on TI's high-secure (HS) SoC variants. For
> additional background please see here [1].

I just wanted to point out that this now-accepted patch series in by
itself is not a 100% complete solution to address all needs of secure
boot. Specifically, the extensions made rely on loading U-Boot as a FIT
image (CONFIG_SPL_LOAD_FIT) but do not prevent the loading of a legacy
non-FIT U-Boot image. This is something that will need to get addressed
in a follow-on patch.

Regards,
Andreas

> [1] http://lists.denx.de/pipermail/u-boot/2016-June/258716.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Booting armv8 Kernel on UBoot

[Rajkumar Ramasamy]

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] fatwrite issue in sub-directories

[Nicolas le bayon]

Hi all,

With a quite old u-boot release (October 2015 more or less), I has some
different issues around fatwrite operations. I realigned a few things
around FAT with latest release, and now I observe only one issue. Maybe
this has been discussed here before, I searched but no success.

I'd like to save a file on an external device (sd card or usb stick), but
not on the root, in a sub-directory. I made the implementation with EXT4
and it works fine. But no way (for the moment) with FAT.

Here is the behaviour, let's imagine the device contains only a "mydir"
directory.
> fatls 
mydir/
> fatwrite   myfile.txt 
> fatls 
mydir/
myfile.txt
> fatwrite   mydir/myfile2.txt 
> fatls 
 mydir/
 myfile.txt
 mydir/myfile2.txt
In fact, data is stored in a file strangely named with a '/' character.

And when I put the device back on my Linux PC, I can see myfile.txt,
nothing special in mydir directory, and no "mydir/myfile2.txt" file.

Does someone have already observed this?

Best Regards
Nicolas
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] armv8/ls1043a: Add MTD partition scheme

[Wenbin Song]

Hi: York

I'm sorry to have misunderstood you mean.
I think it is a good idea that modify/remove the wrong/useless variables  in a 
new patch.
And I will make it later.
Do you have any suggestion?

Best Regards
Wenbin Song

> -Original Message-
> From: york sun
> Sent: Wednesday, July 20, 2016 6:02 AM
> To: Wenbin Song ; Mingkai Hu ;
> u-boot@lists.denx.de
> Cc: Qianyu Gong ; Shaohui Xie ;
> Zhiqiang Hou 
> Subject: Re: [PATCH] armv8/ls1043a: Add MTD partition scheme
> 
> On 04/06/2016 10:46 PM, Wenbin Song wrote:
> > Hi: York
> >
> > Please see my inline comments.
> >
> > Best Regards
> > Wenbin Song
> >
> >> -Original Message-
> >> From: York Sun [mailto:york@nxp.com]
> >> Sent: Thursday, April 07, 2016 1:18 AM
> >> To: Wenbin Song ; Mingkai Hu
> >> ; u-boot@lists.denx.de
> >> Cc: Qianyu Gong ; Shaohui Xie
> >> ; Zhiqiang Hou 
> >> Subject: Re: [PATCH] armv8/ls1043a: Add MTD partition scheme
> >>
> >> On 04/06/2016 12:11 AM, Wenbin Song wrote:
> >>> Hi: York
> >>>
> >>> I set bootargs  as the following steps:
> >>>
> >>> => env default mtdparts
> >>> => printenv mtdparts
> >>>
> >> mtdparts=mtdparts=6000.nor:1m(nor_bank0_rcw),1m(nor_bank0_uboot)
> >> ,1
> >>>
> >> m(nor_bank0_uboot_env),1m(nor_bank0_fman_uconde),40m(nor_bank0_fit
> >> ),1m
> >>>
> >> (nor_bank4_rcw),1m(nor_bank4_uboot),1m(nor_bank4_uboot_env),1m(nor_
> >> ban
> >>>
> >> k4_fman_ucode),40m(nor_bank4_fit);7e80.flash:1m(nand_uboot),1m(na
> >> n
> >>> d_uboot_env),20m(nand_fit);spi0.0:1m(uboot),5m(kernel),1m(dtb),9m(fi
> >>> le
> >>> _system)
> >>> => env default bootargs
> >>> => printenv bootargs
> >>> bootargs=console=ttyS0,115200 root=/dev/ram0
> >>> earlycon=uart8250,mmio,0x21c0500 ${mtdparts}
> >>>
> >>>
> >>> The macro  CONFIG_BOOTARGS  only be extern as an char-string, and it
> >>> will
> >> be spliced into default_environment array .
> >>>
> >>>  const uchar default_environment[] = { #ifdef  CONFIG_BOOTARGS
> >>>   "bootargs=" CONFIG_BOOTARGS "\0"
> >>>  #endif
> >>>
> >>> The variable we use to have $consoledev, $othbootargs  was used in
> >>> the
> >> following cases:
> >>>
> >>> 858  #define CONFIG_BOOTCOMMAND \
> >>> 859 "setenv bootargs root=/dev/ram rw " \
> >>> 860 "console=$consoledev,$baudrate $othbootargs;"   \
> >>> 861 "setenv ramdiskaddr 0x0200;"\
> >>> 862 "setenv fdtaddr 0x00c0;"\
> >>> 863 "setenv loadaddr 0x100;"\
> >>> 864 "bootm $loadaddr $ramdiskaddr $fdtaddr"
> >>>
> >>> Because the "setenv"  will be executed  , So the variable could be 
> >>> extended.
> >>
> >> I see what you mean. I am trying to reduce the environmental variables.
> >> Do you need the variable "mtdparts"?
> >
> > [wenbin]
> >
> > I export this variable in order to make easier  to modify the bootargs under
> uboot command-line.
> >
> > For example:
> > =>setenv bootargs  "console=ttyS0,115200  root=/dev/ram0  $mtdparts"
> > =>setenv bootargs  "console=ttyLP0,115200  root=/dev/ram0  $mtdparts"
> >
> > Use the $mtdparts to instead of a long string.
> >
> >
> >> Would it be a better idea to set bootargs using the bootcmd?
> > [wenbin]
> >
> >  yes, It is a good idea.
> >  But we need all kinds of  ways to boot kernel  with this  "bootargs".  The
> bootcmd only can specify one boot-way.
> > IOW,  only the way specified by this "bootcmd"  can  execute " setenv  
> > bootargs".
> > So I want to supply the default bootargs  by the CONFIG_BOOTARGS .
> >
> >
> >>
> >> While you are on it, I suggest you take a look at other variables.
> >> "console=ttyAMA0,38400n8" is wrong here.
> >>
> >> We don't have to copy kernel image from NOR flash to DDR if the
> >> ramdisk load address is set properly in its file. So you can remove the 
> >> copying
> from bootcmd.
> >>
> > [wenbin]
> >
> > Ok, thanks for your advices,  I will modify them on the later patch.
> >
> 
> Wenbin,
> 
> Do you have an update?
> 
> York

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] (no subject)

[Stefano Babic]

HI Akshay,

On 01/01/1970 01:00,  wrote:
> Add support for Advantech DMS-BA16 board. The board is based on Advantech
> BA16 module which has a i.MX6D processor. The board supports:
>  - FEC Ethernet
>  - USB Ports
>  - SDHC and MMC boot
>  - SPI NOR
>  - LVDS and HDMI display
> 
> Basic information about the module:
>  - Module manufacturer: Advantech
>  - CPU: Freescale ARM Cortex-A9 i.MX6D
>  - SPECS:
>  Up to 2GB Onboard DDR3 Memory;
>  Up to 16GB Onboard eMMC NAND Flash
>  Supports OpenGL ES 2.0 and OpenVG 1.1
>  HDMI, 24-bit LVDS
>  1x UART, 2x I2C, 8x GPIO,
>  4x Host USB 2.0 port, 1x USB OTG port,
>  1x micro SD (SDHC),1x SDIO, 1x SATA II,
>  1x 10/100/1000 Mbps Ethernet, 1x PCIe X1 Gen2
> 
> Signed-off-by: Akshay Bhat 
> Cc: u-boot@lists.denx.de
> Cc: sba...@denx.de
> ---
>  arch/arm/cpu/armv7/mx6/Kconfig   |   5 +
>  board/advantech/dms-ba16/Kconfig |  27 ++
>  board/advantech/dms-ba16/MAINTAINERS |   8 +
>  board/advantech/dms-ba16/Makefile|   8 +
>  board/advantech/dms-ba16/ddr_1g.cfg  | 206 +
>  board/advantech/dms-ba16/ddr_2g.cfg  | 151 +
>  board/advantech/dms-ba16/dms-ba16.c  | 571 
> +++
>  configs/dms-ba16-1g_defconfig|  27 ++
>  configs/dms-ba16_defconfig   |  26 ++
>  include/configs/advantech_dms-ba16.h | 329 
>  10 files changed, 1358 insertions(+)
>  create mode 100644 board/advantech/dms-ba16/Kconfig
>  create mode 100644 board/advantech/dms-ba16/MAINTAINERS
>  create mode 100644 board/advantech/dms-ba16/Makefile
>  create mode 100644 board/advantech/dms-ba16/ddr_1g.cfg
>  create mode 100644 board/advantech/dms-ba16/ddr_2g.cfg
>  create mode 100644 board/advantech/dms-ba16/dms-ba16.c
>  create mode 100644 configs/dms-ba16-1g_defconfig
>  create mode 100644 configs/dms-ba16_defconfig
>  create mode 100644 include/configs/advantech_dms-ba16.h
> 
> diff --git a/arch/arm/cpu/armv7/mx6/Kconfig b/arch/arm/cpu/armv7/mx6/Kconfig
> index 663f970..1e4a1cb 100644
> --- a/arch/arm/cpu/armv7/mx6/Kconfig
> +++ b/arch/arm/cpu/armv7/mx6/Kconfig
> @@ -35,6 +35,10 @@ choice
>   prompt "MX6 board select"
>   optional
>  
> +config TARGET_ADVANTECH_DMS_BA16
> + bool "Advantech dms-ba16"
> + select MX6Q
> +
>  config TARGET_ARISTAINETOS
>   bool "aristainetos"
>  
> @@ -184,6 +188,7 @@ config SYS_SOC
>   default "mx6"
>  
>  source "board/ge/bx50v3/Kconfig"
> +source "board/advantech/dms-ba16/Kconfig"
>  source "board/aristainetos/Kconfig"
>  source "board/bachmann/ot1200/Kconfig"
>  source "board/barco/platinum/Kconfig"
> diff --git a/board/advantech/dms-ba16/Kconfig 
> b/board/advantech/dms-ba16/Kconfig
> new file mode 100644
> index 000..cbc803f
> --- /dev/null
> +++ b/board/advantech/dms-ba16/Kconfig
> @@ -0,0 +1,27 @@
> +choice
> +prompt "DDR Size"
> + default SYS_DDR_2G
> +
> +config SYS_DDR_1G
> + bool "1GiB"
> +
> +config SYS_DDR_2G
> + bool "2GiB"
> +
> +endchoice
> +
> +config IMX_CONFIG
> + default "board/advantech/dms-ba16/ddr_2g.cfg" if SYS_DDR_2G
> + default "board/advantech/dms-ba16/ddr_1g.cfg" if SYS_DDR_1G
> +
> +config SYS_BOARD
> + default "dms-ba16"
> +
> +config SYS_VENDOR
> + default "advantech"
> +
> +config SYS_SOC
> + default "mx6"
> +
> +config SYS_CONFIG_NAME
> + default "advantech_dms-ba16"
> diff --git a/board/advantech/dms-ba16/MAINTAINERS 
> b/board/advantech/dms-ba16/MAINTAINERS
> new file mode 100644
> index 000..e8ea3dd
> --- /dev/null
> +++ b/board/advantech/dms-ba16/MAINTAINERS
> @@ -0,0 +1,8 @@
> +ADVANTECH_DMS-BA16 BOARD
> +M:   Akshay Bhat 
> +M:   Ken Lin 
> +S:   Maintained
> +F:   board/advantech/dms-ba16/
> +F:   include/configs/advantech_dms-ba16.h
> +F:   configs/dms-ba16_defconfig
> +F:   configs/dms-ba16-1g_defconfig
> diff --git a/board/advantech/dms-ba16/Makefile 
> b/board/advantech/dms-ba16/Makefile
> new file mode 100644
> index 000..ec9aaa8
> --- /dev/null
> +++ b/board/advantech/dms-ba16/Makefile
> @@ -0,0 +1,8 @@
> +#
> +# Copyright 2016 Timesys Corporation
> +# Copyright 2016 Advantech Corporation
> +#
> +# SPDX-License-Identifier:   GPL-2.0+
> +#
> +
> +obj-y  := dms-ba16.o
> diff --git a/board/advantech/dms-ba16/ddr_1g.cfg 
> b/board/advantech/dms-ba16/ddr_1g.cfg
> new file mode 100644
> index 000..a470f48
> --- /dev/null
> +++ b/board/advantech/dms-ba16/ddr_1g.cfg
> @@ -0,0 +1,206 @@
> +/*
> + * Copyright (C) 2011 Freescale Semiconductor, Inc.
> + * Jason Liu 
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + *
> + * Refer doc/README.imximage for more details about how-to configure
> + * and create imximage boot image
> + *
> + * The syntax is taken as close as possible with the kwbimage
> + */
> +
> +
> +IMAGE_VERSION 2
> +BOOT_FROM sd
> +
> 

[U-Boot] [PATCH] mx6: wandboard: fix warning due to missing prototype

[Stefano Babic]

Signed-off-by: Stefano Babic 
CC: Fabio Estevam 
---
 board/wandboard/wandboard.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/board/wandboard/wandboard.c b/board/wandboard/wandboard.c
index 8340dd1..10cad3f 100644
--- a/board/wandboard/wandboard.c
+++ b/board/wandboard/wandboard.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] pico-imx6ul: drop warning due to redefined

[Stefano Babic]

USB gadget configuration is set in defconfig and
must be removed from pico-imx6ul.h.

Signed-off-by: Stefano Babic 
CC: Fabio Estevam 
---
 include/configs/pico-imx6ul.h | 12 
 1 file changed, 12 deletions(-)

diff --git a/include/configs/pico-imx6ul.h b/include/configs/pico-imx6ul.h
index a1e5f01..ca3c30b 100644
--- a/include/configs/pico-imx6ul.h
+++ b/include/configs/pico-imx6ul.h
@@ -54,13 +54,9 @@
 #define CONFIG_MXC_USB_FLAGS   0
 #define CONFIG_USB_MAX_CONTROLLER_COUNT2
 
-#define CONFIG_CI_UDC
 #define CONFIG_USBD_HS
-#define CONFIG_USB_GADGET_DUALSPEED
-#define CONFIG_USB_GADGET
 
 #define CONFIG_USB_FUNCTION_MASS_STORAGE
-#define CONFIG_USB_GADGET_DOWNLOAD
 #define CONFIG_USB_GADGET_VBUS_DRAW2
 
 #define CONFIG_USB_FUNCTION_DFU
@@ -68,14 +64,6 @@
 #define CONFIG_SYS_DFU_DATA_BUF_SIZE SZ_16M
 #define DFU_DEFAULT_POLL_TIMEOUT 300
 
-#define CONFIG_G_DNL_VENDOR_NUM0x0525
-#define CONFIG_G_DNL_PRODUCT_NUM   0xa4a5
-#define CONFIG_G_DNL_MANUFACTURER  "FSL"
-
-#define CONFIG_G_DNL_VENDOR_NUM0x0525
-#define CONFIG_G_DNL_PRODUCT_NUM   0xa4a5
-#define CONFIG_G_DNL_MANUFACTURER  "FSL"
-
 #define CONFIG_DEFAULT_FDT_FILE"imx6ul-pico-hobbit.dtb"
 
 #define CONFIG_SYS_MMC_IMG_LOAD_PART   1
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] Fix build for mx7dsabresd (secure config)

[Stefano Babic]

After moving CONFIG_USB_EHCI_MX7 to Kconfig,
the flag must be set in defconfig for mx7dsabresd.
It is already for the not secure config, it is
missing in the secure configuration.

Signed-off-by: Stefano Babic 
CC: Fabio Estevam 
---
 configs/mx7dsabresd_secure_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/configs/mx7dsabresd_secure_defconfig 
b/configs/mx7dsabresd_secure_defconfig
index 9e49004..0a3930e 100644
--- a/configs/mx7dsabresd_secure_defconfig
+++ b/configs/mx7dsabresd_secure_defconfig
@@ -4,6 +4,7 @@ CONFIG_TARGET_MX7DSABRESD=y
 CONFIG_IMX_RDC=y
 CONFIG_IMX_BOOTAUX=y
 CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/freescale/mx7dsabresd/imximage.cfg"
+CONFIG_BOOTDELAY=3
 CONFIG_HUSH_PARSER=y
 # CONFIG_CMD_BOOTD is not set
 CONFIG_CMD_BOOTZ=y
@@ -28,6 +29,8 @@ CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_USB=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_MXC_USB_OTG_HACTIVE=y
 CONFIG_USB_GADGET=y
 CONFIG_CI_UDC=y
 CONFIG_USB_GADGET_DOWNLOAD=y
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] test/py: vboot can be run only at Sandbox

[Stephen Warren]

On 07/20/2016 08:19 AM, Simon Glass wrote:

+Stephen

On 18 July 2016 at 00:49, Michal Simek  wrote:

Getting this error:
Zynq> sb load hostfs - 100
/home/monstr/data/disk/u-boot/build-zynq_zc706/test.fit
Unknown command 'sb' - try 'help'

because sb command is present only for Sandbox
obj-$(CONFIG_SANDBOX) += host.o

that's why mark this test to be run only at Sandbox

Signed-off-by: Michal Simek 
---

  test/py/tests/test_vboot.py | 1 +
  1 file changed, 1 insertion(+)

diff --git a/test/py/tests/test_vboot.py b/test/py/tests/test_vboot.py
index c77989591c7e..92b4eccad808 100644
--- a/test/py/tests/test_vboot.py
+++ b/test/py/tests/test_vboot.py
@@ -29,6 +29,7 @@ import pytest
  import sys
  import u_boot_utils as util

+@pytest.mark.boardspec('sandbox')
  @pytest.mark.buildconfigspec('fit_signature')


Can we have both conditions, or does it only work as an OR?


I believe marks are conditions that must be individually satisfied, so 
when there are multiple marks, it's treated like an AND, which I imagine 
is the desired thing here.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 5/5] fsl-layerscape: Add workaround for PCIe erratum A010315

[Zhiqiang Hou]

Hi York,

Thanks a lot for your comments!

> -Original Message-
> From: york sun
> Sent: 2016年7月20日 0:02
> To: Zhiqiang Hou ; u-boot@lists.denx.de;
> albert.u.b...@aribaud.net; w...@denx.de; Prabhakar Kushwaha
> ; alison.w...@freescale.com;
> mingkai...@freescale.com
> Cc: yao.y...@freescale.com; qianyu.g...@freescale.com;
> bmeng...@gmail.com; Shengzhou Liu 
> Subject: Re: [PATCH 5/5] fsl-layerscape: Add workaround for PCIe erratum
> A010315
> 
> On 07/03/2016 11:39 PM, Zhiqiang Hou wrote:
> > From: Hou Zhiqiang 
> >
> > As the access to serders protocol unselected PCIe controller will
> > hang. So disable the R/W permission to unselected PCIe controller
> > including its CCSR, IO space and memory space according to the serders
> > protocol field of RCW.
> >
> > Signed-off-by: Hou Zhiqiang 
> > ---
> > Tested on LS1043ARDB, LS1021AQDS boards.
> >
> >  arch/arm/cpu/armv7/ls102xa/soc.c  | 14 ++
> >  arch/arm/cpu/armv8/fsl-layerscape/soc.c   | 16 
> >  arch/arm/include/asm/arch-fsl-layerscape/config.h |  2 ++
> >  arch/arm/include/asm/arch-fsl-layerscape/soc.h|  4 
> >  arch/arm/include/asm/arch-ls102xa/config.h|  1 +
> >  arch/arm/include/asm/arch-ls102xa/ls102xa_soc.h   |  4 
> >  board/freescale/ls1012aqds/ls1012aqds.c   |  4 
> >  board/freescale/ls1012ardb/ls1012ardb.c   |  4 
> >  board/freescale/ls1021aqds/ls1021aqds.c   |  4 
> >  board/freescale/ls1021atwr/ls1021atwr.c   |  4 
> >  board/freescale/ls1043aqds/ls1043aqds.c   |  4 
> >  board/freescale/ls1043ardb/ls1043ardb.c   |  4 
> >  12 files changed, 65 insertions(+)
> >
> 
> Can you put the call of erratum_a010315() in an SoC file, instead of 
> individual
> board file?
> 
The erratum_a010315() involved global variable, so it must be called after the 
relocation,
and because it modified the CSU, it must be called at EL3. You know the PPA 
will be called at the
end of the board_init(),  so the erratum_a010315() can only be called in 
board_init(), and can't
call it in SoC file.

Thanks,
Zhiqiang
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4 8/9] efi_loader: Declare secure memory as reserved

[york sun]

On 06/20/2016 04:07 PM, Alexander Graf wrote:
> Some systems may implemente TrustZone (EL3) in U-Boot. Those systems
> reserve some memory that U-Boot is aware of as secure.
>
> For those systems, mask out that secure memory in the EFI memory map,
> as it's not usable from EL2 or EL1.
>
> Signed-off-by: Alexander Graf 
> ---
>  lib/efi_loader/efi_memory.c | 15 +++
>  1 file changed, 15 insertions(+)
>
> diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
> index df2381e..6e2eeeb 100644
> --- a/lib/efi_loader/efi_memory.c
> +++ b/lib/efi_loader/efi_memory.c
> @@ -398,5 +398,20 @@ int efi_memory_init(void)
>   efi_bounce_buffer = (void*)(uintptr_t)efi_bounce_buffer_addr;
>  #endif
>
> +#ifdef CONFIG_SYS_MEM_RESERVE_SECURE
> + /* Declare secure ram as reserved */
> +if (gd->secure_ram & MEM_RESERVE_SECURE_SECURED) {

This variable has been moved to gd->arch.secure_ram in recent commit.

York
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4 2/9] efi_loader: AArch64: Run EFI payloads in EL2 if U-Boot runs in EL3

[york sun]

On 06/21/2016 10:44 PM, Alexander Graf wrote:
>
>
> On 21.06.16 20:02, york sun wrote:
>> On 06/21/2016 10:55 AM, Alexander Graf wrote:
>>>
>>>
 Am 21.06.2016 um 19:12 schrieb york sun :

> On 06/20/2016 04:07 PM, Alexander Graf wrote:
> Some boards decided not to run ATF or other secure firmware in EL3, so
> they instead run U-Boot there. The uEFI spec doesn't know what EL3 is
> though - it only knows about EL2 and EL1. So if we see that we're running
> in EL3, let's get into EL2 to make payloads happy.
>
> Signed-off-by: Alexander Graf 
> ---
>   arch/arm/include/asm/armv8/mmu.h | 19 ---
>   cmd/bootefi.c| 11 +++
>   2 files changed, 23 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/include/asm/armv8/mmu.h 
> b/arch/arm/include/asm/armv8/mmu.h
> index 0d08ed3..876a2b2 100644
> --- a/arch/arm/include/asm/armv8/mmu.h
> +++ b/arch/arm/include/asm/armv8/mmu.h
> @@ -116,19 +116,24 @@
>   static inline void set_ttbr_tcr_mair(int el, u64 table, u64 tcr, u64 
> attr)
>   {
>   asm volatile("dsb sy");
> -if (el == 1) {
> +switch (el) {
> +case 1:
>   asm volatile("msr ttbr0_el1, %0" : : "r" (table) : "memory");
>   asm volatile("msr tcr_el1, %0" : : "r" (tcr) : "memory");
>   asm volatile("msr mair_el1, %0" : : "r" (attr) : "memory");
> -} else if (el == 2) {
> -asm volatile("msr ttbr0_el2, %0" : : "r" (table) : "memory");
> -asm volatile("msr tcr_el2, %0" : : "r" (tcr) : "memory");
> -asm volatile("msr mair_el2, %0" : : "r" (attr) : "memory");
> -} else if (el == 3) {
> +break;
> +case 3:
>   asm volatile("msr ttbr0_el3, %0" : : "r" (table) : "memory");
>   asm volatile("msr tcr_el3, %0" : : "r" (tcr) : "memory");
>   asm volatile("msr mair_el3, %0" : : "r" (attr) : "memory");
> -} else {
> +
> +/* We may switch to EL2 later, so set those too; fall through */
> +case 2:
> +asm volatile("msr ttbr0_el2, %0" : : "r" (table) : "memory");
> +asm volatile("msr tcr_el2, %0" : : "r" (tcr) : "memory");
> +asm volatile("msr mair_el2, %0" : : "r" (attr) : "memory");
> +break;


 This may be problematic. If we use secure memory for EL3, the MMU tables
 have to be within the secure memory. But EL2 will not be able to access
 it. I believe you have verified this patch set actually work. I am
 curious how it work.
>>>
>>> That's a good question. I suppose the default config doesn't actually lock 
>>> secure memory? Or doesn't go secure at all?
>>>
>>
>> The patch set using this secure memory is still pending. Our internal
>> team has been working on it. So the secure memory has been working. I am
>> sure I have put MMU tables in secure memory. You can verify by running
>> "bdi" command. It will show you the secure memory location. If you don't
>> see it, then you don't have secure memory setup. By default, it is enabled.
>
> Ok, yes, I do see secure memory there.
>
>> I remember I have done a test to access to the secure memory from
>> non-secure master and got an exception.
>>
>> Could your test run at EL2 without a proper MMU table? I don't remember
>> if the core would hang, or continue to run if fetching MMU table fails.
>
> So without this patch, U-Boot would just hang (or probably loop in
> delivering page faults) in the switch to EL2, before we even reach any
> EFI payload. I'm not sure why it does succeed in accessing the page
> tables though if they are indeed in secure memory.
>
> Maybe we should just turn the whole logic upside down. Switch from EL3
> to EL2 in very early init code and get people to just run ATF or some
> other self-contained trusted firmware (maybe even built as part of
> U-Boot) in EL3. Putting all of U-Boot into EL3 doesn't seem to much of a
> good idea either way, as there is a lot of code that has no business at EL3.
>
> Would that approach work for you as well?
>

Alex,

With recent patches merged, I think we have a solution here. You can 
call dcache_enable() after switching to el2 in cmd/bootefi.c. Since MMU 
is not on by default, mmu_setup() will be called. In the weak function, 
you check if (!gd->arch.tlb_fillptr), so no new tables are created. The 
code following will enable MMU for EL2. For platforms with mmu_setup 
(including ls2080a), mmu_setup() will take care of creating new tables 
in non-secure memory. I have verified on LS1043A with new PPA framework.

I can test this for you, if you educate me how to run distro boot. Do I 
need hard drive/image to continue?

York


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [v2 1/1] wandboard: fix dtb file names.

[Stefano Babic]

Hi Adam,

On 19/07/2016 19:51, Adam Duskett wrote:
>> From: feste...@gmail.com
>> Date: Tue, 19 Jul 2016 14:46:38 -0300
>> Subject: Re: [U-Boot] [v2 1/1] wandboard: fix dtb file names.
>> To: adamdusk...@outlook.com
>> CC: u-boot@lists.denx.de; sba...@denx.de
>>
>> On Tue, Jul 19, 2016 at 2:40 PM, Adam Duskett
>  wrote:
>>
>> >> I prefer to keep the current code as is.
>> > If it is left as is, then the previous version of the patch needs to be
>> > applied
>> > because the new dtb file names in kernel 4.1.15 are different.
>>
>> Then please change the name of the 4.1.15 vendor kernel dts to match
>> the one from mainline.
> 
> I did, and as per the commit message; Wolfgang Denk suggested making it
> into a 
> logic based function?  What would you like me to do?  I can just
> resubmit the old patch
> which changed the vendor names, or would you like me to follow
> Wolfgang's directions?
> 

There is something wrong in the approach. Please think that this is the
"default" environment fopr the wandboard, and this does not mean that
you have *always* to use the same environment. It is not thinkable that
anytime the kernel name (or something like this) is changed, u-boot
*code* must be changed.

More in the case of "community" boards like a wandboard, it must be
ensured that everybody can still work with it, without breaking for
small things as the DT's name the behaviour.

wandboar uses distro environment: why do not put a "boot.scr" in your
/boot directory on SD, as wandboard boots only from SD, and you
overwrite all values you want ?

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/9] rockchip: cosmetics, a fix and first steps on the rk3188

[Simon Glass]

Hi Heiko,

On 18 July 2016 at 07:42, Heiko Stübner  wrote:
> Hi Simon,
>
> Am Montag, 18. Juli 2016, 06:16:33 schrieb Simon Glass:
>> On 17 July 2016 at 09:27, Simon Glass  wrote:
>> > On 17 July 2016 at 09:20, Heiko Stübner  wrote:
>> >> Am Sonntag, 17. Juli 2016, 08:14:06 schrieb Simon Glass:
>> >>> Hi Heiko,
>> >>>
>> >>> On 15 July 2016 at 16:17, Heiko Stuebner  wrote:
>> >>> > I've made some nice progress on using mainline uboot on the rk3188
>> >>> > and would like to dump some first results.
>> >>> >
>> >>> > Right now I can use uboot on the rk3188 with the Rockchip binary ddr
>> >>> > init,
>> >>> > similar to what barebox does and can even netboot a kernel image using
>> >>> > a usb ethernet adapter [0] .
>> >>> >
>> >>> > While working on this I found quite some cosmetic stuff that shouldn't
>> >>> > persist to make extending easier. So while I don't know what the
>> >>> > policy
>> >>> > is for my standalone pinctrl and clock drivers (without the actual
>> >>> > board)
>> >>> > at least the cosmetics + fix might get in at least.
>> >>>
>> >>> Nice work!
>> >>>
>> >>> It would be best to add the drivers with the board - otherwise they
>> >>> are just dead code. How far away is it?
>> >>
>> >> The big issue is the SPL. Right now I'm using Rockchip's ddr-init as spl-
>> >> replacement, and I'd say this second part is nearly ready - only minor
>> >> cleanups.
>> >>
>> >> The memory-setup is supposed to be very much similar to the rk3288 (same
>> >> dw_upctl and ddr-phy), but it looks like the very first steps are
>> >> somewhat
>> >> different and I haven't been able to make the spl output anything on the
>> >> serial console yet ... which could stem from some difference in what the
>> >> soc expects or just some dumb mistake on my part :-)
>> >
>> > That's always tricky.
>> >
>> > You may already know this, but the EARLY_UART setting is used on
>> > rk3288 to display a character as soon as SPL starts. You might be able
>> > to do something similar. The main issue I had was getting the pinmux
>> > setting right.
>> >
>> > As a test, you can start with booting SPL from the ddr-init binary I
>> > suspect. I have not tried it but it should work. Then the pinmux
>> > should already be set up (since ddr-init outputs to serial).
>
> yep, changing the SPL_TEXT_BASE to the ram address and using the spl as 2nd
> stage brings me the expected
> earlyuart running
> message.
>
> I've also dumped the sram contents after a sucessful boot using the rk ddr-
> init + uboot and can see that the ddr-init is sitting at the 0x800 offset in
> sram - including the rk31 header, so I'm pretty sure the sram-based
> SPL_TEXT_BASE should be 0x10080804 - yet no lifesign.
>
> Judging by how the rk3036 declares its SPL_STACK, I guess 0x10087fff should
> also be right.
>
>> I'm going to apply the earlier patches in your series. Once you have a
>> working board we can apply the rest (to avoid adding dead code).
>
> great ... everything I don't need to carry over helps ;-) .
>
>
> Going forward, I see both the rk3368 and rk3399 support initially not
> providing a spl but sitting on top of the binary ddr init + ATF.
> Is that also something doable for my rk3188 or do you _require_ the spl there?
>
> I.e. bringing the support without spl forward should be fairly easy, so doing
> that first sounds nice, before worrying about the strange things the SPL 
> needs.

That it because we don't have a good story for how to integrate ATF
with SPL at present (on ARMv8). I would much prefer to avoid this on
rk3188. Can you perhaps ask the Rockchip people on the list for help?

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] test/py: vboot can be run only at Sandbox

[Simon Glass]

+Stephen

On 18 July 2016 at 00:49, Michal Simek  wrote:
> Getting this error:
> Zynq> sb load hostfs - 100
> /home/monstr/data/disk/u-boot/build-zynq_zc706/test.fit
> Unknown command 'sb' - try 'help'
>
> because sb command is present only for Sandbox
> obj-$(CONFIG_SANDBOX) += host.o
>
> that's why mark this test to be run only at Sandbox
>
> Signed-off-by: Michal Simek 
> ---
>
>  test/py/tests/test_vboot.py | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/test/py/tests/test_vboot.py b/test/py/tests/test_vboot.py
> index c77989591c7e..92b4eccad808 100644
> --- a/test/py/tests/test_vboot.py
> +++ b/test/py/tests/test_vboot.py
> @@ -29,6 +29,7 @@ import pytest
>  import sys
>  import u_boot_utils as util
>
> +@pytest.mark.boardspec('sandbox')
>  @pytest.mark.buildconfigspec('fit_signature')

Can we have both conditions, or does it only work as an OR?

>  def test_vboot(u_boot_console):
>  """Test verified boot signing with mkimage and verification with 'bootm'.
> --
> 1.9.1
>

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 06/14] drivers: i2c: omap24xx_i2c: adopt omap_i2c driver to driver model

[Simon Glass]

On 18 July 2016 at 03:41, Mugunthan V N  wrote:
> Convert omap i2c driver to adopt i2c driver model
>
> Signed-off-by: Mugunthan V N 
> ---
>  drivers/i2c/omap24xx_i2c.c | 99 
> ++
>  1 file changed, 99 insertions(+)

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] common: fit: Allow U-Boot images to be booted

[Mario Six]

On Wed, Jul 20, 2016 at 3:56 PM, Robert P. J. Day  wrote:
> On Wed, 20 Jul 2016, Mario Six wrote:
>
>> On Wed, Jul 20, 2016 at 2:59 PM, Robert P. J. Day  
>> wrote:
>> > On Wed, 20 Jul 2016, Mario Six wrote:
>> >
>> >> In certain circumstances it comes in handy to be able to boot
>> >> into a second U-Boot. But as of now it is not possible to boot a
>> >> U-Boot binary that is inside a FIT image, which is problematic
>> >> for projects that e.g. need to guarantee a unbroken chain of
>> >> trust from SOC all the way into the OS, since the FIT signing
>> >> mechanism cannot be used.
>> >>
>> >> This patch adds the capability to load such FIT images.
>> >>
>> >> An example .its snippet (utilizing signature verification) might
>> >> look like the following:
>> >>
>> >> images {
>> >>   firmware@1 {
>> >>   description = "2nd stage U-Boot image";
>> >>   data = /incbin/("u-boot-dtb.img.gz");
>> >>   type = "firmware";
>> >>   arch = "arm";
>> >>   os = "u-boot";
>> >>   compression = "gzip";
>> >>   load = <0x8FFFC0>;
>> >>   entry = <0x90>;
>> >>   signature@1 {
>> >>   algo = "sha256,rsa4096";
>> >>   key-name-hint = "key";
>> >>   };
>> >>   };
>> >> };
>> >
>> >   i'm sure i'm about to embarrass myself, but the above represents
>> > loading a second version of u-boot into RAM, no? but i thought
>> > u-boot didn't support being run out of RAM (except in special
>> > circumstances). so what am i misunderstanding here?
>>
>> Well, if by "special circumstances" you mean "load the U-Boot image
>> exactly where CONFIG_SYS_TEXT_BASE expects it to be loaded," then
>> these are special circumstances; the U-Boot in the example snippet
>> has CONFIG_SYS_TEXT_BASE of 0x90, we load it to 0x8FFFC0 (offset
>> for the 0x40 byte header), and the bootm routine simply jumps to the
>> entry point.
>>
>> Accordingly, the second stage U-Boot you want to run must not have
>> the save CONFIG_SYS_TEXT_BASE as the U-Boot you want to run it out
>> of (otherwise you would overwrite the existing image in memory);
>> something like
>>
>> #ifdef CONFIG_SECONDUBOOT
>> #defineCONFIG_SYS_TEXT_BASE0x0080
>> #else
>> #defineCONFIG_SYS_TEXT_BASE0x0090
>> #endif
>>
>> is needed if you want to build both with the same header file.
>>
>> Hope that makes things a bit clearer.
>
>   not really, since i always thought that the difficulty in loading
> and booting a second-stage u-boot was explained here:
>
> http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStartedInRAM
>
> that is, loading the second image to a different address is simple;
> the apparent difficulty is that the second-stage u-boot might not be
> able to handle the early setup already done by the first stage.
>
>   so i'm still confused as to what is being proposed here, and how it
> works.
>
> rday
>

Ah, alright. Look at the following quote from the page:

"On machines with boot-ROM and U-Boot-SPL, you might have better luck."

I'd venture that most SoCs these days have a boot-ROM; on these U-Boot, is not
as sensitive to not finding a "virgin" system (because the boot-ROM does some
initialization beforehand). The system I tested with is a Armada 38x, and we've
also use a similar approach on a MPC85xx system (if you would like to dig that
deep, the code is upstream: board/gdsys/p1022/controlcenterd*). The whole SPL
concept would be a problem if the boot loader needed a virgin CPU (since, well,
the SPL *is* a second U-Boot), so the restrictions mentioned in the page are
not as relevant for modern SoCs.

That's as far as my knowledge goes, if anyone wants to correct me, you're
welcome to do so :-)

Best regards,

Mario
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] test/py: vboot can be run only at Sandbox

[Michal Simek]

On 20.7.2016 16:19, Simon Glass wrote:
> +Stephen
> 
> On 18 July 2016 at 00:49, Michal Simek  wrote:
>> Getting this error:
>> Zynq> sb load hostfs - 100
>> /home/monstr/data/disk/u-boot/build-zynq_zc706/test.fit
>> Unknown command 'sb' - try 'help'
>>
>> because sb command is present only for Sandbox
>> obj-$(CONFIG_SANDBOX) += host.o
>>
>> that's why mark this test to be run only at Sandbox
>>
>> Signed-off-by: Michal Simek 
>> ---
>>
>>  test/py/tests/test_vboot.py | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/test/py/tests/test_vboot.py b/test/py/tests/test_vboot.py
>> index c77989591c7e..92b4eccad808 100644
>> --- a/test/py/tests/test_vboot.py
>> +++ b/test/py/tests/test_vboot.py
>> @@ -29,6 +29,7 @@ import pytest
>>  import sys
>>  import u_boot_utils as util
>>
>> +@pytest.mark.boardspec('sandbox')
>>  @pytest.mark.buildconfigspec('fit_signature')
> 
> Can we have both conditions, or does it only work as an OR?

Test is valid when both options are valid.
Stephen can confirm for sure.

Thanks,
Michal

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 05/14] drivers: i2c: omap24xx_i2c: prepare driver for DM conversion

[Simon Glass]

On 18 July 2016 at 03:41, Mugunthan V N  wrote:
> Prepare the driver for DM conversion.
>
> Signed-off-by: Mugunthan V N 
> ---
>  drivers/i2c/omap24xx_i2c.c | 308 
> +
>  1 file changed, 175 insertions(+), 133 deletions(-)

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] image: fix IH_ARCH_... values for uImage compatibility

[Simon Glass]

Hi Masahiro,

On 20 July 2016 at 07:09, Masahiro Yamada  wrote:
>
> Commit 555f45d8f916 ("image: Convert the IH_... values to enums")
> accidentally changed some IH_ARCH_... values.
>
> Originally, there existed a gap between IH_ARCH_M68K and
> IH_ARCH_MICROBLAZE, like follows.
>
>   #define IH_ARCH_SPARC64 11  /* Sparc 64 Bit */
>   #define IH_ARCH_M68K12  /* M68K */
>   #define IH_ARCH_MICROBLAZE  14  /* MicroBlaze   */
>   #define IH_ARCH_NIOS2   15  /* Nios-II  */
>
> The enum conversion broke the compatibility with existing uImage
> files.  Reverting 555f45d8f916 will cause build error unfortunately,
> so here is another way to fix it more easily.
>
> Signed-off-by: Masahiro Yamada 
> ---
>
>  include/image.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Simon Glass 

I had forgotten that and did not notice the discontinuous numbers.
Perhaps the next one we allocate should go in the gap? Also I suggest
a comment before each enum to explain this.

>
> diff --git a/include/image.h b/include/image.h
> index 2a5b560..b43b179 100644
> --- a/include/image.h
> +++ b/include/image.h
> @@ -182,7 +182,7 @@ enum {
> IH_ARCH_SPARC,  /* Sparc*/
> IH_ARCH_SPARC64,/* Sparc 64 Bit */
> IH_ARCH_M68K,   /* M68K */
> -   IH_ARCH_MICROBLAZE, /* MicroBlaze   */
> +   IH_ARCH_MICROBLAZE  = 14,   /* MicroBlaze   */
> IH_ARCH_NIOS2,  /* Nios-II  */
> IH_ARCH_BLACKFIN,   /* Blackfin */
> IH_ARCH_AVR32,  /* AVR32*/
> --
> 1.9.1
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] common: fit: Allow U-Boot images to be booted

[Robert P. J. Day]

On Wed, 20 Jul 2016, Mario Six wrote:

> On Wed, Jul 20, 2016 at 2:59 PM, Robert P. J. Day  
> wrote:
> > On Wed, 20 Jul 2016, Mario Six wrote:
> >
> >> In certain circumstances it comes in handy to be able to boot
> >> into a second U-Boot. But as of now it is not possible to boot a
> >> U-Boot binary that is inside a FIT image, which is problematic
> >> for projects that e.g. need to guarantee a unbroken chain of
> >> trust from SOC all the way into the OS, since the FIT signing
> >> mechanism cannot be used.
> >>
> >> This patch adds the capability to load such FIT images.
> >>
> >> An example .its snippet (utilizing signature verification) might
> >> look like the following:
> >>
> >> images {
> >>   firmware@1 {
> >>   description = "2nd stage U-Boot image";
> >>   data = /incbin/("u-boot-dtb.img.gz");
> >>   type = "firmware";
> >>   arch = "arm";
> >>   os = "u-boot";
> >>   compression = "gzip";
> >>   load = <0x8FFFC0>;
> >>   entry = <0x90>;
> >>   signature@1 {
> >>   algo = "sha256,rsa4096";
> >>   key-name-hint = "key";
> >>   };
> >>   };
> >> };
> >
> >   i'm sure i'm about to embarrass myself, but the above represents
> > loading a second version of u-boot into RAM, no? but i thought
> > u-boot didn't support being run out of RAM (except in special
> > circumstances). so what am i misunderstanding here?
>
> Well, if by "special circumstances" you mean "load the U-Boot image
> exactly where CONFIG_SYS_TEXT_BASE expects it to be loaded," then
> these are special circumstances; the U-Boot in the example snippet
> has CONFIG_SYS_TEXT_BASE of 0x90, we load it to 0x8FFFC0 (offset
> for the 0x40 byte header), and the bootm routine simply jumps to the
> entry point.
>
> Accordingly, the second stage U-Boot you want to run must not have
> the save CONFIG_SYS_TEXT_BASE as the U-Boot you want to run it out
> of (otherwise you would overwrite the existing image in memory);
> something like
>
> #ifdef CONFIG_SECONDUBOOT
> #defineCONFIG_SYS_TEXT_BASE0x0080
> #else
> #defineCONFIG_SYS_TEXT_BASE0x0090
> #endif
>
> is needed if you want to build both with the same header file.
>
> Hope that makes things a bit clearer.

  not really, since i always thought that the difficulty in loading
and booting a second-stage u-boot was explained here:

http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStartedInRAM

that is, loading the second image to a different address is simple;
the apparent difficulty is that the second-stage u-boot might not be
able to handle the early setup already done by the first stage.

  so i'm still confused as to what is being proposed here, and how it
works.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] fixing typo error in README file. CPU15 -> CP15

[yeongjun Kim]

It looks typo error. 
Not CPU15, CP15(CoProcessor15)

Signed-off-by: yeongjun Kim 
---
 README | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README b/README
index 3c3b699..8887cf5 100644
--- a/README
+++ b/README
@@ -4806,7 +4806,7 @@ Low Level (hardware related) configuration options:
 
 - CONFIG_SKIP_LOWLEVEL_INIT_ONLY
[ARM926EJ-S only] This allows just the call to lowlevel_init()
-   to be skipped. The normal CPU15 init (such as enabling the
+   to be skipped. The normal CP15 init (such as enabling the
instruction cache) is still performed.
 
 - CONFIG_SPL_BUILD
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] common: fit: Allow U-Boot images to be booted

[Mario Six]

On Wed, Jul 20, 2016 at 2:59 PM, Robert P. J. Day  wrote:
> On Wed, 20 Jul 2016, Mario Six wrote:
>
>> In certain circumstances it comes in handy to be able to boot into a second
>> U-Boot. But as of now it is not possible to boot a U-Boot binary that is 
>> inside
>> a FIT image, which is problematic for projects that e.g. need to guarantee a
>> unbroken chain of trust from SOC all the way into the OS, since the FIT 
>> signing
>> mechanism cannot be used.
>>
>> This patch adds the capability to load such FIT images.
>>
>> An example .its snippet (utilizing signature verification) might look
>> like the following:
>>
>> images {
>>   firmware@1 {
>>   description = "2nd stage U-Boot image";
>>   data = /incbin/("u-boot-dtb.img.gz");
>>   type = "firmware";
>>   arch = "arm";
>>   os = "u-boot";
>>   compression = "gzip";
>>   load = <0x8FFFC0>;
>>   entry = <0x90>;
>>   signature@1 {
>>   algo = "sha256,rsa4096";
>>   key-name-hint = "key";
>>   };
>>   };
>> };
>
>   i'm sure i'm about to embarrass myself, but the above represents
> loading a second version of u-boot into RAM, no? but i thought u-boot
> didn't support being run out of RAM (except in special circumstances).
> so what am i misunderstanding here?
>
> rday
>

Well, if by "special circumstances" you mean "load the U-Boot image exactly
where CONFIG_SYS_TEXT_BASE expects it to be loaded," then these are special
circumstances; the U-Boot in the example snippet has CONFIG_SYS_TEXT_BASE of
0x90, we load it to 0x8FFFC0 (offset for the 0x40 byte header), and the
bootm routine simply jumps to the entry point.

Accordingly, the second stage U-Boot you want to run must not have the save
CONFIG_SYS_TEXT_BASE as the U-Boot you want to run it out of (otherwise you
would overwrite the existing image in memory); something like

#ifdef CONFIG_SECONDUBOOT
#defineCONFIG_SYS_TEXT_BASE0x0080
#else
#defineCONFIG_SYS_TEXT_BASE0x0090
#endif

is needed if you want to build both with the same header file.

Hope that makes things a bit clearer.

Best regards,

Mario
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [Urgent Problem] ARM64 Linux fails to boot with initramdisk with uImage header

[Masahiro Yamada]

Hi Tom.


2016-07-20 21:41 GMT+09:00 Tom Rini :
> I think Simon is away this week and that change is in the middle of some
> others.  So I'd like to fix things today and let him weigh in.  But I
> think enums make sense and we've just got a historical oddity to explain
> that gap.

OK.  Now it is on Patchwork:
http://patchwork.ozlabs.org/patch/650664/





-- 
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] image: fix IH_ARCH_... values for uImage compatibility

[Masahiro Yamada]

Commit 555f45d8f916 ("image: Convert the IH_... values to enums")
accidentally changed some IH_ARCH_... values.

Originally, there existed a gap between IH_ARCH_M68K and
IH_ARCH_MICROBLAZE, like follows.

  #define IH_ARCH_SPARC64 11  /* Sparc 64 Bit */
  #define IH_ARCH_M68K12  /* M68K */
  #define IH_ARCH_MICROBLAZE  14  /* MicroBlaze   */
  #define IH_ARCH_NIOS2   15  /* Nios-II  */

The enum conversion broke the compatibility with existing uImage
files.  Reverting 555f45d8f916 will cause build error unfortunately,
so here is another way to fix it more easily.

Signed-off-by: Masahiro Yamada 
---

 include/image.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/image.h b/include/image.h
index 2a5b560..b43b179 100644
--- a/include/image.h
+++ b/include/image.h
@@ -182,7 +182,7 @@ enum {
IH_ARCH_SPARC,  /* Sparc*/
IH_ARCH_SPARC64,/* Sparc 64 Bit */
IH_ARCH_M68K,   /* M68K */
-   IH_ARCH_MICROBLAZE, /* MicroBlaze   */
+   IH_ARCH_MICROBLAZE  = 14,   /* MicroBlaze   */
IH_ARCH_NIOS2,  /* Nios-II  */
IH_ARCH_BLACKFIN,   /* Blackfin */
IH_ARCH_AVR32,  /* AVR32*/
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] common: fit: Allow U-Boot images to be booted

[Robert P. J. Day]

On Wed, 20 Jul 2016, Mario Six wrote:

> In certain circumstances it comes in handy to be able to boot into a second
> U-Boot. But as of now it is not possible to boot a U-Boot binary that is 
> inside
> a FIT image, which is problematic for projects that e.g. need to guarantee a
> unbroken chain of trust from SOC all the way into the OS, since the FIT 
> signing
> mechanism cannot be used.
>
> This patch adds the capability to load such FIT images.
>
> An example .its snippet (utilizing signature verification) might look
> like the following:
>
> images {
>   firmware@1 {
>   description = "2nd stage U-Boot image";
>   data = /incbin/("u-boot-dtb.img.gz");
>   type = "firmware";
>   arch = "arm";
>   os = "u-boot";
>   compression = "gzip";
>   load = <0x8FFFC0>;
>   entry = <0x90>;
>   signature@1 {
>   algo = "sha256,rsa4096";
>   key-name-hint = "key";
>   };
>   };
> };

  i'm sure i'm about to embarrass myself, but the above represents
loading a second version of u-boot into RAM, no? but i thought u-boot
didn't support being run out of RAM (except in special circumstances).
so what am i misunderstanding here?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [Urgent Problem] ARM64 Linux fails to boot with initramdisk with uImage header

[Tom Rini]

On Wed, Jul 20, 2016 at 09:27:43PM +0900, Masahiro Yamada wrote:
> Hi Tom
> 
> 
> 2016-07-20 21:17 GMT+09:00 Tom Rini :
> > On Wed, Jul 20, 2016 at 08:03:03PM +0900, Masahiro Yamada wrote:
> >> Hi.
> >>
> >>
> >> I found ARM64 Linux fails to boot since commit 555f45d8f916 ("image:
> >> Convert the IH_... values to enums").  It claims the ramdisk with
> >> uImage header is corrupt or invalid as follow.
> >>
> >>   ## Loading init Ramdisk from Legacy Image at 84a0 ...
> >>  Image Name:
> >>  Created:  2016-06-20   4:41:26 UTC
> >>  Image Type:   ARC Linux RAMDisk Image (uncompressed)
> >>  Data Size:1752025 Bytes = 1.7 MiB
> >>  Load Address: 
> >>  Entry Point:  
> >>   No Linux AArch64 Ramdisk Image
> >>   Ramdisk image is corrupt or invalid
> >>
> >>
> >> Please note the "Image Type" field shows ARC, not AArch64.
> >>
> >>
> >> The cause of the problem is commit 555f45d8f916
> >> changed IH_ARCH_... values.
> >>
> >>
> >>
> >>
> >> Prior to the commit, IH_ARCH_... were defined as follows:
> >>
> >>   #define IH_ARCH_SH  9   /* SuperH   */
> >>   #define IH_ARCH_SPARC   10  /* Sparc*/
> >>   #define IH_ARCH_SPARC64 11  /* Sparc 64 Bit */
> >>   #define IH_ARCH_M68K12  /* M68K */
> >>   #define IH_ARCH_MICROBLAZE  14  /* MicroBlaze   */
> >>   #define IH_ARCH_NIOS2   15  /* Nios-II  */
> >>   #define IH_ARCH_BLACKFIN16  /* Blackfin */
> >>   #define IH_ARCH_AVR32   17  /* AVR32*/
> >>   #define IH_ARCH_ST200   18  /* STMicroelectronics ST200  */
> >>   #define IH_ARCH_SANDBOX 19  /* Sandbox architecture (test 
> >> only) */
> >>   #define IH_ARCH_NDS32   20  /* ANDES Technology - NDS32  */
> >>   #define IH_ARCH_OPENRISC21  /* OpenRISC 1000  */
> >>   #define IH_ARCH_ARM64   22  /* ARM64*/
> >>   #define IH_ARCH_ARC 23  /* Synopsys DesignWare ARC */
> >>   #define IH_ARCH_X86_64  24  /* AMD x86_64, Intel and Via */
> >>
> >>
> >>
> >> Please notice 13 is missing!
> >>
> >> The enum conversion changed the value of IH_ARCH_ARM64
> >> from 22 to 21.
> >>
> >> This broke the compatibility with already existing uImage files.
> >>
> >> I think the enum conversion was a bad idea
> >> because we tend to assume the order of items in enum
> >> is arbitrary, like sorting items alphabetically is allowed.
> >>
> >>
> >> I think the best thing is to revert 555f45d8f916,
> >> but it causes build error:
> >>
> >>
> >> In file included from tools/common/image.c:1:0:
> >> ./tools/../common/image.c:186:20: error: ‘IH_ARCH_COUNT’ undeclared
> >> here (not in a function)
> >>   { "architecture", IH_ARCH_COUNT, uimage_arch },
> >> ^
> >> ./tools/../common/image.c:187:19: error: ‘IH_COMP_COUNT’ undeclared
> >> here (not in a function)
> >>   { "compression", IH_COMP_COUNT, uimage_comp },
> >>^
> >> ./tools/../common/image.c:188:24: error: ‘IH_OS_COUNT’ undeclared here
> >> (not in a function)
> >>   { "operating system", IH_OS_COUNT, uimage_os },
> >>
> >>
> >>
> >> I am in trouble.
> >>
> >> Currently, I patch my local tree, like follows.
> >>
> >>
> >>
> >> @@ -182,7 +188,7 @@ enum {
> >>   IH_ARCH_SPARC, /* Sparc */
> >>   IH_ARCH_SPARC64, /* Sparc 64 Bit */
> >>   IH_ARCH_M68K, /* M68K */
> >> - IH_ARCH_MICROBLAZE, /* MicroBlaze   */
> >> + IH_ARCH_MICROBLAZE =14, /* MicroBlaze   */
> >>   IH_ARCH_NIOS2, /* Nios-II */
> >>   IH_ARCH_BLACKFIN, /* Blackfin */
> >>   IH_ARCH_AVR32, /* AVR32 */
> >
> > Please formalize this and submit as a real patch, I'll apply it.
> 
> 
> As I mentioned, I believe using enum is a bad idea here.
> 
> Is it better to convert the code back to #define,
> fixing the build error?

I think Simon is away this week and that change is in the middle of some
others.  So I'd like to fix things today and let him weigh in.  But I
think enums make sense and we've just got a historical oddity to explain
that gap.

> > Thanks!  And I am, really, getting some aarch64 systems setup such that
> > I can boot them regularly.
> >
> > But I'm also curious, what is your use case for uImage rather than the
> > kernel generated Image or a FIT image?
> 
> I use arch/arm64/boot/Image as is generated in the kernel tree.
> 
> I use initramdisk with uImage header
> generated by Buildroot.
> (rootfs.cpio.uboot)
> 
> 
> If I use a raw cpio,
> I guess U-Boot cannot know its size.
> (Perhaps, I am missing something, though.
> If you know a better idea, please let me know.)

Yes, you would need to pass in the address and size along to 'booti'.
When I do this kind of thing locally, I make sure to load the
initrd/initramfs last so that $filesize is correct.

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list

Re: [U-Boot] [Urgent Problem] ARM64 Linux fails to boot with initramdisk with uImage header

[Masahiro Yamada]

Hi Tom


2016-07-20 21:17 GMT+09:00 Tom Rini :
> On Wed, Jul 20, 2016 at 08:03:03PM +0900, Masahiro Yamada wrote:
>> Hi.
>>
>>
>> I found ARM64 Linux fails to boot since commit 555f45d8f916 ("image:
>> Convert the IH_... values to enums").  It claims the ramdisk with
>> uImage header is corrupt or invalid as follow.
>>
>>   ## Loading init Ramdisk from Legacy Image at 84a0 ...
>>  Image Name:
>>  Created:  2016-06-20   4:41:26 UTC
>>  Image Type:   ARC Linux RAMDisk Image (uncompressed)
>>  Data Size:1752025 Bytes = 1.7 MiB
>>  Load Address: 
>>  Entry Point:  
>>   No Linux AArch64 Ramdisk Image
>>   Ramdisk image is corrupt or invalid
>>
>>
>> Please note the "Image Type" field shows ARC, not AArch64.
>>
>>
>> The cause of the problem is commit 555f45d8f916
>> changed IH_ARCH_... values.
>>
>>
>>
>>
>> Prior to the commit, IH_ARCH_... were defined as follows:
>>
>>   #define IH_ARCH_SH  9   /* SuperH   */
>>   #define IH_ARCH_SPARC   10  /* Sparc*/
>>   #define IH_ARCH_SPARC64 11  /* Sparc 64 Bit */
>>   #define IH_ARCH_M68K12  /* M68K */
>>   #define IH_ARCH_MICROBLAZE  14  /* MicroBlaze   */
>>   #define IH_ARCH_NIOS2   15  /* Nios-II  */
>>   #define IH_ARCH_BLACKFIN16  /* Blackfin */
>>   #define IH_ARCH_AVR32   17  /* AVR32*/
>>   #define IH_ARCH_ST200   18  /* STMicroelectronics ST200  */
>>   #define IH_ARCH_SANDBOX 19  /* Sandbox architecture (test 
>> only) */
>>   #define IH_ARCH_NDS32   20  /* ANDES Technology - NDS32  */
>>   #define IH_ARCH_OPENRISC21  /* OpenRISC 1000  */
>>   #define IH_ARCH_ARM64   22  /* ARM64*/
>>   #define IH_ARCH_ARC 23  /* Synopsys DesignWare ARC */
>>   #define IH_ARCH_X86_64  24  /* AMD x86_64, Intel and Via */
>>
>>
>>
>> Please notice 13 is missing!
>>
>> The enum conversion changed the value of IH_ARCH_ARM64
>> from 22 to 21.
>>
>> This broke the compatibility with already existing uImage files.
>>
>> I think the enum conversion was a bad idea
>> because we tend to assume the order of items in enum
>> is arbitrary, like sorting items alphabetically is allowed.
>>
>>
>> I think the best thing is to revert 555f45d8f916,
>> but it causes build error:
>>
>>
>> In file included from tools/common/image.c:1:0:
>> ./tools/../common/image.c:186:20: error: ‘IH_ARCH_COUNT’ undeclared
>> here (not in a function)
>>   { "architecture", IH_ARCH_COUNT, uimage_arch },
>> ^
>> ./tools/../common/image.c:187:19: error: ‘IH_COMP_COUNT’ undeclared
>> here (not in a function)
>>   { "compression", IH_COMP_COUNT, uimage_comp },
>>^
>> ./tools/../common/image.c:188:24: error: ‘IH_OS_COUNT’ undeclared here
>> (not in a function)
>>   { "operating system", IH_OS_COUNT, uimage_os },
>>
>>
>>
>> I am in trouble.
>>
>> Currently, I patch my local tree, like follows.
>>
>>
>>
>> @@ -182,7 +188,7 @@ enum {
>>   IH_ARCH_SPARC, /* Sparc */
>>   IH_ARCH_SPARC64, /* Sparc 64 Bit */
>>   IH_ARCH_M68K, /* M68K */
>> - IH_ARCH_MICROBLAZE, /* MicroBlaze   */
>> + IH_ARCH_MICROBLAZE =14, /* MicroBlaze   */
>>   IH_ARCH_NIOS2, /* Nios-II */
>>   IH_ARCH_BLACKFIN, /* Blackfin */
>>   IH_ARCH_AVR32, /* AVR32 */
>
> Please formalize this and submit as a real patch, I'll apply it.


As I mentioned, I believe using enum is a bad idea here.

Is it better to convert the code back to #define,
fixing the build error?



> Thanks!  And I am, really, getting some aarch64 systems setup such that
> I can boot them regularly.
>
> But I'm also curious, what is your use case for uImage rather than the
> kernel generated Image or a FIT image?

I use arch/arm64/boot/Image as is generated in the kernel tree.

I use initramdisk with uImage header
generated by Buildroot.
(rootfs.cpio.uboot)


If I use a raw cpio,
I guess U-Boot cannot know its size.
(Perhaps, I am missing something, though.
If you know a better idea, please let me know.)





-- 
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] common: fit: Allow U-Boot images to be booted

[Tom Rini]

On Wed, Jul 20, 2016 at 08:32:50AM +0200, Mario Six wrote:

> In certain circumstances it comes in handy to be able to boot into a second
> U-Boot. But as of now it is not possible to boot a U-Boot binary that is 
> inside
> a FIT image, which is problematic for projects that e.g. need to guarantee a
> unbroken chain of trust from SOC all the way into the OS, since the FIT 
> signing
> mechanism cannot be used.
> 
> This patch adds the capability to load such FIT images.
> 
> An example .its snippet (utilizing signature verification) might look
> like the following:
> 
> images {
>   firmware@1 {
>   description = "2nd stage U-Boot image";
>   data = /incbin/("u-boot-dtb.img.gz");
>   type = "firmware";
>   arch = "arm";
>   os = "u-boot";
>   compression = "gzip";
>   load = <0x8FFFC0>;
>   entry = <0x90>;
>   signature@1 {
>   algo = "sha256,rsa4096";
>   key-name-hint = "key";
>   };
>   };
> };
> 
> Signed-off-by: Mario Six 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] what is the *recommended* split between defconfig file and header file?

[Tom Rini]

On Wed, Jul 20, 2016 at 12:21:16PM +0200, Andreas Färber wrote:
> Am 20.07.2016 um 10:56 schrieb Robert P. J. Day:
> > On Tue, 19 Jul 2016, Tom Rini wrote:
> > 
> >> On Tue, Jul 19, 2016 at 04:15:47AM -0400, Robert P. J. Day wrote:
> >>
> >>>
> >>>   kind of a style question but what is the preferred way to define a
> >>> board in the sense of what belongs in the defconfig file and what
> >>> belongs in the header file?
> >>
> >> The header files will eventually go away.  Most of the contents are
> >> things that could be, but haven't yet been, converted.  A few things
> >> like default environment are going to be harder to figure out.
> > 
> >   and what about the advantage of header files that allow the
> > inclusion of other header files to reduce duplication? will config
> > files be extended to allow the same thing? (they don't do that now, do
> > they?)
> 
> Use Kconfig files for setting defaults or adding selects.

Yes.  I am in favour of making heavy use of "default y if ..."
constructs and when possible some meta-options such as DISTRO_DEFAULTS

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [Urgent Problem] ARM64 Linux fails to boot with initramdisk with uImage header

[Tom Rini]

On Wed, Jul 20, 2016 at 08:03:03PM +0900, Masahiro Yamada wrote:
> Hi.
> 
> 
> I found ARM64 Linux fails to boot since commit 555f45d8f916 ("image:
> Convert the IH_... values to enums").  It claims the ramdisk with
> uImage header is corrupt or invalid as follow.
> 
>   ## Loading init Ramdisk from Legacy Image at 84a0 ...
>  Image Name:
>  Created:  2016-06-20   4:41:26 UTC
>  Image Type:   ARC Linux RAMDisk Image (uncompressed)
>  Data Size:1752025 Bytes = 1.7 MiB
>  Load Address: 
>  Entry Point:  
>   No Linux AArch64 Ramdisk Image
>   Ramdisk image is corrupt or invalid
> 
> 
> Please note the "Image Type" field shows ARC, not AArch64.
> 
> 
> The cause of the problem is commit 555f45d8f916
> changed IH_ARCH_... values.
> 
> 
> 
> 
> Prior to the commit, IH_ARCH_... were defined as follows:
> 
>   #define IH_ARCH_SH  9   /* SuperH   */
>   #define IH_ARCH_SPARC   10  /* Sparc*/
>   #define IH_ARCH_SPARC64 11  /* Sparc 64 Bit */
>   #define IH_ARCH_M68K12  /* M68K */
>   #define IH_ARCH_MICROBLAZE  14  /* MicroBlaze   */
>   #define IH_ARCH_NIOS2   15  /* Nios-II  */
>   #define IH_ARCH_BLACKFIN16  /* Blackfin */
>   #define IH_ARCH_AVR32   17  /* AVR32*/
>   #define IH_ARCH_ST200   18  /* STMicroelectronics ST200  */
>   #define IH_ARCH_SANDBOX 19  /* Sandbox architecture (test only) 
> */
>   #define IH_ARCH_NDS32   20  /* ANDES Technology - NDS32  */
>   #define IH_ARCH_OPENRISC21  /* OpenRISC 1000  */
>   #define IH_ARCH_ARM64   22  /* ARM64*/
>   #define IH_ARCH_ARC 23  /* Synopsys DesignWare ARC */
>   #define IH_ARCH_X86_64  24  /* AMD x86_64, Intel and Via */
> 
> 
> 
> Please notice 13 is missing!
> 
> The enum conversion changed the value of IH_ARCH_ARM64
> from 22 to 21.
> 
> This broke the compatibility with already existing uImage files.
> 
> I think the enum conversion was a bad idea
> because we tend to assume the order of items in enum
> is arbitrary, like sorting items alphabetically is allowed.
> 
> 
> I think the best thing is to revert 555f45d8f916,
> but it causes build error:
> 
> 
> In file included from tools/common/image.c:1:0:
> ./tools/../common/image.c:186:20: error: ‘IH_ARCH_COUNT’ undeclared
> here (not in a function)
>   { "architecture", IH_ARCH_COUNT, uimage_arch },
> ^
> ./tools/../common/image.c:187:19: error: ‘IH_COMP_COUNT’ undeclared
> here (not in a function)
>   { "compression", IH_COMP_COUNT, uimage_comp },
>^
> ./tools/../common/image.c:188:24: error: ‘IH_OS_COUNT’ undeclared here
> (not in a function)
>   { "operating system", IH_OS_COUNT, uimage_os },
> 
> 
> 
> I am in trouble.
> 
> Currently, I patch my local tree, like follows.
> 
> 
> 
> @@ -182,7 +188,7 @@ enum {
>   IH_ARCH_SPARC, /* Sparc */
>   IH_ARCH_SPARC64, /* Sparc 64 Bit */
>   IH_ARCH_M68K, /* M68K */
> - IH_ARCH_MICROBLAZE, /* MicroBlaze   */
> + IH_ARCH_MICROBLAZE =14, /* MicroBlaze   */
>   IH_ARCH_NIOS2, /* Nios-II */
>   IH_ARCH_BLACKFIN, /* Blackfin */
>   IH_ARCH_AVR32, /* AVR32 */

Please formalize this and submit as a real patch, I'll apply it.
Thanks!  And I am, really, getting some aarch64 systems setup such that
I can boot them regularly.

But I'm also curious, what is your use case for uImage rather than the
kernel generated Image or a FIT image?

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Please pull u-boot-cfi-flash/master

[Tom Rini]

On Wed, Jul 20, 2016 at 11:24:30AM +0200, Stefan Roese wrote:

> Hi Tom,
> 
> please pull the following patch:
> 
> The following changes since commit 9fcf809c1e3ff644b12e04e625d3737ffd8e:
> 
>   Merge git://git.denx.de/u-boot-fsl-qoriq (2016-07-19 16:38:57 -0400)
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-cfi-flash.git 
> 
> for you to fetch changes up to 55edb9d4d521ff733d217ddf47ad7bf4650676be:
> 
>   mtd: cfi_flash: fix polling for bit XSR.7 on Intel chips (2016-07-20 
> 11:13:26 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/5] fsl: serdes: ensure accessing the initialized maps of serdes protocol

[Zhiqiang Hou]

Hi York,

Thanks for your comments!

> -Original Message-
> From: york sun
> Sent: 2016年7月19日 23:46
> To: Zhiqiang Hou ; u-boot@lists.denx.de;
> albert.u.b...@aribaud.net; w...@denx.de; Prabhakar Kushwaha
> ; alison.w...@freescale.com;
> mingkai...@freescale.com
> Cc: yao.y...@freescale.com; qianyu.g...@freescale.com;
> bmeng...@gmail.com; Shengzhou Liu 
> Subject: Re: [PATCH 1/5] fsl: serdes: ensure accessing the initialized maps 
> of serdes
> protocol
> 
> On 07/03/2016 11:39 PM, Zhiqiang Hou wrote:
> > From: Hou Zhiqiang 
> >
> > Up to now, the function is_serdes_configed() doesn't check if the map
> > of serdes protocol is initialized before accessing it. The function
> > is_serdes_configed() will get wrong result when it was called before
> > the serdes protocol maps initialized. As the first eliment of the map
> 
> s/eliment/element
 
Will fix my spelling mistakes next version, thanks a lot!

> > isn't used for any device, so use it as the flag to indicate if the
> > map has been initialized.
> 
> I am not sure it is safe to presume the first element is always not used. Take
> LS2080A as an example, the serdes map array is initialized by serdes_init(), 
> which
> calls serdes_get_prtcl() to get the index of the array. With normal 
> condition, the
> index shouldn't be zero. Zero is used as an error but it is not checked 
> before setting
> 
> serdes_prtcl_map[lane_prtcl] = 1;
> 

The first element of enum srds_prtcl 'NONE' is aim to describe a lane isn't 
assigned to
any device, and the array serdesn_prtcl_map is used to check if the specified 
device
selected by the current serdes protocol, right? Nobody will check if the device 
'NONE'
has been configured, right? So it can be used to indicate if the 
serdes_prtcl_map has
been initialized.
Don't care whether the function serdes_get_prtcl() will return zero, just focus 
if the
serdes protocol map has been filled. For example, if the serdes protocol value 
read from
RCW doesn't match with any entry of the serdes_cfg_tbl, then all lane will be 
assigned to
'NONE'. It still means the serdes protocol map has been filled, even if there 
is only the
serdesn_prtcl_map[NONE] was set to 1.

> If you presumption is correct, and you want to use the first one as a flag, 
> you
> probably need to check all of them to make sure errors are handled correctly,
> instead of setting the flag unexpected. Also it is important to document this 
> idea
> so future platform code follows the same.
> 

Is it necessary to add it to a document, if add a comment to the 
serdesn_prtcl_map make it?

Thanks,
Zhiqiang
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [Urgent Problem] ARM64 Linux fails to boot with initramdisk with uImage header

[Masahiro Yamada]

Hi.


I found ARM64 Linux fails to boot since commit 555f45d8f916 ("image:
Convert the IH_... values to enums").  It claims the ramdisk with
uImage header is corrupt or invalid as follow.

  ## Loading init Ramdisk from Legacy Image at 84a0 ...
 Image Name:
 Created:  2016-06-20   4:41:26 UTC
 Image Type:   ARC Linux RAMDisk Image (uncompressed)
 Data Size:1752025 Bytes = 1.7 MiB
 Load Address: 
 Entry Point:  
  No Linux AArch64 Ramdisk Image
  Ramdisk image is corrupt or invalid


Please note the "Image Type" field shows ARC, not AArch64.


The cause of the problem is commit 555f45d8f916
changed IH_ARCH_... values.




Prior to the commit, IH_ARCH_... were defined as follows:

  #define IH_ARCH_SH  9   /* SuperH   */
  #define IH_ARCH_SPARC   10  /* Sparc*/
  #define IH_ARCH_SPARC64 11  /* Sparc 64 Bit */
  #define IH_ARCH_M68K12  /* M68K */
  #define IH_ARCH_MICROBLAZE  14  /* MicroBlaze   */
  #define IH_ARCH_NIOS2   15  /* Nios-II  */
  #define IH_ARCH_BLACKFIN16  /* Blackfin */
  #define IH_ARCH_AVR32   17  /* AVR32*/
  #define IH_ARCH_ST200   18  /* STMicroelectronics ST200  */
  #define IH_ARCH_SANDBOX 19  /* Sandbox architecture (test only) */
  #define IH_ARCH_NDS32   20  /* ANDES Technology - NDS32  */
  #define IH_ARCH_OPENRISC21  /* OpenRISC 1000  */
  #define IH_ARCH_ARM64   22  /* ARM64*/
  #define IH_ARCH_ARC 23  /* Synopsys DesignWare ARC */
  #define IH_ARCH_X86_64  24  /* AMD x86_64, Intel and Via */



Please notice 13 is missing!

The enum conversion changed the value of IH_ARCH_ARM64
from 22 to 21.

This broke the compatibility with already existing uImage files.

I think the enum conversion was a bad idea
because we tend to assume the order of items in enum
is arbitrary, like sorting items alphabetically is allowed.


I think the best thing is to revert 555f45d8f916,
but it causes build error:


In file included from tools/common/image.c:1:0:
./tools/../common/image.c:186:20: error: ‘IH_ARCH_COUNT’ undeclared
here (not in a function)
  { "architecture", IH_ARCH_COUNT, uimage_arch },
^
./tools/../common/image.c:187:19: error: ‘IH_COMP_COUNT’ undeclared
here (not in a function)
  { "compression", IH_COMP_COUNT, uimage_comp },
   ^
./tools/../common/image.c:188:24: error: ‘IH_OS_COUNT’ undeclared here
(not in a function)
  { "operating system", IH_OS_COUNT, uimage_os },



I am in trouble.

Currently, I patch my local tree, like follows.



@@ -182,7 +188,7 @@ enum {
  IH_ARCH_SPARC, /* Sparc */
  IH_ARCH_SPARC64, /* Sparc 64 Bit */
  IH_ARCH_M68K, /* M68K */
- IH_ARCH_MICROBLAZE, /* MicroBlaze   */
+ IH_ARCH_MICROBLAZE =14, /* MicroBlaze   */
  IH_ARCH_NIOS2, /* Nios-II */
  IH_ARCH_BLACKFIN, /* Blackfin */
  IH_ARCH_AVR32, /* AVR32 */


But, as I said above, I believe enum should not be used here
in the first place.

We need to do something asap.



-- 
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] UBIFS broken on Microblaze architecture and possibly on other architectrures as well

[Michal Simek]

Hi Marco,

On 19.7.2016 15:49, Hoefle Marco wrote:
> Hallo,
> 
> for ubifs on a spi flash I needed to add dummy functions and at atomic.h to 
> the microblaze port in order to get it compile and work.
> 
> code base is v2016.07

Please send it as regular patch with git commands.

Thanks,
Michal
-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP SoCs




signature.asc
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 2/2] config.h: clean unused CONFIG_ENV_SPI_* if using driver model

[Gong Qianyu]

When using SPI driver model, it will get the values from DT. So
there is no need to set CONFIG_ENV_SPI_MAX_HZ and
CONFIG_ENV_SPI_MODE any more.

Signed-off-by: Gong Qianyu 
---
 include/configs/ls1012a_common.h | 2 --
 include/configs/ls1043a_common.h | 2 --
 2 files changed, 4 deletions(-)

diff --git a/include/configs/ls1012a_common.h b/include/configs/ls1012a_common.h
index fba2fac..1602f09 100644
--- a/include/configs/ls1012a_common.h
+++ b/include/configs/ls1012a_common.h
@@ -52,8 +52,6 @@
 #define CONFIG_SYS_FMAN_FW_ADDR0x400d
 #define CONFIG_ENV_SPI_BUS 0
 #define CONFIG_ENV_SPI_CS  0
-#define CONFIG_ENV_SPI_MAX_HZ  100
-#define CONFIG_ENV_SPI_MODE0x03
 #define CONFIG_SPI_FLASH_SPANSION
 #define CONFIG_FSL_SPI_INTERFACE
 #define CONFIG_SF_DATAFLASH
diff --git a/include/configs/ls1043a_common.h b/include/configs/ls1043a_common.h
index b0d4a8d..028f7d9 100644
--- a/include/configs/ls1043a_common.h
+++ b/include/configs/ls1043a_common.h
@@ -222,8 +222,6 @@
 #define CONFIG_SYS_FMAN_FW_ADDR0x400d
 #define CONFIG_ENV_SPI_BUS 0
 #define CONFIG_ENV_SPI_CS  0
-#define CONFIG_ENV_SPI_MAX_HZ  100
-#define CONFIG_ENV_SPI_MODE0x03
 #else
 #define CONFIG_SYS_QE_FMAN_FW_IN_NOR
 /* FMan fireware Pre-load address */
-- 
2.1.0.27.g96db324

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 1/2] net: fm: fix spi flash probe for using driver model

[Gong Qianyu]

The current code would always use the speed and mode set by
CONFIG_ENV_SPI_MAX_HZ and CONFIG_ENV_SPI_MODE. But if using
SPI driver model it should get the values from DT.

Signed-off-by: Gong Qianyu 
---
 drivers/net/fm/fm.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/net/fm/fm.c b/drivers/net/fm/fm.c
index 00cdfd4..6308d22 100644
--- a/drivers/net/fm/fm.c
+++ b/drivers/net/fm/fm.c
@@ -371,8 +371,18 @@ int fm_init_common(int index, struct ccsr_fman *reg)
void *addr = malloc(CONFIG_SYS_QE_FMAN_FW_LENGTH);
int ret = 0;
 
+#ifdef CONFIG_DM_SPI_FLASH
+   struct udevice *new;
+
+   /* Will get the speed and mode from Device Tree */
+   ret = spi_flash_probe_bus_cs(CONFIG_ENV_SPI_BUS, CONFIG_ENV_SPI_CS,
+0, 0, );
+
+   ucode_flash = dev_get_uclass_priv(new);
+#else
ucode_flash = spi_flash_probe(CONFIG_ENV_SPI_BUS, CONFIG_ENV_SPI_CS,
CONFIG_ENV_SPI_MAX_HZ, CONFIG_ENV_SPI_MODE);
+#endif
if (!ucode_flash)
printf("SF: probe for ucode failed\n");
else {
-- 
2.1.0.27.g96db324

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] what is the *recommended* split between defconfig file and header file?

[Andreas Färber]

Am 20.07.2016 um 10:56 schrieb Robert P. J. Day:
> On Tue, 19 Jul 2016, Tom Rini wrote:
> 
>> On Tue, Jul 19, 2016 at 04:15:47AM -0400, Robert P. J. Day wrote:
>>
>>>
>>>   kind of a style question but what is the preferred way to define a
>>> board in the sense of what belongs in the defconfig file and what
>>> belongs in the header file?
>>
>> The header files will eventually go away.  Most of the contents are
>> things that could be, but haven't yet been, converted.  A few things
>> like default environment are going to be harder to figure out.
> 
>   and what about the advantage of header files that allow the
> inclusion of other header files to reduce duplication? will config
> files be extended to allow the same thing? (they don't do that now, do
> they?)

Use Kconfig files for setting defaults or adding selects.

Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v7] mmc: atmel_sdhci: Convert to the driver model support

[Wenyou Yang]

Convert the driver to the driver model while retaining the existing
legacy code. This allows the driver to support boards that have
converted to driver model as well as those that have not.

Signed-off-by: Wenyou Yang 
Reviewed-by: Simon Glass 
---

Changes in v7:
 - Add support for using driver model for block devices and MMC operations.
 - Change clk_client.h -> clk.h to adapt to clk API conversion.

Changes in v6:
 - Remove unnecessary white space.
 - Use sdhci_read(), instead of readl().
 - Remove the local variables min_clk.

Changes in v5:
 - Add Reviewed-by tag.

Changes in v4:
 - Update the clk API based on [PATCH] clk: convert API to match
   reset/mailbox fstyle (http://patchwork.ozlabs.org/patch/625342/).
 - Remove check on dev_get_parent() return.
 - Fixed the return value, such as -ENODEV->-EINVAL.

Changes in v3:
 - Remove the redundant log print.

Changes in v2:
 - Add clock support, include enabling peripheral clock and
   generated clock.
 - Retain the existing legacy code to support boards which have not
   converted to driver model.

 drivers/mmc/Kconfig   |  10 
 drivers/mmc/atmel_sdhci.c | 125 ++
 include/sdhci.h   |   2 +
 3 files changed, 137 insertions(+)

diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index 79cf18f..49b325e 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -34,6 +34,16 @@ config MSM_SDHCI
   SD 3.0 specifications. Both SD and eMMC devices are supported.
  Card-detect gpios are not supported.
 
+config ATMEL_SDHCI
+   bool "Atmel SDHCI controller support"
+   depends on DM_MMC && BLK && DM_MMC_OPS && ARCH_AT91
+   help
+ This enables support for the Atmel SDHCI controller, which supports
+ the embedded MultiMedia Card (e.MMC) Specification V4.51, the SD
+ Memory Card Specification V3.0, and the SDIO V3.0 specification.
+ It is compliant with the SD Host Controller Standard V3.0
+ specification.
+
 config ROCKCHIP_DWMMC
bool "Rockchip SD/MMC controller support"
depends on DM_MMC && OF_CONTROL
diff --git a/drivers/mmc/atmel_sdhci.c b/drivers/mmc/atmel_sdhci.c
index 24b68b6..977f6ef 100644
--- a/drivers/mmc/atmel_sdhci.c
+++ b/drivers/mmc/atmel_sdhci.c
@@ -6,12 +6,15 @@
  */
 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
 
 #define ATMEL_SDHC_MIN_FREQ40
 
+#ifndef CONFIG_DM_MMC
 int atmel_sdhci_init(void *regbase, u32 id)
 {
struct sdhci_host *host;
@@ -38,3 +41,125 @@ int atmel_sdhci_init(void *regbase, u32 id)
 
return 0;
 }
+
+#else
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct atmel_sdhci_plat {
+   struct mmc_config cfg;
+   struct mmc mmc;
+};
+
+static int atmel_sdhci_probe(struct udevice *dev)
+{
+   struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
+   struct atmel_sdhci_plat *plat = dev_get_platdata(dev);
+   struct sdhci_host *host = dev_get_priv(dev);
+   u32 max_clk;
+   u32 caps, caps_1;
+   u32 clk_base, clk_mul;
+   u32 gck_rate;
+   struct udevice *dev_clk;
+   struct clk clk;
+   int periph, ret;
+
+   ret = clk_get_by_index(dev, 0, );
+   if (ret)
+   return ret;
+
+   periph = fdtdec_get_uint(gd->fdt_blob, clk.dev->of_offset, "reg", -1);
+   if (periph < 0)
+   return -EINVAL;
+
+   dev_clk = dev_get_parent(clk.dev);
+   ret = clk_request(dev_clk, );
+   if (ret)
+   return ret;
+
+   clk.id = periph;
+   ret = clk_enable();
+   if (ret)
+   return ret;
+
+   host->name = (char *)dev->name;
+   host->ioaddr = (void *)dev_get_addr(dev);
+
+   host->quirks = 0;
+   host->version = sdhci_readw(host, SDHCI_HOST_VERSION);
+
+   host->bus_width = fdtdec_get_int(gd->fdt_blob, dev->of_offset,
+"bus-width", 4);
+
+   caps = sdhci_readl(host, SDHCI_CAPABILITIES);
+   clk_base = (caps & SDHCI_CLOCK_V3_BASE_MASK) >> SDHCI_CLOCK_BASE_SHIFT;
+   caps_1 = sdhci_readl(host, SDHCI_CAPABILITIES_1);
+   clk_mul = (caps_1 & SDHCI_CLOCK_MUL_MASK) >> SDHCI_CLOCK_MUL_SHIFT;
+   gck_rate = clk_base * 100 * (clk_mul + 1);
+
+   ret = clk_get_by_index(dev, 1, );
+   if (ret)
+   return ret;
+
+   periph = fdtdec_get_uint(gd->fdt_blob, clk.dev->of_offset, "reg", -1);
+   if (periph < 0)
+   return -EINVAL;
+
+   dev_clk = dev_get_parent(clk.dev);
+   ret = clk_request(dev_clk, );
+   if (ret)
+   return ret;
+
+   clk.id = periph;
+   ret = clk_set_rate(, gck_rate);
+   if (ret)
+   return ret;
+
+   max_clk = clk_get_rate();
+   if (!max_clk)
+   return -EINVAL;
+
+   ret = sdhci_setup_cfg(>cfg, dev->name, host->bus_width,
+ caps, max_clk, ATMEL_SDHC_MIN_FREQ,
+  

[U-Boot] [PATCH v3] dm: atmel: Add driver model support for the ehci driver

[Wenyou Yang]

Add driver model support while retaining the existing legacy code.
This allows the driver to support boards that have converted to
driver model as well as those that have not.

Signed-off-by: Wenyou Yang 
Acked-by: Simon Glass 
---

Changes in v3:
 - Change clk_client.h -> clk.h to adapt to clk API conversion.

Changes in v2:
 - Collect Acked-by tag.
 - Update the clk API based on [PATCH] clk: convert API to match
   reset/mailbox fstyle (http://patchwork.ozlabs.org/patch/625342/).

 drivers/usb/host/Kconfig  |   7 +++
 drivers/usb/host/ehci-atmel.c | 116 ++
 2 files changed, 123 insertions(+)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 89580cc..b8dd18e 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -60,6 +60,13 @@ config USB_EHCI
 
 if USB_EHCI_HCD
 
+config USB_EHCI_ATMEL
+   bool  "Support for Atmel on-chip EHCI USB controller"
+   depends on ARCH_AT91
+   default y
+   ---help---
+ Enables support for the on-chip EHCI controller on Atmel chips.
+
 config USB_EHCI_MARVELL
bool "Support for MVEBU (AXP / A38x) on-chip EHCI USB controller"
depends on ARCH_MVEBU
diff --git a/drivers/usb/host/ehci-atmel.c b/drivers/usb/host/ehci-atmel.c
index 1d7d280..d65bbe9 100644
--- a/drivers/usb/host/ehci-atmel.c
+++ b/drivers/usb/host/ehci-atmel.c
@@ -7,12 +7,18 @@
  */
 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
 
 #include "ehci.h"
 
+DECLARE_GLOBAL_DATA_PTR;
+
+#ifndef CONFIG_DM_USB
+
 int ehci_hcd_init(int index, enum usb_init_type init,
struct ehci_hccr **hccr, struct ehci_hcor **hcor)
 {
@@ -41,3 +47,113 @@ int ehci_hcd_stop(int index)
 
return 0;
 }
+
+#else
+
+struct ehci_atmel_priv {
+   struct ehci_ctrl ehci;
+};
+
+static int ehci_atmel_enable_clk(struct udevice *dev)
+{
+   struct udevice *dev_clk;
+   struct clk clk;
+   int periph;
+   int ret;
+
+   ret = clk_get_by_index(dev, 0, );
+   if (ret)
+   return ret;
+
+   ret = clk_enable();
+   if (ret)
+   return ret;
+
+   ret = clk_get_by_index(dev, 1, );
+   if (ret)
+   return -EINVAL;
+
+   periph = fdtdec_get_uint(gd->fdt_blob, clk.dev->of_offset, "reg", -1);
+   if (periph < 0)
+   return -EINVAL;
+
+   dev_clk = dev_get_parent(clk.dev);
+   if (!dev_clk)
+   return -ENODEV;
+
+   ret = clk_request(dev_clk, );
+   if (ret)
+   return ret;
+
+   clk.id = periph;
+   ret = clk_enable();
+   if (ret)
+   return ret;
+
+   clk_free();
+
+   return 0;
+}
+
+static int ehci_atmel_probe(struct udevice *dev)
+{
+   struct ehci_hccr *hccr;
+   struct ehci_hcor *hcor;
+   fdt_addr_t hcd_base;
+   int ret;
+
+   ret = ehci_atmel_enable_clk(dev);
+   if (ret) {
+   debug("Failed to enable USB Host clock\n");
+   return ret;
+   }
+
+   /*
+* Get the base address for EHCI controller from the device node
+*/
+   hcd_base = dev_get_addr(dev);
+   if (hcd_base == FDT_ADDR_T_NONE) {
+   debug("Can't get the EHCI register base address\n");
+   return -ENXIO;
+   }
+
+   hccr = (struct ehci_hccr *)hcd_base;
+   hcor = (struct ehci_hcor *)
+   ((u32)hccr + HC_LENGTH(ehci_readl(>cr_capbase)));
+
+   debug("echi-atmel: init hccr %x and hcor %x hc_length %d\n",
+ (u32)hccr, (u32)hcor,
+ (u32)HC_LENGTH(ehci_readl(>cr_capbase)));
+
+   return ehci_register(dev, hccr, hcor, NULL, 0, USB_INIT_HOST);
+}
+
+static int ehci_atmel_remove(struct udevice *dev)
+{
+   int ret;
+
+   ret = ehci_deregister(dev);
+   if (ret)
+   return ret;
+
+   return 0;
+}
+
+static const struct udevice_id ehci_usb_ids[] = {
+   { .compatible = "atmel,at91sam9g45-ehci", },
+   { }
+};
+
+U_BOOT_DRIVER(ehci_atmel) = {
+   .name   = "ehci_atmel",
+   .id = UCLASS_USB,
+   .of_match   = ehci_usb_ids,
+   .probe  = ehci_atmel_probe,
+   .remove = ehci_atmel_remove,
+   .ops= _usb_ops,
+   .platdata_auto_alloc_size = sizeof(struct usb_platdata),
+   .priv_auto_alloc_size = sizeof(struct ehci_atmel_priv),
+   .flags  = DM_FLAG_ALLOC_PRIV_DMA,
+};
+
+#endif
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v5] clk: at91: Add clock driver

[Wenyou Yang]

The patch is referred to at91 clock driver of Linux, to make
the clock node descriptions in DT aligned with the Linux's.

Signed-off-by: Wenyou Yang 
Reviewed-by: Simon Glass 
---

Changes in v5:
 - Change clk_client.h -> clk.h to adapt to clk API conversion.
 - Fix missing semicolon and clk->dev in clk-generated.c.
 - Make clock options selectable via menuconfig.

Changes in v4:
 - Add Reviewed-by tag.
 - Add more information in Kconfig help.
 - Use u32 for num_parents variable, not u8.
 - Change the check return from clk_get_rate().
 - Remove return -ENODEV line, use return ret.
 - Improve the comments in at91_system_clk_enable().

Changes in v3:
 - Update based on [PATCH] clk: convert API to match reset/mailbox
   style (http://patchwork.ozlabs.org/patch/625342/).
 - Remove [PATCH] clk: clk-uclass: Add post binding for CLK uclass,
   add bind() method to bind the clk node without compatible.
 - Add help for Kconfig HAVE_AT91_XX option.
 - Add ofdata_to_platdata() method for generated clock driver
   to handle the device tree.
 - Use setbits_le32() to replace readl()/writel().
 - Fixed the return value, -ENODEV->-EINVAL.
 - Use dev_get_addr_ptr() to replace dev_get_addr().
 - Remove check on dev_get_parent() return.

Changes in v2:
 - Remove the redundant log print.

 arch/arm/mach-at91/include/mach/at91_pmc.h |  11 +-
 drivers/clk/Kconfig|   1 +
 drivers/clk/Makefile   |   1 +
 drivers/clk/at91/Kconfig   |  43 
 drivers/clk/at91/Makefile  |  11 ++
 drivers/clk/at91/clk-generated.c   | 162 +
 drivers/clk/at91/clk-h32mx.c   |  56 ++
 drivers/clk/at91/clk-main.c|  55 ++
 drivers/clk/at91/clk-master.c  |  33 ++
 drivers/clk/at91/clk-peripheral.c  |  60 +++
 drivers/clk/at91/clk-plla.c|  55 ++
 drivers/clk/at91/clk-slow.c|  37 +++
 drivers/clk/at91/clk-system.c  |  76 ++
 drivers/clk/at91/clk-utmi.c|  67 
 drivers/clk/at91/pmc.c |  71 +
 drivers/clk/at91/pmc.h |  18 
 drivers/clk/at91/sckc.c|  30 ++
 17 files changed, 784 insertions(+), 3 deletions(-)
 create mode 100644 drivers/clk/at91/Kconfig
 create mode 100644 drivers/clk/at91/Makefile
 create mode 100644 drivers/clk/at91/clk-generated.c
 create mode 100644 drivers/clk/at91/clk-h32mx.c
 create mode 100644 drivers/clk/at91/clk-main.c
 create mode 100644 drivers/clk/at91/clk-master.c
 create mode 100644 drivers/clk/at91/clk-peripheral.c
 create mode 100644 drivers/clk/at91/clk-plla.c
 create mode 100644 drivers/clk/at91/clk-slow.c
 create mode 100644 drivers/clk/at91/clk-system.c
 create mode 100644 drivers/clk/at91/clk-utmi.c
 create mode 100644 drivers/clk/at91/pmc.c
 create mode 100644 drivers/clk/at91/pmc.h
 create mode 100644 drivers/clk/at91/sckc.c

diff --git a/arch/arm/mach-at91/include/mach/at91_pmc.h 
b/arch/arm/mach-at91/include/mach/at91_pmc.h
index 680ceb0..2875ff2 100644
--- a/arch/arm/mach-at91/include/mach/at91_pmc.h
+++ b/arch/arm/mach-at91/include/mach/at91_pmc.h
@@ -149,6 +149,9 @@ typedef struct at91_pmc {
 
 #define AT91_PMC_PCR_PID_MASK  (0x3f)
 #define AT91_PMC_PCR_GCKCSS(0x7 << 8)
+#define AT91_PMC_PCR_GCKCSS_MASK   0x07
+#define AT91_PMC_PCR_GCKCSS_OFFSET 8
+#define AT91_PMC_PCR_GCKCSS_(x)((x & 0x07) << 8)
 #defineAT91_PMC_PCR_GCKCSS_SLOW_CLK(0x0 << 8)
 #defineAT91_PMC_PCR_GCKCSS_MAIN_CLK(0x1 << 8)
 #defineAT91_PMC_PCR_GCKCSS_PLLA_CLK(0x2 << 8)
@@ -158,8 +161,9 @@ typedef struct at91_pmc {
 #define AT91_PMC_PCR_CMD_WRITE (0x1 << 12)
 #define AT91_PMC_PCR_DIV   (0x3 << 16)
 #define AT91_PMC_PCR_GCKDIV(0xff << 20)
-#defineAT91_PMC_PCR_GCKDIV_(x) (((x) & 0xff) << 20)
-#defineAT91_PMC_PCR_GCKDIV_OFFSET  20
+#define AT91_PMC_PCR_GCKDIV_MASK   0xff
+#define AT91_PMC_PCR_GCKDIV_OFFSET 20
+#define AT91_PMC_PCR_GCKDIV_(x)((x & 0xff) << 20)
 #define AT91_PMC_PCR_EN(0x1 << 28)
 #define AT91_PMC_PCR_GCKEN (0x1 << 29)
 
@@ -243,8 +247,9 @@ typedef struct at91_pmc {
 #defineAT91_PMC_PCK1RDY(1 <<  9)   /* 
Programmable Clock 1 */
 #defineAT91_PMC_PCK2RDY(1 << 10)   /* 
Programmable Clock 2 */
 #defineAT91_PMC_PCK3RDY(1 << 11)   /* 
Programmable Clock 3 */
+#defineAT91_PMC_MOSCSELS   BIT(16) /* Main 
Oscillator Selection Status */
+#defineAT91_PMC_MOSCRCSBIT(17) /* 12 
MHz RC Oscillator Status */
 #define

Re: [U-Boot] [PATCH V2] net: NFS: Add NFSv3 support

[Guillaume Gardet]

Le 25/06/2016 à 21:26, Joe Hershberger a écrit :

On Fri, Jun 24, 2016 at 10:03 AM, Tom Rini  wrote:

On Fri, Jun 24, 2016 at 09:45:38AM +0200, Guillaume Gardet wrote:


Le 23/06/2016 21:08, Tom Rini a écrit :

On Thu, Jun 23, 2016 at 11:10:26AM +0200, Guillaume GARDET wrote:


This patch enables NFSv3 support.
If NFSv2 is available use it as usual.
If NFSv2 is not available, but NFSv3 is available, use NFSv3.
If NFSv2 and NFSv3 are not available, print an error message since NFSv4 is not 
supported.

Tested on iMX6 sabrelite with 4 Linux NFS servers:
   * NFSv2 + NFSv3 + NFSv4 server: use NFSv2 protocol
   * NFSv2 + NFSv3 server: use NFSv3 protocol
   * NFSv3 + NFSv4 server: use NFSv3 protocol
   * NFSv3 server: use NFSv3 protocol

So, why do we have v2+v3+v4 -> v2 and not v2+v3+v4 -> v3, when we do
v2+v3 -> v3 and v3+v4 -> v3 ?  We should be consistent in preferring
either v2 over v3 or v3 over v2.  Thanks!


Sorry, it is a typo error. Please read: "NFSv2 + NFSv3 server: use NFSv2 
protocol".

As long as NFSv2 is available, we use it. Otherwise, we use v3 if
available. As explained above.

OK, that makes sense, thanks!  Joe, I assume you can just fix that in
the commit message when you pick this up.

Yup, no problem.



Just a friendly reminder for this patch. :)


Guillaume

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v5] dm: at91: Add driver model support for the spi driver

[Wenyou Yang]

Add driver model support while retaining the existing legacy code.
This allows the driver to support boards that have converted to
driver model as well as those that have not.

Signed-off-by: Wenyou Yang 
Reviewed-by: Simon Glass 
---

Changes in v5:
 - Change clk_client.h -> clk.h to adapt to clk API conversion.

Changes in v4:
 - Collect Reviewed-by tag.
 - Update the clk API based on [PATCH] clk: convert API to match
   reset/mailbox fstyle (http://patchwork.ozlabs.org/patch/625342/).
 - Remove check on dev_get_parent() return.
 - Fixed the return value, -ENODEV->-EINVAL.
 - Retain #include  line.

Changes in v3:
 - Remove redundant log print.

Changes in v2:
 - Add clock support.

 drivers/spi/Kconfig |   9 ++
 drivers/spi/atmel_spi.c | 303 
 2 files changed, 312 insertions(+)

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index aca385d..e015d1d 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -32,6 +32,15 @@ config ATH79_SPI
  uses driver model and requires a device tree binding to operate.
  please refer to doc/device-tree-bindings/spi/spi-ath79.txt.
 
+config ATMEL_SPI
+   bool "Atmel SPI driver"
+   depends on ARCH_AT91
+   select SPI_FLASH
+   select SPI_FLASH_ATMEL
+   help
+ Enable the Atmel SPI driver. This driver can be used to access
+ the SPI Flash, such as AT25DF321.
+
 config CADENCE_QSPI
bool "Cadence QSPI driver"
help
diff --git a/drivers/spi/atmel_spi.c b/drivers/spi/atmel_spi.c
index ed6278b..98bee35 100644
--- a/drivers/spi/atmel_spi.c
+++ b/drivers/spi/atmel_spi.c
@@ -4,6 +4,9 @@
  * SPDX-License-Identifier:GPL-2.0+
  */
 #include 
+#include 
+#include 
+#include 
 #include 
 #include 
 
@@ -11,9 +14,15 @@
 
 #include 
 #include 
+#include 
+#include 
 
 #include "atmel_spi.h"
 
+DECLARE_GLOBAL_DATA_PTR;
+
+#ifndef CONFIG_DM_SPI
+
 static int spi_has_wdrbt(struct atmel_spi_slave *slave)
 {
unsigned int ver;
@@ -209,3 +218,297 @@ out:
 
return 0;
 }
+
+#else
+
+#define MAX_CS_COUNT   4
+
+struct atmel_spi_platdata {
+   struct at91_spi *regs;
+};
+
+struct atmel_spi_priv {
+   unsigned int freq;  /* Default frequency */
+   unsigned int mode;
+   ulong bus_clk_rate;
+   struct gpio_desc cs_gpios[MAX_CS_COUNT];
+};
+
+static int atmel_spi_claim_bus(struct udevice *dev)
+{
+   struct udevice *bus = dev_get_parent(dev);
+   struct atmel_spi_platdata *bus_plat = dev_get_platdata(bus);
+   struct atmel_spi_priv *priv = dev_get_priv(bus);
+   struct dm_spi_slave_platdata *slave_plat = dev_get_parent_platdata(dev);
+   struct at91_spi *reg_base = bus_plat->regs;
+   u32 cs = slave_plat->cs;
+   u32 freq = priv->freq;
+   u32 scbr, csrx, mode;
+
+   scbr = (priv->bus_clk_rate + freq - 1) / freq;
+   if (scbr > ATMEL_SPI_CSRx_SCBR_MAX)
+   return -EINVAL;
+
+   if (scbr < 1)
+   scbr = 1;
+
+   csrx = ATMEL_SPI_CSRx_SCBR(scbr);
+   csrx |= ATMEL_SPI_CSRx_BITS(ATMEL_SPI_BITS_8);
+
+   if (!(priv->mode & SPI_CPHA))
+   csrx |= ATMEL_SPI_CSRx_NCPHA;
+   if (priv->mode & SPI_CPOL)
+   csrx |= ATMEL_SPI_CSRx_CPOL;
+
+   writel(csrx, _base->csr[cs]);
+
+   mode = ATMEL_SPI_MR_MSTR |
+  ATMEL_SPI_MR_MODFDIS |
+  ATMEL_SPI_MR_WDRBT |
+  ATMEL_SPI_MR_PCS(~(1 << cs));
+
+   writel(mode, _base->mr);
+
+   writel(ATMEL_SPI_CR_SPIEN, _base->cr);
+
+   return 0;
+}
+
+static int atmel_spi_release_bus(struct udevice *dev)
+{
+   struct udevice *bus = dev_get_parent(dev);
+   struct atmel_spi_platdata *bus_plat = dev_get_platdata(bus);
+
+   writel(ATMEL_SPI_CR_SPIDIS, _plat->regs->cr);
+
+   return 0;
+}
+
+static void atmel_spi_cs_activate(struct udevice *dev)
+{
+   struct udevice *bus = dev_get_parent(dev);
+   struct atmel_spi_priv *priv = dev_get_priv(bus);
+   struct dm_spi_slave_platdata *slave_plat = dev_get_parent_platdata(dev);
+   u32 cs = slave_plat->cs;
+
+   dm_gpio_set_value(>cs_gpios[cs], 0);
+}
+
+static void atmel_spi_cs_deactivate(struct udevice *dev)
+{
+   struct udevice *bus = dev_get_parent(dev);
+   struct atmel_spi_priv *priv = dev_get_priv(bus);
+   struct dm_spi_slave_platdata *slave_plat = dev_get_parent_platdata(dev);
+   u32 cs = slave_plat->cs;
+
+   dm_gpio_set_value(>cs_gpios[cs], 1);
+}
+
+static int atmel_spi_xfer(struct udevice *dev, unsigned int bitlen,
+ const void *dout, void *din, unsigned long flags)
+{
+   struct udevice *bus = dev_get_parent(dev);
+   struct atmel_spi_platdata *bus_plat = dev_get_platdata(bus);
+   struct at91_spi *reg_base = bus_plat->regs;
+
+   u32 len_tx, len_rx, len;
+   u32 status;
+   const u8 *txp = dout;
+   u8 *rxp = din;
+   u8 value;

Re: [U-Boot] [PATCH] drivers:usb:common:fsl-dt-fixup: Fix the dt for all type of usb controllers

[Sriram Dash]

>From: Marek Vasut [mailto:ma...@denx.de]
>On 06/20/2016 06:15 AM, Sriram Dash wrote:
>> Currently, U-boot doesn't allow to compile more than one type of USB
>> protocol simultaneously. Hence, EHCI and XHCI controllers cannot
>> co-exist and CONFIG_USB_MAX_CONTROLLER_COUNT macro represents count
>of
>> only one type of controller.
>
>This does not make sense, with DM we can support all sorts of controllers.
>

Ok. Will change the commit message description in v2.

>> For the Socs which have more than one type of controller e.g. EHCI and
>> XHCI, and the device tree has to support both of them, the macro
>> CONFIG_USB_MAX_CONTROLLER_COUNT will not work for fixing dt from u boot.
>>
>> So, instead of taking the hard coded number of controller from U boot,
>> count the total number of controller present in dt and then fix the dt
>> accordingly.
>>
>> Signed-off-by: Sriram Dash 
>> Signed-off-by: Rajesh Bhagat 
>> ---
>>  drivers/usb/common/fsl-dt-fixup.c | 27 ++-
>>  1 file changed, 26 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/common/fsl-dt-fixup.c
>> b/drivers/usb/common/fsl-dt-fixup.c
>> index 9c48852..1edf146 100644
>> --- a/drivers/usb/common/fsl-dt-fixup.c
>> +++ b/drivers/usb/common/fsl-dt-fixup.c
>> @@ -131,10 +131,29 @@ static int fdt_fixup_erratum(int *usb_erratum_off, void
>*blob,
>>  return 0;
>>  }
>>
>> +static int fdt_max_controller_count(void *blob) {
>> +int count = 0;
>> +int node_offset = -1;
>> +int i;
>> +
>> +for (i = 0; compat_usb_fsl[i]; i++) {
>> +do {
>> +node_offset = fdt_node_offset_by_compatible
>> +(blob, node_offset,
>> + compat_usb_fsl[i]);
>> +if (node_offset >= 0)
>> +count++;
>> +} while (node_offset != -FDT_ERR_NOTFOUND);
>> +}
>> +return count;
>> +}
>> +
>>  void fdt_fixup_dr_usb(void *blob, bd_t *bd)  {
>>  static const char * const modes[] = { "host", "peripheral", "otg" };
>>  static const char * const phys[] = { "ulpi", "utmi", "utmi_dual" };
>> +unsigned int usb_max_controller_count;
>>  int usb_erratum_a006261_off = -1;
>>  int usb_erratum_a007075_off = -1;
>>  int usb_erratum_a007792_off = -1;
>> @@ -146,7 +165,13 @@ void fdt_fixup_dr_usb(void *blob, bd_t *bd)
>>  int i, j;
>>  int ret;
>>
>> -for (i = 1; i <= CONFIG_USB_MAX_CONTROLLER_COUNT; i++) {
>> +usb_max_controller_count = fdt_max_controller_count(blob);
>
>Since you walk the tree below anyway, why do you even need to count the
>elements? Just walk the tree until you can find no more nodes.
>

Ok. Will traverse the dt and find the node. Then fix the node and afterwards,
Traverse the device tree till no nodes are left for fixing.

>> +if (!usb_max_controller_count) {
>> +printf("ERROR: FDT fixup erratum fail.\n");
>> +return;
>> +}
>> +
>> +for (i = 1; i <= usb_max_controller_count; i++) {
>>  const char *dr_mode_type = NULL;
>>  const char *dr_phy_type = NULL;
>>  int mode_idx = -1, phy_idx = -1;
>>
>
>
>--
>Best regards,
>Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v7 4/4] atmel: Bring in at91 pio4 device tree file and bindings

[Wenyou Yang]

Bring in required device tree file and bindings from Linux.

Signed-off-by: Wenyou Yang 
Reviewed-by: Andreas Bießmann 
Reviewed-by: Simon Glass 
---

Changes in v7:
 - Drop [PATCH]: configs: sama5d2_xplained: Add #ifndef before
   CONFIG_ATMEL_PIO4.

Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
 - add detailed example to show how to configure pinctrl for device.
 - remove interrupt and gpio property description.
 - add reviewed-by tag.

 arch/arm/dts/sama5d2-pinfunc.h | 880 +
 .../pinctrl/atmel,at91-pio4-pinctrl.txt|  66 ++
 2 files changed, 946 insertions(+)
 create mode 100644 arch/arm/dts/sama5d2-pinfunc.h
 create mode 100644 doc/device-tree-bindings/pinctrl/atmel,at91-pio4-pinctrl.txt

diff --git a/arch/arm/dts/sama5d2-pinfunc.h b/arch/arm/dts/sama5d2-pinfunc.h
new file mode 100644
index 000..b0c912f
--- /dev/null
+++ b/arch/arm/dts/sama5d2-pinfunc.h
@@ -0,0 +1,880 @@
+#define PINMUX_PIN(no, func, ioset) \
+(((no) & 0x) | (((func) & 0xf) << 16) | (((ioset) & 0xff) << 20))
+
+#define PIN_PA00
+#define PIN_PA0__GPIO  PINMUX_PIN(PIN_PA0, 0, 0)
+#define PIN_PA0__SDMMC0_CK PINMUX_PIN(PIN_PA0, 1, 1)
+#define PIN_PA0__QSPI0_SCK PINMUX_PIN(PIN_PA0, 2, 1)
+#define PIN_PA0__D0PINMUX_PIN(PIN_PA0, 6, 2)
+#define PIN_PA11
+#define PIN_PA1__GPIO  PINMUX_PIN(PIN_PA1, 0, 0)
+#define PIN_PA1__SDMMC0_CMDPINMUX_PIN(PIN_PA1, 1, 1)
+#define PIN_PA1__QSPI0_CS  PINMUX_PIN(PIN_PA1, 2, 1)
+#define PIN_PA1__D1PINMUX_PIN(PIN_PA1, 6, 2)
+#define PIN_PA22
+#define PIN_PA2__GPIO  PINMUX_PIN(PIN_PA2, 0, 0)
+#define PIN_PA2__SDMMC0_DAT0   PINMUX_PIN(PIN_PA2, 1, 1)
+#define PIN_PA2__QSPI0_IO0 PINMUX_PIN(PIN_PA2, 2, 1)
+#define PIN_PA2__D2PINMUX_PIN(PIN_PA2, 6, 2)
+#define PIN_PA33
+#define PIN_PA3__GPIO  PINMUX_PIN(PIN_PA3, 0, 0)
+#define PIN_PA3__SDMMC0_DAT1   PINMUX_PIN(PIN_PA3, 1, 1)
+#define PIN_PA3__QSPI0_IO1 PINMUX_PIN(PIN_PA3, 2, 1)
+#define PIN_PA3__D3PINMUX_PIN(PIN_PA3, 6, 2)
+#define PIN_PA44
+#define PIN_PA4__GPIO  PINMUX_PIN(PIN_PA4, 0, 0)
+#define PIN_PA4__SDMMC0_DAT2   PINMUX_PIN(PIN_PA4, 1, 1)
+#define PIN_PA4__QSPI0_IO2 PINMUX_PIN(PIN_PA4, 2, 1)
+#define PIN_PA4__D4PINMUX_PIN(PIN_PA4, 6, 2)
+#define PIN_PA55
+#define PIN_PA5__GPIO  PINMUX_PIN(PIN_PA5, 0, 0)
+#define PIN_PA5__SDMMC0_DAT3   PINMUX_PIN(PIN_PA5, 1, 1)
+#define PIN_PA5__QSPI0_IO3 PINMUX_PIN(PIN_PA5, 2, 1)
+#define PIN_PA5__D5PINMUX_PIN(PIN_PA5, 6, 2)
+#define PIN_PA66
+#define PIN_PA6__GPIO  PINMUX_PIN(PIN_PA6, 0, 0)
+#define PIN_PA6__SDMMC0_DAT4   PINMUX_PIN(PIN_PA6, 1, 1)
+#define PIN_PA6__QSPI1_SCK PINMUX_PIN(PIN_PA6, 2, 1)
+#define PIN_PA6__TIOA5 PINMUX_PIN(PIN_PA6, 4, 1)
+#define PIN_PA6__FLEXCOM2_IO0  PINMUX_PIN(PIN_PA6, 5, 1)
+#define PIN_PA6__D6PINMUX_PIN(PIN_PA6, 6, 2)
+#define PIN_PA77
+#define PIN_PA7__GPIO  PINMUX_PIN(PIN_PA7, 0, 0)
+#define PIN_PA7__SDMMC0_DAT5   PINMUX_PIN(PIN_PA7, 1, 1)
+#define PIN_PA7__QSPI1_IO0 PINMUX_PIN(PIN_PA7, 2, 1)
+#define PIN_PA7__TIOB5 PINMUX_PIN(PIN_PA7, 4, 1)
+#define PIN_PA7__FLEXCOM2_IO1  PINMUX_PIN(PIN_PA7, 5, 1)
+#define PIN_PA7__D7PINMUX_PIN(PIN_PA7, 6, 2)
+#define PIN_PA88
+#define PIN_PA8__GPIO  PINMUX_PIN(PIN_PA8, 0, 0)
+#define PIN_PA8__SDMMC0_DAT6   PINMUX_PIN(PIN_PA8, 1, 1)
+#define PIN_PA8__QSPI1_IO1 PINMUX_PIN(PIN_PA8, 2, 1)
+#define PIN_PA8__TCLK5 PINMUX_PIN(PIN_PA8, 4, 1)
+#define PIN_PA8__FLEXCOM2_IO2  PINMUX_PIN(PIN_PA8, 5, 1)
+#define PIN_PA8__NWE_NANDWEPINMUX_PIN(PIN_PA8, 6, 2)
+#define PIN_PA99
+#define PIN_PA9__GPIO  PINMUX_PIN(PIN_PA9, 0, 0)
+#define PIN_PA9__SDMMC0_DAT7   PINMUX_PIN(PIN_PA9, 1, 1)
+#define PIN_PA9__QSPI1_IO2 PINMUX_PIN(PIN_PA9, 2, 1)
+#define PIN_PA9__TIOA4 PINMUX_PIN(PIN_PA9, 4, 1)
+#define PIN_PA9__FLEXCOM2_IO3  PINMUX_PIN(PIN_PA9, 5, 1)
+#define PIN_PA9__NCS3  PINMUX_PIN(PIN_PA9, 6, 2)
+#define PIN_PA10   10
+#define PIN_PA10__GPIO PINMUX_PIN(PIN_PA10, 0, 0)
+#define PIN_PA10__SDMMC0_RSTN  

[U-Boot] [PATCH v7 2/4] gpio: atmel_pio4: Rework to support DM & DT

[Wenyou Yang]

Rework the driver to support driver model and device tree, and
support to regard the pio4 pinctrl device as a child of
atmel_pio4 device.

Signed-off-by: Wenyou Yang 
Reviewed-by: Simon Glass 
---

Changes in v7:
 - Change clk_client.h -> clk.h to adapt to clk API conversion.

Changes in v6:
 - Add Reviewed-by tag.
 - Fixed the return value, -EINVAL -> ret.

Changes in v5:
 - Update the clk API based on [PATCH] clk: convert API to match
   reset/mailbox fstyle (http://patchwork.ozlabs.org/patch/625342/).
 - Use clrbits_le32() to replace readl()/writel().
 - Fixed the return value, -ENODEV->-EINVAL.
 - Remove check on dev_get_parent() return.

Changes in v4:
 - Remove the redundant log print.

Changes in v3:
 - Add bind callback to support the pinctl device regarding as
   a child of atmel_pio4 device.
 - Add clock support.

Changes in v2: None

 drivers/gpio/Kconfig  |   2 +-
 drivers/gpio/atmel_pio4.c | 138 ++
 2 files changed, 117 insertions(+), 23 deletions(-)

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 73b862d..3332dab 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -30,7 +30,7 @@ config DWAPB_GPIO
 
 config ATMEL_PIO4
bool "ATMEL PIO4 driver"
-   depends on DM
+   depends on DM_GPIO
default n
help
  Say yes here to support the Atmel PIO4 driver.
diff --git a/drivers/gpio/atmel_pio4.c b/drivers/gpio/atmel_pio4.c
index 84e8cc5..7adea88 100644
--- a/drivers/gpio/atmel_pio4.c
+++ b/drivers/gpio/atmel_pio4.c
@@ -7,11 +7,17 @@
  * SPDX-License-Identifier:GPL-2.0+
  */
 #include 
+#include 
 #include 
+#include 
+#include 
 #include 
+#include 
 #include 
 #include 
 
+DECLARE_GLOBAL_DATA_PTR;
+
 static struct atmel_pio4_port *atmel_pio4_port_base(u32 port)
 {
struct atmel_pio4_port *base = NULL;
@@ -165,15 +171,37 @@ int atmel_pio4_get_pio_input(u32 port, u32 pin)
 }
 
 #ifdef CONFIG_DM_GPIO
+
+struct atmel_pioctrl_data {
+   u32 nbanks;
+};
+
+struct atmel_pio4_platdata {
+   struct atmel_pio4_port *reg_base;
+};
+
+static struct atmel_pio4_port *atmel_pio4_bank_base(struct udevice *dev,
+   u32 bank)
+{
+   struct atmel_pio4_platdata *plat = dev_get_platdata(dev);
+   struct atmel_pio4_port *port_base =
+   (struct atmel_pio4_port *)((u32)plat->reg_base +
+   ATMEL_PIO_BANK_OFFSET * bank);
+
+   return port_base;
+}
+
 static int atmel_pio4_direction_input(struct udevice *dev, unsigned offset)
 {
-   struct at91_port_platdata *plat = dev_get_platdata(dev);
-   struct atmel_pio4_port *port_base = (atmel_pio4_port *)plat->base_addr;
-   u32 mask = 0x01 << offset;
-   u32 reg = ATMEL_PIO_CFGR_FUNC_GPIO;
+   u32 bank = ATMEL_PIO_BANK(offset);
+   u32 line = ATMEL_PIO_LINE(offset);
+   struct atmel_pio4_port *port_base = atmel_pio4_bank_base(dev, bank);
+   u32 mask = BIT(line);
 
writel(mask, _base->mskr);
-   writel(reg, _base->cfgr);
+
+   clrbits_le32(_base->cfgr,
+ATMEL_PIO_CFGR_FUNC_MASK | ATMEL_PIO_DIR_MASK);
 
return 0;
 }
@@ -181,13 +209,15 @@ static int atmel_pio4_direction_input(struct udevice 
*dev, unsigned offset)
 static int atmel_pio4_direction_output(struct udevice *dev,
   unsigned offset, int value)
 {
-   struct at91_port_platdata *plat = dev_get_platdata(dev);
-   struct atmel_pio4_port *port_base = (atmel_pio4_port *)plat->base_addr;
-   u32 mask = 0x01 << offset;
-   u32 reg = ATMEL_PIO_CFGR_FUNC_GPIO | ATMEL_PIO_DIR_MASK;
+   u32 bank = ATMEL_PIO_BANK(offset);
+   u32 line = ATMEL_PIO_LINE(offset);
+   struct atmel_pio4_port *port_base = atmel_pio4_bank_base(dev, bank);
+   u32 mask = BIT(line);
 
writel(mask, _base->mskr);
-   writel(reg, _base->cfgr);
+
+   clrsetbits_le32(_base->cfgr,
+   ATMEL_PIO_CFGR_FUNC_MASK, ATMEL_PIO_DIR_MASK);
 
if (value)
writel(mask, _base->sodr);
@@ -199,9 +229,10 @@ static int atmel_pio4_direction_output(struct udevice *dev,
 
 static int atmel_pio4_get_value(struct udevice *dev, unsigned offset)
 {
-   struct at91_port_platdata *plat = dev_get_platdata(dev);
-   struct atmel_pio4_port *port_base = (atmel_pio4_port *)plat->base_addr;
-   u32 mask = 0x01 << offset;
+   u32 bank = ATMEL_PIO_BANK(offset);
+   u32 line = ATMEL_PIO_LINE(offset);
+   struct atmel_pio4_port *port_base = atmel_pio4_bank_base(dev, bank);
+   u32 mask = BIT(line);
 
return (readl(_base->pdsr) & mask) ? 1 : 0;
 }
@@ -209,9 +240,10 @@ static int atmel_pio4_get_value(struct udevice *dev, 
unsigned offset)
 static int atmel_pio4_set_value(struct udevice *dev,
unsigned offset, int value)
 {
-   struct at91_port_platdata *plat = 

[U-Boot] [PATCH v7 3/4] pinctrl: at91-pio4: Add pinctrl driver

[Wenyou Yang]

AT91 PIO4 controller is a combined gpio-controller, pin-mux and
pin-config module. The peripheral's pins are assigned through
per-pin based muxing logic.

The pin configuration is performed on specific registers which
are shared along with the gpio controller. So regard the pinctrl
device as a child of atmel_pio4 device.

Signed-off-by: Wenyou Yang 
Reviewed-by: Simon Glass 
---

Changes in v7: None
Changes in v6: None
Changes in v5:
 - Fixed the return value, -ENODEV->-EINVAL.
 - Remove check on dev_get_parent() return.

Changes in v4: None
Changes in v3:
 - Rework due to the pinctrl device is regarded as atmel_pio4
   device's child.

Changes in v2:
 - remove meaningless comment.
 - add else path for argument of pinconf.
 - add inline attribute for atmel_pio4_bank_base().
 - add handle if the pinmux entries is greater maximum value.

 drivers/pinctrl/Kconfig |   7 ++
 drivers/pinctrl/Makefile|   1 +
 drivers/pinctrl/pinctrl-at91-pio4.c | 182 
 3 files changed, 190 insertions(+)
 create mode 100644 drivers/pinctrl/pinctrl-at91-pio4.c

diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 1785e3b..01ce740 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -123,6 +123,13 @@ config QCA953X_PINCTRL
  both the GPIO definitions and pin control functions for each
  available multiplex function.
 
+config PINCTRL_AT91PIO4
+   bool "AT91 PIO4 pinctrl driver"
+   depends on DM
+   help
+ This option is to enable the AT91 pinctrl driver for AT91 PIO4
+ controller which is available on SAMA5D2 SoC.
+
 config ROCKCHIP_PINCTRL
bool "Rockchip pin control driver"
depends on DM
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index 7f94681..c92ab8c 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -5,6 +5,7 @@
 obj-y  += pinctrl-uclass.o
 obj-$(CONFIG_$(SPL_)PINCTRL_GENERIC)   += pinctrl-generic.o
 
+obj-$(CONFIG_PINCTRL_AT91PIO4) += pinctrl-at91-pio4.o
 obj-y  += nxp/
 obj-$(CONFIG_ARCH_ATH79) += ath79/
 obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip/
diff --git a/drivers/pinctrl/pinctrl-at91-pio4.c 
b/drivers/pinctrl/pinctrl-at91-pio4.c
new file mode 100644
index 000..6d4aadc
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-at91-pio4.c
@@ -0,0 +1,182 @@
+/*
+ * Atmel PIO4 pinctrl driver
+ *
+ * Copyright (C) 2016 Atmel Corporation
+ *   Wenyou.Yang 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/*
+ * Warning:
+ * In order to not introduce confusion between Atmel PIO groups and pinctrl
+ * framework groups, Atmel PIO groups will be called banks.
+ */
+
+struct atmel_pio4_platdata {
+   struct atmel_pio4_port *reg_base;
+};
+
+static const struct pinconf_param conf_params[] = {
+   { "bias-disable", PIN_CONFIG_BIAS_DISABLE, 0 },
+   { "bias-pull-up", PIN_CONFIG_BIAS_PULL_UP, 1 },
+   { "bias-pull-down", PIN_CONFIG_BIAS_PULL_DOWN, 1 },
+   { "drive-open-drain", PIN_CONFIG_DRIVE_OPEN_DRAIN, 0 },
+   { "input-schmitt-disable", PIN_CONFIG_INPUT_SCHMITT_ENABLE, 0 },
+   { "input-schmitt-enable", PIN_CONFIG_INPUT_SCHMITT_ENABLE, 1 },
+   { "input-debounce", PIN_CONFIG_INPUT_DEBOUNCE, 0 },
+};
+
+static u32 atmel_pinctrl_get_pinconf(const void *blob, int node)
+{
+   const struct pinconf_param *params;
+   u32 param, arg, conf = 0;
+   u32 i;
+
+   for (i = 0; i < ARRAY_SIZE(conf_params); i++) {
+   params = _params[i];
+   if (!fdt_get_property(blob, node, params->property, NULL))
+   continue;
+
+   param = params->param;
+   arg = params->default_value;
+
+   switch (param) {
+   case PIN_CONFIG_BIAS_DISABLE:
+   conf &= (~ATMEL_PIO_PUEN_MASK);
+   conf &= (~ATMEL_PIO_PDEN_MASK);
+   break;
+   case PIN_CONFIG_BIAS_PULL_UP:
+   conf |= ATMEL_PIO_PUEN_MASK;
+   break;
+   case PIN_CONFIG_BIAS_PULL_DOWN:
+   conf |= ATMEL_PIO_PDEN_MASK;
+   break;
+   case PIN_CONFIG_DRIVE_OPEN_DRAIN:
+   if (arg == 0)
+   conf &= (~ATMEL_PIO_OPD_MASK);
+   else
+   conf |= ATMEL_PIO_OPD_MASK;
+   break;
+   case PIN_CONFIG_INPUT_SCHMITT_ENABLE:
+   if (arg == 0)
+   conf |= ATMEL_PIO_SCHMITT_MASK;
+   else
+   conf &= (~ATMEL_PIO_SCHMITT_MASK);
+   break;
+ 

[U-Boot] [PATCH v7 1/4] gpio: atmel_pio4: Move PIO4 definitions to head file

[Wenyou Yang]

In order to make these PIO4 definitions shared with AT91 PIO4
pinctrl driver, move them from the existing gpio driver to the
head file, and rephrase them.

Signed-off-by: Wenyou Yang 
Reviewed-by: Simon Glass 
---

Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/mach-at91/include/mach/atmel_pio4.h | 35 ++
 drivers/gpio/atmel_pio4.c| 71 +++-
 2 files changed, 53 insertions(+), 53 deletions(-)

diff --git a/arch/arm/mach-at91/include/mach/atmel_pio4.h 
b/arch/arm/mach-at91/include/mach/atmel_pio4.h
index 8bb4b12..6760bec 100644
--- a/arch/arm/mach-at91/include/mach/atmel_pio4.h
+++ b/arch/arm/mach-at91/include/mach/atmel_pio4.h
@@ -29,6 +29,41 @@ struct atmel_pio4_port {
 
 #endif
 
+/*
+ * PIO Configuration Register Fields
+ */
+#define ATMEL_PIO_CFGR_FUNC_MASK   GENMASK(2, 0)
+#define ATMEL_PIO_CFGR_FUNC_GPIO   (0x0 << 0)
+#define ATMEL_PIO_CFGR_FUNC_PERIPH_A   (0x1 << 0)
+#define ATMEL_PIO_CFGR_FUNC_PERIPH_B   (0x2 << 0)
+#define ATMEL_PIO_CFGR_FUNC_PERIPH_C   (0x3 << 0)
+#define ATMEL_PIO_CFGR_FUNC_PERIPH_D   (0x4 << 0)
+#define ATMEL_PIO_CFGR_FUNC_PERIPH_E   (0x5 << 0)
+#define ATMEL_PIO_CFGR_FUNC_PERIPH_F   (0x6 << 0)
+#define ATMEL_PIO_CFGR_FUNC_PERIPH_G   (0x7 << 0)
+#define ATMEL_PIO_DIR_MASK BIT(8)
+#define ATMEL_PIO_PUEN_MASKBIT(9)
+#define ATMEL_PIO_PDEN_MASKBIT(10)
+#define ATMEL_PIO_IFEN_MASKBIT(12)
+#define ATMEL_PIO_IFSCEN_MASK  BIT(13)
+#define ATMEL_PIO_OPD_MASK BIT(14)
+#define ATMEL_PIO_SCHMITT_MASK BIT(15)
+#define ATMEL_PIO_CFGR_EVTSEL_MASK GENMASK(26, 24)
+#define ATMEL_PIO_CFGR_EVTSEL_FALLING  (0 << 24)
+#define ATMEL_PIO_CFGR_EVTSEL_RISING   (1 << 24)
+#define ATMEL_PIO_CFGR_EVTSEL_BOTH (2 << 24)
+#define ATMEL_PIO_CFGR_EVTSEL_LOW  (3 << 24)
+#define ATMEL_PIO_CFGR_EVTSEL_HIGH (4 << 24)
+
+#define ATMEL_PIO_NPINS_PER_BANK   32
+#define ATMEL_PIO_BANK(pin_id) (pin_id / ATMEL_PIO_NPINS_PER_BANK)
+#define ATMEL_PIO_LINE(pin_id) (pin_id % ATMEL_PIO_NPINS_PER_BANK)
+#define ATMEL_PIO_BANK_OFFSET  0x40
+
+#define ATMEL_GET_PIN_NO(pinfunc)  ((pinfunc) & 0xff)
+#define ATMEL_GET_PIN_FUNC(pinfunc)((pinfunc >> 16) & 0xf)
+#define ATMEL_GET_PIN_IOSET(pinfunc)   ((pinfunc >> 20) & 0xf)
+
 #define AT91_PIO_PORTA 0x0
 #define AT91_PIO_PORTB 0x1
 #define AT91_PIO_PORTC 0x2
diff --git a/drivers/gpio/atmel_pio4.c b/drivers/gpio/atmel_pio4.c
index d71f525..84e8cc5 100644
--- a/drivers/gpio/atmel_pio4.c
+++ b/drivers/gpio/atmel_pio4.c
@@ -12,41 +12,6 @@
 #include 
 #include 
 
-#define ATMEL_PIO4_PINS_PER_BANK   32
-
-/*
- * Register Field Definitions
- */
-#define ATMEL_PIO4_CFGR_FUNC   (0x7 << 0)
-#defineATMEL_PIO4_CFGR_FUNC_GPIO   (0x0 << 0)
-#defineATMEL_PIO4_CFGR_FUNC_PERIPH_A   (0x1 << 0)
-#defineATMEL_PIO4_CFGR_FUNC_PERIPH_B   (0x2 << 0)
-#defineATMEL_PIO4_CFGR_FUNC_PERIPH_C   (0x3 << 0)
-#defineATMEL_PIO4_CFGR_FUNC_PERIPH_D   (0x4 << 0)
-#defineATMEL_PIO4_CFGR_FUNC_PERIPH_E   (0x5 << 0)
-#defineATMEL_PIO4_CFGR_FUNC_PERIPH_F   (0x6 << 0)
-#defineATMEL_PIO4_CFGR_FUNC_PERIPH_G   (0x7 << 0)
-#define ATMEL_PIO4_CFGR_DIR(0x1 << 8)
-#define ATMEL_PIO4_CFGR_PUEN   (0x1 << 9)
-#define ATMEL_PIO4_CFGR_PDEN   (0x1 << 10)
-#define ATMEL_PIO4_CFGR_IFEN   (0x1 << 12)
-#define ATMEL_PIO4_CFGR_IFSCEN (0x1 << 13)
-#define ATMEL_PIO4_CFGR_OPD(0x1 << 14)
-#define ATMEL_PIO4_CFGR_SCHMITT(0x1 << 15)
-#define ATMEL_PIO4_CFGR_DRVSTR (0x3 << 16)
-#defineATMEL_PIO4_CFGR_DRVSTR_LOW0 (0x0 << 16)
-#defineATMEL_PIO4_CFGR_DRVSTR_LOW1 (0x1 << 16)
-#defineATMEL_PIO4_CFGR_DRVSTR_MEDIUM   (0x2 << 16)
-#defineATMEL_PIO4_CFGR_DRVSTR_HIGH (0x3 << 16)
-#define ATMEL_PIO4_CFGR_EVTSEL (0x7 << 24)
-#defineATMEL_PIO4_CFGR_EVTSEL_FALLING  (0x0 << 24)
-#defineATMEL_PIO4_CFGR_EVTSEL_RISING   (0x1 << 24)
-#defineATMEL_PIO4_CFGR_EVTSEL_BOTH (0x2 << 24)
-#defineATMEL_PIO4_CFGR_EVTSEL_LOW  (0x3 << 24)
-#defineATMEL_PIO4_CFGR_EVTSEL_HIGH (0x4 << 24)
-#define ATMEL_PIO4_CFGR_PCFS   (0x1 << 29)
-#define ATMEL_PIO4_CFGR_ICFS   (0x1 << 30)
-
 static struct atmel_pio4_port *atmel_pio4_port_base(u32 port)
 {
struct atmel_pio4_port *base = NULL;
@@ -79,7 +44,7 @@ static int atmel_pio4_config_io_func(u32 port, u32 pin,
struct atmel_pio4_port *port_base;
u32 reg, mask;
 
-   if (pin >= ATMEL_PIO4_PINS_PER_BANK)
+   if (pin >= ATMEL_PIO_NPINS_PER_BANK)
return -ENODEV;
 
port_base = atmel_pio4_port_base(port);
@@ -88,7 +53,7 @@ static int 

[U-Boot] [PATCH v7 0/4] ARM: AT91: Add AT91 PIO4 pinctrl driver and gpio driver with DM

[Wenyou Yang]

AT91 PIO4 controller is a combined gpio-controller, pin-mux and
pin-config module.

This patch is to add the pinctrl driver, and rework the atmel-pio4
gpio driver to support driver model and device tree.

Changes in v7:
 - Change clk_client.h -> clk.h to adapt to clk API conversion.
 - Drop [PATCH]: configs: sama5d2_xplained: Add #ifndef before
   CONFIG_ATMEL_PIO4.

Changes in v6:
 - Add Reviewed-by tag.
 - Fixed the return value, -EINVAL -> ret.

Changes in v5:
 - Update the clk API based on [PATCH] clk: convert API to match
   reset/mailbox fstyle (http://patchwork.ozlabs.org/patch/625342/).
 - Use clrbits_le32() to replace readl()/writel().
 - Fixed the return value, -ENODEV->-EINVAL.
 - Remove check on dev_get_parent() return.
 - Fixed the return value, -ENODEV->-EINVAL.
 - Remove check on dev_get_parent() return.

Changes in v4:
 - Remove the redundant log print.

Changes in v3:
 - Add bind callback to support the pinctl device regarding as
   a child of atmel_pio4 device.
 - Add clock support.
 - Rework due to the pinctrl device is regarded as atmel_pio4
   device's child.

Changes in v2:
 - remove meaningless comment.
 - add else path for argument of pinconf.
 - add inline attribute for atmel_pio4_bank_base().
 - add handle if the pinmux entries is greater maximum value.
 - add detailed example to show how to configure pinctrl for device.
 - remove interrupt and gpio property description.
 - add reviewed-by tag.

Wenyou Yang (4):
  gpio: atmel_pio4: Move PIO4 definitions to head file
  gpio: atmel_pio4: Rework to support DM & DT
  pinctrl: at91-pio4: Add pinctrl driver
  atmel: Bring in at91 pio4 device tree file and bindings

 arch/arm/dts/sama5d2-pinfunc.h | 880 +
 arch/arm/mach-at91/include/mach/atmel_pio4.h   |  35 +
 .../pinctrl/atmel,at91-pio4-pinctrl.txt|  66 ++
 drivers/gpio/Kconfig   |   2 +-
 drivers/gpio/atmel_pio4.c  | 201 +++--
 drivers/pinctrl/Kconfig|   7 +
 drivers/pinctrl/Makefile   |   1 +
 drivers/pinctrl/pinctrl-at91-pio4.c| 182 +
 8 files changed, 1302 insertions(+), 72 deletions(-)
 create mode 100644 arch/arm/dts/sama5d2-pinfunc.h
 create mode 100644 doc/device-tree-bindings/pinctrl/atmel,at91-pio4-pinctrl.txt
 create mode 100644 drivers/pinctrl/pinctrl-at91-pio4.c

-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Please pull u-boot-cfi-flash/master

[Stefan Roese]

Hi Tom,

please pull the following patch:

The following changes since commit 9fcf809c1e3ff644b12e04e625d3737ffd8e:

  Merge git://git.denx.de/u-boot-fsl-qoriq (2016-07-19 16:38:57 -0400)

are available in the git repository at:

  git://www.denx.de/git/u-boot-cfi-flash.git 

for you to fetch changes up to 55edb9d4d521ff733d217ddf47ad7bf4650676be:

  mtd: cfi_flash: fix polling for bit XSR.7 on Intel chips (2016-07-20 11:13:26 
+0200)


Daniel Schwierzeck (1):
  mtd: cfi_flash: fix polling for bit XSR.7 on Intel chips

 drivers/mtd/cfi_flash.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] mtd: cfi_flash: fix polling for bit XSR.7 on Intel chips

[Stefan Roese]

Hi Daniel,

On 18.07.2016 14:10, Daniel Schwierzeck wrote:

flash_full_status_check() checks bit XSR.7 on Intel chips. This
should be done by only checking bit 7 and not by comparing the
whole status byte or word with 0x80.

This fixes the non-working block erase in the pflash emulation
of Qemu when used with the MIPS Malta board. MIPS Malta uses x32
mode to access the pflash device. In x32 mode Qemu mirrors the
lower 16 bits of the status word into the upper 16 bits. Thus
the CFI driver gets a status word of 0x8080 in x32 mode. If
flash_full_status_check() uses flash_isequal(), then it polls for
XSR.7 by comparing 0x8080 with 0x80 which never becomes true.

Reported-by: Alon Bar-Lev 
Signed-off-by: Daniel Schwierzeck 


Applied to u-boot-cfi-flash/master.

Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] u-boot: x86: interrupt mapping

[Jian Luo]

Hi Christian,

On 20.07.2016 10:22, Christian Gmeiner wrote:

Hi Jian,


I took some time to recall what I did by patching FSP:

- search in every PE32 and TE image section for binary sequence
81c900018908c6460e01
and change to
81c9000102008908c6460e00


In the meantime I started by patching out every access to the uart bar, with
the same result as I get with your patching strategy.


- then replace them in-place


So here is the next interesting problem. During fsp_init it looks like
fsp copies itself
to ram (IP 0xFFFD1C6C vs 0x3F5F64E1) and here it does a busy loop :(

I don't think it's a busy loop. This Bug?:
https://patchwork.ozlabs.org/patch/446555/



At what place do you do the in-place patching? I hoped to do it at
init_board setup.
I mean in UEFITool select the "PE32 image section", right click "Extract 
body", do binary patching using your favorite hex editor, right click 
"Replace body".

The difference can be better understand if disassemblies are compared, eg:
  Disassembly of section .data:
@@ -3367,9 +3367,9 @@
  25fc:05 00 05 00 00   add$0x500,%eax
  2601:8b 08mov(%eax),%ecx
  2603:81 e1 ff ff f8 ffand$0xfff8,%ecx
-2609:81 c9 00 01 00 00or $0x100,%ecx
+2609:81 c9 00 01 02 00or $0x20100,%ecx
What I did here is setting BAUDSEL to SYS_25MHz.

  260f:89 08mov%ecx,(%eax)
-2611:c6 46 0e 01  movb   $0x1,0xe(%esi)
+2611:c6 46 0e 00  movb   $0x0,0xe(%esi)
Can't recall why I did this, maybe bypassing PLL altogether?

  2615:c6 46 0f 00  movb   $0x0,0xf(%esi)
  2619:c6 46 03 83  movb   $0x83,0x3(%esi)
  261d:c6 46 01 00  movb   $0x0,0x1(%esi)

Since I don't rely on Topcliff UART for output, the baud rate recalculation
is all skipped.


The same here... I am using a pci fpga based uart.

Maybe you can try the fsp.bin I sent, to see if it runs


Since it's a bit off-topic, should we exchange information w/o ccing the 
list?


Best regards,

*Jian Luo
DC-IA/EAH2*

Tel.  +49(9352)18-4266

*Be**QIK
*


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] what is the *recommended* split between defconfig file and header file?

[Robert P. J. Day]

On Tue, 19 Jul 2016, Tom Rini wrote:

> On Tue, Jul 19, 2016 at 04:15:47AM -0400, Robert P. J. Day wrote:
>
> >
> >   kind of a style question but what is the preferred way to define a
> > board in the sense of what belongs in the defconfig file and what
> > belongs in the header file?
>
> The header files will eventually go away.  Most of the contents are
> things that could be, but haven't yet been, converted.  A few things
> like default environment are going to be harder to figure out.

  and what about the advantage of header files that allow the
inclusion of other header files to reduce duplication? will config
files be extended to allow the same thing? (they don't do that now, do
they?)

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Revert "T2080QDS/PCIe: Soft Reset PCIe on T2080QDS for down-training issue"

[Qiang Zhao]

On 07/20/2016 06:05 PM, York Sun wrote:
> -Original Message-
> From: york sun
> Sent: Wednesday, July 20, 2016 6:05 AM
> To: Qiang Zhao 
> Cc: Xiaobo Xie ; u-boot@lists.denx.de; Roy Zang
> 
> Subject: Re: [PATCH] Revert "T2080QDS/PCIe: Soft Reset PCIe on T2080QDS for
> down-training issue"
> 
> On 04/20/2016 06:12 PM, York Sun wrote:
> > +Roy to comment on iNIC.
> >
> > On 04/20/2016 06:05 PM, Qiang Zhao wrote:
> >> On 04/21/2016 12:58 AM, York Sun wrote:
> >>> -Original Message-
> >>> From: York Sun [mailto:york@nxp.com]
> >>> Sent: Thursday, April 21, 2016 12:58 AM
> >>> To: Qiang Zhao 
> >>> Cc: Xiaobo Xie ; u-boot@lists.denx.de
> >>> Subject: Re: [PATCH] Revert "T2080QDS/PCIe: Soft Reset PCIe on
> >>> T2080QDS for down-training issue"
> >>>
> >>> On 04/11/2016 02:02 AM, Zhao Qiang wrote:
>  This reverts commit 5066e62847bddf6030262ade2aa3e7bcdc930037.
> 
>  The reverted patch will block t2080RDB iNiC, it was a workaround
>  for T2080QDS down-training issue, we need to revert it and find the
>  root cause for T2080QDS down-training issue.
> >>>
> >>> You have a bad wrap-back in commit message.
> >>>
> >>> Does the workaround block anything? Can you revert it after figuring
> >>> out the root cause?
> >>>
> >>
> >> Yes, it blocks t2080RDB and c29x when using them as iNIC.
> >> If revert it after figuring out the root cause, how about iNIC?
> >> And I am afraid of it is a hard way to find the root cause.
> >>
> >
> > Qiang,
> >
> > You delete the code gated by CONFIG_FSL_PCIE_RESET, and the macro for
> T208xQDS.
> > How does that affect T2080RDB or C29x?
> >
> 
> Qiang,
> 
> Do you have an update? If not, I will defer this patch.
> 

There is no any update.

-Zhao Qiang
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] u-boot: x86: interrupt mapping

[Christian Gmeiner]

Hi Jian,

>
> I took some time to recall what I did by patching FSP:
>
> - search in every PE32 and TE image section for binary sequence
> 81c900018908c6460e01
> and change to
> 81c9000102008908c6460e00
>

In the meantime I started by patching out every access to the uart bar, with
the same result as I get with your patching strategy.

> - then replace them in-place
>

So here is the next interesting problem. During fsp_init it looks like
fsp copies itself
to ram (IP 0xFFFD1C6C vs 0x3F5F64E1) and here it does a busy loop :(

At what place do you do the in-place patching? I hoped to do it at
init_board setup.

> The difference can be better understand if disassemblies are compared, eg:
>  Disassembly of section .data:
> @@ -3367,9 +3367,9 @@
>  25fc:05 00 05 00 00   add$0x500,%eax
>  2601:8b 08mov(%eax),%ecx
>  2603:81 e1 ff ff f8 ffand$0xfff8,%ecx
> -2609:81 c9 00 01 00 00or $0x100,%ecx
> +2609:81 c9 00 01 02 00or $0x20100,%ecx
> What I did here is setting BAUDSEL to SYS_25MHz.
>
>  260f:89 08mov%ecx,(%eax)
> -2611:c6 46 0e 01  movb   $0x1,0xe(%esi)
> +2611:c6 46 0e 00  movb   $0x0,0xe(%esi)
> Can't recall why I did this, maybe bypassing PLL altogether?
>
>  2615:c6 46 0f 00  movb   $0x0,0xf(%esi)
>  2619:c6 46 03 83  movb   $0x83,0x3(%esi)
>  261d:c6 46 01 00  movb   $0x0,0x1(%esi)
>
> Since I don't rely on Topcliff UART for output, the baud rate recalculation
> is all skipped.
>

The same here... I am using a pci fpga based uart.

> Best regards,
>
> *Jian Luo
> DC-IA/EAH2*
>
> Tel.  +49(9352)18-4266
>
> *Be**QIK
> *
>
>
> On 19.07.2016 17:21, Christian Gmeiner wrote:
>>
>> Hi Jian,
>>
>>> For the moment I have no answer to this question. I need to dive into
>>> the vxworks code, which
>>> is not what I like to do now (but needs to be done)-
>>>
>>> Yes, please do track it down. The interrupt line register configured
>>> by U-Boot should be enough for VxWorks to function under PIC mode.
>>>
>>> I have an other (wired) question you may could help out.
>>>
>>>
>>> http://www.mouser.com/pdfdocs/Intel_Platform_Controller_Hub_EG20T_datasheet.pdf
>>> (page 124)
>>>
>>> On my development board the uart_clk is connected to a oscillator and
>>> everything works as expected.
>>> But on the production devices the uart_clk is not connected and fsp
>>> hangs with post code 0x2e.
>>>
>>> I am not sure about the meaning of post code 0x2e. Jian has some
>>> working experience on Atom E6xx with U-Boot. Adding him.
>>>
>>> 0x2e == POST_PRE_MRC (arch/x86/include/asm/post.h)
>>>
>>> Now I would like to change the initial mux settings to use usb_48mhz
>>> but I am quite sure that I need
>>> to have the pci bus and its devices initialised already in order to
>>> change the CLKCFG register. Do you
>>> think there is an other way of accessing this register like fixed
>>> memory address etc?
>>>
>>> Which register do you want to program for this uart_clk? If it's on
>>> the PCI configuration space, you can use PCI config APIs to program.
>>>
>>> There a handful of registers I would need to program but all of them are
>>> accessible via pic config space. E.g CLKCFG:
>>>
>>> Size: 32-bit Default: 2C00 Power Well: Core
>>> Access PCI Configuration B:D:F D0:F0 Offset Start: Offset End: 500h 503h
>>>  Memory Mapped I/O BAR: PKTHubCTLBASE Offset: 500h
>>>
>>>
>>> As I need to program those registers before fsp_init I must setup the pci
>>> bus by myself, change the register values and call fsb_init routine.
>>> Correct?
>>>
>>> My board had this problem too. I however toke a different approach
>>> by patching the original FSP. The waiting for Topcliff UART ready is
>>> completely
>>> bypassed in all UEFI blobs. You can use UEFITool [1] to extract blobs in
>>> the attached FSP for comparison.
>>>
>> Sooo... I did use the UEFITool to compare your fsp with mine and yeah...
>> some files are different.
>>
>> File_Raw_06A70056_3D0F_4A94_A743_5491CC9391D3_body.bin
>>
>> Section_PE32_image_47EA2673_2533_4C07_AABA_69CE5A7C5D35_PlatformLateInit_body.bin
>>
>> Section_PE32_image_47EA2673_2533_4C07_AABA_69CE5A7C5D35_PlatformLateInit_header.bin
>> Section_PE32_image_4D1F48D8_0498_4C09_8EDE_72F30B58B1F2_MpInit_body.bin
>> Section_PE32_image_74D3B506_EE9C_47ED_B749_41261401DA78_TCInitDxe_body.bin
>>
>> Section_TE_image_1BA0062E_C779_4582_8566_336AE8F78F09_Volume_Top_File_body.bin
>> Section_TE_image_52C05B14_0B98_496C_BC3B_04B50211D680_PeiCore_body.bin
>> Section_TE_image_86D70125_BAA3_4296_A62F_602BEBBB9081_DxeIpl_body.bin
>>
>> Section_TE_image_9618C0DC_50A4_496C_994F_7241F282ED01_PlatformEarlyInit_body.bin
>> Section_TE_image_9B3ADA4F_AE56_4C24_8DEA_F03B7558AE50_PcdPeim_body.bin
>>
>> Section_TE_image_D2C69B26_82E1_4A1B_AD35_ED0261B9F347_MemoryInitPei_body.bin
>>
>> 

Re: [U-Boot] [PATCH v3] nitrogen6x : Use generic distro configuration

[Fabien Lahoudere]

Hi Stefano,

Thank you for your comments.

On 13/07/2016 16:28, Stefano Babic wrote:

Hi Fabien,

On 29/06/2016 09:05, Fabien Lahoudere wrote:

In order to simplify the use of various images on various media
for nitrogen6x, the configuration of the board must follow the
generic distro configuration (doc/README.distro).

In order to boot your old rootfs, move your kernel and your device
tree in /boot/. Then create /boot/extlinux/extlinux.conf with for
example:

default Buildroot

label Buildroot
kernel /boot/zImage
append console=ttymxc1,115200 root=/dev/mmcblk0p1 rootwait rw
fdtdir /boot

Signed-off-by: Fabien Lahoudere 
---
Changes for V2:
- reintegration of deleted env
- changes are applied only if CONFIG_DISTRO_DEFAULTS=y

Changes for V3:
- remove undefined device tree

  configs/mx6qsabrelite_defconfig |  1 +
  configs/nitrogen6dl2g_defconfig |  1 +
  configs/nitrogen6dl_defconfig   |  1 +
  configs/nitrogen6q2g_defconfig  |  1 +
  configs/nitrogen6q_defconfig|  1 +
  configs/nitrogen6s1g_defconfig  |  1 +
  configs/nitrogen6s_defconfig|  1 +
  doc/README.imx6 | 47 +
  include/configs/mx6_common.h| 24 +
  include/configs/nitrogen6x.h| 36 +--
  10 files changed, 108 insertions(+), 6 deletions(-)

diff --git a/configs/mx6qsabrelite_defconfig b/configs/mx6qsabrelite_defconfig
index fa6139a..27b64c4 100644
--- a/configs/mx6qsabrelite_defconfig
+++ b/configs/mx6qsabrelite_defconfig
@@ -36,3 +36,4 @@ CONFIG_G_DNL_MANUFACTURER="Boundary"
  CONFIG_G_DNL_VENDOR_NUM=0x0525
  CONFIG_G_DNL_PRODUCT_NUM=0xa4a5
  CONFIG_OF_LIBFDT=y
+CONFIG_DISTRO_DEFAULTS=y
\ No newline at end of file
diff --git a/configs/nitrogen6dl2g_defconfig b/configs/nitrogen6dl2g_defconfig
index 02b2462..b1344c6 100644
--- a/configs/nitrogen6dl2g_defconfig
+++ b/configs/nitrogen6dl2g_defconfig
@@ -34,3 +34,4 @@ CONFIG_G_DNL_MANUFACTURER="Boundary"
  CONFIG_G_DNL_VENDOR_NUM=0x0525
  CONFIG_G_DNL_PRODUCT_NUM=0xa4a5
  CONFIG_OF_LIBFDT=y
+CONFIG_DISTRO_DEFAULTS=y
\ No newline at end of file
diff --git a/configs/nitrogen6dl_defconfig b/configs/nitrogen6dl_defconfig
index 52553f6..f794c08 100644
--- a/configs/nitrogen6dl_defconfig
+++ b/configs/nitrogen6dl_defconfig
@@ -34,3 +34,4 @@ CONFIG_G_DNL_MANUFACTURER="Boundary"
  CONFIG_G_DNL_VENDOR_NUM=0x0525
  CONFIG_G_DNL_PRODUCT_NUM=0xa4a5
  CONFIG_OF_LIBFDT=y
+CONFIG_DISTRO_DEFAULTS=y
\ No newline at end of file
diff --git a/configs/nitrogen6q2g_defconfig b/configs/nitrogen6q2g_defconfig
index 11188b7..56cebe0 100644
--- a/configs/nitrogen6q2g_defconfig
+++ b/configs/nitrogen6q2g_defconfig
@@ -34,3 +34,4 @@ CONFIG_G_DNL_MANUFACTURER="Boundary"
  CONFIG_G_DNL_VENDOR_NUM=0x0525
  CONFIG_G_DNL_PRODUCT_NUM=0xa4a5
  CONFIG_OF_LIBFDT=y
+CONFIG_DISTRO_DEFAULTS=y
\ No newline at end of file
diff --git a/configs/nitrogen6q_defconfig b/configs/nitrogen6q_defconfig
index 05bf140..c150b97 100644
--- a/configs/nitrogen6q_defconfig
+++ b/configs/nitrogen6q_defconfig
@@ -34,3 +34,4 @@ CONFIG_G_DNL_MANUFACTURER="Boundary"
  CONFIG_G_DNL_VENDOR_NUM=0x0525
  CONFIG_G_DNL_PRODUCT_NUM=0xa4a5
  CONFIG_OF_LIBFDT=y
+CONFIG_DISTRO_DEFAULTS=y
\ No newline at end of file
diff --git a/configs/nitrogen6s1g_defconfig b/configs/nitrogen6s1g_defconfig
index bb081a2..dfd096d 100644
--- a/configs/nitrogen6s1g_defconfig
+++ b/configs/nitrogen6s1g_defconfig
@@ -34,3 +34,4 @@ CONFIG_G_DNL_MANUFACTURER="Boundary"
  CONFIG_G_DNL_VENDOR_NUM=0x0525
  CONFIG_G_DNL_PRODUCT_NUM=0xa4a5
  CONFIG_OF_LIBFDT=y
+CONFIG_DISTRO_DEFAULTS=y
\ No newline at end of file
diff --git a/configs/nitrogen6s_defconfig b/configs/nitrogen6s_defconfig
index 08e91c9..5e2e693 100644
--- a/configs/nitrogen6s_defconfig
+++ b/configs/nitrogen6s_defconfig
@@ -34,3 +34,4 @@ CONFIG_G_DNL_MANUFACTURER="Boundary"
  CONFIG_G_DNL_VENDOR_NUM=0x0525
  CONFIG_G_DNL_PRODUCT_NUM=0xa4a5
  CONFIG_OF_LIBFDT=y
+CONFIG_DISTRO_DEFAULTS=y
\ No newline at end of file
diff --git a/doc/README.imx6 b/doc/README.imx6
index 1823fb2..36452f6 100644
--- a/doc/README.imx6
+++ b/doc/README.imx6
@@ -138,3 +138,50 @@ c
  The last "c" command tells kermit (from ckermit package in most distros)
  to switch from command line mode to communication mode, and when the
  script is finished, the U-Boot prompt is shown in the same shell.
+
+3. Using generic distro configuration
+-
+
+In order to simplify the use of various images on various media
+for imx6 boards, the configuration of the board must follow the
+generic distro configuration (doc/README.distro).
+
+3.1. Setup uboot configuration for your board
+-
+
+First, you have to set 'CONFIG_DISTRO_DEFAULTS=y' in your board defconfig
+
+Some mandatory variable are set in mx6_common.h but can be overwritten like:
+  - fdtfile with CONFIG_FDTFILE
+  - fdt_addr_r and 

Re: [U-Boot] [PATCH] arch-mx6: fix MX6_PAD_DECLARE macro to work with MX6 duallite

[Stefano Babic]

Hi Hannes,

this patch breaks most i.MX6 boards (the not DL) and I revert it. Maybe
I had to ask better before, anyway:

On 22/06/2016 12:07, Hannes Schmelzer wrote:
> if we build for an i.mx6 (d)ual(l)ite CONFIC_MX6DL we shall use
> MX6DL_PAD instead the common MX6_PAD.
> 
> Signed-off-by: Hannes Schmelzer 
> ---
> 
>  arch/arm/include/asm/arch-mx6/mx6-pins.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/include/asm/arch-mx6/mx6-pins.h 
> b/arch/arm/include/asm/arch-mx6/mx6-pins.h
> index 4b6bb18..3465205 100644
> --- a/arch/arm/include/asm/arch-mx6/mx6-pins.h
> +++ b/arch/arm/include/asm/arch-mx6/mx6-pins.h
> @@ -18,7 +18,7 @@ enum {
>  #include "mx6q_pins.h"
>  #undef MX6_PAD_DECL
>  #define MX6_PAD_DECL(name, pco, mc, mm, sio, si, pc) \
> - MX6_PAD_DECLARE(MX6DL_PAD_,name, pco, mc, mm, sio, si, pc),
> + MX6_PAD_DECLARE(MX6DL_PAD_, name, pco, mc, mm, sio, si, pc),
>  #include "mx6dl_pins.h"
>  };
>  #elif defined(CONFIG_MX6Q)
> @@ -30,7 +30,7 @@ enum {
>  #elif defined(CONFIG_MX6DL) || defined(CONFIG_MX6S)
>  enum {
>  #define MX6_PAD_DECL(name, pco, mc, mm, sio, si, pc) \
> - MX6_PAD_DECLARE(MX6_PAD_,name, pco, mc, mm, sio, si, pc),
> + MX6_PAD_DECLARE(MX6DL_PAD_, name, pco, mc, mm, sio, si, pc),
>  #include "mx6dl_pins.h"
>  };

Can you better explain the problem you had ? The name is not decisive -
the important thing is that the correct include file with the right
layout is included, that means mx6dl_pins.h. And this was mainlined
since a lot of time.

We have several boards with 6DL into mainline, so I am missing which is
your problem.

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3] driver: spi: fsl-qspi: disable AHB buffer prefetch

[Yunhui Cui]

On Tuesday, July 12, 2016 11:06 AM Prabhakar Wrote
> 
> > -Original Message-
> > From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Yunhui
> > Cui
> > Sent: Tuesday, July 12, 2016 8:20 AM
> > To: york sun 
> > Cc: Yunhui Cui ; u-boot@lists.denx.de
> > Subject: [U-Boot] [PATCH v3] driver: spi: fsl-qspi: disable AHB buffer
> > prefetch
> >
> > From: Yunhui Cui 
> >
> > Errata: A-009282: QuadSPI data pre-fetch can result in incorrect data
> > We need this errata workaround when CONFIG_SYS_FSL_QSPI_AHB is enabled.
> >
> 
> Can we add slightly more details about workaround other than Just
> enabling CONFIG_SYS_FSL_QSPI_AHB.
> With this you can avoid details of workaround in code.
> 
[Yunhui] ok!

> Please add CONFIG_SYS_FSL_QSPI_AHB in README file

[Yunhui] why should we add it and how to add it ?

> 
> > Signed-off-by: Yunhui Cui 
> > ---
> 
> Patch revision history missing.
> 
> --prabhakar

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A with QSPI enabled

[Qianyu Gong]

Hi York,

> -Original Message-
> From: york sun
> Sent: Wednesday, July 20, 2016 5:58 AM
> To: Scott Wood ; Qianyu Gong ; u-
> b...@lists.denx.de
> Cc: Mingkai Hu 
> Subject: Re: [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A with QSPI
> enabled
> 
> On 03/30/2016 07:39 PM, Scott Wood wrote:
> > On Wed, 2016-03-30 at 06:20 +, Qianyu Gong wrote:
> 
> 
> 
> >>
> >> Because this muxing can't be changed at runtime.
> >> Two ways so far to configure it:
> >> 1. SW6[1-4] switches on ls1043aqds board.
> >> 2. Modify QIXIS board config registers and reset the board.
> >
> > These sound like runtime to me -- not compile time.
> >
> 
> Qianyu,
> 
> If one can change mux by either changing switches, or setting QIXIS 
> registers, you
> should be able to read those status and run the fixup, agree?
> 
> York

Yes, we could read QIXIS registers at runtime. But the current argument is that 
if we need to
build two rcw images to support IFC or QSPI, which is already done on 
LS1021AQDS
and LS1043AQDS. This is made at compile time and I just have no idea to solve 
the rcw issue.
So.. how do you think about it?


Regards,
Qianyu
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2] common: fit: Allow U-Boot images to be booted

[Mario Six]

In certain circumstances it comes in handy to be able to boot into a second
U-Boot. But as of now it is not possible to boot a U-Boot binary that is inside
a FIT image, which is problematic for projects that e.g. need to guarantee a
unbroken chain of trust from SOC all the way into the OS, since the FIT signing
mechanism cannot be used.

This patch adds the capability to load such FIT images.

An example .its snippet (utilizing signature verification) might look
like the following:

images {
firmware@1 {
description = "2nd stage U-Boot image";
data = /incbin/("u-boot-dtb.img.gz");
type = "firmware";
arch = "arm";
os = "u-boot";
compression = "gzip";
load = <0x8FFFC0>;
entry = <0x90>;
signature@1 {
algo = "sha256,rsa4096";
key-name-hint = "key";
};
};
};

Signed-off-by: Mario Six 
---

Changes in v2:
 - Use images of type 'firmware' for U-Boot images (as per Wolfgang Denk's
   hint), and make them bootable

---
 common/image-fit.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/common/image-fit.c b/common/image-fit.c
index 6f920da..73ad34e 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -1684,12 +1684,13 @@ int fit_image_load(bootm_headers_t *images, ulong addr,

bootstage_mark(bootstage_id + BOOTSTAGE_SUB_CHECK_ALL);
type_ok = fit_image_check_type(fit, noffset, image_type) ||
-   (image_type == IH_TYPE_KERNEL &&
-   fit_image_check_type(fit, noffset,
-IH_TYPE_KERNEL_NOLOAD));
+ fit_image_check_type(fit, noffset, IH_TYPE_FIRMWARE) ||
+ (image_type == IH_TYPE_KERNEL &&
+  fit_image_check_type(fit, noffset, IH_TYPE_KERNEL_NOLOAD));

os_ok = image_type == IH_TYPE_FLATDT || IH_TYPE_FPGA ||
fit_image_check_os(fit, noffset, IH_OS_LINUX) ||
+   fit_image_check_os(fit, noffset, IH_OS_U_BOOT) ||
fit_image_check_os(fit, noffset, IH_OS_OPENRTOS);

/*
--
2.9.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v1 0/6] Convert FSL LayerScape ARMv8 SoCs to use common MMU code

[york sun]

On 06/24/2016 04:46 PM, York Sun wrote:
> To use common MMU code, non-identical mapping needs to be supported.
> Minior change in the MMU framework is required to support splitting
> blocks. With these changes, using common code is straight forward.
> Attention is needed where the tables are for early boot, secure and
> non-secure ram situations.
>
>
> York Sun (6):
>   armv8: Move secure_ram variable out of generic global data
>   armv8: Add tlb_allocated to arch global data
>   armv8: mmu: house cleaning
>   armv8: mmu: split block if necessary
>   armv8: mmu: Add support of non-identical mapping
>   armv8: layerscape: Convert to use common MMU framework

This set is applied to fsl-qoriq master. Awaiting upstream.

York


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] usb: Kconfig: Add Kconfigs entry USB_EHCI_ZYNQ

[Michal Simek]

On 20.7.2016 03:38, Marek Vasut wrote:
> On 07/19/2016 07:11 AM, Siva Durga Prasad Paladugu wrote:
>> Add Kconfig entry config option for USB_EHCI_ZYNQ
>> and update the same to enable for all zynq boards
>> which supports USB
>>
>> Signed-off-by: Siva Durga Prasad Paladugu 
> 
> Looks ok, except for a bit below. Michal, please double-check.

Sure.


>> ---
>> - This series is based on latest mainline
>> Changes for v2:
>> - Moved CONFIG_USB_EHCI_ZYNQ to Kconfig and removed
>>   config ZYNQ_USB as per review comment
>> ---
>>  configs/zynq_microzed_defconfig | 3 +++
>>  configs/zynq_picozed_defconfig  | 3 +++
>>  configs/zynq_zc702_defconfig| 3 +++
>>  configs/zynq_zc706_defconfig| 3 +++
>>  configs/zynq_zed_defconfig  | 3 +++
>>  configs/zynq_zybo_defconfig | 3 +++
>>  drivers/usb/host/Kconfig| 7 +++
>>  include/configs/zynq-common.h   | 4 +---
>>  include/configs/zynq_microzed.h | 2 --
>>  include/configs/zynq_picozed.h  | 2 --
>>  include/configs/zynq_zc70x.h| 1 -
>>  include/configs/zynq_zed.h  | 2 --
>>  include/configs/zynq_zybo.h | 1 -
>>  13 files changed, 26 insertions(+), 11 deletions(-)
>>
>> diff --git a/configs/zynq_microzed_defconfig 
>> b/configs/zynq_microzed_defconfig
>> index d88c61b..91d5c82 100644
>> --- a/configs/zynq_microzed_defconfig
>> +++ b/configs/zynq_microzed_defconfig
>> @@ -38,6 +38,9 @@ CONFIG_SPI_FLASH_WINBOND=y
>>  CONFIG_ZYNQ_GEM=y
>>  CONFIG_ZYNQ_QSPI=y
>>  CONFIG_USB=y
>> +CONFIG_USB_EHCI_HCD=y
>> +CONFIG_USB_EHCI=y
>> +CONFIG_USB_EHCI_ZYNQ=y
>>  CONFIG_USB_ULPI_VIEWPORT=y
>>  CONFIG_USB_ULPI=y
>>  CONFIG_USB_GADGET=y
>> diff --git a/configs/zynq_picozed_defconfig b/configs/zynq_picozed_defconfig
>> index aeb1270..6d3aef5 100644
>> --- a/configs/zynq_picozed_defconfig
>> +++ b/configs/zynq_picozed_defconfig
>> @@ -28,6 +28,9 @@ CONFIG_SPL_DM_SEQ_ALIAS=y
>>  CONFIG_ZYNQ_SDHCI=y
>>  CONFIG_ZYNQ_GEM=y
>>  CONFIG_USB=y
>> +CONFIG_USB_EHCI_HCD=y
>> +CONFIG_USB_EHCI=y
>> +CONFIG_USB_EHCI_ZYNQ=y
>>  CONFIG_USB_ULPI_VIEWPORT=y
>>  CONFIG_USB_ULPI=y
>>  CONFIG_USB_GADGET=y
>> diff --git a/configs/zynq_zc702_defconfig b/configs/zynq_zc702_defconfig
>> index d68ed0e..57019da 100644
>> --- a/configs/zynq_zc702_defconfig
>> +++ b/configs/zynq_zc702_defconfig
>> @@ -43,6 +43,9 @@ CONFIG_DEBUG_UART_BASE=0xe0001000
>>  CONFIG_DEBUG_UART_CLOCK=5000
>>  CONFIG_ZYNQ_QSPI=y
>>  CONFIG_USB=y
>> +CONFIG_USB_EHCI_HCD=y
>> +CONFIG_USB_EHCI=y
>> +CONFIG_USB_EHCI_ZYNQ=y
>>  CONFIG_USB_ULPI_VIEWPORT=y
>>  CONFIG_USB_ULPI=y
>>  CONFIG_USB_GADGET=y
>> diff --git a/configs/zynq_zc706_defconfig b/configs/zynq_zc706_defconfig
>> index 8bd9230..e19f34f 100644
>> --- a/configs/zynq_zc706_defconfig
>> +++ b/configs/zynq_zc706_defconfig
>> @@ -39,6 +39,9 @@ CONFIG_SPI_FLASH_WINBOND=y
>>  CONFIG_ZYNQ_GEM=y
>>  CONFIG_ZYNQ_QSPI=y
>>  CONFIG_USB=y
>> +CONFIG_USB_EHCI_HCD=y
>> +CONFIG_USB_EHCI=y
>> +CONFIG_USB_EHCI_ZYNQ=y
>>  CONFIG_USB_ULPI_VIEWPORT=y
>>  CONFIG_USB_ULPI=y
>>  CONFIG_USB_GADGET=y
>> diff --git a/configs/zynq_zed_defconfig b/configs/zynq_zed_defconfig
>> index c70b860..6cb8a80 100644
>> --- a/configs/zynq_zed_defconfig
>> +++ b/configs/zynq_zed_defconfig
>> @@ -38,6 +38,9 @@ CONFIG_SPI_FLASH_WINBOND=y
>>  CONFIG_ZYNQ_GEM=y
>>  CONFIG_ZYNQ_QSPI=y
>>  CONFIG_USB=y
>> +CONFIG_USB_EHCI_HCD=y
>> +CONFIG_USB_EHCI=y
>> +CONFIG_USB_EHCI_ZYNQ=y
>>  CONFIG_USB_ULPI_VIEWPORT=y
>>  CONFIG_USB_ULPI=y
>>  CONFIG_USB_GADGET=y
>> diff --git a/configs/zynq_zybo_defconfig b/configs/zynq_zybo_defconfig
>> index 624545e..cce29bc 100644
>> --- a/configs/zynq_zybo_defconfig
>> +++ b/configs/zynq_zybo_defconfig
>> @@ -41,6 +41,9 @@ CONFIG_DEBUG_UART_BASE=0xe0001000
>>  CONFIG_DEBUG_UART_CLOCK=5000
>>  CONFIG_ZYNQ_QSPI=y
>>  CONFIG_USB=y
>> +CONFIG_USB_EHCI_HCD=y
>> +CONFIG_USB_EHCI=y
>> +CONFIG_USB_EHCI_ZYNQ=y
>>  CONFIG_USB_ULPI_VIEWPORT=y
>>  CONFIG_USB_ULPI=y
>>  CONFIG_USB_GADGET=y
>> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
>> index 89580cc..202cb29 100644
>> --- a/drivers/usb/host/Kconfig
>> +++ b/drivers/usb/host/Kconfig
>> @@ -85,6 +85,13 @@ config USB_EHCI_MSM
>>This driver supports combination of Chipidea USB controller
>>and Synapsys USB PHY in host mode only.
>>  
>> +config USB_EHCI_ZYNQ
>> +bool "Support for Xilinx Zynq on-chip EHCI USB controller"
>> +depends on ARCH_ZYNQ
>> +default n

Marek: Maybe make sense to have this as y if there is dependency on
ARCH_ZYNQ. It will shorten defconfigs.


>> +---help---
>> +  Enable support for Zynq on-chip EHCI USB controller
>> +
>>  config USB_EHCI_GENERIC
>>  bool "Support for generic EHCI USB controller"
>>  depends on OF_CONTROL
>> diff --git a/include/configs/zynq-common.h b/include/configs/zynq-common.h
>> index 8dbac87..08b7602 100644
>> --- a/include/configs/zynq-common.h
>> +++ b/include/configs/zynq-common.h
>> @@ -86,10 +86,8 @@
>>  # define CONFIG_ZYNQ_SDHCI_MAX_FREQ 5200
>>  #endif
>>  
>> -#ifdef 

Re: [U-Boot] [PATCH] drivers:usb:common:fsl-dt-fixup: Fix the dt for all type of usb controllers

[Marek Vasut]

On 07/20/2016 05:55 AM, Sriram Dash wrote:
>> From: Marek Vasut [mailto:ma...@denx.de]
>> On 06/20/2016 06:15 AM, Sriram Dash wrote:
>>> Currently, U-boot doesn't allow to compile more than one type of USB
>>> protocol simultaneously. Hence, EHCI and XHCI controllers cannot
>>> co-exist and CONFIG_USB_MAX_CONTROLLER_COUNT macro represents count
>> of
>>> only one type of controller.
>>
>> This does not make sense, with DM we can support all sorts of controllers.
>>
> 
> Ok. Will change the commit message description in v2.
> 
>>> For the Socs which have more than one type of controller e.g. EHCI and
>>> XHCI, and the device tree has to support both of them, the macro
>>> CONFIG_USB_MAX_CONTROLLER_COUNT will not work for fixing dt from u boot.
>>>
>>> So, instead of taking the hard coded number of controller from U boot,
>>> count the total number of controller present in dt and then fix the dt
>>> accordingly.
>>>
>>> Signed-off-by: Sriram Dash 
>>> Signed-off-by: Rajesh Bhagat 
>>> ---
>>>  drivers/usb/common/fsl-dt-fixup.c | 27 ++-
>>>  1 file changed, 26 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/usb/common/fsl-dt-fixup.c
>>> b/drivers/usb/common/fsl-dt-fixup.c
>>> index 9c48852..1edf146 100644
>>> --- a/drivers/usb/common/fsl-dt-fixup.c
>>> +++ b/drivers/usb/common/fsl-dt-fixup.c
>>> @@ -131,10 +131,29 @@ static int fdt_fixup_erratum(int *usb_erratum_off, 
>>> void
>> *blob,
>>> return 0;
>>>  }
>>>
>>> +static int fdt_max_controller_count(void *blob) {
>>> +   int count = 0;
>>> +   int node_offset = -1;
>>> +   int i;
>>> +
>>> +   for (i = 0; compat_usb_fsl[i]; i++) {
>>> +   do {
>>> +   node_offset = fdt_node_offset_by_compatible
>>> +   (blob, node_offset,
>>> +compat_usb_fsl[i]);
>>> +   if (node_offset >= 0)
>>> +   count++;
>>> +   } while (node_offset != -FDT_ERR_NOTFOUND);
>>> +   }
>>> +   return count;
>>> +}
>>> +
>>>  void fdt_fixup_dr_usb(void *blob, bd_t *bd)  {
>>> static const char * const modes[] = { "host", "peripheral", "otg" };
>>> static const char * const phys[] = { "ulpi", "utmi", "utmi_dual" };
>>> +   unsigned int usb_max_controller_count;
>>> int usb_erratum_a006261_off = -1;
>>> int usb_erratum_a007075_off = -1;
>>> int usb_erratum_a007792_off = -1;
>>> @@ -146,7 +165,13 @@ void fdt_fixup_dr_usb(void *blob, bd_t *bd)
>>> int i, j;
>>> int ret;
>>>
>>> -   for (i = 1; i <= CONFIG_USB_MAX_CONTROLLER_COUNT; i++) {
>>> +   usb_max_controller_count = fdt_max_controller_count(blob);
>>
>> Since you walk the tree below anyway, why do you even need to count the
>> elements? Just walk the tree until you can find no more nodes.
>>
> 
> Ok. Will traverse the dt and find the node. Then fix the node and afterwards,
> Traverse the device tree till no nodes are left for fixing.
> 
>>> +   if (!usb_max_controller_count) {
>>> +   printf("ERROR: FDT fixup erratum fail.\n");
>>> +   return;
>>> +   }
>>> +
>>> +   for (i = 1; i <= usb_max_controller_count; i++) {
>>> const char *dr_mode_type = NULL;
>>> const char *dr_phy_type = NULL;
>>> int mode_idx = -1, phy_idx = -1;
>>>
>>
>>
>> --
>> Best regards,
>> Marek Vasut

It'd also be awesome if you replied to emails with less than 1 month pause.

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot