Re: [U-Boot] [PATCH v6 3/3] odroid-c2: enable new Meson GX MMC driver in board defconfig

[Jaehoon Chung]

Dear Heiner,

On 04/12/2017 04:41 AM, Heiner Kallweit wrote:
> Am 20.02.2017 um 20:32 schrieb Heiner Kallweit:
>> Enable new Meson GX MMC driver in Odroid C2 defconfig.
>>
>> Signed-off-by: Heiner Kallweit 
>> ---
>> v6:
>> - no changes
>> ---
>>  configs/odroid-c2_defconfig | 5 -
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/configs/odroid-c2_defconfig b/configs/odroid-c2_defconfig
>> index 62b7627..6de712a 100644
>> --- a/configs/odroid-c2_defconfig
>> +++ b/configs/odroid-c2_defconfig
>> @@ -3,7 +3,9 @@ CONFIG_ARCH_MESON=y
>>  CONFIG_MESON_GXBB=y
>>  CONFIG_TARGET_ODROID_C2=y
>>  CONFIG_IDENT_STRING=" odroid-c2"
>> -# CONFIG_MMC is not set
>> +CONFIG_MMC=y
>> +CONFIG_DM_MMC=y
>> +CONFIG_MMC_MESON_GX=y
>>  CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-odroidc2"
>>  # CONFIG_DISPLAY_CPUINFO is not set
>>  # CONFIG_DISPLAY_BOARDINFO is not set
>> @@ -14,6 +16,7 @@ CONFIG_HUSH_PARSER=y
>>  # CONFIG_CMD_LOADS is not set
>>  # CONFIG_CMD_FPGA is not set
>>  # CONFIG_CMD_SETEXPR is not set
>> +CONFIG_CMD_MMC=y
>>  CONFIG_DOS_PARTITION=y
>>  CONFIG_ISO_PARTITION=y
>>  CONFIG_EFI_PARTITION=y
>>
> Since then I haven't heard back. Anything else which would need to be changed?

Maybe, i had sent the email to you..but when you resend the patches, i will 
pick yours..
When i had applied the patches...it's conflict the latest u-boot..
Sorry for bothering you..if you send the patches, i will apply yours 
immediately.

Best Regards,
Jaehoon Chung 

> 
> Rgds, Heiner
> 
> 
> 
> 

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

Re: [U-Boot] [PATCH v4 0/7] board: sama5d4: convert boards to support DM/DT

[Yang, Wenyou]

Hi Simon,


On 2017/4/11 21:56, Simon Glass wrote:

Hi,

On 10 April 2017 at 00:57, Yang, Wenyou  wrote:

Hi Simon,


On 2017/4/10 3:28, Simon Glass wrote:

+Tom

Hi,

On 7 April 2017 at 01:28, Yang, Wenyou  wrote:

Hi Andreas,

Could you help find a time to take these patch series?

They are here for a long time.


Tom might be able to take it, or if not I could bring it in via DM I
suppose, since it is a conversion.


I truly appreciate you if you take these patches.

OK I've assigned these to myself in patchwork and will pick them up at
some point.


Thank you very much.
Any question, please let me know.



Andreas, please feel free to grab these yourself if you like.

Regards,
Simon


Best Regards,
Wenyou Yang
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] rockchip: rk3399: use regulators_enable_boot_on() to init regulator

[Kever Yang]

Use regulators_enable_boot_on() instead of init regulators one by one,
the interface can init all the regulators with regulator-boot-on property.

Signed-off-by: Kever Yang 
---

 board/rockchip/evb_rk3399/evb-rk3399.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/board/rockchip/evb_rk3399/evb-rk3399.c 
b/board/rockchip/evb_rk3399/evb-rk3399.c
index c437f1b..2ebdee7 100644
--- a/board/rockchip/evb_rk3399/evb-rk3399.c
+++ b/board/rockchip/evb_rk3399/evb-rk3399.c
@@ -40,10 +40,9 @@ int board_init(void)
goto out;
}
 
-   /* rk3399 need init vdd_center to get correct output voltage */
-   ret = regulator_get_by_platname("vdd_center", );
+   ret = regulators_enable_boot_on(false);
if (ret)
-   debug("%s: Cannot get vdd_center regulator\n", __func__);
+   debug("%s: Cannot enable boot on regulator\n", __func__);
 
ret = regulator_get_by_platname("vcc5v0_host", );
if (ret) {
-- 
1.9.1

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

[U-Boot] [PATCH 2/2] rockchip: dts: evb-rk3399: add gmac support

[Kever Yang]

Enable gmac for evb-rk3399.

Signed-off-by: Kever Yang 
---

 arch/arm/dts/rk3399-evb.dts  | 23 +++
 configs/evb-rk3399_defconfig |  4 
 2 files changed, 27 insertions(+)

diff --git a/arch/arm/dts/rk3399-evb.dts b/arch/arm/dts/rk3399-evb.dts
index c3a7ca2..5e7d3bf 100644
--- a/arch/arm/dts/rk3399-evb.dts
+++ b/arch/arm/dts/rk3399-evb.dts
@@ -51,6 +51,13 @@
regulator-name = "vcc5v0_host";
gpio = < 25 GPIO_ACTIVE_HIGH>;
};
+
+   clkin_gmac: external-gmac-clock {
+   compatible = "fixed-clock";
+   clock-frequency = <12500>;
+   clock-output-names = "clkin_gmac";
+   #clock-cells = <0>;
+   };
 };
 
 _phy {
@@ -125,3 +132,19 @@
};
};
 };
+
+ {
+phy-supply = <_phy>;
+   phy-mode = "rgmii";
+   clock_in_out = "input";
+   snps,reset-gpio = < 16 GPIO_ACTIVE_LOW>;
+   snps,reset-active-low;
+   snps,reset-delays-us = <0 1 5>;
+   assigned-clocks = < SCLK_RMII_SRC>;
+   assigned-clock-parents = <_gmac>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   tx_delay = <0x10>;
+   rx_delay = <0x10>;
+   status = "okay";
+};
diff --git a/configs/evb-rk3399_defconfig b/configs/evb-rk3399_defconfig
index 1ee775f..4a17daf 100644
--- a/configs/evb-rk3399_defconfig
+++ b/configs/evb-rk3399_defconfig
@@ -23,6 +23,7 @@ CONFIG_CMD_TIME=y
 CONFIG_SPL_OF_CONTROL=y
 CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names 
interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
 CONFIG_SPL_OF_PLATDATA=y
+CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_REGMAP=y
 CONFIG_SPL_REGMAP=y
 CONFIG_SYSCON=y
@@ -33,6 +34,9 @@ CONFIG_ROCKCHIP_GPIO=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ROCKCHIP=y
+CONFIG_DM_ETH=y
+CONFIG_ETH_DESIGNWARE=y
+CONFIG_GMAC_ROCKCHIP=y
 CONFIG_PINCTRL=y
 CONFIG_SPL_PINCTRL=y
 CONFIG_ROCKCHIP_RK3399_PINCTRL=y
-- 
1.9.1

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

[U-Boot] [PATCH 1/2] rockchip: config: rk3399: clean with make savedefconfig

[Kever Yang]

Clean the evb-rk3399_defconfig with make savedefconfig.

Signed-off-by: Kever Yang 
---

 configs/evb-rk3399_defconfig | 14 +-
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/configs/evb-rk3399_defconfig b/configs/evb-rk3399_defconfig
index 50b0d74..1ee775f 100644
--- a/configs/evb-rk3399_defconfig
+++ b/configs/evb-rk3399_defconfig
@@ -1,20 +1,17 @@
 CONFIG_ARM=y
 CONFIG_ARCH_ROCKCHIP=y
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_SYS_MALLOC_F_LEN=0x4000
 CONFIG_ROCKCHIP_RK3399=y
+CONFIG_SPL_STACK_R_ADDR=0x8
 CONFIG_DEFAULT_DEVICE_TREE="rk3399-evb"
 CONFIG_FIT=y
 CONFIG_SPL_LOAD_FIT=y
-CONFIG_SPL_OF_LIBFDT=y
-CONFIG_SPL_ATF_SUPPORT=y
-CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x200
-CONFIG_SPL_ATF_TEXT_BASE=0x0001
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_SPL_STACK_R=y
-CONFIG_SPL_STACK_R_ADDR=0x8
 CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000
-CONFIG_SPL_LIBCOMMON_SUPPORT=y
-CONFIG_SPL_LIBGENERIC_SUPPORT=y
-CONFIG_SYS_MALLOC_F_LEN=0x4000
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x200
 CONFIG_CMD_BOOTZ=y
 # CONFIG_CMD_IMLS is not set
 CONFIG_CMD_GPT=y
@@ -23,7 +20,6 @@ CONFIG_CMD_SF=y
 CONFIG_CMD_USB=y
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_CMD_TIME=y
-CONFIG_CMD_PXE=y
 CONFIG_SPL_OF_CONTROL=y
 CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names 
interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
 CONFIG_SPL_OF_PLATDATA=y
-- 
1.9.1

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

Re: [U-Boot] [PATCH 00/16] RFC: Board init using driver model

[Simon Glass]

Hi Bin,

On 11 April 2017 at 20:39, Bin Meng  wrote:
> Hi Simon,
>
> On Sat, Apr 1, 2017 at 12:21 PM, Simon Glass  wrote:
>> Hi Tom,
>>
>> On 22 March 2017 at 09:13, Tom Rini  wrote:
>>> On Wed, Mar 22, 2017 at 08:43:54AM -0600, Simon Glass wrote:
 Hi Tom,

 On 22 March 2017 at 08:37, Tom Rini  wrote:
 > On Wed, Mar 22, 2017 at 07:05:38AM -0600, Simon Glass wrote:
 >> Hi Tom,
 >>
 >> On 19 March 2017 at 18:47, Tom Rini  wrote:
 >> > On Sun, Mar 19, 2017 at 12:59:19PM -0600, Simon Glass wrote:
 >> >> At present we have a lot of ad-hoc init functions related to boards, 
 >> >> for
 >> >> example board_early_init_f(), board_misc_init_f() and dram_init().
 >> >>
 >> >> There are used in different ways by different boards as useful hooks 
 >> >> to
 >> >> do the required init and sequence it correctly. Some functions are 
 >> >> always
 >> >> enabled but have a __weak default. Some are controlled by the 
 >> >> existence
 >> >> of a CONFIG.
 >> >>
 >> >> There are two main init sequences: board_init_f() (f for running from
 >> >> read-only flash) which runs before relocation and board_init_r() (r 
 >> >> for
 >> >> relocated) which runs afterwards.
 >> >>
 >> >> One problem with the current sequence is that it has a lot of
 >> >> arch-specific #ifdefs around various functions. There are also 
 >> >> #ifdefs
 >> >> for various features. There has been quite a bit of discussion about 
 >> >> how
 >> >> to tidy this up and at least one RFC series[1].
 >> >>
 >> >> Now that we have driver model we can use this to deal with the init
 >> >> sequences. This approach has several advantages:
 >> >>
 >> >> - We have a path to remove the #ifdefs
 >> >> - It is easy for multiple parts of the code to implement the same 
 >> >> hook
 >> >> - We can track what is called and what is not
 >> >> - We don't need weak functions
 >> >> - We can eventually adjust the sequence to improve naming or to add 
 >> >> new
 >> >> init phases
 >> >> - It provides a model for how we might deal with ft_board_setup() and
 >> >> friends
 >> >>
 >> >> This series starts the process of replacing the pre-relocation init
 >> >> sequence with a driver-model solution. It defines a uclass, adds 
 >> >> tests
 >> >> and converts sandbox and a few x86 boards over to use this new setup.
 >> >>
 >> >> This series is not ready for use yet as the rest of the init sequence
 >> >> hooks need to be converted. But there is enough here to show the 
 >> >> idea.
 >> >>
 >> >> Comments welcome.
 >> >>
 >> >> [1] https://lists.denx.de/pipermail/u-boot/2011-August/098718.html
 >> >
 >> > How does this look, size wise?  With all of these conversions and
 >> > clean-ups, we really need to be size concious as well as it all keeps
 >> > adding up.  Thanks!
 >>
 >> It include size a bit - e.g. x86 808 bytes of text, although that does
 >> include a few extra features.
 >
 > How about if we don't include some of the extra debug/demo type features
 > (which are useful at times, certainly) ?  We keep adding things that add
 > a few bytes here and a few bytes there and it all adds up.

 Yes it's very important that the base version doesn't increase size,
 or at least only minimally. I should have examined that more closely
 in the RFC - my intent was really to get comments on the approach,

 >
 > [snip]
 >> I think I can use a linker-list approach to reduce the overhead. But I
 >> still think the driver has value as it provides a means of adding
 >> hooks to do board-specific things from drivers, something that we keep
 >> running into. Also the idea of a board 'driver' seems conceptually
 >> useful.
 >>
 >> So one approach would be to have:
 >>
 >> 1. A linker-list-based board hook setup, where you can declare, for 
 >> example:
 >>
 >> static int ivybridge_dram_init(void)
 >> {
 >>  ...
 >> }
 >> U_BOOT_BOARD_HOOK(ivybridge_dram_init, BOARD_F_DRAM_INIT);
 >>
 >> This should be pretty cheap, perhaps <200 bytes with some care.
 >>
 >>
 >> 2. An optional BOARD uclass which can be used for more involved
 >> situations, but with a higher code size penalty.
 >
 > OK.  But I also recall that we had talked about trying to condense and
 > re-factor things.  My worry about an approach like this is it allows for
 > us to more easily get back into the bad habits of having each
 > architecture solve similar problems with different solutions.

 Yes that's true and I've been pushing back on this for a while. For
 example there is quite a bit of pressure to add board-specific 

Re: [U-Boot] [PATCH 02/16] x86: Display the SPL banner only once

[Simon Glass]

Hi Bin,

On 11 April 2017 at 21:09, Bin Meng  wrote:
>
> Hi Simon,
>
> On Mon, Mar 20, 2017 at 2:59 AM, Simon Glass  wrote:
> > At present on a cold reboot we must reset the CPU to get it to full speed.
> > With 64-bit U-Boot this happens in SPL. At present we print the banner
> > before doing this, the end result being that we print the banner twice.
> > Print the banner a little later (after the CPU is ready) to avoid this.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  arch/x86/lib/spl.c | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> >
>
> Looks no difference when testing this on QEMU 64-bit. Am I missing anything?

I suspect that QEMU doesn't have this problem, but on chromebook_link
we have to reset to change the CPU speed.

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

Re: [U-Boot] [PATCH 03/16] x86: config: Enable dhrystone command for link

[Bin Meng]

On Mon, Mar 20, 2017 at 2:59 AM, Simon Glass  wrote:
> Enable this command so we can get an approximate performance measurement.
>
> Signed-off-by: Simon Glass 
> ---
>
>  configs/chromebook_link64_defconfig | 1 +
>  configs/chromebook_link_defconfig   | 1 +
>  2 files changed, 2 insertions(+)
>

Reviewed-by: Bin Meng 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 02/16] x86: Display the SPL banner only once

[Bin Meng]

Hi Simon,

On Mon, Mar 20, 2017 at 2:59 AM, Simon Glass  wrote:
> At present on a cold reboot we must reset the CPU to get it to full speed.
> With 64-bit U-Boot this happens in SPL. At present we print the banner
> before doing this, the end result being that we print the banner twice.
> Print the banner a little later (after the CPU is ready) to avoid this.
>
> Signed-off-by: Simon Glass 
> ---
>
>  arch/x86/lib/spl.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>

Looks no difference when testing this on QEMU 64-bit. Am I missing anything?

Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 01/16] x86: Drop leading spaces in cpu_x86_get_desc()

[Bin Meng]

On Mon, Mar 20, 2017 at 2:59 AM, Simon Glass  wrote:
> The Intel CPU name can have leading spaces. Remove them since they are not
> useful.
>
> Signed-off-by: Simon Glass 
> ---
>
>  arch/x86/cpu/cpu_x86.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>

Reviewed-by: Bin Meng 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 2/2] serial: atmel_usart: Add clk support

[Wenyou Yang]

Add the clock support.

The clock handling of DBGU is different fromt the one of USART.

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

Changes in v2:
 - Fix the DBGU clock handling.
 - Add Reviewed-by tag.

 drivers/serial/atmel_usart.c | 52 +---
 1 file changed, 49 insertions(+), 3 deletions(-)

diff --git a/drivers/serial/atmel_usart.c b/drivers/serial/atmel_usart.c
index 8b1e0d55a4..453f8eb451 100644
--- a/drivers/serial/atmel_usart.c
+++ b/drivers/serial/atmel_usart.c
@@ -7,6 +7,7 @@
  * SPDX-License-Identifier:GPL-2.0+
  */
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -133,9 +134,14 @@ __weak struct serial_device *default_serial_console(void)
 #endif
 
 #ifdef CONFIG_DM_SERIAL
+enum serial_clk_type {
+   CLK_TYPE_NORMAL = 0,
+   CLK_TYPE_DBGU,
+};
 
 struct atmel_serial_priv {
atmel_usart3_t *usart;
+   ulong usart_clk_rate;
 };
 
 static void _atmel_serial_set_brg(atmel_usart3_t *usart,
@@ -168,7 +174,7 @@ int atmel_serial_setbrg(struct udevice *dev, int baudrate)
 {
struct atmel_serial_priv *priv = dev_get_priv(dev);
 
-   _atmel_serial_set_brg(priv->usart, get_usart_clk_rate(0), baudrate);
+   _atmel_serial_set_brg(priv->usart, priv->usart_clk_rate, baudrate);
 
return 0;
 }
@@ -213,10 +219,39 @@ static const struct dm_serial_ops atmel_serial_ops = {
.setbrg = atmel_serial_setbrg,
 };
 
+static int atmel_serial_enable_clk(struct udevice *dev)
+{
+   struct atmel_serial_priv *priv = dev_get_priv(dev);
+   struct clk clk;
+   ulong clk_rate;
+   int ret;
+
+   ret = clk_get_by_index(dev, 0, );
+   if (ret)
+   return -EINVAL;
+
+   if (dev_get_driver_data(dev) == CLK_TYPE_NORMAL) {
+   ret = clk_enable();
+   if (ret)
+   return ret;
+   }
+
+   clk_rate = clk_get_rate();
+   if (!clk_rate)
+   return -EINVAL;
+
+   priv->usart_clk_rate = clk_rate;
+
+   clk_free();
+
+   return 0;
+}
+
 static int atmel_serial_probe(struct udevice *dev)
 {
struct atmel_serial_platdata *plat = dev->platdata;
struct atmel_serial_priv *priv = dev_get_priv(dev);
+   int ret;
 #if CONFIG_IS_ENABLED(OF_CONTROL)
fdt_addr_t addr_base;
 
@@ -228,14 +263,25 @@ static int atmel_serial_probe(struct udevice *dev)
 #endif
priv->usart = (atmel_usart3_t *)plat->base_addr;
 
-   _atmel_serial_init(priv->usart, get_usart_clk_rate(0), gd->baudrate);
+   ret = atmel_serial_enable_clk(dev);
+   if (ret)
+   return ret;
+
+   _atmel_serial_init(priv->usart, priv->usart_clk_rate, gd->baudrate);
 
return 0;
 }
 
 #if CONFIG_IS_ENABLED(OF_CONTROL)
 static const struct udevice_id atmel_serial_ids[] = {
-   { .compatible = "atmel,at91sam9260-usart" },
+   {
+   .compatible = "atmel,at91sam9260-dbgu",
+   .data = CLK_TYPE_DBGU,
+   },
+   {
+   .compatible = "atmel,at91sam9260-usart",
+   .data = CLK_TYPE_NORMAL,
+   },
{ }
 };
 #endif
-- 
2.11.0

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

[U-Boot] [PATCH v2 1/2] serial: atmel_usart: Fix early debug not work in SPL

[Wenyou Yang]

Add the uart init function to be used on both probe and the early
debug uart init. For the latter, the input clock should be from
CONFIG_DEBUG_UART_CLOCK.

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

Changes in v2: None

 drivers/serial/atmel_usart.c | 36 +++-
 1 file changed, 31 insertions(+), 5 deletions(-)

diff --git a/drivers/serial/atmel_usart.c b/drivers/serial/atmel_usart.c
index 7674f97e8d..8b1e0d55a4 100644
--- a/drivers/serial/atmel_usart.c
+++ b/drivers/serial/atmel_usart.c
@@ -25,6 +25,7 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
+#ifndef CONFIG_DM_SERIAL
 static void atmel_serial_setbrg_internal(atmel_usart3_t *usart, int id,
 int baudrate)
 {
@@ -66,7 +67,6 @@ static void atmel_serial_activate(atmel_usart3_t *usart)
__udelay(100);
 }
 
-#ifndef CONFIG_DM_SERIAL
 static void atmel_serial_setbrg(void)
 {
atmel_serial_setbrg_internal((atmel_usart3_t *)CONFIG_USART_BASE,
@@ -138,12 +138,37 @@ struct atmel_serial_priv {
atmel_usart3_t *usart;
 };
 
+static void _atmel_serial_set_brg(atmel_usart3_t *usart,
+ ulong usart_clk_rate, int baudrate)
+{
+   unsigned long divisor;
+
+   divisor = (usart_clk_rate / 16 + baudrate / 2) / baudrate;
+   writel(USART3_BF(CD, divisor), >brgr);
+}
+
+void _atmel_serial_init(atmel_usart3_t *usart,
+   ulong usart_clk_rate, int baudrate)
+{
+   writel(USART3_BIT(RXDIS) | USART3_BIT(TXDIS), >cr);
+
+   writel((USART3_BF(USART_MODE, USART3_USART_MODE_NORMAL) |
+   USART3_BF(USCLKS, USART3_USCLKS_MCK) |
+   USART3_BF(CHRL, USART3_CHRL_8) |
+   USART3_BF(PAR, USART3_PAR_NONE) |
+   USART3_BF(NBSTOP, USART3_NBSTOP_1)), >mr);
+
+   _atmel_serial_set_brg(usart, usart_clk_rate, baudrate);
+
+   writel(USART3_BIT(RSTRX) | USART3_BIT(RSTTX), >cr);
+   writel(USART3_BIT(RXEN) | USART3_BIT(TXEN), >cr);
+}
+
 int atmel_serial_setbrg(struct udevice *dev, int baudrate)
 {
struct atmel_serial_priv *priv = dev_get_priv(dev);
 
-   atmel_serial_setbrg_internal(priv->usart, 0 /* ignored */, baudrate);
-   atmel_serial_activate(priv->usart);
+   _atmel_serial_set_brg(priv->usart, get_usart_clk_rate(0), baudrate);
 
return 0;
 }
@@ -202,7 +227,8 @@ static int atmel_serial_probe(struct udevice *dev)
plat->base_addr = (uint32_t)addr_base;
 #endif
priv->usart = (atmel_usart3_t *)plat->base_addr;
-   atmel_serial_init_internal(priv->usart);
+
+   _atmel_serial_init(priv->usart, get_usart_clk_rate(0), gd->baudrate);
 
return 0;
 }
@@ -233,7 +259,7 @@ static inline void _debug_uart_init(void)
 {
atmel_usart3_t *usart = (atmel_usart3_t *)CONFIG_DEBUG_UART_BASE;
 
-   atmel_serial_setbrg_internal(usart, 0, CONFIG_BAUDRATE);
+   _atmel_serial_init(usart, CONFIG_DEBUG_UART_CLOCK, CONFIG_BAUDRATE);
 }
 
 static inline void _debug_uart_putc(int ch)
-- 
2.11.0

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

[U-Boot] [PATCH v2 0/2] serial: atmel_usart: Fix uart init and add clk support

[Wenyou Yang]

The patches is rework the uart init to fix the early debug not work
in SPL, and add the clock support.

Changes in v2:
 - Fix the DBGU clock handling.
 - Add Reviewed-by tag.

Wenyou Yang (2):
  serial: atmel_usart: Fix early debug not work in SPL
  serial: atmel_usart: Add clk support

 drivers/serial/atmel_usart.c | 84 
 1 file changed, 78 insertions(+), 6 deletions(-)

-- 
2.11.0

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

Re: [U-Boot] [PATCH 00/16] RFC: Board init using driver model

[Bin Meng]

Hi Simon,

On Sat, Apr 1, 2017 at 12:21 PM, Simon Glass  wrote:
> Hi Tom,
>
> On 22 March 2017 at 09:13, Tom Rini  wrote:
>> On Wed, Mar 22, 2017 at 08:43:54AM -0600, Simon Glass wrote:
>>> Hi Tom,
>>>
>>> On 22 March 2017 at 08:37, Tom Rini  wrote:
>>> > On Wed, Mar 22, 2017 at 07:05:38AM -0600, Simon Glass wrote:
>>> >> Hi Tom,
>>> >>
>>> >> On 19 March 2017 at 18:47, Tom Rini  wrote:
>>> >> > On Sun, Mar 19, 2017 at 12:59:19PM -0600, Simon Glass wrote:
>>> >> >> At present we have a lot of ad-hoc init functions related to boards, 
>>> >> >> for
>>> >> >> example board_early_init_f(), board_misc_init_f() and dram_init().
>>> >> >>
>>> >> >> There are used in different ways by different boards as useful hooks 
>>> >> >> to
>>> >> >> do the required init and sequence it correctly. Some functions are 
>>> >> >> always
>>> >> >> enabled but have a __weak default. Some are controlled by the 
>>> >> >> existence
>>> >> >> of a CONFIG.
>>> >> >>
>>> >> >> There are two main init sequences: board_init_f() (f for running from
>>> >> >> read-only flash) which runs before relocation and board_init_r() (r 
>>> >> >> for
>>> >> >> relocated) which runs afterwards.
>>> >> >>
>>> >> >> One problem with the current sequence is that it has a lot of
>>> >> >> arch-specific #ifdefs around various functions. There are also #ifdefs
>>> >> >> for various features. There has been quite a bit of discussion about 
>>> >> >> how
>>> >> >> to tidy this up and at least one RFC series[1].
>>> >> >>
>>> >> >> Now that we have driver model we can use this to deal with the init
>>> >> >> sequences. This approach has several advantages:
>>> >> >>
>>> >> >> - We have a path to remove the #ifdefs
>>> >> >> - It is easy for multiple parts of the code to implement the same hook
>>> >> >> - We can track what is called and what is not
>>> >> >> - We don't need weak functions
>>> >> >> - We can eventually adjust the sequence to improve naming or to add 
>>> >> >> new
>>> >> >> init phases
>>> >> >> - It provides a model for how we might deal with ft_board_setup() and
>>> >> >> friends
>>> >> >>
>>> >> >> This series starts the process of replacing the pre-relocation init
>>> >> >> sequence with a driver-model solution. It defines a uclass, adds tests
>>> >> >> and converts sandbox and a few x86 boards over to use this new setup.
>>> >> >>
>>> >> >> This series is not ready for use yet as the rest of the init sequence
>>> >> >> hooks need to be converted. But there is enough here to show the idea.
>>> >> >>
>>> >> >> Comments welcome.
>>> >> >>
>>> >> >> [1] https://lists.denx.de/pipermail/u-boot/2011-August/098718.html
>>> >> >
>>> >> > How does this look, size wise?  With all of these conversions and
>>> >> > clean-ups, we really need to be size concious as well as it all keeps
>>> >> > adding up.  Thanks!
>>> >>
>>> >> It include size a bit - e.g. x86 808 bytes of text, although that does
>>> >> include a few extra features.
>>> >
>>> > How about if we don't include some of the extra debug/demo type features
>>> > (which are useful at times, certainly) ?  We keep adding things that add
>>> > a few bytes here and a few bytes there and it all adds up.
>>>
>>> Yes it's very important that the base version doesn't increase size,
>>> or at least only minimally. I should have examined that more closely
>>> in the RFC - my intent was really to get comments on the approach,
>>>
>>> >
>>> > [snip]
>>> >> I think I can use a linker-list approach to reduce the overhead. But I
>>> >> still think the driver has value as it provides a means of adding
>>> >> hooks to do board-specific things from drivers, something that we keep
>>> >> running into. Also the idea of a board 'driver' seems conceptually
>>> >> useful.
>>> >>
>>> >> So one approach would be to have:
>>> >>
>>> >> 1. A linker-list-based board hook setup, where you can declare, for 
>>> >> example:
>>> >>
>>> >> static int ivybridge_dram_init(void)
>>> >> {
>>> >>  ...
>>> >> }
>>> >> U_BOOT_BOARD_HOOK(ivybridge_dram_init, BOARD_F_DRAM_INIT);
>>> >>
>>> >> This should be pretty cheap, perhaps <200 bytes with some care.
>>> >>
>>> >>
>>> >> 2. An optional BOARD uclass which can be used for more involved
>>> >> situations, but with a higher code size penalty.
>>> >
>>> > OK.  But I also recall that we had talked about trying to condense and
>>> > re-factor things.  My worry about an approach like this is it allows for
>>> > us to more easily get back into the bad habits of having each
>>> > architecture solve similar problems with different solutions.
>>>
>>> Yes that's true and I've been pushing back on this for a while. For
>>> example there is quite a bit of pressure to add board-specific init
>>> code to drivers with driver model. So far I think we have been able to
>>> avoid this using device tree and other drivers. For example if MMC
>>> needs a clock we can find the required clock by phandle and call the
>>> 

Re: [U-Boot] [PATCH] spl: make image arg or fdt blob address reconfigurable

[Vikas MANOCHA]

Hi Tom,

> -Original Message-
> From: Tom Rini [mailto:tr...@konsulko.com]
> Sent: Monday, April 10, 2017 5:29 AM
> To: Vikas MANOCHA 
> Cc: u-boot@lists.denx.de; Marek Vasut ; Stefan Agner 
> ; Jeremy Hunt
> 
> Subject: Re: [U-Boot] [PATCH] spl: make image arg or fdt blob address 
> reconfigurable
> 
> On Fri, Apr 07, 2017 at 03:38:13PM -0700, Vikas Manocha wrote:
> 
> > At present fdt blob or argument address being passed to kernel is
> > fixed at compile time using macro CONFIG_SYS_SPL_ARGS_ADDR. FDT blob
> > from different media like nand, nor flash are copied to the address
> > pointed by the macro.
> > The problem is, it makes args/fdt blob compulsory to copy which is not
> > required in cases like for NOR Flash. This patch removes this limitation.
> >
> > Signed-off-by: Vikas Manocha 
> > ---
> >  arch/arm/lib/spl.c| 7 +++
> >  arch/microblaze/cpu/spl.c | 6 +++---
> >  arch/powerpc/lib/spl.c| 8 
> >  common/spl/spl.c  | 6 --
> >  common/spl/spl_nor.c  | 8 +---
> >  include/spl.h | 5 ++---
> 
> I assume you've tested the spl_nor case afterwards, yes?  Did this result in 
> some measurable boot time decrease?  Thanks!

Yes, I tested it's working on board. Not sure how to measure the impact on boot 
time.

Cheers,
Vikas

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

[U-Boot] [PATCH 2/2] mips: qemu-mips: Expand malloc pool to fit CONFIG_SYS_BOOTPARAMS_LEN

[Kyle Edwards]

Before this patch, CONFIG_SYS_BOOTPARAMS_LEN was the same size as
CONFIG_SYS_MALLOC_LEN. So, if malloc() had previously been called, and
initr_malloc_bootparams() was called, it would fail with an out-of-
memory error. This patch fixes this issue by expanding the malloc pool
to 256KB.

Signed-off-by: Kyle Edwards 
Cc: Daniel Schwierzeck 
---
 include/configs/qemu-mips.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/qemu-mips.h b/include/configs/qemu-mips.h
index b67d413..59a793b 100644
--- a/include/configs/qemu-mips.h
+++ b/include/configs/qemu-mips.h
@@ -80,7 +80,7 @@
 /* max number of command args */
 #define CONFIG_SYS_MAXARGS 16
 
-#define CONFIG_SYS_MALLOC_LEN  128*1024
+#define CONFIG_SYS_MALLOC_LEN  (256 << 10)
 
 #define CONFIG_SYS_BOOTPARAMS_LEN  128*1024
 
-- 
2.7.4

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

[U-Boot] [PATCH 0/2] Fix several bugs in qemu-mips configuration

[Kyle Edwards]

I recently played around with the qemu-mips configuration, and
encountered several issues. Saving the environment to flash overwrites
the U-Boot code, and the malloc pool isn't big enough for
initr_malloc_bootparams(). This patchset fixes these issues.

Kyle Edwards (2):
  mips: qemu-mips: Remove obsolete CONFIG_SYS_MONITOR_LEN from config
  mips: qemu-mips: Expand malloc pool to fit CONFIG_SYS_BOOTPARAMS_LEN

 include/configs/qemu-mips.h | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

-- 
2.7.4

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

[U-Boot] [PATCH 1/2] mips: qemu-mips: Remove obsolete CONFIG_SYS_MONITOR_LEN from config

[Kyle Edwards]

This fixes an issue with the saveenv command causing U-Boot to no
longer work on the QEMU Mips pseudoboard. Because the offset of the
environment was being determined by CONFIG_SYS_MONITOR_LEN, and this
value was less than the actual size of U-Boot, saveenv was overwriting
parts of the U-Boot code. Because CONFIG_SYS_MONITOR_LEN is no longer
used on MIPS, this patch removes it and places the environment at the
end of the pseudoboard's 4MB flash.

Signed-off-by: Kyle Edwards 
Cc: Daniel Schwierzeck 
---
 include/configs/qemu-mips.h | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/include/configs/qemu-mips.h b/include/configs/qemu-mips.h
index be7f4f2..b67d413 100644
--- a/include/configs/qemu-mips.h
+++ b/include/configs/qemu-mips.h
@@ -102,7 +102,6 @@
  */
 /* The following #defines are needed to get flash environment right */
 #define CONFIG_SYS_MONITOR_BASECONFIG_SYS_TEXT_BASE
-#define CONFIG_SYS_MONITOR_LEN (192 << 10)
 
 #define CONFIG_SYS_INIT_SP_OFFSET  0x40
 
@@ -115,10 +114,10 @@
 #define CONFIG_SYS_FLASH_USE_BUFFER_WRITE
 
 #define CONFIG_ENV_IS_IN_FLASH
-#define CONFIG_ENV_ADDR(CONFIG_SYS_FLASH_BASE + 
CONFIG_SYS_MONITOR_LEN)
 
 /* Address and size of Primary Environment Sector */
 #define CONFIG_ENV_SIZE0x8000
+#define CONFIG_ENV_ADDR(CONFIG_SYS_FLASH_BASE + (4 << 20) - 
CONFIG_ENV_SIZE)
 
 #define CONFIG_ENV_OVERWRITE   1
 
-- 
2.7.4

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

Re: [U-Boot] qemu_mips - CONFIG_SYS_MONITOR_LEN is too small

[Daniel Schwierzeck]

Am 09.04.2017 um 20:19 schrieb Kyle Edwards:
> Hi all,
> 
> I recently tried to use u-boot on the qemu_mips platform, and running
> the saveenv command causes u-boot to not boot after a reset. I followed
> these steps:
> 
> $ git clone git://git.denx.de/u-boot.git
> $ cd u-boot
> $ git checkout v2017.05-rc1
> $ export CROSS_COMPILE=mips-linux-gnu-
> $ make qemu_mips_defconfig
> $ make
> $ dd if=/dev/zero of=../flash.bin bs=1k count=4k
> $ dd if=u-boot.bin of=../flash.bin bs=1k conv=notrunc
> $ qemu-system-mips -nographic -M mips -pflash ../flash.bin
> 
> At this point I stopped autoboot, ran "saveenv" inside U-Boot, and reset
> qemu. After reset, U-Boot did not print any messages, and is stuck.
> 
> I tracked this down to an invalid CONFIG_SYS_MONITOR_LEN. It's currently
> configured for 196608 (192 << 10), but running "ls -l u-boot.bin" shows
> a size of 232296. When the environment is being saved, it overwrites
> part of the U-Boot code.

good catch, but your description is a little bit misleading. 
CONFIG_SYS_MONITOR_LEN 
is not used any more on MIPS. The main problem is the wrong env offset which is 
currently derived from CONFIG_SYS_MONITOR_LEN:

#define CONFIG_ENV_ADDR (CONFIG_SYS_FLASH_BASE + CONFIG_SYS_MONITOR_LEN)

> 
> I am willing to write a patch for this bug, but I thought I would report
> it here first.
> 

please do. Patches are always preferred to bug reports because we only have a
patch-tracking system. Thus bug reports likely go missing whereas patches get 
picked
up by a maintainer eventually.

-- 
- Daniel



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

Re: [U-Boot] [PATCH] board/t1024rdb: enable board-level reset when issuing reset command

[York Sun]

On 04/11/2017 02:16 AM, Shengzhou Liu wrote:



-Original Message-
From: York Sun [mailto:york@nxp.com]
Sent: Tuesday, April 11, 2017 1:14 AM
To: Shengzhou Liu ; u-boot@lists.denx.de
Subject: Re: [PATCH] board/t1024rdb: enable board-level reset when issuing
reset command

On 04/10/2017 01:14 AM, Shengzhou Liu wrote:

As board-specific reset logic, it needs to issue reset signal via CPLD
when issuing 'reset' command in u-boot, this patch solves the issue of
reset command not working on T1024RDB.


Shengzhou,

Doesn't the RST_REQ signal work for this board?

York


York,

Yes, RST_REQ can't reliably work without CPLD reset on T1024RDB, it needs a 
board-level reset via CPLD reset logic.


Why? Isn't it a hardware problem? If this is something cannot be fixed, 
we can add this as a software workaround. Let's make it clear.


York

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

Re: [U-Boot] [Patch v2 3/3] armv8: ls1088aqds: Add support of LS1088AQDS

[York Sun]

On 04/10/2017 09:19 AM, Ashish Kumar wrote:

This patch add support of LS1088AQDS platform.

The LS1088A QorIQTM Development System (QDS) is a
high-performance computing, evaluation, and
development platform that supports the LS1088A QorIQ Architecture
processor.

Signed-off-by: Prabhakar Kushwaha 
Signed-off-by: Ashish Kumar 
Signed-off-by: Shaohui Xie 
---
v2:
Fix indentaion in commit msg

 arch/arm/Kconfig |  11 +
 arch/arm/cpu/armv8/Kconfig   |   2 +-
 arch/arm/dts/Makefile|   1 +
 arch/arm/dts/fsl-ls1088a-qds.dts |  70 
 board/freescale/ls1088a/Kconfig  |  16 +
 board/freescale/ls1088a/MAINTAINERS  |  10 +-
 board/freescale/ls1088a/Makefile |   1 +
 board/freescale/ls1088a/ddr.c| 119 +-
 board/freescale/ls1088a/ddr.h|   9 +-
 board/freescale/ls1088a/eth_ls1088aqds.c | 650 +++
 board/freescale/ls1088a/ls1088a.c| 106 -
 board/freescale/ls1088a/ls1088a_qixis.h  |   5 +
 configs/ls1088aqds_qspi_defconfig|  27 ++
 configs/ls1088ardb_qspi_defconfig|   6 -
 include/configs/ls1088a_common.h |   8 +-
 include/configs/ls1088aqds.h | 422 
 16 files changed, 1316 insertions(+), 147 deletions(-)
 create mode 100644 arch/arm/dts/fsl-ls1088a-qds.dts
 create mode 100644 board/freescale/ls1088a/eth_ls1088aqds.c
 create mode 100644 configs/ls1088aqds_qspi_defconfig
 create mode 100644 include/configs/ls1088aqds.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a441cb3..a5a5927 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -883,6 +883,17 @@ config TARGET_LS2080A_SIMU
  development platform that supports the QorIQ LS2080A
  Layerscape Architecture processor.

+config TARGET_LS1088AQDS
+   bool "Support ls1088aqds"
+   select ARCH_LS1088A
+   select ARM64
+   select ARMV8_MULTIENTRY
+   help
+ Support for NXP LS1088AQDS platform
+ The LS1088A Development System (QDS) is a high-performance
+ development platform that supports the QorIQ LS1088A
+ Layerscape Architecture processor.
+
 config TARGET_LS2080AQDS
bool "Support ls2080aqds"
select ARCH_LS2080A
diff --git a/arch/arm/cpu/armv8/Kconfig b/arch/arm/cpu/armv8/Kconfig
index 630bb78..b3565a5 100644
--- a/arch/arm/cpu/armv8/Kconfig
+++ b/arch/arm/cpu/armv8/Kconfig
@@ -88,7 +88,7 @@ config PSCI_RESET
depends on !ARCH_EXYNOS7 && !ARCH_BCM283X && !TARGET_LS2080A_EMU && \
   !TARGET_LS2080A_SIMU && !TARGET_LS2080AQDS && \
   !TARGET_LS2080ARDB && !TARGET_LS1012AQDS && \
-  !TARGET_LS1088ARDB && \
+  !TARGET_LS1088ARDB && !TARGET_LS1088AQDS && \
   !TARGET_LS1012ARDB && !TARGET_LS1012AFRDM && \
   !TARGET_LS1043ARDB && !TARGET_LS1043AQDS && \
   !TARGET_LS1046ARDB && !TARGET_LS1046AQDS && \
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 5ac8ea3..2ec5c12 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -164,6 +164,7 @@ dtb-$(CONFIG_LS102XA) += ls1021a-qds-duart.dtb \
ls1021a-iot-duart.dtb
 dtb-$(CONFIG_FSL_LSCH3) += fsl-ls2080a-qds.dtb \
fsl-ls2080a-rdb.dtb \
+   fsl-ls1088a-qds.dtb \
fsl-ls1088a-rdb.dtb
 dtb-$(CONFIG_FSL_LSCH2) += fsl-ls1043a-qds-duart.dtb \
fsl-ls1043a-qds-lpuart.dtb \
diff --git a/arch/arm/dts/fsl-ls1088a-qds.dts b/arch/arm/dts/fsl-ls1088a-qds.dts
new file mode 100644
index 000..9b7bef4
--- /dev/null
+++ b/arch/arm/dts/fsl-ls1088a-qds.dts
@@ -0,0 +1,70 @@
+/*
+ * NXP ls1088a QDS board device tree source
+ *
+ * Copyright 2017 NXP
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/dts-v1/;
+
+#include "fsl-ls1088a.dtsi"
+
+/ {
+   model = "NXP Layerscape 1088a QDS Board";
+   compatible = "fsl,ls1088a-qds", "fsl,ls1088a";
+   aliases {
+   spi0 = 
+   spi1 = 
+   };
+};
+
+ {
+   bus-num = <0>;
+   status = "okay";
+
+   dflash0: n25q128a {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "spi-flash";
+   reg = <0>;
+   spi-max-frequency = <100>; /* input clock */
+   };
+
+   dflash1: sst25wf040b {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "spi-flash";
+   spi-max-frequency = <350>;
+   reg = <1>;
+   };
+
+   dflash2: en25s64 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "spi-flash";
+   spi-max-frequency = <350>;
+   reg = <2>;
+   };
+};
+
+ {
+   bus-num = <0>;
+   status = "okay";
+
+   qflash0: s25fs512s@0 {
+   #address-cells = <1>;
+ 

Re: [U-Boot] [Patch v2 2/3] armv8: ls1088ardb: Add support for LS1088ARDB platform

[York Sun]

On 04/10/2017 09:19 AM, Ashish Kumar wrote:

LS1088A is an ARMv8 implementation. The LS1088ARDB is an evaluatoin
platform that supports the LS1088A family SoCs. This patch add basic
support of the platform.

Signed-off-by: Alison Wang 
Signed-off-by: Prabhakar Kushwaha 
Signed-off-by: Ashish Kumar 
Signed-off-by: Raghav Dogra 
Signed-off-by: Shaohui Xie 
---
v2:
Fix indentaion in commit msg
Separate RDB and Si specific file

 arch/arm/Kconfig |  12 ++
 arch/arm/cpu/armv8/Kconfig   |   1 +
 arch/arm/dts/Makefile|   3 +-
 arch/arm/dts/fsl-ls1088a-rdb.dts |  40 
 board/freescale/ls1088a/Kconfig  |  15 ++
 board/freescale/ls1088a/MAINTAINERS  |   9 +
 board/freescale/ls1088a/Makefile |   9 +
 board/freescale/ls1088a/ddr.c| 215 +++
 board/freescale/ls1088a/ddr.h|  46 
 board/freescale/ls1088a/eth_ls1088ardb.c | 102 +
 board/freescale/ls1088a/ls1088a.c| 336 ++
 board/freescale/ls1088a/ls1088a_qixis.h  |  34 +++
 configs/ls1088ardb_qspi_defconfig|  33 +++
 include/configs/ls1088a_common.h | 205 ++
 include/configs/ls1088ardb.h | 346 +++
 15 files changed, 1405 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/fsl-ls1088a-rdb.dts
 create mode 100644 board/freescale/ls1088a/Kconfig
 create mode 100644 board/freescale/ls1088a/MAINTAINERS
 create mode 100644 board/freescale/ls1088a/Makefile
 create mode 100644 board/freescale/ls1088a/ddr.c
 create mode 100644 board/freescale/ls1088a/ddr.h
 create mode 100644 board/freescale/ls1088a/eth_ls1088ardb.c
 create mode 100644 board/freescale/ls1088a/ls1088a.c
 create mode 100644 board/freescale/ls1088a/ls1088a_qixis.h
 create mode 100644 configs/ls1088ardb_qspi_defconfig
 create mode 100644 include/configs/ls1088a_common.h
 create mode 100644 include/configs/ls1088ardb.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 0a05662..a441cb3 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -954,6 +954,17 @@ config TARGET_LS1012AFRDM
  development platform that supports the QorIQ LS1012A
  Layerscape Architecture processor.

+config TARGET_LS1088ARDB
+   bool "Support ls1088ardb"
+   select ARCH_LS1088A
+   select ARM64
+   select ARMV8_MULTIENTRY
+   help
+ Support for NXP LS1088ARDB platform.
+ The LS1088AA Reference design board (RDB) is a high-performance
+ development platform that supports the QorIQ LS1088A
+ Layerscape Architecture processor.
+
 config TARGET_LS1021AQDS
bool "Support ls1021aqds"
select BOARD_LATE_INIT
@@ -1207,6 +1218,7 @@ source "board/denx/m53evk/Kconfig"
 source "board/freescale/ls2080a/Kconfig"
 source "board/freescale/ls2080aqds/Kconfig"
 source "board/freescale/ls2080ardb/Kconfig"
+source "board/freescale/ls1088a/Kconfig"
 source "board/freescale/ls1021aqds/Kconfig"
 source "board/freescale/ls1043aqds/Kconfig"
 source "board/freescale/ls1021atwr/Kconfig"
diff --git a/arch/arm/cpu/armv8/Kconfig b/arch/arm/cpu/armv8/Kconfig
index 0188b95..630bb78 100644
--- a/arch/arm/cpu/armv8/Kconfig
+++ b/arch/arm/cpu/armv8/Kconfig
@@ -88,6 +88,7 @@ config PSCI_RESET
depends on !ARCH_EXYNOS7 && !ARCH_BCM283X && !TARGET_LS2080A_EMU && \
   !TARGET_LS2080A_SIMU && !TARGET_LS2080AQDS && \
   !TARGET_LS2080ARDB && !TARGET_LS1012AQDS && \
+  !TARGET_LS1088ARDB && \
   !TARGET_LS1012ARDB && !TARGET_LS1012AFRDM && \
   !TARGET_LS1043ARDB && !TARGET_LS1043AQDS && \
   !TARGET_LS1046ARDB && !TARGET_LS1046AQDS && \
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index eb68c20..5ac8ea3 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -163,7 +163,8 @@ dtb-$(CONFIG_LS102XA) += ls1021a-qds-duart.dtb \
ls1021a-twr-duart.dtb ls1021a-twr-lpuart.dtb \
ls1021a-iot-duart.dtb
 dtb-$(CONFIG_FSL_LSCH3) += fsl-ls2080a-qds.dtb \
-   fsl-ls2080a-rdb.dtb
+   fsl-ls2080a-rdb.dtb \
+   fsl-ls1088a-rdb.dtb
 dtb-$(CONFIG_FSL_LSCH2) += fsl-ls1043a-qds-duart.dtb \
fsl-ls1043a-qds-lpuart.dtb \
fsl-ls1043a-rdb.dtb \
diff --git a/arch/arm/dts/fsl-ls1088a-rdb.dts b/arch/arm/dts/fsl-ls1088a-rdb.dts
new file mode 100644
index 000..30ceed8
--- /dev/null
+++ b/arch/arm/dts/fsl-ls1088a-rdb.dts
@@ -0,0 +1,40 @@
+/*
+ * NXP ls1088a RDB board device tree source
+ *
+ * Copyright 2017 NXP
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/dts-v1/;
+
+#include "fsl-ls1088a.dtsi"
+
+/ {
+   model = "NXP Layerscape 1088a RDB Board";
+   compatible = "fsl,ls1088a-rdb", "fsl,ls1088a";
+   aliases {
+   spi0 = 
+   };
+};
+
+ {
+   bus-num = 

Re: [U-Boot] [Patch v2 1/3] armv8: ls1088a: Add NXP LS1088A SoC support

[York Sun]

On 04/10/2017 09:19 AM, Ashish Kumar wrote:

The QorIQ LS1088A processor is built on the Layerscape
architecture combining eight ARM A53 processor cores
with advanced, high-performance datapath acceleration
and networks, peripheral interfaces required for
networking, wireless infrastructure, and general-purpose
embedded applications.

LS1088A is compliant to the Layerscape Chassis Generation 3.

Features summary:
 - Eight 32-bit / 64-bit ARM v8 Cortex-A53 CPUs
 - Cores are in 2 cluster of 4-cores each
 - Cache coherent interconnect (CCI-400)
 - One 64-bit DDR4 SDRAM memory controller with ECC
 - Data path acceleration architecture 2.0 (DPAA2)
 - Ethernet interfaces: SGMIIs, RGMIIs, QSGMIIs, XFIs
 - QSPI, IFC, 3 PCIe, 1 SATA, 2 USB, 1 SDXC, 2 DUARTs etc

Signed-off-by: Alison Wang 
Signed-off-by: Prabhakar Kushwaha 
Signed-off-by: Ashish Kumar 
Signed-off-by: Raghav Dogra 
Signed-off-by: Shaohui Xie 

Signed-off-by: Ashish Kumar 
---
v2:
 Fix indentaion in commit msg
 Separate RDB and Si specific file
 Move Macros to Kconfig

 arch/arm/cpu/armv8/fsl-layerscape/Kconfig  |  44 ++-
 arch/arm/cpu/armv8/fsl-layerscape/Makefile |   4 +
 arch/arm/cpu/armv8/fsl-layerscape/cpu.c|   1 +
 .../cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c|  10 ++
 arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S   |   6 +-
 arch/arm/cpu/armv8/fsl-layerscape/ls1088a_serdes.c | 126 +
 arch/arm/cpu/armv8/fsl-layerscape/soc.c|   5 +
 arch/arm/dts/fsl-ls1088a.dtsi  |  78 +
 arch/arm/include/asm/arch-fsl-layerscape/config.h  |  62 +-
 arch/arm/include/asm/arch-fsl-layerscape/cpu.h |   4 +
 .../include/asm/arch-fsl-layerscape/fsl_serdes.h   |   3 +-
 .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |  11 ++
 .../asm/arch-fsl-layerscape/ls1088a_stream_id.h|  57 ++
 arch/arm/include/asm/arch-fsl-layerscape/soc.h |   4 +
 drivers/ddr/fsl/util.c |   2 +-
 drivers/net/ldpaa_eth/Makefile |   1 +
 drivers/net/ldpaa_eth/ls1088a.c|  87 ++
 17 files changed, 494 insertions(+), 11 deletions(-)
 create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/ls1088a_serdes.c
 create mode 100644 arch/arm/dts/fsl-ls1088a.dtsi
 create mode 100644 arch/arm/include/asm/arch-fsl-layerscape/ls1088a_stream_id.h
 create mode 100644 drivers/net/ldpaa_eth/ls1088a.c

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig 
b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
index fbb95cd..a3e8499 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
@@ -49,6 +49,29 @@ config ARCH_LS1046A
select BOARD_EARLY_INIT_F
select SYS_FSL_HAS_CCI400

+config ARCH_LS1088A
+   bool
+   select ARMV8_SET_SMPEN
+   select FSL_LSCH3
+   select SYS_FSL_DDR
+   select SYS_FSL_DDR_LE
+   select SYS_FSL_DDR_VER_50
+   select SYS_FSL_HAS_CCI400
+   select SYS_FSL_HAS_DDR4
+   select SYS_FSL_HAS_SEC
+   select SYS_FSL_SEC_COMPAT_5
+   select SYS_FSL_SEC_LE
+   select SYS_FSL_SRDS_1
+   select SYS_FSL_SRDS_2
+   select FSL_TZASC_1
+   select SYS_FSL_ERRATUM_A009803
+   select SYS_FSL_ERRATUM_A009942
+   select SYS_FSL_ERRATUM_A010165
+   select SYS_FSL_ERRATUM_A008511
+   select SYS_FSL_ERRATUM_A008850
+   select ARCH_EARLY_INIT_R
+   select BOARD_EARLY_INIT_F
+
 config ARCH_LS2080A
bool
select ARMV8_SET_SMPEN
@@ -79,6 +102,7 @@ config ARCH_LS2080A
select SYS_FSL_ERRATUM_A009942
select SYS_FSL_ERRATUM_A010165
select SYS_FSL_ERRATUM_A009203
+   select SYS_FSL_HAS_CCN504
select ARCH_EARLY_INIT_R
select BOARD_EARLY_INIT_F

@@ -97,7 +121,7 @@ config FSL_LSCH3

 config FSL_MC_ENET
bool "Management Complex network"
-   depends on ARCH_LS2080A
+   depends on ARCH_LS2080A || ARCH_LS1088A
default y
select RESV_RAM
help
@@ -113,6 +137,7 @@ config FSL_PCIE_COMPAT
default "fsl,ls1043a-pcie" if ARCH_LS1043A
default "fsl,ls1046a-pcie" if ARCH_LS1046A
default "fsl,ls2080a-pcie" if ARCH_LS2080A
+   default "fsl,ls1080a-pcie" if ARCH_LS1088A
help
  This compatible is used to find pci controller node in Kernel DT
  to complete fixup.
@@ -173,6 +198,7 @@ config MAX_CPUS
default 4 if ARCH_LS1043A
default 4 if ARCH_LS1046A
default 16 if ARCH_LS2080A
+   default 8 if ARCH_LS1088A
default 1
help
  Set this number to the maximum number of possible CPUs in the SoC.
@@ -195,13 +221,11 @@ config QSPI_AHB_INIT

 config SYS_FSL_IFC_BANK_COUNT
int "Maximum banks of Integrated flash controller"
-   depends on ARCH_LS1043A || ARCH_LS1046A || 

Re: [U-Boot] [PATCH 5/6] arm: sunxi: Use board hooks to obtain MAC address

[Olliver Schinagl]

Hey Joe,

On 11-04-17 00:56, Joe Hershberger wrote:

On Fri, Apr 7, 2017 at 8:57 AM,   wrote:

On Fri, 2017-04-07 at 15:45 +0200, Olliver Schinagl wrote:

Hey Joe,

On 30-11-16 22:36, Joe Hershberger wrote:

On Fri, Nov 25, 2016 at 9:38 AM, Olliver Schinagl  wrote:

Add board hooks allowing to get ethernet addresses in a board
specific
manner. Currently this is done by generating a MAC address from
the SID and injecting the ethernet device number in the first
octet.

This usually happens as a fallback, if either the eeprom fails to
set a
MAC address or the FDT forces an override.

Signed-off-by: Olliver Schinagl 
---
  arch/arm/include/asm/arch-sunxi/sys_proto.h |  11 ++
  board/sunxi/board.c | 161
+++-
  net/eth_legacy.c|   1 +
  3 files changed, 98 insertions(+), 75 deletions(-)

diff --git a/arch/arm/include/asm/arch-sunxi/sys_proto.h
b/arch/arm/include/asm/arch-sunxi/sys_proto.h
index a373319..fad7c48 100644
--- a/arch/arm/include/asm/arch-sunxi/sys_proto.h
+++ b/arch/arm/include/asm/arch-sunxi/sys_proto.h
@@ -30,4 +30,15 @@ void eth_init_board(void);
  static inline void eth_init_board(void) {}
  #endif

+int board_get_enetaddr(const int i, unsigned char *mac_addr);
+
+#if CONFIG_SUNXI_EMAC
+int sunxi_emac_board_read_rom_hwaddr(unsigned char *enetaddr,
int id);
+#endif
+
+#if defined(CONFIG_SUNXI_GMAC) || defined(CONFIG_ETH_DESIGNWARE)
+int dw_board_read_rom_hwaddr(unsigned char *enetaddr, int id);
+#endif
+
+
  #endif
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 5365638..4aeab51 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -21,6 +21,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #ifndef CONFIG_ARM64
  #include 
@@ -564,6 +565,34 @@ int g_dnl_board_usb_cable_connected(void)
  }
  #endif

+int sunxi_get_board_serial(unsigned int *serial)
+{
+   int ret;
+
+   ret = sunxi_get_sid(serial);
+   if (!ret || serial[0])
+   return -ENOSYS;
+
+   /*
+* The single words 1 - 3 of the SID have quite a few
bits
+* which are the same on many models, so we take a crc32
+* of all 3 words, to get a more unique value.
+*
+* Note we only do this on newer SoCs as we cannot change
+* the algorithm on older SoCs since those have been
using
+* fixed mac-addresses/serial based on only using word 3
for a
+* long time and changing a fixed mac-address/serial with
an
+* u-boot update is not good.
+*/
+#if !defined(CONFIG_MACH_SUN4I) && !defined(CONFIG_MACH_SUN5I)
&& \
+!defined(CONFIG_MACH_SUN6I) && !defined(CONFIG_MACH_SUN7I)
&& \
+!defined(CONFIG_MACH_SUN8I_A23) &&
!defined(CONFIG_MACH_SUN8I_A33)
+   serial[3] = crc32(0, (unsigned char *)[1], 12);
+#endif
+
+   return 0;
+}
+
  #ifdef CONFIG_SERIAL_TAG
  void get_board_serial(struct tag_serialnr *serialnr)
  {
@@ -585,6 +614,54 @@ void get_board_serial(struct tag_serialnr
*serialnr)
  #endif

  /*
+ * Generate a MAC address based on device index and the serial
number.
+ * The first half of the of the first octet holds the eth index.
+ *
+ * In the second octet we forcefully mark the MAC address to a
locally
+ * administered MAC address.
+ *
+ */
+int board_get_enetaddr(const int index, unsigned char *enetaddr)

This would be part of a board-specific eth driver.

this is being called now from sunxi_gmac.c and sunxi_emac.c and
supplies
these board specific drivers with a mac address based on the serial
number of the board. I could move this logic over, but then i'd have
to
add it to both eth drivers. By having it in the board.c file, we have
2
simple functions in the board-specific eth driver:


static int sunxi_gmac_eth_read_rom_hwaddr(struct udevice *dev)
{
   struct eth_pdata *pdata = dev_get_platdata(dev);

   return board_get_enetaddr(dev->seq, pdata->enetaddr);
}

So do you propose to dupilicate the code into both board specific
drivers, have it named differently or that the shared code live
elsewhere?

Replying to myself here,

I just realized, while this bit was not accepted, the overal
implementation has changed in the set. So before, I did things wrong :)
As Simon explained last time.

To clarify, I now have added the logic to the sunxi gmac and emac board
specific drivers. But afaik they share no common code. (like
sunxi_common.c in drivers/net)

With that in mind, how we did things up until now, was to have a
fallback scenario where we use the SoC serial number to generate a MAC
address.

If this is go be done with the board specific driver, we'd need to
still however call board specific functions (sunxi_get_board_serial).

The solution I think is still one of the previously mentioned, a
sunxi_common.c which does the serial -> MAC conversion according to the
previous logic, using sunxi_get_board_serial() (which really is a SoC
specific 

Re: [U-Boot] [PATCH v6 3/3] odroid-c2: enable new Meson GX MMC driver in board defconfig

[Heiner Kallweit]

Am 20.02.2017 um 20:32 schrieb Heiner Kallweit:
> Enable new Meson GX MMC driver in Odroid C2 defconfig.
> 
> Signed-off-by: Heiner Kallweit 
> ---
> v6:
> - no changes
> ---
>  configs/odroid-c2_defconfig | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/configs/odroid-c2_defconfig b/configs/odroid-c2_defconfig
> index 62b7627..6de712a 100644
> --- a/configs/odroid-c2_defconfig
> +++ b/configs/odroid-c2_defconfig
> @@ -3,7 +3,9 @@ CONFIG_ARCH_MESON=y
>  CONFIG_MESON_GXBB=y
>  CONFIG_TARGET_ODROID_C2=y
>  CONFIG_IDENT_STRING=" odroid-c2"
> -# CONFIG_MMC is not set
> +CONFIG_MMC=y
> +CONFIG_DM_MMC=y
> +CONFIG_MMC_MESON_GX=y
>  CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-odroidc2"
>  # CONFIG_DISPLAY_CPUINFO is not set
>  # CONFIG_DISPLAY_BOARDINFO is not set
> @@ -14,6 +16,7 @@ CONFIG_HUSH_PARSER=y
>  # CONFIG_CMD_LOADS is not set
>  # CONFIG_CMD_FPGA is not set
>  # CONFIG_CMD_SETEXPR is not set
> +CONFIG_CMD_MMC=y
>  CONFIG_DOS_PARTITION=y
>  CONFIG_ISO_PARTITION=y
>  CONFIG_EFI_PARTITION=y
> 
Since then I haven't heard back. Anything else which would need to be changed?

Rgds, Heiner

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

Re: [U-Boot] [PATCH RFC 1/7] omap_hsmmc: update struct hsmmc to accommodate omap3 from DT

[Adam Ford]

On Mon, Apr 10, 2017 at 11:33 PM, Vignesh R  wrote:
>
>
> On Tuesday 11 April 2017 03:42 AM, Adam Ford wrote:
>> I am working on porting an OMAP3630 board to support device tree, and
>> I attempted to change enable DM_MMC.  Unfortunately, that broke MMC.
>>
>> I discovered that the base addresses were originally updated to reflect a
>> change in the base address when using the device tree for some devices.
>>
>> This was done in 11e1582506c6 ("omap_hsmmc: update struct hsmmc to accomodate
>> base address from DT")
>>
>> Unfortunately, this breaks the base address on an OMAP3630 (and I assume
>> omap34xx) which currently doesn't have OF support yet.
>>
>> Without this patch, the when driver attemps to write to mmc_base->sysconfig
>> at 4809c110 is used instead of mmc_base->sysconfig at 4809c010.  This makes 
>> any
>> attempt to use the mmc fail.  With this patch, I am able to read/write to the
>> MMC device with DM_MMC enabled with OF support.
>>
>> If there is a better solution, I am open to ideas.  I verified this against
>> the OMAP3530 TRM and OMAP3630 TRM.  Since AM3359 TRM has the same value,
>> it might be helpful for other boards, but I don't have them to test.  If 
>> there
>> is a better solution, I am perfectly open for suggestions.
>
> How about handling this in the same way as handled by Linux kernel
> omap_hsmmc driver?
>

I will concede that I originally misread the AM33xx TRM.   According
to it Table 18-14, the SYSSTATUS is offset 0x114, and the OMAP3
datasheet shows 0x14 consistent with the table in U-boot without the
x100 byte offset.

I believe my initial suggestion should work by checking
CONFIG_OMAP34XX.  If present, it will not add the offset.

Sorry for the noise, I'll clean up the patch and resubmit it.

adam

>>
>> If this gets reviewed and approved, I can push the OMAP3630 (and OMAP3) 
>> device
>> trees which might let more boards move to DM and OF support.
>>
>> Signed-off-by: Adam Ford 
>>
>> diff --git a/arch/arm/include/asm/omap_mmc.h 
>> b/arch/arm/include/asm/omap_mmc.h
>> index f2bf645..fd9b741 100644
>> --- a/arch/arm/include/asm/omap_mmc.h
>> +++ b/arch/arm/include/asm/omap_mmc.h
>> @@ -26,7 +26,7 @@
>>  #define OMAP_MMC_H_
>>
>>  struct hsmmc {
>> -#ifdef CONFIG_DM_MMC
>> +#if defined(CONFIG_DM_MMC) && !defined(OMAP34XX)
>>   unsigned char res0[0x100];
>>  #endif
>>   unsigned char res1[0x10];
>>
>
> --
> Regards
> Vignesh
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 8/8] defconfig: keystone: Enable DM I2C

[Franklin S Cooper Jr]

Now that the davinci I2C driver is converted to driver model enable
it in 66AK2Gx defconfig

Signed-off-by: Franklin S Cooper Jr 
---
 configs/k2e_evm_defconfig  | 1 +
 configs/k2g_evm_defconfig  | 1 +
 configs/k2hk_evm_defconfig | 1 +
 configs/k2l_evm_defconfig  | 1 +
 4 files changed, 4 insertions(+)

diff --git a/configs/k2e_evm_defconfig b/configs/k2e_evm_defconfig
index d319705..52e5bd4 100644
--- a/configs/k2e_evm_defconfig
+++ b/configs/k2e_evm_defconfig
@@ -54,3 +54,4 @@ CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_STORAGE=y
+CONFIG_DM_I2C=y
diff --git a/configs/k2g_evm_defconfig b/configs/k2g_evm_defconfig
index bbdcc2f..d4cdf61 100644
--- a/configs/k2g_evm_defconfig
+++ b/configs/k2g_evm_defconfig
@@ -58,3 +58,4 @@ CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_STORAGE=y
+CONFIG_DM_I2C=y
diff --git a/configs/k2hk_evm_defconfig b/configs/k2hk_evm_defconfig
index b22086d..7d22cd6 100644
--- a/configs/k2hk_evm_defconfig
+++ b/configs/k2hk_evm_defconfig
@@ -54,3 +54,4 @@ CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_STORAGE=y
+CONFIG_DM_I2C=y
diff --git a/configs/k2l_evm_defconfig b/configs/k2l_evm_defconfig
index 5a28112..ec2fcbf 100644
--- a/configs/k2l_evm_defconfig
+++ b/configs/k2l_evm_defconfig
@@ -54,3 +54,4 @@ CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_STORAGE=y
+CONFIG_DM_I2C=y
-- 
2.10.0

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

[U-Boot] [PATCH 0/8] drivers: i2c: davinci_i2c: Convert driver to DM

[Franklin S Cooper Jr]

This patch series converts the davinci i2c driver to use device model.
This updated driver has been verified on both Keystone K2G and Keystone
K2L evms by performing several i2c operations in U-boot prompt.

Some additional work was required to get things working on K2G due to
the code that reads the on board EEPROM. DM I2C sets the default address
length to a default value of 1 when the on EEPROM requires an address
length of 2. Therefore, an additional function and minor changes were
required to get things working properly.

Franklin S Cooper Jr (8):
  i2c: davinci: Split functions into two parts for future DM support
  drivers: i2c: davinci_i2c: Update davinci i2c driver to driver model
  ti: common: board_detect: Introduce function to set the address
length.
  ti: common: board_detect: Set alen to expected value before i2c read
  ARM: dts: k2g: Add I2C nodes to 66AK2Gx
  ARM: dts: keystone2: add I2C aliases for davinci I2C nodes
  ARM: dts: keystone-k2g-evm: Enable I2C0 and I2C1
  defconfig: keystone: Enable DM I2C

 arch/arm/dts/keystone-k2g-evm.dts |   8 ++
 arch/arm/dts/keystone-k2g.dtsi|  32 +
 arch/arm/dts/keystone.dtsi|   3 +
 board/ti/common/board_detect.c|  61 -
 configs/k2e_evm_defconfig |   1 +
 configs/k2g_evm_defconfig |   1 +
 configs/k2hk_evm_defconfig|   1 +
 configs/k2l_evm_defconfig |   1 +
 drivers/i2c/davinci_i2c.c | 277 +++---
 9 files changed, 306 insertions(+), 79 deletions(-)

-- 
2.10.0

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

[U-Boot] [PATCH 6/8] ARM: dts: keystone2: add I2C aliases for davinci I2C nodes

[Franklin S Cooper Jr]

Add aliases for I2C nodes required for the DM framework to probe the
davinci-i2c driver.

Signed-off-by: Franklin S Cooper Jr 
---
 arch/arm/dts/keystone.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/dts/keystone.dtsi b/arch/arm/dts/keystone.dtsi
index be97f3f..9a2e1f6 100644
--- a/arch/arm/dts/keystone.dtsi
+++ b/arch/arm/dts/keystone.dtsi
@@ -22,6 +22,9 @@
spi0 = 
spi1 = 
spi2 = 
+   i2c0 = 
+   i2c1 = 
+   i2c2 = 
};
 
chosen {
-- 
2.10.0

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

[U-Boot] [PATCH 4/8] ti: common: board_detect: Set alen to expected value before i2c read

[Franklin S Cooper Jr]

In non DM I2C read operations the address length passed in during a read
operation will be used automatically. However, in DM I2C the address length
is set to a default value of one which causes problems when trying to
perform a read with a differing alen. Therefore, before the first read in a
series of read operations set the alen to the correct value.

Signed-off-by: Franklin S Cooper Jr 
---
 board/ti/common/board_detect.c | 24 ++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/board/ti/common/board_detect.c b/board/ti/common/board_detect.c
index 1e695f4..6fdcb61 100644
--- a/board/ti/common/board_detect.c
+++ b/board/ti/common/board_detect.c
@@ -83,7 +83,17 @@ static int __maybe_unused ti_i2c_eeprom_init(int i2c_bus, 
int dev_addr)
 static int __maybe_unused ti_i2c_eeprom_read(int dev_addr, int offset,
 uchar *ep, int epsize)
 {
-   return i2c_read(dev_addr, offset, 2, ep, epsize);
+   int bus_num, rc, alen;
+
+   bus_num = i2c_get_bus_num();
+
+   alen = 2;
+
+   rc = ti_i2c_set_alen(bus_num, dev_addr, alen);
+   if (rc)
+   return rc;
+
+   return i2c_read(dev_addr, offset, alen, ep, epsize);
 }
 
 /**
@@ -125,6 +135,11 @@ static int __maybe_unused ti_i2c_eeprom_get(int bus_addr, 
int dev_addr,
 * Read the header first then only read the other contents.
 */
byte = 2;
+
+   rc = ti_i2c_set_alen(bus_addr, dev_addr, byte);
+   if (rc)
+   return rc;
+
rc = i2c_read(dev_addr, 0x0, byte, (uint8_t *)_read, 4);
if (rc)
return rc;
@@ -137,9 +152,14 @@ static int __maybe_unused ti_i2c_eeprom_get(int bus_addr, 
int dev_addr,
 * 1 byte address (some legacy boards need this..)
 */
byte = 1;
-   if (rc)
+   if (rc) {
+   rc = ti_i2c_set_alen(bus_addr, dev_addr, byte);
+   if (rc)
+   return rc;
+
rc = i2c_read(dev_addr, 0x0, byte, (uint8_t *)_read,
  4);
+   }
if (rc)
return rc;
}
-- 
2.10.0

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

[U-Boot] [PATCH 5/8] ARM: dts: k2g: Add I2C nodes to 66AK2Gx

[Franklin S Cooper Jr]

Add I2C nodes to the 66AK2Gx dtsi.

Signed-off-by: Franklin S Cooper Jr 
---
 arch/arm/dts/keystone-k2g.dtsi | 32 
 1 file changed, 32 insertions(+)

diff --git a/arch/arm/dts/keystone-k2g.dtsi b/arch/arm/dts/keystone-k2g.dtsi
index 2193f9f..191e3f1 100644
--- a/arch/arm/dts/keystone-k2g.dtsi
+++ b/arch/arm/dts/keystone-k2g.dtsi
@@ -24,6 +24,9 @@
spi2 = 
spi3 = 
spi4 = 
+   i2c0 = 
+   i2c1 = 
+   i2c2 = 
};
 
memory {
@@ -149,6 +152,35 @@
#size-cells = <0>;
status = "disabled";
};
+   i2c0: i2c@253 {
+   compatible = "ti,keystone-i2c";
+   reg = <0x0253 0x400>;
+   clock-frequency = <10>;
+   interrupts = ;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
+   i2c1: i2c@2530400 {
+   compatible = "ti,keystone-i2c";
+   reg = <0x02530400 0x400>;
+   clock-frequency = <10>;
+   interrupts = ;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
+   i2c2: i2c@2530800 {
+   compatible = "ti,keystone-i2c";
+   reg = <0x02530800 0x400>;
+   clock-frequency = <10>;
+   interrupts = ;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
 
mmc0: mmc@2300 {
compatible = "ti,omap4-hsmmc";
-- 
2.10.0

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

[U-Boot] [PATCH 7/8] ARM: dts: keystone-k2g-evm: Enable I2C0 and I2C1

[Franklin S Cooper Jr]

Enable I2C0 and I2C1 which is needed to enable usage of DM I2C.

Signed-off-by: Franklin S Cooper Jr 
---
 arch/arm/dts/keystone-k2g-evm.dts | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/dts/keystone-k2g-evm.dts 
b/arch/arm/dts/keystone-k2g-evm.dts
index 696a0d7..2c99df4 100644
--- a/arch/arm/dts/keystone-k2g-evm.dts
+++ b/arch/arm/dts/keystone-k2g-evm.dts
@@ -108,3 +108,11 @@
  {
status = "okay";
 };
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
-- 
2.10.0

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

[U-Boot] [PATCH 3/8] ti: common: board_detect: Introduce function to set the address length.

[Franklin S Cooper Jr]

Reading from the I2C EEPROM used typically requires using an address length
of 2. However, when using DM for I2C the default address length used is 1.
To fix this introduce a new function that allows the address length to be
changed. The logic to do so was copied from cmd/i2c.c.

Signed-off-by: Franklin S Cooper Jr 
---
 board/ti/common/board_detect.c | 37 +
 1 file changed, 37 insertions(+)

diff --git a/board/ti/common/board_detect.c b/board/ti/common/board_detect.c
index c55e24e..1e695f4 100644
--- a/board/ti/common/board_detect.c
+++ b/board/ti/common/board_detect.c
@@ -10,10 +10,47 @@
 
 #include 
 #include 
+#include 
 #include 
 
 #include "board_detect.h"
 
+#if defined(CONFIG_DM_I2C_COMPAT)
+/**
+ * ti_i2c_set_alen - Set chip's i2c address length
+ * @bus_addr - I2C bus number
+ * @dev_addr - I2C eeprom id
+ * @alen - I2C address length in bytes
+ *
+ * DM_I2C by default sets the address length to be used to 1. This
+ * function allows this address length to be changed to match the
+ * eeprom used for board detection.
+ */
+int __maybe_unused ti_i2c_set_alen(int bus_addr, int dev_addr, int alen)
+{
+   struct udevice *dev;
+   struct udevice *bus;
+   int rc;
+
+   rc = uclass_get_device_by_seq(UCLASS_I2C, bus_addr, );
+   if (rc)
+   return rc;
+   rc = i2c_get_chip(bus, dev_addr, 1, );
+   if (rc)
+   return rc;
+   rc = i2c_set_chip_offset_len(dev, alen);
+   if (rc)
+   return rc;
+
+   return 0;
+}
+#else
+int __maybe_unused ti_i2c_set_alen(int bus_addr, int dev_addr, int alen)
+{
+   return 0;
+}
+#endif
+
 /**
  * ti_i2c_eeprom_init - Initialize an i2c bus and probe for a device
  * @i2c_bus: i2c bus number to initialize
-- 
2.10.0

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

[U-Boot] [PATCH 2/8] drivers: i2c: davinci_i2c: Update davinci i2c driver to driver model

[Franklin S Cooper Jr]

Convert davinci i2c driver to driver model.

Signed-off-by: Franklin S Cooper Jr 
---
 drivers/i2c/davinci_i2c.c | 92 +--
 1 file changed, 90 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/davinci_i2c.c b/drivers/i2c/davinci_i2c.c
index a6bce26..4471193 100644
--- a/drivers/i2c/davinci_i2c.c
+++ b/drivers/i2c/davinci_i2c.c
@@ -14,11 +14,21 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include "davinci_i2c.h"
 
+#ifdef CONFIG_DM_I2C
+/* Information about i2c controller */
+struct i2c_bus {
+   int id;
+   uintspeed;
+   struct i2c_regs *regs;
+};
+#endif
+
 #define CHECK_NACK() \
do {\
if (tmp & (I2C_TIMEOUT | I2C_STAT_NACK)) {\
@@ -27,8 +37,6 @@
} \
} while (0)
 
-static struct i2c_regs *davinci_get_base(struct i2c_adapter *adap);
-
 static int _wait_for_bus(struct i2c_regs *i2c_base)
 {
int stat, timeout;
@@ -331,6 +339,7 @@ static int _davinci_i2c_probe_chip(struct i2c_regs 
*i2c_base, uint8_t chip)
return rc;
 }
 
+#ifndef CONFIG_DM_I2C
 static struct i2c_regs *davinci_get_base(struct i2c_adapter *adap)
 {
switch (adap->hwadapnr) {
@@ -420,3 +429,82 @@ U_BOOT_I2C_ADAP_COMPLETE(davinci_2, davinci_i2c_init, 
davinci_i2c_probe_chip,
 CONFIG_SYS_DAVINCI_I2C_SLAVE2,
 2)
 #endif
+
+#else /* CONFIG_DM_I2C */
+
+static int davinci_i2c_xfer(struct udevice *bus, struct i2c_msg *msg,
+ int nmsgs)
+{
+   struct i2c_bus *i2c_bus = dev_get_priv(bus);
+   int ret;
+
+   debug("i2c_xfer: %d messages\n", nmsgs);
+   for (; nmsgs > 0; nmsgs--, msg++) {
+   debug("i2c_xfer: chip=0x%x, len=0x%x\n", msg->addr, msg->len);
+   if (msg->flags & I2C_M_RD) {
+   ret = _davinci_i2c_read(i2c_bus->regs, msg->addr,
+   0, 0, msg->buf, msg->len);
+   } else {
+   ret = _davinci_i2c_write(i2c_bus->regs, msg->addr,
+   0, 0, msg->buf, msg->len);
+   }
+   if (ret) {
+   debug("i2c_write: error sending\n");
+   return -EREMOTEIO;
+   }
+   }
+
+   return ret;
+}
+
+static int davinci_i2c_set_speed(struct udevice *dev, uint speed)
+{
+   struct i2c_bus *i2c_bus = dev_get_priv(dev);
+
+   i2c_bus->speed = speed;
+   return _davinci_i2c_setspeed(i2c_bus->regs, speed);
+}
+
+static int davinci_i2c_probe(struct udevice *dev)
+{
+   struct i2c_bus *i2c_bus = dev_get_priv(dev);
+
+   i2c_bus->id = dev->seq;
+   i2c_bus->regs = (struct i2c_regs *)dev_get_addr(dev);
+
+   i2c_bus->speed = 10;
+_davinci_i2c_init(i2c_bus->regs, i2c_bus->speed, 0);
+
+   return 0;
+}
+
+static int davinci_i2c_probe_chip(struct udevice *bus, uint chip_addr,
+ uint chip_flags)
+{
+   struct i2c_bus *i2c_bus = dev_get_priv(bus);
+
+   return _davinci_i2c_probe_chip(i2c_bus->regs, chip_addr);
+}
+
+static const struct dm_i2c_ops davinci_i2c_ops = {
+   .xfer   = davinci_i2c_xfer,
+   .probe_chip = davinci_i2c_probe_chip,
+   .set_bus_speed  = davinci_i2c_set_speed,
+};
+
+static const struct udevice_id davinci_i2c_ids[] = {
+   { .compatible = "ti,davinci-i2c"},
+   { .compatible = "ti,keystone-i2c"},
+   { }
+};
+
+U_BOOT_DRIVER(i2c_davinci) = {
+   .name   = "i2c_davinci",
+   .id = UCLASS_I2C,
+   .of_match = davinci_i2c_ids,
+   .probe  = davinci_i2c_probe,
+   .priv_auto_alloc_size = sizeof(struct i2c_bus),
+   .ops= _i2c_ops,
+};
+
+#endif /* CONFIG_DM_I2C */
-- 
2.10.0

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

[U-Boot] [PATCH 1/8] i2c: davinci: Split functions into two parts for future DM support

[Franklin S Cooper Jr]

The i2c driver will be converted to support device model. In preparation
for that change split the various functions into two parts. This will
allow device model specific driver to reuse the majority of the code from
the non device model implementation.

Also rename the probe function to probe_chip to better reflect its
purpose.

Signed-off-by: Franklin S Cooper Jr 
---
 drivers/i2c/davinci_i2c.c | 185 +++---
 1 file changed, 110 insertions(+), 75 deletions(-)

diff --git a/drivers/i2c/davinci_i2c.c b/drivers/i2c/davinci_i2c.c
index c5bd38c..a6bce26 100644
--- a/drivers/i2c/davinci_i2c.c
+++ b/drivers/i2c/davinci_i2c.c
@@ -29,9 +29,8 @@
 
 static struct i2c_regs *davinci_get_base(struct i2c_adapter *adap);
 
-static int wait_for_bus(struct i2c_adapter *adap)
+static int _wait_for_bus(struct i2c_regs *i2c_base)
 {
-   struct i2c_regs *i2c_base = davinci_get_base(adap);
int stat, timeout;
 
REG(&(i2c_base->i2c_stat)) = 0x;
@@ -51,10 +50,8 @@ static int wait_for_bus(struct i2c_adapter *adap)
return 1;
 }
 
-
-static int poll_i2c_irq(struct i2c_adapter *adap, int mask)
+static int _poll_i2c_irq(struct i2c_regs *i2c_base, int mask)
 {
-   struct i2c_regs *i2c_base = davinci_get_base(adap);
int stat, timeout;
 
for (timeout = 0; timeout < 10; timeout++) {
@@ -68,10 +65,8 @@ static int poll_i2c_irq(struct i2c_adapter *adap, int mask)
return stat | I2C_TIMEOUT;
 }
 
-static void flush_rx(struct i2c_adapter *adap)
+static void _flush_rx(struct i2c_regs *i2c_base)
 {
-   struct i2c_regs *i2c_base = davinci_get_base(adap);
-
while (1) {
if (!(REG(&(i2c_base->i2c_stat)) & I2C_STAT_RRDY))
break;
@@ -82,9 +77,9 @@ static void flush_rx(struct i2c_adapter *adap)
}
 }
 
-static uint davinci_i2c_setspeed(struct i2c_adapter *adap, uint speed)
+static uint _davinci_i2c_setspeed(struct i2c_regs *i2c_base,
+ uint speed)
 {
-   struct i2c_regs *i2c_base = davinci_get_base(adap);
uint32_tdiv, psc;
 
psc = 2;
@@ -94,20 +89,18 @@ static uint davinci_i2c_setspeed(struct i2c_adapter *adap, 
uint speed)
REG(&(i2c_base->i2c_scll)) = (div * 50) / 100; /* 50% Duty */
REG(&(i2c_base->i2c_sclh)) = div - REG(&(i2c_base->i2c_scll));
 
-   adap->speed = speed;
return 0;
 }
 
-static void davinci_i2c_init(struct i2c_adapter *adap, int speed, int slaveadd)
+static void _davinci_i2c_init(struct i2c_regs *i2c_base,
+ uint speed, int slaveadd)
 {
-   struct i2c_regs *i2c_base = davinci_get_base(adap);
-
if (REG(&(i2c_base->i2c_con)) & I2C_CON_EN) {
REG(&(i2c_base->i2c_con)) = 0;
udelay(5);
}
 
-   davinci_i2c_setspeed(adap, speed);
+   _davinci_i2c_setspeed(i2c_base, speed);
 
REG(&(i2c_base->i2c_oa)) = slaveadd;
REG(&(i2c_base->i2c_cnt)) = 0;
@@ -122,47 +115,9 @@ static void davinci_i2c_init(struct i2c_adapter *adap, int 
speed, int slaveadd)
udelay(1000);
 }
 
-static int davinci_i2c_probe(struct i2c_adapter *adap, uint8_t chip)
+static int _davinci_i2c_read(struct i2c_regs *i2c_base, uint8_t chip,
+uint32_t addr, int alen, uint8_t *buf, int len)
 {
-   struct i2c_regs *i2c_base = davinci_get_base(adap);
-   int rc = 1;
-
-   if (chip == REG(&(i2c_base->i2c_oa)))
-   return rc;
-
-   REG(&(i2c_base->i2c_con)) = 0;
-   if (wait_for_bus(adap))
-   return 1;
-
-   /* try to read one byte from current (or only) address */
-   REG(&(i2c_base->i2c_cnt)) = 1;
-   REG(&(i2c_base->i2c_sa))  = chip;
-   REG(&(i2c_base->i2c_con)) = (I2C_CON_EN | I2C_CON_MST | I2C_CON_STT |
-I2C_CON_STP);
-   udelay(5);
-
-   if (!(REG(&(i2c_base->i2c_stat)) & I2C_STAT_NACK)) {
-   rc = 0;
-   flush_rx(adap);
-   REG(&(i2c_base->i2c_stat)) = 0x;
-   } else {
-   REG(&(i2c_base->i2c_stat)) = 0x;
-   REG(&(i2c_base->i2c_con)) |= I2C_CON_STP;
-   udelay(2);
-   if (wait_for_bus(adap))
-   return 1;
-   }
-
-   flush_rx(adap);
-   REG(&(i2c_base->i2c_stat)) = 0x;
-   REG(&(i2c_base->i2c_cnt)) = 0;
-   return rc;
-}
-
-static int davinci_i2c_read(struct i2c_adapter *adap, uint8_t chip,
-   uint32_t addr, int alen, uint8_t *buf, int len)
-{
-   struct i2c_regs *i2c_base = davinci_get_base(adap);
uint32_ttmp;
int i;
 
@@ -171,7 +126,7 @@ static int davinci_i2c_read(struct i2c_adapter *adap, 
uint8_t chip,
return 1;
}
 
-   if (wait_for_bus(adap))
+   if (_wait_for_bus(i2c_base))
return 1;
 
if 

Re: [U-Boot] [PATCH v6 1/3] arm: dts: update Meson GXBB / Odroid-C2 DT with latest Linux version

[felix zihlmann]

Am Montag, den 10.04.2017, 21:07 +0200 schrieb Heiner Kallweit:
> Am 10.04.2017 um 21:03 schrieb felix zihlmann:
> > Hi,
> > 
> > I have tried this patch-set (applied to u-boot-2017.03) on a Odroid-C2.
> > Booting from SD card works fine. However booting form eMMC card (128GB
> > from Hardkernel) produces the following error:
> > 
> > => fatload mmc 0:1 ${initrd_loadaddr} ${initrdfile}
> > Card did not respond to voltage select!
> > mmc_init: -95, time 9
> > ** Bad device mmc 0 **
> 
> mmc 0 is the SD slot. When doing "mmc list" you should see:
> 
> => mmc list
> mmc@72000: 0
> mmc@74000: 1 (eMMC)
> 
> So you have to do "fatload mmc 1:1 ..."
> 
> Heiner

That was it! Thanks very much. You can add me as tested-by if you like.

Felix
> 
> > Setting max-frequency to 60MHz does not help.
> > 
> > Booting from the eMMC card using the Hardkernel u-boot and the
> > Hardkernel kernel works fine.
> > 
> > Thanks!
> > 
> > Felix
> > 
> > 
> 


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

Re: [U-Boot] [PATCH v3 0/6] Introduce DCU support for Vybrid

[Stefan Agner]

Stefano,

This patchset has been on the ML for a quite a while, any chance to get
this still into v2017.05?

--
Stefan

On 2017-04-10 22:42, Sanchayan Maity wrote:
> Hello,
> 
> This patchset adds support for the Freescale/NXP Display Controller Unit 
> (DCU4)
> for Vybrid which is found on the LS1021A and Vybrid SoC.
> 
> Patch series is based on top of latest u-boot master.
> 
> First patch in the series renames existing CONFIG_FSL_DCU_FB to
> CONFIG_VIDEO_FSL_DCU_FB and then converts it to Kconfig. All board defconfigs
> affected by this patch have been compile tested.
> 
> Patch 2-5 introduce incremental changes for supporting DCU on Vybrid.
> 
> Patch 6 in the series adds DCU support to Vybrid and has been tested on
> Toradex Colibri VF61 module.
> 
> Will appreciate it if the maintainers or users of LS1021 SoC can test this to
> check and report regressions if any.
> 
> Changes since v2:
> 1. Rebase on top of latest u-boot master
> 2. Drop the fourth patch in earlier series and replace it with a fix for
> DCU_MODE_BLEND_ITER and use the existing DCU_LAYER_MAX_NUM instead of
> introducing DCU_TOTAL_LAYER_NUM as earlier incoporating Stefan's feedback.
> 
> Changes since v1:
> 1. Rebase of top of latest u-boot master
> 2. Fix a bug present in v1 patch series which resulted in noisy screen when
> switching from u-boot to Linux. Patch fixed is second in this series.
> 
> v1:
> https://lists.denx.de/pipermail/u-boot/2017-February/280281.html
> 
> v2:
> https://www.mail-archive.com/u-boot@lists.denx.de/msg243132.html
> 
> Thanks & Regards,
> Sanchayan.
> 
> Sanchayan Maity (1):
>   Convert CONFIG_FSL_DCU_FB to Kconfig
> 
> Stefan Agner (5):
>   video: fsl_dcu_fb: fix framebuffer to the end of memory
>   video: fsl_dcu_fb: Enable pixel clock after initialization
>   video: fsl_dcu_fb: Fix DCU_MODE_BLEND_ITER setting
>   video: fsl_dcu_fb: add additional modes for DCU
>   board: toradex: colibri_vf: Add DCU support for Colibri Vybrid
> 
>  arch/arm/cpu/armv7/ls102xa/soc.c   |   2 +-
>  arch/arm/include/asm/arch-vf610/crm_regs.h |  14 +++
>  arch/arm/include/asm/arch-vf610/imx-regs.h |   2 +
>  arch/arm/include/asm/arch-vf610/iomux-vf610.h  |  31 ++
>  arch/arm/include/asm/imx-common/iomux-v3.h |   3 +
>  board/freescale/ls1021aiot/Makefile|   2 +-
>  board/freescale/ls1021aqds/Makefile|   2 +-
>  board/freescale/ls1021atwr/Makefile|   2 +-
>  board/toradex/colibri_vf/Makefile  |   1 +
>  board/toradex/colibri_vf/colibri_vf.c  |  76 ++---
>  board/toradex/colibri_vf/dcu.c |  38 +++
>  configs/colibri_vf_defconfig   |   4 +
>  configs/ls1021aqds_ddr4_nor_defconfig  |   1 +
>  configs/ls1021aqds_ddr4_nor_lpuart_defconfig   |   1 +
>  configs/ls1021aqds_nand_defconfig  |   1 +
>  configs/ls1021aqds_nor_SECURE_BOOT_defconfig   |   1 +
>  configs/ls1021aqds_nor_defconfig   |   1 +
>  configs/ls1021aqds_nor_lpuart_defconfig|   1 +
>  configs/ls1021aqds_qspi_defconfig  |   1 +
>  configs/ls1021aqds_sdcard_ifc_defconfig|   1 +
>  configs/ls1021aqds_sdcard_qspi_defconfig   |   1 +
>  configs/ls1021atwr_nor_SECURE_BOOT_defconfig   |   1 +
>  configs/ls1021atwr_nor_defconfig   |   1 +
>  configs/ls1021atwr_nor_lpuart_defconfig|   1 +
>  configs/ls1021atwr_qspi_defconfig  |   1 +
>  .../ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig|   1 +
>  configs/ls1021atwr_sdcard_ifc_defconfig|   1 +
>  configs/ls1021atwr_sdcard_qspi_defconfig   |   1 +
>  drivers/video/Kconfig  |  15 +++
>  drivers/video/Makefile |   2 +-
>  drivers/video/fsl_dcu_fb.c | 121 
> ++---
>  include/configs/colibri_vf.h   |  13 +++
>  include/configs/ls1021aqds.h   |   4 +-
>  include/configs/ls1021atwr.h   |   4 +-
>  include/fsl_dcu_fb.h   |   1 +
>  scripts/config_whitelist.txt   |   1 -
>  36 files changed, 313 insertions(+), 41 deletions(-)
>  create mode 100644 board/toradex/colibri_vf/dcu.c
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 1/6] Convert CONFIG_FSL_DCU_FB to Kconfig

[Stefan Agner]

On 2017-04-10 22:42, Sanchayan Maity wrote:
> Rename CONFIG_FSL_DCU_FB to CONFIG_VIDEO_FSL_DCU_FB
> and convert it to Kconfig.

Looks good to me.

Reviewed-by: Stefan Agner 

--
Stefan

> 
> Signed-off-by: Sanchayan Maity 
> ---
>  arch/arm/cpu/armv7/ls102xa/soc.c| 2 +-
>  board/freescale/ls1021aiot/Makefile | 2 +-
>  board/freescale/ls1021aqds/Makefile | 2 +-
>  board/freescale/ls1021atwr/Makefile | 2 +-
>  configs/ls1021aqds_ddr4_nor_defconfig   | 1 +
>  configs/ls1021aqds_ddr4_nor_lpuart_defconfig| 1 +
>  configs/ls1021aqds_nand_defconfig   | 1 +
>  configs/ls1021aqds_nor_SECURE_BOOT_defconfig| 1 +
>  configs/ls1021aqds_nor_defconfig| 1 +
>  configs/ls1021aqds_nor_lpuart_defconfig | 1 +
>  configs/ls1021aqds_qspi_defconfig   | 1 +
>  configs/ls1021aqds_sdcard_ifc_defconfig | 1 +
>  configs/ls1021aqds_sdcard_qspi_defconfig| 1 +
>  configs/ls1021atwr_nor_SECURE_BOOT_defconfig| 1 +
>  configs/ls1021atwr_nor_defconfig| 1 +
>  configs/ls1021atwr_nor_lpuart_defconfig | 1 +
>  configs/ls1021atwr_qspi_defconfig   | 1 +
>  configs/ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig | 1 +
>  configs/ls1021atwr_sdcard_ifc_defconfig | 1 +
>  configs/ls1021atwr_sdcard_qspi_defconfig| 1 +
>  drivers/video/Kconfig   | 7 +++
>  drivers/video/Makefile  | 2 +-
>  include/configs/ls1021aqds.h| 4 +---
>  include/configs/ls1021atwr.h| 4 +---
>  scripts/config_whitelist.txt| 1 -
>  25 files changed, 30 insertions(+), 12 deletions(-)
> 
> diff --git a/arch/arm/cpu/armv7/ls102xa/soc.c 
> b/arch/arm/cpu/armv7/ls102xa/soc.c
> index 52fb6f8d51..b84a1a686a 100644
> --- a/arch/arm/cpu/armv7/ls102xa/soc.c
> +++ b/arch/arm/cpu/armv7/ls102xa/soc.c
> @@ -91,7 +91,7 @@ int arch_soc_init(void)
>   out_be32(>qspi_cfg, SCFG_QSPI_CLKSEL);
>  #endif
>  
> -#ifdef CONFIG_FSL_DCU_FB
> +#ifdef CONFIG_VIDEO_FSL_DCU_FB
>   out_be32(>pixclkcr, SCFG_PIXCLKCR_PXCKEN);
>  #endif
>  
> diff --git a/board/freescale/ls1021aiot/Makefile
> b/board/freescale/ls1021aiot/Makefile
> index 05709e685c..6b960aa61c 100644
> --- a/board/freescale/ls1021aiot/Makefile
> +++ b/board/freescale/ls1021aiot/Makefile
> @@ -5,5 +5,5 @@
>  #
>  
>  obj-y += ls1021aiot.o
> -obj-$(CONFIG_FSL_DCU_FB) += dcu.o
> +obj-$(CONFIG_VIDEO_FSL_DCU_FB) += dcu.o
>  obj-$(CONFIG_ARMV7_PSCI) += psci.o
> diff --git a/board/freescale/ls1021aqds/Makefile
> b/board/freescale/ls1021aqds/Makefile
> index f0390c129f..1e50e468a3 100644
> --- a/board/freescale/ls1021aqds/Makefile
> +++ b/board/freescale/ls1021aqds/Makefile
> @@ -7,5 +7,5 @@
>  obj-y += ls1021aqds.o
>  obj-y += ddr.o
>  obj-y += eth.o
> -obj-$(CONFIG_FSL_DCU_FB) += dcu.o
> +obj-$(CONFIG_VIDEO_FSL_DCU_FB) += dcu.o
>  obj-$(CONFIG_ARMV7_PSCI) += psci.o
> diff --git a/board/freescale/ls1021atwr/Makefile
> b/board/freescale/ls1021atwr/Makefile
> index 5238b158d7..d9a2f52f2b 100644
> --- a/board/freescale/ls1021atwr/Makefile
> +++ b/board/freescale/ls1021atwr/Makefile
> @@ -5,5 +5,5 @@
>  #
>  
>  obj-y += ls1021atwr.o
> -obj-$(CONFIG_FSL_DCU_FB) += dcu.o
> +obj-$(CONFIG_VIDEO_FSL_DCU_FB) += dcu.o
>  obj-$(CONFIG_ARMV7_PSCI) += psci.o
> diff --git a/configs/ls1021aqds_ddr4_nor_defconfig
> b/configs/ls1021aqds_ddr4_nor_defconfig
> index 8434870af3..5566053ae9 100644
> --- a/configs/ls1021aqds_ddr4_nor_defconfig
> +++ b/configs/ls1021aqds_ddr4_nor_defconfig
> @@ -43,3 +43,4 @@ CONFIG_USB_XHCI_HCD=y
>  CONFIG_USB_XHCI_DWC3=y
>  CONFIG_USB_STORAGE=y
>  # CONFIG_VIDEO_SW_CURSOR is not set
> +CONFIG_VIDEO_FSL_DCU_FB=y
> diff --git a/configs/ls1021aqds_ddr4_nor_lpuart_defconfig
> b/configs/ls1021aqds_ddr4_nor_lpuart_defconfig
> index ece220bf94..9582662e53 100644
> --- a/configs/ls1021aqds_ddr4_nor_lpuart_defconfig
> +++ b/configs/ls1021aqds_ddr4_nor_lpuart_defconfig
> @@ -44,3 +44,4 @@ CONFIG_USB_XHCI_HCD=y
>  CONFIG_USB_XHCI_DWC3=y
>  CONFIG_USB_STORAGE=y
>  # CONFIG_VIDEO_SW_CURSOR is not set
> +CONFIG_VIDEO_FSL_DCU_FB=y
> diff --git a/configs/ls1021aqds_nand_defconfig
> b/configs/ls1021aqds_nand_defconfig
> index dc547b5e0d..73f2fb070d 100644
> --- a/configs/ls1021aqds_nand_defconfig
> +++ b/configs/ls1021aqds_nand_defconfig
> @@ -57,3 +57,4 @@ CONFIG_USB_XHCI_HCD=y
>  CONFIG_USB_XHCI_DWC3=y
>  CONFIG_USB_STORAGE=y
>  # CONFIG_VIDEO_SW_CURSOR is not set
> +CONFIG_VIDEO_FSL_DCU_FB=y
> diff --git a/configs/ls1021aqds_nor_SECURE_BOOT_defconfig
> b/configs/ls1021aqds_nor_SECURE_BOOT_defconfig
> index d1760ed742..74e1241974 100644
> --- a/configs/ls1021aqds_nor_SECURE_BOOT_defconfig
> +++ b/configs/ls1021aqds_nor_SECURE_BOOT_defconfig
> @@ -43,5 +43,6 @@ CONFIG_USB_XHCI_HCD=y
>  CONFIG_USB_XHCI_DWC3=y
>  

[U-Boot] [PATCH] imx: ventana: config: set MMC env Partition to 1

[Tim Harvey]

Partition 1 equates to EMMC boot0

Signed-off-by: Tim Harvey 
---
 include/configs/gw_ventana.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/gw_ventana.h b/include/configs/gw_ventana.h
index c3908de..8191d43 100644
--- a/include/configs/gw_ventana.h
+++ b/include/configs/gw_ventana.h
@@ -232,6 +232,7 @@
 #endif
 #if defined(CONFIG_ENV_IS_IN_MMC)
   #define CONFIG_SYS_MMC_ENV_DEV 0
+  #define CONFIG_SYS_MMC_ENV_PART1
   #define CONFIG_ENV_OFFSET  (709 * SZ_1K)
   #define CONFIG_ENV_SIZE(128 * SZ_1K)
   #define CONFIG_ENV_OFFSET_REDUND   (CONFIG_ENV_OFFSET + (128 * SZ_1K))
-- 
2.7.4

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

Re: [U-Boot] [PATCH v4 00/16] GPT over MTD

[Patrick DELAUNAY]

From: Tom Rini [mailto:tr...@konsulko.com]
Sent: vendredi 7 avril 2017 18:26
> 
> On Wed, Mar 15, 2017 at 03:11:31PM +0100, Patrick Delaunay wrote:
> 
> >
> > I have a request to support GPT over MTD to have the MTD informations
> > without U-Boot environment(CONFIG_ENV_IS_NOWHERE is a other
> > requirement of my project to manage several board configuration with
> > the same defconfig; boot from NAND or NOR or SDCARD).
> >
> > The current idea is to use the GPT header format to save the
> > partitioning information directly in flash device (NOR or NAND), then
> > the U-Boot MTD variables are rebuild from these GPT partitions and can
> > be used by DISTRO command to search bootable binary.
> >
> > This information are directly used by BootRom to locate and load the
> > first bootstage.
> >
> > The added code is under a new CONFIG : CONFIG_EFI_PARTITION_MTD
> and in
> > the new file "disk/part_efi_mtd.c"
> >
> > For implementation details, see doc/README.gpt.mtd
> >
> > TODO: full support for modified command (if needed)
> >   today I limit the support for the command expected
> >   used by DISTRO macro:
> >   + gpt write
> >   + part list
> 
> ... what I said just now to v3 applies here really, sorry for the confusion.
> 
> --
> Tom

Hi, Tom

Sorry I don't expect some issue in boards as I only modify file system part 
under compilation flag (expect includes).

Today I already see one issue in patch 08 (because I include linux/mtd/mtd.h, 
part.h and that cause error for some boards)

I will correct all the errors and  warnings for all boards, rebase my patch on 
latest master version and push a PATCH version 5 soon.

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

Re: [U-Boot] [PATCH 1/3] fsl: PPA: add support PPA image validation from NAND and SD

[Sumit Garg]

> -Original Message-
> From: York Sun [mailto:york@nxp.com]
> Sent: Tuesday, April 11, 2017 9:09 PM
> To: Sumit Garg ; u-boot@lists.denx.de
> Cc: Ruchika Gupta ; Prabhakar Kushwaha
> ; Vini Pillai ; Udit
> Agarwal 
> Subject: Re: [PATCH 1/3] fsl: PPA: add support PPA image validation from
> NAND and SD
> 
> On 04/11/2017 04:59 AM, Sumit Garg wrote:
> >> -Original Message-
> >> From: York Sun [mailto:york@nxp.com]
> >> Sent: Tuesday, April 11, 2017 11:44 AM
> >> To: Sumit Garg ; u-boot@lists.denx.de
> >> Cc: Ruchika Gupta ; Prabhakar Kushwaha
> >> ; Vini Pillai ;
> >> Udit Agarwal 
> >> Subject: Re: [PATCH 1/3] fsl: PPA: add support PPA image validation
> >> from NAND and SD
> >>
> >> On 04/10/2017 10:54 PM, Sumit Garg wrote:
>  -Original Message-
>  From: York Sun [mailto:york@nxp.com]
>  Sent: Monday, April 10, 2017 10:39 PM
>  To: Sumit Garg ; u-boot@lists.denx.de
>  Cc: Ruchika Gupta ; Prabhakar Kushwaha
>  ; Vini Pillai ;
>  Udit Agarwal 
>  Subject: Re: [PATCH 1/3] fsl: PPA: add support PPA image validation
>  from NAND and SD
> 
>  On 04/07/2017 04:41 AM, Sumit Garg wrote:
> > Signed-off-by: Sumit Garg 
> > Signed-off-by: Udit Agarwal 
> > Tested-by: Vinitha Pillai 
> > ---
> >  arch/arm/cpu/armv8/fsl-layerscape/ppa.c | 67
> > -
> >  1 file changed, 66 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/ppa.c
> > b/arch/arm/cpu/armv8/fsl-layerscape/ppa.c
> > index 7f87bb8..d8f1d36 100644
> > --- a/arch/arm/cpu/armv8/fsl-layerscape/ppa.c
> > +++ b/arch/arm/cpu/armv8/fsl-layerscape/ppa.c
> > @@ -39,6 +39,10 @@ int ppa_init(void)  #ifdef
> CONFIG_CHAIN_OF_TRUST
> > uintptr_t ppa_esbc_hdr = CONFIG_SYS_LS_PPA_ESBC_ADDR;
> 
>  For MMC and NAND, this CONFIG_SYS_LS_PPA_ESBC_ADDR is actually
> not
>  used.
>  Shall we move the assignment down to XIP section? The Kconfig
>  should also be updated.
> 
>  York
> >>>
> >>> As per PPA verification patch for eMMC/SD and NAND:
> >>>
> >>> --- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> >>> +++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> >>> @@ -179,12 +179,22 @@ config SYS_LS_PPA_ESBC_ADDR
> >>>   default 0x4074 if SYS_LS_PPA_FW_IN_XIP && ARCH_LS1046A
> >>>   default 0x4048 if SYS_LS_PPA_FW_IN_XIP && ARCH_LS1012A
> >>>   default 0x580c4 if SYS_LS_PPA_FW_IN_XIP && FSL_LSCH3
> >>> + default 0x70 if SYS_LS_PPA_FW_IN_MMC
> >>> + default 0x70 if SYS_LS_PPA_FW_IN_NAND
> >>>   help
> >>> If the PPA header firmware locate at XIP flash, such as NOR or
> >>> QSPI flash, this address is a directly memory-mapped.
> >>> If it is in a serial accessed flash, such as NAND and SD
> >>> card, it is a byte offset.
> >>>
> >>> CONFIG_SYS_LS_PPA_ESBC_ADDR is used to provide offset on eMMC/SD
> >> and NAND.
> >>>
> >>
> >> That's exactly what I was referring to. You are _NOT_ using
> >> CONFIG_SYS_LS_PPA_ESBC_ADDR value for eMMC/SD or NAND. Instead,
> you
> >> use malloc to get a new memory for the header, which I agree it is right to
> do.
> >> So the macro CONFIG_SYS_LS_PPA_ESBC_ADDR is not used for either MMC
> >> or NAND.
> >>
> >> York
> >
> > Actually I am using CONFIG_SYS_LS_PPA_ESBC_ADDR in case of eMMC/SD or
> NAND as follows:
> >
> > For eMMC/SD:
> > +   blk = CONFIG_SYS_LS_PPA_ESBC_ADDR >> 9;
> > +   cnt = DIV_ROUND_UP(CONFIG_LS_PPA_ESBC_HDR_SIZE, 512);
> > +   ret = mmc->block_dev.block_read(>block_dev, blk, cnt,
> ppa_hdr_ddr);
> > +   if (ret != cnt) {
> > +   free(ppa_hdr_ddr);
> > +   printf("MMC/SD read of PPA header failed\n");
> > +   return -EIO;
> > +   }
> >
> > For NAND:
> > +   ret = nand_read(nand_info[0],
> (loff_t)CONFIG_SYS_LS_PPA_ESBC_ADDR,
> > +  _length, (u_char *)ppa_hdr_ddr);
> > +   if (ret == -EUCLEAN) {
> > +   free(ppa_hdr_ddr);
> > +   printf("NAND read of PPA firmware at offset 0x%x failed\n",
> > +  CONFIG_SYS_LS_PPA_FW_ADDR);
> > +   return -EIO;
> > +   }
> >
> 
> So you are using this macro, but not using it directly as the way for XIP. It 
> is
> confusing to see the assignment
> 
> ppa_esbc_hdr = CONFIG_SYS_LS_PPA_ESBC_ADDR;
> 
> I was suggesting to move this assignment down to the XIP section.
> 
> York
 
Yes you are correct, I will move this assignment to XIP section in next version 
of this patch-set.

Sumit
___
U-Boot mailing list

Re: [U-Boot] [PATCH] include: configs: Fix build warnings due to redefined

[Tom Rini]

On Tue, Apr 11, 2017 at 05:57:42PM +0200, Marek Vasut wrote:
> On 04/11/2017 05:53 PM, suniel.spar...@gmail.com wrote:
> > From: Suniel Mahesh 
> > 
> > Driver model for OMAP24XX and later Multichannel SPI master controller,
> > if used, OMAP3 SPI configuration is set.
> > The same configuration is defined in ti_armv7_omap.h, because
> > of redefinition, warnings are spilled during build.
> 
> If it's set by Kconfig, it should NOT be set in include/configs/ .
> If I understand the explanation right, it is set by Kconfig and thus
> this patch is wrong. The correct fix is to remove it from here and
> verify that no board is affected.

Correct, moveconfig.py needs to be run to migrate the rest of the users
over.  Thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] include: configs: Fix build warnings due to redefined

[Marek Vasut]

On 04/11/2017 05:53 PM, suniel.spar...@gmail.com wrote:
> From: Suniel Mahesh 
> 
> Driver model for OMAP24XX and later Multichannel SPI master controller,
> if used, OMAP3 SPI configuration is set.
> The same configuration is defined in ti_armv7_omap.h, because
> of redefinition, warnings are spilled during build.

If it's set by Kconfig, it should NOT be set in include/configs/ .
If I understand the explanation right, it is set by Kconfig and thus
this patch is wrong. The correct fix is to remove it from here and
verify that no board is affected.

> Fixed warnings for AM335x SOC by using #ifndef directive in
> ti_armv7_omap.h.
> 
> Signed-off-by: Suniel Mahesh 
> ---
> Note:
> Tested on Beaglebone Black using latest u-boot mainline tree
> with device tree set
> ---
>  include/configs/ti_armv7_omap.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/include/configs/ti_armv7_omap.h b/include/configs/ti_armv7_omap.h
> index de14b85..3167b61 100644
> --- a/include/configs/ti_armv7_omap.h
> +++ b/include/configs/ti_armv7_omap.h
> @@ -21,7 +21,9 @@
>  #define CONFIG_SYS_I2C_OMAP24XX
>  
>  /* SPI IP Block */
> +#ifndef CONFIG_OMAP3_SPI
>  #define CONFIG_OMAP3_SPI
> +#endif
>  
>  /* GPIO block */
>  #define CONFIG_OMAP_GPIO
> 


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

[U-Boot] [PATCH] include: configs: Fix build warnings due to redefined

[suniel . spartan]

From: Suniel Mahesh 

Driver model for OMAP24XX and later Multichannel SPI master controller,
if used, OMAP3 SPI configuration is set.
The same configuration is defined in ti_armv7_omap.h, because
of redefinition, warnings are spilled during build.

Fixed warnings for AM335x SOC by using #ifndef directive in
ti_armv7_omap.h.

Signed-off-by: Suniel Mahesh 
---
Note:
Tested on Beaglebone Black using latest u-boot mainline tree
with device tree set
---
 include/configs/ti_armv7_omap.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/configs/ti_armv7_omap.h b/include/configs/ti_armv7_omap.h
index de14b85..3167b61 100644
--- a/include/configs/ti_armv7_omap.h
+++ b/include/configs/ti_armv7_omap.h
@@ -21,7 +21,9 @@
 #define CONFIG_SYS_I2C_OMAP24XX
 
 /* SPI IP Block */
+#ifndef CONFIG_OMAP3_SPI
 #define CONFIG_OMAP3_SPI
+#endif
 
 /* GPIO block */
 #define CONFIG_OMAP_GPIO
-- 
1.9.1

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

Re: [U-Boot] Please pull ARC changes

[Tom Rini]

On Tue, Apr 11, 2017 at 02:56:44PM +, Alexey Brodkin wrote:

> Hi Tom,
> 
> There's just a minor but quite important fix for ARC to be pulled from my 
> tree.
> Anyways please pull it.
> 
> The following changes since commit 9963890b8be1d208035945abc5ba9f77637b6542:
> 
>   libfdt: fix build with Python 3 (2017-04-10 13:25:19 -0600)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-arc.git 
> 
> for you to fetch changes up to 40a808f173008729a0c631ab84693b6a2b0dcfc9:
> 
>   ARCv2: SLC: Make sure busy bit is set properly on SLC flushing (2017-04-11 
> 17:54:31 +0300)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

[U-Boot] [PATCH] arc: arcv1: Disable master/slave check

[Alexey Brodkin]

ARCompact cores are not supposed to be used in SMP designs
(this doesn't stop people from creation of heterogeneous chips,
for an example keep reading) so there's no point in
checking ARCNUM and halting somebody if we build for ARC700.

Moreover on AXS101 board we have ARC770 in the ASIC together with
other ARC cores and ARC770 happens to be the last node in JTAG chain
with ARCNUM = 4. And existing check halts the one and only core we
want keep running.

Signed-off-by: Alexey Brodkin 
---
 arch/arc/lib/start.S | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arc/lib/start.S b/arch/arc/lib/start.S
index b2ba7683097f..95d64f9d4375 100644
--- a/arch/arc/lib/start.S
+++ b/arch/arc/lib/start.S
@@ -10,6 +10,9 @@
 #include 
 
 ENTRY(_start)
+; ARCompact devices are not supposed to be SMP so master/slave check
+; makes no sense.
+#ifdef CONFIG_ISA_ARCV2
; Non-masters will be halted immediately, they might be kicked later
; by platform code right before passing control to the Linux kernel
; in bootm.c:boot_jump_linux().
@@ -25,6 +28,7 @@ ENTRY(_start)
nop
 
 .Lmaster_proceed:
+#endif
 
/* Setup interrupt vector base that matches "__text_start" */
sr  __ivt_start, [ARC_AUX_INTR_VEC_BASE]
-- 
2.7.4

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

Re: [U-Boot] [PATCH 1/3] fsl: PPA: add support PPA image validation from NAND and SD

[York Sun]

On 04/11/2017 04:59 AM, Sumit Garg wrote:

-Original Message-
From: York Sun [mailto:york@nxp.com]
Sent: Tuesday, April 11, 2017 11:44 AM
To: Sumit Garg ; u-boot@lists.denx.de
Cc: Ruchika Gupta ; Prabhakar Kushwaha
; Vini Pillai ; Udit
Agarwal 
Subject: Re: [PATCH 1/3] fsl: PPA: add support PPA image validation from
NAND and SD

On 04/10/2017 10:54 PM, Sumit Garg wrote:

-Original Message-
From: York Sun [mailto:york@nxp.com]
Sent: Monday, April 10, 2017 10:39 PM
To: Sumit Garg ; u-boot@lists.denx.de
Cc: Ruchika Gupta ; Prabhakar Kushwaha
; Vini Pillai ;
Udit Agarwal 
Subject: Re: [PATCH 1/3] fsl: PPA: add support PPA image validation
from NAND and SD

On 04/07/2017 04:41 AM, Sumit Garg wrote:

Signed-off-by: Sumit Garg 
Signed-off-by: Udit Agarwal 
Tested-by: Vinitha Pillai 
---
 arch/arm/cpu/armv8/fsl-layerscape/ppa.c | 67
-
 1 file changed, 66 insertions(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/ppa.c
b/arch/arm/cpu/armv8/fsl-layerscape/ppa.c
index 7f87bb8..d8f1d36 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/ppa.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/ppa.c
@@ -39,6 +39,10 @@ int ppa_init(void)  #ifdef CONFIG_CHAIN_OF_TRUST
uintptr_t ppa_esbc_hdr = CONFIG_SYS_LS_PPA_ESBC_ADDR;


For MMC and NAND, this CONFIG_SYS_LS_PPA_ESBC_ADDR is actually not
used.
Shall we move the assignment down to XIP section? The Kconfig should
also be updated.

York


As per PPA verification patch for eMMC/SD and NAND:

--- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
@@ -179,12 +179,22 @@ config SYS_LS_PPA_ESBC_ADDR
default 0x4074 if SYS_LS_PPA_FW_IN_XIP && ARCH_LS1046A
default 0x4048 if SYS_LS_PPA_FW_IN_XIP && ARCH_LS1012A
default 0x580c4 if SYS_LS_PPA_FW_IN_XIP && FSL_LSCH3
+   default 0x70 if SYS_LS_PPA_FW_IN_MMC
+   default 0x70 if SYS_LS_PPA_FW_IN_NAND
help
  If the PPA header firmware locate at XIP flash, such as NOR or
  QSPI flash, this address is a directly memory-mapped.
  If it is in a serial accessed flash, such as NAND and SD
  card, it is a byte offset.

CONFIG_SYS_LS_PPA_ESBC_ADDR is used to provide offset on eMMC/SD

and NAND.




That's exactly what I was referring to. You are _NOT_ using
CONFIG_SYS_LS_PPA_ESBC_ADDR value for eMMC/SD or NAND. Instead, you
use malloc to get a new memory for the header, which I agree it is right to do.
So the macro CONFIG_SYS_LS_PPA_ESBC_ADDR is not used for either MMC or
NAND.

York


Actually I am using CONFIG_SYS_LS_PPA_ESBC_ADDR in case of eMMC/SD or NAND as 
follows:

For eMMC/SD:
+   blk = CONFIG_SYS_LS_PPA_ESBC_ADDR >> 9;
+   cnt = DIV_ROUND_UP(CONFIG_LS_PPA_ESBC_HDR_SIZE, 512);
+   ret = mmc->block_dev.block_read(>block_dev, blk, cnt, ppa_hdr_ddr);
+   if (ret != cnt) {
+   free(ppa_hdr_ddr);
+   printf("MMC/SD read of PPA header failed\n");
+   return -EIO;
+   }

For NAND:
+   ret = nand_read(nand_info[0], (loff_t)CONFIG_SYS_LS_PPA_ESBC_ADDR,
+  _length, (u_char *)ppa_hdr_ddr);
+   if (ret == -EUCLEAN) {
+   free(ppa_hdr_ddr);
+   printf("NAND read of PPA firmware at offset 0x%x failed\n",
+  CONFIG_SYS_LS_PPA_FW_ADDR);
+   return -EIO;
+   }



So you are using this macro, but not using it directly as the way for 
XIP. It is confusing to see the assignment


ppa_esbc_hdr = CONFIG_SYS_LS_PPA_ESBC_ADDR;

I was suggesting to move this assignment down to the XIP section.

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

Re: [U-Boot] [PATCHv5 00/21] Retrieve MAC address from EEPROM

[York Sun]

On 04/11/2017 07:38 AM, o.schin...@ultimaker.com wrote:

Hey York,

On Mon, 2017-04-10 at 09:23 -0700, York Sun wrote:

On 04/10/2017 08:57 AM, Olliver Schinagl wrote:

Hey York,

On 10-04-17 17:52, York Sun wrote:

On 04/10/2017 08:34 AM, Olliver Schinagl wrote:

First off:
P.S. Joe, for some reason my previous patches where added with
me as:
"oli...@schinagl.nl " I see that it comes
from
patchwork
as such. Is there some way to fix this to
"Olliver Schinagl "?

Below the updated summary:

This patch-series introduces methods to retrieve the MAC
address from an
onboard EEPROM. The series does a few small cleanups at the
start, as
either
I ran into them while doing this series and fixed them along
the way or
actually depended on them.

A manufacturer wants to produce boards and may even have MAC
addresses
for
boards. Maintaining unique environments on a per-board basis
however is
horrible. Also this data should be very persistent, and not
easily
deletable
by simply wiping the environment or device tree. Finally there
are
chips available on the market with a pre-programmed MAC address
chips
(proms)
that a board manufacturer wants to use. Because of this, the
MAC needs
to be
stored be able to read from such an 'external' source.

The current idea of the eeprom layout, is to skip the first 8
bytes,
so that
other information can be stored there if needed, for example a
header
with some magic to identify the EEPROM. Or equivalent purposes.

After those 8 bytes the MAC address follows the first
macaddress. The
macaddress is appended by a CRC8 byte and then padded to make
for nice
8 bytes.
Following the first macaddress one can store a second, or a
third etc etc
macaddress.

The CRC8 is optional (via a define) but is strongly recommended
to
have. It
helps preventing user error and more importantly, checks if the
bytes
read are actually a user inserted address. E.g. only writing 1
macaddress into
the eeprom but trying to consume 2.


Interesting solution. We have used EEPROM to store board ID,
version
number, MAC addresses on many of our boards. We have a command
"mac" to
read/write these addresses. Would you take a look to see if it is
possible to integrate?


I feel bad for not noticing the mac command! I think that this
indeed
could get integrated, providing generic helpers.

Just wished you would have sent your suggestion during patch v1 or
v2 :p



Sorry, for some reason I wasn't CC'ed for your earlier version. They
were buried in thousands of emails.


Yeah, I saw, sorry.

As for the do_mac cmd, It looks something useful to add, I'll do that
once Maxime's EEPROM patches have landed as I will add support for that
then. Also I want to use the generic eeprom layout stuff for the layout
then and at that point, it would be good to integrate the do_mac stuff.

The only thing I don't quite understand from looking at the code, is
the name implies that you read/write/modify the MAC address in the rom
with this, but I see that the two implementers have lots of other
functions here, such as dumping the entire eeprom etc.

So what is the intend of do_mac? only MAC address related things, or
full rom related tasks?



The EEPROM we have holds more than just MAC addresses. It also has 
system ID, errata, number of ports, and CRC32 checksum. You can see them 
in cmd/mac.c, or board/freescale/common/sys_eeprom.c.


The command "mac" can read data out, and it can write. This is EEPROM on 
I2C bus. We were requested to provide a tool to update the errata number 
and etc.


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

[U-Boot] Please pull ARC changes

[Alexey Brodkin]

Hi Tom,

There's just a minor but quite important fix for ARC to be pulled from my tree.
Anyways please pull it.

The following changes since commit 9963890b8be1d208035945abc5ba9f77637b6542:

  libfdt: fix build with Python 3 (2017-04-10 13:25:19 -0600)

are available in the git repository at:

  git://git.denx.de/u-boot-arc.git 

for you to fetch changes up to 40a808f173008729a0c631ab84693b6a2b0dcfc9:

  ARCv2: SLC: Make sure busy bit is set properly on SLC flushing (2017-04-11 
17:54:31 +0300)


Alexey Brodkin (1):
  ARCv2: SLC: Make sure busy bit is set properly on SLC flushing

 arch/arc/lib/cache.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-) 

Regards,
Alexey
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCHv5 00/21] Retrieve MAC address from EEPROM

[o . schinagl]

Hey York,

On Mon, 2017-04-10 at 09:23 -0700, York Sun wrote:
> On 04/10/2017 08:57 AM, Olliver Schinagl wrote:
> > Hey York,
> > 
> > On 10-04-17 17:52, York Sun wrote:
> > > On 04/10/2017 08:34 AM, Olliver Schinagl wrote:
> > > > First off:
> > > > P.S. Joe, for some reason my previous patches where added with
> > > > me as:
> > > > "oli...@schinagl.nl " I see that it comes
> > > > from
> > > > patchwork
> > > > as such. Is there some way to fix this to
> > > > "Olliver Schinagl "?
> > > > 
> > > > Below the updated summary:
> > > > 
> > > > This patch-series introduces methods to retrieve the MAC
> > > > address from an
> > > > onboard EEPROM. The series does a few small cleanups at the
> > > > start, as
> > > > either
> > > > I ran into them while doing this series and fixed them along
> > > > the way or
> > > > actually depended on them.
> > > > 
> > > > A manufacturer wants to produce boards and may even have MAC
> > > > addresses
> > > > for
> > > > boards. Maintaining unique environments on a per-board basis
> > > > however is
> > > > horrible. Also this data should be very persistent, and not
> > > > easily
> > > > deletable
> > > > by simply wiping the environment or device tree. Finally there
> > > > are
> > > > chips available on the market with a pre-programmed MAC address
> > > > chips
> > > > (proms)
> > > > that a board manufacturer wants to use. Because of this, the
> > > > MAC needs
> > > > to be
> > > > stored be able to read from such an 'external' source.
> > > > 
> > > > The current idea of the eeprom layout, is to skip the first 8
> > > > bytes,
> > > > so that
> > > > other information can be stored there if needed, for example a
> > > > header
> > > > with some magic to identify the EEPROM. Or equivalent purposes.
> > > > 
> > > > After those 8 bytes the MAC address follows the first
> > > > macaddress. The
> > > > macaddress is appended by a CRC8 byte and then padded to make
> > > > for nice
> > > > 8 bytes.
> > > > Following the first macaddress one can store a second, or a
> > > > third etc etc
> > > > macaddress.
> > > > 
> > > > The CRC8 is optional (via a define) but is strongly recommended
> > > > to
> > > > have. It
> > > > helps preventing user error and more importantly, checks if the
> > > > bytes
> > > > read are actually a user inserted address. E.g. only writing 1
> > > > macaddress into
> > > > the eeprom but trying to consume 2.
> > > 
> > > Interesting solution. We have used EEPROM to store board ID,
> > > version
> > > number, MAC addresses on many of our boards. We have a command
> > > "mac" to
> > > read/write these addresses. Would you take a look to see if it is
> > > possible to integrate?
> > 
> > I feel bad for not noticing the mac command! I think that this
> > indeed
> > could get integrated, providing generic helpers.
> > 
> > Just wished you would have sent your suggestion during patch v1 or
> > v2 :p
> > 
> 
> Sorry, for some reason I wasn't CC'ed for your earlier version. They 
> were buried in thousands of emails.

Yeah, I saw, sorry.

As for the do_mac cmd, It looks something useful to add, I'll do that
once Maxime's EEPROM patches have landed as I will add support for that
then. Also I want to use the generic eeprom layout stuff for the layout
then and at that point, it would be good to integrate the do_mac stuff.

The only thing I don't quite understand from looking at the code, is
the name implies that you read/write/modify the MAC address in the rom
with this, but I see that the two implementers have lots of other
functions here, such as dumping the entire eeprom etc.

So what is the intend of do_mac? only MAC address related things, or
full rom related tasks?

Olliver
> 
> York
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2] tiny-printf: Add support for %p format

[Simon Glass]

On 11 April 2017 at 08:13, Tom Rini  wrote:
> On Tue, Apr 11, 2017 at 08:03:07AM -0600, Simon Glass wrote:
>> Hi Tom,
>>
>> On 11 April 2017 at 08:00, Tom Rini  wrote:
>> > On Tue, Apr 11, 2017 at 07:56:06AM -0600, Simon Glass wrote:
>> >> On 10 April 2017 at 00:53, Vignesh R  wrote:
>> >> > Add support for %p, %pa[p], %pM, %pm and %pI4 formats to tiny-printf.
>> >> > %pM and %pI4 are widely used by SPL networking stack and is required if
>> >> > networking support is desired in SPL.
>> >> > %p, %pa and %pap are mostly used by debug prints and hence supported
>> >> > only when DEBUG is enabled.
>> > [snip]
>> >> > +static void pointer(struct printf_info *info, const char *fmt, void 
>> >> > *ptr)
>> >> > +{
>> >> > +#ifdef DEBUG
>> >>
>> >> What is the #ifdef DEBUG for? It may not be enabled globally so I
>> >> don't think you can do this. You probably need this code always.
>> >
>> > So, %p/%pa/%pa[p] are used in debug() prints, which only matter when
>> > DEBUG is set.  Doing it this way means we globally bloat by (I think I
>> > snipped out..) 25 bytes? instead of ~250 bytes.  And since we're in
>> > tiny-printf, which we use when every byte counts, I'm happier about only
>> > bloating by 25 bytes here.
>>
>> What I mean is that typically DEBUG is enabled file by file. So if I
>> want to output something I need to enable DEBUG in this file as well?
>> That seems confusing to me. Perhaps it needs another CONFIG option?
>
> I usually end up whacking DEBUG into common.h myself, so I hadn't
> thought about it that way.  Long-term, yeah, we should think about how
> to handle debug stuff as there's times you want everything on and times
> you just want a little bit on, and we're talking about the we-need-space
> case here too.

OK. Would be a nice little project for someone :-)

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

Re: [U-Boot] [PATCH v2] tiny-printf: Add support for %p format

[Tom Rini]

On Tue, Apr 11, 2017 at 08:03:07AM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On 11 April 2017 at 08:00, Tom Rini  wrote:
> > On Tue, Apr 11, 2017 at 07:56:06AM -0600, Simon Glass wrote:
> >> On 10 April 2017 at 00:53, Vignesh R  wrote:
> >> > Add support for %p, %pa[p], %pM, %pm and %pI4 formats to tiny-printf.
> >> > %pM and %pI4 are widely used by SPL networking stack and is required if
> >> > networking support is desired in SPL.
> >> > %p, %pa and %pap are mostly used by debug prints and hence supported
> >> > only when DEBUG is enabled.
> > [snip]
> >> > +static void pointer(struct printf_info *info, const char *fmt, void 
> >> > *ptr)
> >> > +{
> >> > +#ifdef DEBUG
> >>
> >> What is the #ifdef DEBUG for? It may not be enabled globally so I
> >> don't think you can do this. You probably need this code always.
> >
> > So, %p/%pa/%pa[p] are used in debug() prints, which only matter when
> > DEBUG is set.  Doing it this way means we globally bloat by (I think I
> > snipped out..) 25 bytes? instead of ~250 bytes.  And since we're in
> > tiny-printf, which we use when every byte counts, I'm happier about only
> > bloating by 25 bytes here.
> 
> What I mean is that typically DEBUG is enabled file by file. So if I
> want to output something I need to enable DEBUG in this file as well?
> That seems confusing to me. Perhaps it needs another CONFIG option?

I usually end up whacking DEBUG into common.h myself, so I hadn't
thought about it that way.  Long-term, yeah, we should think about how
to handle debug stuff as there's times you want everything on and times
you just want a little bit on, and we're talking about the we-need-space
case here too.

-- 
Tom


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

Re: [U-Boot] [PATCH v2] tiny-printf: Add support for %p format

[Simon Glass]

Hi Tom,

On 11 April 2017 at 08:00, Tom Rini  wrote:
> On Tue, Apr 11, 2017 at 07:56:06AM -0600, Simon Glass wrote:
>> On 10 April 2017 at 00:53, Vignesh R  wrote:
>> > Add support for %p, %pa[p], %pM, %pm and %pI4 formats to tiny-printf.
>> > %pM and %pI4 are widely used by SPL networking stack and is required if
>> > networking support is desired in SPL.
>> > %p, %pa and %pap are mostly used by debug prints and hence supported
>> > only when DEBUG is enabled.
> [snip]
>> > +static void pointer(struct printf_info *info, const char *fmt, void *ptr)
>> > +{
>> > +#ifdef DEBUG
>>
>> What is the #ifdef DEBUG for? It may not be enabled globally so I
>> don't think you can do this. You probably need this code always.
>
> So, %p/%pa/%pa[p] are used in debug() prints, which only matter when
> DEBUG is set.  Doing it this way means we globally bloat by (I think I
> snipped out..) 25 bytes? instead of ~250 bytes.  And since we're in
> tiny-printf, which we use when every byte counts, I'm happier about only
> bloating by 25 bytes here.

What I mean is that typically DEBUG is enabled file by file. So if I
want to output something I need to enable DEBUG in this file as well?
That seems confusing to me. Perhaps it needs another CONFIG option?

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

Re: [U-Boot] [PATCH v2] tiny-printf: Add support for %p format

[Tom Rini]

On Tue, Apr 11, 2017 at 07:56:06AM -0600, Simon Glass wrote:
> On 10 April 2017 at 00:53, Vignesh R  wrote:
> > Add support for %p, %pa[p], %pM, %pm and %pI4 formats to tiny-printf.
> > %pM and %pI4 are widely used by SPL networking stack and is required if
> > networking support is desired in SPL.
> > %p, %pa and %pap are mostly used by debug prints and hence supported
> > only when DEBUG is enabled.
[snip]
> > +static void pointer(struct printf_info *info, const char *fmt, void *ptr)
> > +{
> > +#ifdef DEBUG
> 
> What is the #ifdef DEBUG for? It may not be enabled globally so I
> don't think you can do this. You probably need this code always.

So, %p/%pa/%pa[p] are used in debug() prints, which only matter when
DEBUG is set.  Doing it this way means we globally bloat by (I think I
snipped out..) 25 bytes? instead of ~250 bytes.  And since we're in
tiny-printf, which we use when every byte counts, I'm happier about only
bloating by 25 bytes here.

-- 
Tom


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

Re: [U-Boot] [PATCH v4 0/7] board: sama5d4: convert boards to support DM/DT

[Simon Glass]

Hi,

On 10 April 2017 at 00:57, Yang, Wenyou  wrote:
> Hi Simon,
>
>
> On 2017/4/10 3:28, Simon Glass wrote:
>>
>> +Tom
>>
>> Hi,
>>
>> On 7 April 2017 at 01:28, Yang, Wenyou  wrote:
>>>
>>> Hi Andreas,
>>>
>>> Could you help find a time to take these patch series?
>>>
>>> They are here for a long time.
>>>
>> Tom might be able to take it, or if not I could bring it in via DM I
>> suppose, since it is a conversion.
>
>
> I truly appreciate you if you take these patches.

OK I've assigned these to myself in patchwork and will pick them up at
some point.

Andreas, please feel free to grab these yourself if you like.

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

Re: [U-Boot] [PATCH v2] tiny-printf: Add support for %p format

[Simon Glass]

On 10 April 2017 at 00:53, Vignesh R  wrote:
> Add support for %p, %pa[p], %pM, %pm and %pI4 formats to tiny-printf.
> %pM and %pI4 are widely used by SPL networking stack and is required if
> networking support is desired in SPL.
> %p, %pa and %pap are mostly used by debug prints and hence supported
> only when DEBUG is enabled.
>
> Before this patch:
> $ size spl/u-boot-spl
>textdata bss dec hex filename
>   993254899  218584  322808   4ecf8 spl/u-boot-spl
>
> After this patch (with CONFIG_SPL_NET_SUPPORT):
> $ size spl/u-boot-spl
>textdata bss dec hex filename
>   996664899  218584  323149   4ee4d spl/u-boot-spl
>
> So, this patch adds ~350 bytes to code size.
>
> If CONFIG_SPL_NET_SUPPORT is not enabled, this adds ~25 bytes.
>
> If CONFIG_USE_TINY_PRINTF is disabled then:
> $ size spl/u-boot-spl
>   text data bss dec hex filename
>  1011164899  218584  324599   4f3f7 spl/u-boot-spl
>
> So, there is still ~1.4K space saved even with support for %pM/%pI4.
>
> Compiler used is to build is:
> arm-linux-gnueabihf-gcc (Linaro GCC 6.2-2016.11) 6.2.1 20161016
>
> Signed-off-by: Vignesh R 
> ---
>
> Changes wrt RFC:
> * support %p[ap] only under DEBUG
> * Add comparsion data w/o tiny printf to commit message.
>
>  lib/tiny-printf.c | 154 
> ++
>  1 file changed, 154 insertions(+)
>
> diff --git a/lib/tiny-printf.c b/lib/tiny-printf.c
> index 6def8f98aa41..0b04813dc206 100644
> --- a/lib/tiny-printf.c
> +++ b/lib/tiny-printf.c
> @@ -12,6 +12,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  struct printf_info {
> char *bf;   /* Digit buffer */
> @@ -52,6 +53,154 @@ static void div_out(struct printf_info *info, unsigned 
> long *num,
> out_dgt(info, dgt);
>  }
>
> +#ifdef CONFIG_SPL_NET_SUPPORT
> +static void string(struct printf_info *info, char *s)
> +{
> +   char ch;
> +
> +   while ((ch = *s++))
> +   out(info, ch);
> +}
> +
> +static const char hex_asc[] = "0123456789abcdef";
> +#define hex_asc_lo(x)  hex_asc[((x) & 0x0f)]
> +#define hex_asc_hi(x)  hex_asc[((x) & 0xf0) >> 4]
> +
> +static inline char *pack_hex_byte(char *buf, u8 byte)
> +{
> +   *buf++ = hex_asc_hi(byte);
> +   *buf++ = hex_asc_lo(byte);
> +   return buf;
> +}
> +
> +static void mac_address_string(struct printf_info *info, u8 *addr,
> +   bool separator)
> +{
> +   /* (6 * 2 hex digits), 5 colons and trailing zero */
> +   char mac_addr[6 * 3];
> +   char *p = mac_addr;
> +   int i;
> +
> +   for (i = 0; i < 6; i++) {
> +   p = pack_hex_byte(p, addr[i]);
> +   if (separator && i != 5)
> +   *p++ = ':';
> +   }
> +   *p = '\0';
> +
> +   string(info, mac_addr);
> +}
> +
> +static char *put_dec_trunc(char *buf, unsigned int q)
> +{
> +   unsigned int d3, d2, d1, d0;
> +   d1 = (q >> 4) & 0xf;
> +   d2 = (q >> 8) & 0xf;
> +   d3 = (q >> 12);
> +
> +   d0 = 6 * (d3 + d2 + d1) + (q & 0xf);
> +   q = (d0 * 0xcd) >> 11;
> +   d0 = d0 - 10 * q;
> +   *buf++ = d0 + '0'; /* least significant digit */
> +   d1 = q + 9 * d3 + 5 * d2 + d1;
> +   if (d1 != 0) {
> +   q = (d1 * 0xcd) >> 11;
> +   d1 = d1 - 10 * q;
> +   *buf++ = d1 + '0'; /* next digit */
> +
> +   d2 = q + 2 * d2;
> +   if ((d2 != 0) || (d3 != 0)) {
> +   q = (d2 * 0xd) >> 7;
> +   d2 = d2 - 10 * q;
> +   *buf++ = d2 + '0'; /* next digit */
> +
> +   d3 = q + 4 * d3;
> +   if (d3 != 0) {
> +   q = (d3 * 0xcd) >> 11;
> +   d3 = d3 - 10 * q;
> +   *buf++ = d3 + '0';  /* next digit */
> +   if (q != 0)
> +   *buf++ = q + '0'; /* most sign. digit 
> */

OMG not the nicest code!

> +   }
> +   }
> +   }
> +   return buf;
> +}
> +
> +static void ip4_addr_string(struct printf_info *info, u8 *addr)
> +{
> +   /* (4 * 3 decimal digits), 3 dots and trailing zero */
> +   char ip4_addr[4 * 4];
> +   char temp[3];   /* hold each IP quad in reverse order */
> +   char *p = ip4_addr;
> +   int i, digits;
> +
> +   for (i = 0; i < 4; i++) {
> +   digits = put_dec_trunc(temp, addr[i]) - temp;
> +   /* reverse the digits in the quad */
> +   while (digits--)
> +   *p++ = temp[digits];
> +   if (i != 3)
> +   *p++ = '.';
> +   }
> +   *p = '\0';
> +
> +   string(info, ip4_addr);
> +}
> +#endif
> +
> +/*
> + * Show a '%p' thing.  A kernel extension is that the '%p' is followed
> + 

Re: [U-Boot] [PATCH 3/5] rockchip: video: Add mipi dsi driver for rk3399

[Simon Glass]

Hi Eric,

On 9 April 2017 at 20:41, Eric Gao  wrote:
> Add mipi dsi driver for rk chip, To enable this
> you need to enable DM, DM_VIDEO, DM_ROCKCHIP_VIDEO,
> DISPLAY_MIPI in menuconfig. And enable rk808,and it's
> corresponding i2c.

General comment:

Can you please format your commit message, comments and code to use up
more of the 80 columns?

Git commit messages should be word-wrapped to <=75 columns I think (so
that git log looks right in 80 columns). Comments, etc. should be <=80
cols.

Kconfig also should use more of the width.

Set your editor to show a line at 80cols!
>
> Signed-off-by: Eric Gao 
> ---
>
>  arch/arm/include/asm/arch-rockchip/cru_rk3399.h  |   1 +
>  arch/arm/include/asm/arch-rockchip/grf_rk3399.h  |  25 ++
>  arch/arm/include/asm/arch-rockchip/mipi_rk3399.h | 189 +
>  arch/arm/include/asm/arch-rockchip/vop_rk3288.h  |   1 +
>  drivers/video/Kconfig|   2 +
>  drivers/video/rockchip/Kconfig   |  47 +++
>  drivers/video/rockchip/Makefile  |   6 +-
>  drivers/video/rockchip/rk_mipi.c | 465 
> +++
>  drivers/video/rockchip/rk_vop.c  |  39 +-
>  9 files changed, 768 insertions(+), 7 deletions(-)
>  create mode 100644 arch/arm/include/asm/arch-rockchip/mipi_rk3399.h
>  create mode 100644 drivers/video/rockchip/Kconfig
>  create mode 100644 drivers/video/rockchip/rk_mipi.c
>
> diff --git a/arch/arm/include/asm/arch-rockchip/cru_rk3399.h 
> b/arch/arm/include/asm/arch-rockchip/cru_rk3399.h
> index cf830d0..e9e5810 100644
> --- a/arch/arm/include/asm/arch-rockchip/cru_rk3399.h
> +++ b/arch/arm/include/asm/arch-rockchip/cru_rk3399.h
> @@ -70,6 +70,7 @@ struct rk3399_cru {
>  };
>  check_member(rk3399_cru, sdio1_con[1], 0x594);
>  #define MHz100
> +#define MHZ100
>  #define KHz1000
>  #define OSC_HZ (24*MHz)
>  #define APLL_HZ(600*MHz)
> diff --git a/arch/arm/include/asm/arch-rockchip/grf_rk3399.h 
> b/arch/arm/include/asm/arch-rockchip/grf_rk3399.h
> index 62d8496..2bf58da 100644
> --- a/arch/arm/include/asm/arch-rockchip/grf_rk3399.h
> +++ b/arch/arm/include/asm/arch-rockchip/grf_rk3399.h
> @@ -399,6 +399,31 @@ enum {
> GRF_UART_DBG_SEL_MASK   = 3 << GRF_UART_DBG_SEL_SHIFT,
> GRF_UART_DBG_SEL_C  = 2,
>
> +   /* GRF_SOC_CON20 */
> +   GRF_DSI0_VOP_SEL_SHIFT  = 0,
> +   GRF_DSI0_VOP_SEL_MASK   = 1 << GRF_DSI0_VOP_SEL_SHIFT,
> +   GRF_DSI0_VOP_SEL_B  = 0,
> +   GRF_DSI0_VOP_SEL_L,
> +
> +   /* GRF_SOC_CON22 */
> +   GRF_DPHY_TX0_RXMODE_SHIFT = 0,
> +   GRF_DPHY_TX0_RXMODE_MASK =
> +   0xf << GRF_DPHY_TX0_RXMODE_SHIFT,
> +   GRF_DPHY_TX0_RXMODE_EN = 0xb,
> +   GRF_DPHY_TX0_RXMODE_DIS = 0,
> +
> +   GRF_DPHY_TX0_TXSTOPMODE_SHIFT = 4,
> +   GRF_DPHY_TX0_TXSTOPMODE_MASK =
> +   0xf0 << GRF_DPHY_TX0_TXSTOPMODE_SHIFT,
> +   GRF_DPHY_TX0_TXSTOPMODE_EN = 0xc,
> +   GRF_DPHY_TX0_TXSTOPMODE_DIS = 0,
> +
> +   GRF_DPHY_TX0_TURNREQUEST_SHIFT = 12,
> +   GRF_DPHY_TX0_TURNREQUEST_MASK =
> +   0xf000 << GRF_DPHY_TX0_TURNREQUEST_SHIFT,
> +   GRF_DPHY_TX0_TURNREQUEST_EN = 0x1,
> +   GRF_DPHY_TX0_TURNREQUEST_DIS = 0,
> +
> /*  PMUGRF_GPIO0A_IOMUX */
> PMUGRF_GPIO0A6_SEL_SHIFT= 12,
> PMUGRF_GPIO0A6_SEL_MASK = 3 << PMUGRF_GPIO0A6_SEL_SHIFT,
> diff --git a/arch/arm/include/asm/arch-rockchip/mipi_rk3399.h 
> b/arch/arm/include/asm/arch-rockchip/mipi_rk3399.h
> new file mode 100644
> index 000..9a1fffb
> --- /dev/null
> +++ b/arch/arm/include/asm/arch-rockchip/mipi_rk3399.h
> @@ -0,0 +1,189 @@
> +/*
> + * Copyright (C) 2017-2025 Fuzhou Rockchip Electronics Co., Ltd
> + * author: eric@rock-chips.com
> + * create date: 2017-03-31
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +#ifndef RK33_MIPI_DSI_H
> +#define RK33_MIPI_DSI_H
> +
> +/*
> + * All these mipi controller register declaration provide
> + * reg address offset, bits width, bit offset for a
> + * specified register bits. With these message, we can
> + * set or clear every bits individually for a 32bit width
> + * register. We use DSI_HOST_BITS macro definition to
> + * combinat these message using the following format:
> + * val(32bit) = addr(16bit) | width(8bit) | offest(8bit)
> + * for example:
> + * #define SHUTDOWNZ   DSI_HOST_BITS(0X004, 1, 0)
> + * means SHUTDOWNZ is a signal reg bit with bit offset
> + * qual 0,and it's reg addr offset is 0x004.The conbinat
> + * result  = (0x004 << 16) | (1 << 8) | 0

A more conventional idea might be:

struct dsi_host_reg {
  u16 addr;
  u8 bits;
  u8 bit_offset;
};

enum dsi_host_reg_t {
   VERSION,
   SHUTDOWNZ,
   ...
   DSI_HOST_REG_COUNT,
};

#define DSI_HOST_REG(addr, bits, bit_offset) { .addr = _addr; bits =
_bits; bit_offset = _bit_offset }

static const struct dsi_host_reg 

Re: [U-Boot] [PATCH 2/5] rockchip: pmic: Enable RK808 for rk3399 evb

[Simon Glass]

On 9 April 2017 at 20:41, Eric Gao  wrote:
> For using mipi display, we need to enable lcd3v3
> which supplied by rk808,so enable rk808 first.
>
> Signed-off-by: Eric Gao 
> ---
>
>  arch/arm/dts/rk3399-evb.dts  | 39 +++
>  configs/evb-rk3399_defconfig |  5 +
>  2 files changed, 44 insertions(+)

Acked-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 4/5] rockchip: dts: Add mipi dsi support for rk3399

[Simon Glass]

On 9 April 2017 at 20:41, Eric Gao  wrote:
> Add dts config for mipi display, include vop,
> mipi controller, panel, backlight.And Enable rk808
> for lcd_3v3 in another patch.
>
> Signed-off-by: Eric Gao 
> ---
>
>  arch/arm/dts/rk3399-evb.dts | 84 
> +
>  arch/arm/dts/rk3399.dtsi| 72 ++
>  2 files changed, 156 insertions(+)

Acked-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/5] rockchip: i2c: Enable i2c for rk3399

[Simon Glass]

On 9 April 2017 at 20:17, Eric Gao  wrote:
> To enable mipi display, we need to enable pmic
> rk808 first for lcd3v3 power,which use i2c0 to
> communicate with soc. So enable i2c0.
>
> Signed-off-by: Eric Gao 
>
> ---
>
>  arch/arm/dts/rk3399.dtsi | 16 
>  configs/evb-rk3399_defconfig |  1 +
>  drivers/i2c/rk_i2c.c |  1 +
>  3 files changed, 18 insertions(+)
>

Acked-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] rockchip: rk3399: defconfig: add CONFIG_OF_EMBED support

[Simon Glass]

Hi Kever,

On 9 April 2017 at 20:36, Kever Yang  wrote:
> Hi Simon,
>
>
> On 04/10/2017 03:28 AM, Simon Glass wrote:
>>
>> Hi Kever,
>>
>> On 7 April 2017 at 04:35, Kever Yang  wrote:
>>>
>>> Need to enablt CONFIG_OF_EMBED if we use separate uboot and dtb
>>> in FIT image for SPL loading.
>>>
>> Can you please explain that a bit more? We shouldn't OF_EMBED in
>> production code, only for debug/test.
>
>
> When I test with latest code for SPL loading FIT which u-boot and dtb
> are separate, the U-Boot code can not find its dtb file.
> This issue is not happen when I test with code older than v2017.03,
> and with CONFIG_OF_EMBED, U-Boot can find dtb with latest code.
>
> Maybe I need to do some debugging for root cause, please ignore this
> patch if this is not correct.

Yes this needs to be figured out. If you have the debug UART enabled
you should be able to add debugging to fdtdec_setup() to see what is
happening. Perhaps the DT is not word-aligned?

Regards,
Simon

>
> Thanks,
> - Kever
>
>>
>>> Run make savedefconfig to make the options order correct.
>>>
>>> Signed-off-by: Kever Yang 
>>> ---
>>>
>>>   configs/evb-rk3399_defconfig | 43
>>> ---
>>>   1 file changed, 20 insertions(+), 23 deletions(-)
>>
>> Regards,
>> Simon
>>
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCHv2 04/21] net: core: Add function to check/set MAC locality

[Olliver Schinagl]

A first comment I have myself, which will go in a v3 (or as a separate 
patch after this has been merged):


On 10-04-17 17:33, Olliver Schinagl wrote:

Universally administered and locally administered addresses are
distinguished by setting the second-least-significant bit of the first
octet of the address. Having a function to check and set this U/L bit
from a function makes it nice for boards that want to generate their own
mac address to ensure they are locally administered.

Signed-off-by: Olliver Schinagl 
---
 include/net.h | 24 +++-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/include/net.h b/include/net.h
index b4af8eaae4..b1d6f05a76 100644
--- a/include/net.h
+++ b/include/net.h
@@ -779,6 +779,28 @@ static inline int is_multicast_ethaddr(const u8 *addr)
return 0x01 & addr[0];
 }

0x01 can be a defien,


+/**
+ * is_local_ethaddr - Determine if the Ethernet address is a locally
+ *   administered MAC address.
+ * @addr:  Pointer to a six-byte array containing the Ethernet address
+ *
+ * Return true if the address is a locally administered address.
+ */
+static inline int is_local_ethaddr(const u8 *addr)
+{
+   return 0x02 & addr[0];

0x02 can be a define as well


+}
+
+/**
+ * set_local_ethaddr - Make the supplied Ethernet address a locally
+ *administered one.
+ * @addr:  Pointer to a six-byte array containing the Ethernet address
+ */
+static inline void set_local_ethaddr(u8 *addr)
+{
+   addr[0] |= 0x02;/* set local assignment bit (IEEE802) */
+}
+
 /*
  * is_broadcast_ethaddr - Determine if the Ethernet address is broadcast
  * @addr: Pointer to a six-byte array containing the Ethernet address
@@ -823,7 +845,7 @@ static inline void net_random_ethaddr(uchar *addr)
addr[i] = rand_r();

addr[0] &= 0xfe;/* clear multicast bit */
-   addr[0] |= 0x02;/* set local assignment bit (IEEE802) */
+   set_local_ethaddr(addr);
 }

 /* Convert an IP address to a string */


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

Re: [U-Boot] [PATCH v2] tiny-printf: Add support for %p format

[Tom Rini]

On Mon, Apr 10, 2017 at 12:23:22PM +0530, Vignesh R wrote:

> Add support for %p, %pa[p], %pM, %pm and %pI4 formats to tiny-printf.
> %pM and %pI4 are widely used by SPL networking stack and is required if
> networking support is desired in SPL.
> %p, %pa and %pap are mostly used by debug prints and hence supported
> only when DEBUG is enabled.
> 
> Before this patch:
> $ size spl/u-boot-spl
>text  data bss dec hex filename
>   99325  4899  218584  322808   4ecf8 spl/u-boot-spl
> 
> After this patch (with CONFIG_SPL_NET_SUPPORT):
> $ size spl/u-boot-spl
>text  data bss dec hex filename
>   99666  4899  218584  323149   4ee4d spl/u-boot-spl
> 
> So, this patch adds ~350 bytes to code size.
> 
> If CONFIG_SPL_NET_SUPPORT is not enabled, this adds ~25 bytes.
> 
> If CONFIG_USE_TINY_PRINTF is disabled then:
> $ size spl/u-boot-spl
>   text   data bss dec hex filename
>  101116  4899  218584  324599   4f3f7 spl/u-boot-spl
> 
> So, there is still ~1.4K space saved even with support for %pM/%pI4.
> 
> Compiler used is to build is:
> arm-linux-gnueabihf-gcc (Linaro GCC 6.2-2016.11) 6.2.1 20161016
> 
> Signed-off-by: Vignesh R 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] Please pull u-boot-fdt

[Tom Rini]

On Mon, Apr 10, 2017 at 02:52:44PM -0600, Simon Glass wrote:

> Hi Tom,
> 
> Just a few minor fixes.
> 
> 
> The following changes since commit 01cce5fdd098add2b8aa570468cb35fca5d778fe:
> 
>   Merge git://git.denx.de/u-boot-x86 (2017-04-10 08:07:29 -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-fdt.git
> 
> for you to fetch changes up to 9963890b8be1d208035945abc5ba9f77637b6542:
> 
>   libfdt: fix build with Python 3 (2017-04-10 13:25:19 -0600)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [RFC, 1/2] NVMe: add NVMe driver support

[Tom Rini]

On Tue, Apr 11, 2017 at 02:33:40AM +, Z.K. Zhang wrote:

> Hi Tom,
> 
> As I know, the CONFIG_BLK is not supported on some platforms'
> defconfig (# CONFIG_BLK is not set), such as the fsl-qoriq platform.
> I find when 'CONFIG_BLK=y', then 'fsl-esdhc-mmc' device can't work normally.
> 
> So, in order to make sure the NVMe driver is available on all the
> platforms, I support for both with and without BLK.

But shouldn't the other platforms be updated as well?

-- 
Tom


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

Re: [U-Boot] i.Mx6q u-boot stuck

[Fausto Sessego]

what do you suggest?

How can i check if the ram configuration is right?

Thanks

--
*Ing. Fausto Sessego*
*R Hardware & Software Engineer*
info
mob
>
*Tecnologie Wireless per la logistica e la sicurezza*

*a:* Parco scientifico e tecnologico della Sardegna, Edificio 1 Loc.
Piscinamanna - 09010 Pula (CA)

*p:* +39 070 92432952
*e:* fausto.sess...@infomob.it
*w:* www.infomob.it

2017-04-11 12:51 GMT+02:00 Fabio Estevam :

>
>
> On Tue, Apr 11, 2017 at 6:29 AM, Fausto Sessego  > wrote
>>
>>
>>
>> Could it be a problem of ram configuration?
>>
>
> Yes, this could be the problem.
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] MTD devices emulation driver (gluebi) support

[ManuelCurcio]

I tried to use ubifs. However, I just need of a space storage for three files 
with a total size of 500 bytes. 
From theses three files, the UBIFS generated a 1.8 MegaBytes file. The ubifs 
file system mounted took 7 Megabytes just for 500 bytes !
JFFS2 over ubi requires "only" 4 LEB  minimum, so for my 500 bytes, jffs2 
requires 4 * 128 kB == 512 kBytes for my nand.



-
Eaton Industries (France) S.A.S ~ Siège social: 110 Rue Blaise Pascal, Immeuble 
Le Viséo - Bâtiment A Innovallée, 38330, Montbonnot-St.-Martin, France ~ Lieu 
d'enregistrement au registre du commerce: Grenoble ~ Numéro d'enregistrement: 
509 653 176 ~ Capital social souscrit et liberé:€ 16215441 ~ Numéro de TVA: 
FR47509653176
਍
-

-Original Message-
From: Heiko Schocher [mailto:h...@denx.de] 
Sent: mardi 11 avril 2017 13:43
To: Curcio, Manuel
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] MTD devices emulation driver (gluebi) support

Hello Manuel,

Am 11.04.2017 um 09:20 schrieb manuelcur...@eaton.com:
> Hello
>
> Thanks for the answer.
> Hi
>
> Thanks for the answer.
> I would like ... but I think I'm going to a raw data storage in a ubi volume 
> instead of a little jffs2 file system :(  (my need it is just to store some 
> bytes of data) ...

Ok ... or you try to use UBIFS ?

bye,
Heiko
>
> Manuel
>
>
>
>
> -
> Eaton Industries (France) S.A.S ~ Siège social: 110 Rue Blaise Pascal, 
> Immeuble Le Viséo - Bâtiment A Innovallée, 38330, 
> Montbonnot-St.-Martin, France ~ Lieu d'enregistrement au registre du 
> commerce: Grenoble ~ Numéro d'enregistrement: 509 653 176 ~ Capital 
> social souscrit et liberé:€ 16215441 ~ Numéro de TVA: FR47509653176 ਍
> -
>
> 
> De : Heiko Schocher [h...@denx.de]
> Envoyé : vendredi 7 avril 2017 13:02
> À : Curcio, Manuel
> Cc : u-boot@lists.denx.de
> Objet : Re: [U-Boot] MTD devices emulation driver (gluebi) support
>
> Hello Manuel,
>
> Am 06.04.2017 um 10:36 schrieb manuelcur...@eaton.com:
>> Hi,
>>
>> I want to read a jffs2 file system over ubi from uboot.
>>   From ubi.h, I found the CONFIG_MTD_UBI_GLUEBI define to allow this 
>> functionality (I think) :
>>
>> /* gluebi.c */
>> #ifdef CONFIG_MTD_UBI_GLUEBI
>> 
>>
>> However, when I set this define, after compilation, I have errors links 
>> about gluebi functions :
>>
>> uboot/common/cmd_ubi.c:293: undefined reference to `ubi_gluebi_updated'
>>
>> And in fact, after search, I didn't find gluebi.c file in uboot.
>>
>> I use the U-Boot 2015.01 version. When I look the last release, I didn't 
>> find gluebi.c  too.
>>
>> Some one can tell me more about that ? How is it possible to read jffs2 (or 
>> squashfs) from uboot ?
>
> We use the UBI/UBIFS sources from linux, so this part cames from 
> linux. And as fas as I know, nobody has tried to use 
> CONFIG_MTD_UBI_GLUEBI in u-boot yet, so if you want to do this, you 
> have to dig into this part deeper. Patches are welcome ;-)
>
> bye,
> Heiko
>>
>> thanks !
>>
>> Manuel
>>
>>
>>
>> 
>> Eaton Industries (France) S.A.S ~ Siège social: 110 Rue Blaise Pascal, 
>> Immeuble Le Viséo - Bâtiment A Innovallée, 38330, Montbonnot-St.-Martin, 
>> France ~ Lieu d'enregistrement au registre du commerce: Grenoble ~ Numéro 
>> d'enregistrement: 509 653 176 ~ Capital social souscrit et liberé:EUR 
>> 16215441 ~ Numéro de TVA: FR47509653176?
>>
>> 
>>
>>
>> ___
>> U-Boot mailing list
>> U-Boot@lists.denx.de
>> https://lists.denx.de/listinfo/u-boot
>>
>
> --
> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
>

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] MTD devices emulation driver (gluebi) support

[ManuelCurcio]

Hello

Thanks for the answer.
Hi

Thanks for the answer.
I would like ... but I think I'm going to a raw data storage in a ubi volume 
instead of a little jffs2 file system :(  (my need it is just to store some 
bytes of data) ...  

Manuel




-
Eaton Industries (France) S.A.S ~ Siège social: 110 Rue Blaise Pascal, Immeuble 
Le Viséo - Bâtiment A Innovallée, 38330, Montbonnot-St.-Martin, France ~ Lieu 
d'enregistrement au registre du commerce: Grenoble ~ Numéro d'enregistrement: 
509 653 176 ~ Capital social souscrit et liberé:€ 16215441 ~ Numéro de TVA: 
FR47509653176
਍
-


De : Heiko Schocher [h...@denx.de]
Envoyé : vendredi 7 avril 2017 13:02
À : Curcio, Manuel
Cc : u-boot@lists.denx.de
Objet : Re: [U-Boot] MTD devices emulation driver (gluebi) support

Hello Manuel,

Am 06.04.2017 um 10:36 schrieb manuelcur...@eaton.com:
> Hi,
>
> I want to read a jffs2 file system over ubi from uboot.
>  From ubi.h, I found the CONFIG_MTD_UBI_GLUEBI define to allow this 
> functionality (I think) :
>
> /* gluebi.c */
> #ifdef CONFIG_MTD_UBI_GLUEBI
> 
>
> However, when I set this define, after compilation, I have errors links about 
> gluebi functions :
>
> uboot/common/cmd_ubi.c:293: undefined reference to `ubi_gluebi_updated'
>
> And in fact, after search, I didn't find gluebi.c file in uboot.
>
> I use the U-Boot 2015.01 version. When I look the last release, I didn't find 
> gluebi.c  too.
>
> Some one can tell me more about that ? How is it possible to read jffs2 (or 
> squashfs) from uboot ?

We use the UBI/UBIFS sources from linux, so this part cames
from linux. And as fas as I know, nobody has tried to use
CONFIG_MTD_UBI_GLUEBI
in u-boot yet, so if you want to do this, you have to dig into
this part deeper. Patches are welcome ;-)

bye,
Heiko
>
> thanks !
>
> Manuel
>
>
>
> 
> Eaton Industries (France) S.A.S ~ Siège social: 110 Rue Blaise Pascal, 
> Immeuble Le Viséo - Bâtiment A Innovallée, 38330, Montbonnot-St.-Martin, 
> France ~ Lieu d'enregistrement au registre du commerce: Grenoble ~ Numéro 
> d'enregistrement: 509 653 176 ~ Capital social souscrit et liberé:EUR 
> 16215441 ~ Numéro de TVA: FR47509653176?
>
> 
>
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
>

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] i.Mx6q u-boot stuck

[Fausto Sessego]

I tryed to remove it but the result was the same.

I have another straing problem: if i enable the macro #define DEBUG in my
mx6board.h the system stuck

U-Boot 2016.07 (Apr 11 2017 - 11:19:23 +0200)

initcall: 1780b930
U-Boot code: 1780 -> 17847A3C  BSS: -> 178928E8
initcall: 17801cb4
CPU:   Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz)
CPU:   Extended Commercial temperature grade (-20C to 105C)malloc_simple:
size=10, ptr=ec, limit=400: 93fbdc
uclass_find_device_by_seq: 0 -1
uclass_find_device_by_seq: 0 0
   - -1 -1
   - not found
 at 27C
Reset cause: POR
initcall: 1780be60
Board: i.MX6Q SIBIRI
Support: http://www.infomob.it/
initcall: 1780b974
I2C:   ready
initcall: 1780b95c
DRAM:  initcall: 17802db0
gd->ram_size: 1073741824
initcall: 17802dd8
DRAM test not implemented!
initcall: 1780bbb4
Monitor len: 000928E8
Ram size: 4000
Ram top: 5000
initcall: 1780b75c
initcall: 1780b8d8
TLB table from 4fff to 4fff4000
initcall: 1780b774
initcall: 1780b88c
Reserving 586k for U-Boot at: 4ff5d000
initcall: 1780b85c
Reserving 10248k for malloc() at: 4f55b000
initcall: 1780ba8c
Reserving 80 Bytes for Board Info at: 4f55afb0
initcall: 1780b77c
initcall: 1780b828
Reserving 248 Bytes for Global Data at: 4f55aeb8
initcall: 1780b7c4
initcall: 1780b798
initcall: 1780bc34
initcall: 1780bb8c
initcall: 1780bae4

RAM Configuration:
Bank #0: 1000 1 GiB

DRAM:  1 GiB
initcall: 1780b7a8
New Stack Pointer is: 4f55ae90
initcall: 1780ba50
initcall: 1780b9e4
Relocation Offset is: 3875d000
Relocating to 4ff5d000, new gd at 4f55aeb8, sp at 4f55ae90
initcall: 4ff68c80
initcall: 4ff68c88

Could it be a problem of ram configuration?

Thanks


--
*Ing. Fausto Sessego*
*R Hardware & Software Engineer*
info
mob
>
*Tecnologie Wireless per la logistica e la sicurezza*

*a:* Parco scientifico e tecnologico della Sardegna, Edificio 1 Loc.
Piscinamanna - 09010 Pula (CA)

*p:* +39 070 92432952
*e:* fausto.sess...@infomob.it
*w:* www.infomob.it

2017-04-10 22:14 GMT+02:00 Fabio Estevam :

> On Mon, Apr 10, 2017 at 5:07 PM, Fausto Sessego
>  wrote:
> > It is right because it is a custom board designed  by my self.
> >
> > I renamed CONFIG_TARGET_MX6BOARD=y
> >
> > Do you have any hint?
>
> You can try removing the line ""mmcbooterror=echo Boot from mmc
> ERROR!!; " from your CONFIG_EXTRA_ENV_SETTINGS.
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC, 1/2] NVMe: add NVMe driver support

[Z.K. Zhang]

Hi Tom,

As I know, the CONFIG_BLK is not supported on some platforms' defconfig (# 
CONFIG_BLK is not set), such as the fsl-qoriq platform.
I find when 'CONFIG_BLK=y', then 'fsl-esdhc-mmc' device can't work normally.

So, in order to make sure the NVMe driver is available on all the platforms, I 
support for both with and without BLK.

Thank you!

Best regards,
Zhikang Zhang

-Original Message-
From: Tom Rini [mailto:tr...@konsulko.com] 
Sent: Tuesday, April 11, 2017 5:49 AM
To: Z.K. Zhang 
Cc: york sun ; u-boot@lists.denx.de; Wenbin Song 

Subject: Re: [U-Boot] [RFC, 1/2] NVMe: add NVMe driver support

On Thu, Apr 06, 2017 at 04:40:33PM +0800, Zhikang Zhang wrote:

> Add Support of devices that follow the NVM Express standard
> 
>  basic functions:
>   nvme init/scan
>   nvme info - show the basic information of device
>   nvme Read/Write
> 
>  driver model:
>   Use block device(CONFIG_BLK)'s structure to support nvme's DM.
>   Use UCLASS_PCI as a parent uclass.
> 
> The driver code heavily copy from the NVMe driver code in Linux Kernel.
> 
> Signed-off-by: Zhikang Zhang 
> Signed-off-by: Wenbin Song 

Why support for both with and without BLK?  Thanks!

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

Re: [U-Boot] i.Mx6q u-boot stuck

[Fabio Estevam]

On Tue, Apr 11, 2017 at 8:20 AM, Fausto Sessego 
wrote:

> what do you suggest?
>
> How can i check if the ram configuration is right?
>

https://community.nxp.com/docs/DOC-331930

https://community.nxp.com/docs/DOC-105652
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] generating a script file in FIT_SIGNATURE context

[Nicolas LE BAYON]

Hi all,

In my setup, I have activated FIT (without signature in a first step), and I 
boot using standard script way (boot.scr), which I generate with the following 
command :
mkimage -A arm -T script -C none -n "My boot script" -d boot.txt boot.scr
It works fine, and I can "load" and "bootm" the FIT image.

Now I would like to activate fit_signature. When I write manually all the 
boot.txt script commands in the console, it works fine. So it means that the 
FIT image is well generated, and the u-boot is well-configured. That's a good 
point.

But I have some problems to run the generated boot.scr in that case.  I think 
the script should also be generated with the signature. Do you confirm that?

If this is the case, from your point of view, which fields should I add to my 
previous command? -F ? -k ? -K? others?

Thanks in advance for your feedback
Best Regards
Nicolas

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

Re: [U-Boot] [PATCH v4 14/19] arm: socfpga: Add SPL support for Arria 10

[Dinh Nguyen]

On Tue, Apr 11, 2017 at 12:48 AM, Ley Foon Tan  wrote:
> On Tue, Apr 11, 2017 at 11:42 AM, Dinh Nguyen  wrote:
>>
>>
>> On 04/10/2017 05:05 PM, Dinh Nguyen wrote:
>>>
>>>
>>> On 04/10/2017 03:43 PM, Dinh Nguyen wrote:


 On 04/05/2017 04:32 AM, Ley Foon Tan wrote:
> Add SPL support for Arria 10.
>
> Signed-off-by: Tien Fong Chee 
> Signed-off-by: Ley Foon Tan 
> ---
>  arch/arm/mach-socfpga/spl.c | 74 
> ++---
>  1 file changed, 69 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/mach-socfpga/spl.c b/arch/arm/mach-socfpga/spl.c
> index 69c433c..e1e62c2 100644
> --- a/arch/arm/mach-socfpga/spl.c
> +++ b/arch/arm/mach-socfpga/spl.c
> @@ -19,23 +19,32 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
> +#if defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
> +#include 
> +#endif
>
>  DECLARE_GLOBAL_DATA_PTR;
>
> +#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
>  static struct pl310_regs *const pl310 =
> (struct pl310_regs *)CONFIG_SYS_PL310_BASE;
>  static struct scu_registers *scu_regs =
> (struct scu_registers *)SOCFPGA_MPUSCU_ADDRESS;
>  static struct nic301_registers *nic301_regs =
> (struct nic301_registers *)SOCFPGA_L3REGS_ADDRESS;
> -static struct socfpga_system_manager *sysmgr_regs =
> +#endif
> +
> +static const struct socfpga_system_manager *sysmgr_regs =
> (struct socfpga_system_manager *)SOCFPGA_SYSMGR_ADDRESS;
>
>  u32 spl_boot_device(void)
>  {
> const u32 bsel = readl(_regs->bootinfo);
>
> -   switch (bsel & 0x7) {
> +   switch (SYSMGR_GET_BOOTINFO_BSEL(bsel)) {
> case 0x1:   /* FPGA (HPS2FPGA Bridge) */
> return BOOT_DEVICE_RAM;
> case 0x2:   /* NAND Flash (1.8V) */
> @@ -68,6 +77,7 @@ u32 spl_boot_mode(const u32 boot_device)
>  }
>  #endif
>
> +#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
>  static void socfpga_nic301_slave_ns(void)
>  {
> writel(0x1, _regs->lwhps2fpgaregs);
> @@ -85,6 +95,7 @@ void board_init_f(ulong dummy)
>  #endif
> unsigned long sdram_size;
> unsigned long reg;
> +   int ret;
>
> /*
>  * First C code to run. Clear fake OCRAM ECC first as SBE
> @@ -117,7 +128,11 @@ void board_init_f(ulong dummy)
> /* Put everything into reset but L4WD0. */
> socfpga_per_reset_all();
> /* Put FPGA bridges into reset too. */
> -   socfpga_bridges_reset(1);
> +   ret = socfpga_bridges_reset(1);
> +   if (ret) {
> +   printf("socfpga_bridges_reset() failed: %d\n", ret);
> +   hang();
> +   }
>
> socfpga_per_reset(SOCFPGA_RESET(SDR), 0);
> socfpga_per_reset(SOCFPGA_RESET(UART0), 0);
> @@ -150,7 +165,11 @@ void board_init_f(ulong dummy)
>
> /* De-assert reset for peripherals and bridges based on handoff */
> reset_deassert_peripherals_handoff();
> -   socfpga_bridges_reset(0);
> +   ret = socfpga_bridges_reset(0);
> +   if (ret) {
> +   printf("socfpga_bridges_reset() failed: %d\n", ret);
> +   hang();
> +   }
>>
>> I managed to debug the hang of the Atlas board to this function call.
>> socfpga_bridges_reset is indeed returning an error from the FPGA, just
>> the hang() is called.
>>
>> The error is not caused by this patch, but is exposed by this patch.
>> Will have to debug why the fpgamgr_test_fpga_ready() call from
>> socfpga_bridges_reset(0) is returning an error.
>>
> I've tested with our CV SoC devkit, it can bootup to U-boot stage.
> Thanks help to debug.
>

I also tested on the CV devkit. It was fine. Make sure you test
this series on as many variations of HW as you can.

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

Re: [U-Boot] [PATCH 1/3] fsl: PPA: add support PPA image validation from NAND and SD

[Sumit Garg]

> -Original Message-
> From: York Sun [mailto:york@nxp.com]
> Sent: Tuesday, April 11, 2017 11:44 AM
> To: Sumit Garg ; u-boot@lists.denx.de
> Cc: Ruchika Gupta ; Prabhakar Kushwaha
> ; Vini Pillai ; Udit
> Agarwal 
> Subject: Re: [PATCH 1/3] fsl: PPA: add support PPA image validation from
> NAND and SD
> 
> On 04/10/2017 10:54 PM, Sumit Garg wrote:
> >> -Original Message-
> >> From: York Sun [mailto:york@nxp.com]
> >> Sent: Monday, April 10, 2017 10:39 PM
> >> To: Sumit Garg ; u-boot@lists.denx.de
> >> Cc: Ruchika Gupta ; Prabhakar Kushwaha
> >> ; Vini Pillai ;
> >> Udit Agarwal 
> >> Subject: Re: [PATCH 1/3] fsl: PPA: add support PPA image validation
> >> from NAND and SD
> >>
> >> On 04/07/2017 04:41 AM, Sumit Garg wrote:
> >>> Signed-off-by: Sumit Garg 
> >>> Signed-off-by: Udit Agarwal 
> >>> Tested-by: Vinitha Pillai 
> >>> ---
> >>>  arch/arm/cpu/armv8/fsl-layerscape/ppa.c | 67
> >>> -
> >>>  1 file changed, 66 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/ppa.c
> >>> b/arch/arm/cpu/armv8/fsl-layerscape/ppa.c
> >>> index 7f87bb8..d8f1d36 100644
> >>> --- a/arch/arm/cpu/armv8/fsl-layerscape/ppa.c
> >>> +++ b/arch/arm/cpu/armv8/fsl-layerscape/ppa.c
> >>> @@ -39,6 +39,10 @@ int ppa_init(void)  #ifdef CONFIG_CHAIN_OF_TRUST
> >>>   uintptr_t ppa_esbc_hdr = CONFIG_SYS_LS_PPA_ESBC_ADDR;
> >>
> >> For MMC and NAND, this CONFIG_SYS_LS_PPA_ESBC_ADDR is actually not
> >> used.
> >> Shall we move the assignment down to XIP section? The Kconfig should
> >> also be updated.
> >>
> >> York
> >
> > As per PPA verification patch for eMMC/SD and NAND:
> >
> > --- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> > +++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> > @@ -179,12 +179,22 @@ config SYS_LS_PPA_ESBC_ADDR
> > default 0x4074 if SYS_LS_PPA_FW_IN_XIP && ARCH_LS1046A
> > default 0x4048 if SYS_LS_PPA_FW_IN_XIP && ARCH_LS1012A
> > default 0x580c4 if SYS_LS_PPA_FW_IN_XIP && FSL_LSCH3
> > +   default 0x70 if SYS_LS_PPA_FW_IN_MMC
> > +   default 0x70 if SYS_LS_PPA_FW_IN_NAND
> > help
> >   If the PPA header firmware locate at XIP flash, such as NOR or
> >   QSPI flash, this address is a directly memory-mapped.
> >   If it is in a serial accessed flash, such as NAND and SD
> >   card, it is a byte offset.
> >
> > CONFIG_SYS_LS_PPA_ESBC_ADDR is used to provide offset on eMMC/SD
> and NAND.
> >
> 
> That's exactly what I was referring to. You are _NOT_ using
> CONFIG_SYS_LS_PPA_ESBC_ADDR value for eMMC/SD or NAND. Instead, you
> use malloc to get a new memory for the header, which I agree it is right to 
> do.
> So the macro CONFIG_SYS_LS_PPA_ESBC_ADDR is not used for either MMC or
> NAND.
> 
> York

Actually I am using CONFIG_SYS_LS_PPA_ESBC_ADDR in case of eMMC/SD or NAND as 
follows:

For eMMC/SD:
+   blk = CONFIG_SYS_LS_PPA_ESBC_ADDR >> 9;
+   cnt = DIV_ROUND_UP(CONFIG_LS_PPA_ESBC_HDR_SIZE, 512);
+   ret = mmc->block_dev.block_read(>block_dev, blk, cnt, ppa_hdr_ddr);
+   if (ret != cnt) {
+   free(ppa_hdr_ddr);
+   printf("MMC/SD read of PPA header failed\n");
+   return -EIO;
+   }

For NAND:
+   ret = nand_read(nand_info[0], (loff_t)CONFIG_SYS_LS_PPA_ESBC_ADDR,
+  _length, (u_char *)ppa_hdr_ddr);
+   if (ret == -EUCLEAN) {
+   free(ppa_hdr_ddr);
+   printf("NAND read of PPA firmware at offset 0x%x failed\n",
+  CONFIG_SYS_LS_PPA_FW_ADDR);
+   return -EIO;
+   }

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

Re: [U-Boot] MTD devices emulation driver (gluebi) support

[Heiko Schocher]

Hello Manuel,

Am 11.04.2017 um 09:20 schrieb manuelcur...@eaton.com:

Hello

Thanks for the answer.
Hi

Thanks for the answer.
I would like ... but I think I'm going to a raw data storage in a ubi volume 
instead of a little jffs2 file system :(  (my need it is just to store some 
bytes of data) ...


Ok ... or you try to use UBIFS ?

bye,
Heiko


Manuel




-
Eaton Industries (France) S.A.S ~ Siège social: 110 Rue Blaise Pascal, Immeuble 
Le Viséo - Bâtiment A Innovallée, 38330, Montbonnot-St.-Martin, France ~ Lieu 
d'enregistrement au registre du commerce: Grenoble ~ Numéro d'enregistrement: 
509 653 176 ~ Capital social souscrit et liberé:€ 16215441 ~ Numéro de TVA: 
FR47509653176
਍
-


De : Heiko Schocher [h...@denx.de]
Envoyé : vendredi 7 avril 2017 13:02
À : Curcio, Manuel
Cc : u-boot@lists.denx.de
Objet : Re: [U-Boot] MTD devices emulation driver (gluebi) support

Hello Manuel,

Am 06.04.2017 um 10:36 schrieb manuelcur...@eaton.com:

Hi,

I want to read a jffs2 file system over ubi from uboot.
  From ubi.h, I found the CONFIG_MTD_UBI_GLUEBI define to allow this 
functionality (I think) :

/* gluebi.c */
#ifdef CONFIG_MTD_UBI_GLUEBI


However, when I set this define, after compilation, I have errors links about 
gluebi functions :

uboot/common/cmd_ubi.c:293: undefined reference to `ubi_gluebi_updated'

And in fact, after search, I didn't find gluebi.c file in uboot.

I use the U-Boot 2015.01 version. When I look the last release, I didn't find 
gluebi.c  too.

Some one can tell me more about that ? How is it possible to read jffs2 (or 
squashfs) from uboot ?


We use the UBI/UBIFS sources from linux, so this part cames
from linux. And as fas as I know, nobody has tried to use
CONFIG_MTD_UBI_GLUEBI
in u-boot yet, so if you want to do this, you have to dig into
this part deeper. Patches are welcome ;-)

bye,
Heiko


thanks !

Manuel




Eaton Industries (France) S.A.S ~ Siège social: 110 Rue Blaise Pascal, Immeuble 
Le Viséo - Bâtiment A Innovallée, 38330, Montbonnot-St.-Martin, France ~ Lieu 
d'enregistrement au registre du commerce: Grenoble ~ Numéro d'enregistrement: 
509 653 176 ~ Capital social souscrit et liberé:EUR 16215441 ~ Numéro de TVA: 
FR47509653176?




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



--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany



--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] i.Mx6q u-boot stuck

[Fabio Estevam]

On Tue, Apr 11, 2017 at 6:29 AM, Fausto Sessego 
wrote
>
>
>
> Could it be a problem of ram configuration?
>

Yes, this could be the problem.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 14/19] arm: socfpga: Add SPL support for Arria 10

[Marek Vasut]

On 04/11/2017 05:42 AM, Dinh Nguyen wrote:
> 
> 
> On 04/10/2017 05:05 PM, Dinh Nguyen wrote:
>>
>>
>> On 04/10/2017 03:43 PM, Dinh Nguyen wrote:
>>>
>>>
>>> On 04/05/2017 04:32 AM, Ley Foon Tan wrote:
 Add SPL support for Arria 10.

 Signed-off-by: Tien Fong Chee 
 Signed-off-by: Ley Foon Tan 
 ---
  arch/arm/mach-socfpga/spl.c | 74 
 ++---
  1 file changed, 69 insertions(+), 5 deletions(-)

 diff --git a/arch/arm/mach-socfpga/spl.c b/arch/arm/mach-socfpga/spl.c
 index 69c433c..e1e62c2 100644
 --- a/arch/arm/mach-socfpga/spl.c
 +++ b/arch/arm/mach-socfpga/spl.c
 @@ -19,23 +19,32 @@
  #include 
  #include 
  #include 
 +#include 
 +#include 
 +#include 
 +#if defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
 +#include 
 +#endif
  
  DECLARE_GLOBAL_DATA_PTR;
  
 +#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
  static struct pl310_regs *const pl310 =
(struct pl310_regs *)CONFIG_SYS_PL310_BASE;
  static struct scu_registers *scu_regs =
(struct scu_registers *)SOCFPGA_MPUSCU_ADDRESS;
  static struct nic301_registers *nic301_regs =
(struct nic301_registers *)SOCFPGA_L3REGS_ADDRESS;
 -static struct socfpga_system_manager *sysmgr_regs =
 +#endif
 +
 +static const struct socfpga_system_manager *sysmgr_regs =
(struct socfpga_system_manager *)SOCFPGA_SYSMGR_ADDRESS;
  
  u32 spl_boot_device(void)
  {
const u32 bsel = readl(_regs->bootinfo);
  
 -  switch (bsel & 0x7) {
 +  switch (SYSMGR_GET_BOOTINFO_BSEL(bsel)) {
case 0x1:   /* FPGA (HPS2FPGA Bridge) */
return BOOT_DEVICE_RAM;
case 0x2:   /* NAND Flash (1.8V) */
 @@ -68,6 +77,7 @@ u32 spl_boot_mode(const u32 boot_device)
  }
  #endif
  
 +#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
  static void socfpga_nic301_slave_ns(void)
  {
writel(0x1, _regs->lwhps2fpgaregs);
 @@ -85,6 +95,7 @@ void board_init_f(ulong dummy)
  #endif
unsigned long sdram_size;
unsigned long reg;
 +  int ret;
  
/*
 * First C code to run. Clear fake OCRAM ECC first as SBE
 @@ -117,7 +128,11 @@ void board_init_f(ulong dummy)
/* Put everything into reset but L4WD0. */
socfpga_per_reset_all();
/* Put FPGA bridges into reset too. */
 -  socfpga_bridges_reset(1);
 +  ret = socfpga_bridges_reset(1);
 +  if (ret) {
 +  printf("socfpga_bridges_reset() failed: %d\n", ret);
 +  hang();
 +  }
  
socfpga_per_reset(SOCFPGA_RESET(SDR), 0);
socfpga_per_reset(SOCFPGA_RESET(UART0), 0);
 @@ -150,7 +165,11 @@ void board_init_f(ulong dummy)
  
/* De-assert reset for peripherals and bridges based on handoff */
reset_deassert_peripherals_handoff();
 -  socfpga_bridges_reset(0);
 +  ret = socfpga_bridges_reset(0);
 +  if (ret) {
 +  printf("socfpga_bridges_reset() failed: %d\n", ret);
 +  hang();
 +  }
> 
> I managed to debug the hang of the Atlas board to this function call.
> socfpga_bridges_reset is indeed returning an error from the FPGA, just
> the hang() is called.
> 
> The error is not caused by this patch, but is exposed by this patch.
> Will have to debug why the fpgamgr_test_fpga_ready() call from
> socfpga_bridges_reset(0) is returning an error.

Super, thanks !

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

[U-Boot] [PATCH] board: ls2080ardb: Add serdes1 protocol 0x4b support

[Santan Kumar]

Signed-off-by: Santan Kumar 
Signed-off-by: Priyanka Jain 
---
 board/freescale/ls2080ardb/eth_ls2080rdb.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/board/freescale/ls2080ardb/eth_ls2080rdb.c 
b/board/freescale/ls2080ardb/eth_ls2080rdb.c
index 799799c..ba584c8 100644
--- a/board/freescale/ls2080ardb/eth_ls2080rdb.c
+++ b/board/freescale/ls2080ardb/eth_ls2080rdb.c
@@ -62,6 +62,13 @@ int board_eth_init(bd_t *bis)
wriop_set_phy_address(WRIOP1_DPMAC8, AQ_PHY_ADDR4);
 
break;
+   case 0x4B:
+   wriop_set_phy_address(WRIOP1_DPMAC1, CORTINA_PHY_ADDR1);
+   wriop_set_phy_address(WRIOP1_DPMAC2, CORTINA_PHY_ADDR2);
+   wriop_set_phy_address(WRIOP1_DPMAC3, CORTINA_PHY_ADDR3);
+   wriop_set_phy_address(WRIOP1_DPMAC4, CORTINA_PHY_ADDR4);
+
+   break;
default:
printf("SerDes1 protocol 0x%x is not supported on LS2080aRDB\n",
   srds_s1);
-- 
1.9.1

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

Re: [U-Boot] [linux-sunxi] Re: [PATCH] sunxi: set up PLL1 on sun6i+ without use dividers

[Maxime Ripard]

On Mon, Apr 10, 2017 at 12:06:27PM +0200, Ondřej Jirman wrote:
> Hi Maxime,
> 
> Maxime Ripard píše v Po 10. 04. 2017 v 08:59 +0200:
> > On Mon, Apr 10, 2017 at 12:19:41AM +0800, Icenowy Zheng wrote:
> > > According to the researching result of Ondrej Jirman, the factor M of
> > > PLL1 shouldn't be used and the factor P should be used only if the
> > > intended frequency is lower than 288MHz. This is proven by the
> > > clk-sun8iw7_tbl.c in the BSP source code -- in there the M value is
> > > always 0 and the maximum frequency that P is not 0 is 224MHz.
> > > 
> > > As P is ignored on sun6i, it's not currently used. This patch removed
> > > the usage of M.
> > > 
> > > This patch is an original work by Ondrej Jirman, however, he didn't add
> > > a Signed-off-by tag here to his commit. So I take this code and added my
> > > Signed-off-by.
> > > 
> > > Signed-off-by: Icenowy Zheng 
> > > ---
> > > 
> > > This is a critical patch, and should be added to 2017.05.
> > > 
> > > It has been verified by the Armbian.
> > 
> > This doesn't mean anything. How has this been verified?
> 
> We already discussed this here: https://patchwork.kernel.org/patch/9446
> 365/

Yes, I know. I wasn't discussing the fact that this was the right
thing to do or not, just that the wording didn't allow anyone to get
an idea of *how* to reproduce that test on their own board.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: set up PLL1 on sun6i+ without use dividers

[Maxime Ripard]

On Mon, Apr 10, 2017 at 04:43:00PM +0800, icen...@aosc.io wrote:
> 在 2017-04-10 14:59，Maxime Ripard 写道：
> > On Mon, Apr 10, 2017 at 12:19:41AM +0800, Icenowy Zheng wrote:
> > > According to the researching result of Ondrej Jirman, the factor M of
> > > PLL1 shouldn't be used and the factor P should be used only if the
> > > intended frequency is lower than 288MHz. This is proven by the
> > > clk-sun8iw7_tbl.c in the BSP source code -- in there the M value is
> > > always 0 and the maximum frequency that P is not 0 is 224MHz.
> > > 
> > > As P is ignored on sun6i, it's not currently used. This patch removed
> > > the usage of M.
> > > 
> > > This patch is an original work by Ondrej Jirman, however, he didn't
> > > add
> > > a Signed-off-by tag here to his commit. So I take this code and
> > > added my
> > > Signed-off-by.
> > > 
> > > Signed-off-by: Icenowy Zheng 
> > > ---
> > > 
> > > This is a critical patch, and should be added to 2017.05.
> > > 
> > > It has been verified by the Armbian.
> > 
> > This doesn't mean anything. How has this been verified?
> 
> Armbian has included this patch since several months ago,
> and it's proven that without it DVFS will be not stable.
> (And it proved at least it won't make the system more
> unstable). See [1].

Then, this should have been your commit log.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] board/t1024rdb: enable board-level reset when issuing reset command

[Shengzhou Liu]

> -Original Message-
> From: York Sun [mailto:york@nxp.com]
> Sent: Tuesday, April 11, 2017 1:14 AM
> To: Shengzhou Liu ; u-boot@lists.denx.de
> Subject: Re: [PATCH] board/t1024rdb: enable board-level reset when issuing
> reset command
> 
> On 04/10/2017 01:14 AM, Shengzhou Liu wrote:
> > As board-specific reset logic, it needs to issue reset signal via CPLD
> > when issuing 'reset' command in u-boot, this patch solves the issue of
> > reset command not working on T1024RDB.
> 
> Shengzhou,
> 
> Doesn't the RST_REQ signal work for this board?
> 
> York

York,  

Yes, RST_REQ can't reliably work without CPLD reset on T1024RDB, it needs a 
board-level reset via CPLD reset logic. 

Shengzhou


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

[U-Boot] [PATCH v4 1/2] at91: video: Support driver-model for the HLCD driver

[Songjun Wu]

Add driver-model support to this driver.

Signed-off-by: Songjun Wu 
---

Changes in v4:
- Add "atmel,at91sam9x5-hlcdc" to atmel_hlcdc_ids[].

Changes in v3:
- Replace lcdc_readl/lcdc_writel with real/writel
- Replace while() with wait_for_bit().
- Disable the clock if the clock is enabled and
  error occurs.

Changes in v2:
- Due to the peripheral clock driver improvement, remove
  the unneccessary clock calling.

 drivers/video/Kconfig|   6 +
 drivers/video/atmel_hlcdfb.c | 482 ---
 2 files changed, 417 insertions(+), 71 deletions(-)

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 2069576958..0f49612cd0 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -371,6 +371,12 @@ config DISPLAY
   The devices provide a simple interface to start up the display,
   read display information and enable it.
 
+config ATMEL_HLCD
+   bool "Enable ATMEL video support using HLCDC"
+   depends on DM_VIDEO
+   help
+  HLCDC supports video output to an attached LCD panel.
+
 config VIDEO_BROADWELL_IGD
bool "Enable Intel Broadwell integrated graphics device"
depends on X86
diff --git a/drivers/video/atmel_hlcdfb.c b/drivers/video/atmel_hlcdfb.c
index 960b474b76..59b9c45616 100644
--- a/drivers/video/atmel_hlcdfb.c
+++ b/drivers/video/atmel_hlcdfb.c
@@ -10,13 +10,22 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include 
+#include 
+#include 
 #include 
 
 #if defined(CONFIG_LCD_LOGO)
 #include 
 #endif
 
+DECLARE_GLOBAL_DATA_PTR;
+
+#ifndef CONFIG_DM_VIDEO
+
 /* configurable parameters */
 #define ATMEL_LCDC_CVAL_DEFAULT0xc8
 #define ATMEL_LCDC_DMA_BURST_LEN   8
@@ -26,19 +35,16 @@
 
 #define ATMEL_LCDC_FIFO_SIZE   512
 
-#define lcdc_readl(reg)__raw_readl((reg))
-#define lcdc_writel(reg, val)  __raw_writel((val), (reg))
-
 /*
  * the CLUT register map as following
  * RCLUT(24 ~ 16), GCLUT(15 ~ 8), BCLUT(7 ~ 0)
  */
 void lcd_setcolreg(ushort regno, ushort red, ushort green, ushort blue)
 {
-   lcdc_writel(((red << LCDC_BASECLUT_RCLUT_Pos) & LCDC_BASECLUT_RCLUT_Msk)
-   | ((green << LCDC_BASECLUT_GCLUT_Pos) & LCDC_BASECLUT_GCLUT_Msk)
-   | ((blue << LCDC_BASECLUT_BCLUT_Pos) & LCDC_BASECLUT_BCLUT_Msk),
-   panel_info.mmio + ATMEL_LCDC_LUT(regno));
+   writel(panel_info.mmio + ATMEL_LCDC_LUT(regno),
+  ((red << LCDC_BASECLUT_RCLUT_Pos) & LCDC_BASECLUT_RCLUT_Msk)
+  | ((green << LCDC_BASECLUT_GCLUT_Pos) & LCDC_BASECLUT_GCLUT_Msk)
+  | ((blue << LCDC_BASECLUT_BCLUT_Pos) & LCDC_BASECLUT_BCLUT_Msk));
 }
 
 ushort *configuration_get_cmap(void)
@@ -55,6 +61,7 @@ void lcd_ctrl_init(void *lcdbase)
unsigned long value;
struct lcd_dma_desc *desc;
struct atmel_hlcd_regs *regs;
+   int ret;
 
if (!has_lcdc())
return; /* No lcdc */
@@ -62,21 +69,29 @@ void lcd_ctrl_init(void *lcdbase)
regs = (struct atmel_hlcd_regs *)panel_info.mmio;
 
/* Disable DISP signal */
-   lcdc_writel(>lcdc_lcddis, LCDC_LCDDIS_DISPDIS);
-   while ((lcdc_readl(>lcdc_lcdsr) & LCDC_LCDSR_DISPSTS))
-   udelay(1);
+   writel(LCDC_LCDDIS_DISPDIS, >lcdc_lcddis);
+   ret = wait_for_bit(__func__, >lcdc_lcdsr, LCDC_LCDSR_DISPSTS,
+  false, 1000, false);
+   if (ret)
+   printf("%s: %d: Timeout!\n", __func__, __LINE__);
/* Disable synchronization */
-   lcdc_writel(>lcdc_lcddis, LCDC_LCDDIS_SYNCDIS);
-   while ((lcdc_readl(>lcdc_lcdsr) & LCDC_LCDSR_LCDSTS))
-   udelay(1);
+   writel(LCDC_LCDDIS_SYNCDIS, >lcdc_lcddis);
+   ret = wait_for_bit(__func__, >lcdc_lcdsr, LCDC_LCDSR_LCDSTS,
+  false, 1000, false);
+   if (ret)
+   printf("%s: %d: Timeout!\n", __func__, __LINE__);
/* Disable pixel clock */
-   lcdc_writel(>lcdc_lcddis, LCDC_LCDDIS_CLKDIS);
-   while ((lcdc_readl(>lcdc_lcdsr) & LCDC_LCDSR_CLKSTS))
-   udelay(1);
+   writel(LCDC_LCDDIS_CLKDIS, >lcdc_lcddis);
+   ret = wait_for_bit(__func__, >lcdc_lcdsr, LCDC_LCDSR_CLKSTS,
+  false, 1000, false);
+   if (ret)
+   printf("%s: %d: Timeout!\n", __func__, __LINE__);
/* Disable PWM */
-   lcdc_writel(>lcdc_lcddis, LCDC_LCDDIS_PWMDIS);
-   while ((lcdc_readl(>lcdc_lcdsr) & LCDC_LCDSR_PWMSTS))
-   udelay(1);
+   writel(LCDC_LCDDIS_PWMDIS, >lcdc_lcddis);
+   ret = wait_for_bit(__func__, >lcdc_lcdsr, LCDC_LCDSR_PWMSTS,
+  false, 1000, false);
+   if (ret)
+   printf("%s: %d: Timeout!\n", __func__, __LINE__);
 
/* Set pixel clock */
value = get_lcdc_clk_rate(0) / panel_info.vl_clk;
@@ -85,23 +100,23 @@ void lcd_ctrl_init(void *lcdbase)
 
if 

[U-Boot] [PATCH v4 2/2] at91: video: DT binding for HLCDC driver

[Songjun Wu]

DT binding documentation for atmel HLCDC driver.

Signed-off-by: Songjun Wu 
---

Changes in v4:
- Add "atmel,at91sam9x5-hlcdc" to compatible.

Changes in v3:
- Add 'atmel,output-mode' entry in dts.

Changes in v2: None

 doc/device-tree-bindings/video/atme-hlcdc.txt | 42 +++
 1 file changed, 42 insertions(+)
 create mode 100644 doc/device-tree-bindings/video/atme-hlcdc.txt

diff --git a/doc/device-tree-bindings/video/atme-hlcdc.txt 
b/doc/device-tree-bindings/video/atme-hlcdc.txt
new file mode 100644
index 00..1f022568f9
--- /dev/null
+++ b/doc/device-tree-bindings/video/atme-hlcdc.txt
@@ -0,0 +1,42 @@
+Atmel HLCDC Framebuffer
+-
+Required properties:
+- compatible :
+   "atmel,sama5d2-hlcdc", "atmel,at91sam9x5-hlcdc".
+- reg: physical base address of the controller and length of memory mapped
+   region.
+- clocks: phandles to input clocks.
+- atmel,vl-bpix: Bits per pixel.
+- atmel,output-mode: LCD Controller Output Mode,
+  The unit is bits per pixel, there are four values,
+  <12>, <16>, <18>, <24>, the default value is <24>.
+- atmel,guard-time: lcd guard time (Delay in frame periods).
+- display-timings: please refer the displaymode.txt.
+
+Example:
+hlcdc: hlcdc@f000 {
+   u-boot,dm-pre-reloc;
+   compatible = "atmel,sama5d2-hlcdc";
+   reg = <0xf000 0x2000>;
+   clocks = <_clk>;
+   atmel,vl-bpix = <4>;
+   atmel,output-mode = <24>;
+   atmel,guard-time = <1>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_lcd_base _lcd_pwm _lcd_rgb666>;
+   status = "okay";
+
+   display-timings {
+   480x272 {
+   clock-frequency = <900>;
+   hactive = <480>;
+   vactive = <272>;
+   hsync-len = <41>;
+   hfront-porch = <2>;
+   hback-porch = <2>;
+   vfront-porch = <2>;
+   vback-porch = <2>;
+   vsync-len = <11>;
+   };
+   };
+};
\ No newline at end of file
-- 
2.11.0

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

[U-Boot] [PATCH v4 0/2] at91: video: add driver for Atmel HLCD controller

[Songjun Wu]

The i2c driver includes two parts.
1) Driver code to implement the HLCD function.
2) Device tree binding documentation, it describes how to add
   the HLCD in device tree.

Changes in v4:
- Add "atmel,at91sam9x5-hlcdc" to atmel_hlcdc_ids[].
- Add "atmel,at91sam9x5-hlcdc" to compatible.

Changes in v3:
- Replace lcdc_readl/lcdc_writel with real/writel
- Replace while() with wait_for_bit().
- Disable the clock if the clock is enabled and
  error occurs.
- Add 'atmel,output-mode' entry in dts.

Changes in v2:
- Due to the peripheral clock driver improvement, remove
  the unneccessary clock calling.

Songjun Wu (2):
  at91: video: Support driver-model for the HLCD driver
  at91: video: DT binding for HLCDC driver

 doc/device-tree-bindings/video/atme-hlcdc.txt |  42 +++
 drivers/video/Kconfig |   6 +
 drivers/video/atmel_hlcdfb.c  | 482 ++
 3 files changed, 459 insertions(+), 71 deletions(-)
 create mode 100644 doc/device-tree-bindings/video/atme-hlcdc.txt

-- 
2.11.0

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

[U-Boot] [PATCH v2 2/2] doc: dtbinding: add pwm binding file

[Kever Yang]

This is a copy from kernel.

Signed-off-by: Kever Yang 
---

Changes in v2: None

 doc/device-tree-bindings/pwm/pwm.txt | 69 
 1 file changed, 69 insertions(+)
 create mode 100644 doc/device-tree-bindings/pwm/pwm.txt

diff --git a/doc/device-tree-bindings/pwm/pwm.txt 
b/doc/device-tree-bindings/pwm/pwm.txt
new file mode 100644
index 000..8556263
--- /dev/null
+++ b/doc/device-tree-bindings/pwm/pwm.txt
@@ -0,0 +1,69 @@
+Specifying PWM information for devices
+==
+
+1) PWM user nodes
+-
+
+PWM users should specify a list of PWM devices that they want to use
+with a property containing a 'pwm-list':
+
+   pwm-list ::=  [pwm-list]
+   single-pwm ::=  
+   pwm-phandle : phandle to PWM controller node
+   pwm-specifier : array of #pwm-cells specifying the given PWM
+   (controller specific)
+
+PWM properties should be named "pwms". The exact meaning of each pwms
+property must be documented in the device tree binding for each device.
+An optional property "pwm-names" may contain a list of strings to label
+each of the PWM devices listed in the "pwms" property. If no "pwm-names"
+property is given, the name of the user node will be used as fallback.
+
+Drivers for devices that use more than a single PWM device can use the
+"pwm-names" property to map the name of the PWM device requested by the
+pwm_get() call to an index into the list given by the "pwms" property.
+
+The following example could be used to describe a PWM-based backlight
+device:
+
+   pwm: pwm {
+   #pwm-cells = <2>;
+   };
+
+   [...]
+
+   bl: backlight {
+   pwms = < 0 500>;
+   pwm-names = "backlight";
+   };
+
+Note that in the example above, specifying the "pwm-names" is redundant
+because the name "backlight" would be used as fallback anyway.
+
+pwm-specifier typically encodes the chip-relative PWM number and the PWM
+period in nanoseconds.
+
+Optionally, the pwm-specifier can encode a number of flags (defined in
+) in a third cell:
+- PWM_POLARITY_INVERTED: invert the PWM signal polarity
+
+Example with optional PWM specifier for inverse polarity
+
+   bl: backlight {
+   pwms = < 0 500 PWM_POLARITY_INVERTED>;
+   pwm-names = "backlight";
+   };
+
+2) PWM controller nodes
+---
+
+PWM controller nodes must specify the number of cells used for the
+specifier using the '#pwm-cells' property.
+
+An example PWM controller might look like this:
+
+   pwm: pwm@7000a000 {
+   compatible = "nvidia,tegra20-pwm";
+   reg = <0x7000a000 0x100>;
+   #pwm-cells = <2>;
+   };
-- 
1.9.1

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

[U-Boot] [PATCH v2 1/2] power: regulator: pwm: support pwm polarity setting

[Kever Yang]

The latest kernel PWM drivers enable the polarity settings. When system
run from U-Boot to kerenl, if there are differences in polarity set or
duty cycle, the PMW will re-init:
  close -> set polarity and duty cycle -> enable the PWM.
The power supply controled by pwm regulator may have voltage shaking,
which lead to the system not stable.

Signed-off-by: Elaine Zhang 
Signed-off-by: Kever Yang 
---

Changes in v2:
- use pwm_set_invert() instead of pwm_set_init()
- add comment for polarity

 drivers/power/regulator/pwm_regulator.c | 16 ++--
 drivers/pwm/pwm-uclass.c| 10 ++
 drivers/pwm/rk_pwm.c| 17 -
 include/pwm.h   |  9 +
 4 files changed, 49 insertions(+), 3 deletions(-)

diff --git a/drivers/power/regulator/pwm_regulator.c 
b/drivers/power/regulator/pwm_regulator.c
index 4875238..3ffe3a1 100644
--- a/drivers/power/regulator/pwm_regulator.c
+++ b/drivers/power/regulator/pwm_regulator.c
@@ -24,6 +24,12 @@ struct pwm_regulator_info {
int pwm_id;
/* the period of one PWM cycle */
int period_ns;
+   /*
+* the polarity of one PWM
+* 0: normal polarity
+* 1: inverted polarity
+*/
+   int polarity;
struct udevice *pwm;
/* initialize voltage of regulator */
unsigned int init_voltage;
@@ -49,7 +55,7 @@ static int pwm_voltage_to_duty_cycle_percentage(struct 
udevice *dev, int req_uV)
int max_uV = priv->max_voltage;
int diff = max_uV - min_uV;
 
-   return 100 - (((req_uV * 100) - (min_uV * 100)) / diff);
+   return ((req_uV * 100) - (min_uV * 100)) / diff;
 }
 
 static int pwm_regulator_get_voltage(struct udevice *dev)
@@ -67,6 +73,12 @@ static int pwm_regulator_set_voltage(struct udevice *dev, 
int uvolt)
 
duty_cycle = pwm_voltage_to_duty_cycle_percentage(dev, uvolt);
 
+   ret = pwm_set_invert(priv->pwm, priv->pwm_id, priv->polarity);
+   if (ret) {
+   dev_err(dev, "Failed to init PWM\n");
+   return ret;
+   }
+
ret = pwm_set_config(priv->pwm, priv->pwm_id,
(priv->period_ns / 100) * duty_cycle, priv->period_ns);
if (ret) {
@@ -97,9 +109,9 @@ static int pwm_regulator_ofdata_to_platdata(struct udevice 
*dev)
debug("%s: Cannot get PWM phandle: ret=%d\n", __func__, ret);
return ret;
}
-   /* TODO: pwm_id here from device tree if needed */
 
priv->period_ns = args.args[1];
+   priv->polarity = args.args[2];
 
priv->init_voltage = fdtdec_get_int(blob, node,
"regulator-init-microvolt", -1);
diff --git a/drivers/pwm/pwm-uclass.c b/drivers/pwm/pwm-uclass.c
index c2200af..d1d7fce 100644
--- a/drivers/pwm/pwm-uclass.c
+++ b/drivers/pwm/pwm-uclass.c
@@ -9,6 +9,16 @@
 #include 
 #include 
 
+int pwm_set_invert(struct udevice *dev, uint channel, uint polarity)
+{
+   struct pwm_ops *ops = pwm_get_ops(dev);
+
+   if (!ops->set_invert)
+   return -ENOSYS;
+
+   return ops->set_invert(dev, channel, polarity);
+}
+
 int pwm_set_config(struct udevice *dev, uint channel, uint period_ns,
   uint duty_ns)
 {
diff --git a/drivers/pwm/rk_pwm.c b/drivers/pwm/rk_pwm.c
index 9254f5b..f003d09 100644
--- a/drivers/pwm/rk_pwm.c
+++ b/drivers/pwm/rk_pwm.c
@@ -21,8 +21,22 @@ DECLARE_GLOBAL_DATA_PTR;
 struct rk_pwm_priv {
struct rk3288_pwm *regs;
ulong freq;
+   uint enable_conf;
 };
 
+static int rk_pwm_set_invert(struct udevice *dev, uint channel, uint polarity)
+{
+   struct rk_pwm_priv *priv = dev_get_priv(dev);
+
+   debug("%s: polarity=%u\n", __func__, polarity);
+   if (polarity)
+   priv->enable_conf |= PWM_DUTY_NEGATIVE | PWM_INACTIVE_POSTIVE;
+   else
+   priv->enable_conf |= PWM_DUTY_POSTIVE | PWM_INACTIVE_NEGATIVE;
+
+   return 0;
+}
+
 static int rk_pwm_set_config(struct udevice *dev, uint channel, uint period_ns,
 uint duty_ns)
 {
@@ -32,7 +46,7 @@ static int rk_pwm_set_config(struct udevice *dev, uint 
channel, uint period_ns,
 
debug("%s: period_ns=%u, duty_ns=%u\n", __func__, period_ns, duty_ns);
writel(PWM_SEL_SRC_CLK | PWM_OUTPUT_LEFT | PWM_LP_DISABLE |
-   PWM_CONTINUOUS | PWM_DUTY_POSTIVE | PWM_INACTIVE_POSTIVE |
+   PWM_CONTINUOUS | priv->enable_conf |
RK_PWM_DISABLE,
>ctrl);
 
@@ -83,6 +97,7 @@ static int rk_pwm_probe(struct udevice *dev)
 }
 
 static const struct pwm_ops rk_pwm_ops = {
+   .set_invert = rk_pwm_set_invert,
.set_config = rk_pwm_set_config,
.set_enable = rk_pwm_set_enable,
 };
diff --git a/include/pwm.h b/include/pwm.h
index 851915e..66c6bf0 100644
--- a/include/pwm.h
+++ b/include/pwm.h
@@ -14,6 +14,15 @@
 /* struct pwm_ops: Operations 

Re: [U-Boot] Unbricking process with separate environment binary?

[Lukasz Majewski]

Hi John,

> nstead of having 2 builds of u-boot, one which defaults to fastboot
> and one for normal booting, is it possible to have one u-boot binary
> and a separate environment piece (especially for bootcmd, but maybe
> also for some scripts)? 

If I might ask - where your envs are stored? Do they have a separate
area in NAND or eMMC memory?

If yes, then I suppose that you also have the possibility to write data
to this memory in the production?

If yes (again) then maybe it would be better to only adjust (and
replace) the default environment on board?

For example:

1. You extract envs by using the scripts/get_default_envs.sh - modify
it and then use mkenvimage to produce new env image.

2. You store u-boot (with NAND/eMMC not programmed) to your device.
This u-boot has default environment with instructions for flashing.

3. You flash your final envs prepared in point 1.

p.s. This scheme also works with "redundant" envs.

Best regards,

Lukasz Majewski

--

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

[U-Boot] [PATCH] arm: ls1021atwr: Enable RGMII TX/RX clock internal delay for AR8033

[Alison Wang]

Since commit ce412b7, RGMII TX clock internal delay is not enabled for
AR8033 unconditionally. On LS1021ATWR board, the third port eTSEC3 uses
AR8033 in RGMII mode. The TX/RX internal delay needs to be enabled.

This patch will set PHY_INTERFACE_MODE_RGMII_ID to enable RGMII TX/RX
clock internal delay for AR8033 on the third port.

Signed-off-by: Alison Wang 
---
 board/freescale/ls1021atwr/ls1021atwr.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/board/freescale/ls1021atwr/ls1021atwr.c 
b/board/freescale/ls1021atwr/ls1021atwr.c
index d96fd77..ff32d5c 100644
--- a/board/freescale/ls1021atwr/ls1021atwr.c
+++ b/board/freescale/ls1021atwr/ls1021atwr.c
@@ -273,6 +273,7 @@ int board_eth_init(bd_t *bis)
 #endif
 #ifdef CONFIG_TSEC3
SET_STD_TSEC_INFO(tsec_info[num], 3);
+   tsec_info[num].interface = PHY_INTERFACE_MODE_RGMII_ID;
num++;
 #endif
if (!num) {
-- 
2.1.0.27.g96db324

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

Re: [U-Boot] [PATCH 1/3] fsl: PPA: add support PPA image validation from NAND and SD

[York Sun]

On 04/10/2017 10:54 PM, Sumit Garg wrote:

-Original Message-
From: York Sun [mailto:york@nxp.com]
Sent: Monday, April 10, 2017 10:39 PM
To: Sumit Garg ; u-boot@lists.denx.de
Cc: Ruchika Gupta ; Prabhakar Kushwaha
; Vini Pillai ; Udit
Agarwal 
Subject: Re: [PATCH 1/3] fsl: PPA: add support PPA image validation from
NAND and SD

On 04/07/2017 04:41 AM, Sumit Garg wrote:

Signed-off-by: Sumit Garg 
Signed-off-by: Udit Agarwal 
Tested-by: Vinitha Pillai 
---
 arch/arm/cpu/armv8/fsl-layerscape/ppa.c | 67
-
 1 file changed, 66 insertions(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/ppa.c
b/arch/arm/cpu/armv8/fsl-layerscape/ppa.c
index 7f87bb8..d8f1d36 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/ppa.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/ppa.c
@@ -39,6 +39,10 @@ int ppa_init(void)
 #ifdef CONFIG_CHAIN_OF_TRUST
uintptr_t ppa_esbc_hdr = CONFIG_SYS_LS_PPA_ESBC_ADDR;


For MMC and NAND, this CONFIG_SYS_LS_PPA_ESBC_ADDR is actually not
used.
Shall we move the assignment down to XIP section? The Kconfig should also be
updated.

York


As per PPA verification patch for eMMC/SD and NAND:

--- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
@@ -179,12 +179,22 @@ config SYS_LS_PPA_ESBC_ADDR
default 0x4074 if SYS_LS_PPA_FW_IN_XIP && ARCH_LS1046A
default 0x4048 if SYS_LS_PPA_FW_IN_XIP && ARCH_LS1012A
default 0x580c4 if SYS_LS_PPA_FW_IN_XIP && FSL_LSCH3
+   default 0x70 if SYS_LS_PPA_FW_IN_MMC
+   default 0x70 if SYS_LS_PPA_FW_IN_NAND
help
  If the PPA header firmware locate at XIP flash, such as NOR or
  QSPI flash, this address is a directly memory-mapped.
  If it is in a serial accessed flash, such as NAND and SD
  card, it is a byte offset.

CONFIG_SYS_LS_PPA_ESBC_ADDR is used to provide offset on eMMC/SD and NAND.



That's exactly what I was referring to. You are _NOT_ using 
CONFIG_SYS_LS_PPA_ESBC_ADDR value for eMMC/SD or NAND. Instead, you use 
malloc to get a new memory for the header, which I agree it is right to 
do. So the macro CONFIG_SYS_LS_PPA_ESBC_ADDR is not used for either MMC 
or NAND.


York

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

Re: [U-Boot] [PATCH] am335x_evm_usbspl_defconfig: Fix USB RNDIS boot

[Vignesh R]

On Tuesday 11 April 2017 11:25 AM, Lokesh Vutla wrote:
> 
> 
> On Tuesday 11 April 2017 10:30 AM, Vignesh R wrote:
>>
>>
>> On Monday 10 April 2017 06:28 PM, Lokesh Vutla wrote:
>>>
>>>
>>> On 4/10/2017 1:56 PM, Vignesh R wrote:
 It seems few config options are missing in the current
 am335x_evm_usbspl_defconfig causing USB RNDIS boot to fail on AM335x
 EVM. Fix this by adding required configs.

 Signed-off-by: Vignesh R 
 ---
  configs/am335x_evm_usbspl_defconfig | 4 
  1 file changed, 4 insertions(+)

 diff --git a/configs/am335x_evm_usbspl_defconfig 
 b/configs/am335x_evm_usbspl_defconfig
 index a79470e88685..0a32d41eae67 100644
 --- a/configs/am335x_evm_usbspl_defconfig
 +++ b/configs/am335x_evm_usbspl_defconfig
>>>
>>> Any thing that is blocking to use am335x_evm_defconfig for usb eth boot
>>> mode? 
>>
>> Yes, I guess first thing needed is would be SPL_DM support as AFAIK,
>> DM_ETH forces to use DM in both SPL and U-Boot.
> 
> okay. am335x has its own problems enabling SPL_DM on which I am working
> on. Can you check am43xx which has SPL_DM enabled?(I understand there is
> no am43xx_evm_usbspl_defconfig but wanted to know what is blocking to
> use am43xx_evm_defconfig for usb_eth mode?)
> 

dwc3 usb peripheral needs be converted to DM as first step. Need to
revisit: http://lists.denx.de/pipermail/u-boot/2016-March/250115.html

This is something that I have in my list of TODOs.


-- 
Regards
Vignesh
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot