Re: [U-Boot] [PATCH V4 3/9] DWMMC: Initialise dwmci and resolve EMMC read write issues

[Amarendra Reddy]

Hi Jaehoon,

On 11 January 2013 09:31, Jaehoon Chung jh80.ch...@samsung.com wrote:

  On 01/11/2013 12:26 AM, Simon Glass wrote:
  Hi Amar,
 
  On Fri, Jan 4, 2013 at 1:34 AM, Amar amarendra...@samsung.com wrote:
  This patch enumerates dwmci and set auto stop command during
  dwmci initialisation.
  EMMC read/write is not happening in current implementation
  due to improper fifo size computation. Hence Modified the fifo size
  computation to resolve EMMC read write issues.
 
  Changes from V1:
  1)Created the macros RX_WMARK_SHIFT and RX_WMARK_MASK in header
 file.
 
  Changes from V2:
  1)Updation of commit message and resubmition of proper patch
 set.
 
  Changes from V3:
  1)Updated to use the macro DWMCI_CTRL_SEND_AS_CCSD instead of
  the hard coded value (1  10).
 
  I suggest you take a look at patman which might simplify your patch
  sending and change logs - see tools/patman/README for details.
 
 
  Signed-off-by: Amar amarendra...@samsung.com
  ---
   drivers/mmc/dw_mmc.c | 14 --
   1 file changed, 12 insertions(+), 2 deletions(-)
 
  diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
  index 4070d4e..776fdb6 100644
  --- a/drivers/mmc/dw_mmc.c
  +++ b/drivers/mmc/dw_mmc.c
  @@ -136,6 +136,7 @@ static int dwmci_send_cmd(struct mmc *mmc, struct
 mmc_cmd *cmd,
  return TIMEOUT;
  }
  timeout--;
  +   mdelay(1);
 
  How long will this delay in total?
 i didn't sure why add the mdelay(1)..i think mdelay(1) is too long.
 Isn't there other approach to resolve read/write issue?


Other approach is
In the function dwmci_send_cmd(..), currently the variable timeout =
10.
If we change to timeout = 20, it works.


 Best Regards,
 Jaehoon Chung
  
  }
 
  dwmci_writel(host, DWMCI_RINTSTS, DWMCI_INTMSK_ALL);
  @@ -314,7 +315,7 @@ static void dwmci_set_ios(struct mmc *mmc)
   static int dwmci_init(struct mmc *mmc)
   {
  struct dwmci_host *host = (struct dwmci_host *)mmc-priv;
  -   u32 fifo_size, fifoth_val;
  +   u32 fifo_size, fifoth_val, ier;
 
  dwmci_writel(host, DWMCI_PWREN, 1);
 
  @@ -323,6 +324,14 @@ static int dwmci_init(struct mmc *mmc)
  return -1;
  }
 
  +   /* Enumerate at 400KHz */
  +   dwmci_setup_bus(host, mmc-f_min);
  +
  +   /* Set auto stop command */
  +   ier = dwmci_readl(host, DWMCI_CTRL);
  +   ier |= DWMCI_CTRL_SEND_AS_CCSD;
  +   dwmci_writel(host, DWMCI_CTRL, ier);
  +
  dwmci_writel(host, DWMCI_RINTSTS, 0x);
  dwmci_writel(host, DWMCI_INTMASK, 0);
 
  @@ -332,10 +341,11 @@ static int dwmci_init(struct mmc *mmc)
  dwmci_writel(host, DWMCI_BMOD, 1);
 
  fifo_size = dwmci_readl(host, DWMCI_FIFOTH);
  +   fifo_size = ((fifo_size  RX_WMARK_MASK)  RX_WMARK_SHIFT) + 1;
  if (host-fifoth_val)
  fifoth_val = host-fifoth_val;
  else
  -   fifoth_val = MSIZE(0x2) | RX_WMARK(fifo_size/2 -1) |
  +   fifoth_val = MSIZE(0x2) | RX_WMARK(fifo_size/2 - 1) |
  TX_WMARK(fifo_size/2);
 
  {} around this else I think. Also space around /
 
  dwmci_writel(host, DWMCI_FIFOTH, fifoth_val);
 
  --
  1.8.0
 
 
  Regards,
  Simon
 

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

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

Re: [U-Boot] [PATCH V4 2/9] EXYNOS5: FDT: Add DWMMC device node data

[Amarendra Reddy]

Hi Simon,



On 10 January 2013 20:51, Simon Glass s...@chromium.org wrote:

 Hi Amar,

 On Fri, Jan 4, 2013 at 1:34 AM, Amar amarendra...@samsung.com wrote:
  This patch adds DWMMC device node data for exynos5.
  This patch also adds binding file for DWMMC device node.
 
  Changes from V1:
  1)Added binding file for DWMMC device node at the location
  doc/device-tree-bindings/exynos/dwmmc.txt.
  2)Removed the propname 'index' from device node.
  3)Prefixed the vendor name 'samsung' before propname in device
 node.
 
  Changes from V2:
  1)Updation of commit message and resubmition of proper patch set.
 
  Changes from V3:
  No change.

 Sorry I may be too late with this comment.

 
  Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
  Signed-off-by: Amar amarendra...@samsung.comX
  ---
   arch/arm/dts/exynos5250.dtsi  | 32
 +++
   board/samsung/dts/exynos5250-smdk5250.dts | 22 +
   doc/device-tree-bindings/exynos/dwmmc.txt | 29
 
   3 files changed, 83 insertions(+)
   create mode 100644 doc/device-tree-bindings/exynos/dwmmc.txt
 
  diff --git a/arch/arm/dts/exynos5250.dtsi b/arch/arm/dts/exynos5250.dtsi
  index 1008797..b701ae5 100644
  --- a/arch/arm/dts/exynos5250.dtsi
  +++ b/arch/arm/dts/exynos5250.dtsi
  @@ -138,4 +138,36 @@
  reg = 0x131b 0x30;
  interrupts = 0 130 0;
  };
  +
  +   dwmmc@1220 {
  +   #address-cells = 1;
  +   #size-cells = 0;
  +   compatible = samsung,exynos5250-dwmmc;
  +   reg = 0x1220 0x1000;
  +   interrupts = 0 75 0;
  +   };
  +
  +   dwmmc@1221 {
  +   #address-cells = 1;
  +   #size-cells = 0;
  +   compatible = samsung,exynos5250-dwmmc;
  +   reg = 0x1221 0x1000;
  +   interrupts = 0 76 0;
  +   };
  +
  +   dwmmc@1222 {
  +   #address-cells = 1;
  +   #size-cells = 0;
  +   compatible = samsung,exynos5250-dwmmc;
  +   reg = 0x1222 0x1000;
  +   interrupts = 0 77 0;
  +   };
  +
  +   dwmmc@1223 {
  +   #address-cells = 1;
  +   #size-cells = 0;
  +   compatible = samsung,exynos5250-dwmmc;
  +   reg = 0x1223 0x1000;
  +   interrupts = 0 78 0;
  +   };
   };
  diff --git a/board/samsung/dts/exynos5250-smdk5250.dts
 b/board/samsung/dts/exynos5250-smdk5250.dts
  index a8e62da..9baf622 100644
  --- a/board/samsung/dts/exynos5250-smdk5250.dts
  +++ b/board/samsung/dts/exynos5250-smdk5250.dts
  @@ -30,6 +30,10 @@
  spi2 = /spi@12d4;
  spi3 = /spi@131a;
  spi4 = /spi@131b;
  +   dwmmc0 = /dwmmc@1220;
  +   dwmmc1 = /dwmmc@1221;
  +   dwmmc2 = /dwmmc@1222;
  +   dwmmc3 = /dwmmc@1223;

 I think this should be mmc0, mmc1 instead of dwmmc0, dwmmc1, since
 ultimate we might want to support different drivers for each. The
 alias is support to link the generic mmc device number with the
 driver, and I don't think the numbering should be specific to the
 driver.

 Ok.

   };
 
  sromc@1225 {
  @@ -59,4 +63,22 @@
  compatible = wolfson,wm8994-codec;
  };
  };
  +
  +   dwmmc@1220 {
  +   samsung,bus-width = 8;
  +   samsung,timing = 1 3 3;
  +   };
  +
  +   dwmmc@1221 {
  +   status = disabled;
  +   };
  +
  +   dwmmc@1222 {
  +   samsung,bus-width = 4;
  +   samsung,timing = 1 2 3;
  +   };
  +
  +   dwmmc@1223 {
  +   status = disabled;
  +   };
   };
  diff --git a/doc/device-tree-bindings/exynos/dwmmc.txt
 b/doc/device-tree-bindings/exynos/dwmmc.txt
  new file mode 100644
  index 000..6232ad6
  --- /dev/null
  +++ b/doc/device-tree-bindings/exynos/dwmmc.txt
  @@ -0,0 +1,29 @@
  +* Exynos 5250 DWC_mobile_storage
  +
  +The Exynos 5250 provides DWC_mobile_storage interface which supports
  +. Embedded Multimedia Cards (EMMC-version 4.5)
  +. Secure Digital memory (SD mem-version 2.0)
  +. Secure Digital I/O (SDIO-version 3.0)
  +. Consumer Electronics Advanced Transport Architecture (CE-ATA-version
 1.1)
  +
  +The Exynos 5250 DWC_mobile_storage provides four channels.
  +SOC specific and Board specific properties are channel specific.
  +
  +Required SoC Specific Properties:
  +
  +- compatible: should be
  +   - samsung,exynos5250-dwmmc: for exynos5250 platforms
  +
  +- reg: physical base address of the controller and length of memory
 mapped
  +   region.
  +
  +- interrupts: The interrupt number to the cpu.
  +
  +Required Board Specific Properties:
  +
  +- #address-cells: should 

Re: [U-Boot] [PATCH V4 8/9] SMDK5250: Enable EMMC booting

[Amarendra Reddy]

Hi Simon,

Thanks for review comments.
Please find my responses below.

Thanks  Regards
Amarendra

On 10 January 2013 22:09, Simon Glass s...@chromium.org wrote:

 Hi Amar,

 On Fri, Jan 4, 2013 at 1:34 AM, Amar amarendra...@samsung.com wrote:
  This patch adds support for EMMC booting on SMDK5250.
 
  Changes from V1:
  1)Updated spl_boot.c file to maintain irom pointer table
  instead of using the #define values defined in header file.
 
  Changes from V2:
  1)Updation of commit message and resubmition of proper patch set.
 
  Changes from V3:
  No change.
 
  Signed-off-by: Amar amarendra...@samsung.com
  ---
   board/samsung/smdk5250/clock_init.c | 15 +++
   board/samsung/smdk5250/clock_init.h |  5 
   board/samsung/smdk5250/spl_boot.c   | 52
 -
   3 files changed, 65 insertions(+), 7 deletions(-)
 
  diff --git a/board/samsung/smdk5250/clock_init.c
 b/board/samsung/smdk5250/clock_init.c
  index c009ae5..154993c 100644
  --- a/board/samsung/smdk5250/clock_init.c
  +++ b/board/samsung/smdk5250/clock_init.c
  @@ -28,6 +28,7 @@
   #include asm/arch/clk.h
   #include asm/arch/clock.h
   #include asm/arch/spl.h
  +#include asm/arch/dwmmc.h
 
   #include clock_init.h
   #include setup.h
  @@ -664,3 +665,17 @@ void clock_init_dp_clock(void)
  /* We run DP at 267 Mhz */
  setbits_le32(clk-div_disp1_0, CLK_DIV_DISP1_0_FIMD1);
   }
  +
  +/*
  + * Set clock divisor value for booting from EMMC.
  + * Set DWMMC channel-0 clk div to operate mmc0 device at 50MHz.
  + */
  +void emmc_boot_clk_div_set(void)
  +{
  +   struct exynos5_clock *clk = (struct exynos5_clock
 *)EXYNOS5_CLOCK_BASE;
  +   unsigned int div_mmc;
  +
  +   div_mmc = readl((unsigned int) clk-div_fsys1) 
 ~FSYS1_MMC0_DIV_MASK;
  +   div_mmc |= FSYS1_MMC0_DIV_VAL;
  +   writel(div_mmc, (unsigned int) clk-div_fsys1);
  +}
  diff --git a/board/samsung/smdk5250/clock_init.h
 b/board/samsung/smdk5250/clock_init.h
  index f751bcb..20a1d47 100644
  --- a/board/samsung/smdk5250/clock_init.h
  +++ b/board/samsung/smdk5250/clock_init.h
  @@ -146,4 +146,9 @@ struct mem_timings *clock_get_mem_timings(void);
* Initialize clock for the device
*/
   void system_clock_init(void);
  +
  +/*
  + * Set clock divisor value for booting from EMMC.
  + */
  +void emmc_boot_clk_div_set(void);
   #endif
  diff --git a/board/samsung/smdk5250/spl_boot.c
 b/board/samsung/smdk5250/spl_boot.c
  index d8f3c1e..906e197 100644
  --- a/board/samsung/smdk5250/spl_boot.c
  +++ b/board/samsung/smdk5250/spl_boot.c
  @@ -23,16 +23,38 @@
   #includecommon.h
   #includeconfig.h
 
  +#include asm/arch-exynos/dmc.h
  +#include asm/arch/clock.h
  +#include asm/arch/clk.h
  +
  +#include clock_init.h
  +
  +/* Index into irom ptr table */
  +enum index {
  +   MMC_INDEX,
  +   EMMC44_INDEX,
  +   EMMC44_END_INDEX,
  +   SPI_INDEX,
  +};
  +
  +/* IROM Function Pointers Table */
  +u32 irom_ptr_table[] = {
  +   [MMC_INDEX] = 0x02020030,   /* iROM Function Pointer-SDMMC
 boot */
  +   [EMMC44_INDEX] = 0x02020044,/* iROM Function Pointer-EMMC4.4
 boot*/
  +   [EMMC44_END_INDEX] = 0x02020048,/* iROM Function Pointer
  +   -EMMC4.4 end boot
 operation */
  +   [SPI_INDEX] = 0x02020058,   /* iROM Function Pointer-SPI
 boot */
  +   };
  +
   enum boot_mode {
  BOOT_MODE_MMC = 4,
  BOOT_MODE_SERIAL = 20,
  +   BOOT_MODE_EMMC = 8, /* EMMC4.4 */
  /* Boot based on Operating Mode pin settings */
  BOOT_MODE_OM = 32,
  BOOT_MODE_USB,  /* Boot using USB download */
   };
 
  -   typedef u32 (*spi_copy_func_t)(u32 offset, u32 nblock, u32 dst);
  -
   /*
   * Copy U-boot from mmc to RAM:
   * COPY_BL2_FNPTR_ADDR: Address in iRAM, which Contains
  @@ -40,23 +62,39 @@ enum boot_mode {
   */
   void copy_uboot_to_ram(void)
   {
  -   spi_copy_func_t spi_copy;
  enum boot_mode bootmode;
  -   u32 (*copy_bl2)(u32, u32, u32);
  -
  +   u32 (*spi_copy)(u32 offset, u32 nblock, u32 dst);
  +   u32 (*copy_bl2)(u32 offset, u32 nblock, u32 dst);
  +   u32 (*copy_bl2_from_emmc)(u32 nblock, u32 dst);
  +   void (*end_bootop_from_emmc)(void);
  +   /* read Operation Mode ststus register to find the bootmode */
  bootmode = readl(EXYNOS5_POWER_BASE)  OM_STAT;
 
  switch (bootmode) {
  case BOOT_MODE_SERIAL:
  -   spi_copy = *(spi_copy_func_t
 *)EXYNOS_COPY_SPI_FNPTR_ADDR;
  +   spi_copy = (void *) *(u32 *)irom_ptr_table[SPI_INDEX];

 This looks OK to me. My only suggestion is to put the lookup in a function
 like:

 static void *get_irom_func(int index)

 and avoid all the casting here.

 Ok will implement in next patch set.

  spi_copy(SPI_FLASH_UBOOT_POS, CONFIG_BL2_SIZE,
  CONFIG_SYS_TEXT_BASE);
   

Re: [U-Boot] [PATCH V4 6/9] SMDK5250: Initialise and Enable DWMMC, support FDT and non-FDT

[Amarendra Reddy]

Hi Simon,

Thanks for the review comments.
Please find my responses below.

Thanks  Regards
Amarendra Reddy

On 12 January 2013 22:11, Simon Glass s...@chromium.org wrote:

 Hi Amar,

 On Fri, Jan 11, 2013 at 9:58 AM, Amarendra Reddy
 amar.lavan...@gmail.com wrote:
  Hi Simon,
 
  Thanks for review comments.
  Please find my responses below.
 
  Thanks  Regards
  Amarendra Reddy
 
  On 10 January 2013 22:27, Simon Glass s...@chromium.org wrote:
 
  Hi Amar,
 
  On Fri, Jan 4, 2013 at 1:34 AM, Amar amarendra...@samsung.com wrote:
   This patch enables and initialises DWMMC for SMDK5250.
   Supports both FDT and non-FDT. This patch creates a new file
   'exynos5-dt.c' meant for FDT support.
   exynos5-dt.c:   This file shall contain all code which
 supports
   FDT.
   Any addition of FDT support for any module
 needs
   to be
   added in this file.
   smdk5250.c: This file shall contain the code which
 supports
   non-FDT.
   version. Any addition of non-FDT support for
 any
   module
   needs to be added in this file.
   May be, the file smdk5250.c can be removed in
   near future
   when non-FDT is not required.
  
   The Makefile is updated to compile only one of the files
   exynos5-dt.c / smdk5250.c based on FDT configuration.
  
   NOTE:
   Please note that all additions corresponding to FDT need to be added
   into the
   file exynos5-dt.c.
   At same time if non-FDT support is required then add the corresponding
   updations into smdk5250.c.
  
   Changes from V1:
   1)A new file 'exynos5-dt.c' is created meant for FDT support
   2)Makefile is updated to compile only one of the files
   exynos5-dt.c / smdk5250.c based on FDT configuration
  
   Changes from V2:
   1)Updation of commit message and resubmition of proper patch
   set.
  
   Changes from V3:
   No change.
  
   Signed-off-by: Amar amarendra...@samsung.com
   ---
board/samsung/smdk5250/Makefile |   4 +
board/samsung/smdk5250/exynos5-dt.c | 242
   
board/samsung/smdk5250/smdk5250.c   |  97 +++
include/configs/exynos5250-dt.h |   2 +
include/i2c.h   |   2 +
5 files changed, 292 insertions(+), 55 deletions(-)
create mode 100644 board/samsung/smdk5250/exynos5-dt.c
  
   diff --git a/board/samsung/smdk5250/Makefile
   b/board/samsung/smdk5250/Makefile
   index 47c6a5a..ecca9f3 100644
   --- a/board/samsung/smdk5250/Makefile
   +++ b/board/samsung/smdk5250/Makefile
   @@ -32,8 +32,12 @@ COBJS+= tzpc_init.o
COBJS  += smdk5250_spl.o
  
ifndef CONFIG_SPL_BUILD
   +ifdef CONFIG_OF_CONTROL
   +COBJS  += exynos5-dt.o
   +else
COBJS  += smdk5250.o
endif
   +endif
  
ifdef CONFIG_SPL_BUILD
COBJS  += spl_boot.o
   diff --git a/board/samsung/smdk5250/exynos5-dt.c
   b/board/samsung/smdk5250/exynos5-dt.c
   new file mode 100644
   index 000..da539ca
   --- /dev/null
   +++ b/board/samsung/smdk5250/exynos5-dt.c
   @@ -0,0 +1,242 @@
   +/*
   + * Copyright (C) 2012 Samsung Electronics
   + *
   + * See file CREDITS for list of people who contributed to this
   + * project.
   + *
   + * This program is free software; you can redistribute it and/or
   + * modify it under the terms of the GNU General Public License as
   + * published by the Free Software Foundation; either version 2 of
   + * the License, or (at your option) any later version.
   + *
   + * This program is distributed in the hope that it will be useful,
   + * but WITHOUT ANY WARRANTY; without even the implied warranty of
   + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   + * GNU General Public License for more details.
   + *
   + * You should have received a copy of the GNU General Public License
   + * along with this program; if not, write to the Free Software
   + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
   + * MA 02111-1307 USA
   + */
   +
   +#include common.h
   +#include fdtdec.h
   +#include asm/io.h
   +#include i2c.h
   +#include netdev.h
   +#include spi.h
   +#include asm/arch/cpu.h
   +#include asm/arch/dwmmc.h
   +#include asm/arch/gpio.h
   +#include asm/arch/mmc.h
   +#include asm/arch/pinmux.h
   +#include asm/arch/sromc.h
   +#include power/pmic.h
   +
   +DECLARE_GLOBAL_DATA_PTR;
   +
   +int board_init(void)
   +{
   +   gd-bd-bi_boot_params = (PHYS_SDRAM_1 + 0x100UL);
   +#ifdef CONFIG_EXYNOS_SPI
   +   spi_init();
   +#endif
   +   return 0;
   +}
   +
   +int dram_init(void)
   +{
   +   gd-ram_size= get_ram_size((long *)PHYS_SDRAM_1,
   PHYS_SDRAM_1_SIZE)
   +   + get_ram_size((long *)PHYS_SDRAM_2,
   PHYS_SDRAM_2_SIZE)
   +   + get_ram_size((long *)PHYS_SDRAM_3,
   PHYS_SDRAM_3_SIZE)
   +   + get_ram_size((long 

[U-Boot] [PATCH 0/2] SMDK5250: Set Initial PMIC Values

[Rajeshwari Shinde]

This patch set seperates setting PMIC values form previous
Convert lowlevel_init.S to .c patch set.
These patches add PMIC MAX77686 voltage settings for SMDK5250.

Rajeshwari Shinde (2):
  EXYNOS5: Add function to setup set ps hold
  SMDK5250: Add PMIC voltage settings

 arch/arm/cpu/armv7/exynos/power.c|   10 +++
 arch/arm/include/asm/arch-exynos/power.h |8 ++
 board/samsung/smdk5250/smdk5250.c|  113 +-
 include/power/max77686_pmic.h|   30 
 4 files changed, 159 insertions(+), 2 deletions(-)

-- 
1.7.4.4

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

[U-Boot] [PATCH 1/2] EXYNOS5: Add function to setup set ps hold

[Rajeshwari Shinde]

This patch adds a function to set ps_hold data driving value high.
This enables the machine to stay powered on after the initial
power-on condition goes away(e.g. power button).

Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
 arch/arm/cpu/armv7/exynos/power.c|   10 ++
 arch/arm/include/asm/arch-exynos/power.h |8 
 2 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/arch/arm/cpu/armv7/exynos/power.c 
b/arch/arm/cpu/armv7/exynos/power.c
index d4bce6d..8572cfd 100644
--- a/arch/arm/cpu/armv7/exynos/power.c
+++ b/arch/arm/cpu/armv7/exynos/power.c
@@ -95,3 +95,13 @@ void set_dp_phy_ctrl(unsigned int enable)
if (cpu_is_exynos5())
exynos5_dp_phy_control(enable);
 }
+
+void power_ps_hold_setup(void)
+{
+   struct exynos5_power *power =
+   (struct exynos5_power *)samsung_get_base_power();
+
+   /* Set PS-Hold high */
+   setbits_le32(power-ps_hold_control,
+   EXYNOS_PS_HOLD_CONTROL_DATA_HIGH);
+}
diff --git a/arch/arm/include/asm/arch-exynos/power.h 
b/arch/arm/include/asm/arch-exynos/power.h
index d2fdb59..85e2cd9 100644
--- a/arch/arm/include/asm/arch-exynos/power.h
+++ b/arch/arm/include/asm/arch-exynos/power.h
@@ -864,4 +864,12 @@ void set_dp_phy_ctrl(unsigned int enable);
 
 #define EXYNOS_DP_PHY_ENABLE   (1  0)
 
+#define EXYNOS_PS_HOLD_CONTROL_DATA_HIGH   (1  8)
+
+/*Set ps_hold data driving value high
+ * This enables the machine to stay powered on
+ * after the initial power-on condition goes away
+ * (e.g. power button).
+ */
+void power_ps_hold_setup(void);
 #endif
-- 
1.7.4.4

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

[U-Boot] [PATCH 2/2] SMDK5250: Add PMIC voltage settings

[Rajeshwari Shinde]

This patch adds required pmic voltage settings for SMDK5250.

Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
 board/samsung/smdk5250/smdk5250.c |  113 -
 include/power/max77686_pmic.h |   30 ++
 2 files changed, 141 insertions(+), 2 deletions(-)

diff --git a/board/samsung/smdk5250/smdk5250.c 
b/board/samsung/smdk5250/smdk5250.c
index 7a5f132..12cc03e 100644
--- a/board/samsung/smdk5250/smdk5250.c
+++ b/board/samsung/smdk5250/smdk5250.c
@@ -23,6 +23,7 @@
 #include common.h
 #include fdtdec.h
 #include asm/io.h
+#include errno.h
 #include i2c.h
 #include lcd.h
 #include netdev.h
@@ -35,6 +36,7 @@
 #include asm/arch/sromc.h
 #include asm/arch/dp_info.h
 #include power/pmic.h
+#include power/max77686_pmic.h
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -80,12 +82,119 @@ int dram_init(void)
 }
 
 #if defined(CONFIG_POWER)
+static int pmic_reg_update(struct pmic *p, int reg, uint regval)
+{
+   u32 val;
+   int ret = 0;
+
+   ret = pmic_reg_read(p, reg, val);
+   if (ret) {
+   debug(%s: PMIC %d register read failed\n, __func__, reg);
+   return -1;
+   }
+   val |= regval;
+   ret = pmic_reg_write(p, reg, val);
+   if (ret) {
+   debug(%s: PMIC %d register write failed\n, __func__, reg);
+   return -1;
+   }
+   return 0;
+}
+
 int power_init_board(void)
 {
+   struct pmic *p;
+
+   power_ps_hold_setup();
+
+   i2c_init(CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE);
+
if (pmic_init(I2C_PMIC))
return -1;
-   else
-   return 0;
+
+   p = pmic_get(MAX77686_PMIC);
+   if (!p)
+   return -ENODEV;
+
+   if (pmic_probe(p))
+   return -1;
+
+   if (pmic_reg_update(p, MAX77686_REG_PMIC_32KHZ, MAX77686_32KHCP_EN))
+   return -1;
+
+   if (pmic_reg_update(p, MAX77686_REG_PMIC_BBAT,
+   MAX77686_BBCHOSTEN | MAX77686_BBCVS_3_5V))
+   return -1;
+
+   /* VDD_MIF */
+   if (pmic_reg_write(p, MAX77686_REG_PMIC_BUCK1OUT,
+   MAX77686_BUCK1OUT_1V)) {
+   debug(%s: PMIC %d register write failed\n, __func__,
+   MAX77686_REG_PMIC_BUCK1OUT);
+   return -1;
+   }
+
+   if (pmic_reg_update(p, MAX77686_REG_PMIC_BUCK1CRTL,
+   MAX77686_BUCK1CTRL_EN))
+   return -1;
+
+   /* VDD_ARM */
+   if (pmic_reg_write(p, MAX77686_REG_PMIC_BUCK2DVS1,
+   MAX77686_BUCK2DVS1_1_3V)) {
+   debug(%s: PMIC %d register write failed\n, __func__,
+   MAX77686_REG_PMIC_BUCK2DVS1);
+   return -1;
+   }
+
+   if (pmic_reg_update(p, MAX77686_REG_PMIC_BUCK2CTRL1,
+   MAX77686_BUCK2CTRL_ON))
+   return -1;
+
+   /* VDD_INT */
+   if (pmic_reg_write(p, MAX77686_REG_PMIC_BUCK3DVS1,
+   MAX77686_BUCK3DVS1_1_0125V)) {
+   debug(%s: PMIC %d register write failed\n, __func__,
+   MAX77686_REG_PMIC_BUCK3DVS1);
+   return -1;
+   }
+
+   if (pmic_reg_update(p, MAX77686_REG_PMIC_BUCK3CTRL,
+   MAX77686_BUCK3CTRL_ON))
+   return -1;
+
+   /* VDD_G3D */
+   if (pmic_reg_write(p, MAX77686_REG_PMIC_BUCK4DVS1,
+   MAX77686_BUCK4DVS1_1_2V)) {
+   debug(%s: PMIC %d register write failed\n, __func__,
+   MAX77686_REG_PMIC_BUCK4DVS1);
+   return -1;
+   }
+
+   if (pmic_reg_update(p, MAX77686_REG_PMIC_BUCK4CTRL1,
+   MAX77686_BUCK3CTRL_ON))
+   return -1;
+
+   /* VDD_LDO2 */
+   if (pmic_reg_update(p, MAX77686_REG_PMIC_LDO2CTRL1,
+   MAX77686_LD02CTRL1_1_5V | EN_LDO))
+   return -1;
+
+   /* VDD_LDO3 */
+   if (pmic_reg_update(p, MAX77686_REG_PMIC_LDO3CTRL1,
+   MAX77686_LD03CTRL1_1_8V | EN_LDO))
+   return -1;
+
+   /* VDD_LDO5 */
+   if (pmic_reg_update(p, MAX77686_REG_PMIC_LDO5CTRL1,
+   MAX77686_LD05CTRL1_1_8V | EN_LDO))
+   return -1;
+
+   /* VDD_LDO10 */
+   if (pmic_reg_update(p, MAX77686_REG_PMIC_LDO10CTRL1,
+   MAX77686_LD10CTRL1_1_8V | EN_LDO))
+   return -1;
+
+   return 0;
 }
 #endif
 
diff --git a/include/power/max77686_pmic.h b/include/power/max77686_pmic.h
index d949ace..5b7b6ce 100644
--- a/include/power/max77686_pmic.h
+++ b/include/power/max77686_pmic.h
@@ -155,4 +155,34 @@ enum {
EN_LDO = (0x3  6),
 };
 

Re: [U-Boot] [PATCH 1/2] phy: export genphy_parse_link()

[Yegor Yefremov]

On Wed, Nov 28, 2012 at 11:15 AM,  yegorsli...@googlemail.com wrote:
 From: Yegor Yefremov yegorsli...@googlemail.com

 Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com
 ---
  drivers/net/phy/phy.c |2 +-
  include/phy.h |1 +
  2 files changed, 2 insertions(+), 1 deletions(-)

 diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
 index 1ffa791..c28ea70 100644
 --- a/drivers/net/phy/phy.c
 +++ b/drivers/net/phy/phy.c
 @@ -279,7 +279,7 @@ int genphy_update_link(struct phy_device *phydev)
   *
   * Stolen from Linux's mii.c and phy_device.c
   */
 -static int genphy_parse_link(struct phy_device *phydev)
 +int genphy_parse_link(struct phy_device *phydev)
  {
 int mii_reg = phy_read(phydev, MDIO_DEVAD_NONE, MII_BMSR);

 diff --git a/include/phy.h b/include/phy.h
 index 3c30f11..1342ef7 100644
 --- a/include/phy.h
 +++ b/include/phy.h
 @@ -209,6 +209,7 @@ int phy_register(struct phy_driver *drv);
  int genphy_config_aneg(struct phy_device *phydev);
  int genphy_restart_aneg(struct phy_device *phydev);
  int genphy_update_link(struct phy_device *phydev);
 +int genphy_parse_link(struct phy_device *phydev);
  int genphy_config(struct phy_device *phydev);
  int genphy_startup(struct phy_device *phydev);
  int genphy_shutdown(struct phy_device *phydev);
 --
 1.7.7


Hi Joe,

could you please take a look at this patch series (the second patch is
about adding ICPlus phy)?

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

Re: [U-Boot] NAND flash - bad blocks

[Dimitar Penev]

Hi Scott,

I have tried to do some more tests on the board with the NAND chip I have 
scrub-ed


-I have done 'nand erase.chip clean' and tried to probe different nand 
regions
(I have 128MB RAM and 1GB NAND and I am not sure how I could dump the whole 
NAND at once)

It seems the whole NAND is 0xFF

After that I have written 10MB at the beginning of the NAND and those data 
was verified to be written OK

Outside of the 10MB region the NAND stays 0xFF

in Linux 'nandtest' doesn't report any issue.

So I tend to think that nand scrub did a good think for me.

Best Regards
Dimitar

- Original Message - 
From: Scott Wood scottw...@freescale.com

To: Dimitar Penev d...@switchfin.org
Cc: u-boot@lists.denx.de
Sent: Friday, January 11, 2013 10:21 PM
Subject: Re: [U-Boot] NAND flash - bad blocks


On 01/11/2013 02:46:06 AM, Dimitar Penev wrote:

Hi Scott,


On 01/10/2013 01:56:30 AM, Dimitar Penev wrote:

Hello,

First of all sorry if this question was already answered here.

We are sourcing some K9F8G08U0M-PIB0 NAND flash devices.
On the first erase in uboot 2011.09 I got bunch of mostly  consecutive 
bad blocks.
According to the datasheet we should get not more then 80 bad  blocks 
for our chip

but I get something like 240 bad blocks for most of the NAND chips.

I seems to be able to fix this using the following procedure:


Call your NAND vendor and complain?



Well we did but we didn't got something from them which could explain 
what we observe.


After making sure that there's nothing wrong with your NAND driver  or 
controller that causes the OOB to be read incorrectly.


We are using nand_plat driver provide by ADI without any  customization.


Still, do some investigation to see whether it seems to be working.
Dump the raw data that you read -- is it mostly 0xff with some bad
block markers set, or is it returning garbage?  Do any of the blocks
that are not marked bad have non-0xff data?  If you do a scrub of the
entire NAND chip, then write to one block, does the write show up
anywhere else on the NAND chip?


In uboot
ubootnand scrub.chip

In uboot
ubootnand erase.chip clean
at this point I get usually 1,2 bad blocks which looks normal to me.


You're not fixing anything -- you're wiping out all bad block 
information. Those 1,2 bad blocks are not actually bad blocks,  but 
are the bad block table which appears bad to reserve it.   These 
should be at the end of flash.  Or, possibly, they're blocks  that 
happen to be damaged in a way that prevents the bad block  marker from 
becoming 0xff.


Oh Really?
What about 'nandtest -m' in Linux ? I was hoping it does a check of  the 
erase blocks.


That's no substitute for having the factory bad block markers.
Nandtest doesn't look very rigorous at all -- and only seems to mark
bad blocks if the erase or write operations return failure, not if it
sees an uncorrectable error on readback.


Thanks Scott.
Is there any procedure to analyze the nand flash for bad blocks?


Yes, and it's done by the flash manufacturer to produce bad block
markers. :-P

-Scott

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

[U-Boot] Flash Not Erased Problem with M29W128GL

[Ramesh K Khokhani]

Hi Friends,

I have my custom board with MCF5329 processor and M29W128GL (16MB NOR).
I have LTIB package from freescale of M5329EVB board. I am using this package 
and modified according M29W128GL NOR.
Like

* FLASH organization
 */
#define CONFIG_SYS_FLASH_CFI
#ifdef CONFIG_SYS_FLASH_CFI
# define CONFIG_FLASH_CFI_DRIVER  1
# define CONFIG_SYS_FLASH_SIZE0x100   /* Max size that the 
board might have */
# define CONFIG_SYS_FLASH_CFI_WIDTH   FLASH_CFI_16BIT
# define CONFIG_SYS_MAX_FLASH_BANKS   1 /* max number of memory banks */
# define CONFIG_SYS_MAX_FLASH_SECT137   /* max number of sectors on one 
chip */
# define CONFIG_SYS_FLASH_PROTECTION  /* Real (hardware) sectors 
protection */
#endif


And Enviroment Configuration:

#define CONFIG_SYS_FLASH_BASE   CONFIG_SYS_CS0_BASE

/* Configuration for environment
 * Environment is embedded in u-boot in the second sector of the flash
 */
#define CONFIG_ENV_OFFSET   0x4
#define CONFIG_ENV_SECT_SIZE0x2
#define CONFIG_ENV_SIZE 0x2000
#define CONFIG_ENV_IS_IN_FLASH  1


And U-boot output after flash using JTAG:

U-Boot 2011.09 (Jan 15 2013 - 14:03:02)

CPU:   BTAM MCF5329 (Mask:54 Version:2)
   CPU CLK 240 MHz BUS CLK 80 MHz
Board: BTAM 5329
I2C:   ready
DRAM:  32 MiB
Reserving 512k for protected RAM at 41f8
Top of RAM usable for U-Boot at: 41f8
Reserving 155k for U-Boot at: 41f59000
Reserving 256k for malloc() at: 41f19000
Reserving 58 Bytes for Board Info at: 41f18fc6
Reserving 88 Bytes for Global Data at: 41f18f6e
Reserving 64k for boot parameters at: 41f08f6e
Stack Pointer at: 41f08f48
Start relocate of code from 0400 to 41f59000
Now running in RAM - U-Boot at: 41f59000
Flash: flash detect cfi
fwc addr (null) cmd f0 f000 16bit x 8 bit
fwc addr 00aa cmd 98 9800 16bit x 8 bit
is= cmd 51(Q) addr 0020 is= 5100 5100
is= cmd 52(R) addr 0022 is= 5200 5200
is= cmd 59(Y) addr 0024 is= 5900 5900

device interface is 2
found port 2 chip 1 port 16 bits chip 8 bits
00 : 51 52 59 02 00 40 00 00 00 00 00 27 36 b5 c5 04  QRY..@.'6...
10 : 04 09 10 04 02 03 04 18 02 00 06 00 01 7f 00 00  
20 : 02 00 00 00 00 00 00 00 00 00 00 00 00 41 f0 8e  .A..
fwc addr (null) cmd f0 f0 8bit x 8 bit
fwc addr 0aaa cmd aa aa 8bit x 8 bit
fwc addr 0555 cmd 55 55 8bit x 8 bit
fwc addr 0aaa cmd 90 90 8bit x 8 bit
fwc addr (null) cmd f0 f0 8bit x 8 bit
fwc addr 00aa cmd 98 9800 16bit x 8 bit
manufacturer is 2
manufacturer id is 0x0
device id is 0x22
device id2 is 0x0
cfi version is 0x3133
size_ratio 1 port 16 bits chip 8 bits
found 1 erase regions
erase region 0: 0x027f
erase_region_count = 128 erase_region_size = 131072

fwc addr (null) cmd f0 f0 8bit x 8 bit
Portwidth: 1
Chipwidth: 1
Man ID   : 0
Device ID: 34
flash_protect ON: from 0x0400 to 0x000213FF
fwc addr (null) cmd 70 70 8bit x 8 bit
flash_is_busy: 0
protect on 0
fwc addr 0002 cmd 70 70 8bit x 8 bit
flash_is_busy: 0
protect on 1
flash_protect ON: from 0x0004 to 0x0005
fwc addr 0004 cmd 70 70 8bit x 8 bit
flash_is_busy: 0
protect on 2
16 MiB
*** Warning - bad CRC, using default environment

Destroy Hash Table: 41f7beb4 table = (null)
Create Hash Table: N=105
INSERT: table 41f7beb4, filled 1/107 rv 41f19414 == name=bootdelay value=5
INSERT: table 41f7beb4, filled 2/107 rv 41f19480 == name=baudrate 
value=115200
INSERT: table 41f7beb4, filled 3/107 rv 41f1936c == name=ethaddr 
value=00:e0:0c:bc:e5:60
INSERT: table 41f7beb4, filled 4/107 rv 41f1930c == name=ipaddr 
value=192.162.1.2
INSERT: table 41f7beb4, filled 5/107 rv 41f194e0 == name=serverip 
value=192.162.1.1
INSERT: table 41f7beb4, filled 6/107 rv 41f191d4 == name=gatewayip 
value=192.162.1.1
INSERT: table 41f7beb4, filled 7/107 rv 41f19654 == name=netmask 
value=255.255.255.0
INSERT: table 41f7beb4, filled 8/107 rv 41f194a4 == name=hostname 
value=M5329EVB
INSERT: table 41f7beb4, filled 9/107 rv 41f1954c == name=netdev value=eth0
INSERT: table 41f7beb4, filled 10/107 rv 41f194ec == name=loadaddr 
value=4001
INSERT: table 41f7beb4, filled 11/107 rv 41f19564 == name=u-boot 
value=u-boot.bin
INSERT: table 41f7beb4, filled 12/107 rv 41f194b0 == name=load value=tftp 
${loadaddr) ${u-boot}
INSERT: table 41f7beb4, filled 13/107 rv 41f1960c == name=upd value=run 
load; run prog
INSERT: table 41f7beb4, filled 14/107 rv 41f193cc == name=prog value=prot 
off 0 3;era 0 3;cp.b ${loadaddr} 0 ${filesize};save
INSERT: free(data = 41f19008)
INSERT: done
In:serial
Out:   serial
Err:   serial
U-Boot relocated to 41f59000
Net:   No PHY device found.
FEC0
### main_loop entered: bootdelay=5

### main_loop: bootcmd=UNDEFINED
- saveenv
Saving Environment to Flash...
Data to save 0x1f000, 0x4, 0x5
Data (start 0x41000, len 0x1f000) saved at 0x41f1a058
Protect off 0004 ... 0005
Un-Protecting sectors 2..2 in bank 1
fwc addr 0004 cmd 70 70 8bit x 8 bit
flash_is_busy: 0
. done

[U-Boot] [PATCH] README: imximage: mx35 does not boot from internal mode yet

[Fabio Estevam]

Currently booting from internal mode is not supported in U-boot for mx35, so 
remove it from the list of supported SoCs.

Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
 doc/README.imximage |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/README.imximage b/doc/README.imximage
index 073e3fc..5f4d277 100644
--- a/doc/README.imximage
+++ b/doc/README.imximage
@@ -3,7 +3,7 @@ Imximage Boot Image generation using mkimage
 -
 
 This document describes how to set up a U-Boot image that can be booted
-by Freescale MX25, MX35, MX51, MX53 and MX6 processors via internal boot
+by Freescale MX25, MX51, MX53 and MX6 processors via internal boot
 mode.
 
 These processors can boot directly from NAND, SPI flash and SD card flash
-- 
1.7.9.5


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

Re: [U-Boot] [PATCH] README: imximage: mx35 does not boot from internal mode yet

[Stefano Babic]

On 15/01/2013 13:07, Fabio Estevam wrote:
 Currently booting from internal mode is not supported in U-boot for mx35, so 
 remove it from the list of supported SoCs.
 
 Signed-off-by: Fabio Estevam fabio.este...@freescale.com
 ---
  doc/README.imximage |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/doc/README.imximage b/doc/README.imximage
 index 073e3fc..5f4d277 100644
 --- a/doc/README.imximage
 +++ b/doc/README.imximage
 @@ -3,7 +3,7 @@ Imximage Boot Image generation using mkimage
  -
  
  This document describes how to set up a U-Boot image that can be booted
 -by Freescale MX25, MX35, MX51, MX53 and MX6 processors via internal boot
 +by Freescale MX25, MX51, MX53 and MX6 processors via internal boot
  mode.
  


mmmhhh...I know there are not a lot of examples (only one), but I pushed
the woodburn board that boots from SD Card using internal boot mode and SPL.

Best regards,
Stefano Babic

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

Re: [U-Boot] [PATCH] README: imximage: mx35 does not boot from internal mode yet

[Fabio Estevam]

On Tue, Jan 15, 2013 at 1:23 PM, Stefano Babic sba...@denx.de wrote:

 mmmhhh...I know there are not a lot of examples (only one), but I pushed
 the woodburn board that boots from SD Card using internal boot mode and SPL.

Ok, then. I was aware of it.

Regards,

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

Re: [U-Boot] [PATCH] README: imximage: mx35 does not boot from internal mode yet

[Fabio Estevam]

On Tue, Jan 15, 2013 at 1:24 PM, Fabio Estevam feste...@gmail.com wrote:
 On Tue, Jan 15, 2013 at 1:23 PM, Stefano Babic sba...@denx.de wrote:

 mmmhhh...I know there are not a lot of examples (only one), but I pushed
 the woodburn board that boots from SD Card using internal boot mode and SPL.

 Ok, then. I was aware of it.

I meant, I wasn't aware of it ;-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 8/9] tegra: add SPI SLINK driver

[Stephen Warren]

On 01/14/2013 09:33 PM, Allen Martin wrote:
 On Mon, Jan 14, 2013 at 10:49:53AM -0800, Stephen Warren wrote:
 On 01/12/2013 09:56 AM, Simon Glass wrote:
 Hi,

 On Sat, Jan 12, 2013 at 1:07 AM, Allen Martin amar...@nvidia.com wrote:
 Add driver for tegra SPI SLINK style driver.  This controller is
 similar to the tegra20 SPI SFLASH controller.  The difference is
 that the SLINK controller is a genernal purpose SPI controller and the
 SFLASH controller is special purpose and can only talk to FLASH
 devices.  In addition there are potentially many instances of an SLINK
 controller on tegra and only a single instance of SFLASH.  Tegra20 is
 currently ths only version of tegra that instantiates an SFLASH
 controller.

 This driver supports basic PIO mode of operation and is configurable
 (CONFIG_OF_CONTROL) to be driven off devicetree bindings.  Up to 4
 devices per controller may be attached, although typically only a
 single chip select line is exposed from tegra per controller so in
 reality this is usually limited to 1.

 To enable this driver, use CONFIG_TEGRA_SLINK

 +void spi_init(void)
 +{
 +   int node = 0, i;
 +   struct tegra_spi_ctrl *ctrl;

 blank line here

 +   for (i = 0; i  CONFIG_TEGRA_SLINK_CTRLS; i++) {
 +   ctrl = spi_ctrls[i];
 +#ifdef CONFIG_OF_CONTROL
 +   node = fdtdec_next_compatible(gd-fdt_blob, node,
 + COMPAT_NVIDIA_TEGRA20_SLINK);
 +   if (!node)
 +   break;

 I think you should be using fdtdec_find_aliases_for_id() so that aliases 
 work.

 I strongly believe we shouldn't be using aliases for enumeration, which
 is what fdtdec_find_aliases_for_id() does, IIRC. Instead, we should
 enumerate all the devices in the correct fashion, and then apply aliases
 as a separate step if they exists. Hence, I believe it's not correct to
 use fdtdec_find_aliases_for_id() anywhere.
 
 I'm a bit confused about the usage of fdt aliases in u-boot.  My
 understanding of aliases is that they are intended to give drivers
 hints about device naming.  Since u-boot doesn't really name devices,
 what are aliases supposed to do?

Most U-Boot command use IDs to identify devices/interfaces, e.g. in
ext2load mmc 0:1, the 0 means MMC instance #0. The instance number
is parsed out from the end of the alias name.

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

Re: [U-Boot] NAND flash - bad blocks

[Scott Wood]

On 01/15/2013 05:09:16 AM, Dimitar Penev wrote:

Hi Scott,

I have tried to do some more tests on the board with the NAND chip I  
have scrub-ed


-I have done 'nand erase.chip clean'


Don't specify clean.  That will cause jffs2 cleanmarkers to be  
written.  Not all NAND chips can handle partial programming, and in any  
case it's an unnecessary variable for figuring out the bad block  
situation.



and tried to probe different nand regions
(I have 128MB RAM and 1GB NAND and I am not sure how I could dump the  
whole NAND at once)

It seems the whole NAND is 0xFF


Including OOB?


So I tend to think that nand scrub did a good think for me.


No, it didn't.  You are ignoring the problem.

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

Re: [U-Boot] [PATCH 09/10] api/api_display: use the getters for console size info

[Che-liang Chiou]

Acked-by: Che-Liang Chiou clch...@chromium.org

On Sat, Jan 12, 2013 at 2:07 PM, Jeroen Hofstee jer...@myspectrum.nl wrote:
 cc: Che-Liang Chiou clch...@chromium.org
 Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl
 ---
  api/api_display.c |4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/api/api_display.c b/api/api_display.c
 index 6439170..c167db7 100644
 --- a/api/api_display.c
 +++ b/api/api_display.c
 @@ -45,8 +45,8 @@ int display_get_info(int type, struct display_info *di)
 case DISPLAY_TYPE_LCD:
 di-pixel_width  = panel_info.vl_col;
 di-pixel_height = panel_info.vl_row;
 -   di-screen_rows = CONSOLE_ROWS;
 -   di-screen_cols = CONSOLE_COLS;
 +   di-screen_rows = lcd_get_screen_rows();
 +   di-screen_cols = lcd_get_screen_columns();
 break;
  #endif
 }
 --
 1.7.9.5

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

Re: [U-Boot] Googlers please reply: commiters in U-Boot

[Che-liang Chiou]

I work for Google and my patches signed by clch...@chromium.org come
from me while I work for Google.

On Sat, Jan 12, 2013 at 9:20 AM, Simon Glass s...@chromium.org wrote:
 Hi,

 You are being copied because you have written U-Boot code which is now
 in mainline.

 The chromium.org domain does not automatically attribute U-Boot
 commits by company. Each author needs to be manually added to the list
 and this can only be done if you confirm your employer.

 So, if you are on the CC list and work at Google, please reply-all
 with a quick email stating this (without top posting).

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

[U-Boot] [U-Boot-Users] standalone code

[Diego Preciado Barón]

Hello,

I want to use the u-boot drivers such as gpio and spi on a standalone 
application. What do I need to modify in the Makefile to build and link my code 
with the rest of the U-boot code in order to include those drivers in my 
application? because when I try to compile my code, it shows some errors of 
undefined references.
Is it possible to run that application automatically when the u-boot starts? 
maybe from the SD card?

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

Re: [U-Boot] [PATCH V2] MPC8308: Fixup clocks in PCI Host configuration

[Ira W. Snyder]

On Mon, Jan 14, 2013 at 06:59:59PM -0600, Kim Phillips wrote:
 On Tue, 8 Jan 2013 18:25:11 -0800
 Barry Grussling ba...@grussling.com wrote:
 
  While trying to bring up a custom MPC8308 based board I found
  that the clocking was wrong.  The comment in
  include/configs/mpc8308_p1m.h led me to believe
  setting HRCWH_PCI_HOST and HRCWH_PCI1_ARBITER_ENABLE in the
  CONFIG_SYS_HRCW_HIGH should allow the system to work, but on
  my newer version of the 8308 this is not working.  Setting
  the HRCWH_PCI_HOST bit (which doesn't exist according to the manual)
  doesn't latch, and as such the im-reset.rcwh  HRCWH_PCI_HOST test
  in speed.c fails.  Since this board is running off the
  CONFIG_83XX_CLKIN and is not a PCI client, I end up with 0xdeadbeef
  and hosed clock values.
  
  This patch allows for proper clocks on the 8308 as a workaround
  for the lack of HRCWH_PCI_HOST support.
  
  Signed-off-by: Barry Grussling ba...@grussling.com
  
  ---
 
 can I get an ack from someone else with an 8308 here please?  This
 custom board fix has the possibility of bricking all existing
 8308 based mainline boards.
 
 Thanks,
 
 Kim
 

Hi Kim, Barry,

I have an MPC8308RDB board, which is reported by U-Boot as:
CPU:   e300c3, MPC8308, Rev: 1.0 at 400 MHz, CSB: 133.333 MHz
Board: Freescale MPC8308RDB Rev 1.0

Barry: what does your board report as it boots up? Is it a newer version
of the MPC8308 chip? Can you also dump the registers shown below? Use
md e900 4 to dump them. Also, please send me the output of
hexdump -C u-boot.bin | head for your U-Boot image.

Dumping the HRCWH register, I get the value a0606c00.
= md e900 4
e900: 4406 a0606c00  D`l.

So on my board, the HRCWH_PCI_HOST bit *is* latched just fine. The
Freescale manual says the HRCWH register doesn't have this bit, but the
comments in include/configs/MPC8308RDB.h say that it must be set for the
board to work correctly.

The MPC8308RDB is a standalone board, and does not define
CONFIG_83XX_PCICLK. Since the HRCWH_PCI_HOST bit was latched, my U-Boot
takes the first branch in the if (im-reset.rcwh  HRCWH_PCI_HOST) {
path, and continues to work as normal.

In conclusion, the patch doesn't break my board. But I don't know why
Barry's board needs the patch.

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

Re: [U-Boot] [U-Boot-Users] standalone code

[Wolfgang Denk]

Dear Diego Preciado Barón,

In message bay170-w1374704b4379134e5d85c32c8...@phx.gbl you wrote:

 I want to use the u-boot drivers such as gpio and spi on a standalone
 application.

Why do you want to do this from a standalone app, instead from code
linked with the U-Boot image?

 What do I need to modify in the Makefile to build and
 link my code with the rest of the U-boot code in order to include
 those drivers in my application? because when I try to compile my
 code, it shows some errors of undefined references.

You can of course link statically against U-Boot, but then you lose
all kind of compatibility, i. e. your app will oly run with this very
U-Boot image, and will crash in all kinds of horrible ways when you
attempt to run it in other environments.

In theory we could of course extend the list of exported functions,
but this is something we don't want, as this would weaken the GPL
nature of the code.

 Is it possible to run that application automatically when the u-boot
 starts? maybe from the SD card?

Yes, of course - you can run any command or command sequence
automatically, either as part of your preboot settings, or as bootcmd.

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 shortest unit of time in the multiverse is the News York  Second,
defined  as  the  period  of  time between the traffic lights turning
green and the cab behind you honking.
- Terry Pratchett, _Lords and Ladies_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [STATUS] v2013.01 released

[Tom Rini]

Hey all,

U-Boot v2013.01 has been released and uploaded to git.  I expect to see
it on the ftp server soon.

The merge window is now open until February 9th and the next release,
v2013.04 is scheduled for release on April 15th 2013 (the wiki is a bit
off right now).

We'll wait for Wolfgang to run the stats tool, but until then, looking
over the git log I see:
- Lots of cleanups everywhere, once again.
- A big serial cleanup
- Initial support for running sparse on our codebase
- Environment cleanups and support for value validation.
- Further clean-ups and enhancements to our SPL framework and another
  platform now implements support for direct booting of Linux (and
  bypassing full U-Boot).
- Improved support for a number of platforms on almost all arches that
  we support.

Thanks for all of your hard work everyone!

-- 
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] Flash Not Erased Problem with M29W128GL

[Angelo Dureghello]

Dear Ramesh,

this issue could be connected to a patch i recently posted to the 
list, where the erase command is now allowed to be customizable for 
CFI AMD compatible chips only.

Are you using board_flash_get_legacy in your board files ?

If yes, could you just add after line 1834 in cfi_flash.c

info-cmd_reset = AMD_CMD_RESET;
+   info-cmd_erase_sector = AMD_CMD_ERASE_SECTOR;

And report back if erasing now works ?

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

Re: [U-Boot] [PATCH 06/10] common/lcd.c: remove global lcd_base

[Bo Shen]

On 1/13/2013 6:07, Jeroen Hofstee wrote:

lcd_base is available as gd-fb_base as well, there is no need
to keep a seperate copy.

Cc: Alessandro Rubini rub...@unipv.it
Cc: Anatolij Gustschin ag...@denx.de
Cc: Bo Shen voice.s...@atmel.com
Cc: Haavard Skinnemoen haavard.skinnem...@atmel.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Marek Vasut marek.va...@gmail.com
Cc: Minkyu Kang mk7.k...@samsung.com
Cc: Nikita Kiryanov nik...@compulab.co.il
Cc: Simon Glass s...@chromium.org
Cc: Stelian Pop stel...@popies.net
Cc: Tom Warren twar...@nvidia.com
Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl
---
  board/mcc200/lcd.c   |8 ++--
  common/lcd.c |1 +
  drivers/video/atmel_hlcdfb.c |2 --
  drivers/video/atmel_lcdfb.c  |2 --
  drivers/video/exynos_fb.c|8 +++-
  drivers/video/mpc8xx_lcd.c   |   12 ++--
  drivers/video/pxa_lcd.c  |2 --
  drivers/video/tegra.c|6 +-
  include/lcd.h|5 -
  9 files changed, 9 insertions(+), 37 deletions(-)

diff --git a/board/mcc200/lcd.c b/board/mcc200/lcd.c
index caf8d8b..feded49 100644
--- a/board/mcc200/lcd.c
+++ b/board/mcc200/lcd.c
@@ -68,10 +68,6 @@ vidinfo_t panel_info = {
LCD_WIDTH, LCD_HEIGHT, LCD_BPP
  };

-/*
- * Frame buffer memory information
- */
-void *lcd_base;/* Start of framebuffer memory  */

  /*
   *  The device we use to communicate with PSoC
@@ -147,12 +143,12 @@ void lcd_enable (void)

  #if !defined(SWAPPED_LCD)
for (i=0; ifb_size; i++) {
-   serial_putc_raw_dev (PSOC_PSC, ((char *)lcd_base)[i]);
+   serial_putc_raw_dev (PSOC_PSC, ((char *)gd-fb_base)[i]);
}
  #else
  {
int x, y, pwidth;
-   char *p = (char *)lcd_base;
+   char *p = (char *)gd-fb_base;

pwidth = ((panel_info.vl_col+7)  3);
for (y=0; ypanel_info.vl_row; y++) {
diff --git a/common/lcd.c b/common/lcd.c
index d3fd68d..02f4721 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -107,6 +107,7 @@ static short console_col;
  static short console_row;

  static void *lcd_console_address;
+static void *lcd_base; /* Start of framebuffer memory  */

  static char lcd_flush_dcache; /* 1 to flush dcache after each lcd update */

diff --git a/drivers/video/atmel_hlcdfb.c b/drivers/video/atmel_hlcdfb.c
index 32626cf..fc95897 100644
--- a/drivers/video/atmel_hlcdfb.c
+++ b/drivers/video/atmel_hlcdfb.c
@@ -29,8 +29,6 @@
  #include lcd.h
  #include atmel_hlcdc.h

-void *lcd_base;/* Start of framebuffer memory  
*/
-
  /* configurable parameters */
  #define ATMEL_LCDC_CVAL_DEFAULT   0xc8
  #define ATMEL_LCDC_DMA_BURST_LEN  8
diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
index 370d9ca..2afeab2 100644
--- a/drivers/video/atmel_lcdfb.c
+++ b/drivers/video/atmel_lcdfb.c
@@ -29,8 +29,6 @@
  #include lcd.h
  #include atmel_lcdc.h

-void *lcd_base;/* Start of framebuffer memory  
*/
-
  /* configurable parameters */
  #define ATMEL_LCDC_CVAL_DEFAULT   0xc8
  #define ATMEL_LCDC_DMA_BURST_LEN  8


For Atmel part, it is ok for me.

Acked-by: Bo Shen voice.s...@atmel.com

Best Regards,
Bo Shen


diff --git a/drivers/video/exynos_fb.c b/drivers/video/exynos_fb.c
index 3e5f868..6f3c85d 100644
--- a/drivers/video/exynos_fb.c
+++ b/drivers/video/exynos_fb.c
@@ -33,7 +33,7 @@

  #include exynos_fb.h

-void *lcd_base;
+DECLARE_GLOBAL_DATA_PTR;

  static unsigned int panel_width, panel_height;

@@ -44,11 +44,9 @@ static void exynos_lcd_init_mem(void *lcdbase, vidinfo_t 
*vid)

fb_size = vid-vl_row * vid-vl_col * (NBITS(vid-vl_bpix)  3);

-   lcd_base = lcdbase;
-
palette_size = NBITS(vid-vl_bpix) == 8 ? 256 : 16;

-   exynos_fimd_lcd_init_mem((unsigned long)lcd_base,
+   exynos_fimd_lcd_init_mem((unsigned long)lcdbase,
(unsigned long)fb_size, palette_size);
  }

@@ -135,7 +133,7 @@ void lcd_ctrl_init(void *lcdbase)
  void lcd_enable(void)
  {
if (panel_info.logo_on) {
-   memset(lcd_base, 0, panel_width * panel_height *
+   memset((void *) gd-fb_base, 0, panel_width * panel_height *
(NBITS(panel_info.vl_bpix)  3));
draw_logo();
}
diff --git a/drivers/video/mpc8xx_lcd.c b/drivers/video/mpc8xx_lcd.c
index 26ad432..1aa1967 100644
--- a/drivers/video/mpc8xx_lcd.c
+++ b/drivers/video/mpc8xx_lcd.c
@@ -255,14 +255,6 @@ vidinfo_t panel_info = {
  #endif
  /*--*/

-
-/*
- * Frame buffer memory information
- */
-void *lcd_base;/* Start of framebuffer memory  */
-
-//
-
  void lcd_ctrl_init (void *lcdbase);
  void lcd_enable (void);
  #if LCD_BPP == LCD_COLOR8
@@ -392,8 +384,8 @@ void 

Re: [U-Boot] [PATCH 05/10] common/lcd.c: cleanup use of global variables

[Bo Shen]

On 1/13/2013 6:07, Jeroen Hofstee wrote:

console_col, console_row, lcd_line_length, lcd_console_address had
to be declared in board / driver specific code, but were not actually
used there. Get rid of the global variables.

Cc: Alessandro Rubini rub...@unipv.it
Cc: Anatolij Gustschin ag...@denx.de
Cc: Bo Shen voice.s...@atmel.com
Cc: Haavard Skinnemoen haavard.skinnem...@atmel.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Marek Vasut marek.va...@gmail.com
Cc: Minkyu Kang mk7.k...@samsung.com
Cc: Nikita Kiryanov nik...@compulab.co.il
Cc: Simon Glass s...@chromium.org
Cc: Stelian Pop stel...@popies.net
Cc: Tom Warren twar...@nvidia.com
Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl
---
  board/mcc200/lcd.c   |6 --
  common/lcd.c |6 ++
  drivers/video/atmel_hlcdfb.c |6 --
  drivers/video/atmel_lcdfb.c  |6 --
  drivers/video/exynos_fb.c|6 --
  drivers/video/mpc8xx_lcd.c   |6 --
  drivers/video/pxa_lcd.c  |6 --
  drivers/video/tegra.c|6 --
  include/lcd.h|5 -
  9 files changed, 6 insertions(+), 47 deletions(-)

diff --git a/board/mcc200/lcd.c b/board/mcc200/lcd.c
index 0f3f585..caf8d8b 100644
--- a/board/mcc200/lcd.c
+++ b/board/mcc200/lcd.c
@@ -68,16 +68,10 @@ vidinfo_t panel_info = {
LCD_WIDTH, LCD_HEIGHT, LCD_BPP
  };

-int lcd_line_length;
-
  /*
   * Frame buffer memory information
   */
  void *lcd_base;   /* Start of framebuffer memory  */
-void *lcd_console_address; /* Start of console buffer  */
-
-short console_col = 0;
-short console_row = 0;

  /*
   *  The device we use to communicate with PSoC
diff --git a/common/lcd.c b/common/lcd.c
index b67724e..d3fd68d 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -99,9 +99,15 @@ static void lcd_setbgcolor(int color);

  static int lcd_color_fg;
  static int lcd_color_bg;
+static int lcd_line_length;

  char lcd_is_enabled = 0;

+static short console_col;
+static short console_row;
+
+static void *lcd_console_address;
+
  static char lcd_flush_dcache; /* 1 to flush dcache after each lcd update */


diff --git a/drivers/video/atmel_hlcdfb.c b/drivers/video/atmel_hlcdfb.c
index e74eb65..32626cf 100644
--- a/drivers/video/atmel_hlcdfb.c
+++ b/drivers/video/atmel_hlcdfb.c
@@ -29,13 +29,7 @@
  #include lcd.h
  #include atmel_hlcdc.h

-int lcd_line_length;
-
  void *lcd_base;   /* Start of framebuffer memory  
*/
-void *lcd_console_address; /* Start of console buffer  */
-
-short console_col;
-short console_row;

  /* configurable parameters */
  #define ATMEL_LCDC_CVAL_DEFAULT   0xc8
diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
index d96f175..370d9ca 100644
--- a/drivers/video/atmel_lcdfb.c
+++ b/drivers/video/atmel_lcdfb.c
@@ -29,13 +29,7 @@
  #include lcd.h
  #include atmel_lcdc.h

-int lcd_line_length;
-
  void *lcd_base;   /* Start of framebuffer memory  
*/
-void *lcd_console_address; /* Start of console buffer  */
-
-short console_col;
-short console_row;

  /* configurable parameters */
  #define ATMEL_LCDC_CVAL_DEFAULT   0xc8


For Atmel part, it is ok for me.

Acked-by: Bo Shen voice.s...@atmel.com

Best Regards,
Bo Shen


diff --git a/drivers/video/exynos_fb.c b/drivers/video/exynos_fb.c
index 3dd6100..3e5f868 100644
--- a/drivers/video/exynos_fb.c
+++ b/drivers/video/exynos_fb.c
@@ -33,13 +33,7 @@

  #include exynos_fb.h

-int lcd_line_length;
-
  void *lcd_base;
-void *lcd_console_address;
-
-short console_col;
-short console_row;

  static unsigned int panel_width, panel_height;

diff --git a/drivers/video/mpc8xx_lcd.c b/drivers/video/mpc8xx_lcd.c
index 4fd44ac..26ad432 100644
--- a/drivers/video/mpc8xx_lcd.c
+++ b/drivers/video/mpc8xx_lcd.c
@@ -256,16 +256,10 @@ vidinfo_t panel_info = {
  /*--*/


-int lcd_line_length;
-
  /*
   * Frame buffer memory information
   */
  void *lcd_base;   /* Start of framebuffer memory  */
-void *lcd_console_address; /* Start of console buffer  */
-
-short console_col;
-short console_row;

  //

diff --git a/drivers/video/pxa_lcd.c b/drivers/video/pxa_lcd.c
index 25747b1..57243ce 100644
--- a/drivers/video/pxa_lcd.c
+++ b/drivers/video/pxa_lcd.c
@@ -332,13 +332,7 @@ void lcd_getcolreg (ushort regno, ushort *red, ushort 
*green, ushort *blue);
  void lcd_ctrl_init(void *lcdbase);
  void lcd_enable   (void);

-int lcd_line_length;
-
  void *lcd_base;   /* Start of framebuffer memory  */
-void *lcd_console_address; /* Start of console buffer  */
-
-short console_col;
-short console_row;

  static int pxafb_init_mem (void *lcdbase, vidinfo_t *vid);
  static void pxafb_setup_gpio (vidinfo_t *vid);
diff 

[U-Boot] [PATCH] tegra: fdt: remove clocks nodes

[Allen Martin]

These nodes are unused.

Signed-off-by: Allen Martin amar...@nvidia.com
---
 arch/arm/dts/tegra20.dtsi|   10 --
 arch/arm/dts/tegra30.dtsi|   10 --
 board/compulab/dts/tegra20-trimslice.dts |9 -
 board/nvidia/dts/tegra20-harmony.dts |9 -
 board/nvidia/dts/tegra20-seaboard.dts|6 --
 board/nvidia/dts/tegra20-ventana.dts |9 -
 board/nvidia/dts/tegra20-whistler.dts|6 --
 board/nvidia/dts/tegra30-cardhu.dts  |9 -
 8 files changed, 68 deletions(-)

diff --git a/arch/arm/dts/tegra20.dtsi b/arch/arm/dts/tegra20.dtsi
index 636ec2c..cc086b1 100644
--- a/arch/arm/dts/tegra20.dtsi
+++ b/arch/arm/dts/tegra20.dtsi
@@ -10,16 +10,6 @@
#clock-cells = 1;
};
 
-   clocks {
-   #address-cells = 1;
-   #size-cells = 0;
-
-   osc: clock {
-   compatible = fixed-clock;
-   #clock-cells = 0;
-   };
-   };
-
intc: interrupt-controller@50041000 {
compatible = nvidia,tegra20-gic;
interrupt-controller;
diff --git a/arch/arm/dts/tegra30.dtsi b/arch/arm/dts/tegra30.dtsi
index 664c397..09bdb36 100644
--- a/arch/arm/dts/tegra30.dtsi
+++ b/arch/arm/dts/tegra30.dtsi
@@ -9,16 +9,6 @@
#clock-cells = 1;
};
 
-   clocks {
-   #address-cells = 1;
-   #size-cells = 0;
-
-   osc: clock {
-   compatible = fixed-clock;
-   #clock-cells = 0;
-   };
-   };
-
i2c@7000c000 {
#address-cells = 1;
#size-cells = 0;
diff --git a/board/compulab/dts/tegra20-trimslice.dts 
b/board/compulab/dts/tegra20-trimslice.dts
index 4450674..92e3e0f 100644
--- a/board/compulab/dts/tegra20-trimslice.dts
+++ b/board/compulab/dts/tegra20-trimslice.dts
@@ -15,15 +15,6 @@
reg = 0x 0x4000;
};
 
-   clocks {
-   clk_32k: clk_32k {
-   clock-frequency = 32000;
-   };
-   osc {
-   clock-frequency = 1200;
-   };
-   };
-
clock@60006000 {
clocks = clk_32k osc;
};
diff --git a/board/nvidia/dts/tegra20-harmony.dts 
b/board/nvidia/dts/tegra20-harmony.dts
index 5645a8d..332ace1 100644
--- a/board/nvidia/dts/tegra20-harmony.dts
+++ b/board/nvidia/dts/tegra20-harmony.dts
@@ -15,15 +15,6 @@
reg = 0x 0x4000;
};
 
-   clocks {
-   clk_32k: clk_32k {
-   clock-frequency = 32000;
-   };
-   osc {
-   clock-frequency = 1200;
-   };
-   };
-
clock@60006000 {
clocks = clk_32k osc;
};
diff --git a/board/nvidia/dts/tegra20-seaboard.dts 
b/board/nvidia/dts/tegra20-seaboard.dts
index dd98ca4..2d834da 100644
--- a/board/nvidia/dts/tegra20-seaboard.dts
+++ b/board/nvidia/dts/tegra20-seaboard.dts
@@ -45,12 +45,6 @@
};
};
 
-   clocks {
-   osc {
-   clock-frequency = 1200;
-   };
-   };
-
clock@60006000 {
clocks = clk_32k osc;
};
diff --git a/board/nvidia/dts/tegra20-ventana.dts 
b/board/nvidia/dts/tegra20-ventana.dts
index 38b7b13..bbb4480 100644
--- a/board/nvidia/dts/tegra20-ventana.dts
+++ b/board/nvidia/dts/tegra20-ventana.dts
@@ -14,15 +14,6 @@
reg = 0x 0x4000;
};
 
-   clocks {
-   clk_32k: clk_32k {
-   clock-frequency = 32000;
-   };
-   osc {
-   clock-frequency = 1200;
-   };
-   };
-
clock@60006000 {
clocks = clk_32k osc;
};
diff --git a/board/nvidia/dts/tegra20-whistler.dts 
b/board/nvidia/dts/tegra20-whistler.dts
index f830cf3..3c575e6 100644
--- a/board/nvidia/dts/tegra20-whistler.dts
+++ b/board/nvidia/dts/tegra20-whistler.dts
@@ -16,12 +16,6 @@
reg =  0x 0x2000 ;
};
 
-   clocks {
-   osc {
-   clock-frequency = 1200;
-   };
-   };
-
clock@60006000 {
clocks = clk_32k osc;
};
diff --git a/board/nvidia/dts/tegra30-cardhu.dts 
b/board/nvidia/dts/tegra30-cardhu.dts
index 60b91b4..00388fa 100644
--- a/board/nvidia/dts/tegra30-cardhu.dts
+++ b/board/nvidia/dts/tegra30-cardhu.dts
@@ -20,15 +20,6 @@
reg = 0x8000 0x4000;
};
 
-   clocks {
-   clk_32k: clk_32K {
-   clock-frequency = 32768;
-   };
-   osc {
-   clock-frequency = 1200;
-   };
-   };
-
clock@60006000 {

[U-Boot] [PATCH V5 REPOST 2/7] ARM: rpi_b: use bcm2835 mbox driver to get memory size

[Stephen Warren]

The firmware running on the bcm2835 SoC's VideoCore CPU determines how
much of the system RAM is available for use by the ARM CPU. Previously,
U-Boot assumed that only 128MB was available, since this was the
smallest value configured by any public firmware. However, we can now
query the actual value at run-time from the firmware using the mbox
property protocol.

Signed-off-by: Stephen Warren swar...@wwwdotorg.org
---
v5: No change; merged patch series.
v4: No change; rebased.
v3: No change.
v2: Updated to use macros etc. added in v2 of mbox driver patch.
---
 board/raspberrypi/rpi_b/rpi_b.c |   21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/board/raspberrypi/rpi_b/rpi_b.c b/board/raspberrypi/rpi_b/rpi_b.c
index 688b0aa..3c654a1 100644
--- a/board/raspberrypi/rpi_b/rpi_b.c
+++ b/board/raspberrypi/rpi_b/rpi_b.c
@@ -15,13 +15,32 @@
  */
 
 #include common.h
+#include asm/arch/mbox.h
 #include asm/global_data.h
 
 DECLARE_GLOBAL_DATA_PTR;
 
+struct msg_get_arm_mem {
+   struct bcm2835_mbox_hdr hdr;
+   struct bcm2835_mbox_tag_get_arm_mem get_arm_mem;
+   u32 end_tag;
+};
+
 int dram_init(void)
 {
-   gd-ram_size = CONFIG_SYS_SDRAM_SIZE;
+   ALLOC_ALIGN_BUFFER(struct msg_get_arm_mem, msg, 1, 16);
+   int ret;
+
+   BCM2835_MBOX_INIT_HDR(msg);
+   BCM2835_MBOX_INIT_TAG(msg-get_arm_mem, GET_ARM_MEMORY);
+
+   ret = bcm2835_mbox_call_prop(BCM2835_MBOX_PROP_CHAN, msg-hdr);
+   if (ret) {
+   printf(bcm2835: Could not query ARM memory size\n);
+   return -1;
+   }
+
+   gd-ram_size = msg-get_arm_mem.body.resp.mem_size;
 
return 0;
 }
-- 
1.7.10.4

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

[U-Boot] [PATCH V5 REPOST 4/7] ARM: rpi_b: disable rpi_b dcache explicitly

[Stephen Warren]

There appears to be no implementation of flush_dcache_range() for
ARM1176, so explicitly disable dcache support to avoid references to
that function from the LCD core in the next patch. This was presumably
not noticed before simply because no drivers for the rpi_b were
attempting DMA.

Signed-off-by: Stephen Warren swar...@wwwdotorg.org
---
v5: No change; merged patch series.
v4: New patch.
---
 include/configs/rpi_b.h |1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/rpi_b.h b/include/configs/rpi_b.h
index cf62e45..5db31f5 100644
--- a/include/configs/rpi_b.h
+++ b/include/configs/rpi_b.h
@@ -23,6 +23,7 @@
 #define CONFIG_ARM1176
 #define CONFIG_BCM2835
 #define CONFIG_ARCH_CPU_INIT
+#define CONFIG_SYS_DCACHE_OFF
 /*
  * 2835 is a SKU in a series for which the 2708 is the first or primary SoC,
  * so 2708 has historically been used rather than a dedicated 2835 ID.
-- 
1.7.10.4

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

[U-Boot] [PATCH V5 REPOST 1/7] ARM: bcm2835: add mailbox driver

[Stephen Warren]

The BCM2835 SoC contains (at least) two CPUs; the VideoCore (a/k/a GPU)
and the ARM CPU. The ARM CPU is often thought of as the main CPU.
However, the VideoCore actually controls the initial SoC boot, and hides
much of the hardware behind a protocol. This protocol is transported
using the SoC's mailbox hardware module.

Here, we add a very simplistic driver for the mailbox module, and define
a few structures for the property messages.

Signed-off-by: Stephen Warren swar...@wwwdotorg.org
---
For some reason, none of these patches got picked up for v2013.01.

The video driver depends on new ARM/bcm2835 APIs added earlier, so it's
easiest to just merge it through the ARM tree. The patches have been ack'd
by Anatolij.

I believe the MMC driver itself doesn't depend on anything earlier, but
patch 7 which touches ARM/bcm2835 code and enables the MMC driver does depend
on the MMC driver, so it's probably easiest to just merge everything through
the ARM tree.

This series is based on v2013.01.

v5: No change; merged patch series.
v4: No change; rebased.
v3: Re-license to GPL-v2 or later.
v2:
* Added documentation to mbox.h.
* Implemented macros to set up headers and tags.
* Implemented error-checking of response bits in bcm2835_mbox_call_prop().
* Reworked tag structs based on experience writing LCD driver.
* Added a lot more video-related tag structs.
* Added debug spew and error messages to mbox.c; useful when debugging LCD.
* Removed __packed attributes from message structs.
* Removed stale FIXME comments.
---
 arch/arm/cpu/arm1176/bcm2835/Makefile|2 +-
 arch/arm/cpu/arm1176/bcm2835/mbox.c  |  164 
 arch/arm/include/asm/arch-bcm2835/mbox.h |  407 ++
 3 files changed, 572 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/cpu/arm1176/bcm2835/mbox.c
 create mode 100644 arch/arm/include/asm/arch-bcm2835/mbox.h

diff --git a/arch/arm/cpu/arm1176/bcm2835/Makefile 
b/arch/arm/cpu/arm1176/bcm2835/Makefile
index 95da6a8..135de42 100644
--- a/arch/arm/cpu/arm1176/bcm2835/Makefile
+++ b/arch/arm/cpu/arm1176/bcm2835/Makefile
@@ -17,7 +17,7 @@ include $(TOPDIR)/config.mk
 LIB= $(obj)lib$(SOC).o
 
 SOBJS  := lowlevel_init.o
-COBJS  := init.o reset.o timer.o
+COBJS  := init.o reset.o timer.o mbox.o
 
 SRCS   := $(SOBJS:.o=.c) $(COBJS:.o=.c)
 OBJS   := $(addprefix $(obj),$(SOBJS) $(COBJS))
diff --git a/arch/arm/cpu/arm1176/bcm2835/mbox.c 
b/arch/arm/cpu/arm1176/bcm2835/mbox.c
new file mode 100644
index 000..fd65e33
--- /dev/null
+++ b/arch/arm/cpu/arm1176/bcm2835/mbox.c
@@ -0,0 +1,164 @@
+/*
+ * (C) Copyright 2012 Stephen Warren
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include common.h
+#include asm/io.h
+#include asm/arch/mbox.h
+
+#define TIMEOUT (100 * 1000) /* 100mS in uS */
+
+int bcm2835_mbox_call_raw(u32 chan, u32 send, u32 *recv)
+{
+   struct bcm2835_mbox_regs *regs =
+   (struct bcm2835_mbox_regs *)BCM2835_MBOX_PHYSADDR;
+   ulong endtime = get_timer(0) + TIMEOUT;
+   u32 val;
+
+   debug(time: %lu timeout: %lu\n, get_timer(0), endtime);
+
+   if (send  BCM2835_CHAN_MASK) {
+   printf(mbox: Illegal mbox data 0x%08x\n, send);
+   return -1;
+   }
+
+   /* Drain any stale responses */
+
+   for (;;) {
+   val = readl(regs-status);
+   if (val  BCM2835_MBOX_STATUS_RD_EMPTY)
+   break;
+   if (get_timer(0) = endtime) {
+   printf(mbox: Timeout draining stale responses\n);
+   return -1;
+   }
+   val = readl(regs-read);
+   }
+
+   /* Wait for space to send */
+
+   for (;;) {
+   val = readl(regs-status);
+   if (!(val  BCM2835_MBOX_STATUS_WR_FULL))
+   break;
+   if (get_timer(0) = endtime) {
+   printf(mbox: Timeout waiting for send space\n);
+   return -1;
+   }
+   }
+
+   /* Send the request */
+
+   val = BCM2835_MBOX_PACK(chan, send);
+   debug(mbox: TX raw: 0x%08x\n, val);
+   writel(val, regs-write);
+
+   /* Wait for the response */
+
+   for (;;) {
+   val = readl(regs-status);
+   if (!(val  BCM2835_MBOX_STATUS_RD_EMPTY))
+   break;
+   if (get_timer(0) = endtime) {
+   printf(mbox: 

[U-Boot] [PATCH V5 REPOST 5/7] video: add a driver for the bcm2835

[Stephen Warren]

The firmware running on the bcm2835 SoC's VideoCore CPU manages the
display controller. Add a simple LCD driver that communicates with the
firmware using the property mailbox protocol. This configures the
display and frame-buffer to match whatever physical resolution the
firmware chosen when booting, which is typically the native resolution
of the attached display device, presumably unless otherwise specified
in config.txt on the boot media.

Enable this driver in the Raspberry Pi board configuration.

Signed-off-by: Stephen Warren swar...@wwwdotorg.org
Acked-by: Anatolij Gustschin ag...@denx.de
---
v5: No change; merged patch series.
v4: No change; rebased.
v3: Re-license to GPL-v2 or later. Fix typo in commit description.
v2: New patch.
---
 drivers/video/Makefile  |1 +
 drivers/video/bcm2835.c |  127 +++
 include/configs/rpi_b.h |   16 ++
 3 files changed, 144 insertions(+)
 create mode 100644 drivers/video/bcm2835.c

diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 170a358..e8cecca 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -40,6 +40,7 @@ COBJS-$(CONFIG_S6E63D6) += s6e63d6.o
 COBJS-$(CONFIG_LD9040) += ld9040.o
 COBJS-$(CONFIG_SED156X) += sed156x.o
 COBJS-$(CONFIG_VIDEO_AMBA) += amba.o
+COBJS-$(CONFIG_VIDEO_BCM2835) += bcm2835.o
 COBJS-$(CONFIG_VIDEO_COREBOOT) += coreboot_fb.o
 COBJS-$(CONFIG_VIDEO_CT69000) += ct69000.o videomodes.o
 COBJS-$(CONFIG_VIDEO_DA8XX) += da8xx-fb.o videomodes.o
diff --git a/drivers/video/bcm2835.c b/drivers/video/bcm2835.c
new file mode 100644
index 000..1e9a84a
--- /dev/null
+++ b/drivers/video/bcm2835.c
@@ -0,0 +1,127 @@
+/*
+ * (C) Copyright 2012 Stephen Warren
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include common.h
+#include lcd.h
+#include asm/arch/mbox.h
+#include asm/global_data.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* Global variables that lcd.c expects to exist */
+int lcd_line_length;
+int lcd_color_fg;
+int lcd_color_bg;
+void *lcd_base;
+void *lcd_console_address;
+short console_col;
+short console_row;
+vidinfo_t panel_info;
+char lcd_cursor_enabled;
+ushort lcd_cursor_width;
+ushort lcd_cursor_height;
+
+struct msg_query {
+   struct bcm2835_mbox_hdr hdr;
+   struct bcm2835_mbox_tag_physical_w_h physical_w_h;
+   u32 end_tag;
+};
+
+struct msg_setup {
+   struct bcm2835_mbox_hdr hdr;
+   struct bcm2835_mbox_tag_physical_w_h physical_w_h;
+   struct bcm2835_mbox_tag_virtual_w_h virtual_w_h;
+   struct bcm2835_mbox_tag_depth depth;
+   struct bcm2835_mbox_tag_pixel_order pixel_order;
+   struct bcm2835_mbox_tag_alpha_mode alpha_mode;
+   struct bcm2835_mbox_tag_virtual_offset virtual_offset;
+   struct bcm2835_mbox_tag_overscan overscan;
+   struct bcm2835_mbox_tag_allocate_buffer allocate_buffer;
+   u32 end_tag;
+};
+
+void lcd_ctrl_init(void *lcdbase)
+{
+   ALLOC_ALIGN_BUFFER(struct msg_query, msg_query, 1, 16);
+   ALLOC_ALIGN_BUFFER(struct msg_setup, msg_setup, 1, 16);
+   int ret;
+   u32 w, h;
+
+   debug(bcm2835: Query resolution...\n);
+
+   BCM2835_MBOX_INIT_HDR(msg_query);
+   BCM2835_MBOX_INIT_TAG_NO_REQ(msg_query-physical_w_h,
+   GET_PHYSICAL_W_H);
+   ret = bcm2835_mbox_call_prop(BCM2835_MBOX_PROP_CHAN, msg_query-hdr);
+   if (ret) {
+   printf(bcm2835: Could not query display resolution\n);
+   /* FIXME: How to disable the LCD to prevent errors? hang()? */
+   return;
+   }
+
+   w = msg_query-physical_w_h.body.resp.width;
+   h = msg_query-physical_w_h.body.resp.height;
+
+   debug(bcm2835: Setting up display for %d x %d\n, w, h);
+
+   BCM2835_MBOX_INIT_HDR(msg_setup);
+   BCM2835_MBOX_INIT_TAG(msg_setup-physical_w_h, SET_PHYSICAL_W_H);
+   msg_setup-physical_w_h.body.req.width = w;
+   msg_setup-physical_w_h.body.req.height = h;
+   BCM2835_MBOX_INIT_TAG(msg_setup-virtual_w_h, SET_VIRTUAL_W_H);
+   msg_setup-virtual_w_h.body.req.width = w;
+   msg_setup-virtual_w_h.body.req.height = h;
+   BCM2835_MBOX_INIT_TAG(msg_setup-depth, SET_DEPTH);
+   msg_setup-depth.body.req.bpp = 16;
+   BCM2835_MBOX_INIT_TAG(msg_setup-pixel_order, SET_PIXEL_ORDER);
+   msg_setup-pixel_order.body.req.order = BCM2835_MBOX_PIXEL_ORDER_BGR;
+   BCM2835_MBOX_INIT_TAG(msg_setup-alpha_mode, SET_ALPHA_MODE);

[U-Boot] [PATCH V5 REPOST 3/7] lcd: calculate line_length after lcd_ctrl_init()

[Stephen Warren]

When an LCD driver is actually driving a regular external display, e.g.
an HDMI monitor, the display resolution might not be known until the
display controller has initialized, i.e. during lcd_ctrl_init(). However,
lcd.c calculates lcd_line_length before calling this function, thus
relying on a hard-coded resolution in struct panel_info.

Instead, defer this calculation until after lcd_ctrl_init() has had the
chance to dynamically determine the resolution. This needs to happen
before lcd_clear(), since the value is used there.

grep indicates that no code outside lcd.c uses this lcd_line_length; in
particular, no lcd_ctrl_init() implementations read it.

Signed-off-by: Stephen Warren swar...@wwwdotorg.org
Acked-by: Anatolij Gustschin ag...@denx.de
--
v5: No change; merged patch series.
v4: Adjusted to addition of lcd_get_size() function. Rebased.
v3: No change.
---
 common/lcd.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/common/lcd.c b/common/lcd.c
index 66d4f94..9fa4e5c 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -384,8 +384,6 @@ int drv_lcd_init (void)
 
lcd_base = (void *)(gd-fb_base);
 
-   lcd_get_size(lcd_line_length);
-
lcd_init(lcd_base); /* LCD initialization */
 
/* Device initialization */
@@ -468,6 +466,8 @@ static int lcd_init(void *lcdbase)
debug([LCD] Initializing LCD frambuffer at %p\n, lcdbase);
 
lcd_ctrl_init(lcdbase);
+   lcd_get_size(lcd_line_length);
+   lcd_line_length = (panel_info.vl_col * NBITS(panel_info.vl_bpix)) / 8;
lcd_is_enabled = 1;
lcd_clear();
lcd_enable ();
-- 
1.7.10.4

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

[U-Boot] [PATCH V5 REPOST 7/7] ARM: rpi_b: enable SD controller, add related env/cmds

[Stephen Warren]

Enable the SD controller driver for the Raspberry Pi. Enable a number
of useful MMC, partition, and filesystem-related commands. Set up the
environment to provide standard locations for loading a kernel, DTB,
etc. Provide a boot command that loads and executes boot.scr.uimg from
the SD card; this is written considering future extensibilty to USB
storage.

Signed-off-by: Stephen Warren swar...@wwwdotorg.org
---
v5: No change.
v4:
* Merged with video patch series due to dependencies in rpi_b.h.
* Rebased onto latest u-boot-arm/master; no real changes.
v3: No such version was posted.
v2: No change.
---
 arch/arm/include/asm/arch-bcm2835/mbox.h |   26 
 board/raspberrypi/rpi_b/rpi_b.c  |   26 
 include/configs/rpi_b.h  |   68 --
 3 files changed, 117 insertions(+), 3 deletions(-)

diff --git a/arch/arm/include/asm/arch-bcm2835/mbox.h 
b/arch/arm/include/asm/arch-bcm2835/mbox.h
index 4752091..b07c4a0 100644
--- a/arch/arm/include/asm/arch-bcm2835/mbox.h
+++ b/arch/arm/include/asm/arch-bcm2835/mbox.h
@@ -144,6 +144,32 @@ struct bcm2835_mbox_tag_get_arm_mem {
} body;
 };
 
+#define BCM2835_MBOX_TAG_GET_CLOCK_RATE0x00030002
+
+#define BCM2835_MBOX_CLOCK_ID_EMMC 1
+#define BCM2835_MBOX_CLOCK_ID_UART 2
+#define BCM2835_MBOX_CLOCK_ID_ARM  3
+#define BCM2835_MBOX_CLOCK_ID_CORE 4
+#define BCM2835_MBOX_CLOCK_ID_V3D  5
+#define BCM2835_MBOX_CLOCK_ID_H264 6
+#define BCM2835_MBOX_CLOCK_ID_ISP  7
+#define BCM2835_MBOX_CLOCK_ID_SDRAM8
+#define BCM2835_MBOX_CLOCK_ID_PIXEL9
+#define BCM2835_MBOX_CLOCK_ID_PWM  10
+
+struct bcm2835_mbox_tag_get_clock_rate {
+   struct bcm2835_mbox_tag_hdr tag_hdr;
+   union {
+   struct {
+   u32 clock_id;
+   } req;
+   struct {
+   u32 clock_id;
+   u32 rate_hz;
+   } resp;
+   } body;
+};
+
 #define BCM2835_MBOX_TAG_ALLOCATE_BUFFER   0x00040001
 
 struct bcm2835_mbox_tag_allocate_buffer {
diff --git a/board/raspberrypi/rpi_b/rpi_b.c b/board/raspberrypi/rpi_b/rpi_b.c
index 3c654a1..6b3e095 100644
--- a/board/raspberrypi/rpi_b/rpi_b.c
+++ b/board/raspberrypi/rpi_b/rpi_b.c
@@ -16,6 +16,7 @@
 
 #include common.h
 #include asm/arch/mbox.h
+#include asm/arch/sdhci.h
 #include asm/global_data.h
 
 DECLARE_GLOBAL_DATA_PTR;
@@ -26,6 +27,12 @@ struct msg_get_arm_mem {
u32 end_tag;
 };
 
+struct msg_get_clock_rate {
+   struct bcm2835_mbox_hdr hdr;
+   struct bcm2835_mbox_tag_get_clock_rate get_clock_rate;
+   u32 end_tag;
+};
+
 int dram_init(void)
 {
ALLOC_ALIGN_BUFFER(struct msg_get_arm_mem, msg, 1, 16);
@@ -51,3 +58,22 @@ int board_init(void)
 
return 0;
 }
+
+int board_mmc_init(void)
+{
+   ALLOC_ALIGN_BUFFER(struct msg_get_clock_rate, msg_clk, 1, 16);
+   int ret;
+
+   BCM2835_MBOX_INIT_HDR(msg_clk);
+   BCM2835_MBOX_INIT_TAG(msg_clk-get_clock_rate, GET_CLOCK_RATE);
+   msg_clk-get_clock_rate.body.req.clock_id = BCM2835_MBOX_CLOCK_ID_EMMC;
+
+   ret = bcm2835_mbox_call_prop(BCM2835_MBOX_PROP_CHAN, msg_clk-hdr);
+   if (ret) {
+   printf(bcm2835: Could not query eMMC clock rate\n);
+   return -1;
+   }
+
+   return bcm2835_sdhci_init(BCM2835_SDHCI_BASE,
+ msg_clk-get_clock_rate.body.resp.rate_hz);
+}
diff --git a/include/configs/rpi_b.h b/include/configs/rpi_b.h
index e485a06..3d55d36 100644
--- a/include/configs/rpi_b.h
+++ b/include/configs/rpi_b.h
@@ -51,6 +51,7 @@
 #define CONFIG_SYS_MALLOC_LEN  SZ_4M
 #define CONFIG_SYS_MEMTEST_START   0x0010
 #define CONFIG_SYS_MEMTEST_END 0x0020
+#define CONFIG_LOADADDR0x0020
 
 /* Flash */
 #define CONFIG_SYS_NO_FLASH
@@ -70,6 +71,13 @@
 #define CONFIG_VIDEO_BCM2835
 #define CONFIG_SYS_WHITE_ON_BLACK
 
+/* SD/MMC configuration */
+#define CONFIG_GENERIC_MMC
+#define CONFIG_MMC
+#define CONFIG_SDHCI
+#define CONFIG_MMC_SDHCI_IO_ACCESSORS
+#define CONFIG_BCM2835_SDHCI
+
 /* Console UART */
 #define CONFIG_PL011_SERIAL
 #define CONFIG_PL011_CLOCK 300
@@ -85,12 +93,59 @@
 /* Environment */
 #define CONFIG_ENV_SIZESZ_16K
 #define CONFIG_ENV_IS_NOWHERE
+#define CONFIG_ENV_VARS_UBOOT_CONFIG
 #define CONFIG_SYS_LOAD_ADDR   0x100
 #define CONFIG_CONSOLE_MUX
 #define CONFIG_SYS_CONSOLE_IS_IN_ENV
-#define CONFIG_EXTRA_ENV_SETTINGS  stdin=serial\0 \
-   stderr=serial,lcd\0 \
-   stdout=serial,lcd\0
+/*
+ * Memory layout for where various images get loaded by boot scripts:
+ *
+ * scriptaddr can be pretty much anywhere that doesn't conflict with something
+ *   else. Put it low in memory to avoid conflicts.
+ *
+ * kernel_addr_r must be within the first 128M of RAM in order for the
+ *   kernel's 

[U-Boot] [PATCH V5 REPOST 6/7] mmc: add bcm2835 driver

[Stephen Warren]

This adds a simple driver for the BCM2835's SD controller.

Workarounds are implemented for:
* Register writes can't be too close to each-other in time, or they will
  be lost.
* Register accesses must all be 32-bit, so implement custom accessors.

This code was extracted from:
git://github.com/gonzoua/u-boot-pi.git master
which was created by Oleksandr Tymoshenko.

Portions of the code there were obviously based on the Linux kernel at:
git://github.com/raspberrypi/linux.git rpi-3.6.y
commit f5b930b Main bcm2708 linux port signed-off-by Dom Cobley.

swarren changed the following for upstream:
* Removed hack udelay()s in bcm2835_sdhci_raw_writel(); setting
  SDHCI_QUIRK_WAIT_SEND_CMD appears to solve the issues.
* Remove register logging from read*/write* functions.
* Sort out confusion with min/max_freq values passed to add_sdhci().
* Use more descriptive variable names and calculations in IO accessors.
* Simplified and commented twoticks_delay calculation.
* checkpatch fixes.

Cc: Andy Fleming aflem...@gmail.com
Signed-off-by: Oleksandr Tymoshenko go...@bluezbox.com
Signed-off-by: Stephen Warren swar...@wwwdotorg.org
---
Andy, could you please ack this so Albert can take it through the ARM tree;
patch 7/7 depends is an ARM patch and depends on this. Thanks.

v5: Invent struct bcm2835_sdhci_host to avoid static/global variables.
v4:
* Merged with video patch series due to dependencies in rpi_b.h.
* Rebased onto latest u-boot-arm/master; no real changes.
v3: No such version was posted.
v2:
* Use more descriptive variable names and calculations in IO accessors.
* Add Oleksandr's S-o-b.
* Rewrite commit description to note that the Linux code this was derived
  from was S-o-b Dom Cobley.
---
 arch/arm/include/asm/arch-bcm2835/sdhci.h |   24 
 drivers/mmc/Makefile  |1 +
 drivers/mmc/bcm2835_sdhci.c   |  189 +
 3 files changed, 214 insertions(+)
 create mode 100644 arch/arm/include/asm/arch-bcm2835/sdhci.h
 create mode 100644 drivers/mmc/bcm2835_sdhci.c

diff --git a/arch/arm/include/asm/arch-bcm2835/sdhci.h 
b/arch/arm/include/asm/arch-bcm2835/sdhci.h
new file mode 100644
index 000..a4f867b
--- /dev/null
+++ b/arch/arm/include/asm/arch-bcm2835/sdhci.h
@@ -0,0 +1,24 @@
+/*
+ * (C) Copyright 2012 Stephen Warren
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef _BCM2835_SDHCI_H_
+#define _BCM2835_SDHCI_H_
+
+#define BCM2835_SDHCI_BASE 0x2030
+
+int bcm2835_sdhci_init(u32 regbase, u32 emmc_freq);
+
+#endif
diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
index 65791aa..1d6faa2 100644
--- a/drivers/mmc/Makefile
+++ b/drivers/mmc/Makefile
@@ -43,6 +43,7 @@ COBJS-$(CONFIG_MXS_MMC) += mxsmmc.o
 COBJS-$(CONFIG_OMAP_HSMMC) += omap_hsmmc.o
 COBJS-$(CONFIG_PXA_MMC_GENERIC) += pxa_mmc_gen.o
 COBJS-$(CONFIG_SDHCI) += sdhci.o
+COBJS-$(CONFIG_BCM2835_SDHCI) += bcm2835_sdhci.o
 COBJS-$(CONFIG_S5P_SDHCI) += s5p_sdhci.o
 COBJS-$(CONFIG_SH_MMCIF) += sh_mmcif.o
 COBJS-$(CONFIG_TEGRA_MMC) += tegra_mmc.o
diff --git a/drivers/mmc/bcm2835_sdhci.c b/drivers/mmc/bcm2835_sdhci.c
new file mode 100644
index 000..b0afc3c
--- /dev/null
+++ b/drivers/mmc/bcm2835_sdhci.c
@@ -0,0 +1,189 @@
+/*
+ * This code was extracted from:
+ * git://github.com/gonzoua/u-boot-pi.git master
+ * and hence presumably (C) 2012 Oleksandr Tymoshenko
+ *
+ * Tweaks for U-Boot upstreaming
+ * (C) 2012 Stephen Warren
+ *
+ * Portions (e.g. read/write macros, concepts for back-to-back register write
+ * timing workarounds) obviously extracted from the Linux kernel at:
+ * https://github.com/raspberrypi/linux.git rpi-3.6.y
+ *
+ * The Linux kernel code has the following (c) and license, which is hence
+ * propagated to Oleksandr's tree and here:
+ *
+ * Support for SDHCI device on 2835
+ * Based on sdhci-bcm2708.c (c) 2010 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+/* Supports:
+ * 

[U-Boot] [PATCH 2/3] powerpc/p5040: enable SD boot support

[Shaohui Xie]

Signed-off-by: Shaohui Xie shaohui@freescale.com
---
 boards.cfg |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/boards.cfg b/boards.cfg
index 8cf4936..314afa2 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -856,6 +856,7 @@ P5020DS_SPIFLASH powerpc mpc85xx corenet_ds 
 freescale
 P5020DS_SRIO_PCIE_BOOT  powerpc mpc85xx corenet_ds  
freescale  -   P5020DS:SRIO_PCIE_BOOT_SLAVE,SYS_TEXT_BASE=0xFFF8
 P5040DS  powerpc mpc85xx corenet_ds  
freescale
 P5040DS_NANDpowerpc mpc85xx corenet_ds  
freescale  -   P5040DS:RAMBOOT_PBL,NAND,SYS_TEXT_BASE=0xFFF8
+P5040DS_SDCARD  powerpc mpc85xx corenet_ds  
freescale  -   P5040DS:RAMBOOT_PBL,SDCARD,SYS_TEXT_BASE=0xFFF8
 BSC9131RDB_SPIFLASH  powerpc mpc85xx bsc9131rdb  
freescale  -   BSC9131RDB:BSC9131RDB,SPIFLASH
 stxgp3   powerpc mpc85xx stxgp3  stx
 stxssa   powerpc mpc85xx stxssa  stx   
 -   stxssa
-- 
1.6.4


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

[U-Boot] [PATCH 1/3] powerpc/p5040: enable NAND boot support

[Shaohui Xie]

Signed-off-by: Shaohui Xie shaohui@freescale.com
---
 boards.cfg |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/boards.cfg b/boards.cfg
index e4b0d44..8cf4936 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -855,6 +855,7 @@ P5020DS_SECURE_BOOT  powerpc mpc85xx 
corenet_ds  freesca
 P5020DS_SPIFLASHpowerpc mpc85xx corenet_ds  
freescale  -   P5020DS:RAMBOOT_PBL,SPIFLASH,SYS_TEXT_BASE=0xFFF8
 P5020DS_SRIO_PCIE_BOOT  powerpc mpc85xx corenet_ds  
freescale  -   P5020DS:SRIO_PCIE_BOOT_SLAVE,SYS_TEXT_BASE=0xFFF8
 P5040DS  powerpc mpc85xx corenet_ds  
freescale
+P5040DS_NANDpowerpc mpc85xx corenet_ds  
freescale  -   P5040DS:RAMBOOT_PBL,NAND,SYS_TEXT_BASE=0xFFF8
 BSC9131RDB_SPIFLASH  powerpc mpc85xx bsc9131rdb  
freescale  -   BSC9131RDB:BSC9131RDB,SPIFLASH
 stxgp3   powerpc mpc85xx stxgp3  stx
 stxssa   powerpc mpc85xx stxssa  stx   
 -   stxssa
-- 
1.6.4


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

[U-Boot] [PATCH 3/3] powerpc/p5040: enable SPI boot support

[Shaohui Xie]

Signed-off-by: Shaohui Xie shaohui@freescale.com
---
 boards.cfg |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/boards.cfg b/boards.cfg
index 314afa2..710942f 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -857,6 +857,7 @@ P5020DS_SRIO_PCIE_BOOT  powerpc mpc85xx 
corenet_ds  free
 P5040DS  powerpc mpc85xx corenet_ds  
freescale
 P5040DS_NANDpowerpc mpc85xx corenet_ds  
freescale  -   P5040DS:RAMBOOT_PBL,NAND,SYS_TEXT_BASE=0xFFF8
 P5040DS_SDCARD  powerpc mpc85xx corenet_ds  
freescale  -   P5040DS:RAMBOOT_PBL,SDCARD,SYS_TEXT_BASE=0xFFF8
+P5040DS_SPIFLASHpowerpc mpc85xx corenet_ds  
freescale  -   P5040DS:RAMBOOT_PBL,SPIFLASH,SYS_TEXT_BASE=0xFFF8
 BSC9131RDB_SPIFLASH  powerpc mpc85xx bsc9131rdb  
freescale  -   BSC9131RDB:BSC9131RDB,SPIFLASH
 stxgp3   powerpc mpc85xx stxgp3  stx
 stxssa   powerpc mpc85xx stxssa  stx   
 -   stxssa
-- 
1.6.4


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

[U-Boot] Function prototype conflicts with standalone apps

[Chris Packham]

Hi,

I've just run into something porting an existing out of tree board to
u-boot 2012.10 but I think it points to a generic issue for standalone
applications.

Consider the following change

diff --git a/examples/standalone/hello_world.c
b/examples/standalone/hello_world.c
index 067c390..d2e6a77 100644
--- a/examples/standalone/hello_world.c
+++ b/examples/standalone/hello_world.c
@@ -24,7 +24,7 @@
 #include common.h
 #include exports.h

-int hello_world (int argc, char * const argv[])
+int net_init (int argc, char * const argv[])
 {
int i;

Because I'm not linking with the u-boot object file, I should be able to
use any function name I like in my application as long as it isn't one of
the functions in exports.h (at least in theory). Unfortunately I end up
with the following compiler error

  hello_world.c:27: error: conflicting types for ‘net_init’
  uboot/include/net.h:489: error: previous declaration of ‘net_init’ was
here
  make[1]: *** [hello_world.o] Error 1

If I replace #include common.h in my app with the first hunk of includes
from the top of common.h  then I can compile just fine.

I was wondering if it made sense to people to have standalone applications
define something like __STANDALONE__ either via CPPFLAGS or in the source
itself and use the presence of that to exclude the majority of common.h
when used in standalone applications. Or alternatively move the required
bits to exports.h.

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

Re: [U-Boot] Function prototype conflicts with standalone apps

[Chris Packham]

Here is a patch for the latter option

---8---

From ece309850996e2347c54a9874dee5cc67e673402 Mon Sep 17 00:00:00 2001
From: Chris Packham judge.pack...@gmail.com
Date: Wed, 16 Jan 2013 17:36:05 +1300
Subject: [PATCH] exports.h: add required definitions from common.h

To avoid symbol namespace conflicts between standalone applications and
u-boot code add the definitions required in exports.h so standalone
applications do not have to include common.h.
---
 examples/standalone/hello_world.c |1 -
 include/exports.h |   15 +++
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/examples/standalone/hello_world.c
b/examples/standalone/hello_world.c
index 067c390..91a2deb 100644
--- a/examples/standalone/hello_world.c
+++ b/examples/standalone/hello_world.c
@@ -21,7 +21,6 @@
  * MA 02111-1307 USA
  */

-#include common.h
 #include exports.h

 int hello_world (int argc, char * const argv[])
diff --git a/include/exports.h b/include/exports.h
index 63aa4b2..65b25a1 100644
--- a/include/exports.h
+++ b/include/exports.h
@@ -3,6 +3,21 @@

 #ifndef __ASSEMBLY__

+#ifndef __COMMON_H_
+typedef unsigned char   uchar;
+typedef volatile unsigned long  vu_long;
+typedef volatile unsigned short vu_short;
+typedef volatile unsigned char  vu_char;
+
+#include config.h
+#include asm-offsets.h
+#include linux/bitops.h
+#include linux/types.h
+#include linux/string.h
+#include asm/ptrace.h
+#include stdarg.h
+#endif /* ifndef __COMMON_H__ */
+
 /* These are declarations of exported functions available in C code */
 unsigned long get_version(void);
 int  getc(void);
-- 
1.7.10.2.dirty




On Wed, Jan 16, 2013 at 5:23 PM, Chris Packham judge.pack...@gmail.comwrote:

 Hi,

 I've just run into something porting an existing out of tree board to
 u-boot 2012.10 but I think it points to a generic issue for standalone
 applications.

 Consider the following change

 diff --git a/examples/standalone/hello_world.c
 b/examples/standalone/hello_world.c
 index 067c390..d2e6a77 100644
 --- a/examples/standalone/hello_world.c
 +++ b/examples/standalone/hello_world.c
 @@ -24,7 +24,7 @@
  #include common.h
  #include exports.h

 -int hello_world (int argc, char * const argv[])
 +int net_init (int argc, char * const argv[])
  {
 int i;

 Because I'm not linking with the u-boot object file, I should be able to
 use any function name I like in my application as long as it isn't one of
 the functions in exports.h (at least in theory). Unfortunately I end up
 with the following compiler error

   hello_world.c:27: error: conflicting types for ‘net_init’
   uboot/include/net.h:489: error: previous declaration of ‘net_init’ was
 here
   make[1]: *** [hello_world.o] Error 1

 If I replace #include common.h in my app with the first hunk of includes
 from the top of common.h  then I can compile just fine.

 I was wondering if it made sense to people to have standalone applications
 define something like __STANDALONE__ either via CPPFLAGS or in the source
 itself and use the presence of that to exclude the majority of common.h
 when used in standalone applications. Or alternatively move the required
 bits to exports.h.

 Thanks,
 Chris


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

Re: [U-Boot] Flash Not Erased Problem with M29W128GL

[Ramesh K Khokhani]

Thank you so much Angelo,

I am not using board_flash_get_legacy in my board.

In then function flash_erase() there is one function for flash_write_cfiword() 
in that there is one check for if flash is erased or not. In that code there is 
one reading of byte and it returns 0x00. so that is problem. Following is the 
line here, in that flag gets 0 and this function returns ERR_NOT_ERASED.

case FLASH_CFI_8BIT:
flag = ((flash_read8(dstaddr)  cword.c) == cword.c);
break;

static int flash_write_cfiword (flash_info_t * info, ulong dest,
cfiword_t cword)
{
void *dstaddr = (void *)dest;
int flag;
flash_sect_t sect = 0;
char sect_found = 0;

/* Check if Flash is (sufficiently) erased */
switch (info-portwidth) {
case FLASH_CFI_8BIT:
flag = ((flash_read8(dstaddr)  cword.c) == cword.c);
break;
case FLASH_CFI_16BIT:
flag = ((flash_read16(dstaddr)  cword.w) == cword.w);
break;
case FLASH_CFI_32BIT:
flag = ((flash_read32(dstaddr)  cword.l) == cword.l);
break;
case FLASH_CFI_64BIT:
flag = ((flash_read64(dstaddr)  cword.ll) == cword.ll);
break;
default:
flag = 0;
break;
}
if (!flag)
return ERR_NOT_ERASED;

Thanks  Warm Regards,
Ramesh

-Original Message-
From: Angelo Dureghello [mailto:sysa...@gmail.com] 
Sent: Wednesday, January 16, 2013 5:09 AM
To: u-boot@lists.denx.de
Cc: Ramesh K Khokhani
Subject: Re: [U-Boot] Flash Not Erased Problem with M29W128GL

Dear Ramesh,

this issue could be connected to a patch i recently posted to the 
list, where the erase command is now allowed to be customizable for 
CFI AMD compatible chips only.

Are you using board_flash_get_legacy in your board files ?

If yes, could you just add after line 1834 in cfi_flash.c

info-cmd_reset = AMD_CMD_RESET;
+   info-cmd_erase_sector = AMD_CMD_ERASE_SECTOR;

And report back if erasing now works ?

Many Thanks,
Angelo Dureghello

~~Disclaimer~~~
Information contained and transmitted by this e-mail is confidential and 
proprietary to iGATE and its affiliates and is intended for use only by the 
recipient. If you are not the intended recipient, you are hereby notified that 
any dissemination, distribution, copying or use of this e-mail is strictly 
prohibited and you are requested to delete this e-mail immediately and notify 
the originator or mailad...@igate.com mailto:mailad...@igate.com. iGATE does 
not enter into any agreement with any party by e-mail. Any views expressed by 
an individual do not necessarily reflect the view of iGATE. iGATE is not 
responsible for the consequences of any actions taken on the basis of 
information provided, through this email. The contents of an attachment to this 
e-mail may contain software viruses, which could damage your own computer 
system. While iGATE has taken every reasonable precaution to minimise this 
risk, we cannot accept liability for any damage which you sustain as a result of
  software viruses. You should carry out your own virus checks before opening 
an attachment. To know more about iGATE please visit www.igate.com 
http://www.igate.com.


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

Re: [U-Boot] Function prototype conflicts with standalone apps

[U-Boot]

Hi Chris,

On Wed, 16 Jan 2013 17:23:58 +1300, Chris Packham
judge.pack...@gmail.com wrote:

 Hi,
 
 I've just run into something porting an existing out of tree board to
 u-boot 2012.10 but I think it points to a generic issue for standalone
 applications.
 
 Consider the following change
 
 diff --git a/examples/standalone/hello_world.c
 b/examples/standalone/hello_world.c
 index 067c390..d2e6a77 100644
 --- a/examples/standalone/hello_world.c
 +++ b/examples/standalone/hello_world.c
 @@ -24,7 +24,7 @@
  #include common.h
  #include exports.h
 
 -int hello_world (int argc, char * const argv[])
 +int net_init (int argc, char * const argv[])
  {
 int i;
 
 Because I'm not linking with the u-boot object file, I should be able to
 use any function name I like in my application as long as it isn't one of
 the functions in exports.h (at least in theory). Unfortunately I end up
 with the following compiler error
 
   hello_world.c:27: error: conflicting types for ‘net_init’
   uboot/include/net.h:489: error: previous declaration of ‘net_init’ was
 here
   make[1]: *** [hello_world.o] Error 1
 
 If I replace #include common.h in my app with the first hunk of includes
 from the top of common.h  then I can compile just fine.
 
 I was wondering if it made sense to people to have standalone applications
 define something like __STANDALONE__ either via CPPFLAGS or in the source
 itself and use the presence of that to exclude the majority of common.h
 when used in standalone applications. Or alternatively move the required
 bits to exports.h.

(long rant ahead. Short answer after end of rant)

[RANT]

Code writers indeed have a right to name any function or other object
any way they choose... within the constraints of the situation.

Some of these constraints stem from the tools -- you just cannot put an
ampersand in a C object name, for instance -- and some stem from the
'agreement' entered into when using a library -- precisely, the
agreement on the name and semantics of such and such object names.

Here, by including exports.h, you enter an agreement in which
the object name 'net_init' receives a specific meaning. What you want
is to benefit from the agreement without abiding by it.

Now this can be changed, technically, as most things are, and a new
kind of agreement could be devised with fine-grain control on which
object names would or would not be defined. The question is, *should*
this be done?

Would you, analogously, suggest that Linux app developers be able to
opt out of defining fopen() when they #include stdio.h because they
feel they have a right to define 'char* fopen(float F)' in their code if
they so please? And that it should be done so for just about any
kernel-exported symbol? I suspect not.

So why ask this from U-Boot?

[/RANT]

I personally will NAK such a suggestion. I don't see the point in
adding complexity just to solve a naming conflict between a framework,
de facto standard, name and a freely-modifiable application name. Just
rename the application function -- that'll be all the better since that
will also remove potential misunderstanding for readers of your code.

 Thanks,
 Chris

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

Re: [U-Boot] Function prototype conflicts with standalone apps

[Albert ARIBAUD]

Small fix:

 Here, by including exports.h

Actually common.h, but the point stands.

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

[U-Boot] [PATCH] m68k: fix debug call befor serial init

[Jens Scharsig (BuS Elektronik)]

From: Jens Scharsig (BuS Elektronik) e...@bus-elektronik.de

There is a debug call in board.c befor serial interface was initialized.
This moves the debug code behind serial_initialize call.

Signed-off-by: Jens Scharsig (BuS Elektronik) e...@bus-elektronik.de
---
 arch/m68k/lib/board.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/m68k/lib/board.c b/arch/m68k/lib/board.c
index e934cb6..14722e4 100644
--- a/arch/m68k/lib/board.c
+++ b/arch/m68k/lib/board.c
@@ -402,14 +402,14 @@ void board_init_r (gd_t *id, ulong dest_addr)
 
gd-flags |= GD_FLG_RELOC;  /* tell others: relocation done */
 
-   debug (Now running in RAM - U-Boot at: %08lx\n, dest_addr);
-
WATCHDOG_RESET ();
 
gd-reloc_off =  dest_addr - CONFIG_SYS_MONITOR_BASE;
 
serial_initialize();
 
+   debug(Now running in RAM - U-Boot at: %08lx\n, dest_addr);
+
monitor_flash_len = (ulong)__init_end - dest_addr;
 
 #if defined(CONFIG_NEEDS_MANUAL_RELOC)
-- 
1.7.10.4

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

Re: [U-Boot] [PATCH 00/12] cmd_sf: Add support for read and write instructions

[Jagan Teki]

Hi Thomas,

On Thu, Jan 10, 2013 at 8:03 PM, Langer Thomas (LQDE RD ST PON SW)
thomas.lan...@lantiq.com wrote:
 Hello Jagan,

 All these patches are added a support for read and write instruction
 for programming/reading SPI flash.

 I have written some weeks ago that I would really appreciate the support of
 dual and quad IO accesses for serial flashes. I just  think, this is not an 
 acceptable
 way to do this.


First of all thank you very much for your comments.

 It is important to know for all, who do not know the details on the hardware
 requirements of this feature, that these new transfers require a special SPI
 controller! A standard SPI hardware, which is being used on most (maybe all)
 existing boards, cannot use the dual or quad IO features at all!

I am some how unclear about your  concern.

Basically I have added this code that is purely specific to mtd flash
layer, means
the entire code is alters the functionalists of flash parts(stmicro,
spansion, winbond..etc).

whether the respective SOC SPI/QSPI controller driver can support
these transfer or not, may be
we couldn't take care at this point of time.

Please comment if I am wrong with my analyses.


 And in addition, I still haven't seen any change, which indicates the required
 transfer mode to the SPI layer! How do you tell your SPI driver, which part
 of the transfer should be done in dual or quad mode?

I don't think so, but the SPI/QSPI controller  driver should aware
respective read/write/erase instructions
transfer changes those are trying to pass from mtd flash. .

Suppose if the flash used QUAD PP , then the respective h/w SPI/QSPI
controller must
have a support to do the QUAD PP transfers (by adding QUAD_PP command transfer).

I think this job is specific to respective h/w driver, they need to
add these transfers support.
currently I have used a zynq qspi controller for testing these
instruction by adding respective
instructions are this driver.

http://git.xilinx.com/?p=u-boot-xlnx.git;a=blob;f=drivers/spi/zynq_qspi.c;h=642241d0fc25d04c06ecbeb5d01ba06108307c62;hb=master



 Read and Write instruction are implemented as a command line
 arguments for 'sf write' , 'sf read' and 'sf update' commands.

 Currently I have added below instructions those are commonly available
 on all flash types.
 pp - Page Program (existing one)
 qpp - Quad-input Page Program
 afr - Array Fast Read (existing one)
 asr - Array Slow Read
 dofr - Dual Output Fast Read
 qofr - Quad Output Fast Read
 diofr - Dual IO Fast Read
 qiofr - Quad IO Fast Read

 I have tested mostly of the instruction on real h/w.

 This entire implementation will change the current sf framework little bit 
 but
 I thought these changes are worth to add.

 This means, all your patches adding new code, which has no benefit for 
 existing
 boards, but changing the commands in an incompatible way, which forces all 
 users
 to adapt their definitions!
 I don't think this will be accepted, as I would not.

 The biggest question is: Do somebody really need the flexibility to select the
 used instruction at this level?
 If you have a platform, which contains an extended SPI controller and has 
 also a
 supported flash, I expect it would be okay to always use the dual or quad 
 instructions!
 And this can be completely handled by the lower level functions, no need to 
 expose
 this to the command line!

Yes, basically if some don't want/they don't support the respective
instruction at their h/w or
QSPI/SPI controller level certainly they couldn't use.
instead they may use the respective supported instructions at command
level, I suspect this could be
a selective features from users point of view.


 I think, first of all, you should add some config options (e.g. 
 CONFIG_SYS_SF_DUAL /
 CONFIG_SYS_SF_QUAD) to indicate, that the platform / board will support these.
 Then, during sf probe, there should be a detection, if the flash will 
 support this
 (depending on the type) and is enabled (checking the config bit for quad IO).
 Depending on this, either specific functions for read/write could be assigned 
 or
 some other data, which indicate the usable instructions, can be set.

May be your taking about run-time detection of specific instruction
supported by respective flash.
Actually i don't have any idea how to detect whether the flash
supports  pp, qpp, fr, sr, dor, qor?

Please pass any information if there is a flexible way to detect this feature.

But currently these(pp, qpp, afr, asr, dor, qor, dior, qior)
instructions are commonly supported once from
spansion, numonyx and winbond flashes.this is the reason for me to
give these instructions support at this point of time.

Thanks,
Jagan.


 As it depends on the flash type and manufacturer, how the lower sequence must
 look like (for the command/address/data phases, it might be 1-1-4, 1-4-4 or 
 even 4-4-4),
 this should be flexible to be assigned from the detection code.
 For example, please check the differences between Spansion and