[U-Boot] [PATCH][v1] ppc/85xx: Fix up eSDHC controller clock frequency in the device tree

[Dipen Dudhat]

Signed-off-by: Dipen Dudhat 
Acked-by: Kumar Gala 
---
- applies on http://git.denx.de/u-boot-mpc85xx.git branch->next
 cpu/mpc85xx/fdt.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/cpu/mpc85xx/fdt.c b/cpu/mpc85xx/fdt.c
index 53b184f..73886bd 100644
--- a/cpu/mpc85xx/fdt.c
+++ b/cpu/mpc85xx/fdt.c
@@ -352,4 +352,8 @@ void ft_cpu_setup(void *blob, bd_t *bd)
ft_fixup_num_cores(blob);
 
ft_fixup_cache(blob);
+
+#if defined(CONFIG_FSL_ESDHC)
+   fdt_fixup_esdhc(blob, bd);
+#endif
 }
-- 
1.5.6.3

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

[U-Boot] [PATCH][v1] ppc/85xx,86xx: Handling Unknown SOC version

[Poonam Aggrwal]

Incase the system is detected with Unknown SVR, let the system boot
with a default value and a proper message.
Now with dynamic detection of SOC properties from SVR, this is necessary
to prevent a crash. 

Signed-off-by: Poonam Aggrwal 
Signed-off-by: Kumar Gala 
---
applies on git.am.freescale.net/mirrors/u-boot.git
 cpu/mpc85xx/cpu.c   |   10 +++---
 cpu/mpc86xx/cpu.c   |5 +
 cpu/mpc8xxx/cpu.c   |4 ++--
 include/asm-ppc/processor.h |2 ++
 4 files changed, 8 insertions(+), 13 deletions(-)

diff --git a/cpu/mpc85xx/cpu.c b/cpu/mpc85xx/cpu.c
index 6be98dc..63bdb6f 100644
--- a/cpu/mpc85xx/cpu.c
+++ b/cpu/mpc85xx/cpu.c
@@ -69,13 +69,9 @@ int checkcpu (void)
 
cpu = gd->cpu;
 
-   if (cpu->name) {
-   puts(cpu->name);
-   if (IS_E_PROCESSOR(svr))
-   puts("E");
-   } else {
-   puts("Unknown");
-   }
+   puts(cpu->name);
+   if (IS_E_PROCESSOR(svr))
+   puts("E");
 
printf(", Version: %d.%d, (0x%08x)\n", major, minor, svr);
 
diff --git a/cpu/mpc86xx/cpu.c b/cpu/mpc86xx/cpu.c
index 04409ce..e97ab6d 100644
--- a/cpu/mpc86xx/cpu.c
+++ b/cpu/mpc86xx/cpu.c
@@ -65,10 +65,7 @@ checkcpu(void)
 
cpu = gd->cpu;
 
-   if (cpu->name)
-   puts(cpu->name);
-   else
-   puts("Unknown");
+   puts(cpu->name);
 
printf(", Version: %d.%d, (0x%08x)\n", major, minor, svr);
puts("Core:  ");
diff --git a/cpu/mpc8xxx/cpu.c b/cpu/mpc8xxx/cpu.c
index 339f6d9..56fb141 100644
--- a/cpu/mpc8xxx/cpu.c
+++ b/cpu/mpc8xxx/cpu.c
@@ -77,6 +77,7 @@ struct cpu_type cpu_type_list [] = {
CPU_TYPE_ENTRY(8641, 8641, 2),
CPU_TYPE_ENTRY(8641D, 8641D, 2),
 #endif
+   CPU_TYPE_ENTRY(Unknown, Unknown, 1),
 };
 
 struct cpu_type *identify_cpu(u32 ver)
@@ -86,8 +87,7 @@ struct cpu_type *identify_cpu(u32 ver)
if (cpu_type_list[i].soc_ver == ver)
return &cpu_type_list[i];
}
-
-   return NULL;
+   return &cpu_type_list[i-1];
 }
 
 int cpu_numcores() {
diff --git a/include/asm-ppc/processor.h b/include/asm-ppc/processor.h
index dcaf8c0..9b27634 100644
--- a/include/asm-ppc/processor.h
+++ b/include/asm-ppc/processor.h
@@ -1022,6 +1022,8 @@
 #define SVR_8641   0x809000
 #define SVR_8641D  0x809001
 
+#define SVR_Unknown0x00
+
 #define _GLOBAL(n)\
.globl n;\
 n:
-- 
1.5.6.5

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

Re: [U-Boot] [PATCH 1/2] Move uninitialized_var() macro from ubi_uboot.h to compiler.h

[Mike Frysinger]

On Tuesday 01 September 2009 15:58:14 Anton Vorontsov wrote:
> On Tue, Sep 01, 2009 at 08:52:33PM +0200, Albin Tonnerre wrote:
> > > > > +/* compiler options */
> > > > > +#define uninitialized_var(x) x = x
> > > >
> > > > Please excuse my ignorance, but where and what for is such a
> > > > definition useful?
> > >
> > > It's used to avoid GCC warnings, i.e. when GCC isn't smart enough
> > > to see that some variable isn't actually used uninitialized.
> > >
> > > ~/linux-2.6$ git grep uninitialized_var drivers/ | wc -l
> > > 94
> >
> > You seem to be grepping the linux source tree.
>
> Yes, which is a great source of best practices.

except you didnt filter drivers/staging/ thus negating any results you might 
try to use to back up arguments
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] ppc/8xxx: Remove ddr_pd_cntl register since it doesn't exist

[Kumar Gala]

The ddr_pd_cntl isn't defined in any reference manual and thus we wil
remove especially since we set it to 0, which would most likely be its
POR value.

Signed-off-by: Kumar Gala 
---
 board/freescale/p1_p2_rdb/ddr.c |5 -
 cpu/mpc85xx/ddr-gen3.c  |1 -
 cpu/mpc8xxx/ddr/ctrl_regs.c |   23 ---
 include/asm-ppc/fsl_ddr_sdram.h |1 -
 include/asm-ppc/immap_85xx.h|2 +-
 5 files changed, 1 insertions(+), 31 deletions(-)

diff --git a/board/freescale/p1_p2_rdb/ddr.c b/board/freescale/p1_p2_rdb/ddr.c
index 9518392..d1e659b 100644
--- a/board/freescale/p1_p2_rdb/ddr.c
+++ b/board/freescale/p1_p2_rdb/ddr.c
@@ -43,7 +43,6 @@ extern void fsl_ddr_set_memctl_regs(const fsl_ddr_cfg_regs_t 
*regs,
 #define CONFIG_SYS_DDR_MODE_CONTROL0x
 #define CONFIG_SYS_DDR_ZQ_CONTROL  0x
 #define CONFIG_SYS_DDR_WRLVL_CONTROL   0x
-#define CONFIG_SYS_DDR_PD_CONTROL  0x
 #define CONFIG_SYS_DDR_SR_CNTR 0x
 #define CONFIG_SYS_DDR_RCW_1   0x
 #define CONFIG_SYS_DDR_RCW_2   0x
@@ -110,7 +109,6 @@ fsl_ddr_cfg_regs_t ddr_cfg_regs_400 = {
.timing_cfg_5 = CONFIG_SYS_DDR_TIMING_5,
.ddr_zq_cntl = CONFIG_SYS_DDR_ZQ_CONTROL,
.ddr_wrlvl_cntl = CONFIG_SYS_DDR_WRLVL_CONTROL,
-   .ddr_pd_cntl = CONFIG_SYS_DDR_PD_CONTROL,
.ddr_sr_cntr = CONFIG_SYS_DDR_SR_CNTR,
.ddr_sdram_rcw_1 = CONFIG_SYS_DDR_RCW_1,
.ddr_sdram_rcw_2 = CONFIG_SYS_DDR_RCW_2
@@ -138,7 +136,6 @@ fsl_ddr_cfg_regs_t ddr_cfg_regs_533 = {
.timing_cfg_5 = CONFIG_SYS_DDR_TIMING_5,
.ddr_zq_cntl = CONFIG_SYS_DDR_ZQ_CONTROL,
.ddr_wrlvl_cntl = CONFIG_SYS_DDR_WRLVL_CONTROL,
-   .ddr_pd_cntl = CONFIG_SYS_DDR_PD_CONTROL,
.ddr_sr_cntr = CONFIG_SYS_DDR_SR_CNTR,
.ddr_sdram_rcw_1 = CONFIG_SYS_DDR_RCW_1,
.ddr_sdram_rcw_2 = CONFIG_SYS_DDR_RCW_2
@@ -166,7 +163,6 @@ fsl_ddr_cfg_regs_t ddr_cfg_regs_667 = {
.timing_cfg_5 = CONFIG_SYS_DDR_TIMING_5,
.ddr_zq_cntl = CONFIG_SYS_DDR_ZQ_CONTROL,
.ddr_wrlvl_cntl = CONFIG_SYS_DDR_WRLVL_CONTROL,
-   .ddr_pd_cntl = CONFIG_SYS_DDR_PD_CONTROL,
.ddr_sr_cntr = CONFIG_SYS_DDR_SR_CNTR,
.ddr_sdram_rcw_1 = CONFIG_SYS_DDR_RCW_1,
.ddr_sdram_rcw_2 = CONFIG_SYS_DDR_RCW_2
@@ -194,7 +190,6 @@ fsl_ddr_cfg_regs_t ddr_cfg_regs_800 = {
.timing_cfg_5 = CONFIG_SYS_DDR_TIMING_5,
.ddr_zq_cntl = CONFIG_SYS_DDR_ZQ_CONTROL,
.ddr_wrlvl_cntl = CONFIG_SYS_DDR_WRLVL_CONTROL,
-   .ddr_pd_cntl = CONFIG_SYS_DDR_PD_CONTROL,
.ddr_sr_cntr = CONFIG_SYS_DDR_SR_CNTR,
.ddr_sdram_rcw_1 = CONFIG_SYS_DDR_RCW_1,
.ddr_sdram_rcw_2 = CONFIG_SYS_DDR_RCW_2
diff --git a/cpu/mpc85xx/ddr-gen3.c b/cpu/mpc85xx/ddr-gen3.c
index 8ac3d5f..0691ca4 100644
--- a/cpu/mpc85xx/ddr-gen3.c
+++ b/cpu/mpc85xx/ddr-gen3.c
@@ -74,7 +74,6 @@ void fsl_ddr_set_memctl_regs(const fsl_ddr_cfg_regs_t *regs,
out_be32(&ddr->timing_cfg_5, regs->timing_cfg_5);
out_be32(&ddr->ddr_zq_cntl, regs->ddr_zq_cntl);
out_be32(&ddr->ddr_wrlvl_cntl, regs->ddr_wrlvl_cntl);
-   out_be32(&ddr->ddr_pd_cntl, regs->ddr_pd_cntl);
out_be32(&ddr->ddr_sr_cntr, regs->ddr_sr_cntr);
out_be32(&ddr->ddr_sdram_rcw_1, regs->ddr_sdram_rcw_1);
out_be32(&ddr->ddr_sdram_rcw_2, regs->ddr_sdram_rcw_2);
diff --git a/cpu/mpc8xxx/ddr/ctrl_regs.c b/cpu/mpc8xxx/ddr/ctrl_regs.c
index 1689d68..5e63c5d 100644
--- a/cpu/mpc8xxx/ddr/ctrl_regs.c
+++ b/cpu/mpc8xxx/ddr/ctrl_regs.c
@@ -1066,28 +1066,6 @@ static void set_ddr_sr_cntr(fsl_ddr_cfg_regs_t *ddr, 
unsigned int sr_it)
ddr->ddr_sr_cntr = (sr_it & 0xF) << 16;
 }
 
-/* DDR Pre-Drive Conditioning Control (DDR_PD_CNTL) */
-static void set_ddr_pd_cntl(fsl_ddr_cfg_regs_t *ddr)
-{
-   /* Termination value during pre-drive conditioning */
-   unsigned int tvpd = 0;
-   unsigned int pd_en = 0; /* Pre-Drive Conditioning Enable */
-   unsigned int pdar = 0;  /* Pre-Drive After Read */
-   unsigned int pdaw = 0;  /* Pre-Drive After Write */
-   unsigned int pd_on = 0; /* Pre-Drive Conditioning On */
-   unsigned int pd_off = 0;/* Pre-Drive Conditioning Off */
-
-   ddr->ddr_pd_cntl = (0
-   | ((pd_en & 0x1) << 31)
-   | ((tvpd & 0x7) << 28)
-   | ((pdar & 0x7F) << 20)
-   | ((pdaw & 0x7F) << 12)
-   | ((pd_on & 0x1F) << 6)
-   | ((pd_off & 0x1F) << 0)
-   );
-}
-
-
 /* DDR SDRAM Register Control Word 1 (DDR_SDRAM_RCW_1) */
 static void set_ddr_sdram_rcw_1(fsl_ddr_cfg_regs_t *ddr)
 {
@@ -1355,7 +1333,6 @@ compute_fsl_memctl_config_regs(const memctl_options_t 
*popts,
set_ddr_zq_cntl(ddr, zq_en);
set_ddr_wrlvl_cntl(ddr, wrlvl_en);
 
-   set_ddr_pd_cntl(ddr);
set_ddr_sr_cntr(ddr, sr_it);

Re: [U-Boot] [PATCH] ppc/8xxx: Remove ddr_pd_cntl register since it doesn't exist

[Kumar Gala]

On Sep 1, 2009, at 10:03 PM, Kumar Gala wrote:

> The ddr_pd_cntl isn't defined in any reference manual and thus we wil
> remove especially since we set it to 0, which would most likely be its
> POR value.
>
> Signed-off-by: Kumar Gala 
> ---
> board/freescale/p1_p2_rdb/ddr.c |5 -
> cpu/mpc85xx/ddr-gen3.c  |1 -
> cpu/mpc8xxx/ddr/ctrl_regs.c |   23 ---
> include/asm-ppc/fsl_ddr_sdram.h |1 -
> include/asm-ppc/immap_85xx.h|2 +-
> 5 files changed, 1 insertions(+), 31 deletions(-)

applied to 85xx

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

[U-Boot] [PATCH v6 2/2 resend] arm: A320: Add support for Faraday A320 evaluation board

[ratbert . chuang]

From: Po-Yu Chuang 

This patch adds support for A320 evaluation board from Faraday. This board
uses FA526 processor by default and has 512kB and 32MB NOR flash, 64M RAM.
FA526 is an ARMv4 processor and uses the ARM920T source in this patch.

Signed-off-by: Po-Yu Chuang 
---
 MAINTAINERS   |4 +
 MAKEALL   |1 +
 Makefile  |3 +
 board/faraday/a320evb/Makefile|   51 
 board/faraday/a320evb/a320evb.c   |   73 +++
 board/faraday/a320evb/config.mk   |   35 +
 board/faraday/a320evb/lowlevel_init.S |  118 +
 cpu/arm920t/a320/Makefile |   47 +++
 cpu/arm920t/a320/ftsmc020.c   |   51 
 cpu/arm920t/a320/reset.S  |   22 
 cpu/arm920t/a320/timer.c  |  193 
 include/asm-arm/arch-a320/a320.h  |   35 +
 include/asm-arm/arch-a320/ftpmu010.h  |  190 
 include/asm-arm/arch-a320/ftsdmc020.h |  103 +++
 include/asm-arm/arch-a320/ftsmc020.h  |   79 
 include/asm-arm/arch-a320/fttmr010.h  |   73 +++
 include/configs/a320evb.h |  222 +
 17 files changed, 1300 insertions(+), 0 deletions(-)
 create mode 100644 board/faraday/a320evb/Makefile
 create mode 100644 board/faraday/a320evb/a320evb.c
 create mode 100644 board/faraday/a320evb/config.mk
 create mode 100644 board/faraday/a320evb/lowlevel_init.S
 create mode 100644 cpu/arm920t/a320/Makefile
 create mode 100644 cpu/arm920t/a320/ftsmc020.c
 create mode 100644 cpu/arm920t/a320/reset.S
 create mode 100644 cpu/arm920t/a320/timer.c
 create mode 100644 include/asm-arm/arch-a320/a320.h
 create mode 100644 include/asm-arm/arch-a320/ftpmu010.h
 create mode 100644 include/asm-arm/arch-a320/ftsdmc020.h
 create mode 100644 include/asm-arm/arch-a320/ftsmc020.h
 create mode 100644 include/asm-arm/arch-a320/fttmr010.h
 create mode 100644 include/configs/a320evb.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 79873f3..aa54bdb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -533,6 +533,10 @@ Rick Bronson 
 
AT91RM9200DKat91rm9200
 
+Po-Yu Chuang 
+
+   a320evb FA526 (ARM920T-like) (a320 SoC)
+
 George G. Davis 
 
assabet SA1100
diff --git a/MAKEALL b/MAKEALL
index 5882ceb..7c742b6 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -505,6 +505,7 @@ LIST_ARM7=" \
 #
 
 LIST_ARM9="\
+   a320evb \
ap920t  \
ap922_XA10  \
ap926ejs\
diff --git a/Makefile b/Makefile
index c9d315a..a3fb0b8 100644
--- a/Makefile
+++ b/Makefile
@@ -2661,6 +2661,9 @@ shannon_config:   unconfig
 ## ARM92xT Systems
 #
 
+a320evb_config :   unconfig
+   @$(MKCONFIG) $(@:_config=) arm arm920t a320evb faraday a320
+
 #
 ## Atmel AT91RM9200 Systems
 #
diff --git a/board/faraday/a320evb/Makefile b/board/faraday/a320evb/Makefile
new file mode 100644
index 000..74f660d
--- /dev/null
+++ b/board/faraday/a320evb/Makefile
@@ -0,0 +1,51 @@
+#
+# (C) Copyright 2000-2006
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# 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 $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).a
+
+COBJS  := a320evb.o
+SOBJS  := lowlevel_init.o
+
+SRCS   := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS))
+SOBJS  := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+   $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS)
+
+clean:
+   rm -f $(SOBJS) $(OBJS)
+
+distclean: clean
+   rm -f $(LIB) core *.bak $(obj).depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+###

[U-Boot] Does u-boot support nand flash boot

[雷 高]

I want to use u-boot for the ARM chip S3C2410. S3C2410 supports the nand flash 
boot. So I want to know whether the u-boot supports the nand flash boot..

Thank you for your answer!



  ___ 
  好玩贺卡等你发，邮箱贺卡全新上线！ 
http://card.mail.cn.yahoo.com/___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v6 1/2 resend] arm: A320: driver for FTRTC010 real time clock

[ratbert . chuang]

From: Po-Yu Chuang 

This patch adds an FTRTC010 driver for Faraday A320 evaluation board.

Signed-off-by: Po-Yu Chuang 
---
 drivers/rtc/Makefile   |1 +
 drivers/rtc/ftrtc010.c |  124 
 2 files changed, 125 insertions(+), 0 deletions(-)
 create mode 100644 drivers/rtc/ftrtc010.c

diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 822dc1a..25252b5 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -40,6 +40,7 @@ COBJS-$(CONFIG_RTC_DS1556) += ds1556.o
 COBJS-$(CONFIG_RTC_DS164x) += ds164x.o
 COBJS-$(CONFIG_RTC_DS174x) += ds174x.o
 COBJS-$(CONFIG_RTC_DS3231) += ds3231.o
+COBJS-$(CONFIG_RTC_FTRTC010) += ftrtc010.o
 COBJS-$(CONFIG_RTC_ISL1208) += isl1208.o
 COBJS-$(CONFIG_RTC_M41T11) += m41t11.o
 COBJS-$(CONFIG_RTC_M41T60) += m41t60.o
diff --git a/drivers/rtc/ftrtc010.c b/drivers/rtc/ftrtc010.c
new file mode 100644
index 000..c3c0bc2
--- /dev/null
+++ b/drivers/rtc/ftrtc010.c
@@ -0,0 +1,124 @@
+/*
+ * Faraday FTRTC010 Real Time Clock
+ *
+ * (C) Copyright 2009 Faraday Technology
+ * Po-Yu Chuang 
+ *
+ * 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., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+struct ftrtc010 {
+   unsigned int sec;   /* 0x00 */
+   unsigned int min;   /* 0x04 */
+   unsigned int hour;  /* 0x08 */
+   unsigned int day;   /* 0x0c */
+   unsigned int alarm_sec; /* 0x10 */
+   unsigned int alarm_min; /* 0x14 */
+   unsigned int alarm_hour;/* 0x18 */
+   unsigned int record;/* 0x1c */
+   unsigned int cr;/* 0x20 */
+};
+
+/*
+ * RTC Control Register
+ */
+#define FTRTC010_CR_ENABLE (1 << 0)
+#define FTRTC010_CR_INTERRUPT_SEC  (1 << 1)/* per second irq */
+#define FTRTC010_CR_INTERRUPT_MIN  (1 << 2)/* per minute irq */
+#define FTRTC010_CR_INTERRUPT_HR   (1 << 3)/* per hour   irq */
+#define FTRTC010_CR_INTERRUPT_DAY  (1 << 4)/* per dayirq */
+
+static struct ftrtc010 *rtc = (struct ftrtc010 *)CONFIG_FTRTC010_BASE;
+
+static void ftrtc010_enable (void)
+{
+   writel (FTRTC010_CR_ENABLE, &rtc->cr);
+}
+
+/*
+ * return current time in seconds
+ */
+static unsigned long ftrtc010_time (void)
+{
+   unsigned long day;
+   unsigned long hour;
+   unsigned long minute;
+   unsigned long second;
+   unsigned long second2;
+
+   do {
+   second  = readl (&rtc->sec);
+   day = readl (&rtc->day);
+   hour= readl (&rtc->hour);
+   minute  = readl (&rtc->min);
+   second2 = readl (&rtc->sec);
+   } while (second != second2);
+
+   return day * 24 * 60 * 60 + hour * 60 * 60 + minute * 60 + second;
+}
+
+/*
+ * Get the current time from the RTC
+ */
+
+int rtc_get (struct rtc_time *tmp)
+{
+   unsigned long now;
+
+   debug ("%s(): record register: %x\n",
+  __func__, readl (&rtc->record));
+
+   now = ftrtc010_time () + readl (&rtc->record);
+
+   to_tm (now, tmp);
+
+   return 0;
+}
+
+/*
+ * Set the RTC
+ */
+int rtc_set (struct rtc_time *tmp)
+{
+   unsigned long new;
+   unsigned long now;
+
+   debug ("%s(): DATE: %4d-%02d-%02d (wday=%d)  TIME: %2d:%02d:%02d\n",
+  __func__,
+  tmp->tm_year, tmp->tm_mon, tmp->tm_mday, tmp->tm_wday,
+  tmp->tm_hour, tmp->tm_min, tmp->tm_sec);
+
+   new = mktime (tmp->tm_year, tmp->tm_mon, tmp->tm_mday, tmp->tm_hour,
+ tmp->tm_min, tmp->tm_sec);
+
+   now = ftrtc010_time ();
+
+   debug ("%s(): write %lx to record register\n", __func__, new - now);
+
+   writel (new - now, &rtc->record);
+
+   return 0;
+}
+
+void rtc_reset (void)
+{
+   debug ("%s()\n", __func__);
+   ftrtc010_enable ();
+}
-- 
1.6.3.3

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

Re: [U-Boot] [PATCH] ppc/8xxx: relocate cpu pointer in global data

[Kumar Gala]

On Sep 1, 2009, at 9:09 PM, Kumar Gala wrote:

> Now that we have a pointer to the cpu struct we need to relocate it  
> once
> we get into ram.
>
> Signed-off-by: Kumar Gala 
> ---
> lib_ppc/board.c |4 
> 1 files changed, 4 insertions(+), 0 deletions(-)

applied to 85xx.

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

[U-Boot] [PATCH] ppc/8xxx: relocate cpu pointer in global data

[Kumar Gala]

Now that we have a pointer to the cpu struct we need to relocate it once
we get into ram.

Signed-off-by: Kumar Gala 
---
 lib_ppc/board.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/lib_ppc/board.c b/lib_ppc/board.c
index 9faf7f2..6e6483b 100644
--- a/lib_ppc/board.c
+++ b/lib_ppc/board.c
@@ -686,6 +686,10 @@ void board_init_r (gd_t *id, ulong dest_addr)
gd->reloc_off = dest_addr - CONFIG_SYS_MONITOR_BASE;
 #endif
 
+#if defined(CONFIG_MPC85xx) || defined(CONFIG_MPC86xx)
+   gd->cpu += gd->reloc_off;
+#endif
+
 #ifdef CONFIG_SERIAL_MULTI
serial_initialize();
 #endif
-- 
1.6.0.6

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

Re: [U-Boot] [PATCH v2] fsl: sys_eeprom: Fix 'may be used uninitialized' warning

[Kumar Gala]

On Sep 1, 2009, at 5:17 PM, Anton Vorontsov wrote:

> The warning is bogus, so silence it by initializing the 'ret'  
> variable.
>
> Signed-off-by: Anton Vorontsov 
> ---
>
> On Tue, Sep 01, 2009 at 09:27:37PM +0200, Wolfgang Denk wrote:
>> Dear Anton Vorontsov,
>>
>> In message <20090901182518.ga17...@oksana.dev.rtsoft.ru> you wrote:
>>>
>>> We can fix the warnings by assigning some value to a variable
>>> at declaration, but the advantage of 'x = x' trick is that it
>>> doesn't generate any code.
>>
>> Argh... what a clev^H^H^H^Hdirty trick.
>>
>> Thanks for the explanation.
>>
>> However, in this case it seems to make sense to me to explicitly
>> initialize the return code with zero.
>
> Well, I don't see any advantages of this, but here it is anyway.
>
> Thanks.
>
> p.s. Timur, since the patch has changed, I couldn't preserve your
> previous Ack.
>
> board/freescale/common/sys_eeprom.c |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)


applied to 85xx.

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

Re: [U-Boot] [PATCH][v1] ppc/85xx: Use CONFIG_FSL_ESDHC to enable sdhc clk

[Kumar Gala]

On Sep 1, 2009, at 6:57 AM, Dipen Dudhat wrote:

> Enable eSDHC Clock based on generic CONFIG_FSL_ESDHC define instead  
> of a platform define.
> This will enable all the 85xx platforms to use sdhc_clk based on  
> CONFIG_FSL_ESDHC.
>
> Signed-off-by: Gao Guanhua 
> Signed-off-by: Dipen Dudhat 
> ---
> - applies on git.denx.de/u-boot-mpc85xx.git branch->next
> cpu/mpc85xx/speed.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)

applied to 85xx.

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

Re: [U-Boot] [PATCH][v1] ppc/85xx: Fix up eSDHC controller clock frequency in the device tree for P1 & P2 RDB platforms

[Kumar Gala]

On Sep 1, 2009, at 6:57 AM, Dipen Dudhat wrote:

> Fix up eSDHC controller clock frequency in the device tree for P1 &  
> P2 RDB platforms
>
> Signed-off-by: Dipen Dudhat 
> ---
> - applies on git.denx.de/u-boot-mpc85xx.git branch->next
> board/freescale/p1_p2_rdb/p1_p2_rdb.c |3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/board/freescale/p1_p2_rdb/p1_p2_rdb.c b/board/freescale/ 
> p1_p2_rdb/p1_p2_rdb.c
> index 4c03468..4d99e43 100644
> --- a/board/freescale/p1_p2_rdb/p1_p2_rdb.c
> +++ b/board/freescale/p1_p2_rdb/p1_p2_rdb.c
> @@ -209,6 +209,9 @@ void ft_board_setup(void *blob, bd_t *bd)
>   size = getenv_bootm_size();
>
>   fdt_fixup_memory(blob, (u64)base, (u64)size);
> +#ifdef CONFIG_FSL_ESDHC
> + fdt_fixup_esdhc(blob, bd);
> +#endif

why don't we do this in cpu/mpc85xx/fdt.c?

- k

> }
> #endif
>
> -- 
> 1.5.6.3
>
> ___
> 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] I2c imd/imw for a digital potentiometer?

[Brian Hutchinson]

On Tue, Sep 1, 2009 at 2:22 PM, Jerry Van Baren wrote:

> Brian Hutchinson wrote:
>
>> Hi all,
>>
>> I'm a little stumped as to how to write to a EEPot with the imw command.
>>
>> The EEPot is a Maxim 5434 and has an address of 0x28.  To write to its
>> volatile or non-volatile register ... a command byte is given.
>>
>> Writing 5 bits of data (it is a 32 tap pot so that is where the 5 bits
>> come
>> from) to move the wiper goes something like this:
>>
>> Start, 0x28, Ack, Cmd byte, Ack, Data byte, Ack, Stop
>>
>> Cmd byte is 0x11 to write to volatile reg. 0x21 to write to non-volatile
>> reg.
>>
>
> Looks pretty standard if you map "cmd byte" to "register".
>
>  The EEPROM really doesn't have addresses/offsets so I tried:
>>
>> imw 28 11 80 1
>>
>
The one is a count.


>
> What is the trailing '1' here?  Or is the '80' bogus?
>
> I would expect this to work.  The i2c command defaults to a one byte
> register offset.  To write a 0x80 byte to register (aka command) 0x11, you
> want to do this:
>  imw 28 11.1 80
> which should be the same as this:
>  imw 28 11 80
>
>  imw.w 28 0.0 1180
>>
>
> That seems like it should work also, although the '11' is more logically a
> register offset.
>
>  ... but it doesn't appear to play well with my device.
>>
>
> Trivia: the old imw (imr, etc) commands are deprecated, you should use the
> new "i2c " versions.
>
> [snip]
>
>  Regards,
>>
>> Brian
>>
>
> Good luck,
> gvb
>

Well I figured my problem.  I was trying various ways of writing to the
eepot and trying to read back what I wrote in its non-volatile or volatile
registers.  I found out you can't read back from it!  I went over the data
sheet several times and nothing really said you could or you couldn't ... I
just noticed they focused on writing to the eeprom inside and on
power-cycle, the chip would read non-volatile storage and move the stored
value to the volatile register and effect the wiper 20us after power up.

Once I realized this, I started writing values and probing the L pin with a
multimeter and once I found the right pin (helps to know the right pin :) )
I discovered that:
imw 28 11 80 1 would write to the volatile storage and make the wiper move
so it is working!  (there was much rejoycing)

I was using u-boot 1.1.6 which I forgot to mention.  I also have 1.3.4 that
I recently moved to.  For some reason my bitbanged Soft_I2C I had working
with 1.1.6 wouldn't work in 1.3.4. I also didn't notice any new i2c commands
and just kept using the imd, imm, imw commands.  Thanks for the tip on the
new commands ... I'll have to look into it.

Regards,

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

Re: [U-Boot] [PATCH v2] fsl: sys_eeprom: Fix 'may be used uninitialized' warning

[Timur Tabi]

Anton Vorontsov wrote:

> p.s. Timur, since the patch has changed, I couldn't preserve your
>  previous Ack.

I'm okay with this version, too.


-- 
Timur Tabi
Linux kernel developer at Freescale
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2] fsl: sys_eeprom: Fix 'may be used uninitialized' warning

[Anton Vorontsov]

The warning is bogus, so silence it by initializing the 'ret' variable.

Signed-off-by: Anton Vorontsov 
---

On Tue, Sep 01, 2009 at 09:27:37PM +0200, Wolfgang Denk wrote:
> Dear Anton Vorontsov,
> 
> In message <20090901182518.ga17...@oksana.dev.rtsoft.ru> you wrote:
> >
> > We can fix the warnings by assigning some value to a variable
> > at declaration, but the advantage of 'x = x' trick is that it
> > doesn't generate any code.
> 
> Argh... what a clev^H^H^H^Hdirty trick.
> 
> Thanks for the explanation.
> 
> However, in this case it seems to make sense to me to explicitly
> initialize the return code with zero.

Well, I don't see any advantages of this, but here it is anyway.

Thanks.

p.s. Timur, since the patch has changed, I couldn't preserve your
 previous Ack.

 board/freescale/common/sys_eeprom.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/board/freescale/common/sys_eeprom.c 
b/board/freescale/common/sys_eeprom.c
index c0fff68..661015e 100644
--- a/board/freescale/common/sys_eeprom.c
+++ b/board/freescale/common/sys_eeprom.c
@@ -204,7 +204,8 @@ static void update_crc(void)
  */
 static int prog_eeprom(void)
 {
-   int ret, i;
+   int ret = 0; /* shut up gcc */
+   int i;
void *p;
 #ifdef CONFIG_SYS_EEPROM_BUS_NUM
unsigned int bus;
-- 
1.6.3.3

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

Re: [U-Boot] Virtual addresses, u-boot, and the MMU

[J. William Campbell]

Wolfgang Denk wrote:
> Dear "J. William Campbell",
>
> In message <4a9d5ef2.4030...@comcast.net> you wrote:
>   
>>   I have followed the recent discussions about problems in the CFI 
>> driver caused by the need to change the attributes of the address at 
>> which the flash is mapped. This discussion has raised some questions in 
>> my mind regarding the assumptions u-boot makes regarding the behavior of 
>> the addresses used in the code. I am writing this message for comments 
>> that may correct any mis-understandings I have. First, the addresses 
>> used by the u-boot program to reference memory and code are all 
>> "virtual" addresses (VA) because they go through the MMU  to become a 
>> physical address(PA). If there is no MMU, the virtual address and the 
>> physical address are identical.
>> 
>
> Even if there is a MMU, we keep it "switched off" on most systems, or
> otherwise set it up in such a way that there is still a 1:1  mapping,
> i. e. the virtual address and physical address are identical, too.
>
> There have been several discussions concerning this topic on IRC
> (#u-boot at freenode); I'll try to summarize these here - not sure
> though if I don't miss anything: please feel free to complement what
> might be missing.
>
>   

> Becky then posted the summary of this discussion here:
>
> http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/50705
>
>
> Note that there was a general agreement among those who raised their
> voices.
>
>   
In quick summary, for the next few years, we will require that all 
"important" physical addresses have corresponding virtual addresses. 
Some limited support for mapping in "other resources" may be provided at 
an operator interface level, but it will be quite limited. OK, seems 
reasonable to me.
>   
>> The "normal", or legacy,policy for u-boot is to arrange a memory 
>> map such that all physical addresses are mapped to some virtual address. 
>> Originally, the mapping were such that the VA was actually == the PA, 
>> but today on some CPUs, this is not possible. When the size of the 
>> physical address space exceeds the size of the virtual address space, 
>> the VA may not =- the PA numerically, but there is a one-to-one 
>> correspondence. It MAY also acceptable to map the same PA so that it 
>> appears more than once in the address space (VA), but if this is done, 
>> 
>
> This may or may not be possible. It may even make sense or be needed
> on some systems, and it may be impossible to do on others.
>
> In any case, I think we should be careful not to mix things: what  we
> are  discussing here are address mappings. What we are not discussing
> is specific memory properties like  being  cached/uncached,  guarded/
> non-guarded, etc.
>
> Such properties are important, too, but  they  need  to  get  handled
> through a separate interface.
>   
Here is where I am quite sure you are going to have a problem. In very 
many CPUs, cache control and memory management are joined at the hip. 
Some systems have no easy way to enable and disable (D,I) cache 
globally, it is only doable on a page or segment basis. The PPC hardware 
has a relatively low cost way to do so, but not all architectures do.
>   
>>   Becky Bruce "re-wrote the driver to use VAs instead of PAs." I am 
>> not exactly sure what this means, but I assume it meant allowing the VA 
>> referencing the flash
>> to be distinct from the PA where the flash "lives" (and may require 36 
>> bits on a PPC system to represent the PA). Does the driver re-map 
>> 
>
> I think the information provided above sheds more light on this.
>   
Yes, it did.
>   
>> portions of the flash in order to access them? If the flash is really 
>> large, I can certainly see a need to do so. However, I assume on "medium 
>> size" flashes, it does not need to remap. In that case, don't all 
>> references just go through the MMU and get translated? The VA != PA, but 
>> from the point of view of u-boot, the VA is the only address that 
>> matters. The AVR32 certainly does not map flash dynamically, so it would 
>> not matter on that CPU.
>> 
>
> OK.
>
>   
>>   The issue with the CFI driver on the AVR32 is that it needs to 
>> disable cache on the address space of the flash memory when it is 
>> writing to the flash. This apparently is not trivial to do, but there is 
>> 
>
> Actually this is not specific to the AVR32, and so far  most  systems
> simply  do  not  enable  caches at all on the flash memory regions. I
> understand why the AVR32 solution is interesting, and I  think,  when
> we  try to find a solution for this we should use this chance to find
> a solution that also allows other systems to turn on  caches  on  the
> flash memory - things like loading the Linux kernel or ramdisk images
> etc. will benefit from that.
>   
Full ACK.



> While there are specific routines to  "write"  to  the  flash  (init,
> erase,  write),  there  is  no  specific  code  to "read" from flash

Re: [U-Boot] [PATCH] at91sam9260/afeb9260: Fix SPI initialization

[Jean-Christophe PLAGNIOL-VILLARD]

On 11:26 Tue 01 Sep , Albin Tonnerre wrote:
> Commit 7ebafb7ec1a0285af8380623c009576f92583b98 introduced a mistake in the 
> spi
> init function call for those boards. This patch fixes this.
> 
> Signed-off-by: Albin Tonnerre 
> ---
>  board/afeb9260/afeb9260.c |2 +-
>  board/atmel/at91sam9260ek/at91sam9260ek.c |2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
applied to u-boot-arm

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

Re: [U-Boot] [PATCH v8] Support for the Calao TNY-A9260/TNY-A9G20 boards

[Jean-Christophe PLAGNIOL-VILLARD]

On 16:04 Thu 20 Aug , Albin Tonnerre wrote:
> The Calao TNY-A9260 and TNY-9G20 are boards manufactured and sold by
> Calao Systems . Their components are very
> similar to the AT91SAM9260EK board, so their configuration is based on
> the configuration of this board. There are however some differences:
> different clocks, no LCD, no ethernet. They also can use SPI EEPROM to
> store the environment.
> 
> Signed-off-by: Albin Tonnerre 
> ---
>  Changes in v7:
>   - As per Jean-Christophe's commentes, fix long lines and use uppercase for
> defines in include/configs/tny_a9260.h. Slightly rework the ifdef logic in
> the process
>   - Add an entry in MAINTAINERS for the tny_a9g20 as weel, since both 9260 and
> 9g20 are supported
> 
>  Changes in v8:
>   - Update MAKEALL to reflect the changes in Makefile, and add the tny_a9g20
> 
>  MAINTAINERS  |5 +
>  MAKEALL  |2 +
>  Makefile |   10 ++
>  board/calao/tny_a9260/Makefile   |   55 ++
>  board/calao/tny_a9260/config.mk  |1 +
>  board/calao/tny_a9260/spi.c  |   50 +
>  board/calao/tny_a9260/tny_a9260.c|  110 +++
>  cpu/arm926ejs/at91/at91sam9260_devices.c |2 +-
>  include/configs/tny_a9260.h  |  172 
> ++
>  9 files changed, 406 insertions(+), 1 deletions(-)
>  create mode 100644 board/calao/tny_a9260/Makefile
>  create mode 100644 board/calao/tny_a9260/config.mk
>  create mode 100644 board/calao/tny_a9260/spi.c
>  create mode 100644 board/calao/tny_a9260/tny_a9260.c
>  create mode 100644 include/configs/tny_a9260.h
> 
applied to u-boot-arm

but merged manually

please next time when you add different board does it as a patch series
to avoid the manual merge

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

Re: [U-Boot] [PATCH v3] arm: Kirkwood: add SYSRSTn Duration Counter Support

[Jean-Christophe PLAGNIOL-VILLARD]

On 20:59 Thu 20 Aug , Prafulla Wadaskar wrote:
> This feature can be used to trigger special command "sysrstcmd" using
> reset key long press event and environment variable "sysrstdelay" is set
> (useful for reset to factory or manufacturing mode execution)
> 
> Kirkwood SoC implements a hardware-based SYSRSTn duration counter.
> When SYSRSTn is asserted low, a SYSRSTn duration counter is running.
> The counter value is stored in the SYSRSTn Length Counter Register
> The counter is based on the 25-MHz reference clock (40ns)
> It is a 29-bit counter, yielding a maximum counting duration of
> 2^29/25 MHz (21.4 seconds). When the counter reach its maximum value,
> it remains at this value until counter reset is triggered by setting
> bit 31 of KW_REG_SYSRST_CNT
> 
> Implementation:
> Upon long reset assertion (> ${sysrstdelay} in secs) sysrstcmd will be
> executed if pre-defined in environment variables.
> This feature will be disabled if "sysrstdelay" variable is unset.
> 
> for-ex.
> setenv sysrst_cmd "echo starting factory reset;
>  nand erase 0xa 0x2;
>  echo finish ed sysrst command;"
> will erase particular nand sector if triggered by this event
> 
> Signed-off-by: Prafulla Wadaskar 
> ---
> Change log:
> v2: updated as per review feedback for v1
> bug fix in the previous post (V2) fixed
> 
> v2 repost:
> I am sorry for previous post v2, pls ignore it, this is the right patch for 
> the same
> 
> v3: updated as per review feedback for v2
> all possible messages termed as debug
> 
>  cpu/arm926ejs/kirkwood/cpu.c|   75 
> +++
>  include/asm-arm/arch-kirkwood/cpu.h |2 +
>  2 files changed, 77 insertions(+), 0 deletions(-)
Applied to u-boot-arm

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

Re: [U-Boot] [PATCH] imx27lite: add support for imx27lite board from LogicPD

[Jean-Christophe PLAGNIOL-VILLARD]

On 02:32 Tue 11 Aug , Ilya Yanok wrote:
> This patch adds support for i.MX27-LITEKIT development board from
> LogicPD. This board uses i.MX27 SoC and has 2MB NOR flash, 64MB NAND
> flash, FEC ethernet controller integrated into i.MX27.
> 
> Signed-off-by: Ilya Yanok 
> ---
>  MAINTAINERS |1 +
>  MAKEALL |1 +
>  Makefile|3 +
>  board/logicpd/imx27lite/Makefile|   51 ++
>  board/logicpd/imx27lite/config.mk   |1 +
>  board/logicpd/imx27lite/imx27lite.c |   73 +
>  board/logicpd/imx27lite/lowlevel_init.S |  170 +
>  cpu/arm926ejs/mx27/generic.c|   65 
>  include/asm-arm/arch-mx27/imx-regs.h|   12 ++
>  include/configs/imx27lite.h |  252 
> +++
>  10 files changed, 629 insertions(+), 0 deletions(-)
>  create mode 100644 board/logicpd/imx27lite/Makefile
>  create mode 100644 board/logicpd/imx27lite/config.mk
>  create mode 100644 board/logicpd/imx27lite/imx27lite.c
>  create mode 100644 board/logicpd/imx27lite/lowlevel_init.S
>  create mode 100644 include/configs/imx27lite.h
Applie to u-boot-arm

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

Re: [U-Boot] [PATCH 2/2] MTD:NAND: ADD new ECC mode NAND_ECC_HW_OOB_FIRST

[Matt Waddel]

Hi Scott and Sandeep,

As long as we're looking at these patches again I had a question about 
patch 1 of 2 in this series.  

The following part of the patch added a definition for: 

chip->ecc.read_page = nand_read_page_hwecc_oob_first

but since there aren't any "break" statements until "case NAND_ECC_SOFT:" 
it looks like the chip->ecc.read_page definition ends up being set to:

chip->ecc.read_page = nand_read_page_swecc.

Maybe this is explains why things seem to be working???

Best regards,
Matt

+   case NAND_ECC_HW_OOB_FIRST:
+   /* Similar to NAND_ECC_HW, but a separate read_page handle */
+   if (!chip->ecc.calculate || !chip->ecc.correct ||
+!chip->ecc.hwctl) {
+   printk(KERN_WARNING "No ECC functions supplied, "
+  "Hardware ECC not possible\n");
+   BUG();
+   }
+   if (!chip->ecc.read_page)
+   chip->ecc.read_page = nand_read_page_hwecc_oob_first;
+


On Tuesday 01 September 2009 01:19:09 pm Scott Wood wrote:
> Paulraj, Sandeep wrote:
> >> John Rigby wrote:
> >>> Sorry for the late comments.  We have been trying to use this code with
> >>> the associated davinci 4-bit ecc patches and have some questions
> > We use this internally and it works. Are you having any issues because we 
> > don't see any!!
> 
> Calm down, just because it works doesn't mean nobody should ask 
> questions about the code.
> 
> >>> Here you calculate ecc then never use the result?
> >> Hmm, that looks wrong, both here and in the davinci driver.  Are the two
> >> calls to nand_davinci_4bit_readecc reading different things?  Does the
> >> calculate function have any side effects beyond producing data that is
> >> never used?
> > Have you reads the patch description. Maybe that might help a bit
> > 
> > This patch adds the new mode NAND_ECC_HW_OOB_FIRST in the nand code to
> > support 4-bit ECC on TI DaVinci devices with large page (up to 2K) NAND
> > chips.  This ECC mode is similar to NAND_ECC_HW, with the exception of
> > read_page API that first reads the OOB area, reads the data in chunks,
> > feeds the ECC from OOB area to the ECC hw engine and perform any
> > correction on the data as per the ECC status reported by the engine.
> 
> Yes, I've read that.  That doesn't explain why calculate_ecc is 
> producing data, *after* everything has been read, that is never consumed 
> by anything (hardware or software) AFAICT.  It doesn't explain why the 
> "generic" code is passing NULL to ecc.correct.
> 
> -Scott
> ___
> 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 2/2] MTD:NAND: ADD new ECC mode NAND_ECC_HW_OOB_FIRST

[Scott Wood]

Matt Waddel wrote:
> Hi Scott and Sandeep,
> 
> As long as we're looking at these patches again I had a question about 
> patch 1 of 2 in this series.  
> 
> The following part of the patch added a definition for: 
> 
> chip->ecc.read_page = nand_read_page_hwecc_oob_first
> 
> but since there aren't any "break" statements until "case NAND_ECC_SOFT:" 
> it looks like the chip->ecc.read_page definition ends up being set to:
> 
> chip->ecc.read_page = nand_read_page_swecc.
> 
> Maybe this is explains why things seem to be working???

No, that's OK -- it stops before that on the
"if (mtd->writesize >= chip->ecc.size) break;" line (or if that 
condition is not true, it prints a warning that it is falling back on 
soft ecc).

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

Re: [U-Boot] [PATCH 1/2] Move uninitialized_var() macro from ubi_uboot.h to compiler.h

[Anton Vorontsov]

On Tue, Sep 01, 2009 at 08:52:33PM +0200, Albin Tonnerre wrote:
[...]
> > > > +/* compiler options */
> > > > +#define uninitialized_var(x)   x = x
> > > 
> > > Please excuse my ignorance, but where and what for is such a
> > > definition useful?
> > 
> > It's used to avoid GCC warnings, i.e. when GCC isn't smart enough
> > to see that some variable isn't actually used uninitialized.
> > 
> > ~/linux-2.6$ git grep uninitialized_var drivers/ | wc -l
> > 94
> 
> You seem to be grepping the linux source tree.

Yes, which is a great source of best practices.

Thanks,

-- 
Anton Vorontsov
email: cbouatmai...@gmail.com
irc://irc.freenode.net/bd2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] fsl: sys_eeprom: Fix 'may be used uninitialized' warning

[Wolfgang Denk]

Dear Anton Vorontsov,

In message <20090901182914.ga19...@oksana.dev.rtsoft.ru> you wrote:
> On Tue, Sep 01, 2009 at 08:16:26PM +0200, Wolfgang Denk wrote:
> > Dear Anton Vorontsov,
> > 
> > In message <20090901165902.ga6...@oksana.dev.rtsoft.ru> you wrote:
> > > The warning is bogus, so silence it with uninitialized_var().
> > 
> > Which tool chain issues a warning here?
> 
> gcc version 4.0.0 (DENX ELDK 4.0 4.0.0) ;-)

Heh, indeed.

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
A Chairman was as necessary to a Board planet  as  the  zero  was  in
mathematics, but being a zero had big disadvantages...
 - Terry Pratchett, _The Dark Side of the Sun_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] Move uninitialized_var() macro from ubi_uboot.h to compiler.h

[Wolfgang Denk]

Dear Anton Vorontsov,

In message <20090901182518.ga17...@oksana.dev.rtsoft.ru> you wrote:
>
> We can fix the warnings by assigning some value to a variable
> at declaration, but the advantage of 'x = x' trick is that it
> doesn't generate any code.

Argh... what a clev^H^H^H^Hdirty trick.

Thanks for the explanation.

However, in this case it seems to make sense to me to explicitly
initialize the return code with zero.

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
A man either lives life as it happens to him, meets  it  head-on  and
licks it, or he turns his back on it and starts to wither away.
-- Dr. Boyce, "The Menagerie" ("The Cage"), stardate unknown
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] fsl: sys_eeprom: Fix 'may be used uninitialized' warning

[Wolfgang Denk]

Dear Anton Vorontsov,

In message <20090901180613.ga10...@oksana.dev.rtsoft.ru> you wrote:
>
> Another option is to turn the for loop into do {} while, so
> we can avoid unitialized_var() usage. Something like that:

This is much more difficult to read.


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
Witch!  Witch!  They'll burn ya!
-- Hag, "Tomorrow is Yesterday", stardate unknown
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Virtual addresses, u-boot, and the MMU

[Wolfgang Denk]

Dear "J. William Campbell",

In message <4a9d5ef2.4030...@comcast.net> you wrote:
>   I have followed the recent discussions about problems in the CFI 
> driver caused by the need to change the attributes of the address at 
> which the flash is mapped. This discussion has raised some questions in 
> my mind regarding the assumptions u-boot makes regarding the behavior of 
> the addresses used in the code. I am writing this message for comments 
> that may correct any mis-understandings I have. First, the addresses 
> used by the u-boot program to reference memory and code are all 
> "virtual" addresses (VA) because they go through the MMU  to become a 
> physical address(PA). If there is no MMU, the virtual address and the 
> physical address are identical.

Even if there is a MMU, we keep it "switched off" on most systems, or
otherwise set it up in such a way that there is still a 1:1  mapping,
i. e. the virtual address and physical address are identical, too.

There have been several discussions concerning this topic on IRC
(#u-boot at freenode); I'll try to summarize these here - not sure
though if I don't miss anything: please feel free to complement what
might be missing.

[Times are MET/MEST]

Nov 20, 2008:

[19:40:03] galak: do we think of nand->IO_ADDR_R as a physical or virtual addr?
[19:40:10] scottwood: Wouldn't it need to change on Linux too?
[19:40:42] galak: don't know do we does drivers/mtd/nand/fsl_elbc_nand.c look 
the same in linux?
[19:40:48] scottwood: IO_ADDR_R is virtual
[19:41:01] scottwood: So it needs to change with virt != phys
[19:41:51] galak: ok, so this loop in board_nand_init():
[19:41:51] galak: for (priv->bank = 0; priv->bank < MAX_BANKS; 
priv->bank++) {
[19:41:51] galak: br = 
in_be32(&elbc_ctrl->regs->bank[priv->bank].br);
[19:41:51] galak: or = 
in_be32(&elbc_ctrl->regs->bank[priv->bank].or);
[19:41:51] galak: 
[19:41:52] galak: if ((br & BR_V) && (br & BR_MSEL) == 
BR_MS_FCM &&
[19:41:54] galak: (br & or & BR_BA) == nand->IO_ADDR_R)
[19:41:56] galak: break;
[19:41:58] galak: }
[19:42:24] galak: use comparing a virt (IO_ADDR_R) with physical (br & or & 
BR_BA)
[19:43:25] scottwood: Right, it assumess identity mapping.  We'll need some way 
of finding the physical address now.
[19:45:06] scottwood: Does eLBC just ignore the upper 4 bits of the physical 
address, and rely on LAWs for that?
[19:45:16] galak: yep
[19:45:31] galak: which makes this slightly more annoying
[19:47:21] galak: we could have board code implement a function that deals with 
the mapping (given IO_ADDR_R, it hands bank the bank #)
[19:47:36] scottwood: I'd rather not make it board-specific.
[19:47:56] scottwood: Is there a general virt-to-phys function in u-boot?
[19:49:10] galak: nope
[19:49:27] scottwood: There probably should be.
[19:49:38] galak: agreed, but that a huge overhaul
[19:50:29] scottwood: How many other platforms have virt != phys?
[19:50:56] galak: not sure, probably none
[19:51:10] scottwood: So virt_to_phys could do tlbsx on book-e and return the 
argument on everything else.
[19:51:36] galak: yeah, we could do that
[19:52:23] galak: we should probably have it walk BATs on classic
[19:52:33] scottwood: yeah
[19:53:57] galak: what do you think the API for virt_to_phys() looks like?  
(how to report error if no mapping exists?)
[19:54:54] scottwood: Could return ~0, or have the physical address returned 
via pointer.
[19:57:32] galak: ok..will work something up
[19:58:17] scottwood: thanks

Nov 26, 2008:

[20:09:43] beckyb: it's the whole virtual vs physical address question
[20:10:04] beckyb: when I did the 36b stuff that's in the tree now, I went for 
the minimally invasive approach
[20:10:27] beckyb: so, at the moment, all the command-line stuff takes a 
*virtual* address as an argument
[20:10:41] beckyb: I'm wondering if that's really what we want
[20:17:18] beckyb: wdenk_: The whole issue has come up because with galak's 
map_physmem patches, we have to actually start distinguishing between the 2 
kinds of addresses inside u-boot
[20:17:50] beckyb: right now, the 36-bit code is taking advantage of the fact 
that u-boot doesn't know the difference
[20:18:20] beckyb: so the *physical* address only really exists right now in 
the MMU mapping
[20:18:33] beckyb: and in a few other places that actually care about the PA
[20:18:39] beckyb: I'll stop babbling now 
[20:20:39] wdenk_: beckyb: I have to admit that I don't see the immediate 
problem yet.
[20:20:56] beckyb: wdenk_: OK, I'll babble some more 
[20:21:00] wdenk_: beckyb: So far, everybody seems to be happy with using 
virtual addresses.
[20:21:01] beckyb: Let me use a concrete example
[20:21:14] beckyb: wdenk_: and I'm *fine* if we stick with that
[20:21:26] beckyb: I just want to be sure that's what we really want
[20:21:54] beckyb: I've been working on the flash code, which stores the 
physical secto

Re: [U-Boot] Large Block USB Flash Drive Problem

[Remy Bohmer]

Hi,

>> Well, there was a patch posted for this some time ago:
>> http://www.mail-archive.com/u-boot@lists.denx.de/msg05444.html
>> But, this patch broke several 512 byte blocksize devices, so I did not
>> push it to mainline.
>> You might take a look at it, maybe it solves your problem.
>> If you can make it work properly with 512 byte devices as well, I am
>> in for a patch...
>        Do you know if anyone is actively working on this issue?

Not that I am aware of...

> I tried applying the patch to the most recent U-Boot but it doesn't apply 
>cleanly.
> If no one is working on it, I might try to take a look at updating the patch 
>and fixing the issue.

Great!

> Is this not a big issue with people using USB flash drives?
> It seems I'm running into more and more "large block" flash drives.

I heard no complains so far...

> Also, while clicking around the Git repo, I noticed that USB Ethernet support 
> for the AT91 micros was added
> to U-Boot development.  How far along is the USB Ethernet support?  Is it 
> something that can be tested now?

Well, it should be fully operational, and I need to be push it to mainline.
I left it in the u-boot-usb tree for the time being, because the
ARM-subsystem (and lib_arm) was changing a lot lately and I was
waiting until that was stabilised. Probably something for the next
release... Currently the patches are split up in such a way that I can
even push it forward without the ARM support.

Kind regards,

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

Re: [U-Boot] [PATCH 2/2] MTD:NAND: ADD new ECC mode NAND_ECC_HW_OOB_FIRST

[Scott Wood]

Paulraj, Sandeep wrote:
>> John Rigby wrote:
>>> Sorry for the late comments.  We have been trying to use this code with
>>> the associated davinci 4-bit ecc patches and have some questions
> We use this internally and it works. Are you having any issues because we 
> don't see any!!

Calm down, just because it works doesn't mean nobody should ask 
questions about the code.

>>> Here you calculate ecc then never use the result?
>> Hmm, that looks wrong, both here and in the davinci driver.  Are the two
>> calls to nand_davinci_4bit_readecc reading different things?  Does the
>> calculate function have any side effects beyond producing data that is
>> never used?
> Have you reads the patch description. Maybe that might help a bit
> 
> This patch adds the new mode NAND_ECC_HW_OOB_FIRST in the nand code to
> support 4-bit ECC on TI DaVinci devices with large page (up to 2K) NAND
> chips.  This ECC mode is similar to NAND_ECC_HW, with the exception of
> read_page API that first reads the OOB area, reads the data in chunks,
> feeds the ECC from OOB area to the ECC hw engine and perform any
> correction on the data as per the ECC status reported by the engine.

Yes, I've read that.  That doesn't explain why calculate_ecc is 
producing data, *after* everything has been read, that is never consumed 
by anything (hardware or software) AFAICT.  It doesn't explain why the 
"generic" code is passing NULL to ecc.correct.

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

Re: [U-Boot] API License Terms

[Rafal Jaworowski]

On 2009-09-01, at 20:08, Wolfgang Denk wrote:

>> 3)   If presume that we cannot use the GPLv2 glue files in a  
>> closed
>> source application.
>
> Correct.

There's also a BSD licensed version of the gluing code and the syscall  
entry, which is used for integration of the FreeBSD loader(8) with U- 
Boot through the API, so maybe using this code would be an option:

http://svn.freebsd.org/base/head/sys/boot/uboot/lib/glue.{c,h}
http://svn.freebsd.org/base/head/sys/boot/powerpc/uboot/start.S

Rafal

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

Re: [U-Boot] [PATCH 1/2] Move uninitialized_var() macro from ubi_uboot.h to compiler.h

[Albin Tonnerre]

On Tue, Sep 01, 2009 at 10:25:18PM +0400, Anton Vorontsov wrote :
> On Tue, Sep 01, 2009 at 08:11:41PM +0200, Wolfgang Denk wrote:
> > Dear Anton Vorontsov,
> > 
> > In message <20090901165803.ga3...@oksana.dev.rtsoft.ru> you wrote:
> > > This is needed so that we could use this macro for non-UBI code.
> > > 
> > > Signed-off-by: Anton Vorontsov 
> > > ---
> > >  include/compiler.h  |3 +++
> > >  include/ubi_uboot.h |4 +---
> > >  2 files changed, 4 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/include/compiler.h b/include/compiler.h
> > > index 272fd3c..e602cce 100644
> > > --- a/include/compiler.h
> > > +++ b/include/compiler.h
> > > @@ -122,4 +122,7 @@ typedef unsigned intuintptr_t;
> > >  
> > >  #endif
> > >  
> > > +/* compiler options */
> > > +#define uninitialized_var(x) x = x
> > 
> > Please excuse my ignorance, but where and what for is such a
> > definition useful?
> 
> It's used to avoid GCC warnings, i.e. when GCC isn't smart enough
> to see that some variable isn't actually used uninitialized.
> 
> ~/linux-2.6$ git grep uninitialized_var drivers/ | wc -l
> 94

You seem to be grepping the linux source tree. The whole U-boot codebase
contains only 10 of them.

> We can fix the warnings by assigning some value to a variable
> at declaration, but the advantage of 'x = x' trick is that it
> doesn't generate any code.

I'm not quite sure that would be noticeable given the number of uses (I don't
have any opinion as to whether we should initialize them properly, though).

Regards,
-- 
Albin Tonnerre, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com


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] API License Terms

[Daniel Sherwood]

Wolfgang

> > Please can someone clarify the following points regarding the
'Consumer
> > API' which we wish to use to access the environment from the core
> > application of a commercial closed source product.
> 
> There is no such thing as a "consumer API".
> 
> > 1)   Is it true that the so called 'consumer application' can
use
> > this API and remain closed source - if so, where in the license
> > information is this made clear?
> 
> I guess you might be referring to standalone applications here. And
> the licensing for these is described right at the beginning of the
> license file "COPYING".
[Daniel Sherwood] No, I am referring to the code contributed by Rafel
under api/* and examples/api/* (although these directories may have been
renamed more recently).  

> The API code implemented by Rafal (abi/* and examples/abi/*) is *not*
> part of  the  exception  for  standalone  programs;  instead,  it  is
> licensed under GPL. The source code makes this pretty clear.
[Daniel Sherwood] The include/api_public.h header file is clearly dual
licensed as GPLv2/BSD implying that it can be used as a public API from
non-GPL code - indeed I believe there are examples around of this being
accessed from BSD.  Surely this is already effectively an exception (as
BSD is not released under GPLv2 but can link with this API).

> Of course you can always reconsider and release your code under GPL -
> that would be the most natural thing given  the  fact  that  you  are
> taking man-years worth of source code for free.
[Daniel Sherwood] We will be releasing the changes and improvements we
have made to u-Boot itself as part of our project (the main one being
support for digital signature checking in the boot code), however we are
not in a position to release our core application - the only link we
have with u-Boot code is that we also wish to access the environment
variables.  If we have no other option, we will write clean versions of
getenv, setenv and saveenv for our application.

> > Also, following on from these points, how would we go about
extending
> > the API?  Specifically, we would like to add a saveenv function to
the
> > API - is it legitimate for us to simply extend the API to add this
> > functionality - provided we publish our changes to u-boot as per the
GPL
> > - without compromising our core application code as closed source?
> 
> Most probably you will need to include header files in addition to
> those explicitly allowed in the "COPYING" file. This would require
> you to release your code under GPL.
Indeed, we would need to include api_public.h (which we can do under the
BSD license), therefore it becomes an issue of a) the legitimacy of
locating and calling the syscall function from our application and b)
extending the available syscall within u-Boot (which of course would be
released under our GPL obligations).

Cheers

Daniel 


The information in this email is confidential. It is intended
solely for the addressee. Access to this email by anyone else
is unauthorised. If you are not the intended recipient, any
disclosure, copying, or distribution is prohibited and may be
unlawful. If you have received this email in error please delete
it immediately and contact commerc...@sepura.com.

Sepura plc. Registered Office: Radio House, St Andrew’s Road, Cambridge, CB4 
1GR, England. Registered in England and Wales. Registration Number 4353801
 ___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] fsl: sys_eeprom: Fix 'may be used uninitialized' warning

[Timur Tabi]

Anton Vorontsov wrote:
> The warning is bogus, so silence it with uninitialized_var().
> 
> Signed-off-by: Anton Vorontsov 
> ---

Acked-by: Timur Tabi 

-- 
Timur Tabi
Linux kernel developer at Freescale
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] I2c imd/imw for a digital potentiometer?

[Andrew Dyer]

On Tue, Sep 1, 2009 at 12:50 PM, Brian Hutchinson wrote:
> Hi all,
>
> I'm a little stumped as to how to write to a EEPot with the imw command.
>
> The EEPot is a Maxim 5434 and has an address of 0x28.  To write to its
> volatile or non-volatile register ... a command byte is given.
>
> Writing 5 bits of data (it is a 32 tap pot so that is where the 5 bits come
> from) to move the wiper goes something like this:
>
> Start, 0x28, Ack, Cmd byte, Ack, Data byte, Ack, Stop
>
> Cmd byte is 0x11 to write to volatile reg. 0x21 to write to non-volatile
> reg.
>
> The EEPROM really doesn't have addresses/offsets so I tried:
>
> imw 28 11 80 1

I believe this should do what you want.  You could make double sure by
doing imw 28 11.1 80
the .1 forces a one byte address.  You don't need the trailing one
count.  Verify the device is asserting the ACK after each byte is sent
with a 'scope.

You also didn't mention what version code you're on.   The soft_i2c.c
code had some bugs in it that would result in extra transitions if the
I/O had separate tristate enables that I patched a year or two ago.
You should make sure you're on the latest.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] fsl: sys_eeprom: Fix 'may be used uninitialized' warning

[Anton Vorontsov]

On Tue, Sep 01, 2009 at 08:16:26PM +0200, Wolfgang Denk wrote:
> Dear Anton Vorontsov,
> 
> In message <20090901165902.ga6...@oksana.dev.rtsoft.ru> you wrote:
> > The warning is bogus, so silence it with uninitialized_var().
> 
> Which tool chain issues a warning here?

gcc version 4.0.0 (DENX ELDK 4.0 4.0.0) ;-)

Thanks,

-- 
Anton Vorontsov
email: cbouatmai...@gmail.com
irc://irc.freenode.net/bd2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] fsl: sys_eeprom: Fix ' may be used uninitialized' warningп

[Anton Vorontsov]

On Tue, Sep 01, 2009 at 01:09:26PM -0500, Timur Tabi wrote:
> Anton Vorontsov wrote:
> 
> > -   for (i = 0, p = &e; i < sizeof(e); i += 8, p += 8) {
> > +   do {
> > ret = i2c_write(CONFIG_SYS_I2C_EEPROM_ADDR, i, 
> > CONFIG_SYS_I2C_EEPROM_ADDR_LEN,
> > -   p, min((sizeof(e) - i), 8));
> > +   (void *)&e + i, min((sizeof(e) - i), 8));
> > if (ret)
> > break;
> > udelay(5000);   /* 5ms write cycle timing */
> > -   }
> > +   i += 8;
> > +   } while (i < sizeof(e));
> 
> Or we could remove the loop altogether and just do the write in one shot.  Is 
> there any reason to believe that any of Freescale's 8[356]xx boards can't 
> handle a large I2C block write of about 50 bytes or so?

I guess "udelay(5000);  /* 5ms write cycle timing */" hints that
it's EEPROM chip dependant, so has nothing to do with i2c controller
capabilities.

Thanks,

-- 
Anton Vorontsov
email: cbouatmai...@gmail.com
irc://irc.freenode.net/bd2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] Move uninitialized_var() macro from ubi_uboot.h to compiler.h

[Anton Vorontsov]

On Tue, Sep 01, 2009 at 08:11:41PM +0200, Wolfgang Denk wrote:
> Dear Anton Vorontsov,
> 
> In message <20090901165803.ga3...@oksana.dev.rtsoft.ru> you wrote:
> > This is needed so that we could use this macro for non-UBI code.
> > 
> > Signed-off-by: Anton Vorontsov 
> > ---
> >  include/compiler.h  |3 +++
> >  include/ubi_uboot.h |4 +---
> >  2 files changed, 4 insertions(+), 3 deletions(-)
> > 
> > diff --git a/include/compiler.h b/include/compiler.h
> > index 272fd3c..e602cce 100644
> > --- a/include/compiler.h
> > +++ b/include/compiler.h
> > @@ -122,4 +122,7 @@ typedef unsigned intuintptr_t;
> >  
> >  #endif
> >  
> > +/* compiler options */
> > +#define uninitialized_var(x)   x = x
> 
> Please excuse my ignorance, but where and what for is such a
> definition useful?

It's used to avoid GCC warnings, i.e. when GCC isn't smart enough
to see that some variable isn't actually used uninitialized.

~/linux-2.6$ git grep uninitialized_var drivers/ | wc -l
94

We can fix the warnings by assigning some value to a variable
at declaration, but the advantage of 'x = x' trick is that it
doesn't generate any code.

Thanks,

-- 
Anton Vorontsov
email: cbouatmai...@gmail.com
irc://irc.freenode.net/bd2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] I2c imd/imw for a digital potentiometer?

[Jerry Van Baren]

Brian Hutchinson wrote:
> Hi all,
> 
> I'm a little stumped as to how to write to a EEPot with the imw command.
> 
> The EEPot is a Maxim 5434 and has an address of 0x28.  To write to its
> volatile or non-volatile register ... a command byte is given.
> 
> Writing 5 bits of data (it is a 32 tap pot so that is where the 5 bits come
> from) to move the wiper goes something like this:
> 
> Start, 0x28, Ack, Cmd byte, Ack, Data byte, Ack, Stop
> 
> Cmd byte is 0x11 to write to volatile reg. 0x21 to write to non-volatile
> reg.

Looks pretty standard if you map "cmd byte" to "register".

> The EEPROM really doesn't have addresses/offsets so I tried:
> 
> imw 28 11 80 1

What is the trailing '1' here?  Or is the '80' bogus?

I would expect this to work.  The i2c command defaults to a one byte 
register offset.  To write a 0x80 byte to register (aka command) 0x11, 
you want to do this:
   imw 28 11.1 80
which should be the same as this:
   imw 28 11 80

> imw.w 28 0.0 1180

That seems like it should work also, although the '11' is more logically 
a register offset.

> ... but it doesn't appear to play well with my device.

Trivia: the old imw (imr, etc) commands are deprecated, you should use 
the new "i2c " versions.

[snip]

> Regards,
> 
> Brian

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

Re: [U-Boot] [PATCH 2/2] fsl: sys_eeprom: Fix 'may be used uninitialized' warning

[Wolfgang Denk]

Dear Anton Vorontsov,

In message <20090901165902.ga6...@oksana.dev.rtsoft.ru> you wrote:
> The warning is bogus, so silence it with uninitialized_var().

Which tool chain issues a warning here?

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
Change is the essential process of all existence.
-- Spock, "Let That Be Your Last Battlefield",
   stardate 5730.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] Move uninitialized_var() macro from ubi_uboot.h to compiler.h

[Wolfgang Denk]

Dear Anton Vorontsov,

In message <20090901165803.ga3...@oksana.dev.rtsoft.ru> you wrote:
> This is needed so that we could use this macro for non-UBI code.
> 
> Signed-off-by: Anton Vorontsov 
> ---
>  include/compiler.h  |3 +++
>  include/ubi_uboot.h |4 +---
>  2 files changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/include/compiler.h b/include/compiler.h
> index 272fd3c..e602cce 100644
> --- a/include/compiler.h
> +++ b/include/compiler.h
> @@ -122,4 +122,7 @@ typedef unsigned intuintptr_t;
>  
>  #endif
>  
> +/* compiler options */
> +#define uninitialized_var(x) x = x

Please excuse my ignorance, but where and what for is such a
definition useful?

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
Faith may be defined briefly as an illogical belief in the  occurence
of the improbable.- H. L. Mencken
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] invalid core multipliers?

[Kári Davíðsson]

Hello,

I am bootstrapping an mpc5121e board.

When the cpu speed is calculated (cpu/mpc512x/speed.c) there is a comment about
all core pll settings above 7 are invalid

I can't see anything about that in the CPU documentation so I am wondering if
anyone has reference to where this is defined as invalid.

The board I am using is using CORE PLL index 0x8, i.e. multiplier of 4.

If this comment in the code is wrong then the following patch should be o.k...

Index: cpu/mpc512x/speed.c
===
--- cpu/mpc512x/speed.c (revision 635)
+++ cpu/mpc512x/speed.c (working copy)
@@ -44,7 +44,7 @@
{1, 1}, {3, 2},
{2, 1}, {5, 2},
{3, 1}, {7, 2},
-   {0, 1}, {0, 1}, /* and all above 7 are not valid too */
+   {4, 1}, {0, 1}, /* and all above 7 are not valid too I doubt this 
claim */
{0, 1}, {0, 1},
{0, 1}, {0, 1},
{0, 1}, {0, 1}

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

Re: [U-Boot] [PATCH 2/2] fsl: sys_eeprom: Fix 'may be used uninitialized' warning

[Timur Tabi]

Anton Vorontsov wrote:

> - for (i = 0, p = &e; i < sizeof(e); i += 8, p += 8) {
> + do {
>   ret = i2c_write(CONFIG_SYS_I2C_EEPROM_ADDR, i, 
> CONFIG_SYS_I2C_EEPROM_ADDR_LEN,
> - p, min((sizeof(e) - i), 8));
> + (void *)&e + i, min((sizeof(e) - i), 8));
>   if (ret)
>   break;
>   udelay(5000);   /* 5ms write cycle timing */
> - }
> + i += 8;
> + } while (i < sizeof(e));

Or we could remove the loop altogether and just do the write in one shot.  Is 
there any reason to believe that any of Freescale's 8[356]xx boards can't 
handle a large I2C block write of about 50 bytes or so?

-- 
Timur Tabi
Linux kernel developer at Freescale
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] API License Terms

[Wolfgang Denk]

Dear Daniel,

In message <7b12c7cf8eb6734f9c50a406cd99bed205acf...@mail01b> you wrote:
> 
> Please can someone clarify the following points regarding the 'Consumer
> API' which we wish to use to access the environment from the core
> application of a commercial closed source product.

There is no such thing as a "consumer API".

> 1)   Is it true that the so called 'consumer application' can use
> this API and remain closed source - if so, where in the license
> information is this made clear?

I guess you might be referring to standalone applications here. And
the licensing for these is described right at the beginning of the
license file "COPYING".

> 2)   Who has agreed (or has to agree) that this is acceptable use?

Right in the beginning, when U-Boot (or rathewr "PPCBoot", as it  was
calkled  by  then) was basicly written by myself only, I came up with
this notion of allowing a certain, well-defined (and pretty  strictly
restrited) set of closed-source extensions.

> It's all very well Rafal adding the code and a 'public' header file with
> a BSD license - but surely all of the authors that have contributed to
> code accessed through this API would have to consent to these terms.

The API code implemented by Rafal (abi/* and examples/abi/*) is *not*
part of  the  exception  for  standalone  programs;  instead,  it  is
licensed under GPL. The source code makes this pretty clear.

> 3)   If presume that we cannot use the GPLv2 glue files in a closed
> source application.

Correct.

> We need to understand these points before we can proceed with code that
> interacts with this API.

For closed source extensions, your only option is what is available
via standalone applications, restricted as it is.

Of course you can always reconsider and release your code under GPL -
that would be the most natural thing given  the  fact  that  you  are
taking man-years worth of source code for free.

> Also, following on from these points, how would we go about extending
> the API?  Specifically, we would like to add a saveenv function to the
> API - is it legitimate for us to simply extend the API to add this
> functionality - provided we publish our changes to u-boot as per the GPL
> - without compromising our core application code as closed source?

Most probably you will need to include header files in addition to
those explicitly allowed in the "COPYING" file. This would require
you to release your code under GPL.

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
>  Is there a way to determine Yesterday's date using Unix utilities?
 echo "what is yesterday's date?" | /bin/mail root
 -- Randal L. Schwartz in 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] fsl: sys_eeprom: Fix 'may be used uninitialized' warning

[Anton Vorontsov]

On Tue, Sep 01, 2009 at 09:38:14PM +0400, Anton Vorontsov wrote:
[...]
> > >static int prog_eeprom(void)
> > >{
> > >-  int ret, i;
> > >+  int uninitialized_var(ret);
> > >+  int i;
> > 
> > why don't we init ret = 0;  seems like we should be doing that since
> > we might not enter the for loop
> 
> No, we always enter the for loop:
> 
> for (i = 0, p = &e; i < sizeof(e); i += 8, p += 8) {
> 
> sizeof(e) always > 0 because:
> 
> #if !defined(CONFIG_SYS_I2C_EEPROM_CCID) && 
> !defined(CONFIG_SYS_I2C_EEPROM_NXID)
> #error "Please define either CONFIG_SYS_I2C_EEPROM_CCID or 
> CONFIG_SYS_I2C_EEPROM_NXID"
> #endif
> 
> static struct __attribute__ ((__packed__)) eeprom {
> #ifdef CONFIG_SYS_I2C_EEPROM_CCID
> u8 id[4]; /* 0x00 - 0x03 EEPROM Tag 'CCID' */
> ...
> #endif
> #ifdef CONFIG_SYS_I2C_EEPROM_NXID
> u8 id[4]; /* 0x00 - 0x03 EEPROM Tag 'NXID' */
> ...
> #endif
> } e;

Another option is to turn the for loop into do {} while, so
we can avoid unitialized_var() usage. Something like that:

diff --git a/board/freescale/common/sys_eeprom.c 
b/board/freescale/common/sys_eeprom.c
index c0fff68..a4e0980 100644
--- a/board/freescale/common/sys_eeprom.c
+++ b/board/freescale/common/sys_eeprom.c
@@ -204,8 +204,8 @@ static void update_crc(void)
  */
 static int prog_eeprom(void)
 {
-   int ret, i;
-   void *p;
+   int ret;
+   int i = 0;
 #ifdef CONFIG_SYS_EEPROM_BUS_NUM
unsigned int bus;
 #endif
@@ -224,13 +224,14 @@ static int prog_eeprom(void)
i2c_set_bus_num(CONFIG_SYS_EEPROM_BUS_NUM);
 #endif
 
-   for (i = 0, p = &e; i < sizeof(e); i += 8, p += 8) {
+   do {
ret = i2c_write(CONFIG_SYS_I2C_EEPROM_ADDR, i, 
CONFIG_SYS_I2C_EEPROM_ADDR_LEN,
-   p, min((sizeof(e) - i), 8));
+   (void *)&e + i, min((sizeof(e) - i), 8));
if (ret)
break;
udelay(5000);   /* 5ms write cycle timing */
-   }
+   i += 8;
+   } while (i < sizeof(e));
 
 #ifdef CONFIG_SYS_EEPROM_BUS_NUM
i2c_set_bus_num(bus);
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Virtual addresses, u-boot, and the MMU

[J. William Campbell]

  I have followed the recent discussions about problems in the CFI 
driver caused by the need to change the attributes of the address at 
which the flash is mapped. This discussion has raised some questions in 
my mind regarding the assumptions u-boot makes regarding the behavior of 
the addresses used in the code. I am writing this message for comments 
that may correct any mis-understandings I have. First, the addresses 
used by the u-boot program to reference memory and code are all 
"virtual" addresses (VA) because they go through the MMU  to become a 
physical address(PA). If there is no MMU, the virtual address and the 
physical address are identical.
The "normal", or legacy,policy for u-boot is to arrange a memory 
map such that all physical addresses are mapped to some virtual address. 
Originally, the mapping were such that the VA was actually == the PA, 
but today on some CPUs, this is not possible. When the size of the 
physical address space exceeds the size of the virtual address space, 
the VA may not =- the PA numerically, but there is a one-to-one 
correspondence. It MAY also acceptable to map the same PA so that it 
appears more than once in the address space (VA), but if this is done, 
any references inside u-boot (such as in drivers) must be consistent, 
i.e. the flash chip must exist at exactly one virtual address from 
u-boots viewpoint. This is required because the u-boot drivers maintain 
pointers into the flash, and it is important to be able to compare these 
pointers to input virtual addresses. It is also necessary that the VA of 
the flash chip not change after the driver has been set up, or else any 
saved pointers will be wrong.
  Becky Bruce "re-wrote the driver to use VAs instead of PAs." I am 
not exactly sure what this means, but I assume it meant allowing the VA 
referencing the flash
to be distinct from the PA where the flash "lives" (and may require 36 
bits on a PPC system to represent the PA). Does the driver re-map 
portions of the flash in order to access them? If the flash is really 
large, I can certainly see a need to do so. However, I assume on "medium 
size" flashes, it does not need to remap. In that case, don't all 
references just go through the MMU and get translated? The VA != PA, but 
from the point of view of u-boot, the VA is the only address that 
matters. The AVR32 certainly does not map flash dynamically, so it would 
not matter on that CPU.
  The issue with the CFI driver on the AVR32 is that it needs to 
disable cache on the address space of the flash memory when it is 
writing to the flash. This apparently is not trivial to do, but there is 
a second mapping that does have the cache off. Wolfgang has recommended 
the creation of a function to turn off the cache for the flash area, and 
also (presumably) one to turn the flash back on when the write is 
complete. Haavard has at present a function that returns an alternate 
address with the cache already off that addresses the same memory. This 
wouldn't cause a problem if the mapping happened immediately before the 
actual copy operation took place and was used for nothing else. However, 
if it happens early on in the driver, the address will not match the 
structure set up by the rest of the flash code using the non-translated 
address.
Therefore, I have the following questions: If the map_physmem() 
macro is removed from the driver on the AVR32, does the driver work if 
it is told that the flash PA=VA = the un-cached address? If not, why 
not? Shouldn't this be just like any CFI on an un-cached PPC address? 
The driver will be somewhat slower reading but otherwise it should work. 
If/when it does work, couldn't a map_in_cache() macro be placed directly 
in front of the read code that copies data from flash to other buffers. 
The macro would return an address of the same data referenced through a 
cached address if it exists. This address would go nowhere else and 
never be stored anywhere. This would speed up the copy operation for 
situations where it matters, and is applicable to all platforms that can 
do such a thing. The most general solution would be a call to 
map_in_cache/map_in_not_cache for both reads and writes in the CFI 
driver. These routines would return a "substitute" address (or the same 
input one), and may actually add another mapping dynamically, use a 
pre-existing appropriate mapping, just turn on/turn off data cache 
globally, or do nothing). At the end of the copy, map_restore() would 
put the map back  By default, the assumption would be that the flash is 
not cached and the macros do nothing. Sounds simple to me, what have I 
overlooked?

Bill Campbell
> Haavard Skinnemoen wrote:
>
> 
>
>   
>> Right...I'm beginning to doubt that anyone is familiar enough with the
>> u-boot code, since everyone seems to have their own opinion about how
>> things are supposed to work.
>>
>> To summarize, here are the possible ways to fix the problem as I see it:

[U-Boot] I2c imd/imw for a digital potentiometer?

[Brian Hutchinson]

Hi all,

I'm a little stumped as to how to write to a EEPot with the imw command.

The EEPot is a Maxim 5434 and has an address of 0x28.  To write to its
volatile or non-volatile register ... a command byte is given.

Writing 5 bits of data (it is a 32 tap pot so that is where the 5 bits come
from) to move the wiper goes something like this:

Start, 0x28, Ack, Cmd byte, Ack, Data byte, Ack, Stop

Cmd byte is 0x11 to write to volatile reg. 0x21 to write to non-volatile
reg.

The EEPROM really doesn't have addresses/offsets so I tried:

imw 28 11 80 1
imw.w 28 0.0 1180

... but it doesn't appear to play well with my device.

I'm in a bitbanged I2C environment (with GPIO) on a ARM9 core and I can
write to RTC and EEPROM just fine.

So, will uboot I2C commands handle a device like this (address command
data)?

I've been grepping code and searching this mail list and kernel drivers
(lm-sensor's) and I can't find any examples of EEpots being used in u-boot
or the Linux kernel.

Regards,

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

Re: [U-Boot] [PATCH 2/2] fsl: sys_eeprom: Fix 'may be used uninitialized' warning

[Anton Vorontsov]

On Tue, Sep 01, 2009 at 12:30:53PM -0500, Kumar Gala wrote:
> 
> On Sep 1, 2009, at 11:59 AM, Anton Vorontsov wrote:
> 
> >The warning is bogus, so silence it with uninitialized_var().
> >
> >Signed-off-by: Anton Vorontsov 
> >---
> >board/freescale/common/sys_eeprom.c |4 +++-
> >1 files changed, 3 insertions(+), 1 deletions(-)
> >
> >diff --git a/board/freescale/common/sys_eeprom.c
> >b/board/freescale/common/sys_eeprom.c
> >index c0fff68..a765b39 100644
> >--- a/board/freescale/common/sys_eeprom.c
> >+++ b/board/freescale/common/sys_eeprom.c
> >@@ -24,6 +24,7 @@
> > */
> >
> >#include 
> >+#include 
> >#include 
> >#include 
> >#include 
> >@@ -204,7 +205,8 @@ static void update_crc(void)
> > */
> >static int prog_eeprom(void)
> >{
> >-int ret, i;
> >+int uninitialized_var(ret);
> >+int i;
> 
> why don't we init ret = 0;  seems like we should be doing that since
> we might not enter the for loop

No, we always enter the for loop:

for (i = 0, p = &e; i < sizeof(e); i += 8, p += 8) {

sizeof(e) always > 0 because:

#if !defined(CONFIG_SYS_I2C_EEPROM_CCID) && !defined(CONFIG_SYS_I2C_EEPROM_NXID)
#error "Please define either CONFIG_SYS_I2C_EEPROM_CCID or 
CONFIG_SYS_I2C_EEPROM_NXID"
#endif

static struct __attribute__ ((__packed__)) eeprom {
#ifdef CONFIG_SYS_I2C_EEPROM_CCID
u8 id[4]; /* 0x00 - 0x03 EEPROM Tag 'CCID' */
...
#endif
#ifdef CONFIG_SYS_I2C_EEPROM_NXID
u8 id[4]; /* 0x00 - 0x03 EEPROM Tag 'NXID' */
...
#endif
} e;

-- 
Anton Vorontsov
email: cbouatmai...@gmail.com
irc://irc.freenode.net/bd2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] fsl: sys_eeprom: Fix 'may be used uninitialized' warning

[Kumar Gala]

On Sep 1, 2009, at 11:59 AM, Anton Vorontsov wrote:

> The warning is bogus, so silence it with uninitialized_var().
>
> Signed-off-by: Anton Vorontsov 
> ---
> board/freescale/common/sys_eeprom.c |4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/board/freescale/common/sys_eeprom.c b/board/freescale/ 
> common/sys_eeprom.c
> index c0fff68..a765b39 100644
> --- a/board/freescale/common/sys_eeprom.c
> +++ b/board/freescale/common/sys_eeprom.c
> @@ -24,6 +24,7 @@
>  */
>
> #include 
> +#include 
> #include 
> #include 
> #include 
> @@ -204,7 +205,8 @@ static void update_crc(void)
>  */
> static int prog_eeprom(void)
> {
> - int ret, i;
> + int uninitialized_var(ret);
> + int i;

why don't we init ret = 0;  seems like we should be doing that since  
we might not enter the for loop

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

Re: [U-Boot] [PATCH v3] arm: Kirkwood: add SYSRSTn Duration Counter Support

[Prafulla Wadaskar]

 

> -Original Message-
> From: Prafulla Wadaskar [mailto:prafu...@marvell.com] 
> Sent: Thursday, August 20, 2009 8:59 PM
> To: u-boot@lists.denx.de
> Cc: Prabhanjan Sarnaik; Ronen Shitrit; Ashish Karkare; 
> Prafulla Wadaskar
> Subject: [PATCH v3] arm: Kirkwood: add SYSRSTn Duration 
> Counter Support
> 
> This feature can be used to trigger special command "sysrstcmd" using
> reset key long press event and environment variable 
> "sysrstdelay" is set
> (useful for reset to factory or manufacturing mode execution)
> 
> Kirkwood SoC implements a hardware-based SYSRSTn duration counter.
> When SYSRSTn is asserted low, a SYSRSTn duration counter is running.
> The counter value is stored in the SYSRSTn Length Counter Register
> The counter is based on the 25-MHz reference clock (40ns)
> It is a 29-bit counter, yielding a maximum counting duration of
> 2^29/25 MHz (21.4 seconds). When the counter reach its maximum value,
> it remains at this value until counter reset is triggered by setting
> bit 31 of KW_REG_SYSRST_CNT
> 
> Implementation:
> Upon long reset assertion (> ${sysrstdelay} in secs) sysrstcmd will be
> executed if pre-defined in environment variables.
> This feature will be disabled if "sysrstdelay" variable is unset.
> 
> for-ex.
> setenv sysrst_cmd "echo starting factory reset;
>  nand erase 0xa 0x2;
>  echo finish ed sysrst command;"
> will erase particular nand sector if triggered by this event
> 
> Signed-off-by: Prafulla Wadaskar 
> ---
> Change log:
> v2: updated as per review feedback for v1
> bug fix in the previous post (V2) fixed
> 
> v2 repost:
> I am sorry for previous post v2, pls ignore it, this is the 
> right patch for the same
> 
> v3: updated as per review feedback for v2
> all possible messages termed as debug
Ping...
I could not see the reference for this post on 
http://lists.denx.de/pipermail/u-boot/2009-August/date.html
Pls suggest If I need to repost this patch

Regards..
Prafulla . .

> 
>  cpu/arm926ejs/kirkwood/cpu.c|   75 
> +++
>  include/asm-arm/arch-kirkwood/cpu.h |2 +
>  2 files changed, 77 insertions(+), 0 deletions(-)
> 
> diff --git a/cpu/arm926ejs/kirkwood/cpu.c 
> b/cpu/arm926ejs/kirkwood/cpu.c
> index 795a739..3b978e2 100644
> --- a/cpu/arm926ejs/kirkwood/cpu.c
> +++ b/cpu/arm926ejs/kirkwood/cpu.c
> @@ -195,6 +195,78 @@ int kw_config_mpp(u32 mpp0_7, u32 
> mpp8_15, u32 mpp16_23, u32 mpp24_31,
>   return 0;
>  }
>  
> +/*
> + * SYSRSTn Duration Counter Support
> + *
> + * Kirkwood SoC implements a hardware-based SYSRSTn duration counter.
> + * When SYSRSTn is asserted low, a SYSRSTn duration counter 
> is running.
> + * The SYSRSTn duration counter is useful for implementing a 
> manufacturer
> + * or factory reset. Upon a long reset assertion that is 
> greater than a
> + * pre-configured environment variable value for sysrstdelay,
> + * The counter value is stored in the SYSRSTn Length Counter Register
> + * The counter is based on the 25-MHz reference clock (40ns)
> + * It is a 29-bit counter, yielding a maximum counting duration of
> + * 2^29/25 MHz (21.4 seconds). When the counter reach its 
> maximum value,
> + * it remains at this value until counter reset is triggered 
> by setting
> + * bit 31 of KW_REG_SYSRST_CNT
> + */
> +static void kw_sysrst_action(void)
> +{
> + int ret;
> + char *s = getenv("sysrstcmd");
> +
> + if (!s) {
> + debug("Error.. %s failed, check sysrstcmd\n",
> + __FUNCTION__);
> + return;
> + }
> +
> + debug("Starting %s process...\n", __FUNCTION__);
> +#if !defined(CONFIG_SYS_HUSH_PARSER)
> + ret = run_command (s, 0);
> +#else
> + ret = parse_string_outer(s, FLAG_PARSE_SEMICOLON
> +   | FLAG_EXIT_FROM_LOOP);
> +#endif
> + if (ret < 0)
> + debug("Error.. %s failed\n", __FUNCTION__);
> + else
> + debug("%s process finished\n", __FUNCTION__);
> +}
> +
> +static void kw_sysrst_check(void)
> +{
> + u32 sysrst_cnt, sysrst_dly;
> + char *s;
> +
> + /*
> +  * no action if sysrstdelay environment variable is not defined
> +  */
> + s = getenv("sysrstdelay");
> + if (s == NULL)
> + return;
> +
> + /* read sysrstdelay value */
> + sysrst_dly = (u32) simple_strtoul(s, NULL, 10);
> +
> + /* read SysRst Length counter register (bits 28:0) */
> + sysrst_cnt = (0x1fff & readl(KW_REG_SYSRST_CNT));
> + debug("H/w Rst hold time: %d.%d secs\n",
> + sysrst_cnt / SYSRST_CNT_1SEC_VAL,
> + sysrst_cnt % SYSRST_CNT_1SEC_VAL);
> +
> + /* clear the counter for next valid read*/
> + writel(1 << 31, KW_REG_SYSRST_CNT);
> +
> + /*
> +  * sysrst_action:
> +  * if H/w Reset key is pressed and hold for time
> +  * more than sysrst_dly in seconds
> +  */
> + if (sysrst_cnt >= SYSRST_CNT_1SEC_VAL * sysrst_dly)
> +

Re: [U-Boot] [PATCH v3 4/4] tools: mkimage: Add: Kirkwood Boot Image support (kwbimage)

[Prafulla Wadaskar]

 

> -Original Message-
> From: Prafulla Wadaskar [mailto:prafu...@marvell.com] 
> Sent: Monday, August 24, 2009 11:04 PM
> To: u-boot@lists.denx.de
> Cc: Prabhanjan Sarnaik; Ashish Karkare; Prafulla Wadaskar
> Subject: [PATCH v3 4/4] tools: mkimage: Add: Kirkwood Boot 
> Image support (kwbimage)
> 
> This patch adds type kwbimabe support for new mkimage core
> For more details refer docs/README.kwbimage
> 
> This patch is tested with Sheevaplug board
> 
> Signed-off-by: Prafulla Wadaskar 
> ---
> Change log:
> v2: updated as per review comments for v1
> added len checks in checksum functions
> added printable strings for each valid table entry
> use of sccanf not changed since it offers return value for failure
> 
> v3: resolved merge issues on mkimage branch

Ping... (for this entire patch series)

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

[U-Boot] [PATCH 2/2] fsl: sys_eeprom: Fix 'may be used uninitialized' warning

[Anton Vorontsov]

The warning is bogus, so silence it with uninitialized_var().

Signed-off-by: Anton Vorontsov 
---
 board/freescale/common/sys_eeprom.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/board/freescale/common/sys_eeprom.c 
b/board/freescale/common/sys_eeprom.c
index c0fff68..a765b39 100644
--- a/board/freescale/common/sys_eeprom.c
+++ b/board/freescale/common/sys_eeprom.c
@@ -24,6 +24,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -204,7 +205,8 @@ static void update_crc(void)
  */
 static int prog_eeprom(void)
 {
-   int ret, i;
+   int uninitialized_var(ret);
+   int i;
void *p;
 #ifdef CONFIG_SYS_EEPROM_BUS_NUM
unsigned int bus;
-- 
1.6.3.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 1/2] Move uninitialized_var() macro from ubi_uboot.h to compiler.h

[Anton Vorontsov]

This is needed so that we could use this macro for non-UBI code.

Signed-off-by: Anton Vorontsov 
---
 include/compiler.h  |3 +++
 include/ubi_uboot.h |4 +---
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/include/compiler.h b/include/compiler.h
index 272fd3c..e602cce 100644
--- a/include/compiler.h
+++ b/include/compiler.h
@@ -122,4 +122,7 @@ typedef unsigned intuintptr_t;
 
 #endif
 
+/* compiler options */
+#define uninitialized_var(x)   x = x
+
 #endif
diff --git a/include/ubi_uboot.h b/include/ubi_uboot.h
index 74312ab..60f6a5f 100644
--- a/include/ubi_uboot.h
+++ b/include/ubi_uboot.h
@@ -15,6 +15,7 @@
 #define __UBOOT_UBI_H
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -51,9 +52,6 @@ do {  
\
 #undef CONFIG_MTD_UBI_DEBUG_MSG_BLD
 #define CONFIG_MTD_UBI_DEBUG_DISABLE_BGT
 
-/* compiler options */
-#define uninitialized_var(x)   x = x
-
 /* build.c */
 #define get_device(...)
 #define put_device(...)
-- 
1.6.3.3

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

Re: [U-Boot] [PATCH 2/2] MTD:NAND: ADD new ECC mode NAND_ECC_HW_OOB_FIRST

[John Rigby]

Thanks for the info.

On Tue, Sep 1, 2009 at 10:33 AM, Paulraj, Sandeep  wrote:

> This patch is fine.
>
> I'll send an updated NAND Davinci driver patch soon which adds to what is
> already there. I have made a mistake and testing did not show it.
>
> Have you noticed that not all e-mails reach the mailing list in the correct
> order? This is true for the conversation you two were having.
>
> Thanks,
> Sandeep
>
> > -Original Message-
> > From: Paulraj, Sandeep
> > Sent: Tuesday, September 01, 2009 12:04 PM
> > To: Scott Wood; John Rigby
> > Cc: u-boot@lists.denx.de; Paulraj, Sandeep; Narnakaje, Snehaprabha
> > Subject: RE: [U-Boot] [PATCH 2/2] MTD:NAND: ADD new ECC mode
> > NAND_ECC_HW_OOB_FIRST
> >
> >
> > > John Rigby wrote:
> > > > Sorry for the late comments.  We have been trying to use this code
> > with
> > > > the associated davinci 4-bit ecc patches and have some questions
> > We use this internally and it works. Are you having any issues because we
> > don't see any!!
> > J-C has to apply a patch and you will need that for this to work
> properly.
> > That patch updates the DM355 Config
> > > (inline).
> > > >
> > > > .
> > > > +   uint8_t *ecc_code = chip->buffers->ecccode;
> > > > +   uint32_t *eccpos = chip->ecc.layout->eccpos;
> > > > +   uint8_t *ecc_calc = chip->buffers->ecccalc;
> > > > +
> > > > +   /* Read the OOB area first */
> > > > +   chip->cmdfunc(mtd, NAND_CMD_READOOB, 0, page);
> > > >
> > > >
> > > > What about chips that do not support the  NAND_CMD_READOOB?  Do I
> need
> > > > to provide my own read routine for that case?
> > >
> > > cmdfunc is supposed to fix that up.  This is already the case with
> > > existing code.
> > >
> > > > +   chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
> > > > +   chip->cmdfunc(mtd, NAND_CMD_READ0, 0, page);
> > > > +
> > > > +   for (i = 0; i < chip->ecc.total; i++)
> > > > +   ecc_code[i] = chip->oob_poi[eccpos[i]];
> > > > +
> > > > +   for (i = 0; eccsteps; eccsteps--, i += eccbytes, p +=
> > > eccsize) {
> > > > +   int stat;
> > > > +
> > > > +   chip->ecc.hwctl(mtd, NAND_ECC_READ);
> > > > +   chip->read_buf(mtd, p, eccsize);
> > > > +   chip->ecc.calculate(mtd, p, &ecc_calc[i]);
> > > >
> > > >
> > > > Here you calculate ecc then never use the result?
> > >
> > > Hmm, that looks wrong, both here and in the davinci driver.  Are the
> two
> > > calls to nand_davinci_4bit_readecc reading different things?  Does the
> > > calculate function have any side effects beyond producing data that is
> > > never used?
> > Have you reads the patch description. Maybe that might help a bit
> >
> > This patch adds the new mode NAND_ECC_HW_OOB_FIRST in the nand code to
> > support 4-bit ECC on TI DaVinci devices with large page (up to 2K) NAND
> > chips.  This ECC mode is similar to NAND_ECC_HW, with the exception of
> > read_page API that first reads the OOB area, reads the data in chunks,
> > feeds the ECC from OOB area to the ECC hw engine and perform any
> > correction on the data as per the ECC status reported by the engine.
> >
> > >
> > > -Scott
> > > ___
> > > 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 2/2] MTD:NAND: ADD new ECC mode NAND_ECC_HW_OOB_FIRST

[John Rigby]

Scott answered my question about chips that don't support NAND_CMD_READOOB,
we need to take care of it in cmdfunc.

I still don't see why the calculate method is called.  The results are
ignored.

On Tue, Sep 1, 2009 at 10:03 AM, Paulraj, Sandeep  wrote:

>
> > John Rigby wrote:
> > > Sorry for the late comments.  We have been trying to use this code with
> > > the associated davinci 4-bit ecc patches and have some questions
> We use this internally and it works. Are you having any issues because we
> don't see any!!
> J-C has to apply a patch and you will need that for this to work properly.
> That patch updates the DM355 Config
> > (inline).
> > >
> > > .
> > > +   uint8_t *ecc_code = chip->buffers->ecccode;
> > > +   uint32_t *eccpos = chip->ecc.layout->eccpos;
> > > +   uint8_t *ecc_calc = chip->buffers->ecccalc;
> > > +
> > > +   /* Read the OOB area first */
> > > +   chip->cmdfunc(mtd, NAND_CMD_READOOB, 0, page);
> > >
> > >
> > > What about chips that do not support the  NAND_CMD_READOOB?  Do I need
> > > to provide my own read routine for that case?
> >
> > cmdfunc is supposed to fix that up.  This is already the case with
> > existing code.
> >
> > > +   chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
> > > +   chip->cmdfunc(mtd, NAND_CMD_READ0, 0, page);
> > > +
> > > +   for (i = 0; i < chip->ecc.total; i++)
> > > +   ecc_code[i] = chip->oob_poi[eccpos[i]];
> > > +
> > > +   for (i = 0; eccsteps; eccsteps--, i += eccbytes, p +=
> > eccsize) {
> > > +   int stat;
> > > +
> > > +   chip->ecc.hwctl(mtd, NAND_ECC_READ);
> > > +   chip->read_buf(mtd, p, eccsize);
> > > +   chip->ecc.calculate(mtd, p, &ecc_calc[i]);
> > >
> > >
> > > Here you calculate ecc then never use the result?
> >
> > Hmm, that looks wrong, both here and in the davinci driver.  Are the two
> > calls to nand_davinci_4bit_readecc reading different things?  Does the
> > calculate function have any side effects beyond producing data that is
> > never used?
> Have you reads the patch description. Maybe that might help a bit
>
> This patch adds the new mode NAND_ECC_HW_OOB_FIRST in the nand code to
> support 4-bit ECC on TI DaVinci devices with large page (up to 2K) NAND
> chips.  This ECC mode is similar to NAND_ECC_HW, with the exception of
> read_page API that first reads the OOB area, reads the data in chunks,
> feeds the ECC from OOB area to the ECC hw engine and perform any
> correction on the data as per the ECC status reported by the engine.
>
> >
> > -Scott
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > http://lists.denx.de/mailman/listinfo/u-boot
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 2/2] arm: Remove -fno-strict-aliasing

[Kumar Gala]

-fno-strict-aliasing is hidding warnings.

Signed-off-by: Kumar Gala 
---
 cpu/arm1136/config.mk   |3 +--
 cpu/arm1176/config.mk   |3 +--
 cpu/arm1176/s3c64xx/config.mk   |3 +--
 cpu/arm720t/config.mk   |3 +--
 cpu/arm920t/config.mk   |3 +--
 cpu/arm925t/config.mk   |3 +--
 cpu/arm926ejs/config.mk |3 +--
 cpu/arm926ejs/davinci/config.mk |3 +--
 cpu/arm946es/config.mk  |3 +--
 cpu/arm_cortexa8/config.mk  |3 +--
 cpu/arm_intcm/config.mk |3 +--
 cpu/ixp/config.mk   |3 +--
 cpu/lh7a40x/config.mk   |3 +--
 cpu/pxa/config.mk   |3 +--
 cpu/s3c44b0/config.mk   |3 +--
 cpu/sa1100/config.mk|3 +--
 16 files changed, 16 insertions(+), 32 deletions(-)

diff --git a/cpu/arm1136/config.mk b/cpu/arm1136/config.mk
index 61d5a38..3e68535 100644
--- a/cpu/arm1136/config.mk
+++ b/cpu/arm1136/config.mk
@@ -20,8 +20,7 @@
 # Foundation, Inc., 59 Temple Place, Suite 330, Boston,
 # MA 02111-1307 USA
 #
-PLATFORM_RELFLAGS += -fno-strict-aliasing  -fno-common -ffixed-r8 \
-   -msoft-float
+PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float
 
 # Make ARMv5 to allow more compilers to work, even though its v6.
 PLATFORM_CPPFLAGS += -march=armv5
diff --git a/cpu/arm1176/config.mk b/cpu/arm1176/config.mk
index a31c7b0..14346cf 100644
--- a/cpu/arm1176/config.mk
+++ b/cpu/arm1176/config.mk
@@ -20,8 +20,7 @@
 # Foundation, Inc., 59 Temple Place, Suite 330, Boston,
 # MA 02111-1307 USA
 #
-PLATFORM_RELFLAGS += -fno-strict-aliasing  -fno-common -ffixed-r8 \
-   -msoft-float
+PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float
 
 # Make ARMv5 to allow more compilers to work, even though its v6.
 PLATFORM_CPPFLAGS += -march=armv5t
diff --git a/cpu/arm1176/s3c64xx/config.mk b/cpu/arm1176/s3c64xx/config.mk
index a31c7b0..14346cf 100644
--- a/cpu/arm1176/s3c64xx/config.mk
+++ b/cpu/arm1176/s3c64xx/config.mk
@@ -20,8 +20,7 @@
 # Foundation, Inc., 59 Temple Place, Suite 330, Boston,
 # MA 02111-1307 USA
 #
-PLATFORM_RELFLAGS += -fno-strict-aliasing  -fno-common -ffixed-r8 \
-   -msoft-float
+PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float
 
 # Make ARMv5 to allow more compilers to work, even though its v6.
 PLATFORM_CPPFLAGS += -march=armv5t
diff --git a/cpu/arm720t/config.mk b/cpu/arm720t/config.mk
index 74d5283..3844c62 100644
--- a/cpu/arm720t/config.mk
+++ b/cpu/arm720t/config.mk
@@ -22,8 +22,7 @@
 # MA 02111-1307 USA
 #
 
-PLATFORM_RELFLAGS += -fno-strict-aliasing  -fno-common -ffixed-r8 \
-   -msoft-float
+PLATFORM_RELFLAGS +=  -fno-common -ffixed-r8 -msoft-float
 
 PLATFORM_CPPFLAGS += -march=armv4 -mtune=arm7tdmi
 # =
diff --git a/cpu/arm920t/config.mk b/cpu/arm920t/config.mk
index a43b156..8f6c1a3 100644
--- a/cpu/arm920t/config.mk
+++ b/cpu/arm920t/config.mk
@@ -21,8 +21,7 @@
 # MA 02111-1307 USA
 #
 
-PLATFORM_RELFLAGS += -fno-strict-aliasing  -fno-common -ffixed-r8 \
-   -msoft-float
+PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float
 
 PLATFORM_CPPFLAGS += -march=armv4
 # =
diff --git a/cpu/arm925t/config.mk b/cpu/arm925t/config.mk
index a43b156..8f6c1a3 100644
--- a/cpu/arm925t/config.mk
+++ b/cpu/arm925t/config.mk
@@ -21,8 +21,7 @@
 # MA 02111-1307 USA
 #
 
-PLATFORM_RELFLAGS += -fno-strict-aliasing  -fno-common -ffixed-r8 \
-   -msoft-float
+PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float
 
 PLATFORM_CPPFLAGS += -march=armv4
 # =
diff --git a/cpu/arm926ejs/config.mk b/cpu/arm926ejs/config.mk
index 90eb3c0..f8ef90f 100644
--- a/cpu/arm926ejs/config.mk
+++ b/cpu/arm926ejs/config.mk
@@ -21,8 +21,7 @@
 # MA 02111-1307 USA
 #
 
-PLATFORM_RELFLAGS += -fno-strict-aliasing  -fno-common -ffixed-r8 \
-   -msoft-float
+PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float
 
 PLATFORM_CPPFLAGS += -march=armv5te
 # =
diff --git a/cpu/arm926ejs/davinci/config.mk b/cpu/arm926ejs/davinci/config.mk
index 7757be3..565adda 100644
--- a/cpu/arm926ejs/davinci/config.mk
+++ b/cpu/arm926ejs/davinci/config.mk
@@ -21,8 +21,7 @@
 # MA 02111-1307 USA
 #
 
-PLATFORM_RELFLAGS += -fno-strict-aliasing  -fno-common -ffixed-r8 \
-   -msoft-float
+PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float
 
 PLATFORM_CPPFLAGS += -march=armv5te
 # =
diff --git a/cpu/arm946es/config.mk b/cpu/arm946es/config.mk
index a81321b..e783f69 100644
--- a/cpu/arm946es/config.mk
+++ b/cpu/arm946es/config.mk
@@ -21,8 +21,7 @@
 # MA 02111-1307 USA
 #
 
-PLATFORM_RELFLAGS += -fno-strict-aliasing  -fno-common -ffixed-r8 \
--msoft-float
+PLATFORM_RELFLAGS += -fno-common -ff

[U-Boot] [PATCH 1/2] ppc: Remove -fno-strict-aliasing

[Kumar Gala]

-fno-strict-aliasing is hidding warnings.

Signed-off-by: Kumar Gala 
---
 board/tqc/tqm5200/Makefile |2 +-
 cpu/74xx_7xx/config.mk |2 +-
 cpu/mpc824x/config.mk  |2 +-
 cpu/mpc8xx/config.mk   |2 +-
 cpu/ppc4xx/config.mk   |2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/board/tqc/tqm5200/Makefile b/board/tqc/tqm5200/Makefile
index ce125e2..55c4d99 100644
--- a/board/tqc/tqm5200/Makefile
+++ b/board/tqc/tqm5200/Makefile
@@ -41,7 +41,7 @@ distclean:clean
rm -f $(LIB) core *.bak $(obj).depend
 
 cam5200_flash.o:   cam5200_flash.c
-   $(CC) $(CFLAGS) -fno-strict-aliasing -c -o $@ $<
+   $(CC) $(CFLAGS) -c -o $@ $<
 
 #
 
diff --git a/cpu/74xx_7xx/config.mk b/cpu/74xx_7xx/config.mk
index 324f62b..d589210 100644
--- a/cpu/74xx_7xx/config.mk
+++ b/cpu/74xx_7xx/config.mk
@@ -21,6 +21,6 @@
 # MA 02111-1307 USA
 #
 
-PLATFORM_RELFLAGS += -fPIC -ffixed-r14 -meabi -fno-strict-aliasing
+PLATFORM_RELFLAGS += -fPIC -ffixed-r14 -meabi
 
 PLATFORM_CPPFLAGS += -DCONFIG_74xx_7xx -ffixed-r2 -mstring
diff --git a/cpu/mpc824x/config.mk b/cpu/mpc824x/config.mk
index 1bb0487..b607fee 100644
--- a/cpu/mpc824x/config.mk
+++ b/cpu/mpc824x/config.mk
@@ -21,7 +21,7 @@
 # MA 02111-1307 USA
 #
 
-PLATFORM_RELFLAGS += -fPIC -ffixed-r14 -meabi -fno-strict-aliasing
+PLATFORM_RELFLAGS += -fPIC -ffixed-r14 -meabi
 
 PLATFORM_CPPFLAGS += -DCONFIG_MPC824X -ffixed-r2 -mstring -mcpu=603e 
-msoft-float
 
diff --git a/cpu/mpc8xx/config.mk b/cpu/mpc8xx/config.mk
index 6031e7f..2b3d545 100644
--- a/cpu/mpc8xx/config.mk
+++ b/cpu/mpc8xx/config.mk
@@ -21,6 +21,6 @@
 # MA 02111-1307 USA
 #
 
-PLATFORM_RELFLAGS += -fPIC -ffixed-r14 -meabi -fno-strict-aliasing
+PLATFORM_RELFLAGS += -fPIC -ffixed-r14 -meabi
 
 PLATFORM_CPPFLAGS += -DCONFIG_8xx -ffixed-r2 -mstring -mcpu=860 -msoft-float
diff --git a/cpu/ppc4xx/config.mk b/cpu/ppc4xx/config.mk
index baa97a4..00ad39b 100644
--- a/cpu/ppc4xx/config.mk
+++ b/cpu/ppc4xx/config.mk
@@ -21,7 +21,7 @@
 # MA 02111-1307 USA
 #
 
-PLATFORM_RELFLAGS += -fPIC -ffixed-r14 -meabi -fno-strict-aliasing
+PLATFORM_RELFLAGS += -fPIC -ffixed-r14 -meabi
 PLATFORM_CPPFLAGS += -DCONFIG_4xx -ffixed-r2 -mstring -msoft-float
 
 cfg=$(shell grep configs $(OBJTREE)/include/config.h | sed 
's/.*<\(configs.*\)>/\1/')
-- 
1.6.0.6

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

Re: [U-Boot] [PATCH 2/2] MTD:NAND: ADD new ECC mode NAND_ECC_HW_OOB_FIRST

[Paulraj, Sandeep]

> John Rigby wrote:
> > Sorry for the late comments.  We have been trying to use this code with
> > the associated davinci 4-bit ecc patches and have some questions
We use this internally and it works. Are you having any issues because we don't 
see any!!
J-C has to apply a patch and you will need that for this to work properly.
That patch updates the DM355 Config
> (inline).
> >
> > .
> > +   uint8_t *ecc_code = chip->buffers->ecccode;
> > +   uint32_t *eccpos = chip->ecc.layout->eccpos;
> > +   uint8_t *ecc_calc = chip->buffers->ecccalc;
> > +
> > +   /* Read the OOB area first */
> > +   chip->cmdfunc(mtd, NAND_CMD_READOOB, 0, page);
> >
> >
> > What about chips that do not support the  NAND_CMD_READOOB?  Do I need
> > to provide my own read routine for that case?
> 
> cmdfunc is supposed to fix that up.  This is already the case with
> existing code.
> 
> > +   chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
> > +   chip->cmdfunc(mtd, NAND_CMD_READ0, 0, page);
> > +
> > +   for (i = 0; i < chip->ecc.total; i++)
> > +   ecc_code[i] = chip->oob_poi[eccpos[i]];
> > +
> > +   for (i = 0; eccsteps; eccsteps--, i += eccbytes, p +=
> eccsize) {
> > +   int stat;
> > +
> > +   chip->ecc.hwctl(mtd, NAND_ECC_READ);
> > +   chip->read_buf(mtd, p, eccsize);
> > +   chip->ecc.calculate(mtd, p, &ecc_calc[i]);
> >
> >
> > Here you calculate ecc then never use the result?
> 
> Hmm, that looks wrong, both here and in the davinci driver.  Are the two
> calls to nand_davinci_4bit_readecc reading different things?  Does the
> calculate function have any side effects beyond producing data that is
> never used?
Have you reads the patch description. Maybe that might help a bit

This patch adds the new mode NAND_ECC_HW_OOB_FIRST in the nand code to
support 4-bit ECC on TI DaVinci devices with large page (up to 2K) NAND
chips.  This ECC mode is similar to NAND_ECC_HW, with the exception of
read_page API that first reads the OOB area, reads the data in chunks,
feeds the ECC from OOB area to the ECC hw engine and perform any
correction on the data as per the ECC status reported by the engine.

> 
> -Scott
> ___
> 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] atngw100: Use virtual address in CONFIG_ENV_ADDR

[Mark Jackson]

Haavard Skinnemoen wrote:



> Right...I'm beginning to doubt that anyone is familiar enough with the
> u-boot code, since everyone seems to have their own opinion about how
> things are supposed to work.
> 
> To summarize, here are the possible ways to fix the problem as I see it:
>   - Use virtual address in CONFIG_ENV_ADDR to conform with the way the
> CFI driver currently works. Rejected by Wolfgang because virtual
> addresses don't exist.
>   - Fix the API and user interface breakage by reverting commit
> 09ce9921. Rejected because virtual addresses are used everywhere.
>   - Fix it by using map_physmem() in a way that works for all
> architectures. Rejected because all other architectures than PPC
> are evil and need to be punished for doing things differently.

Your "triple revert" patch doesn't look overly complex, and seems to only
add a few map_physmem() calls (I'm summarising *quite* a bit there !!).

Is there not some way using weak functions (or similar) to add some AVR32
specific workarounds.

Or ... there's *plenty* of arch specific #ifdefs in most of the rest of
u-boot, so could we not just "#ifdef AVR32" the existing code for the
time being until this sticking point gets unstuck ?

>   - Introduce a custom flash driver for ATNGW100. Rejected because
> stupid principles are more important than making things work.
> 
> So I don't really know where to proceed from here. I guess two
> additional options are forking the damn thing or creating a proprietary
> bootloader, but I don't really want to do either.

Me neither !!

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

Re: [U-Boot] [PATCH] atngw100: Use virtual address in CONFIG_ENV_ADDR

[Thiago A . Corrêa]

Hi,

   I don't want to intrude too much into the discussion, but I would
like to offer a small bit of info

On Tue, Sep 1, 2009 at 10:23 AM, Haavard
Skinnemoen wrote:
>> It would be a good idea to clean up this board  support,  remove  the
>> proprietary  flash driver and use the CFI driver instead. Patches are
>> welcome.
>
> You must be joking. Replacing a working driver with a broken one? Why
> the hell would anyone do that?
>

My custom board uses AT49BV640D. I wen't thru a lot of trouble getting
u-boot to work with it. And one of my attempts was to use the "working
driver" from stk1000 and it didn't work. On the other hand, the CFI
driver with the tripple revert that Haavard proposed did. I'm
currently patching it like that so I can continue my development,
while people with much more knowleadge than I have on u-boot code
could fix the issue, but looks like I'm about to get orphan on u-boot
and Atmel.

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

[U-Boot] API License Terms

[Daniel Sherwood]

Hi

 

Please can someone clarify the following points regarding the 'Consumer
API' which we wish to use to access the environment from the core
application of a commercial closed source product.

 

1)   Is it true that the so called 'consumer application' can use
this API and remain closed source - if so, where in the license
information is this made clear?

2)   Who has agreed (or has to agree) that this is acceptable use?
It's all very well Rafal adding the code and a 'public' header file with
a BSD license - but surely all of the authors that have contributed to
code accessed through this API would have to consent to these terms.

3)   If presume that we cannot use the GPLv2 glue files in a closed
source application.

 

We need to understand these points before we can proceed with code that
interacts with this API.

 

Also, following on from these points, how would we go about extending
the API?  Specifically, we would like to add a saveenv function to the
API - is it legitimate for us to simply extend the API to add this
functionality - provided we publish our changes to u-boot as per the GPL
- without compromising our core application code as closed source?

 

Cheers

 

Daniel Sherwood
Software Engineer
 
Sepura PLC

Radio House, St Andrew's Road
Cambridge, CB4 1GR, UK
T: +44 (0) 1223 694637
F: +44 (0) 1223 879000
www.sepura.com  

 


The information in this email is confidential. It is intended
solely for the addressee. Access to this email by anyone else
is unauthorised. If you are not the intended recipient, any
disclosure, copying, or distribution is prohibited and may be
unlawful. If you have received this email in error please delete
it immediately and contact commerc...@sepura.com.

Sepura plc. Registered Office: Radio House, St Andrew’s Road, Cambridge, CB4 
1GR, England. Registered in England and Wales. Registration Number 4353801
 ___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] MTD:NAND: ADD new ECC mode NAND_ECC_HW_OOB_FIRST

[John Rigby]

Sorry for the late comments.  We have been trying to use this code with the
associated davinci 4-bit ecc patches and have some questions (inline).

.
> +   uint8_t *ecc_code = chip->buffers->ecccode;
> +   uint32_t *eccpos = chip->ecc.layout->eccpos;
> +   uint8_t *ecc_calc = chip->buffers->ecccalc;
> +
> +   /* Read the OOB area first */
> +   chip->cmdfunc(mtd, NAND_CMD_READOOB, 0, page);
>

What about chips that do not support the  NAND_CMD_READOOB?  Do I need to
provide my own read routine for that case?

+   chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
> +   chip->cmdfunc(mtd, NAND_CMD_READ0, 0, page);
> +
> +   for (i = 0; i < chip->ecc.total; i++)
> +   ecc_code[i] = chip->oob_poi[eccpos[i]];
> +
> +   for (i = 0; eccsteps; eccsteps--, i += eccbytes, p += eccsize) {
> +   int stat;
> +
> +   chip->ecc.hwctl(mtd, NAND_ECC_READ);
> +   chip->read_buf(mtd, p, eccsize);
> +   chip->ecc.calculate(mtd, p, &ecc_calc[i]);
>

Here you calculate ecc then never use the result?

+
> +   stat = chip->ecc.correct(mtd, p, &ecc_code[i], NULL);
> +   if (stat < 0)
> +   mtd->ecc_stats.failed++;
> +   else
> +   mtd->ecc_stats.corrected += stat;
> +   }
> +   return 0;
> +}
> +
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Obtaining board specific phy diagnostics

[Matthew Lear]

Matthew Lear wrote:
> Hi all,
> 
> Is there a common mechanism to hook in board specific ethernet phy
> commands? For example, I'd like to hook in the ability to read the TDR
> characteristics of the ethernet cable connected to my board. I know the
> phy on my board supports this so I was planning on hooking it into the
> mii command set somehow.
> 
> Currently, the ethernet set up code registers phy read and write
> routines, but that is all. Is there a recognised method / approach to
> add such board specific commands/features into an existing 'common' command?
> 
> Cheers,
> --  Matt
> 

A board specific command is fine, so using U_BOOT_CMD.
--  Matt
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] MTD:NAND: ADD new ECC mode NAND_ECC_HW_OOB_FIRST

[Scott Wood]

John Rigby wrote:
> Sorry for the late comments.  We have been trying to use this code with 
> the associated davinci 4-bit ecc patches and have some questions (inline).
> 
> .
> +   uint8_t *ecc_code = chip->buffers->ecccode;
> +   uint32_t *eccpos = chip->ecc.layout->eccpos;
> +   uint8_t *ecc_calc = chip->buffers->ecccalc;
> +
> +   /* Read the OOB area first */
> +   chip->cmdfunc(mtd, NAND_CMD_READOOB, 0, page);
> 
>  
> What about chips that do not support the  NAND_CMD_READOOB?  Do I need 
> to provide my own read routine for that case?

cmdfunc is supposed to fix that up.  This is already the case with 
existing code.

> +   chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
> +   chip->cmdfunc(mtd, NAND_CMD_READ0, 0, page);
> +
> +   for (i = 0; i < chip->ecc.total; i++)
> +   ecc_code[i] = chip->oob_poi[eccpos[i]];
> +
> +   for (i = 0; eccsteps; eccsteps--, i += eccbytes, p += eccsize) {
> +   int stat;
> +
> +   chip->ecc.hwctl(mtd, NAND_ECC_READ);
> +   chip->read_buf(mtd, p, eccsize);
> +   chip->ecc.calculate(mtd, p, &ecc_calc[i]);
> 
>  
> Here you calculate ecc then never use the result?

Hmm, that looks wrong, both here and in the davinci driver.  Are the two 
calls to nand_davinci_4bit_readecc reading different things?  Does the 
calculate function have any side effects beyond producing data that is 
never used?

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

Re: [U-Boot] [PATCH] atngw100: Use virtual address in CONFIG_ENV_ADDR

[Haavard Skinnemoen]

Thiago A. Corrêa  wrote:
> Hi,
> 
>I don't want to intrude too much into the discussion, but I would
> like to offer a small bit of info

Oh, I wish more people would intrude ;-)

> On Tue, Sep 1, 2009 at 10:23 AM, Haavard
> Skinnemoen wrote:
> >> It would be a good idea to clean up this board  support,  remove  the
> >> proprietary  flash driver and use the CFI driver instead. Patches are
> >> welcome.
> >
> > You must be joking. Replacing a working driver with a broken one? Why
> > the hell would anyone do that?
> >
> 
> My custom board uses AT49BV640D. I wen't thru a lot of trouble getting
> u-boot to work with it. And one of my attempts was to use the "working
> driver" from stk1000 and it didn't work.

Understandably since 640D uses the intel command set while the 6416
chip on STK1000 uses the AMD command set and has a couple of
interesting bugs...

Now, I still want to use common code as much as possible, but it's
always been quite expensive in terms of code size, and it currently
doesn't even work. While both of those should be possible to overcome,
I'm getting incredibly frustrated that all my attempts at fixing it are
being shot down by arcane, non-sensical rules which aren't even being
enforced consistently.

> On the other hand, the CFI
> driver with the tripple revert that Haavard proposed did. I'm
> currently patching it like that so I can continue my development,
> while people with much more knowleadge than I have on u-boot code
> could fix the issue, but looks like I'm about to get orphan on u-boot
> and Atmel.

Right...I'm beginning to doubt that anyone is familiar enough with the
u-boot code, since everyone seems to have their own opinion about how
things are supposed to work.

To summarize, here are the possible ways to fix the problem as I see it:
  - Use virtual address in CONFIG_ENV_ADDR to conform with the way the
CFI driver currently works. Rejected by Wolfgang because virtual
addresses don't exist.
  - Fix the API and user interface breakage by reverting commit
09ce9921. Rejected because virtual addresses are used everywhere.
  - Fix it by using map_physmem() in a way that works for all
architectures. Rejected because all other architectures than PPC
are evil and need to be punished for doing things differently.
  - Introduce a custom flash driver for ATNGW100. Rejected because
stupid principles are more important than making things work.

So I don't really know where to proceed from here. I guess two
additional options are forking the damn thing or creating a proprietary
bootloader, but I don't really want to do either.

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

Re: [U-Boot] [PATCH v6 2/2] arm: A320: Add support for Faraday A320 evaluation board

[Jean-Christophe PLAGNIOL-VILLARD]

On 09:41 Tue 01 Sep , Po-Yu Chuang wrote:
> Dear Jean-Christophe PLAGNIOL-VILLARD,
> 
> 2009/8/20 Po-Yu Chuang :
> > Dear Jean-Christophe PLAGNIOL-VILLARD,
> >> From: Po-Yu Chuang 
> >>
> >> This patch adds support for A320 evaluation board from Faraday. This board
> >> uses FA526 processor by default and has 512kB and 32MB NOR flash, 64M RAM.
> >> FA526 is an ARMv4 processor and uses the ARM920T source in this patch.
> >>
> >> Signed-off-by: Po-Yu Chuang 
> > I failed to CC you again, but the patches appear in the mailing list.
> > Hope you can see them.
> >
> > The command I used is like below.
> > Is there anything wrong?
> >
> > git send-email \
> > --from=ratbert.chu...@gmail.com \
> > --to=u-b...@lists.denx.de \
> > --cc=plagn...@jcrosoft.com \
> > --cc...@denx.de \
> > --cc=augulis.dar...@gmail.com \
> > 0002-arm-A320-Add-support-for-Faraday-A320-evaluation-boa.patch
> 
> Did you get the patches?
> or I need to resend again?
still not please send me it as attached or please put on a http or ftp server

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

Re: [U-Boot] Large Block USB Flash Drive Problem

[Barnes, Clifton A.]

From: l.ping...@gmail.com [mailto:l.ping...@gmail.com] On Behalf Of Remy Bohmer
Sent: Monday, June 01, 2009 12:04 PM
To: Barnes, Clifton A.
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] Large Block USB Flash Drive Problem

> Hello,

> 2009/5/28 Barnes, Clifton A. :
> >        I have been trying out loading the Linux kernel using a USB
> > flash drive in the u-boot-2009.06-rc2 release and ran into a problem
> > with one of my flash drives.  This particular drive has a block size of
> > 2048 while the other drives have block sizes of 512.  The drives with a
> > block size of 512 work perfectly.  However, the flash drive with a block
> > size of 2048 fails during the 'usb start' command.  I traced this issue
> > to the Part_dos.c file and the function test_part_dos.  The buffer
> > allocated there is only 512 bytes.  When I changed it to 2048, the 'usb
> > start' command worked correctly and found the one storage device
> > connected.  This had no adverse affect with the flash drives that were
> > 512 bytes.  Should the macro DEFAULT_SECTOR_SIZE be changed to
> > accommodate larger block size usb flash drives?
> >
> >        The second problem came when I tried to use the FAT utilities.
> > When I ran 'fatls usb 0', it failed the same way as when the 'usb start'
> > failed before.  Naturally, I guessed that it was a buffer size problem
> > again.  I was able to trace the issue to the macro SECTOR_SIZE in fat.h.
> > I tried changing it to 2048, however, there is a check right below it
> > that fails if SECTOR_SIZE != FS_BLOCK_SIZE.  So, I assume that the
> > support isn't written to handle sector sizes that are different than the
> > FAT block size.  However, I went ahead and changed them both to 2048.
> > This fixed the issues with the FAT utilities partly.  I was able to run
> > 'fatls usb 0' and it listed the files but also some junk.  I'm guessing
> > it was grabbing junk after the files since the block size is too big.  I
> > was also able to run 'fatload usb 0 0x2200 uImage' successfully and
> > boot the kernel successfully.  So, I think the fix has to be in the
> > SECTOR_SIZE macro in the fat.h file.  Can anyone with expertise in the
> > FAT implementation take a look at supporting different sector sizes for
> > larger block size flash drives?

> Well, there was a patch posted for this some time ago:
> http://www.mail-archive.com/u-boot@lists.denx.de/msg05444.html

> But, this patch broke several 512 byte blocksize devices, so I did not
> push it to mainline.
> You might take a look at it, maybe it solves your problem.
> If you can make it work properly with 512 byte devices as well, I am
> in for a patch...

> Kind Regards,

> Remy


Remy,

Do you know if anyone is actively working on this issue?  I tried 
applying the patch to the most recent U-Boot but it doesn't apply cleanly.  If 
no one is working on it, I might try to take a look at updating the patch and 
fixing the issue.  Is this not a big issue with people using USB flash drives?  
It seems I'm running into more and more "large block" flash drives.

Also, while clicking around the Git repo, I noticed that USB Ethernet 
support for the AT91 micros was added to U-Boot development.  How far along is 
the USB Ethernet support?  Is it something that can be tested now?  

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

Re: [U-Boot] [PATCH] MCI support for AT91 family processors.

[Sami Kantoluoto]

On Mon, Aug 31, 2009 at 01:39:26PM +0200, Albin Tonnerre wrote:
> On Mon, Aug 31, 2009 at 02:22:47PM +0300, Sami Kantoluoto wrote :
> > On Sun, Aug 30, 2009 at 01:08:27AM +0200, Albin Tonnerre wrote:
> > > On Sat, Aug 29, 2009 at 08:18:32PM +0300, Sami Kantoluoto wrote :
> > > > Fixed to parse CSD correctly on little endian processors as gcc orders
> > > > bitfields differently between big and little endian ones.
> > > 
> > > Please also see this patch, which will fix those bugs as weel, while 
> > > switching
> > > to the new GENRIC_MMC API:
> > > http://lists.denx.de/pipermail/u-boot/2009-August/059456.html
> > > I'd highly appreciate if you could test it, to get some feedback
> > 
> > Thanks, I'll test when I get some time later this week but I think (by 
> > reading the patch so I probably missed something) it won't solve the CSD
> > problem. The real reason of the "CSD problem" of course is that how the
> > mmc_csd structure is defined (host byte order not taken in account or
> > at least how gcc handles bitfields).
> > 
> 
> drivers/mmc/mmc.c does not actually use the bitfield to parse the csd struct,
> and got fixed a while back to work no matter what endianness you're using, so 
> it
> should solve it anyway.

I just tested the patch (+ your at91_mci patch + my new patches) and this
seems to work just find.

Thanks!


Best Regards,

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

Re: [U-Boot] [PATCH] atngw100: Use virtual address in CONFIG_ENV_ADDR

[Haavard Skinnemoen]

Wolfgang Denk  wrote:
> Well, that was the part of me saying before: "as long as it doesn't
> hurt others". We don't want to add that complexity to U-Boot as noone
> needs it.

Right. I forgot that nobody actually needs this.

Fuck it, I'm out.

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

[U-Boot] Is there any full story about how to take advantage FDT function ?

[Gao Ya'nan]

And how to configure the kernel to minimize the code modification ?

I am porting U-Boot and Linux to a new board with a MPC875 processor
and two serial chips,  and U-Boot runs well now. I hear that the FDT
function can tell the kernel devices information more flexibly and
reduce the code modification indirectly.

But I didn't find enough materials to make my head clear, so any tip
is greatly appreciated.

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

Re: [U-Boot] [PATCH] atngw100: Use virtual address in CONFIG_ENV_ADDR

[Wolfgang Denk]

Dear Haavard Skinnemoen,

In message <20090901152305.68e8d...@hskinnemoen-d830> you wrote:
>
> > On a 32 bit system with 36 bit physical addresses you cannot use a
> > physical address when running the "md" command, for example.
> 
> Yes you can, if you teach the "md" command to map it at a virtual
> address first. Again, map_physmem() makes this possible without
> changing the external interface in any way.

Well, that was the part of me saying before: "as long as it doesn't
hurt others". We don't want to add that complexity to U-Boot as noone
needs it.

The only few systems that seem to have problems are yours with their
exotic memory mappping.

> > > As far as I understand, the only difference for such systems is that
> > > keeping 64-bit physical addresses around are a bit more costly than
> > > passing around 32-bit virtual pointers. But presumably those systems
> > > have enough memory to make it a non-issue...
> > 
> > That's not true. There are 32 bit systems with bigger physical
> > address spaces. 
> 
> Which part of what I said isn't true? The part about some systems might
> require 64-bit variables to store a physical address or that such
> variables take more storage than a 32-bit virtual address?

Well, that the have enough memory not to case about size, for example.
[Keep in mind that this also effects the U-Boot image size in NOR
flash.]

> > We do not want to implement a full-fledged OS with virtual memory and
> > on-demand paging and all that stuff in U-Boot.
> 
> Then why are you forcing me to implement it for AVR32?!?

I'm not. I'm suggesting to implement a plain stupid 1:1 mapping and a
function to turn on and off data cache (at least on the flash area).

> > The advantage is that other drivers with similar needs can use it as
> > well.
> 
> But they can use map_physmem() today! It allows you to specify exactly
> what caching properties you need. The fact that it _may_ return a
> virtual address which is different from the physical one just allows
> more flexibility in how the architecture chooses to implement it!

You make assumptions on how other architectures work that may or may
not be true.

> > On other architectures it is not possible to map the same memory area
> > multiple times with different attributes.
> 
> So what? They can just return the physical address unchanged. It's not
> _mandatory_ to remap anything...

So how would these benefit from using data cache when reading from
flash? This works for you only because you are then reading from a
different address range.

> > It would be a good idea to clean up this board  support,  remove  the
> > proprietary  flash driver and use the CFI driver instead. Patches are
> > welcome.
> 
> You must be joking. Replacing a working driver with a broken one? Why
> the hell would anyone do that?

Fix the issues on the way?

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
Houston, Tranquillity Base here.  The Eagle has landed.
-- Neil Armstrong
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] atngw100: Use virtual address in CONFIG_ENV_ADDR

[Haavard Skinnemoen]

Wolfgang Denk  wrote:
> Dear Haavard Skinnemoen,
> 
> In message <20090901134257.59961...@hskinnemoen-d830> you wrote:
> >
> > > > complexity (which can be kept to a minimum) localized to a handful of
> > > > drivers, and don't change the command line interface or the board
> > > > configuration interface.
> > > 
> > > We're not doing this. At least not intentionally.
> > 
> > Good. Then let's please put a stop to the madness of exposing virtual
> > addresses all over the place.
> 
> But that's what we've been doing all the time. You just did not notice
> it because of the usual 1:1 mapping.

Up until this commit, yes:

commit 09ce9921a7d8b1ce764656b14b42217bbf4faa38
Author: Becky Bruce 
Date:   Mon Feb 2 16:34:51 2009 -0600

flash/cfi_flash: Use virtual sector start address, not phys

after that, NGW100 support is broken because virtual addresses are no
longer an implementation detail and are being exposed all over the
place.

> On a 32 bit system with 36 bit physical addresses you cannot use a
> physical address when running the "md" command, for example.

Yes you can, if you teach the "md" command to map it at a virtual
address first. Again, map_physmem() makes this possible without
changing the external interface in any way.

> we
> always assumed that the 32 bit VA we used matched 1:1 to a PA with
> the missing high bits set to 0, right?

Yes, but how can you possibly access an arbitrary 36-bit address using
that setup?

> > > The discussion we had was based on our knowledge about existing
> > > systems, and needs to also handle more complex situations like for
> > > example 32 bit systems with 36 bit physical addresses.
> > 
> > As far as I understand, the only difference for such systems is that
> > keeping 64-bit physical addresses around are a bit more costly than
> > passing around 32-bit virtual pointers. But presumably those systems
> > have enough memory to make it a non-issue...
> 
> That's not true. There are 32 bit systems with bigger physical
> address spaces. 

Which part of what I said isn't true? The part about some systems might
require 64-bit variables to store a physical address or that such
variables take more storage than a 32-bit virtual address?

> And note that this is not a new thing. We have been doing this allt
> he time - just without ever explicitly mentioning it, because so far
> nobody ever complained about it.

Doing what exactly? Limiting 36-bit PA systems to only use the lower
4GB of memory because VA must always equal PA come hell or high water?

> > > Agreed - assuming it is possible without hurting the majority of
> > > other existing configurations.
> > 
> > Yes, that is indeed possible, as evidenced by the fact that it used to
> > work without hurting any other configurations. It took another "special
> > case" to break it.
> 
> My understanding is that the special case is yours - using a non-1:1
> mapping.

But the other system must be a special case too -- otherwise it would
work fine without commit 09ce9921a7d8b1ce764656b14b42217bbf4faa38. That
commit does not make any difference whatsoever on 1:1 systems.

If the other system isn't a special case, why don't we just revert that
commit?

> > > discussions  with  Stefan Roese and Detlev Zundel it seems to me that
> > > map_physmem() is probably not the right approach (judging  only  from
> > > the  name).  We  should  not try to fix cache attributes by modifying
> > > addresses / address maps
> > 
> > And why not? That's what Linux does, and it works wonderfully across 26
> > different architectures.
> 
> We do not want to implement a full-fledged OS with virtual memory and
> on-demand paging and all that stuff in U-Boot.

Then why are you forcing me to implement it for AVR32?!?

> > > Instead, we should really extend the CFI driver such that it does not
> > > matter if the addresses you are passing refer to cached or uncached
> > > memory, and then provide hooks in the CFI driver to allow for testing
> > > if cache is enabled, and switching cache off if it is.
> > 
> > What's the advantage of such an approach? It sounds much more
> > complicated from the driver's point of view as well.
> 
> The advantage is that other drivers with similar needs can use it as
> well.

But they can use map_physmem() today! It allows you to specify exactly
what caching properties you need. The fact that it _may_ return a
virtual address which is different from the physical one just allows
more flexibility in how the architecture chooses to implement it!

> > > To me such an approach makes much more sense, as it  is  generic  and
> > > can be used by other drivers and other architectures - even if it may
> > > come at the cost of more effort on your systems.
> > 
> > In what way is it more generic? In what way can map/unmap_physmem() not
> > be used with other drivers and architectures?
> 
> On other architectures it is not possible to map the same memory area
> multiple times with different attributes.

So what? They can just r

[U-Boot] Obtaining board specific phy diagnostics

[Matthew Lear]

Hi all,

Is there a common mechanism to hook in board specific ethernet phy
commands? For example, I'd like to hook in the ability to read the TDR
characteristics of the ethernet cable connected to my board. I know the
phy on my board supports this so I was planning on hooking it into the
mii command set somehow.

Currently, the ethernet set up code registers phy read and write
routines, but that is all. Is there a recognised method / approach to
add such board specific commands/features into an existing 'common' command?

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

Re: [U-Boot] [PATCH] atngw100: Use virtual address in CONFIG_ENV_ADDR

[Wolfgang Denk]

Dear Haavard Skinnemoen,

In message <20090901134257.59961...@hskinnemoen-d830> you wrote:
>
> > > complexity (which can be kept to a minimum) localized to a handful of
> > > drivers, and don't change the command line interface or the board
> > > configuration interface.
> > 
> > We're not doing this. At least not intentionally.
> 
> Good. Then let's please put a stop to the madness of exposing virtual
> addresses all over the place.

But that's what we've been doing all the time. You just did not notice
it because of the usual 1:1 mapping.

On a 32 bit system with 36 bit physical addresses you cannot use a
physical address when running the "md" command, for example. we
always assumed that the 32 bit VA we used matched 1:1 to a PA with
the missing high bits set to 0, right?

> > The discussion we had was based on our knowledge about existing
> > systems, and needs to also handle more complex situations like for
> > example 32 bit systems with 36 bit physical addresses.
> 
> As far as I understand, the only difference for such systems is that
> keeping 64-bit physical addresses around are a bit more costly than
> passing around 32-bit virtual pointers. But presumably those systems
> have enough memory to make it a non-issue...

That's not true. There are 32 bit systems with bigger physical
address spaces. 


And note that this is not a new thing. We have been doing this allt
he time - just without ever explicitly mentioning it, because so far
nobody ever complained about it.

> > Agreed - assuming it is possible without hurting the majority of
> > other existing configurations.
> 
> Yes, that is indeed possible, as evidenced by the fact that it used to
> work without hurting any other configurations. It took another "special
> case" to break it.

My understanding is that the special case is yours - using a non-1:1
mapping.

> > discussions  with  Stefan Roese and Detlev Zundel it seems to me that
> > map_physmem() is probably not the right approach (judging  only  from
> > the  name).  We  should  not try to fix cache attributes by modifying
> > addresses / address maps
> 
> And why not? That's what Linux does, and it works wonderfully across 26
> different architectures.

We do not want to implement a full-fledged OS with virtual memory and
on-demand paging and all that stuff in U-Boot.

> > Instead, we should really extend the CFI driver such that it does not
> > matter if the addresses you are passing refer to cached or uncached
> > memory, and then provide hooks in the CFI driver to allow for testing
> > if cache is enabled, and switching cache off if it is.
> 
> What's the advantage of such an approach? It sounds much more
> complicated from the driver's point of view as well.

The advantage is that other drivers with similar needs can use it as
well.

> > To me such an approach makes much more sense, as it  is  generic  and
> > can be used by other drivers and other architectures - even if it may
> > come at the cost of more effort on your systems.
> 
> In what way is it more generic? In what way can map/unmap_physmem() not
> be used with other drivers and architectures?

On other architectures it is not possible to map the same memory area
multiple times with different attributes.  Remapping  addresses  thus
cannot  help  -  you  really  have  to  switch  the  MMO resp. memory
controller setinngs to turn data cache on or off.

> > Well, but board/atmel/atstk1000/flash.c _is_ a proprietary driver for
> > some flash chips that seem to be CFI conformant at first glance.  You
> > would not get such a driver into mailine any more. 
> 
> So I guess dropping support for ATNGW100 is the only remaining option?

No, why? We're discussing ways to fix the problems, aren;t we?

> At least STK1000 has a working flash driver.

Only because it was added so long ago, before we were more consequent
about using the generic driver. 

It would be a good idea to clean up this board  support,  remove  the
proprietary  flash driver and use the CFI driver instead. Patches are
welcome.

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
I will also, for an appropriate fee, certify that  your  keyboard  is
object-oriented,  and  that  the bits on your hard disk are template-
compatible.- Jeffrey S. Haemer in <411akr$...@cygnus.com>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] AT91: Add SD/MMC controller support

[Albin Tonnerre]

On Tue, Sep 01, 2009 at 03:04:24PM +0300, Sami Kantoluoto wrote :
> On Tue, Sep 01, 2009 at 02:57:46PM +0300, Sami Kantoluoto wrote:
> > On Tue, Sep 01, 2009 at 10:37:21AM +0200, Albin Tonnerre wrote:
> > > This patch allows to use the atmel_mci SD/MMC driver on the at91 
> > > architecture.
> > > It contains:
> > >  - initialization code for the MCI controller for all the supported AT91. 
> > > It
> > >allows the use of only one controller even if a SoC has two controllers
> > >(anyway there's no support for it in atmel_mci as of now)
> > >  - the necessary get_mci_clk_rate function
> > >  - definition of MMCI_BASE for use in atmel_mci
> > >  - the cpu_mmc_init function. As of now this is not used, but will be 
> > > required
> > >when atmel_mci is ported to the new generic mmc API.
> > > 
> > > Signed-off-by: Albin Tonnerre 
> > > ---
> > >  cpu/arm926ejs/at91/at91cap9_devices.c   |   36 ++
> > >  cpu/arm926ejs/at91/at91sam9260_devices.c|   27 +
> > >  cpu/arm926ejs/at91/at91sam9261_devices.c|   18 +
> > >  cpu/arm926ejs/at91/at91sam9263_devices.c|   54 
> > > +++
> > >  cpu/arm926ejs/at91/at91sam9m10g45_devices.c |   54 
> > > +++
> > >  cpu/arm926ejs/at91/at91sam9rl_devices.c |   22 +++
> > >  cpu/arm926ejs/at91/cpu.c|7 +++
> > >  include/asm-arm/arch-at91/at91_common.h |2 +
> > >  include/asm-arm/arch-at91/clk.h |5 ++
> > >  include/asm-arm/arch-at91/hardware.h|   18 +
> > >  include/asm-arm/arch-at91/memory-map.h  |1 +
> > >  11 files changed, 244 insertions(+), 0 deletions(-)
> > 
> > [snip]
> > 
> > > diff --git a/cpu/arm926ejs/at91/at91sam9260_devices.c 
> > > b/cpu/arm926ejs/at91/at91sam9260_devices.c
> > 
> > For some reason this doesn't apply cleanly. I patched the file manually and
> > it worked.
> 
> Ok, it's because of this hasn't been committed (at91sam9260_devices.c):
> 
>   #if defined(CONFIG_HAS_DATAFLASH) || defined(CONFIG_ATMEL_SPI)
>   void at91_spi0_hw_init(unsigned long cs_mask)
>   {

Oh, sorry. Yes, that's part of both the TNY-A9G20 and SBC35-A9G20 boards support
patches, which are both still pending review/inclusion. Jean-Christophe: ping?

Regards,
-- 
Albin Tonnerre, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com


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

[U-Boot] [PATCH] Support for Micrel/Kendin KS899xM managed switches.

[Sami Kantoluoto]

This patch adds simple support for KS8993M and KS8995MA managed switches.
It uses SPI interface for configuration (as everything cannot be configured
through MII). Switch can be configured to either regular switch or to
"router mode" so that every port (except the host port) has it's own VLAN
("port based VLAN").

Signed-off-by: Sami Kantoluoto 
---
 drivers/net/phy/Makefile  |1 +
 drivers/net/phy/ks899xm.c |  189 +
 drivers/net/phy/ks899xm.h |  255 +
 include/netdev.h  |   15 +++
 4 files changed, 460 insertions(+), 0 deletions(-)
 create mode 100644 drivers/net/phy/ks899xm.c
 create mode 100644 drivers/net/phy/ks899xm.h

diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index 3b92614..d91244c 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -26,6 +26,7 @@ include $(TOPDIR)/config.mk
 LIB:= $(obj)libphy.a
 
 COBJS-$(CONFIG_BITBANGMII) += miiphybb.o
+COBJS-$(CONFIG_KS899XM_SWITCH) += ks899xm.o
 COBJS-$(CONFIG_MV88E61XX_SWITCH) += mv88e61xx.o
 
 COBJS  := $(COBJS-y)
diff --git a/drivers/net/phy/ks899xm.c b/drivers/net/phy/ks899xm.c
new file mode 100644
index 000..87e47c7
--- /dev/null
+++ b/drivers/net/phy/ks899xm.c
@@ -0,0 +1,189 @@
+/*
+ * (C) Copyright 2009
+ * Sami Kantoluoto 
+ * Embedtronics Oy 
+ *
+ * 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 
+#include 
+#include 
+#include "ks899xm.h"
+
+static unsigned int ks_cmd (struct spi_slave *ss,
+   unsigned rdwr, unsigned reg, unsigned value,
+   unsigned *retvalue)
+{
+   unsigned char cmd[4] = { rdwr, reg, value }, rsp[4];
+   int ret;
+
+   ret = spi_xfer(ss, 32, cmd, rsp, SPI_XFER_BEGIN | SPI_XFER_END);
+
+   if (ret != 0) {
+   return KS_ERROR;
+   }
+
+   if (retvalue) {
+   *retvalue = rsp[2];
+   }
+
+   return KS_OK;
+}
+
+static unsigned int ks_write_reg (struct spi_slave *ss,
+ unsigned reg, unsigned value)
+{
+   /*printf("%s: reg=%02x, value=%02x\n", __FUNCTION__, reg, value); */
+   return ks_cmd (ss, KS_WR_DATA, reg, value, 0);
+}
+
+static unsigned int ks_read_reg (struct spi_slave *ss,
+unsigned reg, unsigned *value)
+{
+   int ret = ks_cmd (ss, KS_RD_DATA, reg, 0, value);
+   /*printf("%s: reg=%02x, value=%02x, ret=%d\n", __FUNCTION__, reg, 
*value, ret); */
+   return ret;
+}
+
+static unsigned int ks_ind_wr (struct spi_slave *ss,
+  unsigned table, unsigned addr,
+  const unsigned char *data, int dlen)
+{
+   int i, ret;
+
+   for (ret = KS_OK, i = 9 - dlen; ret == KS_OK && (i <= 8); i++) {
+   ret = ks_write_reg (ss, KS_IDR8 + i, *data++);
+   }
+
+   if (ret == KS_OK) {
+   ret =
+   ks_write_reg (ss, KS_IAC0,
+ (table & KS_IAC0_TBL) | ((addr >> 8) &
+  KS_IAC0_ADDR_HIGH));
+   }
+
+   if (ret == KS_OK) {
+   ret = ks_write_reg (ss, KS_IAC1, addr & 0xff);
+   }
+
+   return ret;
+}
+
+static int ks_write_vtab (struct spi_slave *ss,
+ unsigned ndx, unsigned vid, unsigned fid,
+ unsigned members)
+{
+   unsigned char buf[3] = {
+   0x20 | (members & 0x1F),
+   (fid << 4) | ((vid >> 8) & 0xF),
+   vid & 0xFF
+   };
+   return ks_ind_wr (ss, KS_IAC0_TBL_VLAN, ndx, buf, 3);
+}
+
+int ks899xm_switch_initialize(const struct ks899xm_config *swconfig)
+{
+   struct spi_slave *ss;
+   int ret = -1, i, nports = -1;
+   unsigned id0, id1;
+
+   /* check arguments */
+   if (swconfig->vlancfg != KS899XM_VLANCFG_DEFAULT
+   && swconfig->vlancfg != KS899XM_VLANCFG_ROUTER)
+   goto done;
+
+   /* prepare spi */
+   ss = spi_setup_slave(swconfig->spibus, swconfig->spics,
+1000, SPI_MODE_0);
+   if (!ss)
+   goto done;
+   if (spi_claim_bus(ss) != 0)
+

Re: [U-Boot] [PATCH] AT91: Add SD/MMC controller support

[Sami Kantoluoto]

On Tue, Sep 01, 2009 at 02:57:46PM +0300, Sami Kantoluoto wrote:
> On Tue, Sep 01, 2009 at 10:37:21AM +0200, Albin Tonnerre wrote:
> > This patch allows to use the atmel_mci SD/MMC driver on the at91 
> > architecture.
> > It contains:
> >  - initialization code for the MCI controller for all the supported AT91. It
> >allows the use of only one controller even if a SoC has two controllers
> >(anyway there's no support for it in atmel_mci as of now)
> >  - the necessary get_mci_clk_rate function
> >  - definition of MMCI_BASE for use in atmel_mci
> >  - the cpu_mmc_init function. As of now this is not used, but will be 
> > required
> >when atmel_mci is ported to the new generic mmc API.
> > 
> > Signed-off-by: Albin Tonnerre 
> > ---
> >  cpu/arm926ejs/at91/at91cap9_devices.c   |   36 ++
> >  cpu/arm926ejs/at91/at91sam9260_devices.c|   27 +
> >  cpu/arm926ejs/at91/at91sam9261_devices.c|   18 +
> >  cpu/arm926ejs/at91/at91sam9263_devices.c|   54 
> > +++
> >  cpu/arm926ejs/at91/at91sam9m10g45_devices.c |   54 
> > +++
> >  cpu/arm926ejs/at91/at91sam9rl_devices.c |   22 +++
> >  cpu/arm926ejs/at91/cpu.c|7 +++
> >  include/asm-arm/arch-at91/at91_common.h |2 +
> >  include/asm-arm/arch-at91/clk.h |5 ++
> >  include/asm-arm/arch-at91/hardware.h|   18 +
> >  include/asm-arm/arch-at91/memory-map.h  |1 +
> >  11 files changed, 244 insertions(+), 0 deletions(-)
> 
> [snip]
> 
> > diff --git a/cpu/arm926ejs/at91/at91sam9260_devices.c 
> > b/cpu/arm926ejs/at91/at91sam9260_devices.c
> 
> For some reason this doesn't apply cleanly. I patched the file manually and
> it worked.

Ok, it's because of this hasn't been committed (at91sam9260_devices.c):

  #if defined(CONFIG_HAS_DATAFLASH) || defined(CONFIG_ATMEL_SPI)
  void at91_spi0_hw_init(unsigned long cs_mask)
  {

Have you sent patch about this (CONFIG_ATMEL_SPI is not checked in committed
file)?


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

Re: [U-Boot] [PATCH] AT91: Add SD/MMC controller support

[Sami Kantoluoto]

On Tue, Sep 01, 2009 at 10:37:21AM +0200, Albin Tonnerre wrote:
> This patch allows to use the atmel_mci SD/MMC driver on the at91 architecture.
> It contains:
>  - initialization code for the MCI controller for all the supported AT91. It
>allows the use of only one controller even if a SoC has two controllers
>(anyway there's no support for it in atmel_mci as of now)
>  - the necessary get_mci_clk_rate function
>  - definition of MMCI_BASE for use in atmel_mci
>  - the cpu_mmc_init function. As of now this is not used, but will be required
>when atmel_mci is ported to the new generic mmc API.
> 
> Signed-off-by: Albin Tonnerre 
> ---
>  cpu/arm926ejs/at91/at91cap9_devices.c   |   36 ++
>  cpu/arm926ejs/at91/at91sam9260_devices.c|   27 +
>  cpu/arm926ejs/at91/at91sam9261_devices.c|   18 +
>  cpu/arm926ejs/at91/at91sam9263_devices.c|   54 
> +++
>  cpu/arm926ejs/at91/at91sam9m10g45_devices.c |   54 
> +++
>  cpu/arm926ejs/at91/at91sam9rl_devices.c |   22 +++
>  cpu/arm926ejs/at91/cpu.c|7 +++
>  include/asm-arm/arch-at91/at91_common.h |2 +
>  include/asm-arm/arch-at91/clk.h |5 ++
>  include/asm-arm/arch-at91/hardware.h|   18 +
>  include/asm-arm/arch-at91/memory-map.h  |1 +
>  11 files changed, 244 insertions(+), 0 deletions(-)

[snip]

> diff --git a/cpu/arm926ejs/at91/at91sam9260_devices.c 
> b/cpu/arm926ejs/at91/at91sam9260_devices.c

For some reason this doesn't apply cleanly. I patched the file manually and
it worked.


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

[U-Boot] [PATCH][v1] ppc/85xx: Fix up eSDHC controller clock frequency in the device tree for P1 & P2 RDB platforms

[Dipen Dudhat]

Fix up eSDHC controller clock frequency in the device tree for P1 & P2 RDB 
platforms

Signed-off-by: Dipen Dudhat 
---
- applies on git.denx.de/u-boot-mpc85xx.git branch->next
 board/freescale/p1_p2_rdb/p1_p2_rdb.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/board/freescale/p1_p2_rdb/p1_p2_rdb.c 
b/board/freescale/p1_p2_rdb/p1_p2_rdb.c
index 4c03468..4d99e43 100644
--- a/board/freescale/p1_p2_rdb/p1_p2_rdb.c
+++ b/board/freescale/p1_p2_rdb/p1_p2_rdb.c
@@ -209,6 +209,9 @@ void ft_board_setup(void *blob, bd_t *bd)
size = getenv_bootm_size();
 
fdt_fixup_memory(blob, (u64)base, (u64)size);
+#ifdef CONFIG_FSL_ESDHC
+   fdt_fixup_esdhc(blob, bd);
+#endif
 }
 #endif
 
-- 
1.5.6.3

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

[U-Boot] [PATCH][v1] ppc/85xx: Use CONFIG_FSL_ESDHC to enable sdhc clk

[Dipen Dudhat]

Enable eSDHC Clock based on generic CONFIG_FSL_ESDHC define instead of a 
platform define.
This will enable all the 85xx platforms to use sdhc_clk based on 
CONFIG_FSL_ESDHC.

Signed-off-by: Gao Guanhua 
Signed-off-by: Dipen Dudhat 
---
- applies on git.denx.de/u-boot-mpc85xx.git branch->next
 cpu/mpc85xx/speed.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/cpu/mpc85xx/speed.c b/cpu/mpc85xx/speed.c
index 3ef49b4..2fdcefb 100644
--- a/cpu/mpc85xx/speed.c
+++ b/cpu/mpc85xx/speed.c
@@ -153,7 +153,7 @@ int get_clocks (void)
 #endif
gd->i2c2_clk = gd->i2c1_clk;
 
-#if defined(CONFIG_MPC8536)
+#if defined(CONFIG_FSL_ESDHC)
gd->sdhc_clk = gd->bus_clk / 2;
 #endif
 
-- 
1.5.6.3

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

Re: [U-Boot] [PATCH] atngw100: Use virtual address in CONFIG_ENV_ADDR

[Haavard Skinnemoen]

Wolfgang Denk  wrote:
> Dear Haavard Skinnemoen,
> 
> In message <20090901123829.55fcb...@hskinnemoen-d830> you wrote:
> >
> > And that is EXACTLY why I'm trying to advocate: Keep the additional
> > complexity (which can be kept to a minimum) localized to a handful of
> > drivers, and don't change the command line interface or the board
> > configuration interface.
> 
> We're not doing this. At least not intentionally.

Good. Then let's please put a stop to the madness of exposing virtual
addresses all over the place.

> The discussion we had was based on our knowledge about existing
> systems, and needs to also handle more complex situations like for
> example 32 bit systems with 36 bit physical addresses.

As far as I understand, the only difference for such systems is that
keeping 64-bit physical addresses around are a bit more costly than
passing around 32-bit virtual pointers. But presumably those systems
have enough memory to make it a non-issue...

> > But as a matter of principle, I don't want to reduce the performance
> > _and_ increase the code size just because a driver that used to work
> > got broken. I want to fix the driver instead!
> 
> Agreed - assuming it is possible without hurting the majority of
> other existing configurations.

Yes, that is indeed possible, as evidenced by the fact that it used to
work without hurting any other configurations. It took another "special
case" to break it.

> > > If you want to run with data caches enabled by default, then it would
> > > probably make more sense if you invested efforts in extending the CFI
> > > driver to provide hooks / callbacks to (temporarily) switch of data
> > > cache for the memory range in question. This wouls allow you to run
> > > with DC enabled on the flash area, and still use the CFI driver.
> > 
> > But that is exactly how map_physmem() works -- it allows the CFI driver
> > (or any other driver) to request the caches to be bypassed for a given
> > physical address range, possibly resulting in a different virtual
> > address (though for backwards compatibility, all platforms except AVR32
> > simply return the physical address unchanged.)
> 
> I have to admit that I have no idea how map_physmem() used to work or
> how it works now; at this point, I don;t care about implementation
> details, I try to focus only on the overall design.

It works exactly the same way now as it used to work. The difference is
that its return value (which is basically just an architecture-specific
cookie, aka. virtual address) is exposed to a much larger part of the
system.

> I think  your  double  mapping  is  a  hightly  architecture-specific
> feature  which I do not like at all, but if you are happy with it and
> it works for you  I  cannot  and  will  not  prevent  it.

Yes, it was always meant to be an architecture-specific thing. Though I
think some MIPS- and SH-based processors do something very similar.

But in order to utilize architecture-specific features, we need an
architecture-independent abstraction and that's basically what
map_physmem() is.

>  But  after
> discussions  with  Stefan Roese and Detlev Zundel it seems to me that
> map_physmem() is probably not the right approach (judging  only  from
> the  name).  We  should  not try to fix cache attributes by modifying
> addresses / address maps

And why not? That's what Linux does, and it works wonderfully across 26
different architectures.

> Instead, we should really extend the CFI driver such that it does not
> matter if the addresses you are passing refer to cached or uncached
> memory, and then provide hooks in the CFI driver to allow for testing
> if cache is enabled, and switching cache off if it is.

What's the advantage of such an approach? It sounds much more
complicated from the driver's point of view as well.

> Detlev Zundel suggested to use this as  a  chance  to  come  up  with
> something  like a cache API which then could be used by other drivers
> as well.

My suggestion is to use map_physmem() and unmap_physmem(). It exists
today, and it works, provided that we keep its usage internal to the
driver and don't expose whatever architecture-specific values it
returns.

> To me such an approach makes much more sense, as it  is  generic  and
> can be used by other drivers and other architectures - even if it may
> come at the cost of more effort on your systems.

In what way is it more generic? In what way can map/unmap_physmem() not
be used with other drivers and architectures?

> > > Such changes will have it much easier to find their way into mainline
> > > than adding a proprietary flash driver.
> > 
> > It certainly won't be a proprietary driver; if anything, it would be a
> > variant of the driver currently used by ATSTK1000.
> 
> Well, but board/atmel/atstk1000/flash.c _is_ a proprietary driver for
> some flash chips that seem to be CFI conformant at first glance.  You
> would not get such a driver into mailine any more. 

So I guess dropping support for ATNGW1

Re: [U-Boot] how to enable various command support in u-boot-1.3.4?

[sunr2007]

thanks a lot Deng. sorry about previous message postin tat way. Now i was
able to compile cmd_fat.c by adding  tat CONFIG_CMD_FAT  in
/include/configs/at91sam9261ek.h. Now i want to use the atmel_spi.c driver
in /drivers/spi.
can u let me know what to add in the config file? i tried adding 
if define  CONFIG_ATMEL_SPI  AT91SAM9261_ID_SPI0 
so that it used BUS0 of the atmel SPI controller  but the compiler again
gave some error which was similar to previous error which i posted . thanks
a lot .
warm regards,
Ravi Kulkarni.

wd wrote:
> 
> Dear sunr2007,
> 
> Please make sure to read http://www.netmeister.org/news/learn2quote.html
> 
> Your message is next to impossible to read as we cannot see who wrote
> what.
> 
> In message <25237459.p...@talk.nabble.com> you wrote:
>> > 
>> > Why are you not using a recent tool chain?
>> >  since i use AT91SAM9261 boards the latest patch available for that
>> board
>> > is u-boot-1.3.4 
>> > so i used u-boot-1.3.4. i used 2009-08 version and compiled but there
>> is
>> > no support patch file for tat.
>> > i got this info frm linux4sam.org.
> 
> There are several configurations for the at91sam9261ek board
> supported in recent U-Boot. Please look again.
> 
>> >> compile the u-boot but only few of files compiled. in the /common/
>> >> directory
>> >> i want to compile cmd_fat.c and cmd_spi.c . though these files are
>> there
>> >> in
>> >> Makefile im unable to compile. may i know what i need to do to compile
>> >> these
>> >> files in u-boot? do i need to enable something? thanks.:confused:
> 
> You must not trry to compile single files, because you most likely
> don't get the required options right. Just add these features into
> your board configuration.
> 
>> > i tried modifying Makefile by changing this particular line 
>> > COBJS-$(CONFIG_CMD_FAT) += cmd_fat.o 
>> >  to 
>> > COBJS-y += cmd_fat.o
>> > but the compiler gave a error  which im posting here 
> 
> Don't do this. Instead, just add CONFIG_CMD_FAT to your board config
> file, usualklky include/configs/.h
> 
> Then run "make _config" and "make all"
> 
> 
> 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
> Imitation is the sincerest form of plagarism.
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
> 
> 

-- 
View this message in context: 
http://www.nabble.com/how-to-enable-various-command-support-in-u-boot-1.3.4--tp25236687p25238770.html
Sent from the Uboot - Users mailing list archive at Nabble.com.

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

Re: [U-Boot] [PATCH] atngw100: Use virtual address in CONFIG_ENV_ADDR

[Wolfgang Denk]

Dear Haavard Skinnemoen,

In message <20090901123829.55fcb...@hskinnemoen-d830> you wrote:
>
> And that is EXACTLY why I'm trying to advocate: Keep the additional
> complexity (which can be kept to a minimum) localized to a handful of
> drivers, and don't change the command line interface or the board
> configuration interface.

We're not doing this. At least not intentionally.

The discussion we had was based on our knowledge about existing
systems, and needs to also handle more complex situations like for
example 32 bit systems with 36 bit physical addresses.

> But as a matter of principle, I don't want to reduce the performance
> _and_ increase the code size just because a driver that used to work
> got broken. I want to fix the driver instead!

Agreed - assuming it is possible without hurting the majority of
other existing configurations.

> > If you want to run with data caches enabled by default, then it would
> > probably make more sense if you invested efforts in extending the CFI
> > driver to provide hooks / callbacks to (temporarily) switch of data
> > cache for the memory range in question. This wouls allow you to run
> > with DC enabled on the flash area, and still use the CFI driver.
> 
> But that is exactly how map_physmem() works -- it allows the CFI driver
> (or any other driver) to request the caches to be bypassed for a given
> physical address range, possibly resulting in a different virtual
> address (though for backwards compatibility, all platforms except AVR32
> simply return the physical address unchanged.)

I have to admit that I have no idea how map_physmem() used to work or
how it works now; at this point, I don;t care about implementation
details, I try to focus only on the overall design.


I think  your  double  mapping  is  a  hightly  architecture-specific
feature  which I do not like at all, but if you are happy with it and
it works for you  I  cannot  and  will  not  prevent  it.  But  after
discussions  with  Stefan Roese and Detlev Zundel it seems to me that
map_physmem() is probably not the right approach (judging  only  from
the  name).  We  should  not try to fix cache attributes by modifying
addresses / address maps

Instead, we should really extend the CFI driver such that it does not
matter if the addresses you are passing refer to cached or uncached
memory, and then provide hooks in the CFI driver to allow for testing
if cache is enabled, and switching cache off if it is.

Detlev Zundel suggested to use this as  a  chance  to  come  up  with
something  like a cache API which then could be used by other drivers
as well.

To me such an approach makes much more sense, as it  is  generic  and
can be used by other drivers and other architectures - even if it may
come at the cost of more effort on your systems.

> > Such changes will have it much easier to find their way into mainline
> > than adding a proprietary flash driver.
> 
> It certainly won't be a proprietary driver; if anything, it would be a
> variant of the driver currently used by ATSTK1000.

Well, but board/atmel/atstk1000/flash.c _is_ a proprietary driver for
some flash chips that seem to be CFI conformant at first glance.  You
would not get such a driver into mailine any more. 

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
On my planet, to rest is to rest -- to cease using energy. To me,  it
is  quite  illogical to run up and down on green grass, using energy,
instead of saving it.
-- Spock, "Shore Leave", stardate 3025.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] atngw100: Use virtual address in CONFIG_ENV_ADDR

[Haavard Skinnemoen]

Wolfgang Denk  wrote:
> Dear Haavard Skinnemoen,
> > Like I explained in an earlier mail, the default setup includes a 1:1
> > mapping of the lowest addresses, but it's cacheable. The default setup
> > also includes an uncached mapping of the same memory at a higher
> > virtual address.
> 
> You mean you want to have the same memory area mapped _twice_, once
> cached and once (at another address) uncached?

Yes.

> Well, this obviously cannot be done with a plain 1:1 mapping. But
> then: isn't that asking for trouble anyway? Or is there anything that
> prevents you for example reading stale cached data after the memory
> content has changed by accesses through the uncached mapping?

There's nothing which prevents me from accessing a completely different
address either -- I just need to make sure that I access the correct
address, or things will blow up one way or another.

The default virtual memory model makes it very easy to do uncached
access to certain types of memory (i.e. flash) and cached access to
others (i.e. SDRAM). It also makes it easy to run from cached flash
memory at startup and switch to uncached access later (after flushing
the cache, of course).

> > Yes, it is much easier (and smaller) to use the default virtual memory
> > layout than setting up paging (which involves several exception
> > handlers).
> 
> I don't see how paging comes into play here?

If I can't use the default scheme described above (and you're pretty
much saying I can't), I can define caching properties on a page-by-page
basis, but that obviously requires paging to be enabled.

> > Ok, so the code is broken and nobody else cares?
> 
> Broken? You might call it a design decision. This is a boot loader,
> and simplicity of design and easy porting and board bring up are
> usually higher rated that sequeezing out the last few percent of
> performance.

And that is EXACTLY why I'm trying to advocate: Keep the additional
complexity (which can be kept to a minimum) localized to a handful of
drivers, and don't change the command line interface or the board
configuration interface.

> IIRC, on PowerPC the difference of running with DC
> enabled or not is only in the 10% range or so.

But as a matter of principle, I don't want to reduce the performance
_and_ increase the code size just because a driver that used to work
got broken. I want to fix the driver instead!

> > I suppose I could disable the DC (which is a bit complicated, but
> > possible), but that would just add to the already high cost (in terms
> > of both code size and performance) of using common code (i.e. the CFI
> > driver), so I'm leaning towards a custom flash driver instead.
> 
> If you want to run with data caches enabled by default, then it would
> probably make more sense if you invested efforts in extending the CFI
> driver to provide hooks / callbacks to (temporarily) switch of data
> cache for the memory range in question. This wouls allow you to run
> with DC enabled on the flash area, and still use the CFI driver.

But that is exactly how map_physmem() works -- it allows the CFI driver
(or any other driver) to request the caches to be bypassed for a given
physical address range, possibly resulting in a different virtual
address (though for backwards compatibility, all platforms except AVR32
simply return the physical address unchanged.)

The problem is that this virtual address (which currently isn't
dynamic, but it's easy to imagine a platform where it could be) is
exposed to the rest of the world, thus breaking both existing board
configurations and potentially any command-line scripts (and,
apparently, the jffs2 driver though I'm not entirely sure how that
happened.)

> Such changes will have it much easier to find their way into mainline
> than adding a proprietary flash driver.

It certainly won't be a proprietary driver; if anything, it would be a
variant of the driver currently used by ATSTK1000.

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

Re: [U-Boot] how to enable various command support in u-boot-1.3.4?

[Wolfgang Denk]

Dear sunr2007,

Please make sure to read http://www.netmeister.org/news/learn2quote.html

Your message is next to impossible to read as we cannot see who wrote
what.

In message <25237459.p...@talk.nabble.com> you wrote:
> > 
> > Why are you not using a recent tool chain?
> >  since i use AT91SAM9261 boards the latest patch available for that board
> > is u-boot-1.3.4 
> > so i used u-boot-1.3.4. i used 2009-08 version and compiled but there is
> > no support patch file for tat.
> > i got this info frm linux4sam.org.

There are several configurations for the at91sam9261ek board
supported in recent U-Boot. Please look again.

> >> compile the u-boot but only few of files compiled. in the /common/
> >> directory
> >> i want to compile cmd_fat.c and cmd_spi.c . though these files are there
> >> in
> >> Makefile im unable to compile. may i know what i need to do to compile
> >> these
> >> files in u-boot? do i need to enable something? thanks.:confused:

You must not trry to compile single files, because you most likely
don't get the required options right. Just add these features into
your board configuration.

> > i tried modifying Makefile by changing this particular line 
> > COBJS-$(CONFIG_CMD_FAT) += cmd_fat.o 
> >  to 
> > COBJS-y += cmd_fat.o
> > but the compiler gave a error  which im posting here 

Don't do this. Instead, just add CONFIG_CMD_FAT to your board config
file, usualklky include/configs/.h

Then run "make _config" and "make all"


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
Imitation is the sincerest form of plagarism.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] atngw100: Use virtual address in CONFIG_ENV_ADDR

[Haavard Skinnemoen]

Stefan Roese  wrote:
> On Tuesday 01 September 2009 10:57:52 Haavard Skinnemoen wrote:
> > > Well, usually we run with IC on and  with  DC  off,  usually  because
> > > quite  a  number  of  drivers  and  other  code do not use proper I/O
> > > accessors yet, and/or because it's easier and  nobody  really  cares.
> > > For  example  on  PowerPC,  adding support for the data cache usually
> > > gives only a minimal performance boost.  This  may  be  different  on
> > > other architectures.
> >
> > Ok, so the code is broken and nobody else cares?
> 
> I wouldn't put it like this. The CFI driver assumes that the FLASH mapping is 
> not cached. This makes perfect sense in my point of view.

Yes, and it can do that safely because it specifically asks for an
uncached address from map_physmem(). That part didn't actually change
with the patch in question -- the problem is that the address returned
by map_physmem() is now exposed through external interfaces -- it's not
just an internal implementation detail anymore.

> > I suppose I could disable the DC (which is a bit complicated, but
> > possible), but that would just add to the already high cost (in terms
> > of both code size and performance) of using common code (i.e. the CFI
> > driver), so I'm leaning towards a custom flash driver instead.
> 
> On some 440 platforms we configure the FLASH cached upon powerup, and disable 
> the caching after relocating to SDRAM. So when the CFI driver is started, the 
> FLASH is not cached any more, but we have the cache speedup upon relocation.

That's what I want to do as well! And I can actually do that as long as
the flash subsystem uses map_physmem() consistently.

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

Re: [U-Boot] [PATCH] atngw100: Use virtual address in CONFIG_ENV_ADDR

[Haavard Skinnemoen]

Becky Bruce  wrote:
> > Becky: the fact that Haavard's code is breaking is not considered an
> > indication of a deficiency in his code.  
> 
> I'm not calling the code deficient, just a bit inconsistent, and it  
> wasn't clear to me why.  When code uses the same value 1) by mapping  
> it and 2) by dereferencing it directly, that's a bit strange.  Why map  
> it in some cases and in not others?

I agree, that is inconsistent. However, you "fixed" the code which was
actually doing it correctly...we should instead fix the code which is
incorrectly using the physical address as a virtual one.

While doing that, we could also consider dropping that hideous start
array altogether and instead provide a handful of accessors for
locating sector start addresses on the flash.

>  How is that supposed to work when  
> VA!=PA or when the VA can change? This is one of the reasons that it  
> seemed to make sense to modify the driver as I did - it should now be  
> able to work when VA!=PA as well as when we're 1:1.  I could find no  
> users that seemed to need the dynamic mapping.  However, if anyone  
> does need to *dynamically* map the flash in and out with a different  
> VA each time, then we do need to do things a bit differently and we  
> should look into a solution for that.

I don't think anything needs a dynamic mapping right now, but if we're
going to _ever_ support such systems in the future (and your 36-bit PA
system is a likely candidate, isn't it?) we have to stop locking
ourselves into a static mapping.

>  Clearly, I'm not the expert on  
> the CFI code, so when I published that patch I expected someone to  
> smack me if I was being a moron :)

I apologize for not doing so earlier ;-)

Anyway, I have to take most of the blame for this situation...if I had
paid attention and flagged the problem earlier, much of this could have
been avoided.

I'm hoping we can avoid too much pointing of fingers and work towards a
reasonably future-proof solution which works well on all platforms.

> > If the CFI driver kind of allowed for VAs before (but incompletely /
> > incorrectly), then this dis not cause problems on any systems using a
> > strict 1:1 mapping.
> >
> > Any changes to the code to correctly support other mappings must be
> > done in a way that they (1) do not break and (2) do not add additional
> > burdon on systems with a simple 1:1 mapping.  
> 
> Agreed, there shouldn't be any burden on those systems.

Agree too, as long as "those systems" does not include common code which
needs to run on all systems.

> >>> Everything is treated as virtual unless it's being used for hardware
> >>> setup.  
> >
> > Thisis NOT correct. U-Boot usually does NOT use virtual addresses.
> > Only very few systems do, and these must care not to disturb the
> > majority of systems which do no need to differentiate between
> > physical and virtual addresses.  
> 
> I'm not saying it *is* a VA as far as U-Boot knows, but that it is  
> *treated* as one, as mentioned above.   And this code was not expected  
> to disturb the 1:1 case.

Exposing VAs to the user interface and board code is IMO a very bad
idea, however. And that is what's happening now -- instead of
localizing the VAs to the CFI flash driver, it is now spread all over
the place.

> >>> A
> >>> lot of code had been just using the PA as a VA, because things were
> >>> always mapped 1-1.  
> >
> > Not only were, but _are_ and _will_be_.  
> 
> Of course - that should continue to be the default case unless it  
> needs to differ for some reason.

Yes, and that's why the external interface (at least the command line
and board configuration files) needs to use PA.

> > Indeed I'm deeply trouble when log standing rules get silently bent
> > and even broken.  
> 
> I agree 100% that 1:1 support should not be disturbed, since that's  
> the default case.   There was absolutely no intent here to bend any  
> "log standing rules", and nothing has been done here that  
> should have any impact on 1:1 as far as I'm aware.

Agree, 1:1 isn't the issue, it's two different systems with !1:1 which
have started making incompatible changes to the CFI driver.

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

Re: [U-Boot] how to enable various command support in u-boot-1.3.4?

[sunr2007]

wd wrote:
> 
> Dear sunr2007,
> 
> In message <25236687.p...@talk.nabble.com> you wrote:
>> 
>> I was using u-boot-1.1.5 all these days. so i decided to use SPI API
>> improvements and some other improvements. so i switched to u-boot 1.3.4 .
>> I'm using AT91SAM9261 board cross compiler with GCC 3.4.1. i was able to
> 
> May I ask why you decided to switch from an ancient to a very old
> version, and not to a current one?
> 
> U-Boot 1.3.4 is more than a year old. Current release is v2009.08
> 
> Also, GCC 3.4.x is very, very old.
> 
> Why are you not using a recent tool chain?
>  since i use AT91SAM9261 boards the latest patch available for that board
> is u-boot-1.3.4 
> so i used u-boot-1.3.4. i used 2009-08 version and compiled but there is
> no support patch file for tat.
> i got this info frm linux4sam.org.
> 
>> compile the u-boot but only few of files compiled. in the /common/
>> directory
>> i want to compile cmd_fat.c and cmd_spi.c . though these files are there
>> in
>> Makefile im unable to compile. may i know what i need to do to compile
>> these
>> files in u-boot? do i need to enable something? thanks.:confused:
> 
> I don't know what you are doing, buyt I can teel you that U-Boot
> releases 1.3.4 and 2009.08 build fine in all our tests;
> we used ELDK 3.1.1 (gcc 3.3.3) through ELDK 4.2 (gcc 4.2.2) for this.
> 
> If you have problems, then you either must be doing something wrong,
> oryour tool chain is broken - but you don't provide enough information
> for any diagnosis of the actual problem.
>  All i was tryin to do is to compile cmd_fat.c and cmd_spi.c files
> /common/ folder. 
> im not saying that i cant compile u-boot . i was able to compile u-boot
> but with only less commands. i wanted to use fatls and fatload , sspi and
> some other commands. these files are there in makefile but still i cant
> compile them.
> i tried modifying Makefile by changing this particular line 
> COBJS-$(CONFIG_CMD_FAT) += cmd_fat.o 
>  to 
> COBJS-y += cmd_fat.o
> but the compiler gave a error  which im posting here 
> 
> common/libcommon.a(cmd_fat.o): In function `do_fat_fsload':
> /home/ravikulkarni/dasuboot_airforce/u-boot-1.3.4/common/cmd_fat.c:64:
> undefined reference to `fat_register_device'
> /home/ravikulkarni/dasuboot_airforce/u-boot-1.3.4/common/cmd_fat.c:73:
> undefined reference to `file_fat_read'
> common/libcommon.a(cmd_fat.o): In function `do_fat_ls':
> /home/ravikulkarni/dasuboot_airforce/u-boot-1.3.4/common/cmd_fat.c:123:
> undefined reference to `fat_register_device'
> /home/ravikulkarni/dasuboot_airforce/u-boot-1.3.4/common/cmd_fat.c:130:
> undefined reference to `file_fat_ls'
> common/libcommon.a(cmd_fat.o): In function `do_fat_fsinfo':
> /home/ravikulkarni/dasuboot_airforce/u-boot-1.3.4/common/cmd_fat.c:168:
> undefined reference to `fat_register_device'
> /home/ravikulkarni/dasuboot_airforce/u-boot-1.3.4/common/cmd_fat.c:172:
> undefined reference to `file_fat_detectfs'
>  
>  but  i have checked tat all these functions are defined in fat.h 
> so i may know what exactly is going wrong? and can anybody give a link for
> the latest toolchain  which is advisable to compile u-boot?  thanks a lot
> for ur reply
> 
> warm regards,
> Ravi Kulkarni 
> 
> 
> Best regards,
> 
> Wolfgang Denk
> 
> -- 
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
> It became apparent that one reason why the Ice Giants were  known  as
> the  Ice  Giants  was  because they were, well, giants. The other was
> that they were made of ice.  -Terry Pratchett, _Sourcery_
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
> 
> 

-- 
View this message in context: 
http://www.nabble.com/how-to-enable-various-command-support-in-u-boot-1.3.4--tp25236687p25237459.html
Sent from the Uboot - Users mailing list archive at Nabble.com.

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

Re: [U-Boot] [PATCH] atngw100: Use virtual address in CONFIG_ENV_ADDR

[Wolfgang Denk]

Dear Haavard Skinnemoen,

In message <20090901105752.5bb77...@hskinnemoen-d830> you wrote:
>
> > Really? Sorry if I'm asking dumb questions - I don't know  AVR32:  is
> > it  true  that  stting  up a non-1:1 mapping for the NOR flash (i. e.
> > what you are doing now) is easier (less code) than setting up  a  1:1
> > mapping? What exactly are the reasons for this?
> 
> Like I explained in an earlier mail, the default setup includes a 1:1
> mapping of the lowest addresses, but it's cacheable. The default setup
> also includes an uncached mapping of the same memory at a higher
> virtual address.

You mean you want to have the same memory area mapped _twice_, once
cached and once (at another address) uncached?

Well, this obviously cannot be done with a plain 1:1 mapping. But
then: isn't that asking for trouble anyway? Or is there anything that
prevents you for example reading stale cached data after the memory
content has changed by accesses through the uncached mapping?

> Yes, it is much easier (and smaller) to use the default virtual memory
> layout than setting up paging (which involves several exception
> handlers).

I don't see how paging comes into play here?

> > Well, usually we run with IC on and  with  DC  off,  usually  because
> > quite  a  number  of  drivers  and  other  code do not use proper I/O
> > accessors yet, and/or because it's easier and  nobody  really  cares.
> > For  example  on  PowerPC,  adding support for the data cache usually
> > gives only a minimal performance boost.  This  may  be  different  on
> > other architectures.
> 
> Ok, so the code is broken and nobody else cares?

Broken? You might call it a design decision. This is a boot loader,
and simplicity of design and easy porting and board bring up are
usually higher rated that sequeezing out the last few percent of
performance. IIRC, on PowerPC the difference of running with DC
enabled or not is only in the 10% range or so.

> I suppose I could disable the DC (which is a bit complicated, but
> possible), but that would just add to the already high cost (in terms
> of both code size and performance) of using common code (i.e. the CFI
> driver), so I'm leaning towards a custom flash driver instead.

If you want to run with data caches enabled by default, then it would
probably make more sense if you invested efforts in extending the CFI
driver to provide hooks / callbacks to (temporarily) switch of data
cache for the memory range in question. This wouls allow you to run
with DC enabled on the flash area, and still use the CFI driver.

Such changes will have it much easier to find their way into mainline
than adding a proprietary flash driver.

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
Status quo. Latin for "the mess we're in."
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] at91sam9260/afeb9260: Fix SPI initialization

[Albin Tonnerre]

Commit 7ebafb7ec1a0285af8380623c009576f92583b98 introduced a mistake in the spi
init function call for those boards. This patch fixes this.

Signed-off-by: Albin Tonnerre 
---
 board/afeb9260/afeb9260.c |2 +-
 board/atmel/at91sam9260ek/at91sam9260ek.c |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/board/afeb9260/afeb9260.c b/board/afeb9260/afeb9260.c
index 94a65c2..4652672 100644
--- a/board/afeb9260/afeb9260.c
+++ b/board/afeb9260/afeb9260.c
@@ -149,7 +149,7 @@ int board_init(void)
 #ifdef CONFIG_CMD_NAND
afeb9260_nand_hw_init();
 #endif
-   at91_spi0_hw_init((1 << 0) || (1 << 1));
+   at91_spi0_hw_init((1 << 0) | (1 << 1));
 #ifdef CONFIG_MACB
afeb9260_macb_hw_init();
 #endif
diff --git a/board/atmel/at91sam9260ek/at91sam9260ek.c 
b/board/atmel/at91sam9260ek/at91sam9260ek.c
index c10ad72..ed47360 100644
--- a/board/atmel/at91sam9260ek/at91sam9260ek.c
+++ b/board/atmel/at91sam9260ek/at91sam9260ek.c
@@ -160,7 +160,7 @@ int board_init(void)
at91sam9260ek_nand_hw_init();
 #endif
 #ifdef CONFIG_HAS_DATAFLASH
-   at91_spi0_hw_init((1 << 0) || (1 << 1));
+   at91_spi0_hw_init((1 << 0) | (1 << 1));
 #endif
 #ifdef CONFIG_MACB
at91sam9260ek_macb_hw_init();
-- 
1.6.3.3

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

Re: [U-Boot] how to enable various command support in u-boot-1.3.4?

[Wolfgang Denk]

Dear sunr2007,

In message <25236687.p...@talk.nabble.com> you wrote:
> 
> I was using u-boot-1.1.5 all these days. so i decided to use SPI API
> improvements and some other improvements. so i switched to u-boot 1.3.4 .
> I'm using AT91SAM9261 board cross compiler with GCC 3.4.1. i was able to

May I ask why you decided to switch from an ancient to a very old
version, and not to a current one?

U-Boot 1.3.4 is more than a year old. Current release is v2009.08

Also, GCC 3.4.x is very, very old.

Why are you not using a recent tool chain?

> compile the u-boot but only few of files compiled. in the /common/ directory
> i want to compile cmd_fat.c and cmd_spi.c . though these files are there in
> Makefile im unable to compile. may i know what i need to do to compile these
> files in u-boot? do i need to enable something? thanks.:confused:

I don't know what you are doing, buyt I can teel you that U-Boot
releases 1.3.4 and 2009.08 build fine in all our tests;
we used ELDK 3.1.1 (gcc 3.3.3) through ELDK 4.2 (gcc 4.2.2) for this.

If you have problems, then you either must be doing something wrong,
oryour tool chain is broken - but you don't provide enough information
for any diagnosis of the actual problem.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
It became apparent that one reason why the Ice Giants were  known  as
the  Ice  Giants  was  because they were, well, giants. The other was
that they were made of ice.  -Terry Pratchett, _Sourcery_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] atngw100: Use virtual address in CONFIG_ENV_ADDR

[Stefan Roese]

On Tuesday 01 September 2009 10:57:52 Haavard Skinnemoen wrote:
> > Well, usually we run with IC on and  with  DC  off,  usually  because
> > quite  a  number  of  drivers  and  other  code do not use proper I/O
> > accessors yet, and/or because it's easier and  nobody  really  cares.
> > For  example  on  PowerPC,  adding support for the data cache usually
> > gives only a minimal performance boost.  This  may  be  different  on
> > other architectures.
>
> Ok, so the code is broken and nobody else cares?

I wouldn't put it like this. The CFI driver assumes that the FLASH mapping is 
not cached. This makes perfect sense in my point of view.

> I suppose I could disable the DC (which is a bit complicated, but
> possible), but that would just add to the already high cost (in terms
> of both code size and performance) of using common code (i.e. the CFI
> driver), so I'm leaning towards a custom flash driver instead.

On some 440 platforms we configure the FLASH cached upon powerup, and disable 
the caching after relocating to SDRAM. So when the CFI driver is started, the 
FLASH is not cached any more, but we have the cache speedup upon relocation.

Cheers,
Stefan

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

Re: [U-Boot] [PATCH] atngw100: Use virtual address in CONFIG_ENV_ADDR

[Haavard Skinnemoen]

Becky Bruce  wrote:
> Sorry, guys, I'm still not clear on what's going on. Haavard, did you  
> expect each call to flash_map to return a different VA each time (i.e.  
> you're trying to do some sort of dynamic mapping), or are you just  
> calling it to get the VA that corresponds to some PA, since VA != PA  
> on these 2 boards?

I'm calling it to get some VA which corresponds to a given PA with
given caching properties. I don't think it's good design if the board
code for every single board needs to know exactly which VA is going to
be returned.

> >> But exactly what's wrong with hiding all this complexity inside
> >> map_physmem()? It was designed _exactly_ for this purpose -- to allow
> >> platforms with non-trivial mappings between VA and PA to do the
> >> necessary mapping when the driver requests it.
> >
> > Sorry, I don't know that code and it's users well enough to coment.
> > Maybe Becky and/or Stefan can shed some light on this...
> 
> The problem is that would mean the CFI driver would be treating start  
> as a PA, while every other flash driver that I looked at treats it as  
> a VA.  That kind of inconsistency would be bad.

Except that it's even more inconsistent now since lots of code
elsewhere treats start as a PA, and the CFI driver was the only driver
which did it mostly correctly.

> Plus, Wolfgang,  
> Stefan, Kumar, and I discussed this on the list/IRC last november and  
> agreed that it made sense for command-line foo (including the flash  
> commands)  to take a virtual address as the argument.  Platforms that  
> have a non-fixed memory map would need to provide a command-line  
> interface to get a VA to use (since that's highly unusual and expected  
> to remain so).

I think that's an incredibly stupid idea, and it's really a shame that
I didn't participate in the IRC meeting.

It would have been so much easier if the command line only had to deal
with PA and the platform had to remap things transparently if
necessary. Now, if you need to access an arbitrary physical address
through a script, you need to first call this "set up a mapping"
command, record the value it prints out (presumably) and make sure not
to interpret any error message as a virtual address, use it to perform
the command, and then unmap it afterwards.

So if anything is breaking the u-boot philosophy of simplicity it is
this, and it does it in the worst possible way: it exposes all the
complexity through the user interface!

> >> That PA==VA rule is pretty much the reason we're in this mess -- if
> >
> > Let's say, the fact that this rule has not been stricter enforced has
> > caused that teh appearant problems were not discovered earlier.
> >
> >> more platforms had broken this rule, perhaps more of the code would
> >
> > Heh. If more  platforms had broken this rule we would probably have
> > become aware of these violations earlier, and stopped them doing such
> > naughty things ;-)
> 
> Well, u-boot was supposed to be simple, and a VA=PA assumption ended  
> up built into a lot of the code.  Which isn't a problem until you need  
> something different  I had a lot of fun standing on my head trying  
> to get 36-bit physical addressing on PowerPC working as a result of  
> this.   I suspect the next big u-boot problem will be the need for  
> dynamic mappings, because we're assuming for the most part now that  
> the board memory map is static.

Exactly, and with the current approach, dynamic mappings will _never_
be possible because all the VA-to-PA mapping assumptions will be built
into both the board code and the user interface!

So I ask again: Why don't we just fix the broken code instead? We have
the mechanisms available to make this work via the map_physmem()
functions, we just need to use them.

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

Re: [U-Boot] [PATCH] atngw100: Use virtual address in CONFIG_ENV_ADDR

[Haavard Skinnemoen]

Wolfgang Denk  wrote:
> Dear Haavard Skinnemoen,
> 
> In message <20090831155327.62b58...@hskinnemoen-d830> you wrote:
> >
> > Possibly. But it means even more effort and even larger code, so I'm
> > not exactly happy about it.
> 
> Really? Sorry if I'm asking dumb questions - I don't know  AVR32:  is
> it  true  that  stting  up a non-1:1 mapping for the NOR flash (i. e.
> what you are doing now) is easier (less code) than setting up  a  1:1
> mapping? What exactly are the reasons for this?

Like I explained in an earlier mail, the default setup includes a 1:1
mapping of the lowest addresses, but it's cacheable. The default setup
also includes an uncached mapping of the same memory at a higher
virtual address.

Yes, it is much easier (and smaller) to use the default virtual memory
layout than setting up paging (which involves several exception
handlers).

> > > Indeed I am, and intentionally, because this is a different topic. If
> > > your system requires to set up the MMU to enable  caching,  then  you
> > > are  supposed  to  do  it  in  a  way compatible with the rest of the
> > > software design, i. e. as transparently  as  possible.  None  of  the
> > > architectures  I  know resonably well have problems setting up a 1: 1
> > > address mapping even when the MMU is on (but I  have  to  admit  that
> > > AVR32 is not among these architectures).
> > 
> > I suspect quite a few other architectures run with caches disabled
> > because it's not safe to run with caches enabled with the current
> > software design.
> 
> Well, usually we run with IC on and  with  DC  off,  usually  because
> quite  a  number  of  drivers  and  other  code do not use proper I/O
> accessors yet, and/or because it's easier and  nobody  really  cares.
> For  example  on  PowerPC,  adding support for the data cache usually
> gives only a minimal performance boost.  This  may  be  different  on
> other architectures.

Ok, so the code is broken and nobody else cares?

I suppose I could disable the DC (which is a bit complicated, but
possible), but that would just add to the already high cost (in terms
of both code size and performance) of using common code (i.e. the CFI
driver), so I'm leaning towards a custom flash driver instead.

> > > Cache should not be relevant  at  all  when  defining  a  physcal  or
> > > virtual memory map.
> > 
> > Physical, no, but it's very common that the MMU defines caching
> > properties (enabled/disabled, writeback/writethrough, etc.)
> 
> Agreed. But it should be not so difficult to use the MMU to set up  a
> 1:1  mapping  if  you have to set up the MMU at all - or is there any
> problems with that which I'm not aware of?

Yes, there is: caching.

> > > Heh. If more  platforms had broken this rule we would probably have
> > > become aware of these violations earlier, and stopped them doing such
> > > naughty things ;-)
> > 
> > Seems like you think it's more important to follow arbitrary rules than
> > writing code that works well.
> 
> Keeping the code as simple as possible is not exactly an arbitrary
> rule. At least not for me.

As simple as possible, but no simpler...

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

[U-Boot] how to enable various command support in u-boot-1.3.4?

[sunr2007]

Dear all,
I was using u-boot-1.1.5 all these days. so i decided to use SPI API
improvements and some other improvements. so i switched to u-boot 1.3.4 .
I'm using AT91SAM9261 board cross compiler with GCC 3.4.1. i was able to
compile the u-boot but only few of files compiled. in the /common/ directory
i want to compile cmd_fat.c and cmd_spi.c . though these files are there in
Makefile im unable to compile. may i know what i need to do to compile these
files in u-boot? do i need to enable something? thanks.:confused:
warm regards,
Ravi Kulkarni
-- 
View this message in context: 
http://www.nabble.com/how-to-enable-various-command-support-in-u-boot-1.3.4--tp25236687p25236687.html
Sent from the Uboot - Users mailing list archive at Nabble.com.

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

[U-Boot] [PATCH] AT91: Add SD/MMC controller support

[Albin Tonnerre]

This patch allows to use the atmel_mci SD/MMC driver on the at91 architecture.
It contains:
 - initialization code for the MCI controller for all the supported AT91. It
   allows the use of only one controller even if a SoC has two controllers
   (anyway there's no support for it in atmel_mci as of now)
 - the necessary get_mci_clk_rate function
 - definition of MMCI_BASE for use in atmel_mci
 - the cpu_mmc_init function. As of now this is not used, but will be required
   when atmel_mci is ported to the new generic mmc API.

Signed-off-by: Albin Tonnerre 
---
 cpu/arm926ejs/at91/at91cap9_devices.c   |   36 ++
 cpu/arm926ejs/at91/at91sam9260_devices.c|   27 +
 cpu/arm926ejs/at91/at91sam9261_devices.c|   18 +
 cpu/arm926ejs/at91/at91sam9263_devices.c|   54 +++
 cpu/arm926ejs/at91/at91sam9m10g45_devices.c |   54 +++
 cpu/arm926ejs/at91/at91sam9rl_devices.c |   22 +++
 cpu/arm926ejs/at91/cpu.c|7 +++
 include/asm-arm/arch-at91/at91_common.h |2 +
 include/asm-arm/arch-at91/clk.h |5 ++
 include/asm-arm/arch-at91/hardware.h|   18 +
 include/asm-arm/arch-at91/memory-map.h  |1 +
 11 files changed, 244 insertions(+), 0 deletions(-)

diff --git a/cpu/arm926ejs/at91/at91cap9_devices.c 
b/cpu/arm926ejs/at91/at91cap9_devices.c
index 39e405f..4486cbb 100644
--- a/cpu/arm926ejs/at91/at91cap9_devices.c
+++ b/cpu/arm926ejs/at91/at91cap9_devices.c
@@ -79,6 +79,42 @@ void at91_serial_hw_init(void)
 #endif
 }
 
+#ifdef CONFIG_ATMEL_MCI
+#ifdef CONFIG_AT91_MCI0
+void at91_mci0_hw_init(unsigned long mask)
+{
+   at91_sys_write(AT91_PMC_PCER, 1 << AT91SAM9263_ID_MCI0);
+   at91_set_A_periph(AT91_PIN_PA2, 0);
+
+   if (mask & (1 << 0)) {
+   at91_set_A_periph(AT91_PIN_PA0, 1);
+   at91_set_A_periph(AT91_PIN_PA1, 1);
+   if (mask & (1 << 1)) {
+   at91_set_A_periph(AT91_PIN_PA3, 1);
+   at91_set_A_periph(AT91_PIN_PA4, 1);
+   at91_set_A_periph(AT91_PIN_PA5, 1);
+   }
+   }
+}
+#elif defined(CONFIG_AT91_MCI1
+void at91_mci1_hw_init(unsigned long mask)
+{
+   at91_sys_write(AT91_PMC_PCER, 1 << AT91SAM9263_ID_MCI);
+   at91_set_A_periph(AT91_PIN_PA16, 0);
+
+   if (mask & (1 << 0)) {
+   at91_set_A_periph(AT91_PIN_PA17, 1);
+   at91_set_A_periph(AT91_PIN_PA18, 1);
+   if (mask & (1 << 1)) {
+   at91_set_A_periph(AT91_PIN_PA19, 1);
+   at91_set_A_periph(AT91_PIN_PA20, 1);
+   at91_set_A_periph(AT91_PIN_PA21, 1);
+   }
+   }
+}
+#endif
+#endif
+
 #ifdef CONFIG_HAS_DATAFLASH
 void at91_spi0_hw_init(unsigned long cs_mask)
 {
diff --git a/cpu/arm926ejs/at91/at91sam9260_devices.c 
b/cpu/arm926ejs/at91/at91sam9260_devices.c
index f86cb99..ea22030 100644
--- a/cpu/arm926ejs/at91/at91sam9260_devices.c
+++ b/cpu/arm926ejs/at91/at91sam9260_devices.c
@@ -75,6 +75,33 @@ void at91_serial_hw_init(void)
 #endif
 }
 
+#ifdef CONFIG_ATMEL_MCI
+void at91_mci0_hw_init(unsigned long mask)
+{
+   at91_sys_write(AT91_PMC_PCER, 1 << AT91SAM9260_ID_MCI);
+   at91_set_A_periph(AT91_PIN_PA8, 0);
+
+   if (mask & (1 << 0)) {
+   at91_set_A_periph(AT91_PIN_PA6, 1);
+   at91_set_A_periph(AT91_PIN_PA7, 1);
+   if (mask & (1 << 1)) {
+   at91_set_A_periph(AT91_PIN_PA9, 1);
+   at91_set_A_periph(AT91_PIN_PA10, 1);
+   at91_set_A_periph(AT91_PIN_PA11, 1);
+   }
+   }
+   if (mask & (1 << 2)) {
+   at91_set_B_periph(AT91_PIN_PA0, 1);
+   at91_set_B_periph(AT91_PIN_PA1, 1);
+   if (mask & (1 << 3)) {
+   at91_set_B_periph(AT91_PIN_PA3, 1);
+   at91_set_B_periph(AT91_PIN_PA4, 1);
+   at91_set_B_periph(AT91_PIN_PA5, 1);
+   }
+   }
+}
+#endif /* ATMEL_MCI */
+
 #if defined(CONFIG_HAS_DATAFLASH) || defined(CONFIG_ATMEL_SPI)
 void at91_spi0_hw_init(unsigned long cs_mask)
 {
diff --git a/cpu/arm926ejs/at91/at91sam9261_devices.c 
b/cpu/arm926ejs/at91/at91sam9261_devices.c
index 16d411f..7ee573c 100644
--- a/cpu/arm926ejs/at91/at91sam9261_devices.c
+++ b/cpu/arm926ejs/at91/at91sam9261_devices.c
@@ -75,6 +75,24 @@ void at91_serial_hw_init(void)
 #endif
 }
 
+#ifdef CONFIG_ATMEL_MCI
+void at91_mci0_hw_init(unsigned long mask)
+{
+   at91_sys_write(AT91_PMC_PCER, 1 << AT91SAM9261_ID_MCI);
+   at91_set_B_periph(AT91_PIN_PA2, 0);
+
+   if (mask & (1 << 0)) {
+   at91_set_B_periph(AT91_PIN_PA0, 1);
+   at91_set_B_periph(AT91_PIN_PA1, 1);
+   if (mask & (1 << 1)) {
+   at91_set_B_periph(AT91_PIN_PA4, 1);
+   at91_set_B_periph(AT91_PIN_PA5

Re: [U-Boot] ARM preprocessor error generating assembly dependencies

[Dirk Behme]

Dear Wolfgang Denk,

Wolfgang Denk wrote:
> Dear Dirk Behme,
> 
> In message <4a9cc333.7020...@googlemail.com> you wrote:
 That is, it doesn't use AFLAGS set in config.mk to generate assembly 
 dependencies? So setting  -D__ASSEMBLY__ while generating assembly 
 dependencies is missing here?
>>> It's not needed. At least for none of the files in mainline.
>> Does this mean you will accept a patch that removes -D__ASSEMBLY__ 
>> from AFLAGS in config.mk?
> 
> Probablky not, as this seems to be bogus and would most probably break
> a ton of things.
> 
> What I mean is that I am not aware of any __ASSEMBLY__ related issues
> with dependency generation in mainline code, so I fail to understand
> which exact problem you are trying to solve.

I think it's not a good idea to calculate dependencies with different 
options than used for compilation. So the exact problem I'm looking 
for is to use same options for (assembly file) dependency generation 
and compilation. Just to be clean here, independent  of a discussion 
whether it might be necessary or not (which would be obsolete then).

Best regards

Dirk

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

Re: [U-Boot] [PATCH] Add common code dir for Matrix Vision boards.

[André Schwarz]

Wolfgang,

On Mon, 2009-08-31 at 20:26 +0200, Wolfgang Denk wrote:
> Dear Andre Schwarz,
> 
> In message <1251728304-26888-1-git-send-email-andre.schw...@matrix-vision.de> 
> you wrote:
> > This fixes current build failure.
> > 
> > Signed-off-by: Andre Schwarz 
> 
> Hm... You did not test your patch, did you?

of course. Both boards compiled cleanly (I thought).

> 
> -> git-am -3 -i -u --whitespace=strip ~/Mail/U-Boot/8023

Sorry - I'm not familiar with this.

> Commit Body is:
> --
> Add common code dir for Matrix Vision boards.
> 
> This fixes current build failure.
> 
> Signed-off-by: Andre Schwarz 
> --
> Apply? [y]es/[n]o/[e]dit/[v]iew patch/[a]ccept all y
> Applying: Add common code dir for Matrix Vision boards.
> /home/wd/git/u-boot/work/.git/rebase-apply/patch:168: trailing whitespace.

huh - need to do better checking.

> 
> warning: 1 line applied after fixing whitespace errors.
> ...
> Configuring for MVBLM7 board...
> mvblm7.c: In function 'misc_init_r':
> mvblm7.c:108: warning: implicit declaration of function 'mv_reset_environment'

ok - I can see it also on my build. Missed it yesterday.

> 
> 
> I'm a bit disappointed that this warning is still present. I think  I
> pointed it out before...

yes ... and I'm very uncomfortable with this. Don't know how this could
have slipped through. I greatly appreciate your help and will try to
improve.

> 
> OK, I fixed it for you.

Thank you.

> 
> Best regards,
> 
> Wolfgang Denk
> 

Regards,
André


MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, 
Hans-Joachim Reich
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] add Matrix Vision specific dir for common code.

[Wolfgang Denk]

Dear =?ISO-8859-1?Q?Andr=E9?= Schwarz,

In message <1251790163.4137.2.ca...@swa-m460> you wrote:
>
> After following your suggestion (git format-patch) with proper commit
> message and "Signed-off-by:" I could omit the "--compose" argument for
> git send-mail leading to a single mail, i.e. this is fixed now.

Hm... but the man page is pretty clear about the fact that --compose
will result in an additional introductory message to be generated:

Use $GIT_EDITOR, core.editor, $VISUAL, or $EDITOR to edit an
introductory message for the patch series.


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
"A child is a person who can't understand why someone would give away
a perfectly good kitten."   - Doug Larson
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] ARM preprocessor error generating assembly dependencies

[Wolfgang Denk]

Dear Dirk Behme,

In message <4a9cc333.7020...@googlemail.com> you wrote:
>
> >> That is, it doesn't use AFLAGS set in config.mk to generate assembly 
> >> dependencies? So setting  -D__ASSEMBLY__ while generating assembly 
> >> dependencies is missing here?
> > 
> > It's not needed. At least for none of the files in mainline.
> 
> Does this mean you will accept a patch that removes -D__ASSEMBLY__ 
> from AFLAGS in config.mk?

Probablky not, as this seems to be bogus and would most probably break
a ton of things.

What I mean is that I am not aware of any __ASSEMBLY__ related issues
with dependency generation in mainline code, so I fail to understand
which exact problem you are trying to solve.

Your original posting mentioned some file include/asm-arm/assembler.h
but this not part of mainline, so 1) I cannot comment on it and 2) if
adding this file causes problems I would tend to assume that there
are problems with that file, but not necessarily with the rest of the
system.

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
Men don't talk peace unless they're ready to back it up with war.
-- Col. Green, "The Savage Curtain", stardate 5906.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot