Re: [U-Boot] [PATCH] board: ti: DRA7: Add DP83867 TI phy for rev c

[Mugunthan V N]

On Wednesday 30 March 2016 11:28 PM, Dan Murphy wrote:
> Enable the TI DP83867 Giga bit phy on the
> dra7 rev c board.  The rx and tx internal
> delays are need for this board so the usage
> of RGMII_ID is required.
> 
> Signed-off-by: Dan Murphy 

Acked-by: Mugunthan V N 

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

Re: [U-Boot] [PATCH] dm: core: device: set pinctrl state for pinctrl device

[Peng Fan]

Hi Simon,

On Sat, Mar 12, 2016 at 07:51:47PM -0700, Simon Glass wrote:
>+Masahiro
>
>On 11 March 2016 at 22:17, Peng Fan  wrote:
>> We may have pinmux settings for pinctrl device, like the following
>> example:
>> "
>>  {
>> pinctrl-names = "default";
>> pinctrl-0 = <_hog_1>;
>> imx6ul-evk {
>> pinctrl_hog_1: hoggrp-1 {
>> fsl,pins = <
>> MX6UL_PAD_UART1_RTS_B__GPIO1_IO19   
>> 0x17059 /* SD1 CD */
>> MX6UL_PAD_GPIO1_IO05__USDHC1_VSELECT
>> 0x17059 /* SD1 VSELECT */
>> MX6UL_PAD_GPIO1_IO09__GPIO1_IO09
>> 0x17059 /* SD1 RESET */
>> MX6UL_PAD_SNVS_TAMPER0__GPIO5_IO00  
>> 0x8000
>> >;
>> };
>> [..]
>> };
>> "
>>
>> We should not only select pinctrl state for non pinctrl devices, we
>> need also to handle pin mux settings such as pinctrl_log for pinctrl
>> devices.
>>
>> So at the end of probing process of pinctrl device, select the default
>> state of pinctrl device.
>>
>> Signed-off-by: Peng Fan 
>> Cc: Simon Glass 
>> ---
>>  drivers/core/device.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/core/device.c b/drivers/core/device.c
>> index cb24a61..6b1ba22 100644
>> --- a/drivers/core/device.c
>> +++ b/drivers/core/device.c
>> @@ -332,6 +332,9 @@ int device_probe(struct udevice *dev)
>> if (ret)
>> goto fail_uclass;
>>
>> +   if (dev->parent && device_get_uclass_id(dev) == UCLASS_PINCTRL)
>> +   pinctrl_select_state(dev, "default");
>> +
>> return 0;
>>  fail_uclass:
>> if (device_remove(dev)) {
>> --
>> 2.6.2
>>
>
>Reviewed-by: Simon Glass 

Will you pick up this patch?

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

[U-Boot] [PATCH V2] common: env: support sata device

[Peng Fan]

Introduce env support for sata device.
1. Implement write_env/read_env/env_relocate_spec/saveenv/sata_get_env_dev
2. If want to enable this feature, define CONFIG_ENV_IS_IN_SATA, and
   define CONFIG_SYS_SATA_ENV_DEV or implement your own sata_get_ev_dev.

Signed-off-by: Peng Fan 
Cc: Simon Glass 
Cc: Joe Hershberger 
Cc: Bin Meng 
Cc: Stefan Roese 
Cc: Heiko Schocher 
Cc: Stuart Longland 
Cc: Maxime Ripard 
Cc: Tom Rini 
---

V2:
 Add error msg when ENV REDUND, since not supported now.
 Discard ent_ptr
 Use blk_dread/blk_dwrite


 cmd/nvedit.c  |   3 +-
 common/Makefile   |   1 +
 common/env_sata.c | 129 ++
 3 files changed, 132 insertions(+), 1 deletion(-)
 create mode 100644 common/env_sata.c

diff --git a/cmd/nvedit.c b/cmd/nvedit.c
index 9cf884e..b67563b 100644
--- a/cmd/nvedit.c
+++ b/cmd/nvedit.c
@@ -49,12 +49,13 @@ DECLARE_GLOBAL_DATA_PTR;
!defined(CONFIG_ENV_IS_IN_NAND) && \
!defined(CONFIG_ENV_IS_IN_NVRAM)&& \
!defined(CONFIG_ENV_IS_IN_ONENAND)  && \
+   !defined(CONFIG_ENV_IS_IN_SATA) && \
!defined(CONFIG_ENV_IS_IN_SPI_FLASH)&& \
!defined(CONFIG_ENV_IS_IN_REMOTE)   && \
!defined(CONFIG_ENV_IS_IN_UBI)  && \
!defined(CONFIG_ENV_IS_NOWHERE)
 # error Define one of CONFIG_ENV_IS_IN_{EEPROM|FLASH|DATAFLASH|ONENAND|\
-SPI_FLASH|NVRAM|MMC|FAT|EXT4|REMOTE|UBI} or CONFIG_ENV_IS_NOWHERE
+SATA|SPI_FLASH|NVRAM|MMC|FAT|EXT4|REMOTE|UBI} or CONFIG_ENV_IS_NOWHERE
 #endif
 
 /*
diff --git a/common/Makefile b/common/Makefile
index 9a4b817..b23f312 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_ENV_IS_IN_EXT4) += env_ext4.o
 obj-$(CONFIG_ENV_IS_IN_NAND) += env_nand.o
 obj-$(CONFIG_ENV_IS_IN_NVRAM) += env_nvram.o
 obj-$(CONFIG_ENV_IS_IN_ONENAND) += env_onenand.o
+obj-$(CONFIG_ENV_IS_IN_SATA) += env_sata.o
 obj-$(CONFIG_ENV_IS_IN_SPI_FLASH) += env_sf.o
 obj-$(CONFIG_ENV_IS_IN_REMOTE) += env_remote.o
 obj-$(CONFIG_ENV_IS_IN_UBI) += env_ubi.o
diff --git a/common/env_sata.c b/common/env_sata.c
new file mode 100644
index 000..16c7daa
--- /dev/null
+++ b/common/env_sata.c
@@ -0,0 +1,129 @@
+/*
+ * (C) Copyright 2010-2016 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/* #define DEBUG */
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#if defined(CONFIG_ENV_SIZE_REDUND) || defined(CONFIG_ENV_OFFSET_REDUND)
+#error ENV REDUND not supported
+#endif
+
+#if !defined(CONFIG_ENV_OFFSET) || !defined(CONFIG_ENV_SIZE)
+#error CONFIG_ENV_OFFSET or CONFIG_ENV_SIZE not defined
+#endif
+
+char *env_name_spec = "SATA";
+
+DECLARE_GLOBAL_DATA_PTR;
+
+__weak int sata_get_env_dev(void)
+{
+   return CONFIG_SYS_SATA_ENV_DEV;
+}
+
+int env_init(void)
+{
+   /* use default */
+   gd->env_addr = (ulong)_environment[0];
+   gd->env_valid = 1;
+
+   return 0;
+}
+
+#ifdef CONFIG_CMD_SAVEENV
+static inline int write_env(struct blk_desc *sata, unsigned long size,
+   unsigned long offset, void *buffer)
+{
+   uint blk_start, blk_cnt, n;
+
+   blk_start = ALIGN(offset, sata->blksz) / sata->blksz;
+   blk_cnt   = ALIGN(size, sata->blksz) / sata->blksz;
+
+   n = blk_dwrite(sata, blk_start, blk_cnt, buffer);
+
+   return (n == blk_cnt) ? 0 : -1;
+}
+
+int saveenv(void)
+{
+   ALLOC_CACHE_ALIGN_BUFFER(env_t, env_new, 1);
+   struct blk_desc *sata = NULL;
+   int env_sata, ret;
+
+   if (sata_initialize())
+   return 1;
+
+   env_sata = sata_get_env_dev();
+
+   sata = sata_get_dev(env_sata);
+   if (sata == NULL) {
+   printf("Unknown SATA(%d) device for environment!\n",
+  env_sata);
+   return 1;
+   }
+
+   ret = env_export(env_new);
+   if (ret)
+   return 1;
+
+   printf("Writing to SATA(%d)...", env_sata);
+   if (write_env(sata, CONFIG_ENV_SIZE, CONFIG_ENV_OFFSET, _new)) {
+   puts("failed\n");
+   return 1;
+   }
+
+   puts("done\n");
+   return 0;
+}
+#endif /* CONFIG_CMD_SAVEENV */
+
+static inline int read_env(struct blk_desc *sata, unsigned long size,
+  unsigned long offset, void *buffer)
+{
+   uint blk_start, blk_cnt, n;
+
+   blk_start = ALIGN(offset, sata->blksz) / sata->blksz;
+   blk_cnt   = ALIGN(size, sata->blksz) / sata->blksz;
+
+   n = blk_dread(sata, blk_start, blk_cnt, buffer);
+
+   return (n == blk_cnt) ? 0 : -1;
+}
+
+void env_relocate_spec(void)
+{
+#if !defined(ENV_IS_EMBEDDED)
+   ALLOC_CACHE_ALIGN_BUFFER(char, buf, CONFIG_ENV_SIZE);
+   struct blk_desc *sata = NULL;
+   int env_sata;
+
+

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

[Scott Wood]

On Wed, 2016-03-30 at 06:20 +, Qianyu Gong wrote:
> Hi Scott,
> 
> > -Original Message-
> > From: Scott Wood [mailto:o...@buserror.net]
> > Sent: Wednesday, March 30, 2016 4:45 AM
> > To: Qianyu Gong ; u-boot@lists.denx.de; york sun
> > 
> > Cc: Mingkai Hu 
> > Subject: Re: [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A with
> > QSPI
> > enabled
> > 
> > On Fri, 2016-03-11 at 10:18 +, Qianyu Gong wrote:
> > > Hi Scott,
> > > 
> > > > -Original Message-
> > > > From: Scott Wood [mailto:o...@buserror.net]
> > > > Sent: Tuesday, February 23, 2016 8:12 AM
> > > > To: Qianyu Gong ; u-boot@lists.denx.de; york
> > > > sun 
> > > > Cc: Mingkai Hu 
> > > > Subject: Re: [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A
> > > > with QSPI enabled
> > > > 
> > > > On Mon, 2016-02-22 at 18:05 +0800, Gong Qianyu wrote:
> > > > > QSPI and IFC are pin-multiplexed on LS1043A. So if QSPI is
> > > > > enabled, IFC should be disabled.
> > > > > But just disable IFC driver in LS1043A Linux is not enough because
> > > > > mdio-mux will access IFC address space -- actually it accesses
> > > > > FPGA which is connected to IFC CS3. So disable the whole IFC node
> > > > > in Linux device tree.
> > > > > 
> > > > > Signed-off-by: Gong Qianyu 
> > > > > 
> > > > > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > > > > b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > > > > index 4e4861d..5bb3048 100644
> > > > > --- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > > > > +++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > > > > @@ -204,4 +204,11 @@ void ft_cpu_setup(void *blob, bd_t *bd)
> > > > > #ifdef
> > > > > CONFIG_FSL_LSCH3
> > > > >   fdt_fixup_smmu(blob);
> > > > >  #endif
> > > > > +
> > > > > +#ifdef CONFIG_LS1043A
> > > > > +#ifdef CONFIG_FSL_QSPI
> > > > > + do_fixup_by_compat(blob, "fsl,ifc",
> > > > > +"status", "disabled", 8 + 1, 1); #endif
> > > > > #endif
> > > > >  }
> > > > 
> > > > This muxing is done at runtime, right?  It isn't a case of the board
> > > > hardwiring one or the other?  In that case, it should be handled at
> > > > runtime here as well.
> > > >   At a
> > > > minimum, allow the user to use hwconfig to choose which they want to
> > > > be accessible.  Ideally there would be something in the device tree
> > > > to list the reason(s) for a device being disabled, so the OS knows
> > > > it can regard the device as being enabled if it knows about and
> > > > enables them all.
> > > > 
> > > > -Scott
> > > 
> > > Sorry for the late reply. We have been asking the silicon team for the
> > > details of the pin muxing these days.
> > > The conclusion is that all IFC interfaces(cs0/cs1/cs2) are disabled as
> > > long as QSPI is enabled on LS1043AQDS board.
> > > As I know, this muxing won't be handled in kernel. Since IFC is
> > > disabled in U-Boot, IFC node would better be disabled in kernel as
> > > well.
> > > Also in such cases, users have no other choice.
> > 
> > Why should the user not have a choice to choose IFC over QSPI?  Where is
> > the
> > muxing configured?
> > 
> > -Scott
> 
> Because this muxing can't be changed at runtime.
> Two ways so far to configure it:
> 1. SW6[1-4] switches on ls1043aqds board.
> 2. Modify QIXIS board config registers and reset the board.

These sound like runtime to me -- not compile time.

-Scott

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

Re: [U-Boot] [PATCH] sf: params: Add support for n25q016a

[Moritz Fischer]

Hi Marek,

On Wed, Mar 30, 2016 at 5:34 PM, Marek Vasut  wrote:
> On 03/31/2016 12:23 AM, Moritz Fischer wrote:
>> This commits adds support for the N25Q016A, a 16Mbit
>> serial NOR flash from Micron.
>>
>> Signed-off-by: Moritz Fischer 
>> ---
>>  drivers/mtd/spi/sf_params.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
>> index 4f37e33..8ae4eea 100644
>> --- a/drivers/mtd/spi/sf_params.c
>> +++ b/drivers/mtd/spi/sf_params.c
>> @@ -83,6 +83,7 @@ const struct spi_flash_params spi_flash_params_table[] = {
>>   {"M25P64", 0x202017, 0x0,   64 * 1024,   128, RD_NORM, 
>>0},
>>   {"M25P128",0x202018, 0x0,  256 * 1024,64, RD_NORM, 
>>0},
>>   {"M25PX64",0x207117, 0x0,   64 * 1024,   128, RD_NORM, 
>>  SECT_4K},
>> + {"N25Q016A",   0x20bb15, 0x1000,64 * 1024,32, RD_NORM, 
>>  SECT_4K},
>
> According to [1], the device supports Quad I/O, so WR_QPP flag should be
> here in addition to SECT_4K .

Just finished testing your suggestion. Will resubmit v2. Thanks for the review.

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

Re: [U-Boot] [PATCH] sf: params: Add support for n25q016a

[Marek Vasut]

On 03/31/2016 12:23 AM, Moritz Fischer wrote:
> This commits adds support for the N25Q016A, a 16Mbit
> serial NOR flash from Micron.
> 
> Signed-off-by: Moritz Fischer 
> ---
>  drivers/mtd/spi/sf_params.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
> index 4f37e33..8ae4eea 100644
> --- a/drivers/mtd/spi/sf_params.c
> +++ b/drivers/mtd/spi/sf_params.c
> @@ -83,6 +83,7 @@ const struct spi_flash_params spi_flash_params_table[] = {
>   {"M25P64", 0x202017, 0x0,   64 * 1024,   128, RD_NORM,  
>   0},
>   {"M25P128",0x202018, 0x0,  256 * 1024,64, RD_NORM,  
>   0},
>   {"M25PX64",0x207117, 0x0,   64 * 1024,   128, RD_NORM,  
> SECT_4K},
> + {"N25Q016A",   0x20bb15, 0x1000,64 * 1024,32, RD_NORM,  
> SECT_4K},

According to [1], the device supports Quad I/O, so WR_QPP flag should be
here in addition to SECT_4K .

[1]
https://www.micron.com/~/media/documents/products/data-sheet/nor-flash/serial-nor/n25q/n25q_64mb_1_8v_65nm.pdf

>   {"N25Q32", 0x20ba16, 0x0,   64 * 1024,64, RD_FULL,  
>WR_QPP | SECT_4K},
>   {"N25Q32A",0x20bb16, 0x0,   64 * 1024,64, RD_FULL,  
>WR_QPP | SECT_4K},
>   {"N25Q64", 0x20ba17, 0x0,   64 * 1024,   128, RD_FULL,  
>WR_QPP | SECT_4K},
> 


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

[U-Boot] [PATCH 10/11] arm: lib: Import Thumb1 functions

[Marek Vasut]

Import functions into lib1funcs.S which are required for Thumb1
build. These functions come from gcc 5.3.1 release.

Signed-off-by: Marek Vasut 
Cc: Albert Aribaud 
Cc: Masahiro Yamada 
Cc: Simon Glass 
Cc: Tom Rini 
---
 arch/arm/lib/lib1funcs.S | 53 
 1 file changed, 53 insertions(+)

diff --git a/arch/arm/lib/lib1funcs.S b/arch/arm/lib/lib1funcs.S
index c343ea9..408839b 100644
--- a/arch/arm/lib/lib1funcs.S
+++ b/arch/arm/lib/lib1funcs.S
@@ -349,3 +349,56 @@ UNWIND(.save {lr})
ldr pc, [sp], #8
 UNWIND(.fnend)
 ENDPROC(Ldiv0)
+
+/* Thumb-1 specialities */
+#if defined(CONFIG_SYS_THUMB_BUILD) && !defined(CONFIG_HAS_THUMB2)
+ENTRY(__gnu_thumb1_case_sqi)
+   push{r1}
+   mov r1, lr
+   lsrsr1, r1, #1
+   lslsr1, r1, #1
+   ldrsb   r1, [r1, r0]
+   lslsr1, r1, #1
+   add lr, lr, r1
+   pop {r1}
+   bx  lr
+ENDPROC(__gnu_thumb1_case_sqi)
+
+ENTRY(__gnu_thumb1_case_uqi)
+   push{r1}
+   mov r1, lr
+   lsrsr1, r1, #1
+   lslsr1, r1, #1
+   ldrbr1, [r1, r0]
+   lslsr1, r1, #1
+   add lr, lr, r1
+   pop {r1}
+   bx  lr
+ENDPROC(__gnu_thumb1_case_uqi)
+
+ENTRY(__gnu_thumb1_case_shi)
+   push{r0, r1}
+   mov r1, lr
+   lsrsr1, r1, #1
+   lslsr0, r0, #1
+   lslsr1, r1, #1
+   ldrsh   r1, [r1, r0]
+   lslsr1, r1, #1
+   add lr, lr, r1
+   pop {r0, r1}
+   bx  lr
+ENDPROC(__gnu_thumb1_case_shi)
+
+ENTRY(__gnu_thumb1_case_uhi)
+   push{r0, r1}
+   mov r1, lr
+   lsrsr1, r1, #1
+   lslsr0, r0, #1
+   lslsr1, r1, #1
+   ldrhr1, [r1, r0]
+   lslsr1, r1, #1
+   add lr, lr, r1
+   pop {r0, r1}
+   bx  lr
+ENDPROC(__gnu_thumb1_case_uhi)
+#endif
-- 
2.7.0

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

[U-Boot] [PATCH 09/11] arm: lib: import muldi3.S from Linux

[Marek Vasut]

Import muldi3.S from Linux 4.4.6 , commit 
0d1912303e54ed1b2a371be0bba51c384dd57326
on arm32. This file implements __aeabi_lmul and it's alias __muldi3, which
is needed when doing Thumb1 builds.

This patch also defines CONFIG_THUMB2_KERNEL and CONFIG_ARM_ASM_UNIFIED
which is necessary for correct build of these files both in ARM and
Thumb mode, just like Linux does.

Signed-off-by: Marek Vasut 
Cc: Albert Aribaud 
Cc: Masahiro Yamada 
Cc: Simon Glass 
Cc: Tom Rini 
---
 arch/arm/lib/Makefile |  3 ++-
 arch/arm/lib/muldi3.S | 48 
 2 files changed, 50 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/lib/muldi3.S

diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index 8945915..86489fd 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -6,7 +6,8 @@
 #
 
 lib-$(CONFIG_USE_PRIVATE_LIBGCC) += ashldi3.o ashrdi3.o lshrdi3.o \
-   lib1funcs.o uldivmod.o div0.o div64.o
+   lib1funcs.o uldivmod.o div0.o \
+   div64.o muldi3.o
 
 ifdef CONFIG_CPU_V7M
 obj-y  += vectors_m.o crt0.o
diff --git a/arch/arm/lib/muldi3.S b/arch/arm/lib/muldi3.S
new file mode 100644
index 000..2043059
--- /dev/null
+++ b/arch/arm/lib/muldi3.S
@@ -0,0 +1,48 @@
+/*
+ *  linux/arch/arm/lib/muldi3.S
+ *
+ *  Author: Nicolas Pitre
+ *  Created:Oct 19, 2005
+ *  Copyright:  Monta Vista Software, Inc.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+
+#ifdef __ARMEB__
+#define xh r0
+#define xl r1
+#define yh r2
+#define yl r3
+#else
+#define xl r0
+#define xh r1
+#define yl r2
+#define yh r3
+#endif
+
+ENTRY(__muldi3)
+ENTRY(__aeabi_lmul)
+
+   mul xh, yl, xh
+   mla xh, xl, yh, xh
+   mov ip, xl, lsr #16
+   mov yh, yl, lsr #16
+   bic xl, xl, ip, lsl #16
+   bic yl, yl, yh, lsl #16
+   mla xh, yh, ip, xh
+   mul yh, xl, yh
+   mul xl, yl, xl
+   mul ip, yl, ip
+   addsxl, xl, yh, lsl #16
+   adc xh, xh, yh, lsr #16
+   addsxl, xl, ip, lsl #16
+   adc xh, xh, ip, lsr #16
+   ret lr
+
+ENDPROC(__muldi3)
+ENDPROC(__aeabi_lmul)
-- 
2.7.0

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

[U-Boot] [PATCH 07/11] arm: lib: Import __do_div64 from Linux

[Marek Vasut]

Import __do_div64 from Linux 4.4.6 , commit 
0d1912303e54ed1b2a371be0bba51c384dd57326
on arm32. This function is for some toolchains, which generate _udivmoddi4()
for 64 bit division.

Since we do not support stack unwinding, instead of importing the whole
asm/unwind.h and all the baggage, this patch defines empty UNWIND() macro.

This patch also defines CONFIG_THUMB2_KERNEL and CONFIG_ARM_ASM_UNIFIED
which is necessary for correct build of these files both in ARM and
Thumb mode, just like Linux does.

Signed-off-by: Marek Vasut 
Cc: Albert Aribaud 
Cc: Masahiro Yamada 
Cc: Simon Glass 
Cc: Tom Rini 
---
 arch/arm/lib/Makefile |   2 +-
 arch/arm/lib/div64.S  | 214 ++
 2 files changed, 215 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/lib/div64.S

diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index 0b0dbcb..8945915 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -6,7 +6,7 @@
 #
 
 lib-$(CONFIG_USE_PRIVATE_LIBGCC) += ashldi3.o ashrdi3.o lshrdi3.o \
-   lib1funcs.o uldivmod.o div0.o
+   lib1funcs.o uldivmod.o div0.o div64.o
 
 ifdef CONFIG_CPU_V7M
 obj-y  += vectors_m.o crt0.o
diff --git a/arch/arm/lib/div64.S b/arch/arm/lib/div64.S
new file mode 100644
index 000..f238bc6
--- /dev/null
+++ b/arch/arm/lib/div64.S
@@ -0,0 +1,214 @@
+/*
+ *  linux/arch/arm/lib/div64.S
+ *
+ *  Optimized computation of 64-bit dividend / 32-bit divisor
+ *
+ *  Author:Nicolas Pitre
+ *  Created:   Oct 5, 2003
+ *  Copyright: Monta Vista Software, Inc.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#ifdef __UBOOT__
+#define UNWIND(x...)
+#endif
+
+#ifdef __ARMEB__
+#define xh r0
+#define xl r1
+#define yh r2
+#define yl r3
+#else
+#define xl r0
+#define xh r1
+#define yl r2
+#define yh r3
+#endif
+
+/*
+ * __do_div64: perform a division with 64-bit dividend and 32-bit divisor.
+ *
+ * Note: Calling convention is totally non standard for optimal code.
+ *   This is meant to be used by do_div() from include/asm/div64.h only.
+ *
+ * Input parameters:
+ * xh-xl   = dividend (clobbered)
+ * r4  = divisor (preserved)
+ *
+ * Output values:
+ * yh-yl   = result
+ * xh  = remainder
+ *
+ * Clobbered regs: xl, ip
+ */
+
+ENTRY(__do_div64)
+UNWIND(.fnstart)
+
+   @ Test for easy paths first.
+   subsip, r4, #1
+   bls 9f  @ divisor is 0 or 1
+   tst ip, r4
+   beq 8f  @ divisor is power of 2
+
+   @ See if we need to handle upper 32-bit result.
+   cmp xh, r4
+   mov yh, #0
+   blo 3f
+
+   @ Align divisor with upper part of dividend.
+   @ The aligned divisor is stored in yl preserving the original.
+   @ The bit position is stored in ip.
+
+#if __LINUX_ARM_ARCH__ >= 5
+
+   clz yl, r4
+   clz ip, xh
+   sub yl, yl, ip
+   mov ip, #1
+   mov ip, ip, lsl yl
+   mov yl, r4, lsl yl
+
+#else
+
+   mov yl, r4
+   mov ip, #1
+1: cmp yl, #0x8000
+   cmpcc   yl, xh
+   movcc   yl, yl, lsl #1
+   movcc   ip, ip, lsl #1
+   bcc 1b
+
+#endif
+
+   @ The division loop for needed upper bit positions.
+   @ Break out early if dividend reaches 0.
+2: cmp xh, yl
+   orrcs   yh, yh, ip
+   subcss  xh, xh, yl
+   movnes  ip, ip, lsr #1
+   mov yl, yl, lsr #1
+   bne 2b
+
+   @ See if we need to handle lower 32-bit result.
+3: cmp xh, #0
+   mov yl, #0
+   cmpeq   xl, r4
+   movlo   xh, xl
+   retlo   lr
+
+   @ The division loop for lower bit positions.
+   @ Here we shift remainer bits leftwards rather than moving the
+   @ divisor for comparisons, considering the carry-out bit as well.
+   mov ip, #0x8000
+4: movsxl, xl, lsl #1
+   adcsxh, xh, xh
+   beq 6f
+   cmpcc   xh, r4
+5: orrcs   yl, yl, ip
+   subcs   xh, xh, r4
+   movsip, ip, lsr #1
+   bne 4b
+   ret lr
+
+   @ The top part of remainder became zero.  If carry is set
+   @ (the 33th bit) this is a false positive so resume the loop.
+   @ Otherwise, if lower part is also null then we are done.
+6: bcs 5b
+   cmp xl, #0
+   reteq   lr
+
+   @ We still have remainer bits in the low part.  Bring them up.
+
+#if __LINUX_ARM_ARCH__ >= 5
+
+   clz xh, xl  @ we know xh is zero here so...
+   add xh, xh, #1
+   mov xl, xl, lsl xh
+   mov ip, ip, lsr xh
+
+#else
+
+7: movs

[U-Boot] [PATCH 05/11] arm: lib: Sync libgcc 32b division/modulo operations

[Marek Vasut]

Sync the libgcc 32bit division and modulo operations with Linux 4.4.6 ,
commit 0d1912303e54ed1b2a371be0bba51c384dd57326 . The functions in these
four files are present in lib1funcs.S in Linux, so replace these files
with lib1funcs.S from Linux.

Since we do not support stack unwinding, instead of importing the whole
asm/unwind.h and all the baggage, this patch defines empty UNWIND() macro
in lib1funcs.S . Moreover, to make all of the functions available, define
CONFIG_AEABI , which is safe, because U-Boot is always compiled with ARM
EABI.

This patch also defines CONFIG_THUMB2_KERNEL and CONFIG_ARM_ASM_UNIFIED
which is necessary for correct build of these files both in ARM and
Thumb mode, just like Linux does.

Signed-off-by: Marek Vasut 
Cc: Albert Aribaud 
Cc: Masahiro Yamada 
Cc: Simon Glass 
Cc: Tom Rini 
---
 arch/arm/lib/Makefile|   5 +-
 arch/arm/lib/divsi3.S| 143 ---
 arch/arm/lib/lib1funcs.S | 351 +++
 arch/arm/lib/modsi3.S|  99 -
 arch/arm/lib/udivsi3.S   |  95 -
 arch/arm/lib/umodsi3.S   |  90 
 6 files changed, 353 insertions(+), 430 deletions(-)
 delete mode 100644 arch/arm/lib/divsi3.S
 create mode 100644 arch/arm/lib/lib1funcs.S
 delete mode 100644 arch/arm/lib/modsi3.S
 delete mode 100644 arch/arm/lib/udivsi3.S
 delete mode 100644 arch/arm/lib/umodsi3.S

diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index cafd94d..0b0dbcb 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -5,9 +5,8 @@
 # SPDX-License-Identifier: GPL-2.0+
 #
 
-lib-$(CONFIG_USE_PRIVATE_LIBGCC) += ashldi3.o ashrdi3.o divsi3.o \
-   lshrdi3.o modsi3.o udivsi3.o umodsi3.o div0.o \
-   uldivmod.o
+lib-$(CONFIG_USE_PRIVATE_LIBGCC) += ashldi3.o ashrdi3.o lshrdi3.o \
+   lib1funcs.o uldivmod.o div0.o
 
 ifdef CONFIG_CPU_V7M
 obj-y  += vectors_m.o crt0.o
diff --git a/arch/arm/lib/divsi3.S b/arch/arm/lib/divsi3.S
deleted file mode 100644
index c463c68..000
--- a/arch/arm/lib/divsi3.S
+++ /dev/null
@@ -1,143 +0,0 @@
-#include 
-
-.macro ARM_DIV_BODY dividend, divisor, result, curbit
-
-#if __LINUX_ARM_ARCH__ >= 5
-
-   clz \curbit, \divisor
-   clz \result, \dividend
-   sub \result, \curbit, \result
-   mov \curbit, #1
-   mov \divisor, \divisor, lsl \result
-   mov \curbit, \curbit, lsl \result
-   mov \result, #0
-
-#else
-
-   @ Initially shift the divisor left 3 bits if possible,
-   @ set curbit accordingly.  This allows for curbit to be located
-   @ at the left end of each 4 bit nibbles in the division loop
-   @ to save one loop in most cases.
-   tst \divisor, #0xe000
-   moveq   \divisor, \divisor, lsl #3
-   moveq   \curbit, #8
-   movne   \curbit, #1
-
-   @ Unless the divisor is very big, shift it up in multiples of
-   @ four bits, since this is the amount of unwinding in the main
-   @ division loop.  Continue shifting until the divisor is
-   @ larger than the dividend.
-1: cmp \divisor, #0x1000
-   cmplo   \divisor, \dividend
-   movlo   \divisor, \divisor, lsl #4
-   movlo   \curbit, \curbit, lsl #4
-   blo 1b
-
-   @ For very big divisors, we must shift it a bit at a time, or
-   @ we will be in danger of overflowing.
-1: cmp \divisor, #0x8000
-   cmplo   \divisor, \dividend
-   movlo   \divisor, \divisor, lsl #1
-   movlo   \curbit, \curbit, lsl #1
-   blo 1b
-
-   mov \result, #0
-
-#endif
-
-   @ Division loop
-1: cmp \dividend, \divisor
-   subhs   \dividend, \dividend, \divisor
-   orrhs   \result,   \result,   \curbit
-   cmp \dividend, \divisor,  lsr #1
-   subhs   \dividend, \dividend, \divisor, lsr #1
-   orrhs   \result,   \result,   \curbit,  lsr #1
-   cmp \dividend, \divisor,  lsr #2
-   subhs   \dividend, \dividend, \divisor, lsr #2
-   orrhs   \result,   \result,   \curbit,  lsr #2
-   cmp \dividend, \divisor,  lsr #3
-   subhs   \dividend, \dividend, \divisor, lsr #3
-   orrhs   \result,   \result,   \curbit,  lsr #3
-   cmp \dividend, #0   @ Early termination?
-   movnes  \curbit,   \curbit,  lsr #4 @ No, any more bits to do?
-   movne   \divisor,  \divisor, lsr #4
-   bne 1b
-
-.endm
-
-.macro ARM_DIV2_ORDER divisor, order
-
-#if __LINUX_ARM_ARCH__ >= 5
-
-   clz \order, \divisor
-   rsb \order, \order, #31
-
-#else
-
-   cmp \divisor, #(1 << 16)
-   movhs   \divisor, \divisor, lsr #16
-   movhs   \order, #16
-   movlo   \order, #0
-
-   cmp \divisor, #(1 << 8)
-   movhs   \divisor, \divisor, lsr #8
-   addhs   \order, 

[U-Boot] [PATCH 08/11] arm: lib: Repair Warning: conditional infixes are deprecated in unified syntax

[Marek Vasut]

Fix the following warning when building for thumb2 target by tweaking the
instruction syntax:

Warning: conditional infixes are deprecated in unified syntax

Signed-off-by: Marek Vasut 
Cc: Albert Aribaud 
Cc: Masahiro Yamada 
Cc: Simon Glass 
Cc: Tom Rini 
---
 arch/arm/lib/div64.S | 4 ++--
 arch/arm/lib/lib1funcs.S | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/lib/div64.S b/arch/arm/lib/div64.S
index f238bc6..7956051 100644
--- a/arch/arm/lib/div64.S
+++ b/arch/arm/lib/div64.S
@@ -90,8 +90,8 @@ UNWIND(.fnstart)
@ Break out early if dividend reaches 0.
 2: cmp xh, yl
orrcs   yh, yh, ip
-   subcss  xh, xh, yl
-   movnes  ip, ip, lsr #1
+   subscs  xh, xh, yl
+   movsne  ip, ip, lsr #1
mov yl, yl, lsr #1
bne 2b
 
diff --git a/arch/arm/lib/lib1funcs.S b/arch/arm/lib/lib1funcs.S
index 5871dbe..c343ea9 100644
--- a/arch/arm/lib/lib1funcs.S
+++ b/arch/arm/lib/lib1funcs.S
@@ -84,7 +84,7 @@
subhs   \dividend, \dividend, \divisor, lsr #3
orrhs   \result,   \result,   \curbit,  lsr #3
cmp \dividend, #0   @ Early termination?
-   movnes  \curbit,   \curbit,  lsr #4 @ No, any more bits to do?
+   movsne  \curbit,   \curbit,  lsr #4 @ No, any more bits to do?
movne   \divisor,  \divisor, lsr #4
bne 1b
 
@@ -170,7 +170,7 @@
subhs   \dividend, \dividend, \divisor, lsr #3
cmp \dividend, #1
mov \divisor, \divisor, lsr #4
-   subges  \order, \order, #4
+   subsge  \order, \order, #4
bge 1b
 
tst \order, #3
-- 
2.7.0

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

[U-Boot] [PATCH 01/11] arm: config: Introduce CONFIG_SYS_ARM_ARCH

[Marek Vasut]

Introduce new helper Kconfig option, which is automatically set to
the version of ARM architecture for which the U-Boot is built. This
is useful when selecting tuning options in the libgcc imported from
Linux kernel.

Signed-off-by: Marek Vasut 
Cc: Albert Aribaud 
Cc: Masahiro Yamada 
Cc: Simon Glass 
Cc: Tom Rini 
---
 arch/arm/Kconfig | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 9851065..abbe33e 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -64,6 +64,20 @@ config SYS_CPU
 default "sa1100" if CPU_SA1100
default "armv8" if ARM64
 
+config SYS_ARM_ARCH
+   int
+   default 4 if CPU_ARM720T
+   default 4 if CPU_ARM920T
+   default 5 if CPU_ARM926EJS
+   default 5 if CPU_ARM946ES
+   default 6 if CPU_ARM1136
+   default 6 if CPU_ARM1176
+   default 7 if CPU_V7
+   default 7 if CPU_V7M
+   default 5 if CPU_PXA
+   default 4 if CPU_SA1100
+   default 8 if ARM64
+
 config SEMIHOSTING
bool "support boot from semihosting"
help
-- 
2.7.0

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

[U-Boot] [PATCH 03/11] arm: lib: Drop underscore from private libgcc filenames

[Marek Vasut]

Drop the underscore from the filenames of files implementing libgcc
routines. There is no functional change. This change is done to make
sync with Linux kernel easier.

Signed-off-by: Marek Vasut 
Cc: Albert Aribaud 
Cc: Masahiro Yamada 
Cc: Simon Glass 
Cc: Tom Rini 
---
 arch/arm/lib/Makefile| 6 +++---
 arch/arm/lib/{_ashldi3.S => ashldi3.S}   | 0
 arch/arm/lib/{_ashrdi3.S => ashrdi3.S}   | 0
 arch/arm/lib/{_divsi3.S => divsi3.S} | 0
 arch/arm/lib/{_lshrdi3.S => lshrdi3.S}   | 0
 arch/arm/lib/{_modsi3.S => modsi3.S} | 0
 arch/arm/lib/{_udivsi3.S => udivsi3.S}   | 0
 arch/arm/lib/{_uldivmod.S => uldivmod.S} | 0
 arch/arm/lib/{_umodsi3.S => umodsi3.S}   | 0
 9 files changed, 3 insertions(+), 3 deletions(-)
 rename arch/arm/lib/{_ashldi3.S => ashldi3.S} (100%)
 rename arch/arm/lib/{_ashrdi3.S => ashrdi3.S} (100%)
 rename arch/arm/lib/{_divsi3.S => divsi3.S} (100%)
 rename arch/arm/lib/{_lshrdi3.S => lshrdi3.S} (100%)
 rename arch/arm/lib/{_modsi3.S => modsi3.S} (100%)
 rename arch/arm/lib/{_udivsi3.S => udivsi3.S} (100%)
 rename arch/arm/lib/{_uldivmod.S => uldivmod.S} (100%)
 rename arch/arm/lib/{_umodsi3.S => umodsi3.S} (100%)

diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index 1112b9e..cafd94d 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -5,9 +5,9 @@
 # SPDX-License-Identifier: GPL-2.0+
 #
 
-lib-$(CONFIG_USE_PRIVATE_LIBGCC) += _ashldi3.o _ashrdi3.o _divsi3.o \
-   _lshrdi3.o _modsi3.o _udivsi3.o _umodsi3.o div0.o \
-   _uldivmod.o
+lib-$(CONFIG_USE_PRIVATE_LIBGCC) += ashldi3.o ashrdi3.o divsi3.o \
+   lshrdi3.o modsi3.o udivsi3.o umodsi3.o div0.o \
+   uldivmod.o
 
 ifdef CONFIG_CPU_V7M
 obj-y  += vectors_m.o crt0.o
diff --git a/arch/arm/lib/_ashldi3.S b/arch/arm/lib/ashldi3.S
similarity index 100%
rename from arch/arm/lib/_ashldi3.S
rename to arch/arm/lib/ashldi3.S
diff --git a/arch/arm/lib/_ashrdi3.S b/arch/arm/lib/ashrdi3.S
similarity index 100%
rename from arch/arm/lib/_ashrdi3.S
rename to arch/arm/lib/ashrdi3.S
diff --git a/arch/arm/lib/_divsi3.S b/arch/arm/lib/divsi3.S
similarity index 100%
rename from arch/arm/lib/_divsi3.S
rename to arch/arm/lib/divsi3.S
diff --git a/arch/arm/lib/_lshrdi3.S b/arch/arm/lib/lshrdi3.S
similarity index 100%
rename from arch/arm/lib/_lshrdi3.S
rename to arch/arm/lib/lshrdi3.S
diff --git a/arch/arm/lib/_modsi3.S b/arch/arm/lib/modsi3.S
similarity index 100%
rename from arch/arm/lib/_modsi3.S
rename to arch/arm/lib/modsi3.S
diff --git a/arch/arm/lib/_udivsi3.S b/arch/arm/lib/udivsi3.S
similarity index 100%
rename from arch/arm/lib/_udivsi3.S
rename to arch/arm/lib/udivsi3.S
diff --git a/arch/arm/lib/_uldivmod.S b/arch/arm/lib/uldivmod.S
similarity index 100%
rename from arch/arm/lib/_uldivmod.S
rename to arch/arm/lib/uldivmod.S
diff --git a/arch/arm/lib/_umodsi3.S b/arch/arm/lib/umodsi3.S
similarity index 100%
rename from arch/arm/lib/_umodsi3.S
rename to arch/arm/lib/umodsi3.S
-- 
2.7.0

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

[U-Boot] [PATCH 02/11] arm: include: Import unified.h from Linux kernel

[Marek Vasut]

Import unified.h from Linux kernel 4.4.6 , commit
0d1912303e54ed1b2a371be0bba51c384dd57326 . This header file contains
macros used in libgcc functions in Linux kernel on ARM and will be
needed for the libgcc sync.

Since unified.h defines the W(instr) macro, we must drop this from
the macro from memcpy.S , otherwise this triggers a warning about
symbol redefinition. In order to keep the changes to unified.h to
the minimum, tweak arch/arm/lib/Makefile such that it defines the
CONFIG_ARM_ASM_UNIFIED macro, which places .syntax unified into all
of the assembler files. This is mandatory.

Moreover, for Thumb2 build, define CONFIG_THUMB2_KERNEL macro if and
only if Thumb2 build is enabled. This macro is checked by unified.h
and toggles between ARM and Thumb2 variant of the instructions in the
assembler source files.

Finally, this patch defines __LINUX_ARM_ARCH__=N macro based on the
new CONFIG_SYS_ARM_ARCH Kconfig option. This macro selects between
more optimal and more dense codepaths which work on armv5 and newer
and less optimal codepaths which work on armv4 and possible armv3m.
Tegra2 needs the same special handling as it does in arch/arm/Makefile
to cater for the arm720t boot core.

Signed-off-by: Marek Vasut 
Cc: Albert Aribaud 
Cc: Masahiro Yamada 
Cc: Simon Glass 
Cc: Tom Rini 
---
 arch/arm/include/asm/assembler.h |   1 +
 arch/arm/include/asm/unified.h   | 140 +++
 arch/arm/lib/Makefile|   9 ++-
 arch/arm/lib/memcpy.S|   6 --
 4 files changed, 149 insertions(+), 7 deletions(-)
 create mode 100644 arch/arm/include/asm/unified.h

diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
index 11b80fb..ae1e42f 100644
--- a/arch/arm/include/asm/assembler.h
+++ b/arch/arm/include/asm/assembler.h
@@ -15,6 +15,7 @@
  */
 
 #include 
+#include 
 
 /*
  * Endian independent macros for shifting bytes within registers.
diff --git a/arch/arm/include/asm/unified.h b/arch/arm/include/asm/unified.h
new file mode 100644
index 000..a91ae49
--- /dev/null
+++ b/arch/arm/include/asm/unified.h
@@ -0,0 +1,140 @@
+/*
+ * include/asm-arm/unified.h - Unified Assembler Syntax helper macros
+ *
+ * Copyright (C) 2008 ARM Limited
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#ifndef __ASM_UNIFIED_H
+#define __ASM_UNIFIED_H
+
+#if defined(__ASSEMBLY__) && defined(CONFIG_ARM_ASM_UNIFIED)
+   .syntax unified
+#endif
+
+#ifdef CONFIG_CPU_V7M
+#define AR_CLASS(x...)
+#define M_CLASS(x...)  x
+#else
+#define AR_CLASS(x...) x
+#define M_CLASS(x...)
+#endif
+
+#ifdef CONFIG_THUMB2_KERNEL
+
+#if __GNUC__ < 4
+#error Thumb-2 kernel requires gcc >= 4
+#endif
+
+/* The CPSR bit describing the instruction set (Thumb) */
+#define PSR_ISETSTATE  PSR_T_BIT
+
+#define ARM(x...)
+#define THUMB(x...)x
+#ifdef __ASSEMBLY__
+#define W(instr)   instr.w
+#else
+#define WASM(instr)#instr ".w"
+#endif
+
+#else  /* !CONFIG_THUMB2_KERNEL */
+
+/* The CPSR bit describing the instruction set (ARM) */
+#define PSR_ISETSTATE  0
+
+#define ARM(x...)  x
+#define THUMB(x...)
+#ifdef __ASSEMBLY__
+#define W(instr)   instr
+#else
+#define WASM(instr)#instr
+#endif
+
+#endif /* CONFIG_THUMB2_KERNEL */
+
+#ifndef CONFIG_ARM_ASM_UNIFIED
+
+/*
+ * If the unified assembly syntax isn't used (in ARM mode), these
+ * macros expand to an empty string
+ */
+#ifdef __ASSEMBLY__
+   .macro  it, cond
+   .endm
+   .macro  itt, cond
+   .endm
+   .macro  ite, cond
+   .endm
+   .macro  ittt, cond
+   .endm
+   .macro  itte, cond
+   .endm
+   .macro  itet, cond
+   .endm
+   .macro  itee, cond
+   .endm
+   .macro  i, cond
+   .endm
+   .macro  ittte, cond
+   .endm
+   .macro  ittet, cond
+   .endm
+   .macro  ittee, cond
+   .endm
+   .macro  itett, cond
+   .endm
+   .macro  itete, cond
+   .endm
+   .macro  iteet, cond
+   .endm
+   .macro  iteee, cond
+   .endm
+#else  /* !__ASSEMBLY__ */
+__asm__(
+"  .macro  it, cond\n"
+"  .endm\n"
+"  .macro  itt, cond\n"
+"  .endm\n"
+"  .macro  ite, cond\n"
+"  .endm\n"
+"  .macro  ittt, cond\n"
+"  .endm\n"
+"  .macro  itte, cond\n"
+" 

[U-Boot] [PATCH 04/11] arm: lib: Sync libgcc shift operations

[Marek Vasut]

Sync the libgcc shift operations with Linux kernel 4.4.6 , commit
0d1912303e54ed1b2a371be0bba51c384dd57326 . Syncing these three
files is easy, as there is almost no change in them, except the
addition of Thumb support.

This patch also defines CONFIG_THUMB2_KERNEL and CONFIG_ARM_ASM_UNIFIED
which is necessary for correct build of these files both in ARM and
Thumb mode, just like Linux does.

Signed-off-by: Marek Vasut 
Cc: Albert Aribaud 
Cc: Masahiro Yamada 
Cc: Simon Glass 
Cc: Tom Rini 
---
 arch/arm/lib/ashldi3.S | 12 
 arch/arm/lib/ashrdi3.S | 12 
 arch/arm/lib/lshrdi3.S | 12 
 3 files changed, 24 insertions(+), 12 deletions(-)

diff --git a/arch/arm/lib/ashldi3.S b/arch/arm/lib/ashldi3.S
index 9c34c21..a4f5ebb 100644
--- a/arch/arm/lib/ashldi3.S
+++ b/arch/arm/lib/ashldi3.S
@@ -5,6 +5,7 @@
  */
 
 #include 
+#include 
 
 #ifdef __ARMEB__
 #define al r1
@@ -14,15 +15,18 @@
 #define ah r1
 #endif
 
-.globl __ashldi3
-__ashldi3:
+ENTRY(__ashldi3)
 ENTRY(__aeabi_llsl)
 
subsr3, r2, #32
rsb ip, r2, #32
movmi   ah, ah, lsl r2
movpl   ah, al, lsl r3
-   orrmi   ah, ah, al, lsr ip
+ ARM(  orrmi   ah, ah, al, lsr ip  )
+ THUMB(lsrmi   r3, al, ip  )
+ THUMB(orrmi   ah, ah, r3  )
mov al, al, lsl r2
-   mov pc, lr
+   ret lr
+
+ENDPROC(__ashldi3)
 ENDPROC(__aeabi_llsl)
diff --git a/arch/arm/lib/ashrdi3.S b/arch/arm/lib/ashrdi3.S
index c74fd64..c6e1ed3 100644
--- a/arch/arm/lib/ashrdi3.S
+++ b/arch/arm/lib/ashrdi3.S
@@ -5,6 +5,7 @@
  */
 
 #include 
+#include 
 
 #ifdef __ARMEB__
 #define al r1
@@ -14,15 +15,18 @@
 #define ah r1
 #endif
 
-.globl __ashrdi3
-__ashrdi3:
+ENTRY(__ashrdi3)
 ENTRY(__aeabi_lasr)
 
subsr3, r2, #32
rsb ip, r2, #32
movmi   al, al, lsr r2
movpl   al, ah, asr r3
-   orrmi   al, al, ah, lsl ip
+ ARM(  orrmi   al, al, ah, lsl ip  )
+ THUMB(lslmi   r3, ah, ip  )
+ THUMB(orrmi   al, al, r3  )
mov ah, ah, asr r2
-   mov pc, lr
+   ret lr
+
+ENDPROC(__ashrdi3)
 ENDPROC(__aeabi_lasr)
diff --git a/arch/arm/lib/lshrdi3.S b/arch/arm/lib/lshrdi3.S
index 1f9b916..9c51141 100644
--- a/arch/arm/lib/lshrdi3.S
+++ b/arch/arm/lib/lshrdi3.S
@@ -5,6 +5,7 @@
  */
 
 #include 
+#include 
 
 #ifdef __ARMEB__
 #define al r1
@@ -14,15 +15,18 @@
 #define ah r1
 #endif
 
-.globl __lshrdi3
-__lshrdi3:
+ENTRY(__lshrdi3)
 ENTRY(__aeabi_llsr)
 
subsr3, r2, #32
rsb ip, r2, #32
movmi   al, al, lsr r2
movpl   al, ah, lsr r3
-   orrmi   al, al, ah, lsl ip
+ ARM(  orrmi   al, al, ah, lsl ip  )
+ THUMB(lslmi   r3, ah, ip  )
+ THUMB(orrmi   al, al, r3  )
mov ah, ah, lsr r2
-   mov pc, lr
+   ret lr
+
+ENDPROC(__lshrdi3)
 ENDPROC(__aeabi_llsr)
-- 
2.7.0

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

[U-Boot] [PATCH 06/11] arm: lib: Fix uldivmod.S build on Thumb2

[Marek Vasut]

This assembler source won't build in Thumb2 mode, so fix it adding
the necessary Thumb2 conditional macros from unified.h .

This patch also defines CONFIG_THUMB2_KERNEL and CONFIG_ARM_ASM_UNIFIED
which is necessary for correct build of these files both in ARM and
Thumb mode, just like Linux does.

Signed-off-by: Marek Vasut 
Cc: Albert Aribaud 
Cc: Masahiro Yamada 
Cc: Simon Glass 
Cc: Tom Rini 
---
 arch/arm/lib/uldivmod.S | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/arch/arm/lib/uldivmod.S b/arch/arm/lib/uldivmod.S
index 426c2f2..2efcd73 100644
--- a/arch/arm/lib/uldivmod.S
+++ b/arch/arm/lib/uldivmod.S
@@ -9,10 +9,6 @@
 #include 
 #include 
 
-/* We don't use Thumb instructions for now */
-#define ARM(x...)  x
-#define THUMB(x...)
-
 /*
  * A, Q = r0 + (r1 << 32)
  * B, R = r2 + (r3 << 32)
@@ -226,7 +222,9 @@ THUMB(  orrpl   A_0, A_0, TMP   )
@ Shift A to the right by the appropriate amount.
rsb D_1, D_0, #32
mov Q_0, A_0, lsr D_0
-   orr Q_0, A_1, lsl D_1
+ ARM(   orr Q_0, Q_0, A_1, lsl D_1 )
+ THUMB(lsl A_1, D_1)
+ THUMB(orr Q_0, A_1)
mov Q_1, A_1, lsr D_0
@ Move C to R
mov R_0, C_0
-- 
2.7.0

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

[U-Boot] [PATCH 11/11] lib: Enable private libgcc by default

[Marek Vasut]

This patch decouples U-Boot binary from the toolchain on systems where
private libgcc is available. Instead of pulling in functions provided
by the libgcc from the toolchain, U-Boot will use it's own set of libgcc
functions. These functions are usually imported from Linux kernel, which
also uses it's own libgcc functions instead of the ones provided by the
toolchain.

This patch solves a rather common problem. The toolchain can usually
generate code for many variants of target architecture and often even
different endianness. The libgcc on the other hand is usually compiled
for one particular configuration and the functions provided by it may
or may not be suited for use in U-Boot. This can manifest in two ways,
either the U-Boot fails to compile altogether and linker will complain
or, in the much worse case, the resulting U-Boot will build, but will
misbehave in very subtle and hard to debug ways.

Signed-off-by: Marek Vasut 
Cc: Albert Aribaud 
Cc: Masahiro Yamada 
Cc: Simon Glass 
Cc: Tom Rini 
---
 lib/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/Kconfig b/lib/Kconfig
index 7a45336..2b911bc 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -14,6 +14,7 @@ config HAVE_PRIVATE_LIBGCC
 config USE_PRIVATE_LIBGCC
bool "Use private libgcc"
depends on HAVE_PRIVATE_LIBGCC
+   default y if HAVE_PRIVATE_LIBGCC
help
  This option allows you to use the built-in libgcc implementation
  of U-Boot instead of the one privided by the compiler.
-- 
2.7.0

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

[U-Boot] Tegra-specific header file location

[Stephen Warren]

Masahiro,

I'm about to work on some refactoring of the Tegra-specific header files 
in U-Boot to enable support for another Tegra variant. I'd like to 
confirm where you think header files should be located before doing that.


I believe you want Tegra-specific headers moved into 
arch/arm/mach-tegra/include. That would probably be a good location for 
headers currently in arch/arm/include/asm/arch-tegra/. Does that sound 
correct to you?


What about SoC-specific headers currently in 
arch/arm/include/asm/arch-tegraNNN/; should they move to 
arch/arm/mach-tegra/tegraNNN/include?


A number of those header files primarily contain driver-internal 
definitions such as HW register layouts. I'd like to propose moving this 
private information into the relevant drivers/ directories where the 
driver implementation already is. There is no need to place it in an 
include directory where any C file could include it. For example, 99% of 
arch/arm/include/asm/arch-tegra/tegra_mmc.h might move to 
drivers/mmc/tegra_mmc_{priv,internal}.h or even into 
drivers/mmc/tegra_mmc.c itself. The only thing that wouldn't move is the 
public prototype for pad_init_mmc(); a function the MMC driver calls and 
board code is expected to implement. I am considering making a single 
header that defines all those Tegra-specific function prototypes so we 
can reduce the number of header files too. What do you think about this.

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

[U-Boot] [PATCH] sf: params: Add support for n25q016a

[Moritz Fischer]

This commits adds support for the N25Q016A, a 16Mbit
serial NOR flash from Micron.

Signed-off-by: Moritz Fischer 
---
 drivers/mtd/spi/sf_params.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
index 4f37e33..8ae4eea 100644
--- a/drivers/mtd/spi/sf_params.c
+++ b/drivers/mtd/spi/sf_params.c
@@ -83,6 +83,7 @@ const struct spi_flash_params spi_flash_params_table[] = {
{"M25P64", 0x202017, 0x0,   64 * 1024,   128, RD_NORM,  
  0},
{"M25P128",0x202018, 0x0,  256 * 1024,64, RD_NORM,  
  0},
{"M25PX64",0x207117, 0x0,   64 * 1024,   128, RD_NORM,  
SECT_4K},
+   {"N25Q016A",   0x20bb15, 0x1000,64 * 1024,32, RD_NORM,  
SECT_4K},
{"N25Q32", 0x20ba16, 0x0,   64 * 1024,64, RD_FULL,  
   WR_QPP | SECT_4K},
{"N25Q32A",0x20bb16, 0x0,   64 * 1024,64, RD_FULL,  
   WR_QPP | SECT_4K},
{"N25Q64", 0x20ba17, 0x0,   64 * 1024,   128, RD_FULL,  
   WR_QPP | SECT_4K},
-- 
2.5.5

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

Re: [U-Boot] [PATCH 5/5] meson: odroid-c2: enable serial

[Beniamino Galvani]

On Tue, Mar 29, 2016 at 06:06:42PM -0400, Tom Rini wrote:
> ... and do a 'make savedefconfig' and copy the defconfig file to
> configs/odroid-c2_defconfig next time :)

Good to know, thanks!

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

Re: [U-Boot] [PATCH 5/5] meson: odroid-c2: enable serial

[Beniamino Galvani]

On Mon, Mar 28, 2016 at 10:58:34AM +0200, Carlo Caione wrote:
> On Sun, Mar 27, 2016 at 10:22 PM, Beniamino Galvani  
> wrote:
> > Enable serial support in the ODROID-C2 configuration.
> >
> > Signed-off-by: Beniamino Galvani 
> > ---
> >  configs/odroid-c2_defconfig | 5 +
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/configs/odroid-c2_defconfig b/configs/odroid-c2_defconfig
> > index 66d9ab7..e0cd403 100644
> > --- a/configs/odroid-c2_defconfig
> > +++ b/configs/odroid-c2_defconfig
> > @@ -4,6 +4,11 @@ CONFIG_MESON_GXBB=y
> >  CONFIG_TARGET_ODROID_C2=y
> >  CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-odroidc2"
> >  CONFIG_OF_CONTROL=y
> > +CONFIG_MESON_SERIAL=y
> > +CONFIG_DEBUG_UART_MESON=y
> > +GONFIG_DEBUG_UART_BASE=0xc81004c0
> 
> s/GONFIG/CONFIG/

Yeah, I guess it's because C and G are next to each other on the
keyboard :)

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

Re: [U-Boot] [PATCH V3 1/3] drivers: block: add block device cache

[Stephen Warren]

On 03/30/2016 11:34 AM, Eric Nelson wrote:

Thanks again for the detailed review, Stephen.

On 03/30/2016 07:36 AM, Stephen Warren wrote:

On 03/28/2016 11:05 AM, Eric Nelson wrote:

Add a block device cache to speed up repeated reads of block devices by
various filesystems.



diff --git a/disk/part.c b/disk/part.c



@@ -268,6 +268,8 @@ void part_init(struct blk_desc *dev_desc)
   const int n_ents = ll_entry_count(struct part_driver, part_driver);
   struct part_driver *entry;

+blkcache_invalidate(dev_desc->if_type, dev_desc->devnum);


Doesn't this invalidate the cache far too often? I expect that function
is called for command the user executes from the command-line, whereas
it'd be nice if the cache persisted across commands. I suppose this is a
reasonable (and very safe) first implementation though, and saves having
to go through each storage provider type and find out the right place to
detect media changes.


I'm not sure it does. I traced through the mmc initialization and it's
only called when the card itself is initialized.


I don't believe U-Boot caches the partition structure across user 
commands. Doesn't each user command (e.g. part list, ls, load, save) 
first look up the block device, then scan the partition table, then 
"mount" the filesystem, then perform its action, then throw all that 
state away? Conversely, "mmc rescan" only happens under explicit user 
control. Still as I said, the current implementation is probably fine to 
start with, and at least is safe.



diff --git a/drivers/block/blkcache.c b/drivers/block/blkcache.c



+struct block_cache_node {
+struct list_head lh;
+int iftype;
+int devnum;
+lbaint_t start;
+lbaint_t blkcnt;
+unsigned long blksz;
+char *cache;
+};
+
+static LIST_HEAD(block_cache);
+
+static struct block_cache_stats _stats = {
+.max_blocks_per_entry = 2,
+.max_entries = 32
+};


Now is a good time to mention another reason why I don't like using a
dynamically allocated linked list for this: Memory fragmentation. By
dynamically allocating the cache, we could easily run into a situation
where the user runs a command that allocates memory and also adds to the
block cache, then most of that memory gets freed when U-Boot returns to
the command prompt, then the user runs the command again but it fails
since it can't allocate the memory due to fragmentation of the heap.
This is a real problem I've seen e.g. with the "ums" and "dfu" commands,
since they might initialize the USB controller the first time they're
run, which allocates some new memory. Statically allocation would avoid
this.


We're going to allocate a block or set of blocks every time we allocate
a new node for the list, so having the list in an array doesn't fix the
problem.


We could allocate the data storage for the block cache at the top of RAM 
before relocation, like many other things are allocated, and hence not 
use malloc() for that.



While re-working the code, I also thought more about using an array and
still don't see how the implementation doesn't get more complex.

The key bit is that the list is implemented in MRU order so
invalidating the oldest is trivial.


Yes, the MRU logic would make it more complex. Is that particularly 
useful, i.e. is it an intrinsic part of the speedup?

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

Re: [U-Boot] [PATCH 0/5] Basic support for Amlogic GXBaby and ODROID-C2

[Beniamino Galvani]

> Thank you Beniamino for this. Could you please keep
> linux-me...@googlegroups.com in CC for the next submissions?

I will surely do, thanks for testing.

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

[U-Boot] [PATCH] board: ti: DRA7: Add DP83867 TI phy for rev c

[Dan Murphy]

Enable the TI DP83867 Giga bit phy on the
dra7 rev c board.  The rx and tx internal
delays are need for this board so the usage
of RGMII_ID is required.

Signed-off-by: Dan Murphy 
---
 board/ti/dra7xx/evm.c| 6 ++
 include/configs/dra7xx_evm.h | 1 +
 2 files changed, 7 insertions(+)

diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c
index 25f2031..9bd71d8 100644
--- a/board/ti/dra7xx/evm.c
+++ b/board/ti/dra7xx/evm.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "mux_data.h"
 #include "../common/board_detect.h"
@@ -679,6 +680,11 @@ int board_eth_init(bd_t *bis)
if (*omap_si_rev == DRA722_ES1_0)
cpsw_data.active_slave = 1;
 
+   if (board_is_dra72x_revc_or_later()) {
+   cpsw_slaves[0].phy_if = PHY_INTERFACE_MODE_RGMII_ID;
+   cpsw_slaves[1].phy_if = PHY_INTERFACE_MODE_RGMII_ID;
+   }
+
ret = cpsw_register(_data);
if (ret < 0)
printf("Error %d registering CPSW switch\n", ret);
diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h
index c0795ab..7734e8d 100644
--- a/include/configs/dra7xx_evm.h
+++ b/include/configs/dra7xx_evm.h
@@ -155,6 +155,7 @@
 #define CONFIG_MII /* Required in net/eth.c */
 #define CONFIG_PHY_GIGE/* per-board part of CPSW */
 #define CONFIG_PHYLIB
+#define CONFIG_PHY_TI
 
 /* SPI */
 #undef CONFIG_OMAP3_SPI
-- 
2.8.0.rc3

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

Re: [U-Boot] [PATCH V3 1/3] drivers: block: add block device cache

[Eric Nelson]

Hi Tom,

On 03/30/2016 08:19 AM, Tom Rini wrote:
> On Wed, Mar 30, 2016 at 08:36:21AM -0600, Stephen Warren wrote:
>> On 03/28/2016 11:05 AM, Eric Nelson wrote:
>>> Add a block device cache to speed up repeated reads of block devices by
>>> various filesystems.
>>>
[snip]

>>> @@ -268,6 +268,8 @@ void part_init(struct blk_desc *dev_desc)
>>> const int n_ents = ll_entry_count(struct part_driver, part_driver);
>>> struct part_driver *entry;
>>>
>>> +   blkcache_invalidate(dev_desc->if_type, dev_desc->devnum);
>>
>> Doesn't this invalidate the cache far too often? I expect that
>> function is called for command the user executes from the
>> command-line, whereas it'd be nice if the cache persisted across
>> commands. I suppose this is a reasonable (and very safe) first
>> implementation though, and saves having to go through each storage
>> provider type and find out the right place to detect media changes.
> 
> My initial reaction here is that we should stay conservative and
> invalidate the cache more often rather than too infrequent.  I mean,
> what's the worst case here, an extra read? A few extra reads?  We want
> to make sure we keep the complexity to functionality ratio right here,
> if we make the recovery/flashing/factory cases a whole lot better but
> are leaving 1 second of wall clock time on the table when we've just
> gained a minute, we're OK.
> 

I don't think this is called during every command, at least not
with mmc.

>>> diff --git a/drivers/block/blkcache.c b/drivers/block/blkcache.c
>>
>>> +struct block_cache_node {
>>> +   struct list_head lh;
>>> +   int iftype;
>>> +   int devnum;
>>> +   lbaint_t start;
>>> +   lbaint_t blkcnt;
>>> +   unsigned long blksz;
>>> +   char *cache;
>>> +};
>>> +
>>> +static LIST_HEAD(block_cache);
>>> +
>>> +static struct block_cache_stats _stats = {
>>> +   .max_blocks_per_entry = 2,
>>> +   .max_entries = 32
>>> +};
>>
>> Now is a good time to mention another reason why I don't like using
>> a dynamically allocated linked list for this: Memory fragmentation.
>> By dynamically allocating the cache, we could easily run into a
>> situation where the user runs a command that allocates memory and
>> also adds to the block cache, then most of that memory gets freed
>> when U-Boot returns to the command prompt, then the user runs the
>> command again but it fails since it can't allocate the memory due to
>> fragmentation of the heap. This is a real problem I've seen e.g.
>> with the "ums" and "dfu" commands, since they might initialize the
>> USB controller the first time they're run, which allocates some new
>> memory. Statically allocation would avoid this.
> 
> That is a good point.  But how would you hit this?  The problem in
> ums/dfu was that it was several megabytes, yes?  My quick read over the
> code right now has me thinking this is something measured in kilobytes.
> 

36 bytes for the node, plus 512 bytes or 1k for the block data unless
tuned through the blkcache command.

And the block data is going to be allocated at the same time.

Regards,


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

Re: [U-Boot] [PATCH V3 1/3] drivers: block: add block device cache

[Eric Nelson]

Thanks again for the detailed review, Stephen.

On 03/30/2016 07:36 AM, Stephen Warren wrote:
> On 03/28/2016 11:05 AM, Eric Nelson wrote:
>> Add a block device cache to speed up repeated reads of block devices by
>> various filesystems.
>>

>> +
>> +printf("hits: %u\n"
>> +   "misses: %u\n"
>> +   "entries: %u\n"
>> +   "max blocks/entry: %u\n"
>> +   "max cache entries: %u\n",
> 
> Nit: I'm not sure why all that command output is indented. Perhaps it
> made sense before if some kind of title was printed before that text,
> but I don't think it is any more.
> 

Okay.

>> +if (c)
>> +return c->cmd(cmdtp, flag, argc, argv);
>> +else
>> +return CMD_RET_USAGE;
>> +
>> +return 0;
> 
> Nit: I'd prefer to see the error handling immediately follow the
> function call whose result is being tested, and the non-failure-case
> code be not indented, i.e.:
> 
> 
> c = find_cmd_tbl(argv[0], _blkc_sub[0], ARRAY_SIZE(cmd_blkc_sub));
> if (!c)
> return CMD_RET_USAGE;
> 
> return c->cmd(cmdtp, flag, argc, argv);
> 

Okay. As Tom pointed out, I copied this verbatim from i2c.c.

>> diff --git a/disk/part.c b/disk/part.c
> 
>> @@ -268,6 +268,8 @@ void part_init(struct blk_desc *dev_desc)
>>   const int n_ents = ll_entry_count(struct part_driver, part_driver);
>>   struct part_driver *entry;
>>
>> +blkcache_invalidate(dev_desc->if_type, dev_desc->devnum);
> 
> Doesn't this invalidate the cache far too often? I expect that function
> is called for command the user executes from the command-line, whereas
> it'd be nice if the cache persisted across commands. I suppose this is a
> reasonable (and very safe) first implementation though, and saves having
> to go through each storage provider type and find out the right place to
> detect media changes.
> 

I'm not sure it does. I traced through the mmc initialization and it's
only called when the card itself is initialized.

IOW, at the point where we'd recognize a card swap.

>> diff --git a/drivers/block/blkcache.c b/drivers/block/blkcache.c
> 
>> +struct block_cache_node {
>> +struct list_head lh;
>> +int iftype;
>> +int devnum;
>> +lbaint_t start;
>> +lbaint_t blkcnt;
>> +unsigned long blksz;
>> +char *cache;
>> +};
>> +
>> +static LIST_HEAD(block_cache);
>> +
>> +static struct block_cache_stats _stats = {
>> +.max_blocks_per_entry = 2,
>> +.max_entries = 32
>> +};
> 
> Now is a good time to mention another reason why I don't like using a
> dynamically allocated linked list for this: Memory fragmentation. By
> dynamically allocating the cache, we could easily run into a situation
> where the user runs a command that allocates memory and also adds to the
> block cache, then most of that memory gets freed when U-Boot returns to
> the command prompt, then the user runs the command again but it fails
> since it can't allocate the memory due to fragmentation of the heap.
> This is a real problem I've seen e.g. with the "ums" and "dfu" commands,
> since they might initialize the USB controller the first time they're
> run, which allocates some new memory. Statically allocation would avoid
> this.
> 

We're going to allocate a block or set of blocks every time we allocate
a new node for the list, so having the list in an array doesn't fix the
problem.

While re-working the code, I also thought more about using an array and
still don't see how the implementation doesn't get more complex.

The key bit is that the list is implemented in MRU order so
invalidating the oldest is trivial.

Doing this in an array would require keeping the array sorted (a bad
idea) or keeping an access sequence in each node of the array and
searching for oldest when invalidation is needed (when the max entries
limit is hit).

... unless I'm still missing something and you or Marek have something
else in mind.

I could also allocate an array of "free" nodes once the first time
around (as a buffer pool), but I don't think this is warranted because
of the block allocations I mentioned above.

>> diff --git a/include/blk.h b/include/blk.h
> 
>> +int blkcache_read
>> +(int iftype, int dev,
>> + lbaint_t start, lbaint_t blkcnt,
>> + unsigned long blksz, void *buffer);
> 
> Nit: The opening ( and first n arguments should be wrapped onto the same
> line as the function name.

Aargh. You've now pointed this out several times and I keep missing it.

Will fix in V4.

Regards,


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

[U-Boot] [PATCH 7/6] sunxi: Reserve ATF memory space on A64

[Alexander Graf]

On the A64 we usually boot with ATF running in EL3. ATF as it is available
today resides in the first 16MB of RAM. So we should make sure we reserve
that space in our memory maps.

Signed-off-by: Alexander Graf 
---
 board/sunxi/board.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 74510c5..331cb0a 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -136,6 +136,15 @@ int dram_init(void)
return 0;
 }
 
+#ifdef CONFIG_MACH_SUN50I
+void dram_init_banksize(void)
+{
+   /* We need to reserve the first 16MB of RAM for ATF */
+   gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE + (16 * 1024 * 1024);
+   gd->bd->bi_dram[0].size = get_effective_memsize() - (16 * 1024 * 1024);
+}
+#endif
+
 #if defined(CONFIG_NAND_SUNXI) && defined(CONFIG_SPL_BUILD)
 static void nand_pinmux_setup(void)
 {
-- 
1.8.5.6

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

Re: [U-Boot] [RFC v1 PATCH 1/1] mpc85xx: Enable pre-relocation malloc for MPC85xx

[York Sun]

On 03/29/2016 11:53 PM, Mario Six wrote:
> To enable DM on MPC85xx, we need pre-relocation malloc, which is
> implemented in this patch.
> 
> Signed-off-by: Mario Six 
> Cc: York Sun 
> Cc: Simon Glass 
> ---
>  arch/powerpc/cpu/mpc85xx/cpu_init_early.c |  8 
>  arch/powerpc/cpu/mpc85xx/start.S  | 28 
>  2 files changed, 28 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init_early.c 
> b/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
> index 235a635..e6e1688 100644
> --- a/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
> +++ b/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
> @@ -82,7 +82,6 @@ void setup_ifc(void)
>  void cpu_init_early_f(void *fdt)
>  {
>   u32 mas0, mas1, mas2, mas3, mas7;
> - int i;
>  #ifdef CONFIG_SYS_FSL_ERRATUM_P1010_A003549
>   ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
>  #endif
> @@ -95,13 +94,6 @@ void cpu_init_early_f(void *fdt)
>   /* Pointer is writable since we allocated a register for it */
>   gd = (gd_t *) (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_GBL_DATA_OFFSET);
> 
> - /*
> -  * Clear initial global data
> -  *   we don't use memset so we can share this code with NAND_SPL
> -  */
> - for (i = 0; i < sizeof(gd_t); i++)
> - ((char *)gd)[i] = 0;
> -
>  #ifdef CONFIG_QEMU_E500
>   /*
>* CONFIG_SYS_CCSRBAR_PHYS below may use gd->fdt_blob on ePAPR systems,
> diff --git a/arch/powerpc/cpu/mpc85xx/start.S 
> b/arch/powerpc/cpu/mpc85xx/start.S
> index d867e2a..e6b5203 100644
> --- a/arch/powerpc/cpu/mpc85xx/start.S
> +++ b/arch/powerpc/cpu/mpc85xx/start.S
> @@ -1152,6 +1152,34 @@ _start_cont:
>   /* Setup the stack in initial RAM,could be L2-as-SRAM or L1 dcache*/
>   lis r3,(CONFIG_SYS_INIT_RAM_ADDR)@h
>   ori r3,r3,((CONFIG_SYS_INIT_SP_OFFSET-16)&~0xf)@l /* Align to 16 */
> +
> +#ifdef CONFIG_SYS_MALLOC_F_LEN
> + /* Leave 16+ byte for back chain termination and NULL return address */
> + subir3,r3,((CONFIG_SYS_MALLOC_F_LEN+16+15)&~0xf)
> +
> + /* End of RAM */
> + lis r4,(CONFIG_SYS_INIT_RAM_ADDR)@h
> + ori r4,r4,(CONFIG_SYS_INIT_RAM_SIZE)@l
> +
> + li  r0,0
> +
> +1:   subir4,r4,4
> + stw r0,0(r4)
> + cmplw   r4,r3
> + bne 1b
> +
> + lis r4,(CONFIG_SYS_INIT_RAM_ADDR)@h
> + ori r4,r4,(CONFIG_SYS_GBL_DATA_OFFSET)@l
> +
> + addir3,r3,16/* Pre-relocation malloc area */
> + stw r3,GD_MALLOC_BASE(r4)
> + subir3,r3,16
> +
> + /* Fix issue with exception handler alignment */
> + nop
> + nop
> + nop

Why do you need this? Does the code get too long and enters exception handler 
space?

> +#endif
>   li  r0,0
>   stw r0,0(r3)/* Terminate Back Chain */
>   stw r0,+4(r3)   /* NULL return address. */
> --

This patch presumes stack is right under GD, which is OK. But
CONFIG_SYS_MALLOC_F_LEN has not been used by powerpc. Presumption of
(CONFIG_SYS_MALLOC_F_LEN + GENERATED_GBL_DATA_SIZE) < CONFIG_SYS_INIT_RAM_SIZE
may not be true. Would it be better to check at compiling time to make sure we
have enough init ram for the malloc len?

York


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

Re: [U-Boot] [PATCH V3 1/3] drivers: block: add block device cache

[Stephen Warren]

On 03/30/2016 09:19 AM, Tom Rini wrote:

On Wed, Mar 30, 2016 at 08:36:21AM -0600, Stephen Warren wrote:

On 03/28/2016 11:05 AM, Eric Nelson wrote:

Add a block device cache to speed up repeated reads of block devices by
various filesystems.

This small amount of cache can dramatically speed up filesystem
operations by skipping repeated reads of common areas of a block
device (typically directory structures).

This has shown to have some benefit on FAT filesystem operations of
loading a kernel and RAM disk, but more dramatic benefits on ext4
filesystems when the kernel and/or RAM disk are spread across
multiple extent header structures as described in commit fc0fc50.

The cache is implemented through a minimal list (block_cache) maintained
in most-recently-used order and count of the current number of entries
(cache_count). It uses a maximum block count setting to prevent copies
of large block reads and an upper bound on the number of cached areas.

The maximum number of entries in the cache defaults to 32 and the maximum
number of blocks per cache entry has a default of 2, which has shown to
produce the best results on testing of ext4 and FAT filesystems.

The 'blkcache' command (enabled through CONFIG_CMD_BLOCK_CACHE) allows
changing these values and can be used to tune for a particular filesystem
layout.

[snip]

diff --git a/disk/part.c b/disk/part.c



@@ -268,6 +268,8 @@ void part_init(struct blk_desc *dev_desc)
const int n_ents = ll_entry_count(struct part_driver, part_driver);
struct part_driver *entry;

+   blkcache_invalidate(dev_desc->if_type, dev_desc->devnum);


Doesn't this invalidate the cache far too often? I expect that
function is called for command the user executes from the
command-line, whereas it'd be nice if the cache persisted across
commands. I suppose this is a reasonable (and very safe) first
implementation though, and saves having to go through each storage
provider type and find out the right place to detect media changes.


My initial reaction here is that we should stay conservative and
invalidate the cache more often rather than too infrequent.  I mean,
what's the worst case here, an extra read? A few extra reads?  We want
to make sure we keep the complexity to functionality ratio right here,
if we make the recovery/flashing/factory cases a whole lot better but
are leaving 1 second of wall clock time on the table when we've just
gained a minute, we're OK.


diff --git a/drivers/block/blkcache.c b/drivers/block/blkcache.c



+struct block_cache_node {
+   struct list_head lh;
+   int iftype;
+   int devnum;
+   lbaint_t start;
+   lbaint_t blkcnt;
+   unsigned long blksz;
+   char *cache;
+};
+
+static LIST_HEAD(block_cache);
+
+static struct block_cache_stats _stats = {
+   .max_blocks_per_entry = 2,
+   .max_entries = 32
+};


Now is a good time to mention another reason why I don't like using
a dynamically allocated linked list for this: Memory fragmentation.
By dynamically allocating the cache, we could easily run into a
situation where the user runs a command that allocates memory and
also adds to the block cache, then most of that memory gets freed
when U-Boot returns to the command prompt, then the user runs the
command again but it fails since it can't allocate the memory due to
fragmentation of the heap. This is a real problem I've seen e.g.
with the "ums" and "dfu" commands, since they might initialize the
USB controller the first time they're run, which allocates some new
memory. Statically allocation would avoid this.


That is a good point.  But how would you hit this?  The problem in
ums/dfu was that it was several megabytes, yes?  My quick read over the
code right now has me thinking this is something measured in kilobytes.


The allocation that failed was a large multi-megabyte buffer. However, 
the allocations that caused the fragmentation/failure were small 
(probably tens/hundreds of bytes, but I didn't check).


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

Re: [U-Boot] [PATCH V3 1/3] drivers: block: add block device cache

[Tom Rini]

On Wed, Mar 30, 2016 at 08:36:21AM -0600, Stephen Warren wrote:
> On 03/28/2016 11:05 AM, Eric Nelson wrote:
> >Add a block device cache to speed up repeated reads of block devices by
> >various filesystems.
> >
> >This small amount of cache can dramatically speed up filesystem
> >operations by skipping repeated reads of common areas of a block
> >device (typically directory structures).
> >
> >This has shown to have some benefit on FAT filesystem operations of
> >loading a kernel and RAM disk, but more dramatic benefits on ext4
> >filesystems when the kernel and/or RAM disk are spread across
> >multiple extent header structures as described in commit fc0fc50.
> >
> >The cache is implemented through a minimal list (block_cache) maintained
> >in most-recently-used order and count of the current number of entries
> >(cache_count). It uses a maximum block count setting to prevent copies
> >of large block reads and an upper bound on the number of cached areas.
> >
> >The maximum number of entries in the cache defaults to 32 and the maximum
> >number of blocks per cache entry has a default of 2, which has shown to
> >produce the best results on testing of ext4 and FAT filesystems.
> >
> >The 'blkcache' command (enabled through CONFIG_CMD_BLOCK_CACHE) allows
> >changing these values and can be used to tune for a particular filesystem
> >layout.
[snip]
> >diff --git a/disk/part.c b/disk/part.c
> 
> >@@ -268,6 +268,8 @@ void part_init(struct blk_desc *dev_desc)
> > const int n_ents = ll_entry_count(struct part_driver, part_driver);
> > struct part_driver *entry;
> >
> >+blkcache_invalidate(dev_desc->if_type, dev_desc->devnum);
> 
> Doesn't this invalidate the cache far too often? I expect that
> function is called for command the user executes from the
> command-line, whereas it'd be nice if the cache persisted across
> commands. I suppose this is a reasonable (and very safe) first
> implementation though, and saves having to go through each storage
> provider type and find out the right place to detect media changes.

My initial reaction here is that we should stay conservative and
invalidate the cache more often rather than too infrequent.  I mean,
what's the worst case here, an extra read? A few extra reads?  We want
to make sure we keep the complexity to functionality ratio right here,
if we make the recovery/flashing/factory cases a whole lot better but
are leaving 1 second of wall clock time on the table when we've just
gained a minute, we're OK.

> >diff --git a/drivers/block/blkcache.c b/drivers/block/blkcache.c
> 
> >+struct block_cache_node {
> >+struct list_head lh;
> >+int iftype;
> >+int devnum;
> >+lbaint_t start;
> >+lbaint_t blkcnt;
> >+unsigned long blksz;
> >+char *cache;
> >+};
> >+
> >+static LIST_HEAD(block_cache);
> >+
> >+static struct block_cache_stats _stats = {
> >+.max_blocks_per_entry = 2,
> >+.max_entries = 32
> >+};
> 
> Now is a good time to mention another reason why I don't like using
> a dynamically allocated linked list for this: Memory fragmentation.
> By dynamically allocating the cache, we could easily run into a
> situation where the user runs a command that allocates memory and
> also adds to the block cache, then most of that memory gets freed
> when U-Boot returns to the command prompt, then the user runs the
> command again but it fails since it can't allocate the memory due to
> fragmentation of the heap. This is a real problem I've seen e.g.
> with the "ums" and "dfu" commands, since they might initialize the
> USB controller the first time they're run, which allocates some new
> memory. Statically allocation would avoid this.

That is a good point.  But how would you hit this?  The problem in
ums/dfu was that it was several megabytes, yes?  My quick read over the
code right now has me thinking this is something measured in kilobytes.

-- 
Tom


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

Re: [U-Boot] [PATCH V3 1/3] drivers: block: add block device cache

[Stephen Warren]

On 03/28/2016 11:05 AM, Eric Nelson wrote:

Add a block device cache to speed up repeated reads of block devices by
various filesystems.

This small amount of cache can dramatically speed up filesystem
operations by skipping repeated reads of common areas of a block
device (typically directory structures).

This has shown to have some benefit on FAT filesystem operations of
loading a kernel and RAM disk, but more dramatic benefits on ext4
filesystems when the kernel and/or RAM disk are spread across
multiple extent header structures as described in commit fc0fc50.

The cache is implemented through a minimal list (block_cache) maintained
in most-recently-used order and count of the current number of entries
(cache_count). It uses a maximum block count setting to prevent copies
of large block reads and an upper bound on the number of cached areas.

The maximum number of entries in the cache defaults to 32 and the maximum
number of blocks per cache entry has a default of 2, which has shown to
produce the best results on testing of ext4 and FAT filesystems.

The 'blkcache' command (enabled through CONFIG_CMD_BLOCK_CACHE) allows
changing these values and can be used to tune for a particular filesystem
layout.



diff --git a/cmd/blkcache.c b/cmd/blkcache.c



+static int blkc_show(cmd_tbl_t *cmdtp, int flag,
+int argc, char * const argv[])
+{
+   struct block_cache_stats stats;
+   blkcache_stats();
+
+   printf("hits: %u\n"
+  "misses: %u\n"
+  "entries: %u\n"
+  "max blocks/entry: %u\n"
+  "max cache entries: %u\n",


Nit: I'm not sure why all that command output is indented. Perhaps it 
made sense before if some kind of title was printed before that text, 
but I don't think it is any more.



+static int do_blkcache(cmd_tbl_t *cmdtp, int flag,



+   c = find_cmd_tbl(argv[0], _blkc_sub[0], ARRAY_SIZE(cmd_blkc_sub));
+
+   if (c)
+   return c->cmd(cmdtp, flag, argc, argv);
+   else
+   return CMD_RET_USAGE;
+
+   return 0;


Nit: I'd prefer to see the error handling immediately follow the 
function call whose result is being tested, and the non-failure-case 
code be not indented, i.e.:



c = find_cmd_tbl(argv[0], _blkc_sub[0], ARRAY_SIZE(cmd_blkc_sub));
if (!c)
return CMD_RET_USAGE;

return c->cmd(cmdtp, flag, argc, argv);


diff --git a/disk/part.c b/disk/part.c



@@ -268,6 +268,8 @@ void part_init(struct blk_desc *dev_desc)
const int n_ents = ll_entry_count(struct part_driver, part_driver);
struct part_driver *entry;

+   blkcache_invalidate(dev_desc->if_type, dev_desc->devnum);


Doesn't this invalidate the cache far too often? I expect that function 
is called for command the user executes from the command-line, whereas 
it'd be nice if the cache persisted across commands. I suppose this is a 
reasonable (and very safe) first implementation though, and saves having 
to go through each storage provider type and find out the right place to 
detect media changes.



diff --git a/drivers/block/blkcache.c b/drivers/block/blkcache.c



+struct block_cache_node {
+   struct list_head lh;
+   int iftype;
+   int devnum;
+   lbaint_t start;
+   lbaint_t blkcnt;
+   unsigned long blksz;
+   char *cache;
+};
+
+static LIST_HEAD(block_cache);
+
+static struct block_cache_stats _stats = {
+   .max_blocks_per_entry = 2,
+   .max_entries = 32
+};


Now is a good time to mention another reason why I don't like using a 
dynamically allocated linked list for this: Memory fragmentation. By 
dynamically allocating the cache, we could easily run into a situation 
where the user runs a command that allocates memory and also adds to the 
block cache, then most of that memory gets freed when U-Boot returns to 
the command prompt, then the user runs the command again but it fails 
since it can't allocate the memory due to fragmentation of the heap. 
This is a real problem I've seen e.g. with the "ums" and "dfu" commands, 
since they might initialize the USB controller the first time they're 
run, which allocates some new memory. Statically allocation would avoid 
this.



diff --git a/include/blk.h b/include/blk.h



+int blkcache_read
+   (int iftype, int dev,
+lbaint_t start, lbaint_t blkcnt,
+unsigned long blksz, void *buffer);


Nit: The opening ( and first n arguments should be wrapped onto the same 
line as the function name.

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

[U-Boot] [PATCH] efi_loader: Always allocate the highest available address

[Alexander Graf]

Some EFI applications (grub2) expect that an allocation always returns
the highest available memory address for the given size.

Without this, we may run into situations where the initrd gets allocated
at a lower address than the kernel.

This patch fixes booting in such situations for me.

Signed-off-by: Alexander Graf 
---
 lib/efi_loader/efi_memory.c | 29 +
 1 file changed, 29 insertions(+)

diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
index c82b53f..8a1e249 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -27,6 +28,31 @@ struct efi_mem_list {
 LIST_HEAD(efi_mem);
 
 /*
+ * Sorts the memory list from highest address to lowest address
+ *
+ * When allocating memory we should always start from the highest
+ * address chunk, so sort the memory list such that the first list
+ * iterator gets the highest address and goes lower from there.
+ */
+static int efi_mem_cmp(void *priv, struct list_head *a, struct list_head *b)
+{
+   struct efi_mem_list *mema = list_entry(a, struct efi_mem_list, link);
+   struct efi_mem_list *memb = list_entry(b, struct efi_mem_list, link);
+
+   if (mema->desc.physical_start == memb->desc.physical_start)
+   return 0;
+   else if (mema->desc.physical_start < memb->desc.physical_start)
+   return 1;
+   else
+   return -1;
+}
+
+static void efi_mem_sort(void)
+{
+   list_sort(NULL, _mem, efi_mem_cmp);
+}
+
+/*
  * Unmaps all memory occupied by the carve_desc region from the
  * list entry pointed to by map.
  *
@@ -142,6 +168,9 @@ uint64_t efi_add_memory_map(uint64_t start, uint64_t pages, 
int memory_type,
/* Add our new map */
 list_add_tail(>link, _mem);
 
+   /* And make sure memory is listed in descending order */
+   efi_mem_sort();
+
return start;
 }
 
-- 
1.8.5.6

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

Re: [U-Boot] Problem with sf write on Arria 5.

[Chin Liang See]

On Wed, 2016-03-30 at 13:46 +, Bakhvalov, Denis (Nokia -
PL/Wroclaw) wrote:
> Hi Marek,
> 
> > Do "dcache off" and then update the flash again, it will work.
> > That's
> > the cache issue which we cannot track down.
> 
> Thank you for you quick support!
> 
> Maybe it's worth to invent a temporary solution?
> Because in other way users will face problems which are hard to find
> (I've been chasing this problem for 2 days).
> For example execute "dcache off" internally when sf write is called?
> 

I believe we can turn of the dcache as default for socfpga while effort
in progress to figure out the issue.

FYI, I was experimenting with L2 cache PL-310 registers but not
successful. I am trying to understand any issue between L2 cache and
the SDRAM. There is l2 cache sync after a flush but seems its not
working fine. Adding delay works but that not deemed a correct solution
(for USB case). Probably doing a virtual memory aliasing might
understand where the data was stuck.

Thanks
Chin Liang


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

[U-Boot] Custom configurations

[Jan Danielsson]

Hello,

   Is there a way to pass a custom out-of-tree configuration to the
build system?

   This page seems to have an unofficial patch which outlines exactly
what we'd like to do:
https://boundarydevices.com/customizing-u-boot-on-i-mx/

   We have a script which builds an embedded system; it's possible to
pass an parameters to the build script to instruct it take different
build routes (build for different operating systems, hardware platforms,
etc, as well as development versions and production versions).

   I would like to be able to use a simple switch to the build script to
enable "tftp mode", which would mean that it builds all the necessary
files for booting from tftp, but more importantly, tell u-boot to
automatically initialize and boot from tftp.  Other factors play in as
well, like which system it is being built on.

   To illustrate (in short) what I would like to do:

   rm myconf.h
   if [ "$BOOTMODE" = "tftp" ]; then
 if [ "`hostname`" = "maindevsys" ]; then
   SERVERIP="10.101.20.12"
 else
   SERVERIP="`getselfip`"
 fi
 echo CONFIG_BOOTCOMMAND="setenv serverip $SERVERIP ; dhcp ;
tftpboot 0x1000 uramdisk.image.gz ; tftpboot 0x1320 uImage ;
tftpboot 0x1640 zynq-zed.dtb ; bootm 0x1320 0x1000
0x1640" >> ~/tmp/myconf.h
   fi
   [---]
   CUSTOM_CONFIG=~/rmp/myconf.h make zynq_picozed_config
   make

   (Ignore missing escapes etc; this is just for illustration).

   As you can see, the configuration can be pretty dynamic, so this
isn't something we'd like to host in a repository, and furthermore I
would prefer not to modify any in-tree files if possible (it's not a
problem for me to migrate our changes to a new official release branch,
but I'm trying to make this as simple as possible for whoever takes over
maintainership further down the road).

   I'd be surprised if others haven't encountered this need before; and
in place of the CUSTOM_CONFIG feature, what other solutions have people
come up with?

   The most straightforward solution, given the boundary conditions I
set up, would currently, to me, be to make a copy of the picozed config
and copy it into the include/configs directory, and make the appropriate
dynamic modifications in the non-scm tracked file.  This does however
put some extra burden on the person updating the u-boot version used in
the build.

   Looking for any helpful tips on how to accomplish this.

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

Re: [U-Boot] Problem with sf write on Arria 5.

[Marek Vasut]

On 03/30/2016 03:46 PM, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote:
> Hi Marek,
> 
>> Do "dcache off" and then update the flash again, it will work. That's
>> the cache issue which we cannot track down.
> 
> Thank you for you quick support!
> 
> Maybe it's worth to invent a temporary solution?
> Because in other way users will face problems which are hard to find (I've 
> been chasing this problem for 2 days).
> For example execute "dcache off" internally when sf write is called?

Such "temporary solution" will only root in place and noone will ever
fix the real problem anymore. Moreover, the performance hit is really
bad if you turn cache off.

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

Re: [U-Boot] Problem with sf write on Arria 5.

[Bakhvalov, Denis (Nokia - PL/Wroclaw)]

Hi Marek,

> Do "dcache off" and then update the flash again, it will work. That's
> the cache issue which we cannot track down.

Thank you for you quick support!

Maybe it's worth to invent a temporary solution?
Because in other way users will face problems which are hard to find (I've been 
chasing this problem for 2 days).
For example execute "dcache off" internally when sf write is called?

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

Re: [U-Boot] Problem with sf write on Arria 5.

[Marek Vasut]

On 03/30/2016 01:14 PM, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote:
> Dear U-Boot support,
>  
> I’m migrating to new U-Boot version from 2013 and now have problem with
> writing to the flash.
>  
> I have custom board with Altera Arria 5 SocFpga.
> U-Boot version: 2016.03-rc1
> My flash:
> SF: Detected S25FL512S_256K with page size 512 Bytes, erase size 256
> KiB, total 64 MiB
>  
> I’m rewriting the flash with the image that I downloaded from tftp.
> #> tftp 0x1B00 flash.bin
> Then I’m trying to write it to the flash:
> #> sf erase …
> #> sf write …
> After that if I try to mount Ubi partition (this is read operation) I
> receive failures (usually checksum errors).
> So, the problem is that when I’m writing some data to flash and reading
> it back the data is corrupted.
> I’m almost sure that there is no issue with reading, because previously
> I was able to read big amount of data successfully (for example, reading
> OS image and booting it).
>  
> With previous version (2013) there is no such issue.
> With the same sequence of commands I was able to update entire flash.
>  
> I was able to reduce this problem to a smaller one.
> I’m checking consistency of write operation by writing zipped file (3 KB):
> #> tftp 0x1B00 file.zip
> #> sf erase  
> #> sf write   
> #> sf read   
> #> unzip  
>  
> And sometimes I can see:
> Uncompressed size: 524288 = 0x8 (success)
> but more often:
> Error: inflate() returned -3 (data was corrupted)
>  
> So, the problem appears to be occasional.
>  
> When I’m comparing the original data with the data that I’ve read from
> flash I can see the blocks of 256 bytes were not written (0x).
> For example:
> Original data:
> 1b000200: c62e214e 0e48a4c9 19038ec8 37531cfdN!H...S7
> 1b000210: 8f1c7048 f60b861f e9482d5c 857404e8Hp..\-H...t.
> 1b000220: ef3996c1 fd02b093 2ee8d1f6 679ab03d..9.=..g
> 1b000230: e6c739f4 194eaec7 383ddca8 6f90a2ad.9N...=8...o
> … and so on until (1b000300)
> Stored data:
> 1f000200:    
> 1f000210:    
> 1f000220:    
> 1f000230:    
> … and so on until (1f000300)
>  
> I already checked difference in QSPI registers (base address:
> 0xFF705000) between two versions of U-Boot, but haven’t found any clue yet.
> If needed I can provide this diff.

Do "dcache off" and then update the flash again, it will work. That's
the cache issue which we cannot track down.

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

Re: [U-Boot] Issue with ALLOC_CACHE_ALIGN_BUFFER in env_relocate_spec and

[Vincent]

Hi,
In the end, it seems that the issue is neither MMC nor Normal/Secure
world related, but cache related. Between SPL and u-boot, I run a
small piece of secure software, which turns on the ACTLR.SMP bit.
According to cortex a7 TRM, this is mandatory to enable caching.
Setting the MMU is not enough.

With ACTLR.SMP bit set to 1, I get strange behavior in several places
in u-boot (I can witness CAAM & MMC at least).
Could it be that u-boot was running without cache on cortex-a7 and
activating this bit made cache related issues arise ?

Best,
Vincent

2016-03-25 18:33 GMT+01:00 Vincent :
> Hi,
> I am having some issue with several instances of
> ALLOC_CACHE_ALIGN_BUFFER in (at least):
> - common/env_mmc: env_relocate_spec
> - disk/part_dos: test_part_dos
>
> U-boot (ls1021atwr) is build in SPL mode, SPL part is in Secure World,
> u-boot is in Normal World.
> In the SPL part, there is no problem, MMC access are fine. In the
> normal world, I experience what I think is stack corruption:
>
> At these locations, calls to the MMC to read partition info mostly
> read 0 or garbages. Garbage looks like stack overflow/corruption. For
> example, in the first function, checking the CRC of u-boot's env
> stored in the MMC fails because the buffer is correct until the last
> kb where there is values instead of zeroes, which looks like RAM
> addresses and data.
>
> I tried several fix, but I still don't understand what's happening:
> - I tried to allocate the buffer where MMC data is read into the head
> -> it works fine
> - I tried to allocate more room to these buffer on the stack ->
> sometimes it works, but not always.
>
> Maybe it's my compiler (NXP's SDK 1.9, based on yocto) which is buggy,
> I don't know.
> I can provide some custom dump of memory if necessary, but the buffers
> at these locations are quite huge I'm afraid.
>
> Best regards,
> Vincent
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] ARM: uniphier: remove CONFIG_ARP_TIMEOUT define

[Masahiro Yamada]

I no longer see the problem claimed in the comment block.  Rather,
the 0.5 msec timeout seems too short for some TFTP servers.

Drop the CONFIG_ARM_TIMEOUT to fall back to the 5 sec timeout.

Signed-off-by: Masahiro Yamada 
---

 include/configs/uniphier.h | 8 
 1 file changed, 8 deletions(-)

diff --git a/include/configs/uniphier.h b/include/configs/uniphier.h
index 963f55b..c6fc90f 100644
--- a/include/configs/uniphier.h
+++ b/include/configs/uniphier.h
@@ -102,14 +102,6 @@
 /* Time clock 1MHz */
 #define CONFIG_SYS_TIMER_RATE  100
 
-/*
- * By default, ARP timeout is 5 sec.
- * The first ARP request does not seem to work.
- * So we need to retry ARP request anyway.
- * We want to shrink the interval until the second ARP request.
- */
-#define CONFIG_ARP_TIMEOUT 500UL  /* 0.5 msec */
-
 #define CONFIG_SYS_MAX_NAND_DEVICE 1
 #define CONFIG_SYS_NAND_MAX_CHIPS  2
 #define CONFIG_SYS_NAND_ONFI_DETECTION
-- 
1.9.1

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

[U-Boot] [PATCH v2 0/2] ARM: uniphier: add ARMv8 SoCs support

[Masahiro Yamada]

Masahiro Yamada (2):
  ARM: uniphier: add PH1-LD20 SoC support
  ARM: uniphier: add PH1-LD11 SoC support

 arch/arm/mach-uniphier/Kconfig| 10 +++
 arch/arm/mach-uniphier/Makefile   |  1 +
 arch/arm/mach-uniphier/arm64/Makefile |  8 +++
 arch/arm/mach-uniphier/arm64/mem_map.c| 28 +
 arch/arm/mach-uniphier/board_late_init.c  |  3 +-
 arch/arm/mach-uniphier/boards.c   | 45 +
 arch/arm/mach-uniphier/boot-mode/Makefile |  1 +
 arch/arm/mach-uniphier/boot-mode/boot-device.h|  2 +
 arch/arm/mach-uniphier/boot-mode/boot-mode-ld20.c | 77 +++
 arch/arm/mach-uniphier/boot-mode/boot-mode.c  |  4 ++
 arch/arm/mach-uniphier/boot-mode/cmd_pinmon.c |  5 ++
 arch/arm/mach-uniphier/cpu_info.c |  4 +-
 arch/arm/mach-uniphier/dram/Makefile  |  2 +
 arch/arm/mach-uniphier/dram/umc-ld11.c| 14 +
 arch/arm/mach-uniphier/dram/umc-ld20.c| 14 +
 arch/arm/mach-uniphier/early-clk/Makefile |  1 +
 arch/arm/mach-uniphier/early-clk/early-clk-ld20.c | 30 +
 arch/arm/mach-uniphier/init.h |  4 ++
 arch/arm/mach-uniphier/init/Makefile  |  2 +
 arch/arm/mach-uniphier/init/init-ld11.c   | 56 +
 arch/arm/mach-uniphier/init/init-ld20.c   | 55 
 arch/arm/mach-uniphier/init/init.c|  5 ++
 arch/arm/mach-uniphier/memconf/Makefile   |  1 +
 arch/arm/mach-uniphier/memconf/memconf-pxs2.c |  3 +
 arch/arm/mach-uniphier/sbc/Makefile   |  1 +
 arch/arm/mach-uniphier/sg-regs.h  |  3 +-
 configs/uniphier_ld11_defconfig   | 28 +
 configs/uniphier_ld20_defconfig   | 28 +
 include/configs/uniphier.h| 43 +++--
 29 files changed, 469 insertions(+), 9 deletions(-)
 create mode 100644 arch/arm/mach-uniphier/arm64/Makefile
 create mode 100644 arch/arm/mach-uniphier/arm64/mem_map.c
 create mode 100644 arch/arm/mach-uniphier/boot-mode/boot-mode-ld20.c
 create mode 100644 arch/arm/mach-uniphier/dram/umc-ld11.c
 create mode 100644 arch/arm/mach-uniphier/dram/umc-ld20.c
 create mode 100644 arch/arm/mach-uniphier/early-clk/early-clk-ld20.c
 create mode 100644 arch/arm/mach-uniphier/init/init-ld11.c
 create mode 100644 arch/arm/mach-uniphier/init/init-ld20.c
 create mode 100644 configs/uniphier_ld11_defconfig
 create mode 100644 configs/uniphier_ld20_defconfig

-- 
1.9.1

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

[U-Boot] [PATCH v2 2/2] ARM: uniphier: add PH1-LD11 SoC support

[Masahiro Yamada]

Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - newly added

 arch/arm/mach-uniphier/Kconfig   |  5 +++
 arch/arm/mach-uniphier/board_late_init.c |  1 +
 arch/arm/mach-uniphier/boards.c  | 20 
 arch/arm/mach-uniphier/cpu_info.c|  2 +-
 arch/arm/mach-uniphier/dram/Makefile |  1 +
 arch/arm/mach-uniphier/dram/umc-ld11.c   | 14 
 arch/arm/mach-uniphier/init.h|  1 +
 arch/arm/mach-uniphier/init/Makefile |  1 +
 arch/arm/mach-uniphier/init/init-ld11.c  | 56 
 configs/uniphier_ld11_defconfig  | 28 
 include/configs/uniphier.h   |  8 -
 11 files changed, 135 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/mach-uniphier/dram/umc-ld11.c
 create mode 100644 arch/arm/mach-uniphier/init/init-ld11.c
 create mode 100644 configs/uniphier_ld11_defconfig

diff --git a/arch/arm/mach-uniphier/Kconfig b/arch/arm/mach-uniphier/Kconfig
index 87d1675..ae763ad 100644
--- a/arch/arm/mach-uniphier/Kconfig
+++ b/arch/arm/mach-uniphier/Kconfig
@@ -23,6 +23,11 @@ config ARCH_UNIPHIER_PRO5_PXS2_LD6B
bool "UniPhier PH1-Pro5/ProXstream2/PH1-LD6b SoC"
select CPU_V7
 
+config ARCH_UNIPHIER_LD11
+   bool "UniPhier PH1-LD11 SoC"
+   select ARM64
+   select SPL_SEPARATE_BSS
+
 config ARCH_UNIPHIER_LD20
bool "UniPhier PH1-LD20 SoC"
select ARM64
diff --git a/arch/arm/mach-uniphier/board_late_init.c 
b/arch/arm/mach-uniphier/board_late_init.c
index a440a7e..7069836 100644
--- a/arch/arm/mach-uniphier/board_late_init.c
+++ b/arch/arm/mach-uniphier/board_late_init.c
@@ -36,6 +36,7 @@ struct uniphier_fdt_file {
 static const struct uniphier_fdt_file uniphier_fdt_files[] = {
{ "socionext,ph1-ld4-ref", "uniphier-ph1-ld4-ref.dtb", },
{ "socionext,ph1-ld6b-ref", "uniphier-ph1-ld6b-ref.dtb", },
+   { "socionext,ph1-ld11-ref", "uniphier-ph1-ld11-ref.dtb", },
{ "socionext,ph1-ld20-ref", "uniphier-ph1-ld20-ref.dtb", },
{ "socionext,ph1-pro4-ace", "uniphier-ph1-pro4-ace.dtb", },
{ "socionext,ph1-pro4-ref", "uniphier-ph1-pro4-ref.dtb", },
diff --git a/arch/arm/mach-uniphier/boards.c b/arch/arm/mach-uniphier/boards.c
index f0547c3..3d754c0 100644
--- a/arch/arm/mach-uniphier/boards.c
+++ b/arch/arm/mach-uniphier/boards.c
@@ -165,6 +165,23 @@ static const struct uniphier_board_data uniphier_ld6b_data 
= {
 };
 #endif
 
+#if defined(CONFIG_ARCH_UNIPHIER_LD11)
+static const struct uniphier_board_data uniphier_ld11_data = {
+   .dram_freq = 1600,
+   .dram_nr_ch = 2,
+   .dram_ch[0] = {
+   .base = 0x8000,
+   .size = 0x2000,
+   .width = 16,
+   },
+   .dram_ch[1] = {
+   .base = 0xa000,
+   .size = 0x2000,
+   .width = 16,
+   },
+};
+#endif
+
 #if defined(CONFIG_ARCH_UNIPHIER_LD20)
 static const struct uniphier_board_data uniphier_ld20_data = {
.dram_freq = 1866,
@@ -216,6 +233,9 @@ static const struct uniphier_board_id uniphier_boards[] = {
 #if defined(CONFIG_ARCH_UNIPHIER_LD6B)
{ "socionext,ph1-ld6b", _ld6b_data, },
 #endif
+#if defined(CONFIG_ARCH_UNIPHIER_LD11)
+   { "socionext,ph1-ld20", _ld11_data, },
+#endif
 #if defined(CONFIG_ARCH_UNIPHIER_LD20)
{ "socionext,ph1-ld20", _ld20_data, },
 #endif
diff --git a/arch/arm/mach-uniphier/cpu_info.c 
b/arch/arm/mach-uniphier/cpu_info.c
index f9646c0..6ad4c76 100644
--- a/arch/arm/mach-uniphier/cpu_info.c
+++ b/arch/arm/mach-uniphier/cpu_info.c
@@ -45,7 +45,7 @@ int print_cpuinfo(void)
puts("PH1-LD6b (MN2WS0320)");
break;
case 0x31:
-   puts("PH1-LD11 ()");
+   puts("PH1-LD11 (SC1405AP1)");
break;
case 0x32:
puts("PH1-LD20 (SC1401AJ1)");
diff --git a/arch/arm/mach-uniphier/dram/Makefile 
b/arch/arm/mach-uniphier/dram/Makefile
index 41aa53b..5b9d892 100644
--- a/arch/arm/mach-uniphier/dram/Makefile
+++ b/arch/arm/mach-uniphier/dram/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_ARCH_UNIPHIER_SLD8)  += umc-sld8.o \
   ddrphy-training.o ddrphy-ld4.o
 obj-$(CONFIG_ARCH_UNIPHIER_PXS2)   += umc-pxs2.o
 obj-$(CONFIG_ARCH_UNIPHIER_LD6B)   += umc-pxs2.o
+obj-$(CONFIG_ARCH_UNIPHIER_LD11)   += umc-ld11.o
 obj-$(CONFIG_ARCH_UNIPHIER_LD20)   += umc-ld20.o
 
 else
diff --git a/arch/arm/mach-uniphier/dram/umc-ld11.c 
b/arch/arm/mach-uniphier/dram/umc-ld11.c
new file mode 100644
index 000..e9ee12e
--- /dev/null
+++ b/arch/arm/mach-uniphier/dram/umc-ld11.c
@@ -0,0 +1,14 @@
+/*
+ * Copyright (C) 2016 Socionext Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+
+#include "../init.h"
+
+int uniphier_ld11_umc_init(const struct uniphier_board_data *bd)
+{
+   return 0;
+}
diff --git a/arch/arm/mach-uniphier/init.h b/arch/arm/mach-uniphier/init.h

[U-Boot] [PATCH v2 1/2] ARM: uniphier: add PH1-LD20 SoC support

[Masahiro Yamada]

This is the first ARMv8 SoC from Socionext Inc.

Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - Enable booti command
  - add early_clk_init func()

 arch/arm/mach-uniphier/Kconfig|  5 ++
 arch/arm/mach-uniphier/Makefile   |  1 +
 arch/arm/mach-uniphier/arm64/Makefile |  8 +++
 arch/arm/mach-uniphier/arm64/mem_map.c| 28 +
 arch/arm/mach-uniphier/board_late_init.c  |  2 +-
 arch/arm/mach-uniphier/boards.c   | 25 
 arch/arm/mach-uniphier/boot-mode/Makefile |  1 +
 arch/arm/mach-uniphier/boot-mode/boot-device.h|  2 +
 arch/arm/mach-uniphier/boot-mode/boot-mode-ld20.c | 77 +++
 arch/arm/mach-uniphier/boot-mode/boot-mode.c  |  4 ++
 arch/arm/mach-uniphier/boot-mode/cmd_pinmon.c |  5 ++
 arch/arm/mach-uniphier/cpu_info.c |  2 +-
 arch/arm/mach-uniphier/dram/Makefile  |  1 +
 arch/arm/mach-uniphier/dram/umc-ld20.c| 14 +
 arch/arm/mach-uniphier/early-clk/Makefile |  1 +
 arch/arm/mach-uniphier/early-clk/early-clk-ld20.c | 30 +
 arch/arm/mach-uniphier/init.h |  3 +
 arch/arm/mach-uniphier/init/Makefile  |  1 +
 arch/arm/mach-uniphier/init/init-ld20.c   | 55 
 arch/arm/mach-uniphier/init/init.c|  5 ++
 arch/arm/mach-uniphier/memconf/Makefile   |  1 +
 arch/arm/mach-uniphier/memconf/memconf-pxs2.c |  3 +
 arch/arm/mach-uniphier/sbc/Makefile   |  1 +
 arch/arm/mach-uniphier/sg-regs.h  |  3 +-
 configs/uniphier_ld20_defconfig   | 28 +
 include/configs/uniphier.h| 37 +--
 26 files changed, 335 insertions(+), 8 deletions(-)
 create mode 100644 arch/arm/mach-uniphier/arm64/Makefile
 create mode 100644 arch/arm/mach-uniphier/arm64/mem_map.c
 create mode 100644 arch/arm/mach-uniphier/boot-mode/boot-mode-ld20.c
 create mode 100644 arch/arm/mach-uniphier/dram/umc-ld20.c
 create mode 100644 arch/arm/mach-uniphier/early-clk/early-clk-ld20.c
 create mode 100644 arch/arm/mach-uniphier/init/init-ld20.c
 create mode 100644 configs/uniphier_ld20_defconfig

diff --git a/arch/arm/mach-uniphier/Kconfig b/arch/arm/mach-uniphier/Kconfig
index 4724af5..87d1675 100644
--- a/arch/arm/mach-uniphier/Kconfig
+++ b/arch/arm/mach-uniphier/Kconfig
@@ -23,6 +23,11 @@ config ARCH_UNIPHIER_PRO5_PXS2_LD6B
bool "UniPhier PH1-Pro5/ProXstream2/PH1-LD6b SoC"
select CPU_V7
 
+config ARCH_UNIPHIER_LD20
+   bool "UniPhier PH1-LD20 SoC"
+   select ARM64
+   select SPL_SEPARATE_BSS
+
 endchoice
 
 config ARCH_UNIPHIER_LD4
diff --git a/arch/arm/mach-uniphier/Makefile b/arch/arm/mach-uniphier/Makefile
index 35edca1..774ea99 100644
--- a/arch/arm/mach-uniphier/Makefile
+++ b/arch/arm/mach-uniphier/Makefile
@@ -31,3 +31,4 @@ obj-$(CONFIG_MICRO_SUPPORT_CARD) += micro-support-card.o
 obj-$(CONFIG_DEBUG_UART_UNIPHIER) += debug-uart/
 
 obj-$(CONFIG_CPU_V7) += arm32/
+obj-$(CONFIG_ARM64) += arm64/
diff --git a/arch/arm/mach-uniphier/arm64/Makefile 
b/arch/arm/mach-uniphier/arm64/Makefile
new file mode 100644
index 000..3e69eab
--- /dev/null
+++ b/arch/arm/mach-uniphier/arm64/Makefile
@@ -0,0 +1,8 @@
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj- += dummy.o
+ifndef CONFIG_SPL_BUILD
+obj-y += mem_map.o
+endif
diff --git a/arch/arm/mach-uniphier/arm64/mem_map.c 
b/arch/arm/mach-uniphier/arm64/mem_map.c
new file mode 100644
index 000..74ef919
--- /dev/null
+++ b/arch/arm/mach-uniphier/arm64/mem_map.c
@@ -0,0 +1,28 @@
+/*
+ * Copyright (C) 2016 Masahiro Yamada 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+
+static struct mm_region uniphier_mem_map[] = {
+   {
+   .base = 0x,
+   .size = 0x8000,
+   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
+PTE_BLOCK_NON_SHARE |
+PTE_BLOCK_PXN | PTE_BLOCK_UXN
+   },
+   {
+   .base = 0x8000,
+   .size = 0xc000,
+   .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
+PTE_BLOCK_INNER_SHARE
+   },
+   { /* sentinel */ }
+};
+
+struct mm_region *mem_map = uniphier_mem_map;
diff --git a/arch/arm/mach-uniphier/board_late_init.c 
b/arch/arm/mach-uniphier/board_late_init.c
index 6e2008c..a440a7e 100644
--- a/arch/arm/mach-uniphier/board_late_init.c
+++ b/arch/arm/mach-uniphier/board_late_init.c
@@ -36,7 +36,7 @@ struct uniphier_fdt_file {
 static const struct uniphier_fdt_file uniphier_fdt_files[] = {
{ "socionext,ph1-ld4-ref", "uniphier-ph1-ld4-ref.dtb", },
{ "socionext,ph1-ld6b-ref", "uniphier-ph1-ld6b-ref.dtb", },
-   { "socionext,ph1-ld10-ref", "uniphier-ph1-ld10-ref.dtb", },
+   { "socionext,ph1-ld20-ref", 

[U-Boot] [PATCH] cosmetic: Fix typos "privide"

[Masahiro Yamada]

Signed-off-by: Masahiro Yamada 
---

 arch/arm/mach-uniphier/clk/clk-ld4.c  | 2 +-
 arch/arm/mach-uniphier/clk/clk-pro4.c | 2 +-
 arch/arm/mach-uniphier/clk/clk-pro5.c | 2 +-
 arch/arm/mach-uniphier/clk/clk-pxs2.c | 2 +-
 arch/arm/mach-uniphier/early-clk/early-clk-ld4.c  | 2 +-
 arch/arm/mach-uniphier/early-clk/early-clk-pro5.c | 2 +-
 arch/arm/mach-uniphier/early-clk/early-clk-pxs2.c | 2 +-
 lib/Kconfig   | 2 +-
 8 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-uniphier/clk/clk-ld4.c 
b/arch/arm/mach-uniphier/clk/clk-ld4.c
index f11fb53..8744d26 100644
--- a/arch/arm/mach-uniphier/clk/clk-ld4.c
+++ b/arch/arm/mach-uniphier/clk/clk-ld4.c
@@ -27,7 +27,7 @@ void uniphier_ld4_clk_init(void)
writel(tmp, SC_RSTCTRL);
readl(SC_RSTCTRL); /* dummy read */
 
-   /* privide clocks */
+   /* provide clocks */
tmp = readl(SC_CLKCTRL);
 #ifdef CONFIG_UNIPHIER_ETH
tmp |= SC_CLKCTRL_CEN_ETHER;
diff --git a/arch/arm/mach-uniphier/clk/clk-pro4.c 
b/arch/arm/mach-uniphier/clk/clk-pro4.c
index b163e3c..8746d7d 100644
--- a/arch/arm/mach-uniphier/clk/clk-pro4.c
+++ b/arch/arm/mach-uniphier/clk/clk-pro4.c
@@ -38,7 +38,7 @@ void uniphier_pro4_clk_init(void)
readl(SC_RSTCTRL2); /* dummy read */
 #endif
 
-   /* privide clocks */
+   /* provide clocks */
tmp = readl(SC_CLKCTRL);
 #ifdef CONFIG_USB_XHCI_UNIPHIER
tmp |= SC_CLKCTRL_CEN_USB31 | SC_CLKCTRL_CEN_USB30 |
diff --git a/arch/arm/mach-uniphier/clk/clk-pro5.c 
b/arch/arm/mach-uniphier/clk/clk-pro5.c
index 628f5c8..823bb06 100644
--- a/arch/arm/mach-uniphier/clk/clk-pro5.c
+++ b/arch/arm/mach-uniphier/clk/clk-pro5.c
@@ -31,7 +31,7 @@ void uniphier_pro5_clk_init(void)
readl(SC_RSTCTRL2); /* dummy read */
 #endif
 
-   /* privide clocks */
+   /* provide clocks */
tmp = readl(SC_CLKCTRL);
 #ifdef CONFIG_USB_XHCI_UNIPHIER
tmp |= SC_CLKCTRL_CEN_USB31 | SC_CLKCTRL_CEN_USB30 |
diff --git a/arch/arm/mach-uniphier/clk/clk-pxs2.c 
b/arch/arm/mach-uniphier/clk/clk-pxs2.c
index 8548353..76bf856 100644
--- a/arch/arm/mach-uniphier/clk/clk-pxs2.c
+++ b/arch/arm/mach-uniphier/clk/clk-pxs2.c
@@ -34,7 +34,7 @@ void uniphier_pxs2_clk_init(void)
readl(SC_RSTCTRL2); /* dummy read */
 #endif
 
-   /* privide clocks */
+   /* provide clocks */
tmp = readl(SC_CLKCTRL);
 #ifdef CONFIG_USB_XHCI_UNIPHIER
tmp |= SC_CLKCTRL_CEN_USB31 | SC_CLKCTRL_CEN_USB30 |
diff --git a/arch/arm/mach-uniphier/early-clk/early-clk-ld4.c 
b/arch/arm/mach-uniphier/early-clk/early-clk-ld4.c
index c98081f..b6e8b64 100644
--- a/arch/arm/mach-uniphier/early-clk/early-clk-ld4.c
+++ b/arch/arm/mach-uniphier/early-clk/early-clk-ld4.c
@@ -24,7 +24,7 @@ int uniphier_ld4_early_clk_init(const struct 
uniphier_board_data *bd)
writel(tmp, SC_RSTCTRL);
readl(SC_RSTCTRL); /* dummy read */
 
-   /* privide clocks */
+   /* provide clocks */
tmp = readl(SC_CLKCTRL);
tmp |= SC_CLKCTRL_CEN_UMC | SC_CLKCTRL_CEN_SBC | SC_CLKCTRL_CEN_PERI;
writel(tmp, SC_CLKCTRL);
diff --git a/arch/arm/mach-uniphier/early-clk/early-clk-pro5.c 
b/arch/arm/mach-uniphier/early-clk/early-clk-pro5.c
index 5fc8cd0..c41a8ea 100644
--- a/arch/arm/mach-uniphier/early-clk/early-clk-pro5.c
+++ b/arch/arm/mach-uniphier/early-clk/early-clk-pro5.c
@@ -26,7 +26,7 @@ int uniphier_pro5_early_clk_init(const struct 
uniphier_board_data *bd)
writel(tmp, SC_RSTCTRL4);
readl(SC_RSTCTRL); /* dummy read */
 
-   /* privide clocks */
+   /* provide clocks */
tmp = readl(SC_CLKCTRL);
tmp |= SC_CLKCTRL_CEN_SBC | SC_CLKCTRL_CEN_PERI;
writel(tmp, SC_CLKCTRL);
diff --git a/arch/arm/mach-uniphier/early-clk/early-clk-pxs2.c 
b/arch/arm/mach-uniphier/early-clk/early-clk-pxs2.c
index 92b2dcb..665ecd5 100644
--- a/arch/arm/mach-uniphier/early-clk/early-clk-pxs2.c
+++ b/arch/arm/mach-uniphier/early-clk/early-clk-pxs2.c
@@ -30,7 +30,7 @@ int uniphier_pxs2_early_clk_init(const struct 
uniphier_board_data *bd)
writel(tmp, SC_RSTCTRL4);
readl(SC_RSTCTRL4); /* dummy read */
 
-   /* privide clocks */
+   /* provide clocks */
tmp = readl(SC_CLKCTRL);
tmp |= SC_CLKCTRL_CEN_SBC | SC_CLKCTRL_CEN_PERI;
writel(tmp, SC_CLKCTRL);
diff --git a/lib/Kconfig b/lib/Kconfig
index 7a45336..2b97c2b 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -16,7 +16,7 @@ config USE_PRIVATE_LIBGCC
depends on HAVE_PRIVATE_LIBGCC
help
  This option allows you to use the built-in libgcc implementation
- of U-Boot instead of the one privided by the compiler.
+ of U-Boot instead of the one provided by the compiler.
  If unsure, say N.
 
 config SYS_HZ
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de

[U-Boot] [PATCH] ARM: uniphier: rename function names ph1_* to uniphier_*

[Masahiro Yamada]

Eliminate the "ph1"_ prefixes from function names because "uniphier_"
describes the SoC familiy better.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/mach-uniphier/arm32/debug_ll.S| 28 +++
 arch/arm/mach-uniphier/bcu/bcu-ld4.c   |  2 +-
 arch/arm/mach-uniphier/bcu/bcu-sld3.c  |  2 +-
 arch/arm/mach-uniphier/board_early_init_f.c| 28 +++
 arch/arm/mach-uniphier/boards.c| 34 
 arch/arm/mach-uniphier/boot-mode/boot-device.h | 16 ++--
 arch/arm/mach-uniphier/boot-mode/boot-mode-ld4.c   |  4 +-
 arch/arm/mach-uniphier/boot-mode/boot-mode-pro5.c  |  4 +-
 arch/arm/mach-uniphier/boot-mode/boot-mode-pxs2.c  |  4 +-
 arch/arm/mach-uniphier/boot-mode/boot-mode-sld3.c  |  4 +-
 arch/arm/mach-uniphier/boot-mode/boot-mode.c   |  8 +-
 arch/arm/mach-uniphier/boot-mode/cmd_pinmon.c  |  8 +-
 arch/arm/mach-uniphier/clk/clk-ld4.c   |  2 +-
 arch/arm/mach-uniphier/clk/clk-pro4.c  |  2 +-
 arch/arm/mach-uniphier/clk/clk-pro5.c  |  2 +-
 arch/arm/mach-uniphier/clk/clk-pxs2.c  |  2 +-
 arch/arm/mach-uniphier/dram/ddrphy-ld4.c   |  3 +-
 arch/arm/mach-uniphier/dram/ddrphy-regs.h  |  3 +-
 arch/arm/mach-uniphier/dram/umc-ld4.c  |  4 +-
 arch/arm/mach-uniphier/dram/umc-pro4.c |  4 +-
 arch/arm/mach-uniphier/dram/umc-pxs2.c |  2 +-
 arch/arm/mach-uniphier/dram/umc-sld8.c |  4 +-
 arch/arm/mach-uniphier/early-clk/early-clk-ld4.c   |  2 +-
 arch/arm/mach-uniphier/early-clk/early-clk-pro5.c  |  2 +-
 arch/arm/mach-uniphier/early-clk/early-clk-pxs2.c  |  2 +-
 .../early-pinctrl/early-pinctrl-sld3.c |  2 +-
 arch/arm/mach-uniphier/init.h  | 94 +++---
 arch/arm/mach-uniphier/init/init-ld4.c | 14 ++--
 arch/arm/mach-uniphier/init/init-pro4.c| 12 +--
 arch/arm/mach-uniphier/init/init-pro5.c|  6 +-
 arch/arm/mach-uniphier/init/init-pxs2.c| 10 +--
 arch/arm/mach-uniphier/init/init-sld3.c| 16 ++--
 arch/arm/mach-uniphier/init/init-sld8.c| 14 ++--
 arch/arm/mach-uniphier/init/init.c | 12 +--
 arch/arm/mach-uniphier/memconf/memconf-pxs2.c  |  2 +-
 arch/arm/mach-uniphier/memconf/memconf-sld3.c  |  2 +-
 arch/arm/mach-uniphier/pinctrl/pinctrl-ld4.c   |  2 +-
 arch/arm/mach-uniphier/pinctrl/pinctrl-ld6b.c  |  2 +-
 arch/arm/mach-uniphier/pinctrl/pinctrl-pro4.c  |  2 +-
 arch/arm/mach-uniphier/pinctrl/pinctrl-pro5.c  |  2 +-
 arch/arm/mach-uniphier/pinctrl/pinctrl-pxs2.c  |  2 +-
 arch/arm/mach-uniphier/pinctrl/pinctrl-sld3.c  |  2 +-
 arch/arm/mach-uniphier/pinctrl/pinctrl-sld8.c  |  2 +-
 arch/arm/mach-uniphier/pll/pll-init-ld4.c  |  2 +-
 arch/arm/mach-uniphier/pll/pll-init-pro4.c |  2 +-
 arch/arm/mach-uniphier/pll/pll-init-sld3.c |  2 +-
 arch/arm/mach-uniphier/pll/pll-init-sld8.c |  2 +-
 arch/arm/mach-uniphier/pll/pll-spectrum-ld4.c  |  2 +-
 arch/arm/mach-uniphier/pll/pll-spectrum-sld3.c |  2 +-
 arch/arm/mach-uniphier/sbc/sbc-admulti.c   |  2 +-
 arch/arm/mach-uniphier/sbc/sbc-savepin.c   |  2 +-
 51 files changed, 197 insertions(+), 193 deletions(-)

diff --git a/arch/arm/mach-uniphier/arm32/debug_ll.S 
b/arch/arm/mach-uniphier/arm32/debug_ll.S
index 5db7427..76631f2 100644
--- a/arch/arm/mach-uniphier/arm32/debug_ll.S
+++ b/arch/arm/mach-uniphier/arm32/debug_ll.S
@@ -29,7 +29,7 @@ ENTRY(debug_ll_init)
 #if defined(CONFIG_ARCH_UNIPHIER_SLD3)
 #define UNIPHIER_SLD3_UART_CLK 36864000
cmp r1, #0x25
-   bne ph1_sld3_end
+   bne sld3_end
 
sg_set_pinsel   64, 1, 4, 4, r0, r1 @ TXD0 -> TXD0
 
@@ -45,12 +45,12 @@ ENTRY(debug_ll_init)
ldr r3, =DIV_ROUND(UNIPHIER_SLD3_UART_CLK, 16 * BAUDRATE)
 
b   init_uart
-ph1_sld3_end:
+sld3_end:
 #endif
 #if defined(CONFIG_ARCH_UNIPHIER_LD4)
 #define UNIPHIER_LD4_UART_CLK  36864000
cmp r1, #0x26
-   bne ph1_ld4_end
+   bne ld4_end
 
ldr r0, =SG_IECTRL
ldr r1, [r0]
@@ -62,12 +62,12 @@ ph1_sld3_end:
ldr r3, =DIV_ROUND(UNIPHIER_LD4_UART_CLK, 16 * BAUDRATE)
 
b   init_uart
-ph1_ld4_end:
+ld4_end:
 #endif
 #if defined(CONFIG_ARCH_UNIPHIER_PRO4)
 #define UNIPHIER_PRO4_UART_CLK 73728000
cmp r1, #0x28
-   bne ph1_pro4_end
+   bne pro4_end
 
sg_set_pinsel   128, 0, 4, 8, r0, r1@ TXD0 -> TXD0
 
@@ -83,12 +83,12 @@ ph1_ld4_end:
ldr r3, =DIV_ROUND(UNIPHIER_PRO4_UART_CLK, 16 * BAUDRATE)
 
b   init_uart
-ph1_pro4_end:
+pro4_end:
 #endif
 #if defined(CONFIG_ARCH_UNIPHIER_SLD8)
 #define UNIPHIER_SLD8_UART_CLK  

[U-Boot] Problem with sf write on Arria 5.

[Bakhvalov, Denis (Nokia - PL/Wroclaw)]

Dear U-Boot support,

I'm migrating to new U-Boot version from 2013 and now have problem with writing 
to the flash.

I have custom board with Altera Arria 5 SocFpga.
U-Boot version: 2016.03-rc1
My flash:
SF: Detected S25FL512S_256K with page size 512 Bytes, erase size 256 KiB, total 
64 MiB

I'm rewriting the flash with the image that I downloaded from tftp.
#> tftp 0x1B00 flash.bin
Then I'm trying to write it to the flash:
#> sf erase ...
#> sf write ...
After that if I try to mount Ubi partition (this is read operation) I receive 
failures (usually checksum errors).
So, the problem is that when I'm writing some data to flash and reading it back 
the data is corrupted.
I'm almost sure that there is no issue with reading, because previously I was 
able to read big amount of data successfully (for example, reading OS image and 
booting it).

With previous version (2013) there is no such issue.
With the same sequence of commands I was able to update entire flash.

I was able to reduce this problem to a smaller one.
I'm checking consistency of write operation by writing zipped file (3 KB):
#> tftp 0x1B00 file.zip
#> sf erase  
#> sf write   
#> sf read   
#> unzip  

And sometimes I can see:
Uncompressed size: 524288 = 0x8 (success)
but more often:
Error: inflate() returned -3 (data was corrupted)

So, the problem appears to be occasional.

When I'm comparing the original data with the data that I've read from flash I 
can see the blocks of 256 bytes were not written (0x).
For example:
Original data:
1b000200: c62e214e 0e48a4c9 19038ec8 37531cfdN!H...S7
1b000210: 8f1c7048 f60b861f e9482d5c 857404e8Hp..\-H...t.
1b000220: ef3996c1 fd02b093 2ee8d1f6 679ab03d..9.=..g
1b000230: e6c739f4 194eaec7 383ddca8 6f90a2ad.9N...=8...o
... and so on until (1b000300)
Stored data:
1f000200:    
1f000210:    
1f000220:    
1f000230:    
... and so on until (1f000300)

I already checked difference in QSPI registers (base address: 0xFF705000) 
between two versions of U-Boot, but haven't found any clue yet.
If needed I can provide this diff.

All hints are welcome.

Best regards,
Denis Bakhvalov

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

[U-Boot] [PATCH v1] tpm: Fix uclass_first_device error handling

[Mario Six]

uclass_first_device might return NULL for the device despite a zero
return code. Currently, this might lead to null pointer dereferencing,
since the returned device is not properly checked.

Hence, always check if the device returned from uclass_first_device is
NULL and return -ENODEV if it is.

Signed-off-by: Mario Six 
---
 lib/tpm.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/lib/tpm.c b/lib/tpm.c
index f428d45..42aea0a 100644
--- a/lib/tpm.c
+++ b/lib/tpm.c
@@ -245,6 +245,8 @@ static uint32_t tpm_sendrecv_command(const void *command,
ret = uclass_first_device(UCLASS_TPM, );
if (ret)
return ret;
+   if (!dev)
+   return -ENODEV;
err = tpm_xfer(dev, command, tpm_command_size(command),
   response, _length);

@@ -262,8 +264,10 @@ int tpm_init(void)
struct udevice *dev;

err = uclass_first_device(UCLASS_TPM, );
-   if (err || !dev)
+   if (err)
return err;
+   if (!dev)
+   return -ENODEV;
return tpm_open(dev);
 }

--
2.7.0.GIT

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

Re: [U-Boot] [PATCH 0/6] Add Pine64 support

[Hans de Goede]

Hi,

On 29-03-16 18:08, Alexander Graf wrote:



On 29.03.16 17:45, Hans de Goede wrote:

Hi,

On 03/29/2016 05:29 PM, Alexander Graf wrote:

The Pine64 is a kickstarter backed SBC that runs on the Allwinner A64
SoC.
This SoC can run AArch64 code, so this patch set lifts all arm version
indepenent sunxi code into a mach directory and builds the A64 code
as armv8 (aarch64) code.

With these patches applied, I can successfully boot my 1GB Pine64+ board
with an openSUSE EFI image.


Can you provide some quick instructions on how to test this ? Bonus
point for a link to a boot0.bin which I can dd to a sdcard and use
with a u-boot.bin build with these patches.


Sure. Grab these all the files in this directory:

   http://csgraf.de/agraf/pine64

Then do

   $ gcc pine64_image.c -o pine64_image
   $ cat bl31.bin /u-boot.bin > bl31uboot.bin
   $ ./pine64_image scp.bin bl31uboot.bin u-boot.img
   $ dd if=boot0.bin of=/dev/mmcblk0 seek=16
   $ dd if=u-boot.img of=/dev/mmcblk0 seek=80

That should give you a working system. The scp.bin and boot0.bin are
from the Allwinner binary distribution. ATF (bl31.bin) is built from
these sources:


https://build.opensuse.org/package/show/devel:ARM:Factory:Contrib:Pine64/firmware-pine64


Cool thanks. I'll give this a try this weekend.

Regards,

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

[U-Boot] [RFC v1 PATCH 1/1] mpc85xx: Enable pre-relocation malloc for MPC85xx

[Mario Six]

To enable DM on MPC85xx, we need pre-relocation malloc, which is
implemented in this patch.

Signed-off-by: Mario Six 
Cc: York Sun 
Cc: Simon Glass 
---
 arch/powerpc/cpu/mpc85xx/cpu_init_early.c |  8 
 arch/powerpc/cpu/mpc85xx/start.S  | 28 
 2 files changed, 28 insertions(+), 8 deletions(-)

diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init_early.c 
b/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
index 235a635..e6e1688 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
@@ -82,7 +82,6 @@ void setup_ifc(void)
 void cpu_init_early_f(void *fdt)
 {
u32 mas0, mas1, mas2, mas3, mas7;
-   int i;
 #ifdef CONFIG_SYS_FSL_ERRATUM_P1010_A003549
ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
 #endif
@@ -95,13 +94,6 @@ void cpu_init_early_f(void *fdt)
/* Pointer is writable since we allocated a register for it */
gd = (gd_t *) (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_GBL_DATA_OFFSET);

-   /*
-* Clear initial global data
-*   we don't use memset so we can share this code with NAND_SPL
-*/
-   for (i = 0; i < sizeof(gd_t); i++)
-   ((char *)gd)[i] = 0;
-
 #ifdef CONFIG_QEMU_E500
/*
 * CONFIG_SYS_CCSRBAR_PHYS below may use gd->fdt_blob on ePAPR systems,
diff --git a/arch/powerpc/cpu/mpc85xx/start.S b/arch/powerpc/cpu/mpc85xx/start.S
index d867e2a..e6b5203 100644
--- a/arch/powerpc/cpu/mpc85xx/start.S
+++ b/arch/powerpc/cpu/mpc85xx/start.S
@@ -1152,6 +1152,34 @@ _start_cont:
/* Setup the stack in initial RAM,could be L2-as-SRAM or L1 dcache*/
lis r3,(CONFIG_SYS_INIT_RAM_ADDR)@h
ori r3,r3,((CONFIG_SYS_INIT_SP_OFFSET-16)&~0xf)@l /* Align to 16 */
+
+#ifdef CONFIG_SYS_MALLOC_F_LEN
+   /* Leave 16+ byte for back chain termination and NULL return address */
+   subir3,r3,((CONFIG_SYS_MALLOC_F_LEN+16+15)&~0xf)
+
+   /* End of RAM */
+   lis r4,(CONFIG_SYS_INIT_RAM_ADDR)@h
+   ori r4,r4,(CONFIG_SYS_INIT_RAM_SIZE)@l
+
+   li  r0,0
+
+1: subir4,r4,4
+   stw r0,0(r4)
+   cmplw   r4,r3
+   bne 1b
+
+   lis r4,(CONFIG_SYS_INIT_RAM_ADDR)@h
+   ori r4,r4,(CONFIG_SYS_GBL_DATA_OFFSET)@l
+
+   addir3,r3,16/* Pre-relocation malloc area */
+   stw r3,GD_MALLOC_BASE(r4)
+   subir3,r3,16
+
+   /* Fix issue with exception handler alignment */
+   nop
+   nop
+   nop
+#endif
li  r0,0
stw r0,0(r3)/* Terminate Back Chain */
stw r0,+4(r3)   /* NULL return address. */
--
2.7.0.GIT

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

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

[Qianyu Gong]

Hi Scott,

> -Original Message-
> From: Scott Wood [mailto:o...@buserror.net]
> Sent: Wednesday, March 30, 2016 4:45 AM
> To: Qianyu Gong ; u-boot@lists.denx.de; york sun
> 
> Cc: Mingkai Hu 
> Subject: Re: [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A with QSPI
> enabled
> 
> On Fri, 2016-03-11 at 10:18 +, Qianyu Gong wrote:
> > Hi Scott,
> >
> > > -Original Message-
> > > From: Scott Wood [mailto:o...@buserror.net]
> > > Sent: Tuesday, February 23, 2016 8:12 AM
> > > To: Qianyu Gong ; u-boot@lists.denx.de; york
> > > sun 
> > > Cc: Mingkai Hu 
> > > Subject: Re: [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A
> > > with QSPI enabled
> > >
> > > On Mon, 2016-02-22 at 18:05 +0800, Gong Qianyu wrote:
> > > > QSPI and IFC are pin-multiplexed on LS1043A. So if QSPI is
> > > > enabled, IFC should be disabled.
> > > > But just disable IFC driver in LS1043A Linux is not enough because
> > > > mdio-mux will access IFC address space -- actually it accesses
> > > > FPGA which is connected to IFC CS3. So disable the whole IFC node
> > > > in Linux device tree.
> > > >
> > > > Signed-off-by: Gong Qianyu 
> > > >
> > > > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > > > b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > > > index 4e4861d..5bb3048 100644
> > > > --- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > > > +++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > > > @@ -204,4 +204,11 @@ void ft_cpu_setup(void *blob, bd_t *bd)
> > > > #ifdef
> > > > CONFIG_FSL_LSCH3
> > > > fdt_fixup_smmu(blob);
> > > >  #endif
> > > > +
> > > > +#ifdef CONFIG_LS1043A
> > > > +#ifdef CONFIG_FSL_QSPI
> > > > +   do_fixup_by_compat(blob, "fsl,ifc",
> > > > +  "status", "disabled", 8 + 1, 1); #endif
> > > > #endif
> > > >  }
> > >
> > > This muxing is done at runtime, right?  It isn't a case of the board
> > > hardwiring one or the other?  In that case, it should be handled at
> > > runtime here as well.
> > >   At a
> > > minimum, allow the user to use hwconfig to choose which they want to
> > > be accessible.  Ideally there would be something in the device tree
> > > to list the reason(s) for a device being disabled, so the OS knows
> > > it can regard the device as being enabled if it knows about and
> > > enables them all.
> > >
> > > -Scott
> >
> > Sorry for the late reply. We have been asking the silicon team for the
> > details of the pin muxing these days.
> > The conclusion is that all IFC interfaces(cs0/cs1/cs2) are disabled as
> > long as QSPI is enabled on LS1043AQDS board.
> > As I know, this muxing won't be handled in kernel. Since IFC is
> > disabled in U-Boot, IFC node would better be disabled in kernel as
> > well.
> > Also in such cases, users have no other choice.
> 
> Why should the user not have a choice to choose IFC over QSPI?  Where is the
> muxing configured?
> 
> -Scott

Because this muxing can't be changed at runtime.
Two ways so far to configure it:
1. SW6[1-4] switches on ls1043aqds board.
2. Modify QIXIS board config registers and reset the board.


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