Re: [U-Boot] [PATCH] mx6sabre_common: Allow booting a FSL 3.10 kernel

[Stefano Babic]

Hi Otavio, hi Fabio,

On 25/11/2013 17:21, Otavio Salvador wrote:
 On Mon, Nov 25, 2013 at 1:54 PM, Fabio Estevam
 fabio.este...@freescale.com wrote:
 Currently the booting of a 3.10 kernel fails, as explained by Jason Liu [1]:

 Let me explain it:
 since we defined the fdt_high=0x at 
 include/configs/mx6qsabre_common.h,
 which means we disable the fdt re-allocation, which you can see when boot up:

 ## Flattened Device Tree blob at 1100
Booting using the fdt blob at 0x1100
Using Device Tree in place at 1100, end 1800e37e

 The FDT blob will be placed at DDR physical addr: 0x1100. When Linux 
 kernel
 Boot up, it will decompress the compressed kernel image and place the
 decompressed kernel image at the low end of the DDR memory and start running
 from it. If the decompressed kernel image is bigger for example than 16M, it 
 may
 over written the fdt blob which u-boot loaded to the DDR memory @0x1100 
 with
 fdt_addr=0x1100.

 o expand the fdt_addr from 0x1100 to 0x1800, which can avoid the
 override, since we will not likely have one kernel image larger than 128MB.

 The other solution is to enable the FDT blob re-allocation by remove the
 fdt_high=0x

 Use the second approach to enable the boot of a FSL 3.10 kernel.

 [1] http://marc.info/?l=u-bootm=138519609402384w=2

 Signed-off-by: Fabio Estevam fabio.este...@freescale.com
 
 My patch changed the load address for the device tree blog, as
 explained by Liu, it avoids an extra copy which may impact in boot
 speed.

Maybe I am missing something. If I have well understood, the additional
copy is for the DT only. That means 20-30 KB, I suppose. Which is the
improvement in boot time if we let that the FDT is copied one more time
? Is this time maybe negligible (I suppose yes, but I have no real data) ?

Avoiding the additional copy is a sort of optimization, that anybody, if
wanted, can do changing the running environment. The default environment
should ensure that the kernel boots in any conditions.

IMHO it is better to remove fdt_addr at all as proposed by Fabio, and
let the system doing the job - excepted we can say we have a *real* big
improvement dropping the FDT relocation.

Best regards,
Stefano Babic


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

[U-Boot] [PATCH 1/2][v2] powerpc: mmc: Add corenet devices support in esdhc spl

[Priyanka Jain]

Existing eSDHC SPL framework assumes booting from sd-image
with boot_format header which contains final u-boot Image
offset and size. No such header is present in case of
corenet devices like T1040 as corenet deivces use PBI-RCW
based intialization.

So, for corenet deives, SPL bootloader use values provided
at compilation time. These values can be defined in board
specific config file.

Signed-off-by: Priyanka Jain priyanka.j...@freescale.com
---
Changes for v2:
Updated description based on Sun York's inputs

 drivers/mmc/fsl_esdhc_spl.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/mmc/fsl_esdhc_spl.c b/drivers/mmc/fsl_esdhc_spl.c
index 65c52a2..8fc263f 100644
--- a/drivers/mmc/fsl_esdhc_spl.c
+++ b/drivers/mmc/fsl_esdhc_spl.c
@@ -42,6 +42,10 @@ void __noreturn mmc_boot(void)
hang();
}
 
+#ifdef CONFIG_FSL_CORENET
+   offset = CONFIG_SYS_MMC_U_BOOT_OFFS;
+   code_len = CONFIG_SYS_MMC_U_BOOT_SIZE;
+#else
blklen = mmc-read_bl_len;
tmp_buf = malloc(blklen);
if (!tmp_buf) {
@@ -91,6 +95,7 @@ void __noreturn mmc_boot(void)
/*
* Load U-Boot image from mmc into RAM
*/
+#endif
blk_start = ALIGN(offset, mmc-read_bl_len) / mmc-read_bl_len;
blk_cnt = ALIGN(code_len, mmc-read_bl_len) / mmc-read_bl_len;
err = mmc-block_dev.block_read(0, blk_start, blk_cnt,
-- 
1.7.4.1



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

[U-Boot] [PATCH 1/2][v2] powerpc: spiflash:Add corenet devices support in eSPI SPL

[Priyanka Jain]

Existing eSPI SPL framework assumes booting from spi-image
with boot_format header which contains final u-boot Image
offset and size. No such header is present in case of
corenet devices like T1040 as corenet deivces use PBI-RCW
based intialization.

So, for corenet deives, SPL bootloader use values provided
at compilation time. These values can be defined in board
specific config file.

Signed-off-by: Priyanka Jain priyanka.j...@freescale.com
---
Changes for v2:
Updated description based on Sun York's inputs

 drivers/mtd/spi/fsl_espi_spl.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/spi/fsl_espi_spl.c b/drivers/mtd/spi/fsl_espi_spl.c
index 6263d8c..e5ac79b 100644
--- a/drivers/mtd/spi/fsl_espi_spl.c
+++ b/drivers/mtd/spi/fsl_espi_spl.c
@@ -31,6 +31,10 @@ void spi_boot(void)
hang();
}
 
+#ifdef CONFIG_FSL_CORENET
+   offset = CONFIG_SYS_SPI_FLASH_U_BOOT_OFFS;
+   code_len = CONFIG_SYS_SPI_FLASH_U_BOOT_SIZE;
+#else
/*
* Load U-Boot image from SPI flash into RAM
*/
@@ -50,6 +54,7 @@ void spi_boot(void)
code_len = *(u32 *)(buf + ESPI_BOOT_IMAGE_SIZE);
/* Skip spl code */
code_len = code_len - CONFIG_SPL_MAX_SIZE;
+#endif
/* copy code to DDR */
spi_flash_read(flash, offset, code_len,
   (void *)CONFIG_SYS_SPI_FLASH_U_BOOT_DST);
-- 
1.7.4.1



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

[U-Boot] [PATCH v2] .gitignore: ignore spl/ and tpl/ directories except spl/Makefile

[Masahiro Yamada]

Before this commit, output files under tpl/ directry
were not ignored.
This commit fixes this problem.

And we have only one source file under spl/ directory:
 spl/Makefile

So, we can describe .gitignore more simply.

Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
---

Changes in v2:
  - Fix my weird English in commit log
 (in a more simply way - more simply)

 .gitignore | 7 ---
 spl/.gitignore | 4 
 2 files changed, 4 insertions(+), 7 deletions(-)
 delete mode 100644 spl/.gitignore

diff --git a/.gitignore b/.gitignore
index a39bd54..a1f07f0 100644
--- a/.gitignore
+++ b/.gitignore
@@ -59,6 +59,10 @@
 /errlog
 /reloc_off
 
+/spl/
+!/spl/Makefile
+/tpl/
+
 /include/generated/
 /include/spl-autoconf.mk
 /include/tpl-autoconf.mk
@@ -88,6 +92,3 @@ GPATH
 GRTAGS
 GSYMS
 GTAGS
-
-# spl ais files
-/spl/*.ais
diff --git a/spl/.gitignore b/spl/.gitignore
deleted file mode 100644
index 7c88147..000
--- a/spl/.gitignore
+++ /dev/null
@@ -1,4 +0,0 @@
-u-boot-spl
-u-boot-spl.bin
-u-boot-spl.lds
-u-boot-spl.map
-- 
1.8.3.2

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

Re: [U-Boot] [PATCH] cmd_test: fix a compile error on Blackfin

[Masahiro Yamada]

Hello Wolfgang


  Could you resend
  http://patchwork.ozlabs.org/patch/292309/
  in a correct format?
  
  (Or Tom can directly pick it from the ML?)
 
 Of course I can.  Does this patch solve the problem for you?

Yes. It worked for me. Thanks.
(And applied to u-boot/master)

It's OK for now because my motivation is to fix the build error
on blackfin boards.
Although it is true that I am a little concerned about this parts:

#define _STDBOOL_H

#include common.h
#include command.h


Best Regards
Masahiro Yamada

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

[U-Boot] [PATCH] davinci: fix Master Priority Registers location

[Viktar Palstsiuk]

MSTPRI0 (Master Priority 0 Register) sits at 0x01C14110 not at
0x01C14114

Signed-off-by: Viktar Palstsiuk viktar.palsts...@promwad.com
---
 arch/arm/include/asm/arch-davinci/hardware.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/arch-davinci/hardware.h 
b/arch/arm/include/asm/arch-davinci/hardware.h
index 7aaf4bf..27b1844 100644
--- a/arch/arm/include/asm/arch-davinci/hardware.h
+++ b/arch/arm/include/asm/arch-davinci/hardware.h
@@ -478,8 +478,9 @@ struct davinci_syscfg_regs {
dv_reg  rsvd[13];
dv_reg  kick0;
dv_reg  kick1;
-   dv_reg  rsvd1[53];
+   dv_reg  rsvd1[52];
dv_reg  mstpri[3];
+   dv_reg  rsvd2;
dv_reg  pinmux[20];
dv_reg  suspsrc;
dv_reg  chipsig;
-- 
1.8.4.3

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

[U-Boot] [PATCH] ARM: mx6: Remove the FDT loading address to avoid overlaping

[Otavio Salvador]

This patch fixes allow for the DeviceTree and initrd relocation fixing
the boot of FSL 3.10.9-1.0.0-alpha kernel.

This changes following boards:

 - mx6sabreauto
 - mx6sabresd
 - wandboard
 - udoo
 - nitrogen6x
 - cgtqmx6eval

The reasoning, as explained by Hui Liu, is:

,
| The FDT blob will be placed at DDR physical addr: 0x1100. When Linux 
kernel
| Boot up, it will decompress the compressed kernel image and place the 
decompressed
| kernel image at the low end of the DDR memory and start running from it. If 
the
| decompressed kernel image is bigger for example than 16M, it may over written 
the
| fdt blob which u-boot loaded to the DDR memory @0x1100 with 
fdt_addr=0x1100
|
| To expand the fdt_addr from 0x1100 to 0x1800, which can avoid the 
override
| Since we will not likely have one kernel image larger than 128MB.
`

Removing the fdt_high and initrd_high this allows for those to be
relocated.

Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
 include/configs/cgtqmx6eval.h | 2 --
 include/configs/mx6sabre_common.h | 2 --
 include/configs/nitrogen6x.h  | 2 --
 include/configs/udoo.h| 2 --
 include/configs/wandboard.h   | 2 --
 5 files changed, 10 deletions(-)

diff --git a/include/configs/cgtqmx6eval.h b/include/configs/cgtqmx6eval.h
index d5db8f5..48acf50 100644
--- a/include/configs/cgtqmx6eval.h
+++ b/include/configs/cgtqmx6eval.h
@@ -79,8 +79,6 @@
fdt_file= CONFIG_DEFAULT_FDT_FILE \0 \
boot_dir=/boot\0 \
console=ttymxc1\0 \
-   fdt_high=0x\0 \
-   initrd_high=0x\0 \
fdt_addr=0x1100\0 \
boot_fdt=try\0 \
mmcdev=1\0 \
diff --git a/include/configs/mx6sabre_common.h 
b/include/configs/mx6sabre_common.h
index 4b4f640..01acd7f 100644
--- a/include/configs/mx6sabre_common.h
+++ b/include/configs/mx6sabre_common.h
@@ -108,8 +108,6 @@
boot_fdt=try\0 \
ip_dyn=yes\0 \
console= CONFIG_CONSOLE_DEV \0 \
-   fdt_high=0x\0   \
-   initrd_high=0x\0 \
mmcdev= __stringify(CONFIG_SYS_MMC_ENV_DEV) \0 \
mmcpart=1\0 \
mmcroot= CONFIG_MMCROOT  rootwait rw\0 \
diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h
index 3df8de0..93c88c9 100644
--- a/include/configs/nitrogen6x.h
+++ b/include/configs/nitrogen6x.h
@@ -186,8 +186,6 @@
script=boot.scr\0 \
uimage=uImage\0 \
console=ttymxc1\0 \
-   fdt_high=0x\0 \
-   initrd_high=0x\0 \
fdt_file=imx6q-sabrelite.dtb\0 \
fdt_addr=0x1100\0 \
boot_fdt=try\0 \
diff --git a/include/configs/udoo.h b/include/configs/udoo.h
index 78df071..e38a598 100644
--- a/include/configs/udoo.h
+++ b/include/configs/udoo.h
@@ -74,8 +74,6 @@
uimage=uImage\0 \
console=ttymxc1\0 \
splashpos=m,m\0 \
-   fdt_high=0x\0 \
-   initrd_high=0x\0 \
fdt_file= CONFIG_DEFAULT_FDT_FILE \0 \
fdt_addr=0x1100\0 \
boot_fdt=try\0 \
diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h
index 68ff724..8d9b5d8 100644
--- a/include/configs/wandboard.h
+++ b/include/configs/wandboard.h
@@ -118,8 +118,6 @@
uimage=uImage\0 \
console=ttymxc0\0 \
splashpos=m,m\0 \
-   fdt_high=0x\0 \
-   initrd_high=0x\0 \
fdt_file= CONFIG_DEFAULT_FDT_FILE \0 \
fdt_addr=0x1100\0 \
boot_fdt=try\0 \
-- 
1.8.4.3

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

[U-Boot] [PATCH] drivers:power:exynos-tmu: add support for Exynos5260

[Naveen Krishna Chatradhi]

This patch adds support for TMU on Exynos5260
Register bit fields are little different from the previous
versions.

Change-Id: Ibe835abe9cb255d2f8375c8e9e32d32cff19c093
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
---
 arch/arm/include/asm/arch-exynos/tmu.h |   11 +++
 drivers/power/exynos-tmu.c |   25 +++--
 2 files changed, 34 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/arch-exynos/tmu.h 
b/arch/arm/include/asm/arch-exynos/tmu.h
index cad3569..19b8f62 100644
--- a/arch/arm/include/asm/arch-exynos/tmu.h
+++ b/arch/arm/include/asm/arch-exynos/tmu.h
@@ -26,7 +26,11 @@ struct exynos5_tmu_reg {
u32 triminfo_control;
u32 rsvd5[2];
u32 tmu_control;
+#ifdef CONFIG_EXYNOS5260
+   u32 tmu_control1;
+#else
u32 rsvd7;
+#endif
u32 tmu_status;
u32 sampling_internal;
u32 counter_value0;
@@ -41,10 +45,17 @@ struct exynos5_tmu_reg {
u32 past_temp7_4;
u32 past_temp11_8;
u32 past_temp15_12;
+#ifdef CONFIG_EXYNOS5260
+   u32 rsvd15[16];
+#endif
u32 inten;
u32 intstat;
u32 intclear;
+#ifdef CONFIG_EXYNOS5260
+   u32 rsvd31[17];
+#else
u32 rsvd15;
+#endif
u32 emul_con;
 };
 #endif /* __ASM_ARCH_TMU_H */
diff --git a/drivers/power/exynos-tmu.c b/drivers/power/exynos-tmu.c
index 9a093a5..de3ff82 100644
--- a/drivers/power/exynos-tmu.c
+++ b/drivers/power/exynos-tmu.c
@@ -31,7 +31,13 @@
 #define INTEN_RISE01
 #define INTEN_RISE1(1  4)
 #define INTEN_RISE2(1  8)
+
+#ifdef CONFIG_EXYNOS5250
+#define INTEN_FALL0(1  12)
+#else
 #define INTEN_FALL0(1  16)
+#endif
+
 #define INTEN_FALL1(1  20)
 #define INTEN_FALL2(1  24)
 
@@ -43,9 +49,24 @@
 #define INTCLEAR_FALL0 (1  16)
 #define INTCLEAR_FALL1 (1  20)
 #define INTCLEAR_FALL2 (1  24)
+
+#ifdef CONFIG_EXYNOS5260
+#define INTEN_RISE3(1  12)
+#define INTEN_FALL3(1  28)
+#define INTCLEAR_RISE3 (1  12)
+#define INTCLEAR_FALL3 (1  28)
+#endif
+
+#if defined(INTCLEAR_RISE3)  defined(INTCLEAR_FALL3)
 #define INTCLEARALL(INTCLEAR_RISE0 | INTCLEAR_RISE1 | \
-INTCLEAR_RISE2 | INTCLEAR_FALL0 | \
-INTCLEAR_FALL1 | INTCLEAR_FALL2)
+   INTCLEAR_RISE2 | INTCLEAR_RISE3 | \
+   INTCLEAR_FALL0 | INTCLEAR_FALL1 | \
+   INTCLEAR_FALL2 | INTCLEAR_FALL3)
+#else
+#define INTCLEARALL(INTCLEAR_RISE0 | INTCLEAR_RISE1 | \
+   INTCLEAR_RISE2 | INTCLEAR_FALL0 | \
+   INTCLEAR_FALL1 | INTCLEAR_FALL2)
+#endif
 
 /* Tmeperature threshold values for various thermal events */
 struct temperature_params {
-- 
1.7.10.4

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

Re: [U-Boot] [PATCH] ARM: mx6: Remove the FDT loading address to avoid overlaping

[Otavio Salvador]

On Tue, Nov 26, 2013 at 10:11 AM, Tom Rini tr...@ti.com wrote:
 On Tue, Nov 26, 2013 at 09:06:27AM -0200, Otavio Salvador wrote:

 This patch fixes allow for the DeviceTree and initrd relocation fixing
 the boot of FSL 3.10.9-1.0.0-alpha kernel.

 This changes following boards:

  - mx6sabreauto
  - mx6sabresd
  - wandboard
  - udoo
  - nitrogen6x
  - cgtqmx6eval

 The reasoning, as explained by Hui Liu, is:

 ,
 | The FDT blob will be placed at DDR physical addr: 0x1100. When Linux 
 kernel
 | Boot up, it will decompress the compressed kernel image and place the 
 decompressed
 | kernel image at the low end of the DDR memory and start running from it. 
 If the
 | decompressed kernel image is bigger for example than 16M, it may over 
 written the
 | fdt blob which u-boot loaded to the DDR memory @0x1100 with 
 fdt_addr=0x1100
 |
 | To expand the fdt_addr from 0x1100 to 0x1800, which can avoid the 
 override
 | Since we will not likely have one kernel image larger than 128MB.
 `

 Removing the fdt_high and initrd_high this allows for those to be
 relocated.

 I'm going to suggest this is the wrong path.  Once you see i.MX systems
 with  768MB DDR you're going to have initrd/fdt placed into memory
 Linux can't access without HIGHMEM on, and you need the FDT before then.

I didn't catch this case but it is a valid problem, indeed :-(

Fabio/Stefano what is your call here? I think moving it to 128MB is
good for now.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: mx6: Remove the FDT loading address to avoid overlaping

[Tom Rini]

On Tue, Nov 26, 2013 at 09:06:27AM -0200, Otavio Salvador wrote:

 This patch fixes allow for the DeviceTree and initrd relocation fixing
 the boot of FSL 3.10.9-1.0.0-alpha kernel.
 
 This changes following boards:
 
  - mx6sabreauto
  - mx6sabresd
  - wandboard
  - udoo
  - nitrogen6x
  - cgtqmx6eval
 
 The reasoning, as explained by Hui Liu, is:
 
 ,
 | The FDT blob will be placed at DDR physical addr: 0x1100. When Linux 
 kernel
 | Boot up, it will decompress the compressed kernel image and place the 
 decompressed
 | kernel image at the low end of the DDR memory and start running from it. If 
 the
 | decompressed kernel image is bigger for example than 16M, it may over 
 written the
 | fdt blob which u-boot loaded to the DDR memory @0x1100 with 
 fdt_addr=0x1100
 |
 | To expand the fdt_addr from 0x1100 to 0x1800, which can avoid the 
 override
 | Since we will not likely have one kernel image larger than 128MB.
 `
 
 Removing the fdt_high and initrd_high this allows for those to be
 relocated.

I'm going to suggest this is the wrong path.  Once you see i.MX systems
with  768MB DDR you're going to have initrd/fdt placed into memory
Linux can't access without HIGHMEM on, and you need the FDT before then.

-- 
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 0/3] Add support for CM-T335 board

[Ilya Ledvich]

Ping!

On 11/07/2013 07:57 AM, Ilya Ledvich wrote:

This patch series adds support for the Compulab CM-T335 board.
The board is based on TI Sitara AM3352/4 SoC and provides folowing features:
  - 128MB to 512MB DDR3
  - 128MB to 1GB NAND as a main storage
  - Micro SD/MMC card as a secondary storage
  - USB2.0 x4 host ports or USB2.0 x1 OTG port
  - Gigabit Ethernet, WiFi 802.11, Bluetooth, CAN bus, UART
  - LCD/DVI/LVDS display, touchscreen
  - Analog audio

Ilya Ledvich (3):
   cm_t335: add cm_t335 board support
   cm_t335: add support for status LED
   cm_t335: add support for pca9555 i2c gpio extender

  arch/arm/include/asm/arch-am33xx/ddr_defs.h |6 +
  board/compulab/cm_t335/Makefile |   32 +
  board/compulab/cm_t335/cm_t335.c|  162 
  board/compulab/cm_t335/mux.c|  117 +
  board/compulab/cm_t335/spl.c|  110 
  board/compulab/cm_t335/u-boot.lds   |  101 +++
  boards.cfg  |1 +
  include/configs/cm_t335.h   |  182 +++
  8 files changed, 711 insertions(+)
  create mode 100644 board/compulab/cm_t335/Makefile
  create mode 100644 board/compulab/cm_t335/cm_t335.c
  create mode 100644 board/compulab/cm_t335/mux.c
  create mode 100644 board/compulab/cm_t335/spl.c
  create mode 100644 board/compulab/cm_t335/u-boot.lds
  create mode 100644 include/configs/cm_t335.h



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

[U-Boot] [PATCH] rsa: add a more flexible way to support different hash algorithms (e.g. sha256)

[andr...@oetken.name]

I currently need support for rsa-sha256 signatures in u-boot and found out that
the code for signatures is not very generic. Thus adding of different
hash-algorithms for rsa-signatures is not easy to do without copy-pasting the
rsa-code. I attached a patch for how I think it could be better and included
support for rsa-sha256. This is a fast first shot.

diff --git a/common/image-sig.c b/common/image-sig.c
index 973b06d..db15cb6 100644
--- a/common/image-sig.c
+++ b/common/image-sig.c
@@ -14,15 +14,48 @@ DECLARE_GLOBAL_DATA_PTR;
 #endif /* !USE_HOSTCC*/
 #include image.h
 #include rsa.h
+#include rsa-checksum.h

 #define IMAGE_MAX_HASHED_NODES100

+
+struct checksum_algo checksum_algos[] = {
+  {
+sha1,
+SHA1_SUM_LEN,
+#if IMAGE_ENABLE_SIGN
+EVP_sha1,
+#else
+sha1_calculate,
+padding_sha1_rsa2048,
+#endif
+  },
+  {
+sha256,
+SHA256_SUM_LEN,
+#if IMAGE_ENABLE_SIGN
+EVP_sha256,
+#else
+sha256_calculate,
+padding_sha256_rsa2048,
+#endif
+  }
+};
+
 struct image_sig_algo image_sig_algos[] = {
 {
 sha1,rsa2048,
 rsa_sign,
 rsa_add_verify_data,
 rsa_verify,
+checksum_algos[0],
+},
+{
+sha256,rsa2048,
+rsa_sign,
+rsa_add_verify_data,
+rsa_verify,
+checksum_algos[1],
 }
 };

diff --git a/include/image.h b/include/image.h
index ee6eb8d..47268aa 100644
--- a/include/image.h
+++ b/include/image.h
@@ -822,7 +822,8 @@ int calculate_hash(const void *data, int data_len, const
char *algo,
 # ifdef USE_HOSTCC
 #  define IMAGE_ENABLE_SIGN1
 #  define IMAGE_ENABLE_VERIFY0
-#else
+#  include  openssl/evp.h
+# else
 #  define IMAGE_ENABLE_SIGN0
 #  define IMAGE_ENABLE_VERIFY1
 # endif
@@ -861,6 +862,22 @@ struct image_region {
 int size;
 };

+#if IMAGE_ENABLE_VERIFY
+# include rsa-checksum.h
+#endif
+struct checksum_algo {
+  const char *name;
+  const int checksum_len;
+#if IMAGE_ENABLE_SIGN
+  EVP_MD *(*calculate)(void);
+#else
+#if IMAGE_ENABLE_VERIFY
+  void (*calculate)(const struct image_region region[], int region_count,
uint8_t * checksum);
+  const uint8_t * rsa_padding;
+#endif
+#endif
+};
+
 struct image_sig_algo {
 const char *name;/* Name of algorithm */

@@ -911,6 +928,10 @@ struct image_sig_algo {
 int (*verify)(struct image_sign_info *info,
   const struct image_region region[], int region_count,
   uint8_t *sig, uint sig_len);
+
+/* pointer to checksum algorithm */
+struct checksum_algo * checksum;
+
 };

 /**
diff --git a/include/rsa-checksum.h b/include/rsa-checksum.h
new file mode 100644
index 000..a318538
--- /dev/null
+++ b/include/rsa-checksum.h
@@ -0,0 +1,23 @@
+/*
+ * Copyright (c) 2013, Andreas Oetken.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _RSA_CHECKSUM_H
+#define _RSA_CHECKSUM_H
+
+#include errno.h
+#include image.h
+#include sha1.h
+#include sha256.h
+
+#if IMAGE_ENABLE_VERIFY
+extern const uint8_t padding_sha256_rsa2048[];
+extern const uint8_t padding_sha1_rsa2048[];
+
+void sha256_calculate(const struct image_region region[], int region_count,
uint8_t * checksum);
+void sha1_calculate(const struct image_region region[], int region_count,
uint8_t * checksum);
+#endif
+
+#endif
diff --git a/include/rsa.h b/include/rsa.h
index add4c78..3f6bb2c 100644
--- a/include/rsa.h
+++ b/include/rsa.h
@@ -15,6 +15,22 @@
 #include errno.h
 #include image.h

+
+/**
+ * struct rsa_public_key - holder for a public key
+ *
+ * An RSA public key consists of a modulus (typically called N), the inverse
+ * and R^2, where R is 2^(# key bits).
+ */
+
+struct rsa_public_key {
+uint len;/* Length of modulus[] in number of uint32_t */
+uint32_t n0inv;/* -1 / modulus[0] mod 2^32 */
+uint32_t *modulus;/* modulus as little endian array */
+uint32_t *rr;/* R^2 as little endian array */
+};
+
+
 #if IMAGE_ENABLE_SIGN
 /**
  * sign() - calculate and return signature for given input data
diff --git a/lib/rsa/Makefile b/lib/rsa/Makefile
index decd6e5..bf18cdc 100644
--- a/lib/rsa/Makefile
+++ b/lib/rsa/Makefile
@@ -12,7 +12,7 @@ include $(TOPDIR)/config.mk
 LIB= $(obj)librsa.o

 ifdef CONFIG_FIT_SIGNATURE
-COBJS-$(CONFIG_RSA) += rsa-verify.o
+COBJS-$(CONFIG_RSA) += rsa-verify.o rsa-checksum.o
 endif

 COBJS:= $(sort $(COBJS-y))
diff --git a/lib/rsa/rsa-checksum.c b/lib/rsa/rsa-checksum.c
new file mode 100644
index 000..fca065c
--- /dev/null
+++ b/lib/rsa/rsa-checksum.c
@@ -0,0 +1,77 @@
+/*
+ * Copyright (c) 2013, Andreas Oetken.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include fdtdec.h
+#include rsa.h
+#include sha1.h
+#include sha256.h
+#include asm/byteorder.h
+#include asm/errno.h
+#include asm/unaligned.h
+
+#define RSA2048_BYTES 256
+
+const uint8_t padding_sha256_rsa2048[RSA2048_BYTES - SHA256_SUM_LEN] = {
+0x00, 0x01, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 

[U-Boot] [PATCH] ARM/VExpress: fix timer address for TC2 and other VExpress models

[Andre Przywara]

Commit v2013.10-189-gb3a7f22 breaks u-boot on the VExpress TC2, since
the hardcoded value for SP804 timer address is wrong on Versatile
Express boards using the extended memory map.
Replace this value with an existing macro make it work on both sets of
machines.

Signed-off-by: Andre Przywara andre.przyw...@linaro.org
---
 include/configs/vexpress_common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/vexpress_common.h 
b/include/configs/vexpress_common.h
index 6da5e8f..7e78f8a 100644
--- a/include/configs/vexpress_common.h
+++ b/include/configs/vexpress_common.h
@@ -132,7 +132,7 @@
 #define VEXPRESS_FLASHPROG_FLVPPEN (1  0)
 
 #define CONFIG_SYS_TIMER_RATE  100
-#define CONFIG_SYS_TIMER_COUNTER   (0x10011000 + 0x4)
+#define CONFIG_SYS_TIMER_COUNTER   (V2M_TIMER01 + 0x4)
 #define CONFIG_SYS_TIMER_COUNTS_DOWN
 
 /* SMSC9115 Ethernet from SMSC9118 family */
-- 
1.7.12.1

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

[U-Boot] i.MX6 freeze when running Linux FSL 3.10.9-1.0.0-alpha AND U-Boot 2013.10

[Otavio Salvador]

Hello,

last days I've been trying to isolate the hung cause of a customer
board, and also SabreSD board, when using the Freescale's Linux fork
of 3.10.9 with 2013.10 U-Boot.

The below patch makes it work fine but it does not seem to be possible
to upstream this fix, that way. How you guys thing this could be
properly integrated into U-Boot to not break other boards?

diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c
index a390296..08f3eda 100644
--- a/arch/arm/cpu/armv7/mx6/soc.c
+++ b/arch/arm/cpu/armv7/mx6/soc.c
@@ -131,6 +131,34 @@ static void imx_set_wdog_powerdown(bool enable)
  writew(enable, wdog2-wmcr);
 }

+static void imx_set_vddpu_power_down(void)
+{
+ struct anatop_regs *anatop = (struct anatop_regs *)ANATOP_BASE_ADDR;
+ u32 val;
+
+ /* need to power down xPU in GPC before turn off PU LDO */
+ val = readl(GPC_BASE_ADDR + 0x260);
+ writel(val | 0x1, GPC_BASE_ADDR + 0x260);
+
+ val = readl(GPC_BASE_ADDR + 0x0);
+ writel(val | 0x1, GPC_BASE_ADDR + 0x0);
+ while (readl(GPC_BASE_ADDR + 0x0)  0x1)
+ ;
+
+ /* disable VDDPU */
+ val = 0x3e00;
+ writel(val, anatop-reg_core_clr);
+}
+
+static void imx_set_pcie_phy_power_down(void)
+{
+ u32 val;
+
+ val = readl(IOMUXC_BASE_ADDR + 0x4);
+ val |= 0x1  18;
+ writel(val, IOMUXC_BASE_ADDR + 0x4);
+}
+
 int arch_cpu_init(void)
 {
  init_aips();
@@ -139,6 +167,9 @@ int arch_cpu_init(void)

  imx_set_wdog_powerdown(false); /* Disable PDE bit of WMCR register */

+ imx_set_pcie_phy_power_down();
+ imx_set_vddpu_power_down();
+
 #ifdef CONFIG_APBH_DMA
  /* Start APBH DMA */
  mxs_dma_init();
diff --git a/arch/arm/imx-common/cpu.c b/arch/arm/imx-common/cpu.c
index 0cd2538..5cac1a9 100644
--- a/arch/arm/imx-common/cpu.c
+++ b/arch/arm/imx-common/cpu.c
@@ -171,9 +171,21 @@ u32 get_ahb_clk(void)
  return get_periph_clk() / (ahb_podf + 1);
 }

+static void set_anatop_bypass(void)
+{
+ struct anatop_regs *anatop = (struct anatop_regs *)ANATOP_BASE_ADDR;
+ u32 reg = readl(anatop-reg_core);
+
+ /* bypass VDDARM/VDDSOC */
+ reg = reg | (0x1F  18) | 0x1F;
+ writel(reg, anatop-reg_core);
+}
+
 #if defined(CONFIG_VIDEO_IPUV3)
 void arch_preboot_os(void)
 {
+ set_anatop_bypass();
+
  /* disable video before launching O/S */
  ipuv3_fb_shutdown();
 }

Regards,

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] No single character output after update to latest u-boot on pandaboard

[Tom Rini]

On Tue, Nov 26, 2013 at 12:22:19PM +0530, Lokesh Vutla wrote:
 Hi Chao,
 On Tuesday 26 November 2013 10:32 AM, Chao Xu wrote:
  Thank you! Please see the inline reply.
  
  On Mon, Nov 25, 2013 at 10:40 PM, Lokesh Vutla lokeshvu...@ti.com wrote:
  Hi,
  On Tuesday 26 November 2013 09:55 AM, Abraham V. wrote:
  Hello Chao,
  (cc R.Sricharan from TI)
 
  Quite frankly, I have no idea why your pandaboard fails to  work if
  CONFIG_SYS_ENABLE_PADS_ALL isn't defined in the omap4_common.h file. From
  the logs this patch was committed on 13/June/2012 by R.Sricharan. He might
  have a better explanation so I'm adding him to this discussion. The git 
  log
  message says this,
  If we enable CONFIG_SYS_ENABLE_PADS_ALL, pin mux for non essential pads 
  for u-boot
  will be configured. Ideally this configuration should be taken care by 
  kernel. This is the main reason
  to remove this config option.
  Due to this reason the following is added to 
  ./doc/feature-removal-schedule.txt
 
  What:  Remove CONFIG_SYS_ENABLE_PADS_ALL and CONFIG_SYS_CLOCKS_ENABLE_ALL
  When:   Release v2013.07
 
  Why:When set these options enable all of the pads and clocks found
  on OMAP4/5 platforms, so that the Linux Kernel does not have to.
  It has been agreed that this goes against the U-Boot design
  philosophy and since f3f98bb0 we have not enabled more than is
  used in U-Boot.  The kernel has been updating drivers to enable
  rather than assume pads/clocks have been enabled already.  Our
  expectation is that by v2013.07 a suitable kernel shall exist that
  does not need these options set for a reasonable I/O set to 
  function.
 
  Who:Tom Rini tr...@ti.com and Sricharan R r.sricha...@ti.com
 
  Please let me know if I am not clear.
 
  The explanation is crystal clear. So the setup of non-essential pins
  are left to the kernel. Then do I need to enable any linux kernel
  config options to instruct the kernel to take over? I just copied the
  old .config from my v3.7 kernel to build v3.12 kernel.
 No need to enable any config in kernel for this. Your dts should contain the 
 required pin mux details.
 I am not sure what is in 3.7 kernel. May be its good to use 
 omap2plus_defconfig.
 
 
  ARM: OMAP4/5: Do not configure non essential pads, clocks, dplls.
 
  Currently on OMAP4/5 platforms, many kernel drivers are dependent
  upon the bootloaders for mux, dpll and clock configurations.
  This should not be the case and bootloaders should set only the
  minimum required for the uboot functionality and kernel boot.
 
  Note that this is going to break the kernel drivers. But this
  is the only way to get things fixed in the kernel.
 
  Signed-off-by: R Sricharan r.sricha...@ti.com
 
  so I'm curious now. Chao - was your problem that uboot refused to start or
  were you seeing crashes in the linux kernel? If it's the former, then the
  kernel doesn't even come into the picture.
  Yes even I am not clear at this point. Chao can you please clarify.
  Ideally the above config will not harm U-Boot to come up on your board.
 
  I think it's the uboot refused to start. Because there was no single
  character from the serial port. I enabled the early_printk option in
  .config and added it to uEnv.txt. After I added the
  CONFIG_SYS_CLOCKS_ENABLE_ALL, the board can boot until Starting
  Kernel. I then fixed some other issue of the kernel, like copy the
  .dtb to /media/boot, and then kernel booted just fine. I'm curious,
  too. Is there anything I can do to further debugging? Thank you both
  very much!
 I think I got the problem.
 I grabbed my panda and tried latest mainline. As you said U-Boot didn't come 
 up for me either.
 I did a bisect and verified which patch is causing th issue. Below is the 
 patch which breaks omap4.
 
 6789e84 i2c, omap24xx: convert driver to new mutlibus/mutliadapter framework
 I think because of the linker code added in this patch for 
 omap-common/u-boot-spl.lds
 
   . = ALIGN(4);
   .u_boot_list : {
   KEEP(*(SORT(.u_boot_list*_i2c_*)));
   } .sram
 
 If I comment out this code, u-boot comes up as usual.
 Tom/Heiko, can you give a pointer why this is causing the issue.
 Please correct me if I am wrong.

Those lines keep the i2c adapter information in the binary (see the
lists created in the driver now) so that omap3_beagle for example works.
I think we need some further digging going on here.

-- 
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 2/9] ARM: HYP/non-sec: move switch to non-sec to the last boot phase

[Andre Przywara]

On 11/21/2013 09:59 AM, Marc Zyngier wrote:

Having the switch to non-secure in the prep phase is causing
all kind of troubles, as that stage can be called multiple times.

Instead, move the switch to non-secure to the last possible phase,
when there is no turning back anymore.


Tested on Versatile Express TC2.

Albert, Tom: please apply for v2014.01.

Acked-by: Andre Przywara andre.przyw...@linaro.org



Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
  arch/arm/lib/bootm.c | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index f476a89..f3da634 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -234,7 +234,6 @@ static void boot_prep_linux(bootm_headers_t *images)
printf(FDT and ATAGS support not compiled in - hanging\n);
hang();
}
-   do_nonsec_virt_switch();
  }

  /* Subcommand: GO */
@@ -264,8 +263,10 @@ static void boot_jump_linux(bootm_headers_t *images, int 
flag)
else
r2 = gd-bd-bi_boot_params;

-   if (!fake)
+   if (!fake) {
+   do_nonsec_virt_switch();
kernel_entry(0, machid, r2);
+   }
  }

  /* Main Entry point for arm bootm implementation



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

Re: [U-Boot] i.MX6 freeze when running Linux FSL 3.10.9-1.0.0-alpha AND U-Boot 2013.10

[Eric Bénard]

Hi Otavio,

Le Tue, 26 Nov 2013 12:32:45 -0200,
Otavio Salvador ota...@ossystems.com.br a écrit :

 Hello,
 
 last days I've been trying to isolate the hung cause of a customer
 board, and also SabreSD board, when using the Freescale's Linux fork
 of 3.10.9 with 2013.10 U-Boot.
 
 The below patch makes it work fine but it does not seem to be possible
 to upstream this fix, that way. How you guys thing this could be
 properly integrated into U-Boot to not break other boards?
 
 diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c
 index a390296..08f3eda 100644
 --- a/arch/arm/cpu/armv7/mx6/soc.c
 +++ b/arch/arm/cpu/armv7/mx6/soc.c
 @@ -131,6 +131,34 @@ static void imx_set_wdog_powerdown(bool enable)
   writew(enable, wdog2-wmcr);
  }
 
 +static void imx_set_vddpu_power_down(void)
 +{
 + struct anatop_regs *anatop = (struct anatop_regs *)ANATOP_BASE_ADDR;
 + u32 val;
 +
 + /* need to power down xPU in GPC before turn off PU LDO */
 + val = readl(GPC_BASE_ADDR + 0x260);
 + writel(val | 0x1, GPC_BASE_ADDR + 0x260);
 +
 + val = readl(GPC_BASE_ADDR + 0x0);
 + writel(val | 0x1, GPC_BASE_ADDR + 0x0);
 + while (readl(GPC_BASE_ADDR + 0x0)  0x1)
 + ;
 +
 + /* disable VDDPU */
 + val = 0x3e00;
 + writel(val, anatop-reg_core_clr);
 +}
 +
 +static void imx_set_pcie_phy_power_down(void)
 +{
 + u32 val;
 +
 + val = readl(IOMUXC_BASE_ADDR + 0x4);
 + val |= 0x1  18;
 + writel(val, IOMUXC_BASE_ADDR + 0x4);
 +}
 +
  int arch_cpu_init(void)
  {
   init_aips();
 @@ -139,6 +167,9 @@ int arch_cpu_init(void)
 
   imx_set_wdog_powerdown(false); /* Disable PDE bit of WMCR register */
 
 + imx_set_pcie_phy_power_down();
 + imx_set_vddpu_power_down();
 +
  #ifdef CONFIG_APBH_DMA
   /* Start APBH DMA */
   mxs_dma_init();
 diff --git a/arch/arm/imx-common/cpu.c b/arch/arm/imx-common/cpu.c
 index 0cd2538..5cac1a9 100644
 --- a/arch/arm/imx-common/cpu.c
 +++ b/arch/arm/imx-common/cpu.c
 @@ -171,9 +171,21 @@ u32 get_ahb_clk(void)
   return get_periph_clk() / (ahb_podf + 1);
  }
 
 +static void set_anatop_bypass(void)
 +{
 + struct anatop_regs *anatop = (struct anatop_regs *)ANATOP_BASE_ADDR;
 + u32 reg = readl(anatop-reg_core);
 +
 + /* bypass VDDARM/VDDSOC */
 + reg = reg | (0x1F  18) | 0x1F;
 + writel(reg, anatop-reg_core);
 +}
 +
  #if defined(CONFIG_VIDEO_IPUV3)
  void arch_preboot_os(void)
  {
 + set_anatop_bypass();
 +
   /* disable video before launching O/S */
   ipuv3_fb_shutdown();
  }
 
isn't the last change (enabling bypass) sufficient to fix the problem
or do you also need the 2 power_down before ?

Do you also get the kernel freeze without changing anything in
u-boot when you disable cpufreq in the kernel ?

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

Re: [U-Boot] [PATCH 3/9] ARM: HYP/non-sec: add a barrier after setting SCR.NS==1

[Andre Przywara]

On 11/21/2013 09:59 AM, Marc Zyngier wrote:

A CP15 instruction execution can be reordered, requiring an
isb to be sure it is executed in program order.


Makes sense ;-) and works on the VExpress TC2.

Albert, Tom, please apply for v2014.01.

Acked-by: Andre Przywara andre.przyw...@linaro.org


Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
  arch/arm/cpu/armv7/nonsec_virt.S | 1 +
  1 file changed, 1 insertion(+)

diff --git a/arch/arm/cpu/armv7/nonsec_virt.S b/arch/arm/cpu/armv7/nonsec_virt.S
index 29987cd..648066f 100644
--- a/arch/arm/cpu/armv7/nonsec_virt.S
+++ b/arch/arm/cpu/armv7/nonsec_virt.S
@@ -47,6 +47,7 @@ _secure_monitor:
  #endif

mcr p15, 0, r1, c1, c1, 0   @ write SCR (with NS bit set)
+   isb

  #ifdef CONFIG_ARMV7_VIRT
mrceq   p15, 0, r0, c12, c0, 1  @ get MVBAR value



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

Re: [U-Boot] [PATCH 4/9] ARM: non-sec: reset CNTVOFF to zero

[Andre Przywara]

On 11/21/2013 09:59 AM, Marc Zyngier wrote:

Before switching to non-secure, make sure that CNTVOFF is set
to zero on all CPUs. Otherwise, kernel running in non-secure
without HYP enabled (hence using virtual timers) may observe
timers that are not synchronized, effectively seeing time
going backward...


Under what circumstances would native Linux use the virtual timers? When 
VIRT_EXT is not defined?


Regards,
Andre.



Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
  arch/arm/cpu/armv7/nonsec_virt.S | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/arch/arm/cpu/armv7/nonsec_virt.S b/arch/arm/cpu/armv7/nonsec_virt.S
index 648066f..bbacbce 100644
--- a/arch/arm/cpu/armv7/nonsec_virt.S
+++ b/arch/arm/cpu/armv7/nonsec_virt.S
@@ -53,7 +53,14 @@ _secure_monitor:
mrceq   p15, 0, r0, c12, c0, 1  @ get MVBAR value
mcreq   p15, 4, r0, c12, c0, 0  @ write HVBAR
  #endif
+   bne 1f

+   @ Reset CNTVOFF to 0 before leaving monitor mode
+   mrc p15, 0, r0, c0, c1, 1   @ read ID_PFR1
+   andsr0, r0, #CPUID_ARM_GENTIMER_MASK@ test arch timer bits
+   movne   r0, #0
+   mcrrne  p15, 4, r0, r0, c14 @ Reset CNTVOFF to zero
+1:
movspc, lr  @ return to non-secure SVC

  _hyp_trap:



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

Re: [U-Boot] [PATCH 4/9] ARM: non-sec: reset CNTVOFF to zero

[Marc Zyngier]

On 26/11/13 14:41, Andre Przywara wrote:
 On 11/21/2013 09:59 AM, Marc Zyngier wrote:
 Before switching to non-secure, make sure that CNTVOFF is set
 to zero on all CPUs. Otherwise, kernel running in non-secure
 without HYP enabled (hence using virtual timers) may observe
 timers that are not synchronized, effectively seeing time
 going backward...
 
 Under what circumstances would native Linux use the virtual timers? When 
 VIRT_EXT is not defined?

Yes. In general, when the kernel is not entered in HYP mode.

M.

 Regards,
 Andre.
 

 Signed-off-by: Marc Zyngier marc.zyng...@arm.com
 ---
   arch/arm/cpu/armv7/nonsec_virt.S | 7 +++
   1 file changed, 7 insertions(+)

 diff --git a/arch/arm/cpu/armv7/nonsec_virt.S 
 b/arch/arm/cpu/armv7/nonsec_virt.S
 index 648066f..bbacbce 100644
 --- a/arch/arm/cpu/armv7/nonsec_virt.S
 +++ b/arch/arm/cpu/armv7/nonsec_virt.S
 @@ -53,7 +53,14 @@ _secure_monitor:
  mrceq   p15, 0, r0, c12, c0, 1  @ get MVBAR value
  mcreq   p15, 4, r0, c12, c0, 0  @ write HVBAR
   #endif
 +bne 1f

 +@ Reset CNTVOFF to 0 before leaving monitor mode
 +mrc p15, 0, r0, c0, c1, 1   @ read ID_PFR1
 +andsr0, r0, #CPUID_ARM_GENTIMER_MASK@ test arch timer bits
 +movne   r0, #0
 +mcrrne  p15, 4, r0, r0, c14 @ Reset CNTVOFF to zero
 +1:
  movspc, lr  @ return to non-secure SVC

   _hyp_trap:

 
 


-- 
Jazz is not dead. It just smells funny...

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

[U-Boot] [PATCH] mmc/dwmmc: remove recursive FIFO threshold setup

[Alexey Brodkin]

Removed code works properly only once after power-up because on every
first invocation of dwmci_init existing value of fifo_size is used
for calculation of itself. More over other bits in the same register
(namely TX watermark and burst size) get corrupted (lost forever till
the next power-toggle).

I understand that usually (in production systems) U-Boot starts only
once and then passes control to Linux kernel etc. But when you do
U-Boot debugging it might be loaded in memory via JTAG multiple times.

Also I wasn't able to find any instance of host-fifoth_val usage so I
believe it's safe to just remove this code completely.

Another important thing - in the latest Linux kernel driver for DW MMC
comtroller I don't see any utilization (configuration/modificatoin) of
the register in question (SDMMC_FIFOTH). That's why I think we may want
to keep it untouched as well so we don't force a situation when kernel
driver gets DW MMC unexpectedly configured by U-Boot.

Signed-off-by: Alexey Brodkin abrod...@synopsys.com

Cc: Mischa Jonker mjon...@synopsys.com
Cc: Alim Akhtar alim.akh...@samsung.com
Cc: Rajeshwari Shinde rajeshwar...@samsung.com
Cc: Jaehoon Chung jh80.ch...@samsung.com
Cc: Amar amarendra...@samsung.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Hatim Ali hatim...@samsung.com
Cc: Minkyu Kang mk7.k...@samsung.com
Cc: Simon Glass s...@chromium.org
Cc: Pantelis Antoniou pa...@antoniou-consulting.com
Cc: Andy Fleming aflem...@freescale.com
---
 drivers/mmc/dw_mmc.c | 9 -
 include/dwmmc.h  | 1 -
 2 files changed, 10 deletions(-)

diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
index 1e0f72b..166124d 100644
--- a/drivers/mmc/dw_mmc.c
+++ b/drivers/mmc/dw_mmc.c
@@ -300,7 +300,6 @@ static void dwmci_set_ios(struct mmc *mmc)
 static int dwmci_init(struct mmc *mmc)
 {
struct dwmci_host *host = (struct dwmci_host *)mmc-priv;
-   u32 fifo_size;
 
if (host-quirks  DWMCI_QUIRK_DISABLE_SMU) {
dwmci_writel(host, EMMCP_MPSBEGIN0, 0);
@@ -330,14 +329,6 @@ static int dwmci_init(struct mmc *mmc)
dwmci_writel(host, DWMCI_IDINTEN, 0);
dwmci_writel(host, DWMCI_BMOD, 1);
 
-   if (!host-fifoth_val) {
-   fifo_size = dwmci_readl(host, DWMCI_FIFOTH);
-   fifo_size = ((fifo_size  RX_WMARK_MASK)  RX_WMARK_SHIFT) + 1;
-   host-fifoth_val = MSIZE(0x2) | RX_WMARK(fifo_size / 2 - 1) |
-   TX_WMARK(fifo_size / 2);
-   }
-   dwmci_writel(host, DWMCI_FIFOTH, host-fifoth_val);
-
dwmci_writel(host, DWMCI_CLKENA, 0);
dwmci_writel(host, DWMCI_CLKSRC, 0);
 
diff --git a/include/dwmmc.h b/include/dwmmc.h
index 6c91143..20cd1eb 100644
--- a/include/dwmmc.h
+++ b/include/dwmmc.h
@@ -137,7 +137,6 @@ struct dwmci_host {
int dev_index;
int buswidth;
u32 clksel_val;
-   u32 fifoth_val;
struct mmc *mmc;
 
void (*clksel)(struct dwmci_host *host);
-- 
1.8.4.2

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

Re: [U-Boot] [ANN] v2014.01-rc1

[Wolfgang Denk]

Dear Tom,

In message 20131125215854.GW420@bill-the-cat you wrote:
 
 I've put v2014.01-rc1 out and and we should have a tarball out soon.

The tarball is on the FTP server.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Die ganzen Zahlen hat der liebe Gott  geschaffen,  alles  andere  ist
Menschenwerk... Leopold Kronecker
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] i.MX6 freeze when running Linux FSL 3.10.9-1.0.0-alpha AND U-Boot 2013.10

[Wolfgang Denk]

Dear Otavio,

In message cap9odkpaarheq3w7dwchknd7+ay7u3xdbxr4df3fx2tbtak...@mail.gmail.com 
you wrote:
 
 last days I've been trying to isolate the hung cause of a customer
 board, and also SabreSD board, when using the Freescale's Linux fork
 of 3.10.9 with 2013.10 U-Boot.

Do I understand correctly that this happens only with the FSL kernel,
i. e. not with mainline Linux?


What exactly is the effect of calling your set_anatop_bypass()
function?  Why would that be needed on the FSL kernel, and not on
mainline?


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
It's hard to make a program foolproof because fools are so ingenious.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] i.MX6 freeze when running Linux FSL 3.10.9-1.0.0-alpha AND U-Boot 2013.10

[Otavio Salvador]

On Tue, Nov 26, 2013 at 12:39 PM, Eric Bénard e...@eukrea.com wrote:
 Hi Otavio,

 Le Tue, 26 Nov 2013 12:32:45 -0200,
 Otavio Salvador ota...@ossystems.com.br a écrit :

 Hello,

 last days I've been trying to isolate the hung cause of a customer
 board, and also SabreSD board, when using the Freescale's Linux fork
 of 3.10.9 with 2013.10 U-Boot.

 The below patch makes it work fine but it does not seem to be possible
 to upstream this fix, that way. How you guys thing this could be
 properly integrated into U-Boot to not break other boards?

 diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c
 index a390296..08f3eda 100644
 --- a/arch/arm/cpu/armv7/mx6/soc.c
 +++ b/arch/arm/cpu/armv7/mx6/soc.c
 @@ -131,6 +131,34 @@ static void imx_set_wdog_powerdown(bool enable)
   writew(enable, wdog2-wmcr);
  }

 +static void imx_set_vddpu_power_down(void)
 +{
 + struct anatop_regs *anatop = (struct anatop_regs *)ANATOP_BASE_ADDR;
 + u32 val;
 +
 + /* need to power down xPU in GPC before turn off PU LDO */
 + val = readl(GPC_BASE_ADDR + 0x260);
 + writel(val | 0x1, GPC_BASE_ADDR + 0x260);
 +
 + val = readl(GPC_BASE_ADDR + 0x0);
 + writel(val | 0x1, GPC_BASE_ADDR + 0x0);
 + while (readl(GPC_BASE_ADDR + 0x0)  0x1)
 + ;
 +
 + /* disable VDDPU */
 + val = 0x3e00;
 + writel(val, anatop-reg_core_clr);
 +}
 +
 +static void imx_set_pcie_phy_power_down(void)
 +{
 + u32 val;
 +
 + val = readl(IOMUXC_BASE_ADDR + 0x4);
 + val |= 0x1  18;
 + writel(val, IOMUXC_BASE_ADDR + 0x4);
 +}
 +
  int arch_cpu_init(void)
  {
   init_aips();
 @@ -139,6 +167,9 @@ int arch_cpu_init(void)

   imx_set_wdog_powerdown(false); /* Disable PDE bit of WMCR register */

 + imx_set_pcie_phy_power_down();
 + imx_set_vddpu_power_down();
 +
  #ifdef CONFIG_APBH_DMA
   /* Start APBH DMA */
   mxs_dma_init();
 diff --git a/arch/arm/imx-common/cpu.c b/arch/arm/imx-common/cpu.c
 index 0cd2538..5cac1a9 100644
 --- a/arch/arm/imx-common/cpu.c
 +++ b/arch/arm/imx-common/cpu.c
 @@ -171,9 +171,21 @@ u32 get_ahb_clk(void)
   return get_periph_clk() / (ahb_podf + 1);
  }

 +static void set_anatop_bypass(void)
 +{
 + struct anatop_regs *anatop = (struct anatop_regs *)ANATOP_BASE_ADDR;
 + u32 reg = readl(anatop-reg_core);
 +
 + /* bypass VDDARM/VDDSOC */
 + reg = reg | (0x1F  18) | 0x1F;
 + writel(reg, anatop-reg_core);
 +}
 +
  #if defined(CONFIG_VIDEO_IPUV3)
  void arch_preboot_os(void)
  {
 + set_anatop_bypass();
 +
   /* disable video before launching O/S */
   ipuv3_fb_shutdown();
  }

 isn't the last change (enabling bypass) sufficient to fix the problem
 or do you also need the 2 power_down before ?

It does indeed. I did a full test cycle from cold boot and also from
inside system reboot and it works.

So:

diff --git a/arch/arm/imx-common/cpu.c b/arch/arm/imx-common/cpu.c
index 0cd2538..5cac1a9 100644
--- a/arch/arm/imx-common/cpu.c
+++ b/arch/arm/imx-common/cpu.c
@@ -171,9 +171,21 @@ u32 get_ahb_clk(void)
return get_periph_clk() / (ahb_podf + 1);
 }

+static void set_anatop_bypass(void)
+{
+   struct anatop_regs *anatop = (struct anatop_regs *)ANATOP_BASE_ADDR;
+   u32 reg = readl(anatop-reg_core);
+
+   /* bypass VDDARM/VDDSOC */
+   reg = reg | (0x1F  18) | 0x1F;
+   writel(reg, anatop-reg_core);
+}
+
 #if defined(CONFIG_VIDEO_IPUV3)
 void arch_preboot_os(void)
 {
+   set_anatop_bypass();
+
/* disable video before launching O/S */
ipuv3_fb_shutdown();
 }

is the needed patch.

 Do you also get the kernel freeze without changing anything in
 u-boot when you disable cpufreq in the kernel ?

The FSL kernel does not build without cpufreq so I didn't try.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] i.MX6 freeze when running Linux FSL 3.10.9-1.0.0-alpha AND U-Boot 2013.10

[Otavio Salvador]

On Tue, Nov 26, 2013 at 1:39 PM, Wolfgang Denk w...@denx.de wrote:
 Dear Otavio,

 In message 
 cap9odkpaarheq3w7dwchknd7+ay7u3xdbxr4df3fx2tbtak...@mail.gmail.com you 
 wrote:

 last days I've been trying to isolate the hung cause of a customer
 board, and also SabreSD board, when using the Freescale's Linux fork
 of 3.10.9 with 2013.10 U-Boot.

 Do I understand correctly that this happens only with the FSL kernel,
 i. e. not with mainline Linux?

Exactly.

 What exactly is the effect of calling your set_anatop_bypass()
 function?  Why would that be needed on the FSL kernel, and not on
 mainline?

Mainline seems to not drive the pmic while the FSL kernel does. So it
seems we ought to bypass the internal LDO.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] i.MX6 freeze when running Linux FSL 3.10.9-1.0.0-alpha AND U-Boot 2013.10

[Eric Bénard]

Le Tue, 26 Nov 2013 13:59:36 -0200,
Otavio Salvador ota...@ossystems.com.br a écrit :
  Do you also get the kernel freeze without changing anything in
  u-boot when you disable cpufreq in the kernel ?
 
 The FSL kernel does not build without cpufreq so I didn't try.
 
check if your regulator settings is not defaulted to use anatop's ldo
by default instead of the PMIC's one.

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

Re: [U-Boot] i.MX6 freeze when running Linux FSL 3.10.9-1.0.0-alpha AND U-Boot 2013.10

[Otavio Salvador]

On Tue, Nov 26, 2013 at 2:09 PM, Eric Bénard e...@eukrea.com wrote:
 Le Tue, 26 Nov 2013 13:59:36 -0200,
 Otavio Salvador ota...@ossystems.com.br a écrit :
  Do you also get the kernel freeze without changing anything in
  u-boot when you disable cpufreq in the kernel ?

 The FSL kernel does not build without cpufreq so I didn't try.

 check if your regulator settings is not defaulted to use anatop's ldo
 by default instead of the PMIC's one.

I think what is happening is the invert; in case of mainline kernel it
is using the internal LDO while in Freescale kernel it uses the PMIC's
one. Hence the failure.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 0/4] MIPS Malta fixes

[Paul Burton]

This series fixes a few issues with the MIPS Malta board. The first 2
patches correct the handling of the UART baudrate and allow Linux to
correctly inherit that used by U-boot. The third patch enables an
interrupt which Linux relies upon but does not enable itself. I will
submit a patch to Linux in due course but enabling it in U-boot is
required in order for current Linux kernels to function correctly. The
final patch isn't a fix but allows larger kernel images to be booted
which improves the experience of using U-boot on a Malta.

Paul Burton (4):
  mips: don't hardcode Malta env baudrate
  malta: correct UART baudrate
  malta: enable PIIX4 SERIRQ
  malta: set CONFIG_SYS_BOOTM_LEN to 64MB

 arch/mips/include/asm/malta.h |  7 +++
 arch/mips/lib/bootm.c |  6 --
 board/imgtec/malta/malta.c| 12 
 include/configs/malta.h   |  3 ++-
 4 files changed, 25 insertions(+), 3 deletions(-)

-- 
1.8.4.2


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

[U-Boot] [PATCH 1/4] mips: don't hardcode Malta env baudrate

[Paul Burton]

The baudrate passed to Linux in the environment was hardcoded at 38400.
Instead pass the correct baudrate from global data, allowing Linux to
correctly inherit the baudrate used by U-boot when console setup is not
explicitly specified.

Signed-off-by: Paul Burton paul.bur...@imgtec.com
---
 arch/mips/lib/bootm.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/mips/lib/bootm.c b/arch/mips/lib/bootm.c
index 1febf29..71bb0d2 100644
--- a/arch/mips/lib/bootm.c
+++ b/arch/mips/lib/bootm.c
@@ -196,8 +196,10 @@ static void boot_prep_linux(bootm_headers_t *images)
if (cp)
linux_env_set(eth1addr, cp);
 
-   if (mips_boot_malta)
-   linux_env_set(modetty0, 38400n8r);
+   if (mips_boot_malta) {
+   sprintf(env_buf, %un8r, gd-baudrate);
+   linux_env_set(modetty0, env_buf);
+   }
 }
 
 static void boot_jump_linux(bootm_headers_t *images)
-- 
1.8.4.2


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

[U-Boot] [PATCH 3/4] malta: enable PIIX4 SERIRQ

[Paul Burton]

Whilst U-boot does not require this itself, Linux currently relies upon
it having been muxed and enabled by the bootloader. Thus in order to
preserve compatibility with current kernels before a fix is merged in
Linux we will enable the SERIRQ interrupt and mux it to its pin.

Without doing this current kernels will never receive serial port
interrupts and the end result is typically that userland appears to
hang.

Signed-off-by: Paul Burton paul.bur...@imgtec.com
---
 arch/mips/include/asm/malta.h |  7 +++
 board/imgtec/malta/malta.c| 12 
 2 files changed, 19 insertions(+)

diff --git a/arch/mips/include/asm/malta.h b/arch/mips/include/asm/malta.h
index bd9043d..9e7c045 100644
--- a/arch/mips/include/asm/malta.h
+++ b/arch/mips/include/asm/malta.h
@@ -56,5 +56,12 @@
 #define PCI_CFG_PIIX4_PIRQRCB  0x61
 #define PCI_CFG_PIIX4_PIRQRCC  0x62
 #define PCI_CFG_PIIX4_PIRQRCD  0x63
+#define PCI_CFG_PIIX4_SERIRQC  0x64
+#define PCI_CFG_PIIX4_GENCFG   0xb0
+
+#define PCI_CFG_PIIX4_SERIRQC_EN   (1  7)
+#define PCI_CFG_PIIX4_SERIRQC_CONT (1  6)
+
+#define PCI_CFG_PIIX4_GENCFG_SERIRQ(1  16)
 
 #endif /* _MIPS_ASM_MALTA_H */
diff --git a/board/imgtec/malta/malta.c b/board/imgtec/malta/malta.c
index a1a4c01..d363e49 100644
--- a/board/imgtec/malta/malta.c
+++ b/board/imgtec/malta/malta.c
@@ -171,6 +171,8 @@ struct serial_device *default_serial_console(void)
 void pci_init_board(void)
 {
pci_dev_t bdf;
+   u32 val32;
+   u8 val8;
 
switch (malta_sys_con()) {
case SYSCON_GT64120:
@@ -205,4 +207,14 @@ void pci_init_board(void)
pci_write_config_byte(bdf, PCI_CFG_PIIX4_PIRQRCB, 10);
pci_write_config_byte(bdf, PCI_CFG_PIIX4_PIRQRCC, 11);
pci_write_config_byte(bdf, PCI_CFG_PIIX4_PIRQRCD, 11);
+
+   /* mux SERIRQ onto SERIRQ pin */
+   pci_read_config_dword(bdf, PCI_CFG_PIIX4_GENCFG, val32);
+   val32 |= PCI_CFG_PIIX4_GENCFG_SERIRQ;
+   pci_write_config_dword(bdf, PCI_CFG_PIIX4_GENCFG, val32);
+
+   /* enable SERIRQ - Linux currently depends upon this */
+   pci_read_config_byte(bdf, PCI_CFG_PIIX4_SERIRQC, val8);
+   val8 |= PCI_CFG_PIIX4_SERIRQC_EN | PCI_CFG_PIIX4_SERIRQC_CONT;
+   pci_write_config_byte(bdf, PCI_CFG_PIIX4_SERIRQC, val8);
 }
-- 
1.8.4.2


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

[U-Boot] [PATCH 4/4] malta: set CONFIG_SYS_BOOTM_LEN to 64MB

[Paul Burton]

Allow a larger kernel binary to be decompressed - the default 8MB can
become limiting on a Malta.

Signed-off-by: Paul Burton paul.bur...@imgtec.com
---
 include/configs/malta.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/malta.h b/include/configs/malta.h
index 666cca9..cc574ed 100644
--- a/include/configs/malta.h
+++ b/include/configs/malta.h
@@ -54,6 +54,7 @@
 
 #define CONFIG_SYS_MALLOC_LEN  (128 * 1024)
 #define CONFIG_SYS_BOOTPARAMS_LEN  (128 * 1024)
+#define CONFIG_SYS_BOOTM_LEN   (64 * 1024 * 1024)
 
 /*
  * Console configuration
-- 
1.8.4.2


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

[U-Boot] [PATCH 2/4] malta: correct UART baudrate

[Paul Burton]

CONFIG_SYS_NS16550_CLK specifies the rate of the clock 16x the baud
rate. The SMSC FDC37M81x datasheet states that a divider of 1 results in
a UART at 115200 baud, thus the x16 clock rate is 115200 * 16.
Previously the divider was left at 0 which led to a rate of 38400 baud
regardless of CONFIG_BAUDRATE or the baudrate environment variable.

Signed-off-by: Paul Burton paul.bur...@imgtec.com
---
 include/configs/malta.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/malta.h b/include/configs/malta.h
index 458c33a..666cca9 100644
--- a/include/configs/malta.h
+++ b/include/configs/malta.h
@@ -80,7 +80,7 @@
 #define CONFIG_SYS_NS16550
 #define CONFIG_SYS_NS16550_SERIAL
 #define CONFIG_SYS_NS16550_REG_SIZE1
-#define CONFIG_SYS_NS16550_CLK 115200
+#define CONFIG_SYS_NS16550_CLK (115200 * 16)
 #define CONFIG_SYS_NS16550_COM1CKSEG1ADDR(MALTA_GT_UART0_BASE)
 #define CONFIG_SYS_NS16550_COM2
CKSEG1ADDR(MALTA_MSC01_UART0_BASE)
 #define CONFIG_CONS_INDEX  1
-- 
1.8.4.2


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

Re: [U-Boot] [PATCH 0/4] MIPS Malta fixes

[Daniel Schwierzeck]

2013/11/26 Paul Burton paul.bur...@imgtec.com:
 This series fixes a few issues with the MIPS Malta board. The first 2
 patches correct the handling of the UART baudrate and allow Linux to
 correctly inherit that used by U-boot. The third patch enables an
 interrupt which Linux relies upon but does not enable itself. I will
 submit a patch to Linux in due course but enabling it in U-boot is
 required in order for current Linux kernels to function correctly. The
 final patch isn't a fix but allows larger kernel images to be booted
 which improves the experience of using U-boot on a Malta.

 Paul Burton (4):
   mips: don't hardcode Malta env baudrate
   malta: correct UART baudrate
   malta: enable PIIX4 SERIRQ
   malta: set CONFIG_SYS_BOOTM_LEN to 64MB

  arch/mips/include/asm/malta.h |  7 +++
  arch/mips/lib/bootm.c |  6 --
  board/imgtec/malta/malta.c| 12 
  include/configs/malta.h   |  3 ++-
  4 files changed, 25 insertions(+), 3 deletions(-)

 --
 1.8.4.2



all patches applied to u-boot-mips/master, thanks

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

Re: [U-Boot] [PATCH V2 05/14] ARM: AM43XX: board: add support for reading onboard EEPROM

[Vaibhav Bedia]

On Sun, Nov 24, 2013 at 11:46 PM, Lokesh Vutla lokeshvu...@ti.com wrote:
 On Friday 22 November 2013 01:56 AM, Vaibhav Bedia wrote:
 On Thu, Nov 21, 2013 at 1:18 AM, Lokesh Vutla lokeshvu...@ti.com wrote:
 [...]
  #define NON_SECURE_SRAM_START  0x402F0400
  #define NON_SECURE_SRAM_END0x4034
  #define SRAM_SCRATCH_SPACE_ADDR0x4033C000
 +#define AM4372_BOARD_NAME_STARTSRAM_SCRATCH_SPACE_ADDR
 +#define AM4372_BOARD_NAME_END  SRAM_SCRATCH_SPACE_ADDR + 0xC

 Why do you need to keep the struct address hardcoded like this?
 FYI, this is not struct address. This is the place where where I am storing 
 board name.
 This helps in detecting the board.
 It ll be good to understand the code properly and comment.

My bad. Should have looked closer.


 [...]
 +static inline int board_is_eposevm(void)
 +{
 +   return !strncmp(am43xx_board_name, AM43EPOS, HDR_NAME_LEN);
 +}
 +
 +static inline int board_is_gpevm(void)
 +{
 +   return !strncmp(am43xx_board_name, AM43__GP, HDR_NAME_LEN);
 +}
 +

 Looks like you got the EEPROM content updated ;)
 There is nothing updated. This is what I have used previously.
 Please recollect your comments properly.


Well it would help if you added in a more detailed changelog for the different
variants of the patches highlighting what's changed and if some comment is
being ignored the reason for the same.

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

Re: [U-Boot] [PATCH V2 06/14] ARM: AM43XX: Add CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG support

[Vaibhav Bedia]

On Sun, Nov 24, 2013 at 11:48 PM, Lokesh Vutla lokeshvu...@ti.com wrote:
 On Friday 22 November 2013 01:58 AM, Vaibhav Bedia wrote:
 On Thu, Nov 21, 2013 at 1:18 AM, Lokesh Vutla lokeshvu...@ti.com wrote:
 [...]
 +#ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
 +   char safe_string[HDR_NAME_LEN + 1];
 +   struct am43xx_board_id header;
 +
 +   if (read_eeprom(header)  0)
 +   puts(Could not get board ID.\n);

 Hmm... didn't the previous patch read the EEPROM?
 This is as per suggested by Tom. If I populate a common structure it ll bread 
 NOR boot.
 I hope you understand what happens in NOR boot.


Care to explain how this particular snippet relates to NOR boot?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [GIT PULL] u-boot-mips/master

[Daniel Schwierzeck]

Hi Tom,

please pull some additional fixes for MIPS malta board, thanks.

The following changes since commit d19ad726bcd5d9106f7ba9c750462fcc369f1020:

  Prepare v2014.01-rc1 (2013-11-25 16:49:32 -0500)

are available in the git repository at:

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

for you to fetch changes up to 67d4752d1dae768c7ff381272880d4aceeb62085:

  malta: set CONFIG_SYS_BOOTM_LEN to 64MB (2013-11-26 21:49:42 +0100)


Paul Burton (4):
  mips: don't hardcode Malta env baudrate
  malta: correct UART baudrate
  malta: enable PIIX4 SERIRQ
  malta: set CONFIG_SYS_BOOTM_LEN to 64MB

 arch/mips/include/asm/malta.h |  7 +++
 arch/mips/lib/bootm.c |  6 --
 board/imgtec/malta/malta.c| 12 
 include/configs/malta.h   |  3 ++-
 4 files changed, 25 insertions(+), 3 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2 07/14] ARM: AM43xx: Select clk source for Timer2

[Vaibhav Bedia]

On Sun, Nov 24, 2013 at 11:53 PM, Lokesh Vutla lokeshvu...@ti.com wrote:
 On Friday 22 November 2013 02:01 AM, Vaibhav Bedia wrote:
 On Thu, Nov 21, 2013 at 1:18 AM, Lokesh Vutla lokeshvu...@ti.com wrote:
 Selecting the Master osc clk as Timer2 clock source.

 Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
 ---
  arch/arm/cpu/armv7/am33xx/clock_am43xx.c |4 
  1 file changed, 4 insertions(+)

 diff --git a/arch/arm/cpu/armv7/am33xx/clock_am43xx.c 
 b/arch/arm/cpu/armv7/am33xx/clock_am43xx.c
 index c4890f2..22963b7 100644
 --- a/arch/arm/cpu/armv7/am33xx/clock_am43xx.c
 +++ b/arch/arm/cpu/armv7/am33xx/clock_am43xx.c
 @@ -18,6 +18,7 @@

  struct cm_perpll *const cmper = (struct cm_perpll *)CM_PER;
  struct cm_wkuppll *const cmwkup = (struct cm_wkuppll *)CM_WKUP;
 +struct cm_dpll *const cmdpll = (struct cm_dpll *)CM_DPLL;

  const struct dpll_regs dpll_mpu_regs = {
 .cm_clkmode_dpll= CM_WKUP + 0x560,
 @@ -107,4 +108,7 @@ void enable_basic_clocks(void)
 };

 do_enable_clocks(clk_domains, clk_modules_explicit_en, 1);
 +
 +   /* Select the Master osc clk as Timer2 clock source */
 +   writel(0x1, cmdpll-clktimer2clk);

 I really don't see a point of copying whatever AM335x does. You should
 have a good reason for not using the other timers :P
 Again nothing is copied here, I am reusing the code what ever is present.
 I don't have any restrictions to choose any timer here. All OMAPs and AM uses 
 timer 2
 and I used it. I have already told you why I can't use timer1.


If by that you are referring to your reasoning that there's a base
address that's already
there and hence let's reuse it, then yes you did.

 First please give me a *valid reason* why I should not use timer2, then Ill 
 think of using other timer.
 As per my understanding there is nothing wrong to reuse what ever is present.
 Please be specific when you are commenting.


And the reuse without rethink is exactly how over a period of time we
end up with choices in s/w that no one can recollect have it your way :)

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

Re: [U-Boot] [PATCH V2 09/14] ARM: AM43xx: mux: Update mux data

[Vaibhav Bedia]

On Sun, Nov 24, 2013 at 11:59 PM, Lokesh Vutla lokeshvu...@ti.com wrote:
 On Friday 22 November 2013 02:04 AM, Vaibhav Bedia wrote:
 On Thu, Nov 21, 2013 at 1:18 AM, Lokesh Vutla lokeshvu...@ti.com wrote:
 Updating the mux data for UART, adding data for i2c0 and mmc.
 And also updating pad_signals structure.

 Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
 ---
  arch/arm/include/asm/arch-am33xx/mux_am43xx.h |   45 
 +
  board/ti/am43xx/mux.c |   22 ++--
  2 files changed, 65 insertions(+), 2 deletions(-)

 diff --git a/arch/arm/include/asm/arch-am33xx/mux_am43xx.h 
 b/arch/arm/include/asm/arch-am33xx/mux_am43xx.h
 index 0206912..98fc2b5 100644
 --- a/arch/arm/include/asm/arch-am33xx/mux_am43xx.h
 +++ b/arch/arm/include/asm/arch-am33xx/mux_am43xx.h
 @@ -137,6 +137,51 @@ struct pad_signals {
 int mcasp0_fsr;
 int mcasp0_axr1;
 int mcasp0_ahclkx;
 +   int xdma_event_intr0;
 +   int xdma_event_intr1;
 +   int nresetin_out;
 +   int porz;
 +   int nnmi;
 +   int osc0_in;
 +   int osc0_out;
 +   int rsvd1;
 +   int tms;
 +   int tdi;
 +   int tdo;
 +   int tck;
 +   int ntrst;
 +   int emu0;
 +   int emu1;
 +   int osc1_in;
 +   int osc1_out;
 +   int pmic_power_en;
 +   int rtc_porz;
 +   int rsvd2;
 +   int ext_wakeup;
 +   int enz_kaldo_1p8v;
 +   int usb0_dm;
 +   int usb0_dp;
 +   int usb0_ce;
 +   int usb0_id;
 +   int usb0_vbus;
 +   int usb0_drvvbus;
 +   int usb1_dm;
 +   int usb1_dp;
 +   int usb1_ce;
 +   int usb1_id;
 +   int usb1_vbus;
 +   int usb1_drvvbus;
 +   int ddr_resetn;
 +   int ddr_csn0;
 +   int ddr_cke;
 +   int ddr_ck;
 +   int ddr_nck;
 +   int ddr_casn;
 +   int ddr_rasn;
 +   int ddr_wen;
 +   int ddr_ba0;
 +   int ddr_ba1;
 +   int ddr_ba2;
  };

 IIRC not all the pads over here have any IO control. Some are analog pins
 and some like JTAG, PORz really shouldn't be meddled with if the h/w does
 expose some configuration. Please revisit this change.
 Nothing to be revisited here. I have to use ddr_ba2 for VTT, so I have
 populated the structure till this point.
 I don't see any error to update a structure so that I can use the desired 
 pins.
 I am not using the pins what ever you have mentioned. I purposefully 
 populated those
 because I don't want make them as reserved.

I think i gave a good enough technical reason why that's not a good thing to do.
If you really don't see the shortcomings of that i have nothing more
to add here.



  #endif /* _MUX_AM43XX_H_ */
 diff --git a/board/ti/am43xx/mux.c b/board/ti/am43xx/mux.c
 index 700e9a7..46bad01 100644
 --- a/board/ti/am43xx/mux.c
 +++ b/board/ti/am43xx/mux.c
 @@ -12,8 +12,24 @@
  #include board.h

  static struct module_pin_mux uart0_pin_mux[] = {
 -   {OFFSET(uart0_rxd), (MODE(0) | RXACTIVE)},  /* UART0_RXD */
 -   {OFFSET(uart0_txd), (MODE(0))}, /* UART0_TXD */
 +   {OFFSET(uart0_rxd), (MODE(0) | PULLUP_EN | RXACTIVE | SLEWCTRL)},
 +   {OFFSET(uart0_txd), (MODE(0) | PULLUDDIS | PULLUP_EN | SLEWCTRL)},
 +   {-1},

 SLEWCTRL is typically not changed. You might want to double check this 
 portion
 with the h/w folks.
 I have checked with h/w folks, they said nothing wrong here.

Fine with me.

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

Re: [U-Boot] [PATCH V2 10/14] ARM: AM43xx: clocks: Update DPLL details for EPOS EVM

[Vaibhav Bedia]

On Mon, Nov 25, 2013 at 12:08 AM, Lokesh Vutla lokeshvu...@ti.com wrote:
 On Friday 22 November 2013 02:07 AM, Vaibhav Bedia wrote:
 On Thu, Nov 21, 2013 at 1:18 AM, Lokesh Vutla lokeshvu...@ti.com wrote:
 Updating the Multiplier and Dividers values for all DPLLs for EPOS EVM.
 Following are the DPLL locking frequencies at OPP NOM:
 MPU locks at 600MHz
 Core locks at 1000MHz
 Per locks at 960MHz
 DDR locks at 266MHz


 As mentioned earlier, this hardcoded frequency approach is really not
 scalable when you have
 more device variants coming in. Just look at the AM335x changes on how
 this gets complicated.
 We already had a discussion on this during V1 of this series.
 Sekhar and Tom replied to you comments. What is the point in asking the same 
 question again?


Because i don't recall any conclusion being reached on that thread? Because the
objective of a patch review is to come up with a solution which learns
from the past
and doesn't try to brush the past issues under the carpet under the
assumption that
the shiny new device will never have bugs?

 Since you are very concerned here. Why are you feeling it so complicated when 
 new variants come?
 We can always differentiate the new variant from the old ones and can pass 
 dpll structure accordingly. It is just a matter a one if condition.
 It ll be better to look at the current code and see how cleanly it is done.


As the OPP decoder table in the AM335x datasheet will tell you it's
not that simple.
Frankly, i could care less about this change...
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2 12/14] ARM: AM43xx: EPOS_EVM: Add support for LPDDR2

[Vaibhav Bedia]

On Mon, Nov 25, 2013 at 12:13 AM, Lokesh Vutla lokeshvu...@ti.com wrote:
 On Friday 22 November 2013 02:16 AM, Vaibhav Bedia wrote:
 On Thu, Nov 21, 2013 at 1:18 AM, Lokesh Vutla lokeshvu...@ti.com wrote:
 AM4372 EPOS EVM has 1GB LPDDR2(Part no: MT42L256M32D2LG-25 WT:A)
 Adding LPDDR2 init sequence and register details for the same.
 Below is the brief description of LPDDR2 init sequence:
 - Configure VTP
 - Configure DDR IO settings
 - Disable initialization and refreshes until EMIF registers are programmed.
 - Program Timing registers
 - Program PHY control and Temp alert and ZQ config registers.
 - Enable initialization and refreshes and configure SDRAM CONFIG register
 - Wait till initialization is complete and the configure MR registers.


 This patch does too many things, some of which affects AM335x and needs to be
 split up. I lost track of what you were doing as i scrolled down :\
 It does only two things. Update IO settings and emif configuration.
 I wanted to keep these things in a single patch so that if some functionality
 breaks down I can burn down to this patch.

That doesn't mean that you mix up everything in one humungous patch and
try to force your way through.


 Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
 ---
  arch/arm/cpu/armv7/am33xx/ddr.c|  147 
 +++-
  arch/arm/cpu/armv7/am33xx/emif4.c  |   25 +++-
  arch/arm/include/asm/arch-am33xx/clocks_am33xx.h   |3 +
  arch/arm/include/asm/arch-am33xx/cpu.h |5 +
  arch/arm/include/asm/arch-am33xx/ddr_defs.h|   33 -
  arch/arm/include/asm/arch-am33xx/hardware_am43xx.h |1 +
  arch/arm/include/asm/emif.h|   12 ++
  board/isee/igep0033/board.c|   10 +-
  board/phytec/pcm051/board.c|   12 +-
  board/siemens/dxr2/board.c |   10 +-
  board/siemens/pxm2/board.c |   10 +-
  board/siemens/rut/board.c  |   10 +-
  board/ti/am335x/board.c|   40 +-
  board/ti/am43xx/board.c|   66 +
  board/ti/ti814x/evm.c  |4 +-
  board/ti/ti816x/evm.c  |   12 +-
  16 files changed, 373 insertions(+), 27 deletions(-)

As the diffstat above shows, this patch affects a critical portion of AM335x,
TI81xx and and at the same time adds in support for a new SoC. If that's not
mixing up things i honestly don't know what is.

And if you have some discussions off-list you should at least attempt to capture
the summary of what was agreed to do taken up as TODO for the benefit of
others. If there's a agreed upon patch to improving the code that helps is
overlooking some short term compromises.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2 13/14] ARM: AM43xx: GP_EVM: Add support for DDR3

[Vaibhav Bedia]

On Mon, Nov 25, 2013 at 12:18 AM, Lokesh Vutla lokeshvu...@ti.com wrote:
 On Friday 22 November 2013 02:22 AM, Vaibhav Bedia wrote:
 On Thu, Nov 21, 2013 at 1:18 AM, Lokesh Vutla lokeshvu...@ti.com wrote:
 [...]

 -/*
 - * Get SDRAM type connected to EMIF.
 - * Assuming similar SDRAM parts are connected to both EMIF's
 - * which is typically the case. So it is sufficient to get
 - * SDRAM type from EMIF1.
 - */
 -u32 emif_sdram_type()
 -{
 -   struct emif_reg_struct *emif = (struct emif_reg_struct *)EMIF1_BASE;
 -
 -   return (readl(emif-emif_sdram_config) 
 -   EMIF_REG_SDRAM_TYPE_MASK)  EMIF_REG_SDRAM_TYPE_SHIFT;
 -}
 -
  static inline u32 get_mr(u32 base, u32 cs, u32 mr_addr)
  {
 u32 mr;
 diff --git a/arch/arm/include/asm/arch-am33xx/ddr_defs.h 
 b/arch/arm/include/asm/arch-am33xx/ddr_defs.h
 index c98ab7f..646e50f 100644
 --- a/arch/arm/include/asm/arch-am33xx/ddr_defs.h
 +++ b/arch/arm/include/asm/arch-am33xx/ddr_defs.h
 @@ -138,6 +138,14 @@
  #define  LPDDR2_DATA2_IOCTRL_VALUE   0x2294
  #define  LPDDR2_DATA3_IOCTRL_VALUE   0x2294

 +#define  DDR3_ADDRCTRL_WD0_IOCTRL_VALUE 0x
 +#define  DDR3_ADDRCTRL_WD1_IOCTRL_VALUE 0x
 +#define  DDR3_ADDRCTRL_IOCTRL_VALUE   0x84
 +#define  DDR3_DATA0_IOCTRL_VALUE   0x84
 +#define  DDR3_DATA1_IOCTRL_VALUE   0x84
 +#define  DDR3_DATA2_IOCTRL_VALUE   0x84
 +#define  DDR3_DATA3_IOCTRL_VALUE   0x84
 +
  /**
   * Configure DMM
   */
 diff --git a/arch/arm/include/asm/emif.h b/arch/arm/include/asm/emif.h
 index ce6b229..b4a8c9f 100644
 --- a/arch/arm/include/asm/emif.h
 +++ b/arch/arm/include/asm/emif.h
 @@ -1151,6 +1151,20 @@ static inline u32 get_emif_rev(u32 base)
  EMIF_REG_MAJOR_REVISION_SHIFT;
  }

 +/*
 + * Get SDRAM type connected to EMIF.
 + * Assuming similar SDRAM parts are connected to both EMIF's
 + * which is typically the case. So it is sufficient to get
 + * SDRAM type from EMIF1.
 + */
 +static inline u32 emif_sdram_type(void)
 +{
 +   struct emif_reg_struct *emif = (struct emif_reg_struct *)EMIF1_BASE;
 +
 +   return (readl(emif-emif_sdram_config) 
 +   EMIF_REG_SDRAM_TYPE_MASK)  EMIF_REG_SDRAM_TYPE_SHIFT;
 +}
 +

 This change don't make any sense to me. How are the EMIF register bits
 any indication
 of what memory time is used especially for DDR2/3?
 What is not making sense here ?
 If you go and read EMIF spec, it is clearly written that on coming out of 
 reset
 HW sequence starts according to the value populated in SDRAM config register.
 As far as I am concerned this is the best way to differentiate between 
 Memories.


Take a moment to think about where that register value comes from. Does it
somehow automagically get reconfigured when the chip is put in a board with
LPDDR2 vs DDR2 vs DDR3? While you are at it also look at the JEDEC specs
to figure out is there's some way to probe the DDR2/3 memory types.

 Can you tell me a better way to differentiate between memories in emif file ?
 Definitely  I should not use board_is_foo() functions.


AFAIK there is none and hence this way of trying to get the memory type
is broken.

Moreover, my understanding was that one of the prime functions of the EEPROM
board data was to enable differentiation between the memory types.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] ARM: mx6: Update non-Freescale boards to include CPU errata.

[Eric Nelson]

The CPU errata expressed in include/configs/mx6_common.h apply
to all i.MX6DQ and i.MX6DLS parts.

Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
---
 include/configs/nitrogen6x.h | 1 +
 include/configs/titanium.h   | 1 +
 include/configs/udoo.h   | 1 +
 include/configs/wandboard.h  | 1 +
 4 files changed, 4 insertions(+)

diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h
index 3df8de0..13718ca 100644
--- a/include/configs/nitrogen6x.h
+++ b/include/configs/nitrogen6x.h
@@ -10,6 +10,7 @@
 #ifndef __CONFIG_H
 #define __CONFIG_H
 
+#include mx6_common.h
 #define CONFIG_MX6
 #define CONFIG_DISPLAY_CPUINFO
 #define CONFIG_DISPLAY_BOARDINFO
diff --git a/include/configs/titanium.h b/include/configs/titanium.h
index 0bb6731..f9e00c5 100644
--- a/include/configs/titanium.h
+++ b/include/configs/titanium.h
@@ -13,6 +13,7 @@
 #ifndef __CONFIG_H
 #define __CONFIG_H
 
+#include mx6_common.h
 #include asm/arch/imx-regs.h
 #include asm/imx-common/gpio.h
 
diff --git a/include/configs/udoo.h b/include/configs/udoo.h
index 78df071..949be95 100644
--- a/include/configs/udoo.h
+++ b/include/configs/udoo.h
@@ -9,6 +9,7 @@
 #ifndef __CONFIG_H
 #define __CONFIG_H
 
+#include mx6_common.h
 #include asm/arch/imx-regs.h
 #include asm/imx-common/gpio.h
 #include asm/sizes.h
diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h
index e9c7e64..8ce2d6e 100644
--- a/include/configs/wandboard.h
+++ b/include/configs/wandboard.h
@@ -9,6 +9,7 @@
 #ifndef __CONFIG_H
 #define __CONFIG_H
 
+#include mx6_common.h
 #include asm/arch/imx-regs.h
 #include asm/imx-common/gpio.h
 #include asm/sizes.h
-- 
1.8.1.2

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

Re: [U-Boot] [PATCH] ARM: mx6: Update non-Freescale boards to include CPU errata.

[Fabio Estevam]

On Tue, Nov 26, 2013 at 10:40 PM, Eric Nelson
eric.nel...@boundarydevices.com wrote:
 The CPU errata expressed in include/configs/mx6_common.h apply
 to all i.MX6DQ and i.MX6DLS parts.

 Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com

Thanks, Eric.

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

Re: [U-Boot] [PATCH] ARM: mx6: Update non-Freescale boards to include CPU errata.

[Eric Nelson]

On 11/26/2013 05:57 PM, Fabio Estevam wrote:

On Tue, Nov 26, 2013 at 10:40 PM, Eric Nelson
eric.nel...@boundarydevices.com wrote:

The CPU errata expressed in include/configs/mx6_common.h apply
to all i.MX6DQ and i.MX6DLS parts.

Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com


Thanks, Eric.



No problem. If this is good enough for Freescale, it's
good enough for the riff-raff...


Reviewed-by: Fabio Estevam fabio.este...@freescale.com



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

Re: [U-Boot] [PATCH 0/9 v8] EXYNOS5420: Add SMDK5420 board support

[Minkyu Kang]

On 26/11/13 13:24, Rajeshwari Birje wrote:
 Hi Minkyu Kang.
 
 Please do let me know if any comments or can we get this merged?
 
 On Fri, Nov 15, 2013 at 10:29 AM, Rajeshwari S Shinde
 rajeshwar...@samsung.com wrote:
 This patch adds basic board support for SMDK5420 board.
 These patches are tested for booting fine on EVT1 SMDK5420.

 Changes in V2:
 - Corrected a compilation issue for SMDK5420.

 Changes in V3:
 - Add patch to support variable size SPL support
 - Add patch to disable SMU for eMMC.

 Changes in V4:
 - Added check for MAX77686 pmic compilation.
 - Added correct calculation of gpio based addresses.
 - Rebased on the latest u-boot code.
 - Removed patches for UART and TZPC changes as
 they were not needed.
 - Added flag to disable SMU for eMMC.

 Changes in V5:
 - Moved functions board_mmc_init and board_eth_init
 to common/board.c in case of device tree support.

 Changes in V6:
 - Rebased on the latest mainline branch.
 - Moved the definitions for SMU to arch/arm dwmmc.h

 Changes in V7:
 - Removed below patch as it is already merged
 DWMMC: SMDK5420: Disable SMU for eMMC
 - Corrected the multi line comments and removal of
 blank spaces and lines.
 - Corrected the license.

 Changes in V8:
 - corrected the if loops with if conditions of
 pro_id and cpu_id.

 Rajeshwari S Shinde (9):
   EXYNOS5: Create a common board file
   Exynos5420: Add base addresses for 5420
   Exynos5420: Add clock initialization for 5420
   Exynos5420: Add DDR3 initialization for 5420
   Exynos5420: Add support for 5420 in pinmux and gpio
   Exynos5420: Add base patch for SMDK5420
   DTS: Add dts support for SMDK5420
   Config: Add initial config for SMDK5420
   SPL: EXYNOS: Prepare for variable size SPL support

  arch/arm/cpu/armv7/exynos/clock.c  | 258 -
  arch/arm/cpu/armv7/exynos/clock_init.h |  17 +
  arch/arm/cpu/armv7/exynos/clock_init_exynos5.c | 352 +++-
  arch/arm/cpu/armv7/exynos/dmc_common.c |  10 +-
  arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c  | 421 +-
  arch/arm/cpu/armv7/exynos/exynos5_setup.h  | 738 
 +++--
  arch/arm/cpu/armv7/exynos/pinmux.c | 260 -
  arch/arm/dts/exynos5.dtsi  | 198 +++
  arch/arm/dts/exynos5250.dtsi   | 196 +--
  arch/arm/dts/exynos5420.dtsi   |  70 +++
  arch/arm/include/asm/arch-exynos/board.h   |  17 +
  arch/arm/include/asm/arch-exynos/clk.h |   1 +
  arch/arm/include/asm/arch-exynos/clock.h   | 494 +
  arch/arm/include/asm/arch-exynos/cpu.h |  51 +-
  arch/arm/include/asm/arch-exynos/dmc.h | 123 +++--
  arch/arm/include/asm/arch-exynos/gpio.h| 143 -
  arch/arm/include/asm/arch-exynos/periph.h  |   3 +
  board/samsung/common/Makefile  |   4 +
  board/samsung/common/board.c   | 407 ++
  board/samsung/dts/exynos5420-smdk5420.dts  | 169 ++
  board/samsung/smdk5250/exynos5-dt.c| 361 +---
  board/samsung/smdk5250/smdk5250.c  | 182 +-
  board/samsung/smdk5420/Makefile|  34 ++
  board/samsung/smdk5420/smdk5420.c  | 159 ++
  board/samsung/smdk5420/smdk5420_spl.c  |  52 ++
  boards.cfg |   1 +
  include/configs/arndale.h  |   1 +
  include/configs/exynos5-dt.h   | 300 ++
  include/configs/exynos5250-dt.h| 316 +--
  include/configs/smdk5420.h |  56 ++
  spl/Makefile   |   7 +-
  tools/Makefile |   3 +-
  tools/mkexynosspl.c| 167 --
  33 files changed, 4227 insertions(+), 1344 deletions(-)
  create mode 100644 arch/arm/dts/exynos5.dtsi
  create mode 100644 arch/arm/dts/exynos5420.dtsi
  create mode 100644 arch/arm/include/asm/arch-exynos/board.h
  create mode 100644 board/samsung/common/board.c
  create mode 100644 board/samsung/dts/exynos5420-smdk5420.dts
  create mode 100644 board/samsung/smdk5420/Makefile
  create mode 100644 board/samsung/smdk5420/smdk5420.c
  create mode 100644 board/samsung/smdk5420/smdk5420_spl.c
  create mode 100644 include/configs/exynos5-dt.h
  create mode 100644 include/configs/smdk5420.h

 --
 1.7.12.4

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

I already sent comments on your patches.
but, it does not reached at mailing list.
I don't know why.
Anyway sorry, I'll resend comments.

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

Re: [U-Boot] [PATCH] ARM: mx6: Update non-Freescale boards to include CPU errata.

[Stefan Roese]

On 27.11.2013 01:40, Eric Nelson wrote:
 The CPU errata expressed in include/configs/mx6_common.h apply
 to all i.MX6DQ and i.MX6DLS parts.
 
 Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com

Acked-by: Stefan Roese s...@denx.de

Thanks,
Stefan

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

Re: [U-Boot] [PATCH V2 12/14] ARM: AM43xx: EPOS_EVM: Add support for LPDDR2

[Lokesh Vutla]

On Wednesday 27 November 2013 05:42 AM, Vaibhav Bedia wrote:
 On Mon, Nov 25, 2013 at 12:13 AM, Lokesh Vutla lokeshvu...@ti.com wrote:
 On Friday 22 November 2013 02:16 AM, Vaibhav Bedia wrote:
 On Thu, Nov 21, 2013 at 1:18 AM, Lokesh Vutla lokeshvu...@ti.com wrote:
 AM4372 EPOS EVM has 1GB LPDDR2(Part no: MT42L256M32D2LG-25 WT:A)
 Adding LPDDR2 init sequence and register details for the same.
 Below is the brief description of LPDDR2 init sequence:
 - Configure VTP
 - Configure DDR IO settings
 - Disable initialization and refreshes until EMIF registers are 
 programmed.
 - Program Timing registers
 - Program PHY control and Temp alert and ZQ config registers.
 - Enable initialization and refreshes and configure SDRAM CONFIG register
 - Wait till initialization is complete and the configure MR registers.


 This patch does too many things, some of which affects AM335x and needs to 
 be
 split up. I lost track of what you were doing as i scrolled down :\
 It does only two things. Update IO settings and emif configuration.
 I wanted to keep these things in a single patch so that if some functionality
 breaks down I can burn down to this patch.
 
 That doesn't mean that you mix up everything in one humungous patch and
 try to force your way through.
OK, Ill separate out EMIF configuration and io settings and repost.
 
Thanks
Lokesh
 

 Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
 ---
  arch/arm/cpu/armv7/am33xx/ddr.c|  147 
 +++-
  arch/arm/cpu/armv7/am33xx/emif4.c  |   25 +++-
  arch/arm/include/asm/arch-am33xx/clocks_am33xx.h   |3 +
  arch/arm/include/asm/arch-am33xx/cpu.h |5 +
  arch/arm/include/asm/arch-am33xx/ddr_defs.h|   33 -
  arch/arm/include/asm/arch-am33xx/hardware_am43xx.h |1 +
  arch/arm/include/asm/emif.h|   12 ++
  board/isee/igep0033/board.c|   10 +-
  board/phytec/pcm051/board.c|   12 +-
  board/siemens/dxr2/board.c |   10 +-
  board/siemens/pxm2/board.c |   10 +-
  board/siemens/rut/board.c  |   10 +-
  board/ti/am335x/board.c|   40 +-
  board/ti/am43xx/board.c|   66 +
  board/ti/ti814x/evm.c  |4 +-
  board/ti/ti816x/evm.c  |   12 +-
  16 files changed, 373 insertions(+), 27 deletions(-)
 
 As the diffstat above shows, this patch affects a critical portion of AM335x,
 TI81xx and and at the same time adds in support for a new SoC. If that's not
 mixing up things i honestly don't know what is.
 
 And if you have some discussions off-list you should at least attempt to 
 capture
 the summary of what was agreed to do taken up as TODO for the benefit of
 others. If there's a agreed upon patch to improving the code that helps is
 overlooking some short term compromises.
 

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

Re: [U-Boot] [PATCH] mmc/dwmmc: remove recursive FIFO threshold setup

[Jaehoon Chung]

Hi, Alexey,

I think good that use the initial fifoth value at register.
Then we need not to change the value.
But according to my experiment, some SoC needs to change the fifoth value.

On 11/27/2013 12:08 AM, Alexey Brodkin wrote:
 Removed code works properly only once after power-up because on every
 first invocation of dwmci_init existing value of fifo_size is used
 for calculation of itself. More over other bits in the same register
 (namely TX watermark and burst size) get corrupted (lost forever till
 the next power-toggle).
 
 I understand that usually (in production systems) U-Boot starts only
 once and then passes control to Linux kernel etc. But when you do
 U-Boot debugging it might be loaded in memory via JTAG multiple times.
 
 Also I wasn't able to find any instance of host-fifoth_val usage so I
 believe it's safe to just remove this code completely.
If developer is need to change the fifoth value, the use the host-fifoth_val.
So it's existed.

 
 Another important thing - in the latest Linux kernel driver for DW MMC
 comtroller I don't see any utilization (configuration/modificatoin) of
 the register in question (SDMMC_FIFOTH). That's why I think we may want
 to keep it untouched as well so we don't force a situation when kernel
 driver gets DW MMC unexpectedly configured by U-Boot.
Right, if fifoth register is changed into U-boot,
then kernel driver use the value that fifoth register was set to value at 
U-Boot.
I known that kernel driver can set to the value with dt file.

Best Regards,
Jaehoon Chung
 
 Signed-off-by: Alexey Brodkin abrod...@synopsys.com
 
 Cc: Mischa Jonker mjon...@synopsys.com
 Cc: Alim Akhtar alim.akh...@samsung.com
 Cc: Rajeshwari Shinde rajeshwar...@samsung.com
 Cc: Jaehoon Chung jh80.ch...@samsung.com
 Cc: Amar amarendra...@samsung.com
 Cc: Kyungmin Park kyungmin.p...@samsung.com
 Cc: Hatim Ali hatim...@samsung.com
 Cc: Minkyu Kang mk7.k...@samsung.com
 Cc: Simon Glass s...@chromium.org
 Cc: Pantelis Antoniou pa...@antoniou-consulting.com
 Cc: Andy Fleming aflem...@freescale.com
 ---
  drivers/mmc/dw_mmc.c | 9 -
  include/dwmmc.h  | 1 -
  2 files changed, 10 deletions(-)
 
 diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
 index 1e0f72b..166124d 100644
 --- a/drivers/mmc/dw_mmc.c
 +++ b/drivers/mmc/dw_mmc.c
 @@ -300,7 +300,6 @@ static void dwmci_set_ios(struct mmc *mmc)
  static int dwmci_init(struct mmc *mmc)
  {
   struct dwmci_host *host = (struct dwmci_host *)mmc-priv;
 - u32 fifo_size;
  
   if (host-quirks  DWMCI_QUIRK_DISABLE_SMU) {
   dwmci_writel(host, EMMCP_MPSBEGIN0, 0);
 @@ -330,14 +329,6 @@ static int dwmci_init(struct mmc *mmc)
   dwmci_writel(host, DWMCI_IDINTEN, 0);
   dwmci_writel(host, DWMCI_BMOD, 1);
  
 - if (!host-fifoth_val) {
 - fifo_size = dwmci_readl(host, DWMCI_FIFOTH);
 - fifo_size = ((fifo_size  RX_WMARK_MASK)  RX_WMARK_SHIFT) + 1;
 - host-fifoth_val = MSIZE(0x2) | RX_WMARK(fifo_size / 2 - 1) |
 - TX_WMARK(fifo_size / 2);
 - }
 - dwmci_writel(host, DWMCI_FIFOTH, host-fifoth_val);
 -
   dwmci_writel(host, DWMCI_CLKENA, 0);
   dwmci_writel(host, DWMCI_CLKSRC, 0);
  
 diff --git a/include/dwmmc.h b/include/dwmmc.h
 index 6c91143..20cd1eb 100644
 --- a/include/dwmmc.h
 +++ b/include/dwmmc.h
 @@ -137,7 +137,6 @@ struct dwmci_host {
   int dev_index;
   int buswidth;
   u32 clksel_val;
 - u32 fifoth_val;
   struct mmc *mmc;
  
   void (*clksel)(struct dwmci_host *host);
 

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

Re: [U-Boot] [PATCH 3/9 v8] Exynos5420: Add clock initialization for 5420

[Minkyu Kang]

ping.

 Original Message 
Subject: Re: [PATCH 3/9 v8] Exynos5420: Add clock initialization for 5420
Date: Thu, 21 Nov 2013 16:03:23 +0900
From: Minkyu Kang mk7.k...@samsung.com
Organization: SAMSUNG ELECTRONICS
To: Rajeshwari S Shinde rajeshwar...@samsung.com
CC: u-boot@lists.denx.de, patc...@linaro.org, s...@chromium.org,  
chander.kash...@linaro.org, u-boot-rev...@google.com,  alim.akh...@samsung.com, 
tr...@ti.com

Dear Rajeshwari,

On 15/11/13 13:59, Rajeshwari S Shinde wrote:
 This patch adds code for clock initialization and clock settings
 of various IP's and controllers, required for Exynos5420
 
 Signed-off-by: Rajeshwari S Shinde rajeshwar...@samsung.com
 Signed-off-by: Akshay Saraswat aksha...@samsung.com
 Acked-by: Simon Glass s...@chromium.org
 ---
 Changes in V2:
   - None
 Changes in V3:
   - None
 Changes in V4:
   - Corrected the multiline commenting style
 Changes in V5:
   - None
 Changes in V6:
   - None
 Changes in V7:
   - Correct the logic for exynos5420_set_spi_clk api.
 Changes in V8:
   - Chnages the if condition loop for pro_id and cpu_id.
  arch/arm/cpu/armv7/exynos/clock.c  | 258 -
  arch/arm/cpu/armv7/exynos/clock_init.h |  17 +
  arch/arm/cpu/armv7/exynos/clock_init_exynos5.c | 352 +++-
  arch/arm/cpu/armv7/exynos/exynos5_setup.h  | 738 
 +++--
  arch/arm/include/asm/arch-exynos/clk.h |   1 +
  arch/arm/include/asm/arch-exynos/clock.h   | 494 +
  6 files changed, 1659 insertions(+), 201 deletions(-)
 
 diff --git a/arch/arm/cpu/armv7/exynos/clock_init_exynos5.c 
 b/arch/arm/cpu/armv7/exynos/clock_init_exynos5.c
 index a24c2f3..e7f1496 100644
 --- a/arch/arm/cpu/armv7/exynos/clock_init_exynos5.c
 +++ b/arch/arm/cpu/armv7/exynos/clock_init_exynos5.c
 @@ -24,6 +24,24 @@
  DECLARE_GLOBAL_DATA_PTR;
  
  struct arm_clk_ratios arm_clk_ratios[] = {
 +#ifdef CONFIG_EXYNOS5420
 + {
 + .arm_freq_mhz = 900,
 +
 + .apll_mdiv = 0x96,
 + .apll_pdiv = 0x2,
 + .apll_sdiv = 0x1,
 +
 + .arm2_ratio = 0x0,
 + .apll_ratio = 0x3,
 + .pclk_dbg_ratio = 0x6,
 + .atb_ratio = 0x6,
 + .periph_ratio = 0x7,
 + .acp_ratio = 0x0,
 + .cpud_ratio = 0x2,
 + .arm_ratio = 0x0,
 + }
 +#else
   {
   .arm_freq_mhz = 600,
  
 @@ -115,8 +133,133 @@ struct arm_clk_ratios arm_clk_ratios[] = {
   .cpud_ratio = 0x3,
   .arm_ratio = 0x0,
   }
 +#endif
  };
 +
  struct mem_timings mem_timings[] = {
 +#ifdef CONFIG_EXYNOS5420
 + {
 + .mem_manuf = MEM_MANUF_SAMSUNG,
 + .mem_type = DDR_MODE_DDR3,
 + .frequency_mhz = 800,
 +
 + /* MPLL @800MHz*/
 + .mpll_mdiv = 0xc8,
 + .mpll_pdiv = 0x3,
 + .mpll_sdiv = 0x1,
 + /* CPLL @666MHz */
 + .cpll_mdiv = 0xde,
 + .cpll_pdiv = 0x4,
 + .cpll_sdiv = 0x1,
 + /* EPLL @600MHz */
 + .epll_mdiv = 0x64,
 + .epll_pdiv = 0x2,
 + .epll_sdiv = 0x1,
 + /* VPLL @430MHz */
 + .vpll_mdiv = 0xd7,
 + .vpll_pdiv = 0x3,
 + .vpll_sdiv = 0x2,
 + /* BPLL @800MHz */
 + .bpll_mdiv = 0xc8,
 + .bpll_pdiv = 0x3,
 + .bpll_sdiv = 0x1,
 + /* KPLL @600MHz */
 + .kpll_mdiv = 0x190,
 + .kpll_pdiv = 0x4,
 + .kpll_sdiv = 0x2,
 + /* DPLL @600MHz */
 + .dpll_mdiv = 0x190,
 + .dpll_pdiv = 0x4,
 + .dpll_sdiv = 0x2,
 + /* IPLL @370MHz */
 + .ipll_mdiv = 0xb9,
 + .ipll_pdiv = 0x3,
 + .ipll_sdiv = 0x2,
 + /* SPLL @400MHz */
 + .spll_mdiv = 0xc8,
 + .spll_pdiv = 0x3,
 + .spll_sdiv = 0x2,
 +
 + .direct_cmd_msr = {
 + 0x00020018, 0x0003, 0x00010046, 0x0d70,
 + 0x0c70
 + },
 + .timing_ref = 0x00bb,
 + .timing_row = 0x6836650f,
 + .timing_data = 0x3630580b,
 + .timing_power = 0x41000a26,
 + .phy0_dqs = 0x08080808,
 + .phy1_dqs = 0x08080808,
 + .phy0_dq = 0x08080808,
 + .phy1_dq = 0x08080808,
 + .phy0_tFS = 0x8,
 + .phy1_tFS = 0x8,
 + .phy0_pulld_dqs = 0xf,
 + .phy1_pulld_dqs = 0xf,
 +
 + .lpddr3_ctrl_phy_reset = 0x1,
 + .ctrl_start_point = 0x10,
 + .ctrl_inc = 0x10,
 + .ctrl_start = 0x1,
 + .ctrl_dll_on = 0x1,
 + .ctrl_ref = 0x8,
 +
 + .ctrl_force = 0x1a,
 + .ctrl_rdlat = 0x0b,
 + .ctrl_bstlen = 0x08,
 +
 + 

Re: [U-Boot] [PATCH 6/9 v8] Exynos5420: Add base patch for SMDK5420

[Minkyu Kang]

ping.

 Original Message 
Subject: Re: [PATCH 6/9 v8] Exynos5420: Add base patch for SMDK5420
Date: Thu, 21 Nov 2013 16:24:14 +0900
From: Minkyu Kang mk7.k...@samsung.com
Organization: SAMSUNG ELECTRONICS
To: Rajeshwari S Shinde rajeshwar...@samsung.com
CC: u-boot@lists.denx.de, patc...@linaro.org, s...@chromium.org,  
chander.kash...@linaro.org, u-boot-rev...@google.com,  alim.akh...@samsung.com, 
tr...@ti.com

Dear Rajeshwari,

On 15/11/13 13:59, Rajeshwari S Shinde wrote:
 Adding the base patch for Exynos based SMDK5420.
 This shall enable compilation and basic boot support for
 SMDK5420.
 
 Signed-off-by: Rajeshwari S Shinde rajeshwar...@samsung.com
 Signed-off-by: Akshay Saraswat aksha...@samsung.com
 ---
 Changes in V2:
   - None
 Changes in V3:
   - None
 Changes in V4:
   - Rebased on latest u-boot-samsung tree.
 Changes in V5:
   - Removed functions board_eth_init and board_mmc_init
   as they were moved to common/board.c
 Changes in V6:
   - None
 Changes in V7:
   - added CONFIG_EXYNOS_SPL to build 5420 and 5250  
 Changes in V8:
   - None
  board/samsung/common/board.c  |   2 +
  board/samsung/smdk5420/Makefile   |  34 
  board/samsung/smdk5420/smdk5420.c | 159 
 ++
  board/samsung/smdk5420/smdk5420_spl.c |  52 +++
  boards.cfg|   1 +
  include/configs/arndale.h |   1 +
  include/configs/exynos5250-dt.h   |   1 +
  tools/Makefile|   3 +-
  8 files changed, 252 insertions(+), 1 deletion(-)
  create mode 100644 board/samsung/smdk5420/Makefile
  create mode 100644 board/samsung/smdk5420/smdk5420.c
  create mode 100644 board/samsung/smdk5420/smdk5420_spl.c
 
 diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
 index 9ebfc42..2512a59 100644
 --- a/board/samsung/common/board.c
 +++ b/board/samsung/common/board.c
 @@ -143,6 +143,7 @@ struct cros_ec_dev *board_get_cros_ec_dev(void)
   return local.cros_ec_dev;
  }
  
 +#ifdef CONFIG_CROS_EC
  static int board_init_cros_ec_devices(const void *blob)
  {
   local.cros_ec_err = cros_ec_init(blob, local.cros_ec_dev);
 @@ -151,6 +152,7 @@ static int board_init_cros_ec_devices(const void *blob)
  
   return 0;
  }
 +#endif
  
  #if defined(CONFIG_POWER)
  #ifdef CONFIG_POWER_MAX77686
 diff --git a/board/samsung/smdk5420/Makefile b/board/samsung/smdk5420/Makefile
 new file mode 100644
 index 000..be538ec
 --- /dev/null
 +++ b/board/samsung/smdk5420/Makefile
 @@ -0,0 +1,34 @@
 +#
 +# Copyright (C) 2013 Samsung Electronics
 +#
 +# SPDX-License-Identifier:   GPL-2.0+
 +#
 +
 +include $(TOPDIR)/config.mk
 +
 +LIB  = $(obj)lib$(BOARD).o
 +
 +COBJS+= smdk5420_spl.o
 +
 +ifndef CONFIG_SPL_BUILD
 +COBJS+= smdk5420.o
 +endif
 +
 +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
 +OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS))
 +
 +ALL  :=   $(obj).depend $(LIB)
 +
 +all: $(ALL)
 +
 +$(LIB):  $(OBJS)
 + $(call cmd_link_o_target, $(OBJS))
 +
 +#
 +
 +# defines $(obj).depend target
 +include $(SRCTREE)/rules.mk
 +
 +sinclude $(obj).depend
 +
 +#
 diff --git a/board/samsung/smdk5420/smdk5420.c 
 b/board/samsung/smdk5420/smdk5420.c
 new file mode 100644
 index 000..d85b953
 --- /dev/null
 +++ b/board/samsung/smdk5420/smdk5420.c
 @@ -0,0 +1,159 @@
 +/*
 + * Copyright (C) 2013 Samsung Electronics
 + *
 + * SPDX-License-Identifier:  GPL-2.0+
 + */
 +
 +#include common.h
 +#include fdtdec.h
 +#include asm/io.h
 +#include i2c.h
 +#include lcd.h
 +#include spi.h
 +#include asm/arch/board.h
 +#include asm/arch/cpu.h
 +#include asm/arch/gpio.h
 +#include asm/arch/pinmux.h
 +#include asm/arch/dp_info.h
 +
 +DECLARE_GLOBAL_DATA_PTR;
 +
 +#ifdef CONFIG_USB_EHCI_EXYNOS
 +static int board_usb_vbus_init(void)
 +{
 + struct exynos5_gpio_part1 *gpio1 = (struct exynos5_gpio_part1 *)
 + samsung_get_base_gpio_part1();
 +
 + /* Enable VBUS power switch */
 + s5p_gpio_direction_output(gpio1-x2, 6, 1);
 +
 + /* VBUS turn ON time */
 + mdelay(3);
 +
 + return 0;
 +}
 +#endif
 +
 +int exynos_init(void)
 +{
 +#ifdef CONFIG_USB_EHCI_EXYNOS
 + board_usb_vbus_init();
 +#endif
 + return 0;
 +}
 +
 +#ifdef CONFIG_LCD
 +void cfg_lcd_gpio(void)
 +{
 + struct exynos5_gpio_part1 *gpio1 =
 + (struct exynos5_gpio_part1 *)samsung_get_base_gpio_part1();
 +
 + /* For Backlight */
 + s5p_gpio_cfg_pin(gpio1-b2, 0, GPIO_OUTPUT);
 + s5p_gpio_set_value(gpio1-b2, 0, 1);
 +
 + /* LCD power on */
 + s5p_gpio_cfg_pin(gpio1-x1, 5, GPIO_OUTPUT);
 + s5p_gpio_set_value(gpio1-x1, 5, 1);
 +
 + /* Set Hotplug detect for DP */
 + s5p_gpio_cfg_pin(gpio1-x0, 7, GPIO_FUNC(0x3));
 +}
 +
 +vidinfo_t panel_info = {
 + .vl_freq

Re: [U-Boot] [PATCH 8/9 v8] Config: Add initial config for SMDK5420

[Minkyu Kang]

ping.

 Original Message 
Subject: Re: [PATCH 8/9 v8] Config: Add initial config for SMDK5420
Date: Thu, 21 Nov 2013 16:32:32 +0900
From: Minkyu Kang mk7.k...@samsung.com
Organization: SAMSUNG ELECTRONICS
To: Rajeshwari S Shinde rajeshwar...@samsung.com
CC: u-boot@lists.denx.de, patc...@linaro.org, s...@chromium.org,  
chander.kash...@linaro.org, u-boot-rev...@google.com,  alim.akh...@samsung.com, 
tr...@ti.com

Dear Rajeshwari,

On 15/11/13 13:59, Rajeshwari S Shinde wrote:
 Adding initial config for SMDK5420 to build and boot U-Boot
 over Exynos based SMDK5420.
 
 Signed-off-by: Rajeshwari S Shinde rajeshwar...@samsung.com
 Signed-off-by: Akshay Saraswat aksha...@samsung.com
 Acked-by: Simon Glass s...@chromium.org
 ---
 Changes in V2:
   - None
 Changes in V3:
   - None
 Changes in V4:
   - Created a common exynos5-dt.h
 Changes in V5:
   - None
 Changes in V6:
   - None
 Chnages in V7:
   - Corrected the coding style nits.
 Changes in V8:
   - None
  include/configs/exynos5-dt.h| 300 +
  include/configs/exynos5250-dt.h | 319 
 +---
  include/configs/smdk5420.h  |  49 ++
  3 files changed, 357 insertions(+), 311 deletions(-)
  create mode 100644 include/configs/exynos5-dt.h
  create mode 100644 include/configs/smdk5420.h
 
 diff --git a/include/configs/exynos5-dt.h b/include/configs/exynos5-dt.h
 new file mode 100644
 index 000..2b3714f
 --- /dev/null
 +++ b/include/configs/exynos5-dt.h
 @@ -0,0 +1,300 @@
 +/*
 + * Copyright (C) 2013 Samsung Electronics
 + *
 + * Configuration settings for the SAMSUNG EXYNOS5 board.
 + *
 + * SPDX-License-Identifier:  GPL-2.0+
 + */
 +
 +#ifndef __CONFIG_H
 +#define __CONFIG_H
 +
 +/* High Level Configuration Options */
 +#define CONFIG_SAMSUNG   /* in a SAMSUNG core */
 +#define CONFIG_S5P   /* S5P Family */
 +#define CONFIG_EXYNOS5   /* which is in a Exynos5 Family 
 */
 +
 +#include asm/arch/cpu.h/* get chip and board defs */
 +
 +#define CONFIG_SYS_GENERIC_BOARD
 +#define CONFIG_ARCH_CPU_INIT
 +#define CONFIG_DISPLAY_CPUINFO
 +#define CONFIG_DISPLAY_BOARDINFO
 +#define CONFIG_BOARD_COMMON
 +#define CONFIG_ARCH_EARLY_INIT_R
 +#define CONFIG_EXYNOS_SPL
 +
 +/* Enable fdt support for Exynos5250 */
 +#define CONFIG_OF_CONTROL
 +#define CONFIG_OF_SEPARATE
 +
 +/* Allow tracing to be enabled */
 +#define CONFIG_TRACE
 +#define CONFIG_CMD_TRACE
 +#define CONFIG_TRACE_BUFFER_SIZE (16  20)
 +#define CONFIG_TRACE_EARLY_SIZE  (8  20)
 +#define CONFIG_TRACE_EARLY
 +#define CONFIG_TRACE_EARLY_ADDR  0x5000
 +
 +/* Keep L2 Cache Disabled */
 +#define CONFIG_SYS_DCACHE_OFF
 +
 +/* Enable ACE acceleration for SHA1 and SHA256 */
 +#define CONFIG_EXYNOS_ACE_SHA
 +#define CONFIG_SHA_HW_ACCEL
 +
 +/* input clock of PLL: SMDK5250 has 24MHz input clock */
 +#define CONFIG_SYS_CLK_FREQ  2400
 +
 +#define CONFIG_SETUP_MEMORY_TAGS
 +#define CONFIG_CMDLINE_TAG
 +#define CONFIG_INITRD_TAG
 +#define CONFIG_CMDLINE_EDITING
 +
 +/* Power Down Modes */
 +#define S5P_CHECK_SLEEP  0x0BAD
 +#define S5P_CHECK_DIDLE  0xBAD0
 +#define S5P_CHECK_LPA0xABAD
 +
 +/* Offset for inform registers */
 +#define INFORM0_OFFSET   0x800
 +#define INFORM1_OFFSET   0x804
 +#define INFORM2_OFFSET   0x808
 +#define INFORM3_OFFSET   0x80c
 +
 +/* Size of malloc() pool */
 +#define CONFIG_SYS_MALLOC_LEN(CONFIG_ENV_SIZE + (4  20))
 +
 +/* select serial console configuration */
 +#define CONFIG_BAUDRATE  115200
 +#define EXYNOS5_DEFAULT_UART_OFFSET  0x01
 +#define CONFIG_SILENT_CONSOLE
 +
 +/* Enable keyboard */
 +#define CONFIG_CROS_EC   /* CROS_EC protocol */
 +#define CONFIG_CROS_EC_SPI   /* Support CROS_EC over SPI */
 +#define CONFIG_CROS_EC_I2C   /* Support CROS_EC over I2C */
 +#define CONFIG_CROS_EC_KEYB  /* CROS_EC keyboard input */
 +#define CONFIG_CMD_CROS_EC
 +#define CONFIG_KEYBOARD
 +
 +/* Console configuration */
 +#define CONFIG_CONSOLE_MUX
 +#define CONFIG_SYS_CONSOLE_IS_IN_ENV
 +#define EXYNOS_DEVICE_SETTINGS \
 + stdin=serial,cros-ec-keyb\0 \
 + stdout=serial,lcd\0 \
 + stderr=serial,lcd\0
 +
 +#define CONFIG_EXTRA_ENV_SETTINGS \
 + EXYNOS_DEVICE_SETTINGS
 +
 +/* SD/MMC configuration */
 +#define CONFIG_GENERIC_MMC
 +#define CONFIG_MMC
 +#define CONFIG_SDHCI
 +#define CONFIG_S5P_SDHCI
 +#define CONFIG_DWMMC
 +#define CONFIG_EXYNOS_DWMMC
 +#define CONFIG_SUPPORT_EMMC_BOOT
 +
 +#define CONFIG_BOARD_EARLY_INIT_F
 +#define CONFIG_SKIP_LOWLEVEL_INIT
 +
 +/* PWM */
 +#define CONFIG_PWM
 +
 +/* allow to overwrite serial and ethaddr */
 +#define CONFIG_ENV_OVERWRITE
 +
 +/* Command definition*/
 +#include 

Re: [U-Boot] [PATCH 4/9 v8] Exynos5420: Add DDR3 initialization for 5420

[Minkyu Kang]

ping.

 Original Message 
Subject: Re: [PATCH 4/9 v8] Exynos5420: Add DDR3 initialization for 5420
Date: Thu, 21 Nov 2013 16:13:24 +0900
From: Minkyu Kang mk7.k...@samsung.com
Organization: SAMSUNG ELECTRONICS
To: Rajeshwari S Shinde rajeshwar...@samsung.com
CC: u-boot@lists.denx.de, patc...@linaro.org, s...@chromium.org,  
chander.kash...@linaro.org, u-boot-rev...@google.com,  alim.akh...@samsung.com, 
tr...@ti.com

Dear Rajeshwari,

On 15/11/13 13:59, Rajeshwari S Shinde wrote:
 This patch intends to add DDR3 initialization code for Exynos5420.
 
 Signed-off-by: Rajeshwari S Shinde rajeshwar...@samsung.com
 Signed-off-by: Akshay Saraswat aksha...@samsung.com
 Acked-by: Simon Glass s...@chromium.org
 ---
 Changes in V2:
   - Corrected a compilation issue for SMDK5250.
 Changes in V3:
   - None
 Changes in V4:
   - None
 Changes in V5:
   - None
 Changes in V6:
   - None
 Changes in V7:
   - Fixed multi line comment.
 Changes in V8:
   - None
  arch/arm/cpu/armv7/exynos/dmc_common.c|  10 +-
  arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c | 421 
 +-
  arch/arm/include/asm/arch-exynos/cpu.h|   4 +
  arch/arm/include/asm/arch-exynos/dmc.h| 123 ++---
  4 files changed, 513 insertions(+), 45 deletions(-)
 
 diff --git a/arch/arm/cpu/armv7/exynos/dmc_common.c 
 b/arch/arm/cpu/armv7/exynos/dmc_common.c
 index 53cfe6e..9e432c2 100644
 --- a/arch/arm/cpu/armv7/exynos/dmc_common.c
 +++ b/arch/arm/cpu/armv7/exynos/dmc_common.c
 @@ -1,5 +1,5 @@
  /*
 - * Mem setup common file for different types of DDR present on SMDK5250 
 boards.
 + * Mem setup common file for different types of DDR present on Exynos boards.
   *
   * Copyright (C) 2012 Samsung Electronics
   *
 @@ -152,14 +152,6 @@ void dmc_config_prech(struct mem_timings *mem, struct 
 exynos5_dmc *dmc)
   }
  }
  
 -void dmc_config_memory(struct mem_timings *mem, struct exynos5_dmc *dmc)
 -{
 - writel(mem-memconfig, dmc-memconfig0);
 - writel(mem-memconfig, dmc-memconfig1);
 - writel(DMC_MEMBASECONFIG0_VAL, dmc-membaseconfig0);
 - writel(DMC_MEMBASECONFIG1_VAL, dmc-membaseconfig1);
 -}
 -
  void mem_ctrl_init(int reset)
  {
   struct spl_machine_param *param = spl_get_machine_params();
 diff --git a/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c 
 b/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c
 index 5f5914e..3fab50b 100644
 --- a/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c
 +++ b/arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c
 @@ -1,5 +1,5 @@
  /*
 - * DDR3 mem setup file for SMDK5250 board based on EXYNOS5
 + * DDR3 mem setup file for board based on EXYNOS5
   *
   * Copyright (C) 2012 Samsung Electronics
   *
 @@ -15,8 +15,9 @@
  #include exynos5_setup.h
  #include clock_init.h
  
 -#define RDLVL_COMPLETE_TIMEOUT   1
 +#define TIMEOUT  1
  
 +#ifdef CONFIG_EXYNOS5250
  static void reset_phy_ctrl(void)
  {
   struct exynos5_clock *clk =
 @@ -108,7 +109,7 @@ int ddr3_mem_ctrl_init(struct mem_timings *mem, unsigned 
 long mem_iv_size,
  
   /* Precharge Configuration */
   writel(mem-prechconfig_tp_cnt  PRECHCONFIG_TP_CNT_SHIFT,
 -dmc-prechconfig);
 +dmc-prechconfig0);
  
   /* Power Down mode Configuration */
   writel(mem-dpwrdn_cyc  PWRDNCONFIG_DPWRDN_CYC_SHIFT |
 @@ -174,7 +175,7 @@ int ddr3_mem_ctrl_init(struct mem_timings *mem, unsigned 
 long mem_iv_size,
   writel(val, phy1_ctrl-phy_con1);
  
   writel(CTRL_RDLVL_GATE_ENABLE, dmc-rdlvl_config);
 - i = RDLVL_COMPLETE_TIMEOUT;
 + i = TIMEOUT;
   while ((readl(dmc-phystatus) 
   (RDLVL_COMPLETE_CHO | RDLVL_COMPLETE_CH1)) !=
   (RDLVL_COMPLETE_CHO | RDLVL_COMPLETE_CH1)  i  0) {
 @@ -215,3 +216,415 @@ int ddr3_mem_ctrl_init(struct mem_timings *mem, 
 unsigned long mem_iv_size,
   | (mem-aref_en  CONCONTROL_AREF_EN_SHIFT), dmc-concontrol);
   return 0;
  }
 +#endif
 +
 +#ifdef CONFIG_EXYNOS5420
 +int ddr3_mem_ctrl_init(struct mem_timings *mem, unsigned long mem_iv_size,
 +int reset)
 +{
 + struct exynos5420_clock *clk =
 + (struct exynos5420_clock *)EXYNOS5_CLOCK_BASE;

samsung_get_base_clock();

 + struct exynos5_phy_control *phy0_ctrl, *phy1_ctrl;
 + struct exynos5_dmc *drex0, *drex1;
 + struct exynos5_tzasc *tzasc0, *tzasc1;
 + uint32_t val, n_lock_r, n_lock_w_phy0, n_lock_w_phy1;
 + int chip;
 + int i;
 +
 + phy0_ctrl = (struct exynos5_phy_control *)samsung_get_base_dmc_phy();
 + phy1_ctrl = (struct exynos5_phy_control *)(samsung_get_base_dmc_phy()
 + + DMC_OFFSET);
 + drex0 = (struct exynos5_dmc *)samsung_get_base_dmc_ctrl();
 + drex1 = (struct exynos5_dmc *)(samsung_get_base_dmc_ctrl()
 + + DMC_OFFSET);
 + tzasc0 = (struct exynos5_tzasc 

Re: [U-Boot] i.MX6 freeze when running Linux FSL 3.10.9-1.0.0-alpha AND U-Boot 2013.10

[Wolfgang Denk]

Dear Otavio Salvador,

In message CAP9ODKqBwH+LfhTcPMBn1ppUtfpfUnUyyN8CTi=akwja1ka...@mail.gmail.com 
you wrote:

  Do I understand correctly that this happens only with the FSL kernel,
  i. e. not with mainline Linux?
 
 Exactly.
 
  What exactly is the effect of calling your set_anatop_bypass()
  function?  Why would that be needed on the FSL kernel, and not on
  mainline?
 
 Mainline seems to not drive the pmic while the FSL kernel does. So it
 seems we ought to bypass the internal LDO.

Or rather fix the FSL kernel?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The right word may be effective, but no word was ever as effective as
a rightly timed pause.   - Mark Twain
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2 10/14] ARM: AM43xx: clocks: Update DPLL details for EPOS EVM

[Lokesh Vutla]

On Wednesday 27 November 2013 05:36 AM, Vaibhav Bedia wrote:
 On Mon, Nov 25, 2013 at 12:08 AM, Lokesh Vutla lokeshvu...@ti.com wrote:
 On Friday 22 November 2013 02:07 AM, Vaibhav Bedia wrote:
 On Thu, Nov 21, 2013 at 1:18 AM, Lokesh Vutla lokeshvu...@ti.com wrote:
 Updating the Multiplier and Dividers values for all DPLLs for EPOS EVM.
 Following are the DPLL locking frequencies at OPP NOM:
 MPU locks at 600MHz
 Core locks at 1000MHz
 Per locks at 960MHz
 DDR locks at 266MHz


 As mentioned earlier, this hardcoded frequency approach is really not
 scalable when you have
 more device variants coming in. Just look at the AM335x changes on how
 this gets complicated.
 We already had a discussion on this during V1 of this series.
 Sekhar and Tom replied to you comments. What is the point in asking the same 
 question again?

 
 Because i don't recall any conclusion being reached on that thread? Because 
 the
 objective of a patch review is to come up with a solution which learns
 from the past
 and doesn't try to brush the past issues under the carpet under the
 assumption that
 the shiny new device will never have bugs?
Yes I agree with you point.
But I have replied to this thread saying that 
Currently these values are not blown in eFuse. Both EPOS and GP evms support 
OPP NOM. So there is no harm in booting at OPP NOM here.
You haven't come back on that. 

 
 Since you are very concerned here. Why are you feeling it so complicated 
 when new variants come?
 We can always differentiate the new variant from the old ones and can pass 
 dpll structure accordingly. It is just a matter a one if condition.
 It ll be better to look at the current code and see how cleanly it is done.

 
 As the OPP decoder table in the AM335x datasheet will tell you it's
 not that simple.
I guess your previous comment was about the code complexity when a new variant 
of the board comes.
Coming to OPP tables:
Frankly, I don't know what happened during AM33xx times. I am just trying to 
make things simpler and cleaner.
Do you mean here, we need to support  all OPPs in U-Boot?
Are you expecting complete OPP table to get from e-fuse values for AM43xx?

As per my understanding from working on OMAP, U-Boot supports only OPP_NOM( or 
the safe OPP to boot).

Please correct me if I am wrong.

Thanks and regards,
Lokesh 
 Frankly, i could care less about this change...
 

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

Re: [U-Boot] [ANN] v2014.01-rc1

[Masahiro Yamada]

Hello.

 As always, please speak up if something suddenly broke or you've found a
 problem of some sort.  Thanks all!

I noticed at least two boards got broken by v2014.01-rc release:
cam_enc_4xx and linkstation_HGLAN


I bisected and

68ec9c85a9d334c7598b4972af037de05c034f8d is the first bad commit
for cam_enc_4xx board.


commit 68ec9c85a9d334c7598b4972af037de05c034f8d
Author: Prabhakar Kushwaha prabha...@freescale.com
Date:   Fri Oct 4 13:47:58 2013 +0530

mtd: move  update nand_ecclayout structure (plus board changes)



22ece0e2e23c5cc5a23a5b8aff3dc75c9832e82f is the first bad commit
for linkstation_HGLAN board.


commit 22ece0e2e23c5cc5a23a5b8aff3dc75c9832e82f
Author: Thierry Reding thierry.red...@gmail.com
Date:   Fri Sep 20 16:03:42 2013 +0200

net: rtl8169: Improve cache maintenance



Best Regards
Masahiro Yamada

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

Re: [U-Boot] [PATCH] mmc/dwmmc: remove recursive FIFO threshold setup

[Pantelis Antoniou]

Hi Alexey,

On Nov 27, 2013, at 9:11 AM, Alexey Brodkin wrote:

 Hi Jaehoon,
 
 On Wed, 2013-11-27 at 14:33 +0900, Jaehoon Chung wrote:
 Hi, Alexey,
 
 I think good that use the initial fifoth value at register.
 Then we need not to change the value.
 But according to my experiment, some SoC needs to change the fifoth value.
 
 
 Ok, so let's leave possibility to set fifoth manually (if
 host-fifoth_val != 0 then use provided value; else do nothing) on mmc
 controller instantiation.
 
 Will it work for you?
 

ATM if no host-fifoth_val value is provided the code will calculate one and 
write it.
Otherwise it will write the one configured.

 Still I have a couple of questions to you:
 1. Why there's no example/instance of host-fifoth_val setup/usage in
 U-Boot source tree? If there was at least one I would leave
 host-fifoth_val.
 

I would guess it's because everyone uses the default setting of 0 which
results in a somewhat sane value.

 2. How come there's no way to set/modify the register in question in
 Linux kernel? Don't people use Linux kernel on mentioned selected SoCs
 without U-Boot (i.e. fifoth gets set by U-Boot before kernel starts)?
 

That's a good question for the kernel driver devs.

 Regards,
 Alexey

Regards

-- Pantelis

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

Re: [U-Boot] [PATCH] ARM: mx6: Remove the FDT loading address to avoid overlaping

[Stefano Babic]

Hi Otavio,

On 26/11/2013 13:16, Otavio Salvador wrote:
 I'm going to suggest this is the wrong path.  Once you see i.MX systems
 with  768MB DDR you're going to have initrd/fdt placed into memory
 Linux can't access without HIGHMEM on, and you need the FDT before then.
 
 I didn't catch this case but it is a valid problem, indeed :-(

I missed this issue, too :-(

Does it work with your patch ? Most supported i.MX6 boards have more as
768MB, and I am wondering that all kernels can boot.

 
 Fabio/Stefano what is your call here? I think moving it to 128MB is
 good for now.

Yes, it seems this becomes our choice.

Best regards,
Stefano

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