Re: [U-Boot] new uboot for custom platform

[Olliver Schinagl]

On 06-12-13 05:03, Abraham V. wrote:

A VERY vague question. The only thing you are correct on, is that the
bootloader is the first software component that runs when starting a
system. But as Michael replied, without further details like CPU,
memory ... etc, there's very little information you've given us to
help you.

Now, on the other hand, if you are just fishing for information about
embedded and android, I would suggest you buy a beaglebone. Android
has been ported to it and you'll have a better idea of how things work
by studying the related source code and hardware datasheets.

Also extremly interesting are the Allwinner based boards.

Board such as the Olimex Olinuxino's are open source hardware 
(schematics etc available via their github) and are supported (out of 
tree unfortunately for now, but tree is being pulled regularly) by 
u-boot and linux. Usermanuals/datasheets are available for A10, A13 and 
A20 series of chips to study.


Oliver


-Abraham V.

On Thu, Dec 5, 2013 at 5:33 PM, Cornel Miron cornel.miro...@gmail.com wrote:

Hello,
I'm new to everything about android and I try to start android on a custom
platform. How can I build the bootloaders and to put android os on that
platform.
Can someone help me?

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


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



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

[U-Boot] Pull request: u-boot-blackfin

[Sonic Zhang]

Hi Tom,

Please pull the following patches from u-boot-blackfin into your tree.

Thanks

Sonic Zhang


The following changes since commit f44483b57c49282299da0e5c10073b909cdad979:

  Merge branch 'serial' of git://git.denx.de/u-boot-microblaze
(2013-12-02 08:48:02 -0500)

are available in the git repository at:


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

for you to fetch changes up to 985e18d14e0cb3933311945d30de6357cf8be9df:

  blackfin: Do not generate unused header bootrom-asm-offsets.h
(2013-12-06 16:06:51 +0800)


Axel Lin (2):
  spi: bfin_spi: Remove unnecessary test for bus and pins[bus]
  spi: bfin_spi6xx: Remove unnecessary test for bus and pins[bus]

Masahiro Yamada (1):
  blackfin: Do not generate unused header bootrom-asm-offsets.h

Sonic Zhang (4):
  blackfin: Use ADI_GPIO2 driver other than the default ADI_GPIO1
  blackfin: If none ADI_GPIOX macro is defined, use ADI_GPIO1 as default
  blackfin: Add missing macro CONFIG_BFIN_SERIAL
  blackfin: soft-i2c: No need to define blackfin specific soft i2c
operations

 Makefile   |  1 -
 arch/blackfin/cpu/.gitignore   |  2 --
 arch/blackfin/cpu/Makefile | 10 
 arch/blackfin/cpu/bootrom-asm-offsets.awk  | 41 --
 arch/blackfin/cpu/bootrom-asm-offsets.c.in | 12 -
 arch/blackfin/cpu/gpio.c   |  2 +-
 arch/blackfin/include/asm/gpio.h   |  2 +-
 drivers/spi/bfin_spi.c | 17 +++--
 drivers/spi/bfin_spi6xx.c  |  5 +---
 include/configs/bf506f-ezkit.h |  1 +
 include/configs/bf525-ucr2.h   |  1 +
 include/configs/bf533-stamp.h  | 29 ++---
 include/configs/bf537-minotaur.h   |  1 +
 include/configs/bf537-srv1.h   |  1 +
 include/configs/blackstamp.h   |  1 +
 include/configs/cm-bf548.h |  2 ++
 include/configs/dnp5370.h  |  1 +
 17 files changed, 22 insertions(+), 107 deletions(-)
 delete mode 100644 arch/blackfin/cpu/bootrom-asm-offsets.awk
 delete mode 100644 arch/blackfin/cpu/bootrom-asm-offsets.c.in
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Albert ARIBAUD]

Hi Tom,

On Wed, 4 Dec 2013 17:06:30 -0500, Tom Rini tr...@ti.com wrote:

 Hey,
 
 The following changes since commit 4c54419737ffbfadd605263d97a1357bb03c04e8:
 
   socfpga: Adding Freeze Controller driver (2013-12-03 14:38:56 +0100)
 
 are available in the git repository at:
 
   git://git.denx.de/u-boot-ti.git master
 
 for you to fetch changes up to b06f8984959f51f4b99f9c77efa5267623c98957:
 
   omap4_panda: Don't use ulpi_reset (2013-12-04 11:41:14 -0500)

This causes am3517_evm to fail with warnings:

am3517evm.c: In function 'misc_init_r':
am3517evm.c:106:6: warning: unused variable 'reset' [-Wunused-variable]
am3517evm.c:105:24: warning: unused variable 'ctr' [-Wunused-variable]
am3517evm.c: In function 'misc_init_r':
am3517evm.c:106:6: warning: unused variable 'reset' [-Wunused-variable]
am3517evm.c:105:24: warning: unused variable 'ctr' [-Wunused-variable]

These are trivial, but I'd like them fixed; lingering warnings are a
pain to manage when doing large-scale test build.

These ones come from commit ae98bbeb, that is :

 Yegor Yefremov (1):
   am3517_evm: activate Ethernet PHY

Yegor, can you fix this? Thanks.

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

[U-Boot] Stale references in the u-boot-samsung repo

[Albert ARIBAUD]

Hi Minkyu,

While fetching u-boot-samsung, I could see the following messages:

remote: error: refs/remotes/origin/GPL-Cleanup does not point to a
valid object!

remote: error: refs/remotes/origin/i.MX31 does not point to a valid
object!

remote: error: refs/remotes/origin/lwmon5 does not point to a valid
object!

remote: error: refs/remotes/origin/mkimage does not point to a valid
object!

It looks like these branches that were pushed on the remote, then later
the commit to which they point was cleaned up.

Can you fix this? Thanks in advance!

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

[U-Boot] [PATCH v2] am3517_evm: activate Ethernet PHY

[yegorslists]

From: Yegor Yefremov yegorsli...@googlemail.com

Pin 30 is connected to PHY's RESET# signal, so it must be
put to high. Otherwise PHY won't be found via MDIO interface.

Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com
---
Changes:
v2: put ctr and reset under #if defined statement. to avoid 
compilerwarnigs, when EMAC is not selected

 board/logicpd/am3517evm/am3517evm.c |   36 +++
 board/logicpd/am3517evm/am3517evm.h |2 +-
 2 files changed, 37 insertions(+), 1 deletions(-)

diff --git a/board/logicpd/am3517evm/am3517evm.c 
b/board/logicpd/am3517evm/am3517evm.c
index 1569905..a917a03 100644
--- a/board/logicpd/am3517evm/am3517evm.c
+++ b/board/logicpd/am3517evm/am3517evm.c
@@ -22,6 +22,7 @@
 #include asm/arch/musb.h
 #include asm/mach-types.h
 #include asm/errno.h
+#include asm/gpio.h
 #include linux/usb/ch9.h
 #include linux/usb/gadget.h
 #include linux/usb/musb.h
@@ -31,6 +32,9 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
+#define AM3517_IP_SW_RESET 0x48002598
+#define CPGMACSS_SW_RST(1  1)
+
 /*
  * Routine: board_init
  * Description: Early hardware init.
@@ -98,6 +102,11 @@ static void am3517_evm_musb_init(void)
  */
 int misc_init_r(void)
 {
+#if defined(CONFIG_DRIVER_TI_EMAC)
+   volatile unsigned int ctr;
+   u32 reset;
+#endif
+
 #ifdef CONFIG_SYS_I2C_OMAP34XX
i2c_init(CONFIG_SYS_OMAP24_I2C_SPEED, CONFIG_SYS_OMAP24_I2C_SLAVE);
 #endif
@@ -106,6 +115,33 @@ int misc_init_r(void)
 
am3517_evm_musb_init();
 
+#if defined(CONFIG_DRIVER_TI_EMAC)
+   /* activate PHY reset */
+   gpio_direction_output(30, 0);
+   gpio_set_value(30, 0);
+
+   ctr  = 0;
+   do {
+   udelay(1000);
+   ctr++;
+   } while (ctr  300);
+
+   /* deactivate PHY reset */
+   gpio_set_value(30, 1);
+
+   /* allow the PHY to stabilize and settle down */
+   ctr = 0;
+   do {
+   udelay(1000);
+   ctr++;
+   } while (ctr  300);
+
+   /* ensure that the module is out of reset */
+   reset = readl(AM3517_IP_SW_RESET);
+   reset = (~CPGMACSS_SW_RST);
+   writel(reset,AM3517_IP_SW_RESET);
+#endif
+
return 0;
 }
 
diff --git a/board/logicpd/am3517evm/am3517evm.h 
b/board/logicpd/am3517evm/am3517evm.h
index 704af84..d407d66 100644
--- a/board/logicpd/am3517evm/am3517evm.h
+++ b/board/logicpd/am3517evm/am3517evm.h
@@ -315,7 +315,7 @@ const omap3_sysinfo sysinfo = {
MUX_VAL(CP(SYS_CLKREQ), (IEN  | PTD | DIS | M0)) \
MUX_VAL(CP(SYS_NIRQ),   (IEN  | PTU | EN  | M0)) \
/*SYS_nRESWARM */\
-   MUX_VAL(CP(SYS_NRESWARM),   (IDIS | PTU | DIS | M4)) \
+   MUX_VAL(CP(SYS_NRESWARM),   (IDIS | PTU | EN | M4)) \
/* - GPIO30 */\
MUX_VAL(CP(SYS_BOOT0),  (IEN  | PTD | DIS | M4)) /*GPIO_2*/\
 /* - PEN_IRQ */\
-- 
1.7.7

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

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

[Yegor Yefremov]

On Fri, Dec 6, 2013 at 9:33 AM, Albert ARIBAUD
albert.u.b...@aribaud.net wrote:
 Hi Tom,

 On Wed, 4 Dec 2013 17:06:30 -0500, Tom Rini tr...@ti.com wrote:

 Hey,

 The following changes since commit 4c54419737ffbfadd605263d97a1357bb03c04e8:

   socfpga: Adding Freeze Controller driver (2013-12-03 14:38:56 +0100)

 are available in the git repository at:

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

 for you to fetch changes up to b06f8984959f51f4b99f9c77efa5267623c98957:

   omap4_panda: Don't use ulpi_reset (2013-12-04 11:41:14 -0500)

 This causes am3517_evm to fail with warnings:

 am3517evm.c: In function 'misc_init_r':
 am3517evm.c:106:6: warning: unused variable 'reset' [-Wunused-variable]
 am3517evm.c:105:24: warning: unused variable 'ctr' [-Wunused-variable]
 am3517evm.c: In function 'misc_init_r':
 am3517evm.c:106:6: warning: unused variable 'reset' [-Wunused-variable]
 am3517evm.c:105:24: warning: unused variable 'ctr' [-Wunused-variable]

 These are trivial, but I'd like them fixed; lingering warnings are a
 pain to manage when doing large-scale test build.

 These ones come from commit ae98bbeb, that is :

 Yegor Yefremov (1):
   am3517_evm: activate Ethernet PHY

 Yegor, can you fix this? Thanks.

v2 sent. I've put those variables under if defined statement, so the
warning has gone.

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

Re: [U-Boot] please pull u-boot-samsung master

[Albert ARIBAUD]

Hi Minkyu,

On Thu, 05 Dec 2013 17:11:17 +0900, Minkyu Kang mk7.k...@samsung.com
wrote:

 Dear Albert,
 
 The following changes since commit d44a5f51288aec60c6bdb4ac939d75c24e5bf9c2:
 
   Merge branch 'u-boot-microblaze/zynq' into 'u-boot-arm/master' (2013-11-22 
 10:19:35 +0100)
 
 are available in the git repository at:
 
 
   git://git.denx.de/u-boot-samsung master
 
 for you to fetch changes up to 01322004ec08c207141b08a2e0423b9b4c7b2714:
 
   arm: exynos: remove the unused define. (2013-12-05 10:42:04 +0900)

This breaks three boards in ARM: smdkv310 origen arndale

spl_boot.c: In function 'exynos_spi_copy':
spl_boot.c:111:49: error: 'CONFIG_ENV_SPI_BASE' undeclared (first use
in this function)
spl_boot.c:111:49: note: each undeclared identifier is reported only
once for each function it appears in
spl_boot.c:142:2: error: 'SPI_FLASH_UBOOT_POS' undeclared (first use in
this function)
spl_boot.c: In function 'copy_uboot_to_ram':
spl_boot.c:189:28: warning: unused variable 'param' [-Wunused-variable]
spl_boot.c: At top level:
spl_boot.c:107:13: warning: 'exynos_spi_copy' defined but not used
[-Wunused-function]

This is due to commit 347e45d, aka:

 Rajeshwari Shinde (1):
   exynos: spl: Add a custom spi copy function

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

[U-Boot] [PATCH] t2080qds/ddr: update ddr parameters

[Shengzhou Liu]

- optimize ddr parameters for whole frequency range from 1500MT/s to 2140MT/s.
- remove unused patameters: 'cpo', 'wrdata delay', '2T', which is unrelated
  to DDR3/3L on t2080qds.
- remove unused rdimm code(only udimm is supported on t2080qds).

Signed-off-by: Shengzhou Liu shengzhou@freescale.com
---
Against master branch of git://git.denx.de/u-boot-mpc85xx.git

 board/freescale/t2080qds/ddr.c | 20 ++---
 board/freescale/t2080qds/ddr.h | 64 +-
 2 files changed, 17 insertions(+), 67 deletions(-)

diff --git a/board/freescale/t2080qds/ddr.c b/board/freescale/t2080qds/ddr.c
index 5db5d21..bc366ae 100644
--- a/board/freescale/t2080qds/ddr.c
+++ b/board/freescale/t2080qds/ddr.c
@@ -24,24 +24,17 @@ void fsl_ddr_board_options(memctl_options_t *popts,
const struct board_specific_parameters *pbsp, *pbsp_highest = NULL;
ulong ddr_freq;
 
-   if (ctrl_num  2) {
+   if (ctrl_num  1) {
printf(Not supported controller number %d\n, ctrl_num);
return;
}
if (!pdimm-n_ranks)
return;
 
-   /*
-* we use identical timing for all slots. If needed, change the code
-* to  pbsp = rdimms[ctrl_num] or pbsp = udimms[ctrl_num];
-*/
-   if (popts-registered_dimm_en)
-   pbsp = rdimms[0];
-   else
-   pbsp = udimms[0];
+   pbsp = udimms[0];
 
 
-   /* Get clk_adjust, cpo, write_data_delay,2T, according to the board ddr
+   /* Get clk_adjust, wrlvl_start, wrlvl_ctl, according to the board ddr
 * freqency and n_banks specified in board_specific_parameters table.
 */
ddr_freq = get_ddr_freq(0) / 100;
@@ -49,14 +42,10 @@ void fsl_ddr_board_options(memctl_options_t *popts,
if (pbsp-n_ranks == pdimm-n_ranks 
(pdimm-rank_density  30) = pbsp-rank_gb) {
if (ddr_freq = pbsp-datarate_mhz_high) {
-   popts-cpo_override = pbsp-cpo;
-   popts-write_data_delay =
-   pbsp-write_data_delay;
popts-clk_adjust = pbsp-clk_adjust;
popts-wrlvl_start = pbsp-wrlvl_start;
popts-wrlvl_ctl_2 = pbsp-wrlvl_ctl_2;
popts-wrlvl_ctl_3 = pbsp-wrlvl_ctl_3;
-   popts-twot_en = pbsp-force_2t;
goto found;
}
pbsp_highest = pbsp;
@@ -69,13 +58,10 @@ void fsl_ddr_board_options(memctl_options_t *popts,
printf(for data rate %lu MT/s\n, ddr_freq);
printf(Trying to use the highest speed (%u) parameters\n,
   pbsp_highest-datarate_mhz_high);
-   popts-cpo_override = pbsp_highest-cpo;
-   popts-write_data_delay = pbsp_highest-write_data_delay;
popts-clk_adjust = pbsp_highest-clk_adjust;
popts-wrlvl_start = pbsp_highest-wrlvl_start;
popts-wrlvl_ctl_2 = pbsp-wrlvl_ctl_2;
popts-wrlvl_ctl_3 = pbsp-wrlvl_ctl_3;
-   popts-twot_en = pbsp_highest-force_2t;
} else {
panic(DIMM is not supported by this board);
}
diff --git a/board/freescale/t2080qds/ddr.h b/board/freescale/t2080qds/ddr.h
index 964eaad..f8c5d2b 100644
--- a/board/freescale/t2080qds/ddr.h
+++ b/board/freescale/t2080qds/ddr.h
@@ -14,9 +14,6 @@ struct board_specific_parameters {
u32 wrlvl_start;
u32 wrlvl_ctl_2;
u32 wrlvl_ctl_3;
-   u32 cpo;
-   u32 write_data_delay;
-   u32 force_2t;
 };
 
 /*
@@ -28,58 +25,25 @@ struct board_specific_parameters {
 static const struct board_specific_parameters udimm0[] = {
/*
 * memory controller 0
-*   num|  hi| rank|  clk| wrlvl |   wrlvl   |  wrlvl | cpo  |wrdata|2T
-* ranks| mhz| GB  |adjst| start |   ctl2|  ctl3  |  |delay |
+*   num|  hi| rank|  clk| wrlvl |   wrlvl   |  wrlvl |
+* ranks| mhz| GB  |adjst| start |   ctl2|  ctl3  |
 */
-   {2,  1350, 4, 4, 8, 0x0809090b, 0x0c0c0d0a,   0xff,2,  0},
-   {2,  1350, 0, 5, 7, 0x0709090b, 0x0c0c0d09,   0xff,2,  0},
-   {2,  1666, 4, 4, 8, 0x080a0a0d, 0x0d10100b,   0xff,2,  0},
-   {2,  1666, 0, 5, 7, 0x080a0a0c, 0x0d0d0e0a,   0xff,2,  0},
-   {2,  1900, 0, 4, 8, 0x090a0b0e, 0x0f11120c,   0xff,2,  0},
-   {2,  2140, 0, 4, 8, 0x090a0b0e, 0x0f11120c,   0xff,2,  0},
-   {1,  1350, 0, 5, 8, 0x0809090b, 0x0c0c0d0a,   0xff,2,  0},
-   {1,  1700, 0, 5, 8, 0x080a0a0c, 0x0c0d0e0a,   0xff,2,  0},
-   {1,  1800, 2, 5, 6, 0x06070709, 0x110a0b08,   0xff,2,  0},
-   {1,  1866, 2, 4, 6, 0x06060708, 0x09090a07,   0xff,2,  0},
-   {1,  1900, 

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

[Stefan Roese]

Hi Yegor,

On 06.12.2013 10:20, Yegor Yefremov wrote:
 This causes am3517_evm to fail with warnings:

 am3517evm.c: In function 'misc_init_r':
 am3517evm.c:106:6: warning: unused variable 'reset' [-Wunused-variable]
 am3517evm.c:105:24: warning: unused variable 'ctr' [-Wunused-variable]
 am3517evm.c: In function 'misc_init_r':
 am3517evm.c:106:6: warning: unused variable 'reset' [-Wunused-variable]
 am3517evm.c:105:24: warning: unused variable 'ctr' [-Wunused-variable]

 These are trivial, but I'd like them fixed; lingering warnings are a
 pain to manage when doing large-scale test build.

 These ones come from commit ae98bbeb, that is :

 Yegor Yefremov (1):
   am3517_evm: activate Ethernet PHY

 Yegor, can you fix this? Thanks.
 
 v2 sent. I've put those variables under if defined statement, so the
 warning has gone.

In general its preferred to use the __maybe_unused statement instead of
adding more #ifdef's. Like this:

+   __maybe_unused volatile unsigned int ctr;
+   __maybe_unused u32 reset;

Care to send a v3 for this patch?

Thanks,
Stefan

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

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

[Yegor Yefremov]

On Fri, Dec 6, 2013 at 11:08 AM, Stefan Roese s...@denx.de wrote:
 Hi Yegor,

 On 06.12.2013 10:20, Yegor Yefremov wrote:
 This causes am3517_evm to fail with warnings:

 am3517evm.c: In function 'misc_init_r':
 am3517evm.c:106:6: warning: unused variable 'reset' [-Wunused-variable]
 am3517evm.c:105:24: warning: unused variable 'ctr' [-Wunused-variable]
 am3517evm.c: In function 'misc_init_r':
 am3517evm.c:106:6: warning: unused variable 'reset' [-Wunused-variable]
 am3517evm.c:105:24: warning: unused variable 'ctr' [-Wunused-variable]

 These are trivial, but I'd like them fixed; lingering warnings are a
 pain to manage when doing large-scale test build.

 These ones come from commit ae98bbeb, that is :

 Yegor Yefremov (1):
   am3517_evm: activate Ethernet PHY

 Yegor, can you fix this? Thanks.

 v2 sent. I've put those variables under if defined statement, so the
 warning has gone.

 In general its preferred to use the __maybe_unused statement instead of
 adding more #ifdef's. Like this:

 +   __maybe_unused volatile unsigned int ctr;
 +   __maybe_unused u32 reset;

 Care to send a v3 for this patch?

Will do.

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

[U-Boot] [PATCH v3] am3517_evm: activate Ethernet PHY

[yegorslists]

From: Yegor Yefremov yegorsli...@googlemail.com

Pin 30 is connected to PHY's RESET# signal, so it must be
put to high. Otherwise PHY won't be found via MDIO interface.

Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com
---
Changes:
v3: use __maybe_unused, instead of #if defined statement (Stefan 
Roese)
v2: put ctr and reset under #if defined statement, to avoid compiler 
warnings, when EMAC is not selected

 board/logicpd/am3517evm/am3517evm.c |   34 ++
 board/logicpd/am3517evm/am3517evm.h |2 +-
 2 files changed, 35 insertions(+), 1 deletions(-)

diff --git a/board/logicpd/am3517evm/am3517evm.c 
b/board/logicpd/am3517evm/am3517evm.c
index 1569905..3b1dfd1 100644
--- a/board/logicpd/am3517evm/am3517evm.c
+++ b/board/logicpd/am3517evm/am3517evm.c
@@ -22,6 +22,7 @@
 #include asm/arch/musb.h
 #include asm/mach-types.h
 #include asm/errno.h
+#include asm/gpio.h
 #include linux/usb/ch9.h
 #include linux/usb/gadget.h
 #include linux/usb/musb.h
@@ -31,6 +32,9 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
+#define AM3517_IP_SW_RESET 0x48002598
+#define CPGMACSS_SW_RST(1  1)
+
 /*
  * Routine: board_init
  * Description: Early hardware init.
@@ -98,6 +102,9 @@ static void am3517_evm_musb_init(void)
  */
 int misc_init_r(void)
 {
+   __maybe_unused volatile unsigned int ctr;
+   __maybe_unused u32 reset;
+
 #ifdef CONFIG_SYS_I2C_OMAP34XX
i2c_init(CONFIG_SYS_OMAP24_I2C_SPEED, CONFIG_SYS_OMAP24_I2C_SLAVE);
 #endif
@@ -106,6 +113,33 @@ int misc_init_r(void)
 
am3517_evm_musb_init();
 
+#if defined(CONFIG_DRIVER_TI_EMAC)
+   /* activate PHY reset */
+   gpio_direction_output(30, 0);
+   gpio_set_value(30, 0);
+
+   ctr  = 0;
+   do {
+   udelay(1000);
+   ctr++;
+   } while (ctr  300);
+
+   /* deactivate PHY reset */
+   gpio_set_value(30, 1);
+
+   /* allow the PHY to stabilize and settle down */
+   ctr = 0;
+   do {
+   udelay(1000);
+   ctr++;
+   } while (ctr  300);
+
+   /* ensure that the module is out of reset */
+   reset = readl(AM3517_IP_SW_RESET);
+   reset = (~CPGMACSS_SW_RST);
+   writel(reset,AM3517_IP_SW_RESET);
+#endif
+
return 0;
 }
 
diff --git a/board/logicpd/am3517evm/am3517evm.h 
b/board/logicpd/am3517evm/am3517evm.h
index 704af84..d407d66 100644
--- a/board/logicpd/am3517evm/am3517evm.h
+++ b/board/logicpd/am3517evm/am3517evm.h
@@ -315,7 +315,7 @@ const omap3_sysinfo sysinfo = {
MUX_VAL(CP(SYS_CLKREQ), (IEN  | PTD | DIS | M0)) \
MUX_VAL(CP(SYS_NIRQ),   (IEN  | PTU | EN  | M0)) \
/*SYS_nRESWARM */\
-   MUX_VAL(CP(SYS_NRESWARM),   (IDIS | PTU | DIS | M4)) \
+   MUX_VAL(CP(SYS_NRESWARM),   (IDIS | PTU | EN | M4)) \
/* - GPIO30 */\
MUX_VAL(CP(SYS_BOOT0),  (IEN  | PTD | DIS | M4)) /*GPIO_2*/\
 /* - PEN_IRQ */\
-- 
1.7.7

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

[U-Boot] [PATCH] arm: arndale: disable spi boot

[Minkyu Kang]

arndale board is booted from mmc

Signed-off-by: Minkyu Kang mk7.k...@samsung.com
Cc: Albert ARIBAUD albert.u.b...@aribaud.net
Cc: Inderpal Singh inderpal.si...@linaro.org
---
 include/configs/arndale.h |4 
 1 file changed, 4 deletions(-)

diff --git a/include/configs/arndale.h b/include/configs/arndale.h
index 45fa047..f0b9f94 100644
--- a/include/configs/arndale.h
+++ b/include/configs/arndale.h
@@ -198,10 +198,6 @@
 #define BL2_START_OFFSET   (CONFIG_BL2_OFFSET/512)
 #define BL2_SIZE_BLOC_COUNT(CONFIG_BL2_SIZE/512)
 
-#define CONFIG_SPI_BOOTING
-#define EXYNOS_COPY_SPI_FNPTR_ADDR 0x02020058
-#define SPI_FLASH_UBOOT_POS(CONFIG_SEC_FW_SIZE + CONFIG_BL1_SIZE)
-
 #define CONFIG_DOS_PARTITION
 #define CONFIG_EFI_PARTITION
 #define CONFIG_CMD_PART
-- 
1.7.9.5
-- 
Thanks,
Minkyu Kang.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] arm: exynos: adds ifdef for spi boot

[Minkyu Kang]

This patch fix following errors and warnings

spl_boot.c: In function 'exynos_spi_copy':
spl_boot.c:111:49: error: 'CONFIG_ENV_SPI_BASE' undeclared (first use in this 
function)
spl_boot.c:111:49: note: each undeclared identifier is reported only once for 
each function it appears in
spl_boot.c:142:2: error: 'SPI_FLASH_UBOOT_POS' undeclared (first use in this 
function)
spl_boot.c: In function 'copy_uboot_to_ram':
spl_boot.c:189:28: warning: unused variable 'param' [-Wunused-variable]
spl_boot.c: At top level:
spl_boot.c:107:13: warning: 'exynos_spi_copy' defined but not used 
[-Wunused-function]

Signed-off-by: Minkyu Kang mk7.k...@samsung.com
Cc: Albert ARIBAUD albert.u.b...@aribaud.net
---
 arch/arm/cpu/armv7/exynos/spl_boot.c |4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/cpu/armv7/exynos/spl_boot.c 
b/arch/arm/cpu/armv7/exynos/spl_boot.c
index 6faf13f..ade45fd 100644
--- a/arch/arm/cpu/armv7/exynos/spl_boot.c
+++ b/arch/arm/cpu/armv7/exynos/spl_boot.c
@@ -62,6 +62,7 @@ static int config_branch_prediction(int set_cr_z)
 }
 #endif
 
+#ifdef CONFIG_SPI_BOOTING
 static void spi_rx_tx(struct exynos_spi *regs, int todo,
void *dinp, void const *doutp, int i)
 {
@@ -174,6 +175,7 @@ static void exynos_spi_copy(unsigned int uboot_size, 
unsigned int uboot_addr)
clrbits_le32(regs-ch_cfg, SPI_CH_RST);
clrbits_le32(regs-ch_cfg, SPI_TX_CH_ON | SPI_RX_CH_ON);
 }
+#endif
 
 /*
 * Copy U-boot from mmc to RAM:
@@ -186,7 +188,9 @@ void copy_uboot_to_ram(void)
 
u32 (*copy_bl2)(u32 offset, u32 nblock, u32 dst) = NULL;
u32 offset = 0, size = 0;
+#ifdef CONFIG_SPI_BOOTING
struct spl_machine_param *param = spl_get_machine_params();
+#endif
 #ifdef CONFIG_SUPPORT_EMMC_BOOT
u32 (*copy_bl2_from_emmc)(u32 nblock, u32 dst);
void (*end_bootop_from_emmc)(void);
-- 
1.7.9.5
-- 
Thanks,
Minkyu Kang.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3] am3517_evm: activate Ethernet PHY

[Stefan Roese]

On 06.12.2013 11:17, yegorsli...@googlemail.com wrote:
 From: Yegor Yefremov yegorsli...@googlemail.com
 
 Pin 30 is connected to PHY's RESET# signal, so it must be
 put to high. Otherwise PHY won't be found via MDIO interface.
 
 Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com

Looks good. One questions below though:

 ---
 Changes:
   v3: use __maybe_unused, instead of #if defined statement (Stefan 
 Roese)
   v2: put ctr and reset under #if defined statement, to avoid compiler 
 warnings, when EMAC is not selected
 
  board/logicpd/am3517evm/am3517evm.c |   34 ++
  board/logicpd/am3517evm/am3517evm.h |2 +-
  2 files changed, 35 insertions(+), 1 deletions(-)
 
 diff --git a/board/logicpd/am3517evm/am3517evm.c 
 b/board/logicpd/am3517evm/am3517evm.c
 index 1569905..3b1dfd1 100644
 --- a/board/logicpd/am3517evm/am3517evm.c
 +++ b/board/logicpd/am3517evm/am3517evm.c
 @@ -22,6 +22,7 @@
  #include asm/arch/musb.h
  #include asm/mach-types.h
  #include asm/errno.h
 +#include asm/gpio.h
  #include linux/usb/ch9.h
  #include linux/usb/gadget.h
  #include linux/usb/musb.h
 @@ -31,6 +32,9 @@
  
  DECLARE_GLOBAL_DATA_PTR;
  
 +#define AM3517_IP_SW_RESET   0x48002598
 +#define CPGMACSS_SW_RST  (1  1)
 +
  /*
   * Routine: board_init
   * Description: Early hardware init.
 @@ -98,6 +102,9 @@ static void am3517_evm_musb_init(void)
   */
  int misc_init_r(void)
  {
 + __maybe_unused volatile unsigned int ctr;
 + __maybe_unused u32 reset;
 +
  #ifdef CONFIG_SYS_I2C_OMAP34XX
   i2c_init(CONFIG_SYS_OMAP24_I2C_SPEED, CONFIG_SYS_OMAP24_I2C_SLAVE);
  #endif
 @@ -106,6 +113,33 @@ int misc_init_r(void)
  
   am3517_evm_musb_init();
  
 +#if defined(CONFIG_DRIVER_TI_EMAC)
 + /* activate PHY reset */
 + gpio_direction_output(30, 0);
 + gpio_set_value(30, 0);
 +
 + ctr  = 0;
 + do {
 + udelay(1000);
 + ctr++;
 + } while (ctr  300);
 +
 + /* deactivate PHY reset */
 + gpio_set_value(30, 1);
 +
 + /* allow the PHY to stabilize and settle down */
 + ctr = 0;
 + do {
 + udelay(1000);
 + ctr++;
 + } while (ctr  300);
 +
 + /* ensure that the module is out of reset */
 + reset = readl(AM3517_IP_SW_RESET);
 + reset = (~CPGMACSS_SW_RST);
 + writel(reset,AM3517_IP_SW_RESET);
 +#endif

Why do you need to put this #if defined(CONFIG_DRIVER_TI_EMAC) here at
all? Isn't CONFIG_DRIVER_TI_EMAC enabled for this board always?

Thanks,
Stefan

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

Re: [U-Boot] Stale references in the u-boot-samsung repo

[Minkyu Kang]

Hi Albert,

On 06/12/13 17:44, Albert ARIBAUD wrote:
 Hi Minkyu,
 
 While fetching u-boot-samsung, I could see the following messages:
 
 remote: error: refs/remotes/origin/GPL-Cleanup does not point to a
 valid object!
 
 remote: error: refs/remotes/origin/i.MX31 does not point to a valid
 object!
 
 remote: error: refs/remotes/origin/lwmon5 does not point to a valid
 object!
 
 remote: error: refs/remotes/origin/mkimage does not point to a valid
 object!
 
 It looks like these branches that were pushed on the remote, then later
 the commit to which they point was cleaned up.
 
 Can you fix this? Thanks in advance!
 

Please let me know how I can fix it!

 Amicalement,
 

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: arndale: disable spi boot

[Minkyu Kang]

On 06/12/13 19:25, Minkyu Kang wrote:
 arndale board is booted from mmc
 
 Signed-off-by: Minkyu Kang mk7.k...@samsung.com
 Cc: Albert ARIBAUD albert.u.b...@aribaud.net
 Cc: Inderpal Singh inderpal.si...@linaro.org
 ---
  include/configs/arndale.h |4 
  1 file changed, 4 deletions(-)
 
 diff --git a/include/configs/arndale.h b/include/configs/arndale.h
 index 45fa047..f0b9f94 100644
 --- a/include/configs/arndale.h
 +++ b/include/configs/arndale.h
 @@ -198,10 +198,6 @@
  #define BL2_START_OFFSET (CONFIG_BL2_OFFSET/512)
  #define BL2_SIZE_BLOC_COUNT  (CONFIG_BL2_SIZE/512)
  
 -#define CONFIG_SPI_BOOTING
 -#define EXYNOS_COPY_SPI_FNPTR_ADDR   0x02020058
 -#define SPI_FLASH_UBOOT_POS  (CONFIG_SEC_FW_SIZE + CONFIG_BL1_SIZE)
 -
  #define CONFIG_DOS_PARTITION
  #define CONFIG_EFI_PARTITION
  #define CONFIG_CMD_PART
 

applied to u-boot-samsung.

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: exynos: adds ifdef for spi boot

[Minkyu Kang]

On 06/12/13 19:25, Minkyu Kang wrote:
 This patch fix following errors and warnings
 
 spl_boot.c: In function 'exynos_spi_copy':
 spl_boot.c:111:49: error: 'CONFIG_ENV_SPI_BASE' undeclared (first use in this 
 function)
 spl_boot.c:111:49: note: each undeclared identifier is reported only once for 
 each function it appears in
 spl_boot.c:142:2: error: 'SPI_FLASH_UBOOT_POS' undeclared (first use in this 
 function)
 spl_boot.c: In function 'copy_uboot_to_ram':
 spl_boot.c:189:28: warning: unused variable 'param' [-Wunused-variable]
 spl_boot.c: At top level:
 spl_boot.c:107:13: warning: 'exynos_spi_copy' defined but not used 
 [-Wunused-function]
 
 Signed-off-by: Minkyu Kang mk7.k...@samsung.com
 Cc: Albert ARIBAUD albert.u.b...@aribaud.net
 ---
  arch/arm/cpu/armv7/exynos/spl_boot.c |4 
  1 file changed, 4 insertions(+)
 
 diff --git a/arch/arm/cpu/armv7/exynos/spl_boot.c 
 b/arch/arm/cpu/armv7/exynos/spl_boot.c
 index 6faf13f..ade45fd 100644
 --- a/arch/arm/cpu/armv7/exynos/spl_boot.c
 +++ b/arch/arm/cpu/armv7/exynos/spl_boot.c
 @@ -62,6 +62,7 @@ static int config_branch_prediction(int set_cr_z)
  }
  #endif
  
 +#ifdef CONFIG_SPI_BOOTING
  static void spi_rx_tx(struct exynos_spi *regs, int todo,
   void *dinp, void const *doutp, int i)
  {
 @@ -174,6 +175,7 @@ static void exynos_spi_copy(unsigned int uboot_size, 
 unsigned int uboot_addr)
   clrbits_le32(regs-ch_cfg, SPI_CH_RST);
   clrbits_le32(regs-ch_cfg, SPI_TX_CH_ON | SPI_RX_CH_ON);
  }
 +#endif
  
  /*
  * Copy U-boot from mmc to RAM:
 @@ -186,7 +188,9 @@ void copy_uboot_to_ram(void)
  
   u32 (*copy_bl2)(u32 offset, u32 nblock, u32 dst) = NULL;
   u32 offset = 0, size = 0;
 +#ifdef CONFIG_SPI_BOOTING
   struct spl_machine_param *param = spl_get_machine_params();
 +#endif
  #ifdef CONFIG_SUPPORT_EMMC_BOOT
   u32 (*copy_bl2_from_emmc)(u32 nblock, u32 dst);
   void (*end_bootop_from_emmc)(void);
 

applied to u-boot-samsung.

Thanks,
Minkyu Kang.

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

Re: [U-Boot] [PATCH v3] am3517_evm: activate Ethernet PHY

[Yegor Yefremov]

On Fri, Dec 6, 2013 at 11:37 AM, Stefan Roese stefan.ro...@gmail.com wrote:
 On 06.12.2013 11:17, yegorsli...@googlemail.com wrote:
 From: Yegor Yefremov yegorsli...@googlemail.com

 Pin 30 is connected to PHY's RESET# signal, so it must be
 put to high. Otherwise PHY won't be found via MDIO interface.

 Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com

 Looks good. One questions below though:

 ---
 Changes:
   v3: use __maybe_unused, instead of #if defined statement (Stefan 
 Roese)
   v2: put ctr and reset under #if defined statement, to avoid compiler 
 warnings, when EMAC is not selected

  board/logicpd/am3517evm/am3517evm.c |   34 
 ++
  board/logicpd/am3517evm/am3517evm.h |2 +-
  2 files changed, 35 insertions(+), 1 deletions(-)

 diff --git a/board/logicpd/am3517evm/am3517evm.c 
 b/board/logicpd/am3517evm/am3517evm.c
 index 1569905..3b1dfd1 100644
 --- a/board/logicpd/am3517evm/am3517evm.c
 +++ b/board/logicpd/am3517evm/am3517evm.c
 @@ -22,6 +22,7 @@
  #include asm/arch/musb.h
  #include asm/mach-types.h
  #include asm/errno.h
 +#include asm/gpio.h
  #include linux/usb/ch9.h
  #include linux/usb/gadget.h
  #include linux/usb/musb.h
 @@ -31,6 +32,9 @@

  DECLARE_GLOBAL_DATA_PTR;

 +#define AM3517_IP_SW_RESET   0x48002598
 +#define CPGMACSS_SW_RST  (1  1)
 +
  /*
   * Routine: board_init
   * Description: Early hardware init.
 @@ -98,6 +102,9 @@ static void am3517_evm_musb_init(void)
   */
  int misc_init_r(void)
  {
 + __maybe_unused volatile unsigned int ctr;
 + __maybe_unused u32 reset;
 +
  #ifdef CONFIG_SYS_I2C_OMAP34XX
   i2c_init(CONFIG_SYS_OMAP24_I2C_SPEED, CONFIG_SYS_OMAP24_I2C_SLAVE);
  #endif
 @@ -106,6 +113,33 @@ int misc_init_r(void)

   am3517_evm_musb_init();

 +#if defined(CONFIG_DRIVER_TI_EMAC)
 + /* activate PHY reset */
 + gpio_direction_output(30, 0);
 + gpio_set_value(30, 0);
 +
 + ctr  = 0;
 + do {
 + udelay(1000);
 + ctr++;
 + } while (ctr  300);
 +
 + /* deactivate PHY reset */
 + gpio_set_value(30, 1);
 +
 + /* allow the PHY to stabilize and settle down */
 + ctr = 0;
 + do {
 + udelay(1000);
 + ctr++;
 + } while (ctr  300);
 +
 + /* ensure that the module is out of reset */
 + reset = readl(AM3517_IP_SW_RESET);
 + reset = (~CPGMACSS_SW_RST);
 + writel(reset,AM3517_IP_SW_RESET);
 +#endif

 Why do you need to put this #if defined(CONFIG_DRIVER_TI_EMAC) here at
 all? Isn't CONFIG_DRIVER_TI_EMAC enabled for this board always?

It is enabled in arago repository:
http://arago-project.org/git/projects/?p=u-boot-omap3.git;a=blob;f=include/configs/am3517_evm.h;h=b37b81e2aa5d635d14db87393e751ac25cb3611e;hb=HEAD,
but not in upstream u-boot. I was testing the stuff with my own board,
so my am3517_evm.h is a little bit messy for now. That's why I wanted
to have this change only in board/logicpd/am3517evm/am3517evm.c. It
does no harm so far. I could patch am3517_evm.h later.

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

[U-Boot] please pull u-boot-samsung master (v2)

[Minkyu Kang]

The following changes since commit d44a5f51288aec60c6bdb4ac939d75c24e5bf9c2:

  Merge branch 'u-boot-microblaze/zynq' into 'u-boot-arm/master' (2013-11-22 
10:19:35 +0100)

are available in the git repository at:


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

for you to fetch changes up to 55f2118c11ff933e272c1084f93e72ff719a269b:

  arm: arndale: disable spi boot (2013-12-06 19:18:13 +0900)


Jaehoon Chung (3):
  arm: exynos: fix set_mmc_clk for exynos4x12
  arm: exynos/goni: fix the return type for s5p_mmc_init
  arm: exynos: remove the unused define.

Luka Perkov (1):
  config: arm: exynos5250: remove duplicate defines

Minkyu Kang (3):
  arm: exynos: fix the align for exynos4_power structure
  arm: exynos: adds ifdef for spi boot
  arm: arndale: disable spi boot

Piotr Wilczek (7):
  driver:usb:s3c_udc: add support for Exynos4x12
  trats2: enable ums support on Trats2
  trats2: enable dfu and thor protocol for Tizen download
  board: trats2: remove unused defines from config file
  board: trats2: fix environmental variables
  board: trats2: fix access to samsung registers
  board: trats2: update Tizen partition definitions

Przemyslaw Marczak (1):
  trats: usb: Add usb_cable_connected() function

Rajeshwari Shinde (1):
  exynos: spl: Add a custom spi copy function

 arch/arm/cpu/armv7/exynos/clock.c|3 +-
 arch/arm/cpu/armv7/exynos/pinmux.c   |2 +-
 arch/arm/cpu/armv7/exynos/spl_boot.c |  126 +-
 arch/arm/include/asm/arch-exynos/dwmmc.h |4 -
 arch/arm/include/asm/arch-exynos/mmc.h   |2 +-
 arch/arm/include/asm/arch-exynos/power.h |2 +-
 arch/arm/include/asm/arch-exynos/spi.h   |1 +
 arch/arm/include/asm/arch-s5pc1xx/mmc.h  |2 +-
 board/samsung/trats/trats.c  |   11 +++
 board/samsung/trats2/trats2.c|  108 +++--
 drivers/usb/gadget/regs-otg.h|5 ++
 drivers/usb/gadget/s3c_udc_otg.c |9 ++-
 include/configs/arndale.h|4 -
 include/configs/exynos5250-dt.h  |   25 +-
 include/configs/trats.h  |1 +
 include/configs/trats2.h |   68 +++-
 16 files changed, 304 insertions(+), 69 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] mmc/dwmmc: modify FIFO threshold only if value explicitly set

[Alexey Brodkin]

On Wed, 2013-11-27 at 22:07 +0900, Jaehoon Chung wrote:
 Acked-by: Jaehoon Chung jh80.ch...@samsung.com

Any chance to get this patch applied?

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

Re: [U-Boot] [PATCH v2] mmc/dwmmc: modify FIFO threshold only if value explicitly set

[Pantelis Antoniou]

Hi Alexey,

Will do so over the weekend.

Regards

-- Pantelis
On Dec 6, 2013, at 12:52 PM, Alexey Brodkin wrote:

 On Wed, 2013-11-27 at 22:07 +0900, Jaehoon Chung wrote:
 Acked-by: Jaehoon Chung jh80.ch...@samsung.com
 
 Any chance to get this patch applied?
 
 -Alexey

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

Re: [U-Boot] [PATCH 2/5] port wandboards to use the generic distro configs

[Wolfgang Denk]

Dear Dennis Gilmore,

In message 1386296295-28658-3-git-send-email-den...@ausil.us you wrote:

 - fdt_addr=0x1100\0 \
 + fdt_addr=0x1110\0 \
 + fdt_addr_r=0x1120\0 \

Why would you need fdt_addr and fdt_addr_r ?  This makes no sense.
Two different values would only be needed if there was NOR flash
available where we could read the FDT from without loading it to RAM
first.  AFAIK ther ewill never be variants of the Wandboard with NOR
flash, so you will always have to load the FDT to RAM first - thus the
destinction makes no sense.

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
There are three principal ways to lose money: wine, women,  and  en-
gineers.  While  the first two are more pleasant, the third is by far
the more certain.  -- Baron Rothschild, ca. 1800
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/5] add a generic set of configs to enable Distros to more easier support u-boot based systems

[Wolfgang Denk]

Dear Dennis Gilmore,

In message 1386296295-28658-2-git-send-email-den...@ausil.us you wrote:

 +#if defined(__arm__)
 +#define CONFIG_BOOTP_PXE_CLIENTARCH 0x100
 +#define CONFIG_BOOTP_VCI_STRING U-boot.armv7
 +#endif

This cannot be right.  Not all the world is an ARMv7.

Please also note that the correct spelling (when using capitalization)
is U-Boot (i. e. with a capital 'B').

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
Philosophy:  A route of many roads leading from nowhere to nothing.
- Ambrose Bierce
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/9] ARMv7: add PSCI support to u-boot

[Andre Przywara]

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

PSCI is an ARM standard that provides a generic interface that
...


Thanks again for posting this, I like the idea of adding PSCI handlers 
to u-boot for several platforms very much.



This patch series contains 3 parts:
- the first four patches are just bug fixes


Those are fine, I already acked those patches.


- the next three contain the generic PSCI code and build infrastructure


As I heard you will rework these anyway, I will refrain from commenting 
in detail, just some generic comments on the approach:


* Is the creation of a top-level psci directory for holding the PSCI 
binaries really necessary? Should this mimic the spl approach?
Can you consider to move this at least into the arch/arm directory, as 
PSCI is ARM specific? Or add it to the SPL directory, as this serves a 
similar purpose? But maybe your new approach renders this all moot.


* Can you keep the SMP bringup code in place and re-use it from the PSCI 
handlers instead of #ifndef PSCIing it? So maybe rename 
arch/arm/cpu/armv7/sunxi/psci.S to .../sunxi/smp.S?
My idea here is to make PSCI an option in addition to the current SMP 
HYP mode code. So that for instance on VExpress (or better: Arndale) you 
could either use the existing code using the kernel's platform SMP code 
or enable PSCI in u-boot and let the kernel use that, too.
I maybe ask too much for the first incarnation of the code, but that is 
how I would like to eventually see it. AFAIK Linux prefers PSCI over 
platform-defined SMP code, so this should work out of the box.


* Is the use of TPIDRPRW  Co. really safe? It looks like as we seem to 
be the only secure user (and they are banked), but I am just curious 
whether there is any prior art in using those registers temporarily.



...
The kernel now boots in HYP mode, finds its secondary CPU without any
additional SMP code, and runs KVM out of the box. Hopefully, the
Xen/ARM guys can do the same fairly easily.


BTW: Yesterday my PSCI host patches for Xen have been committed, so Xen 
should be able to use that feature just like the kernel does.


Thanks!
Andre.

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

Re: [U-Boot] [PATCH v3] am3517_evm: activate Ethernet PHY

[Tom Rini]

On Fri, Dec 06, 2013 at 11:47:38AM +0100, Yegor Yefremov wrote:
 On Fri, Dec 6, 2013 at 11:37 AM, Stefan Roese stefan.ro...@gmail.com wrote:
  On 06.12.2013 11:17, yegorsli...@googlemail.com wrote:
  From: Yegor Yefremov yegorsli...@googlemail.com
 
  Pin 30 is connected to PHY's RESET# signal, so it must be
  put to high. Otherwise PHY won't be found via MDIO interface.
 
  Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com
 
  Looks good. One questions below though:
 
  ---
  Changes:
v3: use __maybe_unused, instead of #if defined statement (Stefan 
  Roese)
v2: put ctr and reset under #if defined statement, to avoid compiler 
  warnings, when EMAC is not selected
 
   board/logicpd/am3517evm/am3517evm.c |   34 
  ++
   board/logicpd/am3517evm/am3517evm.h |2 +-
   2 files changed, 35 insertions(+), 1 deletions(-)
 
  diff --git a/board/logicpd/am3517evm/am3517evm.c 
  b/board/logicpd/am3517evm/am3517evm.c
  index 1569905..3b1dfd1 100644
  --- a/board/logicpd/am3517evm/am3517evm.c
  +++ b/board/logicpd/am3517evm/am3517evm.c
  @@ -22,6 +22,7 @@
   #include asm/arch/musb.h
   #include asm/mach-types.h
   #include asm/errno.h
  +#include asm/gpio.h
   #include linux/usb/ch9.h
   #include linux/usb/gadget.h
   #include linux/usb/musb.h
  @@ -31,6 +32,9 @@
 
   DECLARE_GLOBAL_DATA_PTR;
 
  +#define AM3517_IP_SW_RESET   0x48002598
  +#define CPGMACSS_SW_RST  (1  1)
  +
   /*
* Routine: board_init
* Description: Early hardware init.
  @@ -98,6 +102,9 @@ static void am3517_evm_musb_init(void)
*/
   int misc_init_r(void)
   {
  + __maybe_unused volatile unsigned int ctr;
  + __maybe_unused u32 reset;
  +
   #ifdef CONFIG_SYS_I2C_OMAP34XX
i2c_init(CONFIG_SYS_OMAP24_I2C_SPEED, CONFIG_SYS_OMAP24_I2C_SLAVE);
   #endif
  @@ -106,6 +113,33 @@ int misc_init_r(void)
 
am3517_evm_musb_init();
 
  +#if defined(CONFIG_DRIVER_TI_EMAC)
  + /* activate PHY reset */
  + gpio_direction_output(30, 0);
  + gpio_set_value(30, 0);
  +
  + ctr  = 0;
  + do {
  + udelay(1000);
  + ctr++;
  + } while (ctr  300);
  +
  + /* deactivate PHY reset */
  + gpio_set_value(30, 1);
  +
  + /* allow the PHY to stabilize and settle down */
  + ctr = 0;
  + do {
  + udelay(1000);
  + ctr++;
  + } while (ctr  300);
  +
  + /* ensure that the module is out of reset */
  + reset = readl(AM3517_IP_SW_RESET);
  + reset = (~CPGMACSS_SW_RST);
  + writel(reset,AM3517_IP_SW_RESET);
  +#endif
 
  Why do you need to put this #if defined(CONFIG_DRIVER_TI_EMAC) here at
  all? Isn't CONFIG_DRIVER_TI_EMAC enabled for this board always?
 
 It is enabled in arago repository:
 http://arago-project.org/git/projects/?p=u-boot-omap3.git;a=blob;f=include/configs/am3517_evm.h;h=b37b81e2aa5d635d14db87393e751ac25cb3611e;hb=HEAD,
 but not in upstream u-boot. I was testing the stuff with my own board,
 so my am3517_evm.h is a little bit messy for now. That's why I wanted
 to have this change only in board/logicpd/am3517evm/am3517evm.c. It
 does no harm so far. I could patch am3517_evm.h later.

Ah, I forgot that I marked http://patchwork.ozlabs.org/patch/129720/ as
Deferred way back when rather than merge it.  I don't know why I didn't
need the bit you pulled in when I was testing eth.

The right answer here is to do both of these so that we are using and
testing the feature we add.  I'll see if I can dig up and boot up my
am3517_evm.

-- 
Tom


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

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

[Albert ARIBAUD]

Hi Stefan,

On Fri, 06 Dec 2013 11:08:17 +0100, Stefan Roese s...@denx.de wrote:

 Hi Yegor,
 
 On 06.12.2013 10:20, Yegor Yefremov wrote:
  This causes am3517_evm to fail with warnings:
 
  am3517evm.c: In function 'misc_init_r':
  am3517evm.c:106:6: warning: unused variable 'reset' [-Wunused-variable]
  am3517evm.c:105:24: warning: unused variable 'ctr' [-Wunused-variable]
  am3517evm.c: In function 'misc_init_r':
  am3517evm.c:106:6: warning: unused variable 'reset' [-Wunused-variable]
  am3517evm.c:105:24: warning: unused variable 'ctr' [-Wunused-variable]
 
  These are trivial, but I'd like them fixed; lingering warnings are a
  pain to manage when doing large-scale test build.
 
  These ones come from commit ae98bbeb, that is :
 
  Yegor Yefremov (1):
am3517_evm: activate Ethernet PHY
 
  Yegor, can you fix this? Thanks.
  
  v2 sent. I've put those variables under if defined statement, so the
  warning has gone.
 
 In general its preferred to use the __maybe_unused statement instead of
 adding more #ifdef's. Like this:
 
 + __maybe_unused volatile unsigned int ctr;
 + __maybe_unused u32 reset;
 
 Care to send a v3 for this patch?
 
 Thanks,
 Stefan
 

Hmm, if the variables are used under a clearly defined conditional, I
prefer them to be defined under than conditional too. This makes
it clearer what is affected when removing the conditional.

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

Re: [U-Boot] Pull request: u-boot-sh/rmobile into u-boot-arm/master

[Albert ARIBAUD]

Hi Nobuhiro,

On Tue, 3 Dec 2013 10:40:07 +0900, Nobuhiro Iwamatsu
iwama...@nigauri.org wrote:

 Dear Albert Aribaud,
 
 Please pull u-boot-sh/rmobile into u-boot-arm/master.
 
 The following changes since commit
 77524d2c9d81e97c54e704b65c8a02e4bec0f441:
 
   Merge branch 'u-boot-atmel/master' into 'u-boot-arm/master'
 (2013-12-02 16:00:10 +0100)
 
 are available in the git repository at:
 
 
   git://git.denx.de/u-boot-sh.git rmobile
 
 for you to fetch changes up to
 cae83ce5159f9533b3dd3b442e9e5926fd0e285b:
 
   arm: rmobile: Remove config.mk (2013-12-03 09:47:15 +0900)
 
 
 Nobuhiro Iwamatsu (7):
   arm: rmobile: Move lowlevel_init.o to taget of each CPU
   arm: rmobile: Add support R8A7790
   arm: rmobile: Add support lager board
   arm: rmobile: Add support R8A7791
   arm: rmobile: Add support koelsch board
   arm: kzm9g: Fix undefined reference to `__aeabi_uldivmod' error
   arm: rmobile: Remove config.mk
 
  arch/arm/cpu/armv7/rmobile/Makefile  |   11 +-
  arch/arm/cpu/armv7/rmobile/config.mk |9 -
  arch/arm/cpu/armv7/rmobile/cpu_info-r8a7790.c|   22 +
  arch/arm/cpu/armv7/rmobile/cpu_info-r8a7791.c|   29 +
  arch/arm/cpu/armv7/rmobile/cpu_info.c|   10 +
  arch/arm/cpu/armv7/rmobile/lowlevel_init_ca15.S  |   60 ++
  arch/arm/cpu/armv7/rmobile/pfc-r8a7790.c |  829
 +++
  arch/arm/cpu/armv7/rmobile/pfc-r8a7790.h |   92 ++
  arch/arm/cpu/armv7/rmobile/pfc-r8a7791.c | 1117
 
  arch/arm/cpu/armv7/rmobile/timer.c   |8 +-
  arch/arm/include/asm/arch-rmobile/gpio.h |6 +
  arch/arm/include/asm/arch-rmobile/r8a7790-gpio.h |  387 +++
  arch/arm/include/asm/arch-rmobile/r8a7790.h  |  614 +++
  arch/arm/include/asm/arch-rmobile/r8a7791-gpio.h |  438 
  arch/arm/include/asm/arch-rmobile/r8a7791.h  |  664 
  arch/arm/include/asm/arch-rmobile/rmobile.h  |4 +
  board/renesas/koelsch/Makefile   |9 +
  board/renesas/koelsch/koelsch.c  |  283 +
  board/renesas/koelsch/qos.c  | 1220
 ++
  board/renesas/koelsch/qos.h  |   12 +
  board/renesas/lager/Makefile |9 +
  board/renesas/lager/lager.c  |  287 +
  board/renesas/lager/qos.c| 1119
 
  board/renesas/lager/qos.h|   12 +
  boards.cfg   |4 +
  include/configs/koelsch.h|  133 +++
  include/configs/lager.h  |  141 +++
  27 files changed, 7512 insertions(+), 17 deletions(-)
  delete mode 100644 arch/arm/cpu/armv7/rmobile/config.mk
  create mode 100644 arch/arm/cpu/armv7/rmobile/cpu_info-r8a7790.c
  create mode 100644 arch/arm/cpu/armv7/rmobile/cpu_info-r8a7791.c
  create mode 100644 arch/arm/cpu/armv7/rmobile/lowlevel_init_ca15.S
  create mode 100644 arch/arm/cpu/armv7/rmobile/pfc-r8a7790.c
  create mode 100644 arch/arm/cpu/armv7/rmobile/pfc-r8a7790.h
  create mode 100644 arch/arm/cpu/armv7/rmobile/pfc-r8a7791.c
  create mode 100644 arch/arm/include/asm/arch-rmobile/r8a7790-gpio.h
  create mode 100644 arch/arm/include/asm/arch-rmobile/r8a7790.h
  create mode 100644 arch/arm/include/asm/arch-rmobile/r8a7791-gpio.h
  create mode 100644 arch/arm/include/asm/arch-rmobile/r8a7791.h
  create mode 100644 board/renesas/koelsch/Makefile
  create mode 100644 board/renesas/koelsch/koelsch.c
  create mode 100644 board/renesas/koelsch/qos.c
  create mode 100644 board/renesas/koelsch/qos.h
  create mode 100644 board/renesas/lager/Makefile
  create mode 100644 board/renesas/lager/lager.c
  create mode 100644 board/renesas/lager/qos.c
  create mode 100644 board/renesas/lager/qos.h
  create mode 100644 include/configs/koelsch.h
  create mode 100644 include/configs/lager.h
 

Applied to u-boot-arm/master, thanks!

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

Re: [U-Boot] I want to a board(tiny4412) for exyno4412, but I can't get any output

[randy]

I may mistake the sdcard, in my board, the sdcard is connect
sd2(GPK2[0:6]), using the GPK2[2] as CDn.
But it still can't work. It don't light any LED at all(in my board, it
is the low power level of gpio which the led is connected to that light
the led).
==
From d83b3e370c01fbbdc5e287225ac725fffe01f6de Mon Sep 17 00:00:00 2001
From: ayaka ay...@mail.sumomo.pri
Date: Fri, 6 Dec 2013 19:29:41 +0800
Subject: [PATCH] board: Fix mmc pins and remove some no use gpio.

In my board, the sdcard is in mmc2, and using sd2_cdn to detect.
---
 board/samsung/tiny4412/tiny4412.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/board/samsung/tiny4412/tiny4412.c
b/board/samsung/tiny4412/tiny4412.c
index 4f5bfbd..f969866 100644
--- a/board/samsung/tiny4412/tiny4412.c
+++ b/board/samsung/tiny4412/tiny4412.c
@@ -41,6 +41,8 @@ static void check_hw_revision(void)
s5p_gpio_cfg_pin(gpio2-m1, i, GPIO_INPUT);

/* GPM1[5:2]: HW_REV[3:0] */
+   /*In my board, those pins are used for camera*/
+   /* GMP0[0:7] and GPM1[0:3] */
for (i = 2; i  6; i++) {
s5p_gpio_cfg_pin(gpio2-m1, i, GPIO_INPUT);
s5p_gpio_set_pull(gpio2-m1, i, GPIO_PULL_NONE);
@@ -87,9 +89,7 @@ static void board_external_gpio_init(void)
 * if that pin set as input then that floated
 */

-   s5p_gpio_set_pull(gpio2-x1, 5, GPIO_PULL_NONE);   /* IF_PMIC_IRQ*/
s5p_gpio_set_pull(gpio2-x3, 5, GPIO_PULL_NONE);   /* OK_KEY */
-   s5p_gpio_set_pull(gpio2-x3, 7, GPIO_PULL_NONE);   /* HDMI_HPD */
 }

 #ifdef CONFIG_SYS_I2C_INIT_BOARD
@@ -114,6 +114,7 @@ static void board_init_i2c(void)

 int board_early_init_f(void)
 {
+   /*pull up led*/
gpio2 = (struct exynos4x12_gpio_part2 *)EXYNOS4X12_GPIO_PART2_BASE;
s5p_gpio_cfg_pin(gpio2-m4, 1, GPIO_INPUT);
s5p_gpio_set_pull(gpio2-m4, 1, GPIO_PULL_NONE);
@@ -206,9 +207,9 @@ int board_mmc_init(bd_t *bis)

/*
 * Check the T-flash  detect pin
-* GPX3[4] T-flash detect pin
+* GPK2[2] T-flash detect pin
 */
-   if (!s5p_gpio_get_value(gpio2-x3, 4)) {
+   if (!s5p_gpio_get_value(gpio2-k2, 2)) {
err2 = exynos_pinmux_config(PERIPH_ID_SDMMC2, PINMUX_FLAG_NONE);
if (err2)
debug(SDMMC2 not configured\n);
-- 
1.8.4.rc3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3] am3517_evm: activate Ethernet PHY

[Tom Rini]

On Fri, Dec 06, 2013 at 06:59:52AM -0500, Tom Rini wrote:
 On Fri, Dec 06, 2013 at 11:47:38AM +0100, Yegor Yefremov wrote:
  On Fri, Dec 6, 2013 at 11:37 AM, Stefan Roese stefan.ro...@gmail.com 
  wrote:
   On 06.12.2013 11:17, yegorsli...@googlemail.com wrote:
   From: Yegor Yefremov yegorsli...@googlemail.com
  
   Pin 30 is connected to PHY's RESET# signal, so it must be
   put to high. Otherwise PHY won't be found via MDIO interface.
  
   Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com
  
   Looks good. One questions below though:
  
   ---
   Changes:
 v3: use __maybe_unused, instead of #if defined statement (Stefan 
   Roese)
 v2: put ctr and reset under #if defined statement, to avoid 
   compiler warnings, when EMAC is not selected
  
board/logicpd/am3517evm/am3517evm.c |   34 
   ++
board/logicpd/am3517evm/am3517evm.h |2 +-
2 files changed, 35 insertions(+), 1 deletions(-)
  
   diff --git a/board/logicpd/am3517evm/am3517evm.c 
   b/board/logicpd/am3517evm/am3517evm.c
   index 1569905..3b1dfd1 100644
   --- a/board/logicpd/am3517evm/am3517evm.c
   +++ b/board/logicpd/am3517evm/am3517evm.c
   @@ -22,6 +22,7 @@
#include asm/arch/musb.h
#include asm/mach-types.h
#include asm/errno.h
   +#include asm/gpio.h
#include linux/usb/ch9.h
#include linux/usb/gadget.h
#include linux/usb/musb.h
   @@ -31,6 +32,9 @@
  
DECLARE_GLOBAL_DATA_PTR;
  
   +#define AM3517_IP_SW_RESET   0x48002598
   +#define CPGMACSS_SW_RST  (1  1)
   +
/*
 * Routine: board_init
 * Description: Early hardware init.
   @@ -98,6 +102,9 @@ static void am3517_evm_musb_init(void)
 */
int misc_init_r(void)
{
   + __maybe_unused volatile unsigned int ctr;
   + __maybe_unused u32 reset;
   +
#ifdef CONFIG_SYS_I2C_OMAP34XX
 i2c_init(CONFIG_SYS_OMAP24_I2C_SPEED, CONFIG_SYS_OMAP24_I2C_SLAVE);
#endif
   @@ -106,6 +113,33 @@ int misc_init_r(void)
  
 am3517_evm_musb_init();
  
   +#if defined(CONFIG_DRIVER_TI_EMAC)
   + /* activate PHY reset */
   + gpio_direction_output(30, 0);
   + gpio_set_value(30, 0);
   +
   + ctr  = 0;
   + do {
   + udelay(1000);
   + ctr++;
   + } while (ctr  300);
   +
   + /* deactivate PHY reset */
   + gpio_set_value(30, 1);
   +
   + /* allow the PHY to stabilize and settle down */
   + ctr = 0;
   + do {
   + udelay(1000);
   + ctr++;
   + } while (ctr  300);
   +
   + /* ensure that the module is out of reset */
   + reset = readl(AM3517_IP_SW_RESET);
   + reset = (~CPGMACSS_SW_RST);
   + writel(reset,AM3517_IP_SW_RESET);
   +#endif
  
   Why do you need to put this #if defined(CONFIG_DRIVER_TI_EMAC) here at
   all? Isn't CONFIG_DRIVER_TI_EMAC enabled for this board always?
  
  It is enabled in arago repository:
  http://arago-project.org/git/projects/?p=u-boot-omap3.git;a=blob;f=include/configs/am3517_evm.h;h=b37b81e2aa5d635d14db87393e751ac25cb3611e;hb=HEAD,
  but not in upstream u-boot. I was testing the stuff with my own board,
  so my am3517_evm.h is a little bit messy for now. That's why I wanted
  to have this change only in board/logicpd/am3517evm/am3517evm.c. It
  does no harm so far. I could patch am3517_evm.h later.
 
 Ah, I forgot that I marked http://patchwork.ozlabs.org/patch/129720/ as
 Deferred way back when rather than merge it.  I don't know why I didn't
 need the bit you pulled in when I was testing eth.
 
 The right answer here is to do both of these so that we are using and
 testing the feature we add.  I'll see if I can dig up and boot up my
 am3517_evm.

Bah, it's not quite trivial to apply the old patch, some other stuff
needs to be enabled too, so I'll set this aside for now.

-- 
Tom


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

[U-Boot] Please pull u-boot-ti/master, v2

[Tom Rini]

Hey,

The following changes since commit 4c54419737ffbfadd605263d97a1357bb03c04e8:

  socfpga: Adding Freeze Controller driver (2013-12-03 14:38:56 +0100)

are available in the git repository at:

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

for you to fetch changes up to 18a02e8050b7af165efa72325753e7880bf5567c:

  AM3517 EVM: Enable ethernet (2013-12-06 07:04:26 -0500)


Hardik Patel (1):
  pandaboard: 1/1] ARM:OMAP4+: panda-es: Support Rev B3 Elpida DDR2 RAM

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

Lars Poeschel (1):
  pcm051: Support for revision 3

Lokesh Vutla (1):
  ARM: OMAP5+: Remove unnecessary EFUSE settings

Lubomir Popov (1):
  ARM: OMAP4: Fix bug in omap4470_volts struct

Michael Trimarchi (2):
  arm: omap3: Add uart4 omap3 adddress
  arm: omap3: Enable clocks for peripherals only if they are used

Oleg Kosheliev (2):
  ARMV7: OMAP4: Add struct for twl603x data
  ARMV7: OMAP4: Add twl6032 support

Roger Quadros (11):
  ahci: Error out with message on malloc() failure
  ahci: Fix cache align error messages
  ARM: OMAP5: Add Pipe3 PHY driver
  ARM: OMAP5: Add PRCM and Control information for SATA
  ARM: OMAP5: Add SATA platform glue
  ARM: omap5_uevm: Add SATA support
  ARM: DRA7xx: Add PRCM and Control information for SATA
  ARM: dra7_evm: Add SATA support
  usb: ehci-omap: Reset the USB Host OMAP module
  omap3_beagle: Don't use ulpi_reset
  omap4_panda: Don't use ulpi_reset

SRICHARAN R (3):
  ARM: DRA7: Add is_dra7xx cpu check definition
  ARM: DRA: EMIF: Change DDR3 settings to use hw leveling
  ARM: DRA7/OMAP5: EMIF: Add workaround for bug 0039

Stefan Roese (1):
  arm: am335x: Add DT (FDT) support to Siemens boards

Tom Rini (3):
  am33xx: Stop modifying certain EMIF4D registers
  am335x_evm: Update nandboot to use partitions and DT
  AM3517 EVM: Enable ethernet

Viktar Palstsiuk (1):
  davinci: fix Master Priority Registers location

Vladimir Koutny (1):
  am335x: cpsw: optimize cpsw_recv to increase network performance

 arch/arm/cpu/armv7/am33xx/ddr.c  |7 -
 arch/arm/cpu/armv7/omap-common/Makefile  |5 +
 arch/arm/cpu/armv7/omap-common/emif-common.c |  142 
 arch/arm/cpu/armv7/omap-common/pipe3-phy.c   |  231 ++
 arch/arm/cpu/armv7/omap-common/pipe3-phy.h   |   36 
 arch/arm/cpu/armv7/omap-common/sata.c|   75 +
 arch/arm/cpu/armv7/omap3/clock.c |2 -
 arch/arm/cpu/armv7/omap4/hw_data.c   |   12 +-
 arch/arm/cpu/armv7/omap4/sdram_elpida.c  |9 +-
 arch/arm/cpu/armv7/omap5/hw_data.c   |9 +-
 arch/arm/cpu/armv7/omap5/hwinit.c|   18 +-
 arch/arm/cpu/armv7/omap5/prcm-regs.c |7 +
 arch/arm/cpu/armv7/omap5/sdram.c |  214 +---
 arch/arm/include/asm/arch-am33xx/ddr_defs.h  |   37 ++---
 arch/arm/include/asm/arch-davinci/hardware.h |3 +-
 arch/arm/include/asm/arch-omap3/clock.h  |2 -
 arch/arm/include/asm/arch-omap3/omap3.h  |1 +
 arch/arm/include/asm/arch-omap4/sys_proto.h  |4 +
 arch/arm/include/asm/arch-omap5/clock.h  |3 +
 arch/arm/include/asm/arch-omap5/omap.h   |4 +
 arch/arm/include/asm/arch-omap5/sata.h   |   48 ++
 arch/arm/include/asm/emif.h  |   14 +-
 arch/arm/include/asm/omap_common.h   |   10 ++
 board/compulab/cm_t335/Makefile  |   10 ++
 board/compulab/cm_t335/cm_t335.c |  162 ++
 board/compulab/cm_t335/mux.c |  117 +
 board/compulab/cm_t335/spl.c |  106 
 board/compulab/cm_t335/u-boot.lds|  101 +++
 board/isee/igep0033/board.c  |4 -
 board/phytec/pcm051/board.c  |   53 --
 board/siemens/dxr2/board.c   |4 -
 board/siemens/pxm2/board.c   |5 -
 board/siemens/rut/board.c|5 -
 board/ti/am335x/board.c  |   17 --
 board/ti/dra7xx/evm.c|7 +
 board/ti/omap5_uevm/evm.c|7 +
 board/ti/panda/panda.c   |   60 +++
 board/ti/ti814x/evm.c|5 -
 board/ti/ti816x/evm.c|   17 --
 boards.cfg   |4 +-
 drivers/block/ahci.c |   18 +-
 drivers/net/cpsw.c   |2 +-
 drivers/power/twl6030.c  |   77 +++--
 drivers/usb/host/ehci-omap.c |   57 +--
 include/configs/am335x_evm.h |9 +-
 include/configs/am3517_evm.h |   14 +-
 include/configs/cm_t335.h   

Re: [U-Boot] [PATCH 0/9] ARMv7: add PSCI support to u-boot

[Marc Zyngier]

Hi Andre,

On 06/12/13 11:43, Andre Przywara wrote:
 On 11/21/2013 09:59 AM, Marc Zyngier wrote:
 PSCI is an ARM standard that provides a generic interface that
 ...
 
 Thanks again for posting this, I like the idea of adding PSCI handlers 
 to u-boot for several platforms very much.
 
 This patch series contains 3 parts:
 - the first four patches are just bug fixes
 
 Those are fine, I already acked those patches.
 
 - the next three contain the generic PSCI code and build infrastructure
 
 As I heard you will rework these anyway, I will refrain from commenting 
 in detail, just some generic comments on the approach:
 
 * Is the creation of a top-level psci directory for holding the PSCI 
 binaries really necessary? Should this mimic the spl approach?
 Can you consider to move this at least into the arch/arm directory, as 
 PSCI is ARM specific? Or add it to the SPL directory, as this serves a 
 similar purpose? But maybe your new approach renders this all moot.

The code base I have at the moment completely gets rid of the psci
directory, and make that code a separate section that can be relocated
to secure memory or simply marked as reserved.

 * Can you keep the SMP bringup code in place and re-use it from the PSCI 
 handlers instead of #ifndef PSCIing it? So maybe rename 
 arch/arm/cpu/armv7/sunxi/psci.S to .../sunxi/smp.S?
 My idea here is to make PSCI an option in addition to the current SMP 
 HYP mode code. So that for instance on VExpress (or better: Arndale) you 
 could either use the existing code using the kernel's platform SMP code 
 or enable PSCI in u-boot and let the kernel use that, too.

The main problem is the SMP wake-up code in u-boot. With PSCI, you
really don't want to wake up the secondaries at all, and you wait until
the kernel does an SMC. The current code wakes up the CPUs
unconditionnally, and put them in a separate pen, and I'd really like to
avoid dealing with a pen in the PSCI case (stupid platforms like
VExpress might still require it, but that's an orthogonal discussion).

 I maybe ask too much for the first incarnation of the code, but that is 
 how I would like to eventually see it. AFAIK Linux prefers PSCI over 
 platform-defined SMP code, so this should work out of the box.

Not really. So far, it will use the the platform SMP code if it is
defined, and fallback to PSCI otherwise. There were patches from Stephen
Boyd to use the enable-method property in the cpu node to select PSCI
though. I need to ping him on that.

 * Is the use of TPIDRPRW  Co. really safe? It looks like as we seem to 
 be the only secure user (and they are banked), but I am just curious 
 whether there is any prior art in using those registers temporarily.

As you said, we own secure mode entirely. So they really are scratch
registers, free to be used.

 ...
 The kernel now boots in HYP mode, finds its secondary CPU without any
 additional SMP code, and runs KVM out of the box. Hopefully, the
 Xen/ARM guys can do the same fairly easily.
 
 BTW: Yesterday my PSCI host patches for Xen have been committed, so Xen 
 should be able to use that feature just like the kernel does.

Excellent! I really need to sort these patches out and repost the whole
series...

Thanks,

M.
-- 
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

Re: [U-Boot] [linux-sunxi] Re: [PATCH 0/9] ARMv7: add PSCI support to u-boot

[Ian Campbell]

On Fri, 2013-12-06 at 12:12 +, Marc Zyngier wrote:
  BTW: Yesterday my PSCI host patches for Xen have been committed, so Xen 
  should be able to use that feature just like the kernel does.
 
 Excellent! I really need to sort these patches out and repost the whole
 series...

I was hoping to give this a go on my cb2 this afternoon. Do you happen
to have a public git tree of either this version or the upcoming new one
handy?

Ian.

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

Re: [U-Boot] [PATCH 0/9] ARMv7: add PSCI support to u-boot

[Andre Przywara]

On 12/06/2013 01:12 PM, Marc Zyngier wrote:

Hi Andre,

On 06/12/13 11:43, Andre Przywara wrote:

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

PSCI is an ARM standard that provides a generic interface that
...


Thanks again for posting this, I like the idea of adding PSCI handlers
to u-boot for several platforms very much.


This patch series contains 3 parts:
- the first four patches are just bug fixes


Those are fine, I already acked those patches.


- the next three contain the generic PSCI code and build infrastructure


As I heard you will rework these anyway, I will refrain from commenting
in detail, just some generic comments on the approach:

* Is the creation of a top-level psci directory for holding the PSCI
binaries really necessary? Should this mimic the spl approach?
Can you consider to move this at least into the arch/arm directory, as
PSCI is ARM specific? Or add it to the SPL directory, as this serves a
similar purpose? But maybe your new approach renders this all moot.


The code base I have at the moment completely gets rid of the psci
directory, and make that code a separate section that can be relocated
to secure memory or simply marked as reserved.


Nice!




* Can you keep the SMP bringup code in place and re-use it from the PSCI
handlers instead of #ifndef PSCIing it? So maybe rename
arch/arm/cpu/armv7/sunxi/psci.S to .../sunxi/smp.S?
My idea here is to make PSCI an option in addition to the current SMP
HYP mode code. So that for instance on VExpress (or better: Arndale) you
could either use the existing code using the kernel's platform SMP code
or enable PSCI in u-boot and let the kernel use that, too.


The main problem is the SMP wake-up code in u-boot. With PSCI, you
really don't want to wake up the secondaries at all, and you wait until
the kernel does an SMC. The current code wakes up the CPUs
unconditionnally,


Yes, and I want to do away with this if PSCI is defined - as this is not 
needed. I just asked for keeping the SMP wakeup code as generic as 
possible and neither tie it to PSCI nor HYP mode, so that either of them 
can reference that.

But, ...


and put them in a separate pen, and I'd really like to
avoid dealing with a pen in the PSCI case (stupid platforms like
VExpress might still require it, but that's an orthogonal discussion).


Yes, there is indeed this problem with the pen. Maybe one can use your 
upcoming relocation code to move the pen to a more secure place (defined 
per platform).
With avoid dealing with a pen you mean to wakeup from the system's pen 
and immediately jump to the OS init code, without staying in a wfi loop 
in some special memory?





I maybe ask too much for the first incarnation of the code, but that is
how I would like to eventually see it. AFAIK Linux prefers PSCI over
platform-defined SMP code, so this should work out of the box.


Not really. So far, it will use the the platform SMP code if it is
defined, and fallback to PSCI otherwise.


Indeed. So I was mistaken on this. I thought it worked this way once at 
least with Highbank/Midway (could have been an internal branch, though).



There were patches from Stephen
Boyd to use the enable-method property in the cpu node to select PSCI
though. I need to ping him on that.


That one that is mandatory on ARM64? Makes sense, then.

Regards,
Andre.




* Is the use of TPIDRPRW  Co. really safe? It looks like as we seem to
be the only secure user (and they are banked), but I am just curious
whether there is any prior art in using those registers temporarily.


As you said, we own secure mode entirely. So they really are scratch
registers, free to be used.


...
The kernel now boots in HYP mode, finds its secondary CPU without any
additional SMP code, and runs KVM out of the box. Hopefully, the
Xen/ARM guys can do the same fairly easily.


BTW: Yesterday my PSCI host patches for Xen have been committed, so Xen
should be able to use that feature just like the kernel does.


Excellent! I really need to sort these patches out and repost the whole
series...

Thanks,

M.



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

Re: [U-Boot] Pull request: u-boot-blackfin

[Tom Rini]

On Fri, Dec 06, 2013 at 04:14:42PM +0800, Sonic Zhang wrote:

 Hi Tom,
 
 Please pull the following patches from u-boot-blackfin into your tree.
 
 Thanks
 
 Sonic Zhang
 
 
 The following changes since commit f44483b57c49282299da0e5c10073b909cdad979:
 
   Merge branch 'serial' of git://git.denx.de/u-boot-microblaze
 (2013-12-02 08:48:02 -0500)
 
 are available in the git repository at:
 
 
   git://git.denx.de/u-boot-blackfin.git master
 
 for you to fetch changes up to 985e18d14e0cb3933311945d30de6357cf8be9df:
 
   blackfin: Do not generate unused header bootrom-asm-offsets.h
 (2013-12-06 16:06:51 +0800)
 
 
 Axel Lin (2):
   spi: bfin_spi: Remove unnecessary test for bus and pins[bus]
   spi: bfin_spi6xx: Remove unnecessary test for bus and pins[bus]
 
 Masahiro Yamada (1):
   blackfin: Do not generate unused header bootrom-asm-offsets.h
 
 Sonic Zhang (4):
   blackfin: Use ADI_GPIO2 driver other than the default ADI_GPIO1
   blackfin: If none ADI_GPIOX macro is defined, use ADI_GPIO1 as default
   blackfin: Add missing macro CONFIG_BFIN_SERIAL
   blackfin: soft-i2c: No need to define blackfin specific soft i2c
 operations
 
  Makefile   |  1 -
  arch/blackfin/cpu/.gitignore   |  2 --
  arch/blackfin/cpu/Makefile | 10 
  arch/blackfin/cpu/bootrom-asm-offsets.awk  | 41 
 --
  arch/blackfin/cpu/bootrom-asm-offsets.c.in | 12 -
  arch/blackfin/cpu/gpio.c   |  2 +-
  arch/blackfin/include/asm/gpio.h   |  2 +-
  drivers/spi/bfin_spi.c | 17 +++--
  drivers/spi/bfin_spi6xx.c  |  5 +---
  include/configs/bf506f-ezkit.h |  1 +
  include/configs/bf525-ucr2.h   |  1 +
  include/configs/bf533-stamp.h  | 29 ++---
  include/configs/bf537-minotaur.h   |  1 +
  include/configs/bf537-srv1.h   |  1 +
  include/configs/blackstamp.h   |  1 +
  include/configs/cm-bf548.h |  2 ++
  include/configs/dnp5370.h  |  1 +
  17 files changed, 22 insertions(+), 107 deletions(-)
  delete mode 100644 arch/blackfin/cpu/bootrom-asm-offsets.awk
  delete mode 100644 arch/blackfin/cpu/bootrom-asm-offsets.c.in

Applied to u-boot/master, thanks!

But please note that with gcc 4.5 from
http://sourceforge.net/projects/adi-toolchain/files/2013R1/2013R1_45-RC1/x86_64/
I see:
- SUMMARY 
Boards compiled: 30
Boards with errors: 7 ( cm-bf537u cm-bf537e bf561-acvilon blackvme
bf506f-ezkit tcm-bf537 bf561-ezkit )
Boards with warnings but no errors: 28 ( bf609-ezkit bf533-ezkit
bf525-ucr2 dnp5370 ip04 blackstamp cm-bf561 bf537-srv1 ibf-dsp561
bf527-sdp bf537-stamp bct-brettl2 bf537-minotaur bf538f-ezkit
bf526-ezbrd cm-bf527 bf527-ezkit br4 cm-bf548 cm-bf533 bf533-stamp
bf518f-ezbrd bf527-ad7160-eval bf548-ezkit pr1 bf527-ezkit-v2 tcm-bf518
bf537-pnav )
--

Can we address these warnings / errors?  Thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH v3] am3517_evm: activate Ethernet PHY

[Yegor Yefremov]

On Fri, Dec 6, 2013 at 1:14 PM, Tom Rini tr...@ti.com wrote:
 On Fri, Dec 06, 2013 at 06:59:52AM -0500, Tom Rini wrote:
 On Fri, Dec 06, 2013 at 11:47:38AM +0100, Yegor Yefremov wrote:
  On Fri, Dec 6, 2013 at 11:37 AM, Stefan Roese stefan.ro...@gmail.com 
  wrote:
   On 06.12.2013 11:17, yegorsli...@googlemail.com wrote:
   From: Yegor Yefremov yegorsli...@googlemail.com
  
   Pin 30 is connected to PHY's RESET# signal, so it must be
   put to high. Otherwise PHY won't be found via MDIO interface.
  
   Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com
  
   Looks good. One questions below though:
  
   ---
   Changes:
 v3: use __maybe_unused, instead of #if defined statement 
   (Stefan Roese)
 v2: put ctr and reset under #if defined statement, to avoid 
   compiler warnings, when EMAC is not selected
  
board/logicpd/am3517evm/am3517evm.c |   34 
   ++
board/logicpd/am3517evm/am3517evm.h |2 +-
2 files changed, 35 insertions(+), 1 deletions(-)
  
   diff --git a/board/logicpd/am3517evm/am3517evm.c 
   b/board/logicpd/am3517evm/am3517evm.c
   index 1569905..3b1dfd1 100644
   --- a/board/logicpd/am3517evm/am3517evm.c
   +++ b/board/logicpd/am3517evm/am3517evm.c
   @@ -22,6 +22,7 @@
#include asm/arch/musb.h
#include asm/mach-types.h
#include asm/errno.h
   +#include asm/gpio.h
#include linux/usb/ch9.h
#include linux/usb/gadget.h
#include linux/usb/musb.h
   @@ -31,6 +32,9 @@
  
DECLARE_GLOBAL_DATA_PTR;
  
   +#define AM3517_IP_SW_RESET   0x48002598
   +#define CPGMACSS_SW_RST  (1  1)
   +
/*
 * Routine: board_init
 * Description: Early hardware init.
   @@ -98,6 +102,9 @@ static void am3517_evm_musb_init(void)
 */
int misc_init_r(void)
{
   + __maybe_unused volatile unsigned int ctr;
   + __maybe_unused u32 reset;
   +
#ifdef CONFIG_SYS_I2C_OMAP34XX
 i2c_init(CONFIG_SYS_OMAP24_I2C_SPEED, 
   CONFIG_SYS_OMAP24_I2C_SLAVE);
#endif
   @@ -106,6 +113,33 @@ int misc_init_r(void)
  
 am3517_evm_musb_init();
  
   +#if defined(CONFIG_DRIVER_TI_EMAC)
   + /* activate PHY reset */
   + gpio_direction_output(30, 0);
   + gpio_set_value(30, 0);
   +
   + ctr  = 0;
   + do {
   + udelay(1000);
   + ctr++;
   + } while (ctr  300);
   +
   + /* deactivate PHY reset */
   + gpio_set_value(30, 1);
   +
   + /* allow the PHY to stabilize and settle down */
   + ctr = 0;
   + do {
   + udelay(1000);
   + ctr++;
   + } while (ctr  300);
   +
   + /* ensure that the module is out of reset */
   + reset = readl(AM3517_IP_SW_RESET);
   + reset = (~CPGMACSS_SW_RST);
   + writel(reset,AM3517_IP_SW_RESET);
   +#endif
  
   Why do you need to put this #if defined(CONFIG_DRIVER_TI_EMAC) here at
   all? Isn't CONFIG_DRIVER_TI_EMAC enabled for this board always?
 
  It is enabled in arago repository:
  http://arago-project.org/git/projects/?p=u-boot-omap3.git;a=blob;f=include/configs/am3517_evm.h;h=b37b81e2aa5d635d14db87393e751ac25cb3611e;hb=HEAD,
  but not in upstream u-boot. I was testing the stuff with my own board,
  so my am3517_evm.h is a little bit messy for now. That's why I wanted
  to have this change only in board/logicpd/am3517evm/am3517evm.c. It
  does no harm so far. I could patch am3517_evm.h later.

 Ah, I forgot that I marked http://patchwork.ozlabs.org/patch/129720/ as
 Deferred way back when rather than merge it.  I don't know why I didn't
 need the bit you pulled in when I was testing eth.

 The right answer here is to do both of these so that we are using and
 testing the feature we add.  I'll see if I can dig up and boot up my
 am3517_evm.

 Bah, it's not quite trivial to apply the old patch, some other stuff
 needs to be enabled too, so I'll set this aside for now.

I've added #define CONFIG_PHYLIB and #define CONFIG_OMAP_GPIO

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

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

[Tom Rini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/04/2013 06:47 PM, York Sun wrote:
 Tom,
 
 The following changes since commit f44483b57c49282299da0e5c10073b909cdad979:
 
   Merge branch 'serial' of git://git.denx.de/u-boot-microblaze
 (2013-12-02 08:48:02 -0500)
 
 are available in the git repository at:
 
 
   git://git.denx.de/u-boot-mpc85xx.git master
 
 for you to fetch changes up to 1df99080cb6dea9216ee1925f03bd7cc35dc34c7:
 
   powerpc/mpc8349: Use generic mpc85xx DDR driver (2013-12-04 14:55:05
 -0800)
 
 
 Dave Liu (1):
   powerpc/corenet: CPC1 speculation disable
 
 Po Liu (1):
   powerpc/c29xpcie: Getting DDR SPD image from 16-bit sub-address EEPROM
 
 Priyanka Jain (1):
   powerpc: spiflash:Add corenet devices support in eSPI SPL
 
 Shengzhou Liu (1):
   powerpc/t2080qds: undef CONFIG_FSL_DDR_INTERACTIVE
 
 York Sun (1):
   powerpc/mpc8349: Use generic mpc85xx DDR driver
 
 Zang Roy-R61911 (1):
   T4240: Address T4240/T4160 Rev2.0 DDR clock change
 
 Zhao Qiang (1):
   powerpc/p1010rdb:modify the mtest start_address
 
  arch/powerpc/cpu/mpc83xx/Makefile |4 +---
  arch/powerpc/cpu/mpc85xx/speed.c  |8 
  arch/powerpc/cpu/mpc85xx/start.S  |4 
  board/freescale/c29xpcie/ddr.c|   13 +
  drivers/mtd/spi/fsl_espi_spl.c|5 +
  include/configs/MPC8349EMDS.h |1 +
  include/configs/P1010RDB.h|2 +-
  include/configs/T2080QDS.h|2 +-
  8 files changed, 34 insertions(+), 5 deletions(-)

(Once more, for the mailing list too)
Applied to u-boot/master, thanks!

- -- 
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSodHhAAoJENk4IS6UOR1WAtAQAICRVx0wYARJRNHBh10R1wvq
mzXGRvIcAbv3JBiVSrus793o4g3L6GwSVqbnScA8BhhO8FQ1GfCYia/HB435EvoK
CaKf5/gP3H5nRI+ERZpST1gdF6xWE/HWoL3eA36e3x9CsQsQ+drY/PiPIHrKoYhq
MC0nPKzG3X3B0LN+w18sKtgIApk3lM6HyUe2eHlAmiefzLWyMdhIu+o5JDjO2e9M
2lq25K8e+wDf6hnyizx7OoIZ7XUhEe7CpFc8VtkEpmZDdyFsU0AP4G1eKyB1Xyhz
NAhsNtd+Glzo/QKecQVfP3gOsrGj5NaLVxolKibsspqhqUgwS3WgueY6ivd+xhOf
Gk0Nuo1CBJVAVKiVh7L5cgyKOLtloRrYEvc8pIooapnKBOELhYddFTAKkgIdbMWl
xDFy35ZZWdYMDrSM58WckAb7Aqx86pmthqgFNF1jj9UneWAUsYbWw3+Li/asYxRW
wcZC6J8mVIKQOMDV37ABhxFEe76uaAReig81ucaZHtm3eIvvUgVkO2VgNwOanR+P
28cUh+XcorW0KNSH0AaZ+J6e8idjSwfAjqdMEjDGkinrB/InuNbq0kIL0n8avbNV
j3ZpfX74JAfH/X1Y9bHiD2EmBvGURW20o/sZi/bV8DHRmcumCan9xGuba9ERgsj8
52EwyQp9MbgEW/Jbna8E
=csur
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Stefan Roese]

Hi Albert,

On 06.12.2013 13:06, Albert ARIBAUD wrote:
 On 06.12.2013 10:20, Yegor Yefremov wrote:
 This causes am3517_evm to fail with warnings:

 am3517evm.c: In function 'misc_init_r':
 am3517evm.c:106:6: warning: unused variable 'reset' [-Wunused-variable]
 am3517evm.c:105:24: warning: unused variable 'ctr' [-Wunused-variable]
 am3517evm.c: In function 'misc_init_r':
 am3517evm.c:106:6: warning: unused variable 'reset' [-Wunused-variable]
 am3517evm.c:105:24: warning: unused variable 'ctr' [-Wunused-variable]

 These are trivial, but I'd like them fixed; lingering warnings are a
 pain to manage when doing large-scale test build.

 These ones come from commit ae98bbeb, that is :

 Yegor Yefremov (1):
   am3517_evm: activate Ethernet PHY

 Yegor, can you fix this? Thanks.

 v2 sent. I've put those variables under if defined statement, so the
 warning has gone.

 In general its preferred to use the __maybe_unused statement instead of
 adding more #ifdef's. Like this:

 +__maybe_unused volatile unsigned int ctr;
 +__maybe_unused u32 reset;

 Care to send a v3 for this patch?

 Thanks,
 Stefan

 
 Hmm, if the variables are used under a clearly defined conditional, I
 prefer them to be defined under than conditional too. This makes
 it clearer what is affected when removing the conditional.

I personally still prefer the __maybe_unused version. And I have seen
other U-Boot developers also using it lately more frequently. The
removed #ifdef outweighs the added __maybe_unused for my taste.

Thanks,
Stefan

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

Re: [U-Boot] [PATCH REPOST] ARM: rpi_b: power on SDHCI and USB HW modules

[Andre Heider]

Hi Stephen,

On Tue, Dec 03, 2013 at 09:01:55PM -0700, Stephen Warren wrote:
 Send RPC commands to the VideoCore to turn on the SDHCI and USB modules.
 For SDHCI this isn't needed in practice, since the firmware already
 turned on the power in order to load U-Boot. However, it's best to be
 explicit. For USB, this is necessary, since the module isn't powered
 otherwise. This will allow the kernel USB driver to work.

I didn't test this patch yet, but from skimming over it it looks similar to
what I tried with barebox a while back.

What I did notice with the set power mbox call is that it takes way longer
than 100ms (the current mbox call timeout) to finish on a cold boot. You
don't seem to bump the timeout here, and with 100ms I always hit it and
hence the mbox call failed for me. Don't you get these huge delays?

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

Re: [U-Boot] Please pull u-boot-ti/master, v2

[Albert ARIBAUD]

Hi Tom,

On Fri, 6 Dec 2013 07:15:25 -0500, Tom Rini tr...@ti.com wrote:

 Hey,
 
 The following changes since commit 4c54419737ffbfadd605263d97a1357bb03c04e8:
 
   socfpga: Adding Freeze Controller driver (2013-12-03 14:38:56 +0100)
 
 are available in the git repository at:
 
   git://git.denx.de/u-boot-ti.git master
 
 for you to fetch changes up to 18a02e8050b7af165efa72325753e7880bf5567c:
 
   AM3517 EVM: Enable ethernet (2013-12-06 07:04:26 -0500)
 
 
 Hardik Patel (1):
   pandaboard: 1/1] ARM:OMAP4+: panda-es: Support Rev B3 Elpida DDR2 RAM
 
 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
 
 Lars Poeschel (1):
   pcm051: Support for revision 3
 
 Lokesh Vutla (1):
   ARM: OMAP5+: Remove unnecessary EFUSE settings
 
 Lubomir Popov (1):
   ARM: OMAP4: Fix bug in omap4470_volts struct
 
 Michael Trimarchi (2):
   arm: omap3: Add uart4 omap3 adddress
   arm: omap3: Enable clocks for peripherals only if they are used
 
 Oleg Kosheliev (2):
   ARMV7: OMAP4: Add struct for twl603x data
   ARMV7: OMAP4: Add twl6032 support
 
 Roger Quadros (11):
   ahci: Error out with message on malloc() failure
   ahci: Fix cache align error messages
   ARM: OMAP5: Add Pipe3 PHY driver
   ARM: OMAP5: Add PRCM and Control information for SATA
   ARM: OMAP5: Add SATA platform glue
   ARM: omap5_uevm: Add SATA support
   ARM: DRA7xx: Add PRCM and Control information for SATA
   ARM: dra7_evm: Add SATA support
   usb: ehci-omap: Reset the USB Host OMAP module
   omap3_beagle: Don't use ulpi_reset
   omap4_panda: Don't use ulpi_reset
 
 SRICHARAN R (3):
   ARM: DRA7: Add is_dra7xx cpu check definition
   ARM: DRA: EMIF: Change DDR3 settings to use hw leveling
   ARM: DRA7/OMAP5: EMIF: Add workaround for bug 0039
 
 Stefan Roese (1):
   arm: am335x: Add DT (FDT) support to Siemens boards
 
 Tom Rini (3):
   am33xx: Stop modifying certain EMIF4D registers
   am335x_evm: Update nandboot to use partitions and DT
   AM3517 EVM: Enable ethernet
 
 Viktar Palstsiuk (1):
   davinci: fix Master Priority Registers location
 
 Vladimir Koutny (1):
   am335x: cpsw: optimize cpsw_recv to increase network performance
 
  arch/arm/cpu/armv7/am33xx/ddr.c  |7 -
  arch/arm/cpu/armv7/omap-common/Makefile  |5 +
  arch/arm/cpu/armv7/omap-common/emif-common.c |  142 
  arch/arm/cpu/armv7/omap-common/pipe3-phy.c   |  231 
 ++
  arch/arm/cpu/armv7/omap-common/pipe3-phy.h   |   36 
  arch/arm/cpu/armv7/omap-common/sata.c|   75 +
  arch/arm/cpu/armv7/omap3/clock.c |2 -
  arch/arm/cpu/armv7/omap4/hw_data.c   |   12 +-
  arch/arm/cpu/armv7/omap4/sdram_elpida.c  |9 +-
  arch/arm/cpu/armv7/omap5/hw_data.c   |9 +-
  arch/arm/cpu/armv7/omap5/hwinit.c|   18 +-
  arch/arm/cpu/armv7/omap5/prcm-regs.c |7 +
  arch/arm/cpu/armv7/omap5/sdram.c |  214 +---
  arch/arm/include/asm/arch-am33xx/ddr_defs.h  |   37 ++---
  arch/arm/include/asm/arch-davinci/hardware.h |3 +-
  arch/arm/include/asm/arch-omap3/clock.h  |2 -
  arch/arm/include/asm/arch-omap3/omap3.h  |1 +
  arch/arm/include/asm/arch-omap4/sys_proto.h  |4 +
  arch/arm/include/asm/arch-omap5/clock.h  |3 +
  arch/arm/include/asm/arch-omap5/omap.h   |4 +
  arch/arm/include/asm/arch-omap5/sata.h   |   48 ++
  arch/arm/include/asm/emif.h  |   14 +-
  arch/arm/include/asm/omap_common.h   |   10 ++
  board/compulab/cm_t335/Makefile  |   10 ++
  board/compulab/cm_t335/cm_t335.c |  162 ++
  board/compulab/cm_t335/mux.c |  117 +
  board/compulab/cm_t335/spl.c |  106 
  board/compulab/cm_t335/u-boot.lds|  101 +++
  board/isee/igep0033/board.c  |4 -
  board/phytec/pcm051/board.c  |   53 --
  board/siemens/dxr2/board.c   |4 -
  board/siemens/pxm2/board.c   |5 -
  board/siemens/rut/board.c|5 -
  board/ti/am335x/board.c  |   17 --
  board/ti/dra7xx/evm.c|7 +
  board/ti/omap5_uevm/evm.c|7 +
  board/ti/panda/panda.c   |   60 +++
  board/ti/ti814x/evm.c|5 -
  board/ti/ti816x/evm.c|   17 --
  boards.cfg   |4 +-
  drivers/block/ahci.c |   18 +-
  drivers/net/cpsw.c   |2 +-
  drivers/power/twl6030.c  |   77 +++--
  

Re: [U-Boot] am3517: segmentation fault in Linux after upgrading from arago src to mainline u-boot

[Måns Rullgård]

Yegor Yefremov yegorsli...@googlemail.com writes:

 On Fri, Dec 6, 2013 at 8:28 AM, Yegor Yefremov
 yegorsli...@googlemail.com wrote:
 On Thu, Dec 5, 2013 at 6:28 PM, Måns Rullgård m...@mansr.com wrote:
 Yegor Yefremov yegorsli...@googlemail.com writes:

 On Thu, Nov 28, 2013 at 5:57 PM, Tom Rini tr...@ti.com wrote:
 On Thu, Nov 28, 2013 at 05:39:09PM +0100, Yegor Yefremov wrote:

 I'm having problems with the new u-boot (November 2013) and am3517
 SoC. When I start Debian 7.0 armhf I get lots of Segmentation faults,
 I can't even perform apt-get udpate. With the older u-boot (arago
 sources from 2010) everything seems to work properly.

 I've checked ATAG_MEM and both u-boot versions deliver same RAM start
 address and size. I've compared EMIF4 settings
 (arch/arm/cpu/armv7/omap3/emif4.c) and PINMUX and everything is the
 same.

 Where else can I look for differences?

 Can you bisect the arago tree from what it's based on, to what the top
 of tree is there?  Some errata or another being patched up I guess..

 I've compared the x-loader's init routine with the one from SPL. An
 found this workaround in the mainline U-Boot
 (arch/arm/cpu/armv7/omap3/board.c):

 static void omap3_setup_aux_cr(void)
 {
 /* Workaround for Cortex-A8 errata: #454179 #430973
  *  Set IBE bit
  *  Set Disable Branch Size Mispredicts bit
  * Workaround for erratum #621766
  *  Enable L1NEON bit
  * ACR |= (IBE | DBSM | L1NEON) = ACR |= 0xE0
  */
 omap3_update_aux_cr_secure(0xE0, 0);
 }

 After commenting this routine and I don't see any segmentation faults
 during apt usage.

 On an r1pX Cortex-A8 (as found in the 35xx chips) you absolutely want
 those bits set, especially if you're running Thumb2 code.  Otherwise you
 will get random crashes.

 Where can I find info, if am3517 is r1pX? I've looked through AM35x
 ARM Microprocessor: Technical Reference Manual, but found nothing
 similar.

 This info was in the Errata.pdf:

 AM3517AZCN i.e. silicon revision 1.1 (r1p7 ROM 15:58)

All of those errata are present in r1p7.  The 454179 and 430973 also
need workarounds enabled in the kernel.  Enabling the workarounds on a
CPU without the problems will not break anything, but it will cause a
minor performance drop.

-- 
Måns Rullgård
m...@mansr.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Albert ARIBAUD]

Hi Stefan,

On Fri, 06 Dec 2013 14:38:58 +0100, Stefan Roese s...@denx.de wrote:

 Hi Albert,
 
 On 06.12.2013 13:06, Albert ARIBAUD wrote:
  On 06.12.2013 10:20, Yegor Yefremov wrote:
  This causes am3517_evm to fail with warnings:
 
  am3517evm.c: In function 'misc_init_r':
  am3517evm.c:106:6: warning: unused variable 'reset' [-Wunused-variable]
  am3517evm.c:105:24: warning: unused variable 'ctr' [-Wunused-variable]
  am3517evm.c: In function 'misc_init_r':
  am3517evm.c:106:6: warning: unused variable 'reset' [-Wunused-variable]
  am3517evm.c:105:24: warning: unused variable 'ctr' [-Wunused-variable]
 
  These are trivial, but I'd like them fixed; lingering warnings are a
  pain to manage when doing large-scale test build.
 
  These ones come from commit ae98bbeb, that is :
 
  Yegor Yefremov (1):
am3517_evm: activate Ethernet PHY
 
  Yegor, can you fix this? Thanks.
 
  v2 sent. I've put those variables under if defined statement, so the
  warning has gone.
 
  In general its preferred to use the __maybe_unused statement instead of
  adding more #ifdef's. Like this:
 
  +  __maybe_unused volatile unsigned int ctr;
  +  __maybe_unused u32 reset;
 
  Care to send a v3 for this patch?
 
  Thanks,
  Stefan
 
  
  Hmm, if the variables are used under a clearly defined conditional, I
  prefer them to be defined under than conditional too. This makes
  it clearer what is affected when removing the conditional.
 
 I personally still prefer the __maybe_unused version. And I have seen
 other U-Boot developers also using it lately more frequently. The
 removed #ifdef outweighs the added __maybe_unused for my taste.

I respect your preference. However, my own taste is for making explicit
rather than implicit the reason why a variable is marked possibly
unused, therefore I would prefer the declarations to be under the same
conditional as their use.

Note however that in case where one cannot readily see the conditions
under which the variable is unused (e.g. if the variable is an
argument to a macro which may or may not use it), I'm ok with using
the attribute 'maybe_unused'.

Note also that in the case at hand, a solution may be to declare the
variables inside a block under the existing conditional; that
block could enclose the three lines below the ensure that the module is
out of reset comment. The declarations would then require neither
conditionals or attributes (and would be topologically as close to the
use as possible).

 Thanks,
 Stefan

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

Re: [U-Boot] [PATCH 2/5] port wandboards to use the generic distro configs

[Dennis Gilmore]

El Fri, 06 Dec 2013 11:59:05 +0100
Wolfgang Denk w...@denx.de escribió:
 Dear Dennis Gilmore,
 
 In message 1386296295-28658-3-git-send-email-den...@ausil.us you
 wrote:
 
  -   fdt_addr=0x1100\0 \
  +   fdt_addr=0x1110\0 \
  +   fdt_addr_r=0x1120\0 \
 
 Why would you need fdt_addr and fdt_addr_r ?  This makes no sense.
 Two different values would only be needed if there was NOR flash
 available where we could read the FDT from without loading it to RAM
 first.  AFAIK ther ewill never be variants of the Wandboard with NOR
 flash, so you will always have to load the FDT to RAM first - thus the
 destinction makes no sense.

please go and read the cmd_pxe.c file it specifies the use of the two
variables. one is for a system provided dtb and the other is for a user
provided dtb

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

Re: [U-Boot] toolchain problems when building iMX6 mx6qsabreauto (and another bootloader tool)

[Pierre Aubert]

Dear Måns Rullgård ,

On Wed, Dec 4, 2013 at 9:35 AM, Måns Rullgård [hidden email] wrote: 

 mx6: compute PLL PFD frequencies rather than using defines

 That commit introduces a 64-bit division without using the lldiv()
 function, which pulls in previously unused libgcc stuff.

Thank you for the fix. I missed the 64 bits division.

Best regards




--
View this message in context: 
http://u-boot.10912.n7.nabble.com/toolchain-problems-when-building-iMX6-mx6qsabreauto-and-another-bootloader-tool-tp168514p169107.html
Sent from the U-Boot mailing list archive at Nabble.com.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/5] port wandboards to use the generic distro configs

[Wolfgang Denk]

Dear Dennis Gilmore,

In message 20131206084854.0e0da...@adria.ausil.us you wrote:

 Wolfgang Denk w...@denx.de escribi=F3:
  Dear Dennis Gilmore,
 =20
  In message 1386296295-28658-3-git-send-email-den...@ausil.us you
  wrote:
  
   - fdt_addr=0x1100\0 \
   + fdt_addr=0x1110\0 \
   + fdt_addr_r=0x1120\0 \
  
  Why would you need fdt_addr and fdt_addr_r ?  This makes no sense.
  Two different values would only be needed if there was NOR flash
  available where we could read the FDT from without loading it to RAM
  first.  AFAIK ther ewill never be variants of the Wandboard with NOR
  flash, so you will always have to load the FDT to RAM first - thus the
  destinction makes no sense.

 please go and read the cmd_pxe.c file it specifies the use of the two
 variables. one is for a system provided dtb and the other is for a user
 provided dtb

But this is crap. The meaning of these variables has been wel-defined
for a long, long time.  fdt_addr is the FDT address in NOR flash (or
similar memory except system RAM); fdt_addr_r is the FDT address
when loaded to system RAM (hence the _r in the variable name).

Arbitariry redefining this meaning is counterproductive and confusing.

If cmd_pxe.c uses incorrect names, then please fix the bug there.

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
How does a project get to be a year late?  ... One day at a time.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [linux-sunxi] Re: [PATCH 0/9] ARMv7: add PSCI support to u-boot

[Ian Campbell]

(damn linux-sunxi reply-to vs. evolution madness ate your copy Marc,
sorry!)

On Fri, 2013-12-06 at 12:59 +, Ian Campbell wrote:
 On Fri, 2013-12-06 at 12:12 +, Marc Zyngier wrote:
   BTW: Yesterday my PSCI host patches for Xen have been committed, so Xen 
   should be able to use that feature just like the kernel does.
  
  Excellent! I really need to sort these patches out and repost the whole
  series...
 
 I was hoping to give this a go on my cb2 this afternoon. Do you happen
 to have a public git tree of either this version or the upcoming new one
 handy?

Actually, since this series doesn't build (no rule to make
sunxi-psci.bin...) I guess I'll wait for the upcoming one.

Ian.

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

[U-Boot] [RFC] ARM: Start using fdt_high for relocation

[Tom Rini]

Hey all,

I've been thinking.  We've had a thread on i.MX platforms about fdt
being overwritten and needing to be moved to another address.  And I've
also had an internal problem about fdt being overwritten.  So, how about
as a rule of thumb we start setting fdt_high (in configs) to
memory-start + 512MiB, as that's the lowmem limit we should always have
available.  This will fix the problem of BSS overwriting the DT, which
is the problem we won't catch in normal bootm/bootz usage.  Thoughts?

-- 
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] [linux-sunxi] Re: [PATCH 0/9] ARMv7: add PSCI support to u-boot

[Andre Przywara]

On 12/06/2013 04:44 PM, Ian Campbell wrote:

(damn linux-sunxi reply-to vs. evolution madness ate your copy Marc,
sorry!)

On Fri, 2013-12-06 at 12:59 +, Ian Campbell wrote:

On Fri, 2013-12-06 at 12:12 +, Marc Zyngier wrote:

BTW: Yesterday my PSCI host patches for Xen have been committed, so Xen
should be able to use that feature just like the kernel does.


Excellent! I really need to sort these patches out and repost the whole
series...


I was hoping to give this a go on my cb2 this afternoon. Do you happen
to have a public git tree of either this version or the upcoming new one
handy?


Actually, since this series doesn't build (no rule to make
sunxi-psci.bin...) I guess I'll wait for the upcoming one.


Have you observed this sentence is Marc's mail?

The patches are against a merge of u-boot mainline and the sunxi tree 
as of ten days ago.


Not sure if that really helps, though, I stopped at this point and just 
tried the first 7 patches.


But you may give this another shot as long as there are still the winds 
outside ;-) Or is it already over on the isles?


Regards,
Andre.

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

Re: [U-Boot] [PATCH 0/9] ARMv7: add PSCI support to u-boot

[Marc Zyngier]

On 06/12/13 13:03, Andre Przywara wrote:

 Yes, there is indeed this problem with the pen. Maybe one can use your 
 upcoming relocation code to move the pen to a more secure place (defined 
 per platform).

Yes, that's what I've done. Also rewritten some of it to be able to
execute solely in secure mode (you can't do SMC+HVC there, as you'd try
to run non-secure from secure RAM...).

 With avoid dealing with a pen you mean to wakeup from the system's pen 
 and immediately jump to the OS init code, without staying in a wfi loop 
 in some special memory?

Even better, waking up the CPUs from power-off directly, configuring the
per-cpu part of the GIC and jumping to the kernel. Almost nothing.

M.
-- 
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

Re: [U-Boot] [PATCH 2/5] port wandboards to use the generic distro configs

[Tom Rini]

On Fri, Dec 06, 2013 at 04:26:51PM +0100, Wolfgang Denk wrote:
 Dear Dennis Gilmore,
 
 In message 20131206084854.0e0da...@adria.ausil.us you wrote:
 
  Wolfgang Denk w...@denx.de escribi=F3:
   Dear Dennis Gilmore,
  =20
   In message 1386296295-28658-3-git-send-email-den...@ausil.us you
   wrote:
   
-   fdt_addr=0x1100\0 \
+   fdt_addr=0x1110\0 \
+   fdt_addr_r=0x1120\0 \
   
   Why would you need fdt_addr and fdt_addr_r ?  This makes no sense.
   Two different values would only be needed if there was NOR flash
   available where we could read the FDT from without loading it to RAM
   first.  AFAIK ther ewill never be variants of the Wandboard with NOR
   flash, so you will always have to load the FDT to RAM first - thus the
   destinction makes no sense.
 
  please go and read the cmd_pxe.c file it specifies the use of the two
  variables. one is for a system provided dtb and the other is for a user
  provided dtb
 
 But this is crap. The meaning of these variables has been wel-defined
 for a long, long time.  fdt_addr is the FDT address in NOR flash (or
 similar memory except system RAM); fdt_addr_r is the FDT address
 when loaded to system RAM (hence the _r in the variable name).

It's a well defined and widely ignored in ARM convention then.  We've
got lots of 'fdt_addr' meaning RAM and no 'fdt_addr_r' and then in both
ARM and PowerPC 'fdtaddr' being presumably RAM.

 Arbitariry redefining this meaning is counterproductive and confusing.
 
 If cmd_pxe.c uses incorrect names, then please fix the bug there.

I would say that 'fdt_addr' being the system provided DT, even when not
found on memory-mapped flash and 'fdt_addr_r' being the user provided
one is a logical extension.

If we want to set some new rules on these variables we're going to live
with for a long while and really document and enforce (see above about
fdt_addr/fdt_addr_r/fdtaddr current usage), OK, sure.

-- 
Tom


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

Re: [U-Boot] please pull u-boot-samsung master (v2)

[Albert ARIBAUD]

Hi Minkyu,

On Fri, 06 Dec 2013 19:51:21 +0900, Minkyu Kang mk7.k...@samsung.com
wrote:

 The following changes since commit d44a5f51288aec60c6bdb4ac939d75c24e5bf9c2:
 
   Merge branch 'u-boot-microblaze/zynq' into 'u-boot-arm/master' (2013-11-22 
 10:19:35 +0100)
 
 are available in the git repository at:
 
 
   git://git.denx.de/u-boot-samsung master
 
 for you to fetch changes up to 55f2118c11ff933e272c1084f93e72ff719a269b:
 
   arm: arndale: disable spi boot (2013-12-06 19:18:13 +0900)
 
 
 Jaehoon Chung (3):
   arm: exynos: fix set_mmc_clk for exynos4x12
   arm: exynos/goni: fix the return type for s5p_mmc_init
   arm: exynos: remove the unused define.
 
 Luka Perkov (1):
   config: arm: exynos5250: remove duplicate defines
 
 Minkyu Kang (3):
   arm: exynos: fix the align for exynos4_power structure
   arm: exynos: adds ifdef for spi boot
   arm: arndale: disable spi boot
 
 Piotr Wilczek (7):
   driver:usb:s3c_udc: add support for Exynos4x12
   trats2: enable ums support on Trats2
   trats2: enable dfu and thor protocol for Tizen download
   board: trats2: remove unused defines from config file
   board: trats2: fix environmental variables
   board: trats2: fix access to samsung registers
   board: trats2: update Tizen partition definitions
 
 Przemyslaw Marczak (1):
   trats: usb: Add usb_cable_connected() function
 
 Rajeshwari Shinde (1):
   exynos: spl: Add a custom spi copy function
 
  arch/arm/cpu/armv7/exynos/clock.c|3 +-
  arch/arm/cpu/armv7/exynos/pinmux.c   |2 +-
  arch/arm/cpu/armv7/exynos/spl_boot.c |  126 
 +-
  arch/arm/include/asm/arch-exynos/dwmmc.h |4 -
  arch/arm/include/asm/arch-exynos/mmc.h   |2 +-
  arch/arm/include/asm/arch-exynos/power.h |2 +-
  arch/arm/include/asm/arch-exynos/spi.h   |1 +
  arch/arm/include/asm/arch-s5pc1xx/mmc.h  |2 +-
  board/samsung/trats/trats.c  |   11 +++
  board/samsung/trats2/trats2.c|  108 +++--
  drivers/usb/gadget/regs-otg.h|5 ++
  drivers/usb/gadget/s3c_udc_otg.c |9 ++-
  include/configs/arndale.h|4 -
  include/configs/exynos5250-dt.h  |   25 +-
  include/configs/trats.h  |1 +
  include/configs/trats2.h |   68 +++-
  16 files changed, 304 insertions(+), 69 deletions(-)

Applied to u-boot-arm/master, thanks!

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

Re: [U-Boot] [PATCH] t2080qds/ddr: update ddr parameters

[York Sun]

On 12/06/2013 12:53 AM, Shengzhou Liu wrote:
 - optimize ddr parameters for whole frequency range from 1500MT/s to 2140MT/s.
 - remove unused patameters: 'cpo', 'wrdata delay', '2T', which is unrelated
   to DDR3/3L on t2080qds.
 - remove unused rdimm code(only udimm is supported on t2080qds).
 
 Signed-off-by: Shengzhou Liu shengzhou@freescale.com
 ---
 Against master branch of git://git.denx.de/u-boot-mpc85xx.git
 
  board/freescale/t2080qds/ddr.c | 20 ++---
  board/freescale/t2080qds/ddr.h | 64 
 +-
  2 files changed, 17 insertions(+), 67 deletions(-)
 
 diff --git a/board/freescale/t2080qds/ddr.c b/board/freescale/t2080qds/ddr.c
 index 5db5d21..bc366ae 100644
 --- a/board/freescale/t2080qds/ddr.c
 +++ b/board/freescale/t2080qds/ddr.c
 @@ -24,24 +24,17 @@ void fsl_ddr_board_options(memctl_options_t *popts,
   const struct board_specific_parameters *pbsp, *pbsp_highest = NULL;
   ulong ddr_freq;
  
 - if (ctrl_num  2) {
 + if (ctrl_num  1) {
   printf(Not supported controller number %d\n, ctrl_num);
   return;
   }
   if (!pdimm-n_ranks)
   return;
  
 - /*
 -  * we use identical timing for all slots. If needed, change the code
 -  * to  pbsp = rdimms[ctrl_num] or pbsp = udimms[ctrl_num];
 -  */
 - if (popts-registered_dimm_en)
 - pbsp = rdimms[0];
 - else
 - pbsp = udimms[0];
 + pbsp = udimms[0];
  

This is not right. You should throw out an error if RDIMM is not
supported. But why isn't it supported? T2080 SoC can support RDIMM.

York


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

Re: [U-Boot] Stale references in the u-boot-samsung repo

[Albert ARIBAUD]

Hi Minkyu,

On Fri, 06 Dec 2013 19:44:28 +0900, Minkyu Kang mk7.k...@samsung.com
wrote:

 Hi Albert,
 
 On 06/12/13 17:44, Albert ARIBAUD wrote:
  Hi Minkyu,
  
  While fetching u-boot-samsung, I could see the following messages:
  
  remote: error: refs/remotes/origin/GPL-Cleanup does not point to a
  valid object!
  
  remote: error: refs/remotes/origin/i.MX31 does not point to a valid
  object!
  
  remote: error: refs/remotes/origin/lwmon5 does not point to a valid
  object!
  
  remote: error: refs/remotes/origin/mkimage does not point to a valid
  object!
  
  It looks like these branches that were pushed on the remote, then later
  the commit to which they point was cleaned up.
  
  Can you fix this? Thanks in advance!
  
 
 Please let me know how I can fix it!

For branches which you still need to publish and for which are correct
in your working repo, you can do a push as you would for master or
next, e.g.

git push [...] branchname:branchname

where branchname should be replaced (on both sides of the colon) with
the actual name of the branch you want to update.

For branches which you don't need to publish any more, you can remove
them on the Denx repo with:

git push [...] :branchname

where there is nothing on the left side of the colon, and branchname
is replaced with the actual name of the branch you want to remove.

 Thanks,
 Minkyu Kang.

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

Re: [U-Boot] Stale references in the u-boot-samsung repo

[Tom Rini]

On Fri, Dec 06, 2013 at 09:44:22AM +0100, Albert ARIBAUD wrote:
 Hi Minkyu,
 
 While fetching u-boot-samsung, I could see the following messages:
 
 remote: error: refs/remotes/origin/GPL-Cleanup does not point to a
 valid object!
 
 remote: error: refs/remotes/origin/i.MX31 does not point to a valid
 object!
 
 remote: error: refs/remotes/origin/lwmon5 does not point to a valid
 object!
 
 remote: error: refs/remotes/origin/mkimage does not point to a valid
 object!
 
 It looks like these branches that were pushed on the remote, then later
 the commit to which they point was cleaned up.
 
 Can you fix this? Thanks in advance!

Note that these aren't a u-boot-samsung specific problem, I see this too
for master, but have just ignored it.

-- 
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] [RFC] ARM: Start using fdt_high for relocation

[Albert ARIBAUD]

Hi Tom,

On Fri, 6 Dec 2013 10:48:50 -0500, Tom Rini tr...@ti.com wrote:

 Hey all,
 
 I've been thinking.  We've had a thread on i.MX platforms about fdt
 being overwritten and needing to be moved to another address.  And I've
 also had an internal problem about fdt being overwritten.  So, how about
 as a rule of thumb we start setting fdt_high (in configs) to
 memory-start + 512MiB, as that's the lowmem limit we should always have
 available.  This will fix the problem of BSS overwriting the DT, which
 is the problem we won't catch in normal bootm/bootz usage.  Thoughts?

Not sure I'm getting the issue clear, and I would like to avoid (me and
others) having to switch back and forth between threads. Can you sketch
the failure scenario in a couple of lines?

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

Re: [U-Boot] I want to a board(tiny4412) for exyno4412, but I can't get any output

[randy]

sorry, I sent attach git format-patch directly, it cause the mistake
mail, the patch is below.
The SPL(bl2) is still the old one from manufacturer, as I don't know how
to build a new one.
I don't know much debug method, the how to use JTAG of it. Could anyone
teach me some of it?
Thanks.
[PATCH] board: Fix mmc pins and remove some no use gpio.

In my board, the sdcard is in mmc2, and using sd2_cdn to detect.
---
 board/samsung/tiny4412/tiny4412.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/board/samsung/tiny4412/tiny4412.c
b/board/samsung/tiny4412/tiny4412.c
index 4f5bfbd..f969866 100644
--- a/board/samsung/tiny4412/tiny4412.c
+++ b/board/samsung/tiny4412/tiny4412.c
@@ -41,6 +41,8 @@ static void check_hw_revision(void)
s5p_gpio_cfg_pin(gpio2-m1, i, GPIO_INPUT);

/* GPM1[5:2]: HW_REV[3:0] */
+   /*In my board, those pins are used for camera*/
+   /* GMP0[0:7] and GPM1[0:3] */
for (i = 2; i  6; i++) {
s5p_gpio_cfg_pin(gpio2-m1, i, GPIO_INPUT);
s5p_gpio_set_pull(gpio2-m1, i, GPIO_PULL_NONE);
@@ -87,9 +89,7 @@ static void board_external_gpio_init(void)
 * if that pin set as input then that floated
 */

-   s5p_gpio_set_pull(gpio2-x1, 5, GPIO_PULL_NONE);   /* IF_PMIC_IRQ*/
s5p_gpio_set_pull(gpio2-x3, 5, GPIO_PULL_NONE);   /* OK_KEY */
-   s5p_gpio_set_pull(gpio2-x3, 7, GPIO_PULL_NONE);   /* HDMI_HPD */
 }

 #ifdef CONFIG_SYS_I2C_INIT_BOARD
@@ -114,6 +114,7 @@ static void board_init_i2c(void)

 int board_early_init_f(void)
 {
+   /*pull up led*/
gpio2 = (struct exynos4x12_gpio_part2 *)EXYNOS4X12_GPIO_PART2_BASE;
s5p_gpio_cfg_pin(gpio2-m4, 1, GPIO_INPUT);
s5p_gpio_set_pull(gpio2-m4, 1, GPIO_PULL_NONE);
@@ -206,9 +207,9 @@ int board_mmc_init(bd_t *bis)

/*
 * Check the T-flash  detect pin
-* GPX3[4] T-flash detect pin
+* GPK2[2] T-flash detect pin
 */
-   if (!s5p_gpio_get_value(gpio2-x3, 4)) {
+   if (!s5p_gpio_get_value(gpio2-k2, 2)) {
err2 = exynos_pinmux_config(PERIPH_ID_SDMMC2, PINMUX_FLAG_NONE);
if (err2)
debug(SDMMC2 not configured\n);
-- 1.8.4.rc3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC] implementation of generic distro configs

[Tom Rini]

On Thu, Dec 05, 2013 at 08:18:10PM -0600, Dennis Gilmore wrote:

 As a followup to http://lists.denx.de/pipermail/u-boot/2013-August/160080.html
 ive put together what i Think is a reasonable starting point for defining a
 unified set of features and options. 
 
 There are some things that really need some more work yet. mostly to do with
 austomatically loading of the dtb.  All of these patches are currently enabled
 in Fedora's u-boot builds.
 
 the wandboard in particular has received a lot of testing using
 sysboot command to load a extlinux.conf file. which did pick up bugs
 in teh pxe.c code early on.
 I would appreciate some feedback from a wider audience as we move to
 making this be a default configuration.

I think you've got the breakdown in relative locations wrong.  And, per
the email I sent out after this, I think we should start using fdt_high
at least for its intended purpose, moving the DT out of the way of what
we know about.

The breakdown I see in your series is (or similar):
 + fdt_addr_r=0x8110\0 \
 + fdt_addr=0x8120\0 \
 + pxefile_addr_r=0x8130\0 \
 + kernel_addr_r=0x8140\0 \
 + ramdisk_addr_r=0x8340\0 \

Now the issues we have to deal with are:
1) zImage running into ramdisk.  There's 32MiB here, so that's unlikely,
hopefully, for a while at least.
2) When the zImage runs, it will unpack the kernel to top of memory and
then BSS follows.  You've only left ~17MiB for that, and that's iffy.
When you start enabling function tracing and some other stuff, that's
close, on a single platform image.  I bet a multi-platform runs into the
DT.

#2 is why the defaults on these platforms place the DT in memory after
the kernel image, before the ramdisk.  I think we can get a better
situation out of this by saying the u-boot used parts (pxefile) are
as low as we can (start of memory), throw in the reasonable size, then
place the kernel, 32MiB gap, 1MiB gap for each DT (which I really hope
is more than enough..), then the ramdisk.

This just leaves the worry of 32MiB for a kernel + BSS being an uncaught
conflict.  One could stop worrying about this, largely I think, if we
set fdt_high to memory base + 512MiB and then do some corner case
testing to make sure that we do not relocate on top of the end of a
large ramdisk, and that the only cases which simply do not work are the
cases where you flat out do not have enough memory for what you're
trying to load (giant kernel + giant ramdisk on a nowadays-small 128MiB
DDR system for example).

-- 
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] [RFC] ARM: Start using fdt_high for relocation

[Tom Rini]

On Fri, Dec 06, 2013 at 05:59:37PM +0100, Albert ARIBAUD wrote:
 Hi Tom,
 
 On Fri, 6 Dec 2013 10:48:50 -0500, Tom Rini tr...@ti.com wrote:
 
  Hey all,
  
  I've been thinking.  We've had a thread on i.MX platforms about fdt
  being overwritten and needing to be moved to another address.  And I've
  also had an internal problem about fdt being overwritten.  So, how about
  as a rule of thumb we start setting fdt_high (in configs) to
  memory-start + 512MiB, as that's the lowmem limit we should always have
  available.  This will fix the problem of BSS overwriting the DT, which
  is the problem we won't catch in normal bootm/bootz usage.  Thoughts?
 
 Not sure I'm getting the issue clear, and I would like to avoid (me and
 others) having to switch back and forth between threads. Can you sketch
 the failure scenario in a couple of lines?

Sure.  Lets take am335x_evm builds (so Beaglebone Black/White, etc).
If you start enabling all of the tracing options in the kernel (function
tracing, graphs, etc), you get an uncompressed kernel and BSS that will
use up the first ~16MiB of DDR.  We default to placing the DT at about
15MiB into memory.  So the kernel runs, clears BSS and eats the DT.
System now hangs, and depending on debug options set you may or may not
see anything at all from the kernel.  U-Boot couldn't detect this
failure because we don't know how big the kernel BSS is, only how big
the zImage is (and where it is) and how big the fdt is and where it is.
No overlaps, go ahead and run.

-- 
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] [linux-sunxi] Re: [PATCH 0/9] ARMv7: add PSCI support to u-boot

[Ian Campbell]

On Fri, 2013-12-06 at 16:48 +0100, Andre Przywara wrote:
 On 12/06/2013 04:44 PM, Ian Campbell wrote:
  (damn linux-sunxi reply-to vs. evolution madness ate your copy Marc,
  sorry!)
 
  On Fri, 2013-12-06 at 12:59 +, Ian Campbell wrote:
  On Fri, 2013-12-06 at 12:12 +, Marc Zyngier wrote:
  BTW: Yesterday my PSCI host patches for Xen have been committed, so Xen
  should be able to use that feature just like the kernel does.
 
  Excellent! I really need to sort these patches out and repost the whole
  series...
 
  I was hoping to give this a go on my cb2 this afternoon. Do you happen
  to have a public git tree of either this version or the upcoming new one
  handy?
 
  Actually, since this series doesn't build (no rule to make
  sunxi-psci.bin...) I guess I'll wait for the upcoming one.
 
 Have you observed this sentence is Marc's mail?
 
 The patches are against a merge of u-boot mainline and the sunxi tree 
 as of ten days ago.

The sunxi tree today has mainline v2014.01-rc1 in it, which I'd assumed
was new enough because it was tagged after Marc posted these patches.

Nothing between v2013.01-rc1 and the current mainline looks related.

Ian.

 Not sure if that really helps, though, I stopped at this point and just 
 tried the first 7 patches.
 
 But you may give this another shot as long as there are still the winds 
 outside ;-) Or is it already over on the isles?
 
 Regards,
 Andre.
 
 


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

Re: [U-Boot] [linux-sunxi] Re: [PATCH 0/9] ARMv7: add PSCI support to u-boot

[Marc Zyngier]

On 06/12/13 17:21, Ian Campbell wrote:
 On Fri, 2013-12-06 at 16:48 +0100, Andre Przywara wrote:
 On 12/06/2013 04:44 PM, Ian Campbell wrote:
 (damn linux-sunxi reply-to vs. evolution madness ate your copy Marc,
 sorry!)

 On Fri, 2013-12-06 at 12:59 +, Ian Campbell wrote:
 On Fri, 2013-12-06 at 12:12 +, Marc Zyngier wrote:
 BTW: Yesterday my PSCI host patches for Xen have been committed, so Xen
 should be able to use that feature just like the kernel does.

 Excellent! I really need to sort these patches out and repost the whole
 series...

 I was hoping to give this a go on my cb2 this afternoon. Do you happen
 to have a public git tree of either this version or the upcoming new one
 handy?

 Actually, since this series doesn't build (no rule to make
 sunxi-psci.bin...) I guess I'll wait for the upcoming one.

 Have you observed this sentence is Marc's mail?

 The patches are against a merge of u-boot mainline and the sunxi tree 
 as of ten days ago.
 
 The sunxi tree today has mainline v2014.01-rc1 in it, which I'd assumed
 was new enough because it was tagged after Marc posted these patches.
 
 Nothing between v2013.01-rc1 and the current mainline looks related.

Don't underestimate my own capacity to screw things up in a devastating
way... ;-)

I'll try to sort my patches tomorrow morning, and hopefully won't mess
it up this time. And given that I'm heading for Devonshire in a couple
of hours (hint, hint!), it is not a strong guarantee... :D

M.
-- 
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

Re: [U-Boot] [PATCH 3/4] at91: nand: switch atmel_nand to generic GPIO API

[Scott Wood]

On Fri, 2013-11-29 at 12:13 +0100, Andreas Bießmann wrote:
 Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com
 ---
  board/BuS/vl_ma2sc/vl_ma2sc.c  |5 +++--
  board/egnite/ethernut5/ethernut5.c |3 ++-
  board/esd/meesc/meesc.c|5 +++--
  board/esd/otc570/otc570.c  |5 +++--
  board/eukrea/cpu9260/cpu9260.c |5 +++--
  board/ronetix/pm9261/pm9261.c  |5 +++--
  board/ronetix/pm9263/pm9263.c  |5 +++--
  board/ronetix/pm9g45/pm9g45.c  |5 +++--
  drivers/mtd/nand/atmel_nand.c  |8 +++-
  include/configs/at91sam9n12ek.h|4 ++--
  include/configs/cpu9260.h  |4 ++--
  include/configs/ethernut5.h|2 +-
  include/configs/meesc.h|4 ++--
  include/configs/otc570.h   |4 ++--
  include/configs/pm9261.h   |4 ++--
  include/configs/pm9263.h   |4 ++--
  include/configs/pm9g45.h   |4 ++--
  include/configs/vl_ma2sc.h |4 ++--
  18 files changed, 43 insertions(+), 37 deletions(-)

Acked-by: Scott Wood scottw...@freescale.com

-Scott



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

Re: [U-Boot] [PATCH REPOST] ARM: rpi_b: power on SDHCI and USB HW modules

[Stephen Warren]

On 12/06/2013 06:37 AM, Andre Heider wrote:
 Hi Stephen,
 
 On Tue, Dec 03, 2013 at 09:01:55PM -0700, Stephen Warren wrote:
 Send RPC commands to the VideoCore to turn on the SDHCI and USB modules.
 For SDHCI this isn't needed in practice, since the firmware already
 turned on the power in order to load U-Boot. However, it's best to be
 explicit. For USB, this is necessary, since the module isn't powered
 otherwise. This will allow the kernel USB driver to work.
 
 I didn't test this patch yet, but from skimming over it it looks similar to
 what I tried with barebox a while back.
 
 What I did notice with the set power mbox call is that it takes way longer
 than 100ms (the current mbox call timeout) to finish on a cold boot. You
 don't seem to bump the timeout here, and with 100ms I always hit it and
 hence the mbox call failed for me. Don't you get these huge delays?

I didn't notice this, but I'll have to double-check to be completely sure.

What firmware version are you using? I'm currently using the latest
firmware (as of a week or two ago) from the git repo in github. I do
recall issues with the set_power call operating incorrectly, although I
think not a timeout, in the past, but that issue was mostly fixed in a
firmware update quite a while ago. For details, see:

https://github.com/raspberrypi/firmware/issues/106
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC] ARM: Start using fdt_high for relocation

[Albert ARIBAUD]

Hi Tom,

On Fri, 6 Dec 2013 12:18:13 -0500, Tom Rini tr...@ti.com wrote:

 On Fri, Dec 06, 2013 at 05:59:37PM +0100, Albert ARIBAUD wrote:
  Hi Tom,
  
  On Fri, 6 Dec 2013 10:48:50 -0500, Tom Rini tr...@ti.com wrote:
  
   Hey all,
   
   I've been thinking.  We've had a thread on i.MX platforms about fdt
   being overwritten and needing to be moved to another address.  And I've
   also had an internal problem about fdt being overwritten.  So, how about
   as a rule of thumb we start setting fdt_high (in configs) to
   memory-start + 512MiB, as that's the lowmem limit we should always have
   available.  This will fix the problem of BSS overwriting the DT, which
   is the problem we won't catch in normal bootm/bootz usage.  Thoughts?
  
  Not sure I'm getting the issue clear, and I would like to avoid (me and
  others) having to switch back and forth between threads. Can you sketch
  the failure scenario in a couple of lines?
 
 Sure.  Lets take am335x_evm builds (so Beaglebone Black/White, etc).
 If you start enabling all of the tracing options in the kernel (function
 tracing, graphs, etc), you get an uncompressed kernel and BSS that will
 use up the first ~16MiB of DDR.  We default to placing the DT at about
 15MiB into memory.  So the kernel runs, clears BSS and eats the DT.
 System now hangs, and depending on debug options set you may or may not
 see anything at all from the kernel.  U-Boot couldn't detect this
 failure because we don't know how big the kernel BSS is, only how big
 the zImage is (and where it is) and how big the fdt is and where it is.
 No overlaps, go ahead and run.

Thanks.

The only issue I have with the RFC is that the +512 MiB value will only
work with targets which have more than 512 MiB DDR, right? But since
you're suggesting this should be set in configs, you are only suggesting
+512 MiB, and any target could actually specify a lower value as long as
it's greater than or eqal to 16 MiB. Correct?

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

Re: [U-Boot] [RFC] ARM: Start using fdt_high for relocation

[Wolfgang Denk]

Dear Tom,

In message 20131206154850.GW420@bill-the-cat you wrote:
 
 I've been thinking.  We've had a thread on i.MX platforms about fdt
 being overwritten and needing to be moved to another address.  And I've
 also had an internal problem about fdt being overwritten.  So, how about
 as a rule of thumb we start setting fdt_high (in configs) to
 memory-start + 512MiB, as that's the lowmem limit we should always have
 available.  This will fix the problem of BSS overwriting the DT, which
 is the problem we won't catch in normal bootm/bootz usage.  Thoughts?

Maybe I'm missing something - but what about systems with less than
1 GB RAM?  Actually only a small percentage of devices we see here
have 512 MB or more...

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
In the bathtub of history the truth is harder to hold than the  soap,
and much more difficult to find ... - Terry Pratchett, _Sourcery_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC] ARM: Start using fdt_high for relocation

[Tom Rini]

On Fri, Dec 06, 2013 at 08:28:04PM +0100, Albert ARIBAUD wrote:
 Hi Tom,
 
 On Fri, 6 Dec 2013 12:18:13 -0500, Tom Rini tr...@ti.com wrote:
 
  On Fri, Dec 06, 2013 at 05:59:37PM +0100, Albert ARIBAUD wrote:
   Hi Tom,
   
   On Fri, 6 Dec 2013 10:48:50 -0500, Tom Rini tr...@ti.com wrote:
   
Hey all,

I've been thinking.  We've had a thread on i.MX platforms about fdt
being overwritten and needing to be moved to another address.  And I've
also had an internal problem about fdt being overwritten.  So, how about
as a rule of thumb we start setting fdt_high (in configs) to
memory-start + 512MiB, as that's the lowmem limit we should always have
available.  This will fix the problem of BSS overwriting the DT, which
is the problem we won't catch in normal bootm/bootz usage.  Thoughts?
   
   Not sure I'm getting the issue clear, and I would like to avoid (me and
   others) having to switch back and forth between threads. Can you sketch
   the failure scenario in a couple of lines?
  
  Sure.  Lets take am335x_evm builds (so Beaglebone Black/White, etc).
  If you start enabling all of the tracing options in the kernel (function
  tracing, graphs, etc), you get an uncompressed kernel and BSS that will
  use up the first ~16MiB of DDR.  We default to placing the DT at about
  15MiB into memory.  So the kernel runs, clears BSS and eats the DT.
  System now hangs, and depending on debug options set you may or may not
  see anything at all from the kernel.  U-Boot couldn't detect this
  failure because we don't know how big the kernel BSS is, only how big
  the zImage is (and where it is) and how big the fdt is and where it is.
  No overlaps, go ahead and run.
 
 Thanks.
 
 The only issue I have with the RFC is that the +512 MiB value will only
 work with targets which have more than 512 MiB DDR, right? But since
 you're suggesting this should be set in configs, you are only suggesting
 +512 MiB, and any target could actually specify a lower value as long as
 it's greater than or eqal to 16 MiB. Correct?

fdt_high is only an upper bound on what we may relocate to (setting
aside the magic value of 0x which means no relocation).  I just
confirmed this too:
U-Boot# bdi
...
boot_params = 0x8100
DRAM bank   = 0x
- start= 0x8000
- size = 0x4000
...
U-Boot# setenv fdt_high 0xe000
...
U-Boot# bootz $loadaddr - $fdtaddr
Kernel image @ 0x8020 [ 0x00 - 0x3e5068 ]
## Flattened Device Tree blob at 80f8
   Booting using the fdt blob at 0x80f8
   Loading Device Tree to bf62a000, end bf630d9a ... OK

Of course, 0xbf62a000 is a bad address in that it won't be seen by the
kernel, but it was in the higher-than-we-have-memory-at limit I set.

-- 
Tom


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

[U-Boot] [RFC][PATCH 2/7] ARM: OMAP5: Rename to ti_omap5_common.h

[Enric Balletbo i Serra]

Follow the pattern ti_processor family_common.h used by other TI processors
to be coherent. So just rename omap5_common.h to ti_omap5_common.h.

Signed-off-by: Enric Balletbo i Serra eballe...@gmail.com
---
 include/configs/dra7xx_evm.h  | 4 ++--
 include/configs/omap5_uevm.h  | 4 ++--
 include/configs/{omap5_common.h = ti_omap5_common.h} | 6 +++---
 3 files changed, 7 insertions(+), 7 deletions(-)
 rename include/configs/{omap5_common.h = ti_omap5_common.h} (97%)

diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h
index 8a69c7d..fdd5f19 100644
--- a/include/configs/dra7xx_evm.h
+++ b/include/configs/dra7xx_evm.h
@@ -4,7 +4,7 @@
  * Lokesh Vutla  lokeshvu...@ti.com
  *
  * Configuration settings for the TI DRA7XX board.
- * See omap5_common.h for omap5 common settings.
+ * See ti_omap5_common.h for omap5 common settings.
  *
  * SPDX-License-Identifier:GPL-2.0+
  */
@@ -34,7 +34,7 @@
 
 #define CONFIG_SYS_OMAP_ABE_SYSCK
 
-#include configs/omap5_common.h
+#include configs/ti_omap5_common.h
 
 /* CPSW Ethernet */
 #define CONFIG_CMD_NET /* 'bootp' and 'tftp' */
diff --git a/include/configs/omap5_uevm.h b/include/configs/omap5_uevm.h
index 4d3a800..1cc4f47 100644
--- a/include/configs/omap5_uevm.h
+++ b/include/configs/omap5_uevm.h
@@ -4,7 +4,7 @@
  * Sricharan R   r.sricha...@ti.com
  *
  * Configuration settings for the TI EVM5430 board.
- * See omap5_common.h for omap5 common settings.
+ * See ti_omap5_common.h for omap5 common settings.
  *
  * SPDX-License-Identifier:GPL-2.0+
  */
@@ -17,7 +17,7 @@
uuid_disk=${uuid_gpt_disk}; \
name=rootfs,start=2MiB,size=-,uuid=${uuid_gpt_rootfs}
 
-#include configs/omap5_common.h
+#include configs/ti_omap5_common.h
 
 #define CONFIG_CONS_INDEX  3
 #define CONFIG_SYS_NS16550_COM3UART3_BASE
diff --git a/include/configs/omap5_common.h b/include/configs/ti_omap5_common.h
similarity index 97%
rename from include/configs/omap5_common.h
rename to include/configs/ti_omap5_common.h
index c7fa37e..4f34dcf 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/ti_omap5_common.h
@@ -14,8 +14,8 @@
  * http://www.ti.com/product/omap5432
  */
 
-#ifndef __CONFIG_OMAP5_COMMON_H
-#define __CONFIG_OMAP5_COMMON_H
+#ifndef __CONFIG_TI_OMAP5_COMMON_H
+#define __CONFIG_TI_OMAP5_COMMON_H
 
 #define CONFIG_OMAP54XX
 #define CONFIG_DISPLAY_CPUINFO
@@ -146,4 +146,4 @@
 #define CONFIG_SPL_DISPLAY_PRINT
 #define CONFIG_SPL_LDSCRIPT $(CPUDIR)/omap-common/u-boot-spl.lds
 
-#endif /* __CONFIG_OMAP5_COMMON_H */
+#endif /* __CONFIG_TI_OMAP5_COMMON_H */
-- 
1.8.1.2

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

[U-Boot] [RFC][PATCH 7/7] OMAP3: igep00x0: Convert to ti_omap3_common.h.

[Enric Balletbo i Serra]

To reduce code duplication update omap3_igep00x0.h to use ti_omap3_common.h.

Signed-off-by: Enric Balletbo i Serra eballe...@gmail.com
---
 include/configs/omap3_igep00x0.h | 189 ++-
 1 file changed, 9 insertions(+), 180 deletions(-)

diff --git a/include/configs/omap3_igep00x0.h b/include/configs/omap3_igep00x0.h
index 71062a6..20fbbec 100644
--- a/include/configs/omap3_igep00x0.h
+++ b/include/configs/omap3_igep00x0.h
@@ -10,20 +10,13 @@
 #ifndef __IGEP00X0_H
 #define __IGEP00X0_H
 
-#include asm/sizes.h
-
-/*
- * High Level Configuration Options
- */
-#define CONFIG_OMAP1   /* in a TI OMAP core */
-#define CONFIG_OMAP34XX1   /* which is a 34XX */
-#define CONFIG_OMAP_GPIO
-#define CONFIG_OMAP_COMMON
+#ifdef CONFIG_BOOT_NAND
+#define CONFIG_NAND
+#endif
 
-#define CONFIG_SDRC/* The chip has SDRC controller */
+#define CONFIG_NR_DRAM_BANKS2
 
-#include asm/arch/cpu.h
-#include asm/arch/omap3.h
+#include configs/ti_omap3_common.h
 #include asm/mach-types.h
 
 /*
@@ -32,47 +25,12 @@
 #define CONFIG_DISPLAY_CPUINFO 1
 #define CONFIG_DISPLAY_BOARDINFO   1
 
-/* Clock Defines */
-#define V_OSCK 2600/* Clock output from T2 */
-#define V_SCLK (V_OSCK  1)
-
 #define CONFIG_MISC_INIT_R
 
-#define CONFIG_CMDLINE_TAG 1   /* enable passing of ATAGs */
-#define CONFIG_SETUP_MEMORY_TAGS   1
-#define CONFIG_INITRD_TAG  1
 #define CONFIG_REVISION_TAG1
 
-#define CONFIG_OF_LIBFDT
-#define CONFIG_CMD_BOOTZ
 #define CONFIG_SUPPORT_RAW_INITRD
 
-/*
- * NS16550 Configuration
- */
-
-#define V_NS16550_CLK  4800/* 48MHz (APLL96/2) */
-
-#define CONFIG_SYS_NS16550
-#define CONFIG_SYS_NS16550_SERIAL
-#define CONFIG_SYS_NS16550_REG_SIZE(-4)
-#define CONFIG_SYS_NS16550_CLK V_NS16550_CLK
-
-/* select serial console configuration */
-#define CONFIG_CONS_INDEX  3
-#define CONFIG_SYS_NS16550_COM3OMAP34XX_UART3
-#define CONFIG_SERIAL3 3
-
-/* allow to overwrite serial and ethaddr */
-#define CONFIG_ENV_OVERWRITE
-#define CONFIG_BAUDRATE115200
-#define CONFIG_SYS_BAUDRATE_TABLE  {4800, 9600, 19200, 38400, 57600, \
-   115200}
-#define CONFIG_GENERIC_MMC 1
-#define CONFIG_MMC 1
-#define CONFIG_OMAP_HSMMC  1
-#define CONFIG_DOS_PARTITION   1
-
 /* define to enable boot progress via leds */
 #if (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0020) || \
 (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0030)
@@ -95,21 +53,10 @@
 #define CONFIG_USBD_MANUFACTURER   Texas Instruments
 #define CONFIG_USBD_PRODUCT_NAME   IGEP
 
-/* commands to include */
-#include config_cmd_default.h
-
 #define CONFIG_CMD_CACHE
-#define CONFIG_CMD_EXT4
-#define CONFIG_CMD_FAT /* FAT support  */
-#define CONFIG_CMD_FS_GENERIC
-#define CONFIG_CMD_I2C /* I2C serial bus support   */
-#define CONFIG_CMD_MMC /* MMC support  */
 #ifdef CONFIG_BOOT_ONENAND
 #define CONFIG_CMD_ONENAND /* ONENAND support  */
 #endif
-#ifdef CONFIG_BOOT_NAND
-#define CONFIG_CMD_NAND
-#endif
 #if (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0020) || \
 (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0032)
 #define CONFIG_CMD_NET /* bootp, tftpboot, rarpboot*/
@@ -117,24 +64,8 @@
 #define CONFIG_CMD_DHCP
 #define CONFIG_CMD_PING
 #define CONFIG_CMD_NFS /* NFS support  */
-#define CONFIG_CMD_MTDPARTS/* Enable MTD parts commands*/
-#define CONFIG_MTD_DEVICE
-
-#undef CONFIG_CMD_FLASH/* flinfo, erase, protect   */
-#undef CONFIG_CMD_IMLS /* List all found images*/
 
-#define CONFIG_SYS_NO_FLASH
-#define CONFIG_SYS_I2C
-#define CONFIG_SYS_I2C_OMAP34XX
-#define CONFIG_SYS_OMAP24_I2C_SPEED10
-#define CONFIG_SYS_OMAP24_I2C_SLAVE1
-
-/*
- * TWL4030
- */
-#define CONFIG_TWL4030_POWER   1
-
-#define CONFIG_BOOTDELAY   3
+/*#undef CONFIG_ENV_IS_NOWHERE*/
 
 #define CONFIG_EXTRA_ENV_SETTINGS \
usbtty=cdc_acm\0 \
@@ -205,48 +136,6 @@
fi; \
run nandboot; \
 
-#define CONFIG_AUTO_COMPLETE   1
-
-/*
- * Miscellaneous configurable options
- */
-#define CONFIG_SYS_LONGHELP/* undef to save memory */
-#define CONFIG_SYS_HUSH_PARSER /* use hush command parser */
-#define CONFIG_SYS_PROMPT  U-Boot # 
-#define CONFIG_SYS_CBSIZE  256 /* Console I/O Buffer Size */
-/* Print Buffer Size */
-#define CONFIG_SYS_PBSIZE  (CONFIG_SYS_CBSIZE + \
-   sizeof(CONFIG_SYS_PROMPT) + 16)
-#define CONFIG_SYS_MAXARGS 16  /* max number of command args */
-/* Boot Argument Buffer Size */
-#define CONFIG_SYS_BARGSIZE(CONFIG_SYS_CBSIZE)
-
-#define 

Re: [U-Boot] [PATCH 2/5] port wandboards to use the generic distro configs

[Wolfgang Denk]

Dear Tom,

In message 20131206162854.GX420@bill-the-cat you wrote:
 
  But this is crap. The meaning of these variables has been wel-defined
  for a long, long time.  fdt_addr is the FDT address in NOR flash (or
  similar memory except system RAM); fdt_addr_r is the FDT address
  when loaded to system RAM (hence the _r in the variable name).
 
 It's a well defined and widely ignored in ARM convention then.  We've
 got lots of 'fdt_addr' meaning RAM and no 'fdt_addr_r' and then in both
 ARM and PowerPC 'fdtaddr' being presumably RAM.

I think it's actually OK to omit the _r in NOR-less systems.  The
number of devices with actual NOT flash is decreasing, and if you can
be sure that there is no such memory device available, then it is
just overhead to always carry the _r suffice around, knowing all
the time that there will never be any other option than RAM to store
that data.

I do not complain if such systems use a simplified setup without the
_r.

What I don't like to see is to have fdt_addr_r and fdt_addr used
with a new, totally different meaning.


I don't know where the spelling fdtaddr is coming from; I would
consider it one of the many non-standard variants (assuming we agree
that there is actually something like a standard).  Note that there
is no fdtaddr_r anywhere.

 I would say that 'fdt_addr' being the system provided DT, even when not
 found on memory-mapped flash and 'fdt_addr_r' being the user provided
 one is a logical extension.

Um... you enter completely new terms here - system provided and
user provided. I cannot see how a user provided DTB in NOR flash
would fit in such a concept, nor how this would work on systems with
NOR if a system provided DTB gets loaded into RAM from a DHCP
server.

I understand that you are trying to give the old names a new
definition that would magically cover the suggested use, but this is
extremely thin ice.  I recommend not to try that.


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 important thing about being a leader is not being right or wrong,
but being *certain*.- Terry Pratchett, _Truckers_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [RFC][PATCH 3/7] TI: armv7: Move ELM support to SoC configuration file.

[Enric Balletbo i Serra]

The ELM hardware engine wihich is used for ECC error detections is not present
on OMAP3 SoC, so move the CONFIG_SPL_NAND_AM33XX_BCH from ti_armv7_common.h to
SoC configuration file.

Signed-off-by: Enric Balletbo i Serra eballe...@gmail.com
---
 include/configs/ti_am335x_common.h | 4 
 include/configs/ti_armv7_common.h  | 1 -
 include/configs/ti_omap4_common.h  | 4 
 include/configs/ti_omap5_common.h  | 4 
 4 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/include/configs/ti_am335x_common.h 
b/include/configs/ti_am335x_common.h
index 10fe47f..cb0 100644
--- a/include/configs/ti_am335x_common.h
+++ b/include/configs/ti_am335x_common.h
@@ -72,6 +72,10 @@
 #define CONFIG_SKIP_LOWLEVEL_INIT
 #endif
 
+#ifdef CONFIG_NAND
+#define CONFIG_SPL_NAND_AM33XX_BCH /* ELM support */
+#endif
+
 /* Now bring in the rest of the common code. */
 #include configs/ti_armv7_common.h
 
diff --git a/include/configs/ti_armv7_common.h 
b/include/configs/ti_armv7_common.h
index 99b60fc..f4e42ef 100644
--- a/include/configs/ti_armv7_common.h
+++ b/include/configs/ti_armv7_common.h
@@ -237,7 +237,6 @@
 #define CONFIG_SPL_BOARD_INIT
 
 #ifdef CONFIG_NAND
-#define CONFIG_SPL_NAND_AM33XX_BCH /* OMAP4 and later ELM support */
 #define CONFIG_SPL_NAND_SUPPORT
 #define CONFIG_SPL_NAND_BASE
 #define CONFIG_SPL_NAND_DRIVERS
diff --git a/include/configs/ti_omap4_common.h 
b/include/configs/ti_omap4_common.h
index bce32d6..815aaf5 100644
--- a/include/configs/ti_omap4_common.h
+++ b/include/configs/ti_omap4_common.h
@@ -154,4 +154,8 @@
 #define CONFIG_SPL_DISPLAY_PRINT
 #define CONFIG_SPL_LDSCRIPT $(CPUDIR)/omap-common/u-boot-spl.lds
 
+#ifdef CONFIG_NAND
+#define CONFIG_SPL_NAND_AM33XX_BCH /* ELM support */
+#endif
+
 #endif /* __CONFIG_TI_OMAP4_COMMON_H */
diff --git a/include/configs/ti_omap5_common.h 
b/include/configs/ti_omap5_common.h
index 4f34dcf..7b10fbd 100644
--- a/include/configs/ti_omap5_common.h
+++ b/include/configs/ti_omap5_common.h
@@ -146,4 +146,8 @@
 #define CONFIG_SPL_DISPLAY_PRINT
 #define CONFIG_SPL_LDSCRIPT $(CPUDIR)/omap-common/u-boot-spl.lds
 
+#ifdef CONFIG_NAND
+#define CONFIG_SPL_NAND_AM33XX_BCH /* ELM support */
+#endif
+
 #endif /* __CONFIG_TI_OMAP5_COMMON_H */
-- 
1.8.1.2

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

[U-Boot] [RFC][PATCH 1/7] ARM: OMAP4: Rename to ti_omap4_common.h

[Enric Balletbo i Serra]

Follow the pattern ti_processor family_common.h used by other TI processors
to be coherent. So just rename omap4_common.h to ti_omap4_common.h.

Signed-off-by: Enric Balletbo i Serra eballe...@gmail.com
---
 include/configs/omap4_panda.h | 4 ++--
 include/configs/omap4_sdp4430.h   | 4 ++--
 include/configs/{omap4_common.h = ti_omap4_common.h} | 6 +++---
 3 files changed, 7 insertions(+), 7 deletions(-)
 rename include/configs/{omap4_common.h = ti_omap4_common.h} (97%)

diff --git a/include/configs/omap4_panda.h b/include/configs/omap4_panda.h
index 6820e42..2a8ff5d 100644
--- a/include/configs/omap4_panda.h
+++ b/include/configs/omap4_panda.h
@@ -4,7 +4,7 @@
  * Steve Sakoman  st...@sakoman.com
  *
  * Configuration settings for the TI OMAP4 Panda board.
- * See omap4_common.h for OMAP4 common part
+ * See ti_omap4_common.h for OMAP4 common part
  *
  * SPDX-License-Identifier:GPL-2.0+
  */
@@ -39,7 +39,7 @@
 #define CONFIG_USB_ULPI
 #define CONFIG_USB_ULPI_VIEWPORT_OMAP
 
-#include configs/omap4_common.h
+#include configs/ti_omap4_common.h
 #define CONFIG_CMD_NET
 
 /* GPIO */
diff --git a/include/configs/omap4_sdp4430.h b/include/configs/omap4_sdp4430.h
index b352511..a837974 100644
--- a/include/configs/omap4_sdp4430.h
+++ b/include/configs/omap4_sdp4430.h
@@ -5,7 +5,7 @@
  * Steve Sakoman  st...@sakoman.com
  *
  * Configuration settings for the TI SDP4430 board.
- * See omap4_common.h for OMAP4 common part
+ * See ti_omap4_common.h for OMAP4 common part
  *
  * SPDX-License-Identifier:GPL-2.0+
  */
@@ -19,7 +19,7 @@
 #define CONFIG_4430SDP 1   /* working with SDP */
 #define CONFIG_MACH_TYPE   MACH_TYPE_OMAP_4430SDP
 
-#include configs/omap4_common.h
+#include configs/ti_omap4_common.h
 
 /* Battery Charger */
 #ifndef CONFIG_SPL_BUILD
diff --git a/include/configs/omap4_common.h b/include/configs/ti_omap4_common.h
similarity index 97%
rename from include/configs/omap4_common.h
rename to include/configs/ti_omap4_common.h
index ea56eeb..bce32d6 100644
--- a/include/configs/omap4_common.h
+++ b/include/configs/ti_omap4_common.h
@@ -9,8 +9,8 @@
  * SPDX-License-Identifier:GPL-2.0+
  */
 
-#ifndef __CONFIG_OMAP4_COMMON_H
-#define __CONFIG_OMAP4_COMMON_H
+#ifndef __CONFIG_TI_OMAP4_COMMON_H
+#define __CONFIG_TI_OMAP4_COMMON_H
 
 /*
  * High Level Configuration Options
@@ -154,4 +154,4 @@
 #define CONFIG_SPL_DISPLAY_PRINT
 #define CONFIG_SPL_LDSCRIPT $(CPUDIR)/omap-common/u-boot-spl.lds
 
-#endif /* __CONFIG_OMAP4_COMMON_H */
+#endif /* __CONFIG_TI_OMAP4_COMMON_H */
-- 
1.8.1.2

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

[U-Boot] [RFC][PATCH 0/7] TI: OMAP3: Use common config file.

[Enric Balletbo i Serra]

Hi all,

Most of the boards based on TI processors uses common configuration files
(ti_armv7_common.h, ti_processor_common.h) to avoid duplication of code.
This is right except for OMAP3-based boards. In order to use the same schema
as used on am33xx, omap4, omap5 and dra7 TI processors these patches create
a new ti_omap3_common.h (that include ti_armv7_common.h) with the purpose that
all OMAP3 board can use it.

Patches 1 and 2 just renames current omap4|omap5_common.h to
ti_omap4|omap5_common.h to be coherent with current ti_am33xx_common.h,
ti_armv7_common.h and the new ti_omap3_common.h. It's just a cosmetic change so
if people don't like it I don't have any inconvenient to remove from these
series.

Patches 3 and 4 modifies the ti_armv7_common.h to be more compatible with OMAP3
boards. For example, patch 3 removes the assumption that all ti_armv7 have an
ELM hardware engine and patch 4 handles the case that the number of DRAM banks
is defined at board level. The patch 5 is also required to integrate the use
of ti_armv7_common.h on OMAP3 boards.

Patch 6 creates the new ti_omap3_common.h to be used for any OMAP3-based board.

And finally, patch 7 moves the IGEP boards to use the new common file. As I
only have IGEP hardware to test these patches I decided only implement the use
case for these boards. I don't have any inconvenient to move other OMAP3 boards
to use this schema but I prefer leave the decision to the board maintainers.

Any comments, improvements, fixes are welcome.

Best regards,

Enric Balletbo i Serra (7):
  ARM: OMAP4: Rename to ti_omap4_common.h
  ARM: OMAP5: Rename to ti_omap5_common.h
  TI: armv7: Move ELM support to SoC configuration file.
  TI: armv7: Do not define the number DRAM banks if is already defined.
  ARM: OMAP3: Rename OMAP3_PUBLIC_SRAM_* to NON_SECURE_SRAM_*
  TI: OMAP3: Create common config files for TI OMAP3 platforms.
  OMAP3: igep00x0: Convert to ti_omap3_common.h.

 arch/arm/include/asm/arch-omap3/omap3.h|   6 +-
 include/configs/dra7xx_evm.h   |   4 +-
 include/configs/omap3_igep00x0.h   | 190 +
 include/configs/omap4_panda.h  |   4 +-
 include/configs/omap4_sdp4430.h|   4 +-
 include/configs/omap5_uevm.h   |   4 +-
 include/configs/ti_am335x_common.h |   4 +
 include/configs/ti_armv7_common.h  |  11 +-
 include/configs/ti_omap3_common.h  |  73 
 .../configs/{omap4_common.h = ti_omap4_common.h}  |  10 +-
 .../configs/{omap5_common.h = ti_omap5_common.h}  |  10 +-
 11 files changed, 118 insertions(+), 202 deletions(-)
 create mode 100644 include/configs/ti_omap3_common.h
 rename include/configs/{omap4_common.h = ti_omap4_common.h} (95%)
 rename include/configs/{omap5_common.h = ti_omap5_common.h} (95%)

-- 
1.8.1.2

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

[U-Boot] [RFC][PATCH 6/7] TI: OMAP3: Create common config files for TI OMAP3 platforms.

[Enric Balletbo i Serra]

Create a new file, include/configs/ti_omap3_common.h, for everything
common to the OMAP3 SoC leaving just the board specific part to board
configuration file.

Signed-off-by: Enric Balletbo i Serra eballe...@gmail.com
---
 include/configs/ti_omap3_common.h | 73 +++
 1 file changed, 73 insertions(+)
 create mode 100644 include/configs/ti_omap3_common.h

diff --git a/include/configs/ti_omap3_common.h 
b/include/configs/ti_omap3_common.h
new file mode 100644
index 000..854cb78
--- /dev/null
+++ b/include/configs/ti_omap3_common.h
@@ -0,0 +1,73 @@
+/*
+ * ti_omap3_common.h
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ *
+ * For more details, please see the technical documents listed at
+ *   http://www.ti.com/product/omap3530
+ *   http://www.ti.com/product/omap3630
+ *   http://www.ti.com/product/dm3730
+ */
+
+#ifndef __CONFIG_TI_OMAP3_COMMON_H__
+#define __CONFIG_TI_OMAP3_COMMON_H__
+
+#define CONFIG_OMAP34XX
+
+#include asm/arch/cpu.h
+#include asm/arch/omap3.h
+
+/* The chip has SDRC controller */
+#define CONFIG_SDRC
+
+/* Clock Defines */
+#define V_OSCK 2600/* Clock output from T2 */
+#define V_SCLK (V_OSCK  1)
+
+/* NS16550 Configuration */
+#define V_NS16550_CLK  4800/* 48MHz (APLL96/2) */
+#define CONFIG_SYS_NS16550
+#define CONFIG_SYS_NS16550_SERIAL
+#define CONFIG_SYS_NS16550_REG_SIZE(-4)
+#define CONFIG_SYS_NS16550_CLK V_NS16550_CLK
+#define CONFIG_SYS_BAUDRATE_TABLE  {4800, 9600, 19200, 38400, 57600, \
+   115200}
+
+/* Select serial console configuration */
+#define CONFIG_CONS_INDEX  3
+#define CONFIG_SYS_NS16550_COM3OMAP34XX_UART3
+#define CONFIG_SERIAL3 3
+
+/* Physical Memory Map */
+#define PHYS_SDRAM_1   OMAP34XX_SDRC_CS0
+#define PHYS_SDRAM_2   OMAP34XX_SDRC_CS1
+
+/*
+ * OMAP3 has 12 GP timers, they can be driven by the system clock
+ * (12/13/16.8/19.2/38.4MHz) or by 32KHz clock. We use 13MHz (V_SCLK).
+ * This rate is divided by a local divisor.
+ */
+#define CONFIG_SYS_TIMERBASE   (OMAP34XX_GPT2)
+
+#define CONFIG_SYS_MONITOR_LEN (256  10)
+
+/* TWL4030 */
+#define CONFIG_TWL4030_POWER   1
+
+/* SPL */
+#define CONFIG_SPL_TEXT_BASE   0x40200800
+#define CONFIG_SPL_MAX_SIZE(54 * 1024)
+#define CONFIG_SPL_LDSCRIPT$(CPUDIR)/omap-common/u-boot-spl.lds
+#define CONFIG_SPL_POWER_SUPPORT
+
+#ifdef CONFIG_NAND
+#define CONFIG_SPL_NAND_SUPPORT
+#define CONFIG_SPL_NAND_SIMPLE
+#endif
+
+/* Now bring in the rest of the common code. */
+#include configs/ti_armv7_common.h
+
+#endif /* __CONFIG_TI_OMAP3_COMMON_H__ */
-- 
1.8.1.2

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

[U-Boot] [RFC][PATCH 5/7] ARM: OMAP3: Rename OMAP3_PUBLIC_SRAM_* to NON_SECURE_SRAM_*

[Enric Balletbo i Serra]

Other TI processors like am33xx, omap4 and omap5 have called these variables
as NON_SECURE_SRAM_*, shouldn't be a big problem rename these variables to
be coherent.

One reason more to rename these variables is to have the possibility of any
OMAP3 board to use the ti_armv7_common.h include as the NON_SECURE_SRAM_END
is used to define the CONFIG_SYS_INIT_SP_ADDR variable.

Signed-off-by: Enric Balletbo i Serra eballe...@gmail.com
---
 arch/arm/include/asm/arch-omap3/omap3.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/include/asm/arch-omap3/omap3.h 
b/arch/arm/include/asm/arch-omap3/omap3.h
index 7fb549a..d5f3dd3 100644
--- a/arch/arm/include/asm/arch-omap3/omap3.h
+++ b/arch/arm/include/asm/arch-omap3/omap3.h
@@ -139,13 +139,13 @@ struct gpio {
 SRAM_OFFSET2)
 #define SRAM_CLK_CODE  (SRAM_VECT_CODE + 64)
 
-#define OMAP3_PUBLIC_SRAM_BASE 0x40208000 /* Works for GP  EMU */
-#define OMAP3_PUBLIC_SRAM_END  0x4021
+#define NON_SECURE_SRAM_START  0x40208000 /* Works for GP  EMU */
+#define NON_SECURE_SRAM_END0x4021
 
 #define LOW_LEVEL_SRAM_STACK   0x4020FFFC
 
 /* scratch area - accessible on both EMU and GP */
-#define OMAP3_PUBLIC_SRAM_SCRATCH_AREA OMAP3_PUBLIC_SRAM_BASE
+#define OMAP3_PUBLIC_SRAM_SCRATCH_AREA NON_SECURE_SRAM_START
 
 #define DEBUG_LED1 149 /* gpio */
 #define DEBUG_LED2 150 /* gpio */
-- 
1.8.1.2

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

[U-Boot] [RFC][PATCH 4/7] TI: armv7: Do not define the number DRAM banks if is already defined.

[Enric Balletbo i Serra]

If CONFIG_NR_DRAM_BANKS is not defined, we say (for simplicity) that we have
1 bank, but for some boards should be interesting that we can define
CONFIG_NR_DRAM_BANKS. To handle this possibility just define the number of
DRAM banks if is not already defined. This is useful for some OMAP3 boards
where the DRAM initialitzation is only at u-boot level.

Signed-off-by: Enric Balletbo i Serra eballe...@gmail.com
---
 include/configs/ti_armv7_common.h | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/include/configs/ti_armv7_common.h 
b/include/configs/ti_armv7_common.h
index f4e42ef..69d69a5 100644
--- a/include/configs/ti_armv7_common.h
+++ b/include/configs/ti_armv7_common.h
@@ -45,11 +45,15 @@
 #define CONFIG_BOOTDELAY   1
 
 /*
- * DDR information.  We say (for simplicity) that we have 1 bank,
- * always, even when we have more.  We always start at 0x8000,
- * and we place the initial stack pointer in our SRAM.
+ * DDR information.  If the CONFIG_NR_DRAM_BANKS is not defined,
+ * we say (for simplicity) that we have 1 bank, always, even when
+ * we have more.  We always start at 0x8000, and we place the
+ * initial stack pointer in our SRAM. Otherwise, we can define
+ * CONFIG_NR_DRAM_BANKS before including this file.
  */
+#ifndef CONFIG_NR_DRAM_BANKS
 #define CONFIG_NR_DRAM_BANKS   1
+#endif
 #define CONFIG_SYS_SDRAM_BASE  0x8000
 #define CONFIG_SYS_INIT_SP_ADDR (NON_SECURE_SRAM_END - \
GENERATED_GBL_DATA_SIZE)
-- 
1.8.1.2

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

Re: [U-Boot] [RFC] ARM: Start using fdt_high for relocation

[Stephen Warren]

On 12/06/2013 01:31 PM, Tom Rini wrote:
 On Fri, Dec 06, 2013 at 08:28:04PM +0100, Albert ARIBAUD wrote:
 Hi Tom,

 On Fri, 6 Dec 2013 12:18:13 -0500, Tom Rini tr...@ti.com wrote:

 On Fri, Dec 06, 2013 at 05:59:37PM +0100, Albert ARIBAUD wrote:
 Hi Tom,

 On Fri, 6 Dec 2013 10:48:50 -0500, Tom Rini tr...@ti.com wrote:

 Hey all,

 I've been thinking.  We've had a thread on i.MX platforms about fdt
 being overwritten and needing to be moved to another address.  And I've
 also had an internal problem about fdt being overwritten.  So, how about
 as a rule of thumb we start setting fdt_high (in configs) to
 memory-start + 512MiB, as that's the lowmem limit we should always have
 available.  This will fix the problem of BSS overwriting the DT, which
 is the problem we won't catch in normal bootm/bootz usage.  Thoughts?

 Not sure I'm getting the issue clear, and I would like to avoid (me and
 others) having to switch back and forth between threads. Can you sketch
 the failure scenario in a couple of lines?

 Sure.  Lets take am335x_evm builds (so Beaglebone Black/White, etc).
 If you start enabling all of the tracing options in the kernel (function
 tracing, graphs, etc), you get an uncompressed kernel and BSS that will
 use up the first ~16MiB of DDR.  We default to placing the DT at about
 15MiB into memory.  So the kernel runs, clears BSS and eats the DT.
 System now hangs, and depending on debug options set you may or may not
 see anything at all from the kernel.  U-Boot couldn't detect this
 failure because we don't know how big the kernel BSS is, only how big
 the zImage is (and where it is) and how big the fdt is and where it is.
 No overlaps, go ahead and run.

 Thanks.

 The only issue I have with the RFC is that the +512 MiB value will only
 work with targets which have more than 512 MiB DDR, right? But since
 you're suggesting this should be set in configs, you are only suggesting
 +512 MiB, and any target could actually specify a lower value as long as
 it's greater than or eqal to 16 MiB. Correct?
 
 fdt_high is only an upper bound on what we may relocate to (setting
 aside the magic value of 0x which means no relocation).  I just
 confirmed this too:
 U-Boot# bdi
 ...
 boot_params = 0x8100
 DRAM bank   = 0x
 - start= 0x8000
 - size = 0x4000
 ...
 U-Boot# setenv fdt_high 0xe000
 ...
 U-Boot# bootz $loadaddr - $fdtaddr
 Kernel image @ 0x8020 [ 0x00 - 0x3e5068 ]
 ## Flattened Device Tree blob at 80f8
Booting using the fdt blob at 0x80f8
Loading Device Tree to bf62a000, end bf630d9a ... OK
 
 Of course, 0xbf62a000 is a bad address in that it won't be seen by the
 kernel, but it was in the higher-than-we-have-memory-at limit I set.

I haven't really followed this thread since I just noticed it
tangentially, but on Tegra...

Since commit 7f1b767aea94 ARM: tegra: define CONFIG_SYS_BOOTMAPSZ
all Tegra boards define BOOTMAPSZ to influence where the DTB gets
relocated. I wonder what's the benefit of using BOOTMAPSZ vs. defining
a default value for $fdt_high?

And couldn't you just move $fdt_addr_r high enough in RAM so even if
the DTB wasn't relocated it'd never overlap BSS? Tegra's
$kernel_addr_r and $fdt_addr_r are likely set up that way already,
although I didn't check.


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

Re: [U-Boot] [RFC] ARM: Start using fdt_high for relocation

[Tom Rini]

On Fri, Dec 06, 2013 at 01:44:22PM -0700, Stephen Warren wrote:
 On 12/06/2013 01:31 PM, Tom Rini wrote:
  On Fri, Dec 06, 2013 at 08:28:04PM +0100, Albert ARIBAUD wrote:
  Hi Tom,
 
  On Fri, 6 Dec 2013 12:18:13 -0500, Tom Rini tr...@ti.com wrote:
 
  On Fri, Dec 06, 2013 at 05:59:37PM +0100, Albert ARIBAUD wrote:
  Hi Tom,
 
  On Fri, 6 Dec 2013 10:48:50 -0500, Tom Rini tr...@ti.com wrote:
 
  Hey all,
 
  I've been thinking.  We've had a thread on i.MX platforms about fdt
  being overwritten and needing to be moved to another address.  And I've
  also had an internal problem about fdt being overwritten.  So, how about
  as a rule of thumb we start setting fdt_high (in configs) to
  memory-start + 512MiB, as that's the lowmem limit we should always have
  available.  This will fix the problem of BSS overwriting the DT, which
  is the problem we won't catch in normal bootm/bootz usage.  Thoughts?
 
  Not sure I'm getting the issue clear, and I would like to avoid (me and
  others) having to switch back and forth between threads. Can you sketch
  the failure scenario in a couple of lines?
 
  Sure.  Lets take am335x_evm builds (so Beaglebone Black/White, etc).
  If you start enabling all of the tracing options in the kernel (function
  tracing, graphs, etc), you get an uncompressed kernel and BSS that will
  use up the first ~16MiB of DDR.  We default to placing the DT at about
  15MiB into memory.  So the kernel runs, clears BSS and eats the DT.
  System now hangs, and depending on debug options set you may or may not
  see anything at all from the kernel.  U-Boot couldn't detect this
  failure because we don't know how big the kernel BSS is, only how big
  the zImage is (and where it is) and how big the fdt is and where it is.
  No overlaps, go ahead and run.
 
  Thanks.
 
  The only issue I have with the RFC is that the +512 MiB value will only
  work with targets which have more than 512 MiB DDR, right? But since
  you're suggesting this should be set in configs, you are only suggesting
  +512 MiB, and any target could actually specify a lower value as long as
  it's greater than or eqal to 16 MiB. Correct?
  
  fdt_high is only an upper bound on what we may relocate to (setting
  aside the magic value of 0x which means no relocation).  I just
  confirmed this too:
  U-Boot# bdi
  ...
  boot_params = 0x8100
  DRAM bank   = 0x
  - start= 0x8000
  - size = 0x4000
  ...
  U-Boot# setenv fdt_high 0xe000
  ...
  U-Boot# bootz $loadaddr - $fdtaddr
  Kernel image @ 0x8020 [ 0x00 - 0x3e5068 ]
  ## Flattened Device Tree blob at 80f8
 Booting using the fdt blob at 0x80f8
 Loading Device Tree to bf62a000, end bf630d9a ... OK
  
  Of course, 0xbf62a000 is a bad address in that it won't be seen by the
  kernel, but it was in the higher-than-we-have-memory-at limit I set.
 
 I haven't really followed this thread since I just noticed it
 tangentially, but on Tegra...
 
 Since commit 7f1b767aea94 ARM: tegra: define CONFIG_SYS_BOOTMAPSZ
 all Tegra boards define BOOTMAPSZ to influence where the DTB gets
 relocated. I wonder what's the benefit of using BOOTMAPSZ vs. defining
 a default value for $fdt_high?

I believe they both get the same thing done but SYS_BOOTMAPSZ also
influences relocation of ramdisks (and in these cases we disable ramdisk
relocation with initrd_high=0x).

 And couldn't you just move $fdt_addr_r high enough in RAM so even if
 the DTB wasn't relocated it'd never overlap BSS? Tegra's
 $kernel_addr_r and $fdt_addr_r are likely set up that way already,
 although I didn't check.

There's two problems here.  The first problem is that we have between
256MiB and 1GiB of DDR on the platform, but we could just design for the
smallest case.  The second problem is, what's big enough?  You've got
32MiB (tegra30) which I would hope is enough (and I suggested as much in
Dennis' thread) for kernel + BSS, but how big is a multi platform kernel
with a few big features going to get?  Or do we say that's an
unreasonable out of box use case?

-- 
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] ARM: align MVBAR on 32 byte boundary

[Albert ARIBAUD]

Hi Masahiro,

On Mon,  7 Oct 2013 11:46:56 +0900, Masahiro Yamada
yamad...@jp.panasonic.com wrote:

 The lower 5 bit of MVBAR is UNK/SBZP.
 So, Monitor Vector Base Address must be 32-byte aligned.
 On the other hand, the secure monitor handler does not need
 32-byte alignment.
 
 This commit moves .algin 5 directive to the correct place.
 
 Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
 Cc: Andre Przywara andre.przyw...@linaro.org
 ---
 
 BTW, I noticed the legacy license block is used in this file.
 
 Because arch/arm/cpu/armv7/nonsec_virt.S is a newly added file,
 SPDX License Identifier should have been used...
 
 
  arch/arm/cpu/armv7/nonsec_virt.S | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/arch/arm/cpu/armv7/nonsec_virt.S 
 b/arch/arm/cpu/armv7/nonsec_virt.S
 index 358348f..ee36760 100644
 --- a/arch/arm/cpu/armv7/nonsec_virt.S
 +++ b/arch/arm/cpu/armv7/nonsec_virt.S
 @@ -30,6 +30,7 @@
  .arch_extension sec
  .arch_extension virt
  
 + .align  5
  /* the vector table for secure state and HYP mode */
  _monitor_vectors:
   .word 0 /* reset */
 @@ -48,7 +49,6 @@ _monitor_vectors:
   * to non-secure state.
   * We use only r0 and r1 here, due to constraints in the caller.
   */
 - .align  5
  _secure_monitor:
   mrc p15, 0, r1, c1, c1, 0   @ read SCR
   bic r1, r1, #0x4e   @ clear IRQ, FIQ, EA, nET bits

Applied to u-boot-arm/master, thanks!

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

Re: [U-Boot] [PATCH 2/5] port wandboards to use the generic distro configs

[Tom Rini]

On Fri, Dec 06, 2013 at 09:37:59PM +0100, Wolfgang Denk wrote:
 Dear Tom,
 
 In message 20131206162854.GX420@bill-the-cat you wrote:
  
   But this is crap. The meaning of these variables has been wel-defined
   for a long, long time.  fdt_addr is the FDT address in NOR flash (or
   similar memory except system RAM); fdt_addr_r is the FDT address
   when loaded to system RAM (hence the _r in the variable name).
  
  It's a well defined and widely ignored in ARM convention then.  We've
  got lots of 'fdt_addr' meaning RAM and no 'fdt_addr_r' and then in both
  ARM and PowerPC 'fdtaddr' being presumably RAM.
 
 I think it's actually OK to omit the _r in NOR-less systems.  The
 number of devices with actual NOT flash is decreasing, and if you can
 be sure that there is no such memory device available, then it is
 just overhead to always carry the _r suffice around, knowing all
 the time that there will never be any other option than RAM to store
 that data.

Right.  So the rule is fdt_addr means the [shipped] DT in NOR, if
present.  fdt_addr_r means the [shipped] DT in system RAM.

 I do not complain if such systems use a simplified setup without the
 _r.
 
 What I don't like to see is to have fdt_addr_r and fdt_addr used
 with a new, totally different meaning.

Well, fdt_addr still means the shipped DT and fdt_addr_r still means
a DT loaded into system RAM.  The only change is that fdt_addr may also
be a system RAM address.

 I don't know where the spelling fdtaddr is coming from; I would
 consider it one of the many non-standard variants (assuming we agree
 that there is actually something like a standard).  Note that there
 is no fdtaddr_r anywhere.

fdtaddr comes from somewhere along the line someone not going Hey,
you forgot a _ in your env since it means what fdt_addr_r means or
fdt_addr means when you lack NOR/similar flash for a DT.

  I would say that 'fdt_addr' being the system provided DT, even when not
  found on memory-mapped flash and 'fdt_addr_r' being the user provided
  one is a logical extension.
 
 Um... you enter completely new terms here - system provided and
 user provided. I cannot see how a user provided DTB in NOR flash
 would fit in such a concept, nor how this would work on systems with
 NOR if a system provided DTB gets loaded into RAM from a DHCP
 server.

system provided or shipped or what have you for the vendor provided
DT, which previously would have been in NOR, for fdt_addr when you also
have fdt_addr_r.  And I believe the answer to the second question is
that yes, the shipped or system provided DTB would end up in fdt_addr,
so long as whatever grab the provided default DT puts it there.

 I understand that you are trying to give the old names a new
 definition that would magically cover the suggested use, but this is
 extremely thin ice.  I recommend not to try that.

Well, lets see if we can't convince you around.  Or get some better
names to use for these use cases.

-- 
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/5] port wandboards to use the generic distro configs

[Dennis Gilmore]

Hi Wolfgang,

El Fri, 06 Dec 2013 21:37:59 +0100
Wolfgang Denk w...@denx.de escribió:
 Dear Tom,
 
 In message 20131206162854.GX420@bill-the-cat you wrote:
  
   But this is crap. The meaning of these variables has been
   wel-defined for a long, long time.  fdt_addr is the FDT address
   in NOR flash (or similar memory except system RAM); fdt_addr_r
   is the FDT address when loaded to system RAM (hence the _r in
   the variable name).
  
  It's a well defined and widely ignored in ARM convention then.
  We've got lots of 'fdt_addr' meaning RAM and no 'fdt_addr_r' and
  then in both ARM and PowerPC 'fdtaddr' being presumably RAM.
 
 I think it's actually OK to omit the _r in NOR-less systems.  The
 number of devices with actual NOT flash is decreasing, and if you can
 be sure that there is no such memory device available, then it is
 just overhead to always carry the _r suffice around, knowing all
 the time that there will never be any other option than RAM to store
 that data.
 
 I do not complain if such systems use a simplified setup without the
 _r.
 
 What I don't like to see is to have fdt_addr_r and fdt_addr used
 with a new, totally different meaning.
 
 
 I don't know where the spelling fdtaddr is coming from; I would
 consider it one of the many non-standard variants (assuming we agree
 that there is actually something like a standard).  Note that there
 is no fdtaddr_r anywhere.
fdtaddr is highly prevalent in the configs

grep -r fdtaddr include/configs/|wc -l
390

more so than fdt_addr 

grep -r fdt_addr include/configs/|wc -l
278

those counts are in my git tree with the proposed patches applied
that converted soem systems from fdtaddr to fdt_addr. One of the
problems right or wrong is that u-boot is seen as not having any kind of
standard, which is what I am trying to fix, at least for use in the
generic distro world where we need to have an standardised
documented interface.

  I would say that 'fdt_addr' being the system provided DT, even when
  not found on memory-mapped flash and 'fdt_addr_r' being the user
  provided one is a logical extension.
 
 Um... you enter completely new terms here - system provided and
 user provided. I cannot see how a user provided DTB in NOR flash
 would fit in such a concept, nor how this would work on systems with
 NOR if a system provided DTB gets loaded into RAM from a DHCP
 server.
 
 I understand that you are trying to give the old names a new
 definition that would magically cover the suggested use, but this is
 extremely thin ice.  I recommend not to try that.

greping through the doc directory of git I am unable to find any
reference to this convention you speak of. 

The only references i found was in README.falcon README.pxe and
README.commands.spl based on your description it would mean falcon mode
could not be implemented on any system not having nand.


cmd_pxe.c clearly specifies what it thinks the addresses are for

 fdt_addr_r - location in RAM at which 'pxe boot' will store the
 fdt blob it retrieves from tftp. The retrieval is possible if
 'fdt' label is defined in pxe file and 'fdt_addr_r' is set. If
 retrieval is possible, 'fdt_addr_r' will be passed to bootm
 command to boot the kernel.

 fdt_addr - the location of a fdt blob. 'fdt_addr' will be passed
 to bootm command if it is set and 'fdt_addr_r' is not passed to 
 bootm command.

Which i read as fdt_addr is a system provided dtb, and fdt_addr_r is a
user provided one. there is no mention of where exactly they come from.

when pxe booting or installing on an arm system we do not want to put a
fdt line in the config file, because we do not want to have to have
the knowledge in the installer to work out what dtb file we want. that
really is a job for u-boot to provide, but we do have the option to if
its needed for some reason.

I was purely working with what is in front of me.

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

Re: [U-Boot] [PATCH 2/5] port wandboards to use the generic distro configs

[Wolfgang Denk]

Dear Tom,

In message 20131206221307.GD420@bill-the-cat you wrote:
 
  I think it's actually OK to omit the _r in NOR-less systems.  The
  number of devices with actual NOT flash is decreasing, and if you can
  be sure that there is no such memory device available, then it is
  just overhead to always carry the _r suffice around, knowing all
  the time that there will never be any other option than RAM to store
  that data.
 
 Right.  So the rule is fdt_addr means the [shipped] DT in NOR, if
 present.  fdt_addr_r means the [shipped] DT in system RAM.

No.  NAK.  Delete this [shipped] stuff here.  This is some new
interpretation which you are trying to sneak in here, but there has
never been any such notion before.  It's just an address, and we don't
care where the actual data came from or who put it there.

 Well, fdt_addr still means the shipped DT and fdt_addr_r still means
 a DT loaded into system RAM.  The only change is that fdt_addr may also
 be a system RAM address.

Stop.  There is no such thing as a shipped DT.

  Um... you enter completely new terms here - system provided and
  user provided. I cannot see how a user provided DTB in NOR flash
  would fit in such a concept, nor how this would work on systems with
  NOR if a system provided DTB gets loaded into RAM from a DHCP
  server.

 system provided or shipped or what have you for the vendor provided
 DT, which previously would have been in NOR, for fdt_addr when you also

NAK.  We have never been using any such terms before.  You are trying
to insert completely new meaning here, and I do not agree with such
interpretation.  A DT is a DT is a DT, no matter who provided it or
where it is coming from or who installed it where.

 Well, lets see if we can't convince you around.  Or get some better
 names to use for these use cases.

No chance.  This is the first time ever such terms come up, and we've
been using DTs for a long, long time before.

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 use of COBOL cripples the mind; its teaching  should,  therefore,
be regarded as a criminal offense.   - E. W. Dijkstra
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC] ARM: Start using fdt_high for relocation

[Stephen Warren]

On 12/06/2013 02:04 PM, Tom Rini wrote:
...
 There's two problems here.  The first problem is that we have
 between 256MiB and 1GiB of DDR on the platform, but we could just
 design for the smallest case.  The second problem is, what's big
 enough?  You've got 32MiB (tegra30) which I would hope is enough
 (and I suggested as much in Dennis' thread) for kernel + BSS, but
 how big is a multi platform kernel with a few big features going to
 get?  Or do we say that's an unreasonable out of box use case?

Is there any limit on .data/.bss size like there is .text (due to the
limited range of relative jump encoding), or would data accesses just
fall back to a relative load of the absolute address, and hence be
unbounded.

FWIW, I see the following sizes currently:

tegra_defconfig

.text   005862c4
.data   0005eb68
.bss00055bf0

multi_v7_defconfig

.text   004a5560
.data   00092600
.bss00046014

(I think multi_v7_defconfig doesn't yet have that many drivers
enabled, and when it does presumably they'd be modules)

... so BSS isn't terribly large at the moment.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/5] port wandboards to use the generic distro configs

[Wolfgang Denk]

Dear Dennis,

In message 20131206164420.36e5f...@adria.ausil.us you wrote:
 
 fdtaddr is highly prevalent in the configs

Yes, it appears some vendors favoured this name.  I'm temptted to add
that these very vendors often tend to define thier own ways without
caring what the community has been using before ;-)

That doesn't make it any better, though...

 those counts are in my git tree with the proposed patches applied
 that converted soem systems from fdtaddr to fdt_addr. One of the
 problems right or wrong is that u-boot is seen as not having any kind of
 standard, which is what I am trying to fix, at least for use in the
 generic distro world where we need to have an standardised
 documented interface.

Even if you feel differntly, I do appreciate your efforts.  But I'd
also like to see things done in a consistent way.  And the whole idea
of using the _r names was to show clearly which of the addresses are
supposed to be in system RAM (with _r), and which are not (without).

This parallels function names like board_init_f() [_f standing for
running from [NOR] flash] and board_init_r() [_r = running from
system RAM].

 greping through the doc directory of git I am unable to find any
 reference to this convention you speak of. 

Agreed. Noone wrote a document about this, yet.

 The only references i found was in README.falcon README.pxe and
 README.commands.spl based on your description it would mean falcon mode
 could not be implemented on any system not having nand.

I lost you here.  What makes you think so?

 cmd_pxe.c clearly specifies what it thinks the addresses are for

Yes, it does.  But this is confused or incorrect, misusing existing
names for other purposes.  This should be fixed.

 Which i read as fdt_addr is a system provided dtb, and fdt_addr_r is a
 user provided one. there is no mention of where exactly they come from.

Stop.  There has never been any such notion like system provided or
user provided before.  You cannot just put new meanings over
existing terms.  Actually, to me such terms don't even make much
sense.

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
My play was a complete success.  The audience was a failure.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] bootm: Reinstate special case for standalone images

[Simon Glass]

For standalone images, bootm had a special case where the OS boot function
was NULL but did actually exist. It was just called manually.

This was removed by commit 35fc84fa which checks for the non-existence of
this function before the special case is examined.

There is no obvious reason why standalone is handled with a special case.
Adjust the code so that standalone has a normal OS boot function. We still
need a special case for when the function returns, but at least we can
avoid the main problem.

This is intended to fix the reported:

ERROR: booting os 'U-Boot' (17) is not supported

but needs testing.

Signed-off-by: Simon Glass s...@chromium.org
---

 common/cmd_bootm.c | 21 -
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index ba73f57..2120aa0 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -77,6 +77,9 @@ static int do_imls(cmd_tbl_t *cmdtp, int flag, int argc, char 
* const argv[]);
 static void fixup_silent_linux(void);
 #endif
 
+static int do_bootm_standalone(int flag, int argc, char * const argv[],
+  bootm_headers_t *images);
+
 static const void *boot_get_kernel(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[], bootm_headers_t *images,
ulong *os_data, ulong *os_len);
@@ -131,6 +134,7 @@ static boot_os_fn do_bootm_integrity;
 #endif
 
 static boot_os_fn *boot_os[] = {
+   [IH_TYPE_STANDALONE] = do_bootm_standalone,
 #ifdef CONFIG_BOOTM_LINUX
[IH_OS_LINUX] = do_bootm_linux,
 #endif
@@ -487,17 +491,18 @@ static int bootm_load_os(bootm_headers_t *images, 
unsigned long *load_end,
return 0;
 }
 
-static int bootm_start_standalone(int argc, char * const argv[])
+static int do_bootm_standalone(int flag, int argc, char * const argv[],
+  bootm_headers_t *images)
 {
char  *s;
int   (*appl)(int, char * const []);
 
/* Don't start if autostart is set to no */
if (((s = getenv(autostart)) != NULL)  (strcmp(s, no) == 0)) {
-   setenv_hex(filesize, images.os.image_len);
+   setenv_hex(filesize, images-os.image_len);
return 0;
}
-   appl = (int (*)(int, char * const []))(ulong)ntohl(images.ep);
+   appl = (int (*)(int, char * const []))(ulong)ntohl(images-ep);
(*appl)(argc, argv);
return 0;
 }
@@ -523,14 +528,12 @@ static cmd_tbl_t cmd_bootm_sub[] = {
 static int boot_selected_os(int argc, char * const argv[], int state,
bootm_headers_t *images, boot_os_fn *boot_fn)
 {
-   if (images-os.type == IH_TYPE_STANDALONE) {
-   /* This may return when 'autostart' is 'no' */
-   bootm_start_standalone(argc, argv);
-   return 0;
-   }
arch_preboot_os();
boot_fn(state, argc, argv, images);
-   if (state == BOOTM_STATE_OS_FAKE_GO) /* We expect to return */
+
+   /* Stand-alone may return when 'autostart' is 'no' */
+   if (images-os.type == IH_TYPE_STANDALONE ||
+   state == BOOTM_STATE_OS_FAKE_GO) /* We expect to return */
return 0;
bootstage_error(BOOTSTAGE_ID_BOOT_OS_RETURNED);
 #ifdef DEBUG
-- 
1.8.5.1

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

Re: [U-Boot] [PATCH 0/8] Secure boot improvements and test on Beaglebone Black

[Simon Glass]

Hi Tom,

On 2 October 2013 08:44, Simon Glass s...@chromium.org wrote:
 This series adds a few improvements to the image signing feature to
 make it easier to use on the Beaglebone Black.

 - Add a DEV_TREE_BIN option to make it easier to include the correct FDT
 (with embedded public keys) into the U-Boot image
 - Enable cache for more TI boards (to speed things up)
 - Increase malloc size
 - Enable CONFIG_OF_CONTROL, FIT and secure boot on am33xx/omap
 (RFC only, not sure we want this, although we could create a separate
  config for it)

 I also have a change to adjust mkimage to automatically make space in the
 FDT when adding hashes and signatures. Included here is the ENOSPC patch,
 but the fit_image.c patch will wait until the dumpimage tool is merged,
 since I am changing the same code.

 With this, secure boot was tested successfully on Beaglebone Black.

Do you think any of these patches should be applied?

Regards,
Simon



 Simon Glass (8):
   am33xx/omap: Allow cache enable for all Sitara/OMAP
   hash: Export functions to find and show hash
   fdt: Add DEV_TREE_BIN option to specify a device tree binary file
   fdt: Update functions which write to an FDT to return -ENOSPC
   arm: ti: Increase malloc size to 16MB for armv7 boards
   RFC: am33xx/omap: Enable CONFIG_OF_CONTROL
   RFC: am33xx/omap: Enable FIT support
   RFC: am33xx/omap: Enable secure boot with CONFIG_FIT_SIGNATURE

  Makefile   |   8 +-
  arch/arm/cpu/armv7/omap-common/Makefile|   4 +
  arch/arm/cpu/armv7/omap-common/hwinit-common.c |  41 --
  arch/arm/cpu/armv7/omap-common/omap-cache.c|  56 +++
  arch/arm/cpu/armv7/omap3/board.c   |   8 -
  arch/arm/dts/am33xx.dtsi   | 649 
 +
  arch/arm/dts/dt-bindings/gpio/gpio.h   |  15 +
  arch/arm/dts/dt-bindings/pinctrl/am33xx.h  |  41 ++
  arch/arm/dts/dt-bindings/pinctrl/omap.h|  54 ++
  board/siemens/common/board.c   |   9 -
  board/ti/dts/am335x-bone-common.dtsi   | 262 ++
  board/ti/dts/am335x-boneblack.dts  |  17 +
  board/ti/dts/tps65217.dtsi |  56 +++
  common/hash.c  |  13 +-
  common/image-fit.c |   4 +-
  doc/README.fdt-control |  16 +-
  include/configs/am335x_evm.h   |   9 +
  include/configs/ti_armv7_common.h  |   2 +-
  include/hash.h |  22 +
  include/rsa.h  |   3 +-
  lib/rsa/rsa-sign.c |  28 +-
  21 files changed, 1236 insertions(+), 81 deletions(-)
  create mode 100644 arch/arm/cpu/armv7/omap-common/omap-cache.c
  create mode 100644 arch/arm/dts/am33xx.dtsi
  create mode 100644 arch/arm/dts/dt-bindings/gpio/gpio.h
  create mode 100644 arch/arm/dts/dt-bindings/pinctrl/am33xx.h
  create mode 100644 arch/arm/dts/dt-bindings/pinctrl/omap.h
  create mode 100644 board/ti/dts/am335x-bone-common.dtsi
  create mode 100644 board/ti/dts/am335x-boneblack.dts
  create mode 100644 board/ti/dts/tps65217.dtsi

 --
 1.8.4

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

Re: [U-Boot] [PATCH 2/5] port wandboards to use the generic distro configs

[Dennis Gilmore]

Hi Wolfgang,

El Sat, 07 Dec 2013 00:16:16 +0100
Wolfgang Denk w...@denx.de escribió:
 Dear Dennis,
 
 In message 20131206164420.36e5f...@adria.ausil.us you wrote:
  
  fdtaddr is highly prevalent in the configs
 
 Yes, it appears some vendors favoured this name.  I'm temptted to add
 that these very vendors often tend to define thier own ways without
 caring what the community has been using before ;-)
 
 That doesn't make it any better, though...

Not saying that it does, just pointing out the inconsistency in the
tree today. something we likely should fix.

  those counts are in my git tree with the proposed patches applied
  that converted soem systems from fdtaddr to fdt_addr. One of the
  problems right or wrong is that u-boot is seen as not having any
  kind of standard, which is what I am trying to fix, at least for
  use in the generic distro world where we need to have an
  standardised documented interface.
 
 Even if you feel differntly, I do appreciate your efforts.  But I'd
 also like to see things done in a consistent way.  And the whole idea
 of using the _r names was to show clearly which of the addresses are
 supposed to be in system RAM (with _r), and which are not (without).

Thankyou I'm trying to be consistent in the interface between u-boot and
the operating system.

 This parallels function names like board_init_f() [_f standing for
 running from [NOR] flash] and board_init_r() [_r = running from
 system RAM].

which makes some sense in the code, but the  config is defining the
interface to kernel/userland and needs to be consistent regardless of
what is underneath 

  greping through the doc directory of git I am unable to find any
  reference to this convention you speak of. 
 
 Agreed. Noone wrote a document about this, yet.
 
  The only references i found was in README.falcon README.pxe and
  README.commands.spl based on your description it would mean falcon
  mode could not be implemented on any system not having nand.
 
 I lost you here.  What makes you think so?
Usage:

spl export img=atags|fdt [kernel_addr] [initrd_addr] [fdt_addr ]

which to me based on what you said means everything needs to be in nand

  cmd_pxe.c clearly specifies what it thinks the addresses are for
 
 Yes, it does.  But this is confused or incorrect, misusing existing
 names for other purposes.  This should be fixed.

I actually think it is spot on and is how it should be.

  Which i read as fdt_addr is a system provided dtb, and fdt_addr_r
  is a user provided one. there is no mention of where exactly they
  come from.
 
 Stop.  There has never been any such notion like system provided or
 user provided before.  You cannot just put new meanings over
 existing terms.  Actually, to me such terms don't even make much
 sense.

from u-boot itself there is not this notion. But from a Distro
perspective its always there and is a really big thing. It really is
important. in 99% of cases we want to have u-boot use a provided dtb
without the need to say so and to have it work. 

Dennis

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

Re: [U-Boot] [PATCH] mtd: nand: omap: add CONFIG_SPL_NAND_DEVICE_WIDTH to determine NAND device bus-width

[Scott Wood]

On Thu, 2013-12-05 at 18:09 +0530, Pekon Gupta wrote:
 This patch adds CONFIG_SPL_NAND_DEVICE_WIDTH to specify bus-width of NAND 
 device
   CONFIG_SPL_NAND_DEVICE_WIDTH == 16: NAND device with x16 bus-width
   CONFIG_SPL_NAND_DEVICE_WIDTH == 8:  NAND device with x8 bus-width
 
 Need for a separate CONFIG_xx arise from following situations.
 (1) SPL NAND drivers does not have framework to parse ONFI parameter page.

Yes, at least for smaller SPLs.

 (2) if !defined(CONFIG_SYS_NAND_SELF_INIT)
  |- board_nand_init()
  |- nand_scan()
|- nand_scan_ident()
|- nand_scan_tail()
This means board_nand_init() is called before nand_scan_ident(). So NAND
controller is initialized before the actual probing of NAND device.
However some controller (like GPMC) need to be specifically configured for
bus-width of NAND device.
In such cases, bus-width of the NAND device should be known in advance
of actual device probing. Hence, CONFIG_SPL_NAND_DEVICE_WIDTH is useful.

See below.

 (3) Non-ONFI compliant devices need some mechanism to specify device bus-width
to driver.

Does an x8 READ ID work with non-ONFI devices?  If not, you need
something, and I suppose you need to hardcode whether an ONFI device is
present -- but for non-SPL it's better to do it in a way that is
per-device, such as having board code initialize certain registers.  If
you really want to do it this way, though, there's already a variable
for this: CONFIG_SYS_NAND_BUSWIDTH_16BIT

Just be sure to update the documentation to add to the list of drivers
that care about that symbol.

 Signed-off-by: Pekon Gupta pe...@ti.com
 ---
  doc/README.nand|  9 +
  drivers/mtd/nand/omap_gpmc.c   | 14 ++
  include/configs/am335x_evm.h   |  1 +
  include/configs/am335x_igep0033.h  |  1 +
  include/configs/am3517_crane.h |  1 +
  include/configs/am3517_evm.h   |  1 +
  include/configs/cm_t35.h   |  1 +
  include/configs/devkit8000.h   |  1 +
  include/configs/dig297.h   |  1 +
  include/configs/mcx.h  |  1 +
  include/configs/omap3_beagle.h |  1 +
   include/configs/omap3_evm_common.h |  2 +-
  include/configs/omap3_igep00x0.h   |  1 +
  include/configs/omap3_logic.h  |  1 +
  include/configs/omap3_overo.h  |  1 +
  include/configs/omap3_pandora.h|  2 +-
  include/configs/omap3_zoom1.h  |  1 +
  include/configs/omap3_zoom2.h  |  1 +
  include/configs/siemens-am33x-common.h |  1 +
  include/configs/tam3517-common.h   |  1 +
  include/configs/tricorder.h|  1 +
  21 files changed, 38 insertions(+), 6 deletions(-)
 
 diff --git a/doc/README.nand b/doc/README.nand
 index b91f198..a07863a 100644
 --- a/doc/README.nand
 +++ b/doc/README.nand
 @@ -190,6 +190,15 @@ Configuration Options:
   This is used by SoC platforms which do not have built-in ELM
   hardware engine required for BCH ECC correction.
  
 +   CONFIG_SPL_NAND_DEVICE_WIDTH
 + Specifies bus-width of the default NAND device connected to SoC.
 + This config is useful for driver which cannot self initialize or
 + parse ONFI parameter (like SPL drivers), or for supporting non-ONFI
 + compliant devices.
 + This config can take following values:
 + - 8: x8 NAND devices is connected
 + - 16: x16 NAND device is connected

I don't understand cannot self initialize.  I understand doesn't
currently self initialize, but if that's causing a problem then why not
convert the driver to use self-init?

SPL is a different situation as it typically doesn't have dynamic ID
code at all (as opposed to the question of whether driver code can be
inserted between nand_scan_ident and nand_scan_tail).

  Platform specific options
  =
 diff --git a/drivers/mtd/nand/omap_gpmc.c b/drivers/mtd/nand/omap_gpmc.c
 index fae00be..1870152 100644
 --- a/drivers/mtd/nand/omap_gpmc.c
 +++ b/drivers/mtd/nand/omap_gpmc.c
 @@ -861,13 +861,19 @@ int board_nand_init(struct nand_chip *nand)
   nand-priv  = bch_priv;
   nand-cmd_ctrl  = omap_nand_hwcontrol;
   nand-options   |= NAND_NO_PADDING | NAND_CACHEPRG;
 - /* If we are 16 bit dev, our gpmc config tells us that */
 - if ((readl(gpmc_cfg-cs[cs].config1)  0x3000) == 0x1000)
 - nand-options |= NAND_BUSWIDTH_16;
 -
   nand-chip_delay = 100;
   nand-ecc.layout = omap_ecclayout;
  
 + /* configure driver and controller based on NAND device bus-width */
 + gpmc_config = readl(gpmc_cfg-cs[cs].config1);
 + if (CONFIG_SPL_NAND_DEVICE_WIDTH == 16) {
 + nand-options |= NAND_BUSWIDTH_16;
 + writel(gpmc_config | (0x1  12), gpmc_cfg-cs[cs].config1);
 + } else {
 + nand-options = ~NAND_BUSWIDTH_16;
 + writel(gpmc_config  ~(0x1  12), gpmc_cfg-cs[cs].config1);
 + }

This doesn't appear 

Re: [U-Boot] [PATCH v2 2/2] powerpc/c29xpcie: 8k page size NAND boot support base on TPL/SPL

[Scott Wood]

On Thu, 2013-12-05 at 14:19 +0800, Po Liu wrote:
 diff --git a/board/freescale/c29xpcie/spl.c b/board/freescale/c29xpcie/spl.c
 new file mode 100644
 index 000..7bc8ce1
 --- /dev/null
 +++ b/board/freescale/c29xpcie/spl.c
 @@ -0,0 +1,73 @@
 +/* Copyright 2013 Freescale Semiconductor, Inc.
 + *
 + * SPDX-License-Identifier:GPL-2.0+
 + */
 +
 +#include common.h
 +#include ns16550.h
 +#include malloc.h
 +#include mmc.h
 +#include nand.h
 +#include i2c.h
 +
 +DECLARE_GLOBAL_DATA_PTR;
 +
 +ulong get_effective_memsize(void)
 +{
 + return CONFIG_SYS_L2_SIZE;
 +}
 +
 +void board_init_f(ulong bootflag)
 +{
 + u32 plat_ratio;
 + ccsr_gur_t *gur = (void *)CONFIG_SYS_MPC85xx_GUTS_ADDR;
 +
 + console_init_f();
 +
 + /* initialize selected port with appropriate baud rate */
 + plat_ratio = in_be32(gur-porpllsr)  MPC85xx_PORPLLSR_PLAT_RATIO;
 + plat_ratio = 1;
 + gd-bus_clk = CONFIG_SYS_CLK_FREQ * plat_ratio;
 +
 + NS16550_init((NS16550_t)CONFIG_SYS_NS16550_COM1,
 +  gd-bus_clk / 16 / CONFIG_BAUDRATE);
 +
 + /* copy code to RAM and jump to it - this should not return */
 + /* NOTE - code has to be copied out of NAND buffer before
 +  * other blocks can be read.
 +  */
 + relocate_code(CONFIG_SPL_RELOC_STACK, 0, CONFIG_SPL_RELOC_TEXT_BASE);
 +}
 +
 +void board_init_r(gd_t *gd, ulong dest_addr)
 +{
 + /* Pointer is writable since we allocated a register for it */
 + gd = (gd_t *)CONFIG_SPL_GD_ADDR;
 + bd_t *bd;
 +
 + memset(gd, 0, sizeof(gd_t));
 + bd = (bd_t *)(CONFIG_SPL_GD_ADDR + sizeof(gd_t));
 + memset(bd, 0, sizeof(bd_t));
 + gd-bd = bd;
 + bd-bi_memstart = CONFIG_SYS_INIT_L2_ADDR;
 + bd-bi_memsize = CONFIG_SYS_L2_SIZE;
 +
 + probecpu();
 + get_clocks();
 + mem_malloc_init(CONFIG_SPL_RELOC_MALLOC_ADDR,
 + CONFIG_SPL_RELOC_MALLOC_SIZE);
 +
 + /* relocate environment function pointers etc. */
 + nand_spl_load_image(CONFIG_ENV_OFFSET, CONFIG_ENV_SIZE,
 +   (uchar *)CONFIG_ENV_ADDR);
 +   gd-env_addr  = (ulong)(CONFIG_ENV_ADDR);
 + gd-env_valid = 1;
 +
 + i2c_init_all();
 +
 + gd-ram_size = initdram(0);
 +
 + puts(\nTertiary program loader running in sram...);

Why do you assume tertiary?  Couldn't this be SPL for SD/SPI?  Or was it
a copy/paste error that you added things to the board config file for
SD/SPI (after all, the subject line says it's a NAND patch)?

 +void board_init_r(gd_t *gd, ulong dest_addr)
 +{
 + puts(\nSecond program loader running in sram...);

I see that this isn't new to this patch, but we ought to be consistent
and either change this to secondary, or change tertiary to third.

It's also probably too verbose...  Simply saying SPL\n or TPL\n
would suffice to indicate progress and verify that console output is
working (if nothing is printed, then that path doesn't get tested in the
absence of a load error).

 diff --git a/board/freescale/c29xpcie/tlb.c b/board/freescale/c29xpcie/tlb.c
 index 84844ee..11f8a37 100644
 --- a/board/freescale/c29xpcie/tlb.c
 +++ b/board/freescale/c29xpcie/tlb.c
 @@ -26,10 +26,20 @@ struct fsl_e_tlb_entry tlb_table[] = {
   0, 0, BOOKE_PAGESZ_4K, 0),
  
   /* TLB 1 */
 +#ifdef CONFIG_SPL_NAND_MINIMAL
 + SET_TLB_ENTRY(1, 0xf000, 0xf000,
 + MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
 + 0, 10, BOOKE_PAGESZ_4K, 1),
 + SET_TLB_ENTRY(1, 0xe000, 0xe000,
 + MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
 + 0, 11, BOOKE_PAGESZ_4K, 1),
 +#endif

CONFIG_SPL_NAND_MINIMAL should not exist.  It was introduced by accident
after a different approach was chosen in patch review (and even then,
this wasn't what it meant).

Prabhakar, why did you extend that to other uses?  Why are both entries
ifdeffed here, but only the 0xe000 entry on existing boards?

If this needs to be ifdeffed (and it probably does, if only to avoid
possible speculative instruction fetches), use (and document)
CONFIG_SPL_NAND_BOOT.

   SET_TLB_ENTRY(1, CONFIG_SYS_NAND_BASE, CONFIG_SYS_NAND_BASE_PHYS,
 - MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
 + MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
   0, 5, BOOKE_PAGESZ_64K, 1),

No.
 
   SET_TLB_ENTRY(1, CONFIG_SYS_PLATFORM_SRAM_BASE,
 @@ -61,7 +72,8 @@ struct fsl_e_tlb_entry tlb_table[] = {
   MAS3_SX|MAS3_SW|MAS3_SR, 0,
   0, 7, BOOKE_PAGESZ_256K, 1),
  
 -#ifdef CONFIG_SYS_RAMBOOT
 +#if defined(CONFIG_SYS_RAMBOOT) || (defined(CONFIG_SPL) \
 +  !defined(CONFIG_SPL_COMMON_INIT_DDR))
   SET_TLB_ENTRY(1, CONFIG_SYS_DDR_SDRAM_BASE,
   CONFIG_SYS_DDR_SDRAM_BASE,
   MAS3_SX|MAS3_SW|MAS3_SR, 0,

This will have the result of mapping DDR in the SPL where it's not used,
but not in the TPL where it is.

Re: [U-Boot] [PATCH v2 1/2] powerpc:mpc85xx: Add ifc nand boot support for TPL/SPL

[Scott Wood]

On Thu, 2013-12-05 at 14:18 +0800, Po Liu wrote:
 diff --git a/drivers/mtd/nand/fsl_ifc_spl.c b/drivers/mtd/nand/fsl_ifc_spl.c
 index 9de327b..93303b4 100644
 --- a/drivers/mtd/nand/fsl_ifc_spl.c
 +++ b/drivers/mtd/nand/fsl_ifc_spl.c
 @@ -88,7 +88,11 @@ static inline int bad_block(uchar *marker, int port_size)
   return __raw_readw((u16 *)marker) != 0x;
  }
  
 +#ifdef CONFIG_TPL_BUILD
 +void nand_spl_load_image(uint32_t offs, int uboot_size, void *vdst)
 +#else
  static void nand_load(unsigned int offs, int uboot_size, uchar *dst)
 +#endif
  {
   struct fsl_ifc *ifc = IFC_BASE_ADDR;
   uchar *buf = (uchar *)CONFIG_SYS_NAND_BASE;
 @@ -105,6 +109,9 @@ static void nand_load(unsigned int offs, int uboot_size, 
 uchar *dst)
  
   int sram_addr;
   int pg_no;
 +#ifdef CONFIG_TPL_BUILD
 + char *dst = vdst;
 +#endif

Use uchar to be consistent.

   /* Get NAND Flash configuration */
   csor = CONFIG_SYS_NAND_CSOR;
 @@ -211,6 +218,15 @@ static void nand_load(unsigned int offs, int uboot_size, 
 uchar *dst)
  }
  
  /*
 ++ * Defines a static function nand_load_image() here, because non-static 
 makes
 ++ * the code too large for certain SPLs(minimal SPL, maximum size = 4Kbytes)
 ++ */
 +#ifndef CONFIG_TPL_BUILD

Too many pluses -- did you copy and paste from a patch?

 diff --git a/spl/Makefile b/spl/Makefile
 index 2a787af..908af35 100644
 --- a/spl/Makefile
 +++ b/spl/Makefile
 @@ -79,6 +79,7 @@ LIBS-$(CONFIG_SPL_LIBGENERIC_SUPPORT) += lib/
  LIBS-$(CONFIG_SPL_POWER_SUPPORT) += drivers/power/ \
   drivers/power/pmic/
  LIBS-$(CONFIG_SPL_NAND_SUPPORT) += drivers/mtd/nand/
 +LIBS-$(CONFIG_SPL_IFC_SUPPORT) += drivers/misc/

Make a CONFIG_SPL_DRIVERS_MISC_SUPPORT instead.

-Scott



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

Re: [U-Boot] [PATCH REPOST] ARM: rpi_b: power on SDHCI and USB HW modules

[Stephen Warren]

On 12/06/2013 06:37 AM, Andre Heider wrote:
 Hi Stephen,
 
 On Tue, Dec 03, 2013 at 09:01:55PM -0700, Stephen Warren wrote:
 Send RPC commands to the VideoCore to turn on the SDHCI and USB modules.
 For SDHCI this isn't needed in practice, since the firmware already
 turned on the power in order to load U-Boot. However, it's best to be
 explicit. For USB, this is necessary, since the module isn't powered
 otherwise. This will allow the kernel USB driver to work.
 
 I didn't test this patch yet, but from skimming over it it looks similar to
 what I tried with barebox a while back.
 
 What I did notice with the set power mbox call is that it takes way longer
 than 100ms (the current mbox call timeout) to finish on a cold boot. You
 don't seem to bump the timeout here, and with 100ms I always hit it and
 hence the mbox call failed for me. Don't you get these huge delays?

I have firmware commit b38194c kernel: Bump version to 3.10.19, and
I'm seeing a valid non-error response to both the SD and USB set_power
requests, with no timeouts.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v1] arm: keep all sections in ELF file

[Albert ARIBAUD]

On Thu,  7 Nov 2013 14:21:46 +0100, Albert ARIBAUD
albert.u.b...@aribaud.net wrote:

 Current LDS files /DISCARD/ a lot of sections when linking ELF
 files, causing diagnostic tools such as readelf or objdump to
 produce partial output. Keep all section at link stage, filter
 only at objcopy time so that .bin remains minimal.
 
 Signed-off-by: Albert ARIBAUD albert.u.b...@aribaud.net
 ---
 This is a repost of the previously posted RFC.
 
 I have verified on an intermediate form of the patch (with .hash
 and .got.plt kept in place) that the change was binary invariant
 wrt master branch of ARM repo.
 
 Please test on your HW to make sure the .bin is functional across
 a selection of boards.
 
  Makefile|  2 +-
  arch/arm/config.mk  |  3 +++
  arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds   | 16 +---
  arch/arm/cpu/arm926ejs/spear/u-boot-spl.lds | 16 +---
  arch/arm/cpu/ixp/u-boot.lds | 15 +--
  arch/arm/cpu/u-boot-spl.lds | 15 +--
  arch/arm/cpu/u-boot.lds | 18 ++
  board/actux1/u-boot.lds | 15 +--
  board/actux2/u-boot.lds | 15 +--
  board/actux3/u-boot.lds | 15 +--
  board/dvlhost/u-boot.lds| 15 +--
  board/freescale/mx31ads/u-boot.lds  | 18 +-
  board/ti/am335x/u-boot.lds  | 15 +--
  board/vpac270/u-boot-spl.lds| 18 +-
  14 files changed, 113 insertions(+), 83 deletions(-)
 
 diff --git a/Makefile b/Makefile
 index dc04179..4720db5 100644
 --- a/Makefile
 +++ b/Makefile
 @@ -428,7 +428,7 @@ $(obj)u-boot.hex: $(obj)u-boot
   $(OBJCOPY) ${OBJCFLAGS} -O ihex $ $@
  
  $(obj)u-boot.srec:   $(obj)u-boot
 - $(OBJCOPY) -O srec $ $@
 + $(OBJCOPY) ${OBJCFLAGS} -O srec $ $@
  
  $(obj)u-boot.bin:$(obj)u-boot
   $(OBJCOPY) ${OBJCFLAGS} -O binary $ $@
 diff --git a/arch/arm/config.mk b/arch/arm/config.mk
 index bdabcf4..fd3e5fb 100644
 --- a/arch/arm/config.mk
 +++ b/arch/arm/config.mk
 @@ -103,3 +103,6 @@ ALL-y += checkarmreloc
  # such usage by requiring word relocations.
  PLATFORM_CPPFLAGS += $(call cc-option, -mword-relocations)
  endif
 +
 +# limit ourselves to the sections we want in the .bin.
 +OBJCFLAGS += -j .text -j .rodata -j .data -j .u_boot_list -j .rel.dyn
 diff --git a/arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds 
 b/arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds
 index 40bcc31..80fb9bd 100644
 --- a/arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds
 +++ b/arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds
 @@ -51,11 +51,13 @@ SECTIONS
  
   _end = .;
  
 - /DISCARD/ : { *(.dynstr*) }
 - /DISCARD/ : { *(.dynsym*) }
 - /DISCARD/ : { *(.dynamic*) }
 - /DISCARD/ : { *(.hash*) }
 - /DISCARD/ : { *(.plt*) }
 - /DISCARD/ : { *(.interp*) }
 - /DISCARD/ : { *(.gnu*) }
 + .dynsym _end : { *(.dynsym) }
 + .dynbss : { *(.dynbss) }
 + .dynstr : { *(.dynstr*) }
 + .dynamic : { *(.dynamic*) }
 + .hash : { *(.hash*) }
 + .plt : { *(.plt*) }
 + .interp : { *(.interp*) }
 + .gnu : { *(.gnu*) }
 + .ARM.exidx : { *(.ARM.exidx*) }
  }
 diff --git a/arch/arm/cpu/arm926ejs/spear/u-boot-spl.lds 
 b/arch/arm/cpu/arm926ejs/spear/u-boot-spl.lds
 index 4927736..76b499d 100644
 --- a/arch/arm/cpu/arm926ejs/spear/u-boot-spl.lds
 +++ b/arch/arm/cpu/arm926ejs/spear/u-boot-spl.lds
 @@ -51,11 +51,13 @@ SECTIONS
  
   _end = .;
  
 - /DISCARD/ : { *(.dynstr*) }
 - /DISCARD/ : { *(.dynsym*) }
 - /DISCARD/ : { *(.dynamic*) }
 - /DISCARD/ : { *(.hash*) }
 - /DISCARD/ : { *(.plt*) }
 - /DISCARD/ : { *(.interp*) }
 - /DISCARD/ : { *(.gnu*) }
 + .dynsym _end : { *(.dynsym) }
 + .dynbss : { *(.dynbss) }
 + .dynstr : { *(.dynstr*) }
 + .dynamic : { *(.dynamic*) }
 + .hash : { *(.hash*) }
 + .plt : { *(.plt*) }
 + .interp : { *(.interp*) }
 + .gnu : { *(.gnu*) }
 + .ARM.exidx : { *(.ARM.exidx*) }
  }
 diff --git a/arch/arm/cpu/ixp/u-boot.lds b/arch/arm/cpu/ixp/u-boot.lds
 index c8d2e12..676ae2c 100644
 --- a/arch/arm/cpu/ixp/u-boot.lds
 +++ b/arch/arm/cpu/ixp/u-boot.lds
 @@ -79,10 +79,13 @@ SECTIONS
   KEEP(*(.__bss_end));
   }
  
 - /DISCARD/ : { *(.dynsym) }
 - /DISCARD/ : { *(.dynstr*) }
 - /DISCARD/ : { *(.dynamic*) }
 - /DISCARD/ : { *(.plt*) }
 - /DISCARD/ : { *(.interp*) }
 - /DISCARD/ : { *(.gnu*) }
 + .dynsym _end : { *(.dynsym) }
 + .dynbss : { *(.dynbss) }
 + .dynstr : { *(.dynstr*) }
 + .dynamic : { *(.dynamic*) }
 + .hash : { *(.hash*) }
 + .plt : { *(.plt*) }
 + .interp : { *(.interp*) }
 + .gnu : { *(.gnu*) }
 + .ARM.exidx : { *(.ARM.exidx*) }
  }
 diff --git a/arch/arm/cpu/u-boot-spl.lds 

Re: [U-Boot] new uboot for custom platform

[Cornel Miron]

The CPU is : samsung s3c6410xh 66



Miron Cornel

Mobile: +40-732.746.305
E-mail: cornel.miro...@gmail.com
Yahoo ID: cornel_m2...@yahoo.com
Skype:  miron_cornel
__


On Fri, Dec 6, 2013 at 11:57 AM, Abraham V.
abraham.varric...@vvdntech.comwrote:

 Please reply to the mailing list (or just use reply-to-all option) - I
 can only respond in my spare time.

 And I'm still confused about what your hardware is. I'm *guessing*
 that you have a development board with Windows CE running. Is it a
 standard development board? Or something customized? Can you share the
 technical specifications and at least a block level diagram?

 Answer those questions on the mailing list, and I'm sure you'll be
 able to get better help.

 -Abraham

 On Fri, Dec 6, 2013 at 3:19 PM, Cornel Miron cornel.miro...@gmail.com
 wrote:
  Currently the processor has Wind CE starting, and I will start from thows
  boootlable to find informations about the addresses on where to put the
  bootable applications, but I didn't find a source code for bootable that
 can
  start android os.
 
  What am I asking links/tutorial from where I can start porting android on
  the platform.
  The platform is unknow, I have access using JTAG to processor to load the
  kernel and boot, I have access to see the chips on the board.
 
  
 
  Miron Cornel
 
  Mobile: +40-732.746.305
  E-mail: cornel.miro...@gmail.com
  Yahoo ID: cornel_m2...@yahoo.com
  Skype:  miron_cornel
  __
 
 
  On Fri, Dec 6, 2013 at 6:03 AM, Abraham V. 
 abraham.varric...@vvdntech.com
  wrote:
 
  A VERY vague question. The only thing you are correct on, is that the
  bootloader is the first software component that runs when starting a
  system. But as Michael replied, without further details like CPU,
  memory ... etc, there's very little information you've given us to
  help you.
 
  Now, on the other hand, if you are just fishing for information about
  embedded and android, I would suggest you buy a beaglebone. Android
  has been ported to it and you'll have a better idea of how things work
  by studying the related source code and hardware datasheets.
 
  -Abraham V.
 
  On Thu, Dec 5, 2013 at 5:33 PM, Cornel Miron cornel.miro...@gmail.com
  wrote:
   Hello,
   I'm new to everything about android and I try to start android on a
   custom
   platform. How can I build the bootloaders and to put android os on
 that
   platform.
   Can someone help me?
  
   ___
   U-Boot mailing list
   U-Boot@lists.denx.de
   http://lists.denx.de/mailman/listinfo/u-boot
  
 
 

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