[U-Boot] need your help on u-boot usbkeyboard

[卫 王]

hello:
  recently,i'm using the new edition of u-boot,the 
edition u-boot-2009-rc1.and i met some troubles.so i need your help.
  i want to use the usbkeyboard as a console,how can i add this function to 
the u-boot?
because the interrupt is masked in the u-boot.and i've read your document,you 
said i need a script.but i don't know how to write that,can you offer me 
somehelp.by the way,the mcu of my board is s3c2410.

 yours:Iverson David
 
  2009.4.1


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

Re: [U-Boot] [PATCH] Added a tftp command

[Ben Warren]

Mike Frysinger wrote:
> On Tuesday 31 March 2009 19:40:27 kevin.morf...@fearnside-systems.co.uk wrote:
>   
>> Mike Frysinger wrote:
>> 
>>> On Tuesday 31 March 2009 18:44:21 kevin.morfitt wrote:
>>>   
 Adds a "tftp" command that gets a specified file from a TFTP Server and
 stores it in RAM at a specified RAM address. Most of the code already
 exists in board-specific form (eg in board/hymod) but this patch
 extracts it and makes it available as a standard u-boot command.
 
>>> your patch is horribly word wrapped.  ignoring that, how is this any
>>> different from the "tftpboot" command ?  i use "t  " to load
>>> arbitrary files via tftp to arbitrary addresses all the time.
>>>   
>> "tftpboot" loads the file then if "autostart" is "yes" it automatically
>> boots from the load address. The patch just loads the file then stops.
>> When programming a board I use it to copy images across before I program
>> them into flash. In effect, it does the same thing as setting
>> "autostart" to "off" then using "tftpboot".
>> 
>
> so dont set autostart ?
> -mike
>   
>   
Yeah, seriously.  Just script it.

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

Re: [U-Boot] [PATCH] Add support for Faraday Ethernet IP FTMAC100

[Ben Warren]

Hi Po Yu Chang,

PoYu_Chuang wrote:
> This patch adds support for Faraday Technology Ethernet IP - FTMAC100
>
> Signed-off-by: Po-Yu Chuang 
>   
Please use a valid e-mail address (hint - it should have an @ sign).  
You may want to provide a brief description of the controller here.
> ---
> diff -ruN u-boot-2009.03/drivers/net/ftmac100.c 
> FA5A320LINUX26_u-boot/drivers/net/ftmac100.c
>   
It's best to use git tools to generate the patch.  If you use 
git-send-email you're more-or-less guaranteed to avoid line-wrapping issues.
> --- u-boot-2009.03/drivers/net/ftmac100.c 1970-01-01 08:00:00.0 
> +0800
> +++ FA5A320LINUX26_u-boot/drivers/net/ftmac100.c  2009-03-31 
> 15:20:33.0 +0800
> @@ -0,0 +1,219 @@
> +/*
> + * Faraday FTMAC100 Ethernet
> + *
> + * (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.
> + */
> +
> +#undef   DEBUG
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "ftmac100.h"
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +static unsigned int  ftmac100_base = CONFIG_SYS_MAC100_BASE;
> +
> +static volatile struct ftmac100_txdestxdes[1];
> +static volatile struct ftmac100_rxdesrxdes[PKTBUFSRX];
> +static int   rx_index;
> +
> +/*
> + * Reset MAC
> + */
> +static void
> +ftmac100_reset(void)
> +{
> + debug("ftmac100_reset()\n");
> +
> + outl(FTMAC100_MACCR_SW_RST, ftmac100_base + FTMAC100_OFFSET_MACCR);
> +
> + while (inl(ftmac100_base + FTMAC100_OFFSET_MACCR) & 
> FTMAC100_MACCR_SW_RST);
> +}
> +
> +/*
> + * Set MAC address
> + */
> +static void
> +ftmac100_set_mac(const unsigned char *mac)
> +{
> + unsigned short  maddr = mac[0] << 8 | mac[1];
> + unsigned intladdr = mac[2] << 24 | mac[3] << 16 | mac[4] << 8 | 
> mac[5];
>   
This is a strange way of doing this.  Do you really need to use two 
variables?
> +
> + debug("ftmac100_set_mac()\n");
> +
> + outl(maddr, ftmac100_base + FTMAC100_OFFSET_MAC_MADR);
> + outl(laddr, ftmac100_base + FTMAC100_OFFSET_MAC_LADR);
>   
Others have mentioned not using outl(), so echo'd here
> +}
> +
> +/*
> + * disable transmitter, receiver
> + */
> +void
> +eth_halt(void)
> +{
> + debug("eth_halt()\n");
> +
> + outl(0, ftmac100_base + FTMAC100_OFFSET_MACCR);
> +}
>   
Please don't use the old-style API (eth_halt(), eth_init() etc.)  You 
should have a single xxx_initialize() function that fills in an 
eth_device struct with function pointers to static functions.  You'll 
find lots of examples in drivers/net
> +
> +int
> +eth_init(bd_t *bd)
> +{
> + int i;
> + unsigned intmaccr;
> +
> + debug("eth_init()\n");
> +
> + ftmac100_reset();
> +
> + /* set the ethernet address */
> +
> + ftmac100_set_mac(gd->bd->bi_enetaddr);
> +
> + /* disable all interrupts */
> +
> + outl(0, ftmac100_base + FTMAC100_OFFSET_IMR);
> +
> + /* initialize descriptors */
> +
> + rx_index = 0;
> +
> + txdes[0].txdes1 = FTMAC100_TXDES1_EDOTR;
> + rxdes[PKTBUFSRX - 1].rxdes1 = FTMAC100_RXDES1_EDORR;
> +
> + for (i = 0; i < PKTBUFSRX; i++) {
> + rxdes[i].rxdes2 = (unsigned int)NetRxPackets[i];/* 
> RXBUF_BADR */
> + rxdes[i].rxdes1 |= FTMAC100_RXDES1_RXBUF_SIZE(PKTSIZE_ALIGN);
> + rxdes[i].rxdes0 = FTMAC100_RXDES0_RXDMA_OWN;
> + }
> +
> + /* transmit ring */
> +
> + outl(txdes, ftmac100_base + FTMAC100_OFFSET_TXR_BADR);
> +
> + /* receive ring */
> +
> + outl(rxdes, ftmac100_base + FTMAC100_OFFSET_RXR_BADR);
> +
> + /* poll receive descriptor automatically */
> +
> + outl(FTMAC100_APTC_RXPOLL_CNT(1), ftmac100_base + FTMAC100_OFFSET_APTC);
> +
> + /* enable transmitter, receiver */
> +
> + maccr   = FTMAC100_MACCR_XMT_EN
> + | FTMAC100_MACCR_RCV_EN
> + | FTMAC100_MACCR_XDMA_EN
> + | FTMAC100_MACCR_RDMA_EN
> + | FTMAC100_MACCR_CRC_APD
> + | FTMAC100_MACCR_ENRX_IN_HALFTX 
> + | FTMAC100_MACCR_RX_RUNT
> + | FTMAC100_MACCR_RX_BROADPKT;
> +
> + outl(maccr, ftmac100_base + FTMAC100_OFFSET_MACCR);
> +
> + return 0;
> +}
> +
> +/*
> + * Get a data block via Ethernet
> + */
> +int
> +eth_rx(void)
> +{
> + volatile struct

Re: [U-Boot] [PATCH] 85xx/86xx: Ensure MP boot page is not used

[Kumar Gala]

On Mar 31, 2009, at 11:23 PM, Kumar Gala wrote:

> We had a bug on 86xx in which the boot page used to bring up secondary
> cores was being overwritten and used for the malloc region in u-boot.
>
> We need to reserve the region of memory that the boot page is going to
> be put at so nothing uses it.
>
> Signed-off-by: Kumar Gala 
> ---
> lib_ppc/board.c |   13 +
> 1 files changed, 13 insertions(+), 0 deletions(-)

Wolfgang,

This patch depends on the other two.  If you ack this one I can send  
all three via the 85xx git tree.

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

[U-Boot] [PATCH] 85xx/86xx: Ensure MP boot page is not used

[Kumar Gala]

We had a bug on 86xx in which the boot page used to bring up secondary
cores was being overwritten and used for the malloc region in u-boot.

We need to reserve the region of memory that the boot page is going to
be put at so nothing uses it.

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

diff --git a/lib_ppc/board.c b/lib_ppc/board.c
index 3b93e4e..6eeca02 100644
--- a/lib_ppc/board.c
+++ b/lib_ppc/board.c
@@ -79,6 +79,10 @@
 #include 
 #endif
 
+#ifdef CONFIG_MP
+extern u32 determine_mp_bootpg(void);
+#endif
+
 #ifdef CONFIG_SYS_UPDATE_FLASH_SIZE
 extern int update_flash_size (int flash_size);
 #endif
@@ -444,6 +448,15 @@ void board_init_f (ulong bootflag)
 
addr = CONFIG_SYS_SDRAM_BASE + get_effective_memsize();
 
+#if defined(CONFIG_MP) && (defined(CONFIG_MPC86xx) || defined(CONFIG_E500))
+   /* We need to make sure the location we intend to put secondary core
+* boot code is reserved and not used by any part of u-boot */
+   if (addr > determine_mp_bootpg()) {
+   addr = determine_mp_bootpg();
+   debug ("Reserving MP boot page to %08lx\n", addr);
+   }
+#endif
+
 #ifdef CONFIG_LOGBUFFER
 #ifndef CONFIG_ALT_LB_ADDR
/* reserve kernel log buffer */
-- 
1.5.6.6

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

[U-Boot] [PATCH] 86xx: Cleanup MP support

[Kumar Gala]

* Use CONFIG_MP instead of CONFIG_NUM_CPUS to match 85xx
* Introduce determine_mp_bootpg() helper.  We'll need this to address a
  bug introduced in v2009.03 with 86xx MP booting.  We have to make sure
  to reserve the region of memory used for the MP bootpg() so other
  u-boot code doesn't use it.

Signed-off-by: Kumar Gala 
---
 board/freescale/mpc8641hpcn/mpc8641hpcn.c |2 +-
 board/sbc8641d/sbc8641d.c |2 +-
 cpu/mpc85xx/mp.h  |1 +
 cpu/mpc86xx/Makefile  |7 ++--
 cpu/mpc86xx/fdt.c |   12 ++-
 cpu/mpc86xx/mp.c  |   47 ++--
 cpu/mpc86xx/mp.h  |1 +
 cpu/mpc86xx/release.S |2 -
 include/configs/MPC8641HPCN.h |1 +
 include/configs/sbc8641d.h|1 +
 10 files changed, 42 insertions(+), 34 deletions(-)

diff --git a/board/freescale/mpc8641hpcn/mpc8641hpcn.c 
b/board/freescale/mpc8641hpcn/mpc8641hpcn.c
index 1e35dfa..ef0095a 100644
--- a/board/freescale/mpc8641hpcn/mpc8641hpcn.c
+++ b/board/freescale/mpc8641hpcn/mpc8641hpcn.c
@@ -375,7 +375,7 @@ void board_reset(void)
;
 }
 
-#if (CONFIG_NUM_CPUS > 1)
+#ifdef CONFIG_MP
 extern void cpu_mp_lmb_reserve(struct lmb *lmb);
 
 void board_lmb_reserve(struct lmb *lmb)
diff --git a/board/sbc8641d/sbc8641d.c b/board/sbc8641d/sbc8641d.c
index fc1f07d..9f69638 100644
--- a/board/sbc8641d/sbc8641d.c
+++ b/board/sbc8641d/sbc8641d.c
@@ -414,7 +414,7 @@ void board_reset(void)
 #endif
 }
 
-#if (CONFIG_NUM_CPUS > 1)
+#ifdef CONFIG_MP
 extern void cpu_mp_lmb_reserve(struct lmb *lmb);
 
 void board_lmb_reserve(struct lmb *lmb)
diff --git a/cpu/mpc85xx/mp.h b/cpu/mpc85xx/mp.h
index 4329286..b06707f 100644
--- a/cpu/mpc85xx/mp.h
+++ b/cpu/mpc85xx/mp.h
@@ -5,6 +5,7 @@ ulong get_spin_addr(void);
 void setup_mp(void);
 u32 get_my_id(void);
 void cpu_mp_lmb_reserve(struct lmb *lmb);
+u32 determine_bootpg(void);
 
 #define BOOT_ENTRY_ADDR_UPPER  0
 #define BOOT_ENTRY_ADDR_LOWER  1
diff --git a/cpu/mpc86xx/Makefile b/cpu/mpc86xx/Makefile
index 34a9755..f1af64e 100644
--- a/cpu/mpc86xx/Makefile
+++ b/cpu/mpc86xx/Makefile
@@ -31,10 +31,9 @@ LIB  = $(obj)lib$(CPU).a
 START  = start.o
 SOBJS  = cache.o
 
-ifneq ($(CONFIG_NUM_CPUS),1)
-COBJS-y += mp.o
-SOBJS += release.o
-endif
+SOBJS-$(CONFIG_MP) += release.o
+SOBJS  += $(SOBJS-y)
+COBJS-$(CONFIG_MP) += mp.o
 COBJS-y+= traps.o
 COBJS-y+= cpu.o
 COBJS-y+= cpu_init.o
diff --git a/cpu/mpc86xx/fdt.c b/cpu/mpc86xx/fdt.c
index 383b06b..ee2eb0b 100644
--- a/cpu/mpc86xx/fdt.c
+++ b/cpu/mpc86xx/fdt.c
@@ -15,9 +15,9 @@ DECLARE_GLOBAL_DATA_PTR;
 
 void ft_cpu_setup(void *blob, bd_t *bd)
 {
-#if (CONFIG_NUM_CPUS > 1)
+#ifdef CONFIG_MP
int off;
-   u32 bootpg;
+   u32 bootpg = determine_mp_bootpg();
 #endif
 
do_fixup_by_prop_u32(blob, "device_type", "cpu", 4,
@@ -48,13 +48,7 @@ void ft_cpu_setup(void *blob, bd_t *bd)
   "clock-frequency", CONFIG_SYS_NS16550_CLK, 1);
 #endif
 
-#if (CONFIG_NUM_CPUS > 1)
-   /* if we have 4G or more of memory, put the boot page at 4Gb-1M */
-   if (gd->ram_size > 0xf000)
-   bootpg = 0xfff0;
-   else
-   bootpg = gd->ram_size - (1024 * 1024);
-
+#ifdef CONFIG_MP
/* Reserve the boot page so OSes dont use it */
off = fdt_add_mem_rsv(blob, bootpg, (u64)4096);
if (off < 0)
diff --git a/cpu/mpc86xx/mp.c b/cpu/mpc86xx/mp.c
index 5014401..b4c6b79 100644
--- a/cpu/mpc86xx/mp.c
+++ b/cpu/mpc86xx/mp.c
@@ -8,16 +8,39 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-#if (CONFIG_NUM_CPUS > 1)
-void cpu_mp_lmb_reserve(struct lmb *lmb)
+int cpu_reset(int nr)
+{
+   volatile immap_t *immr = (immap_t *)CONFIG_SYS_IMMR;
+   volatile ccsr_pic_t *pic = &immr->im_pic;
+   out_be32(&pic->pir, 1 << nr);
+   (void)in_be32(&pic->pir);
+   out_be32(&pic->pir, 0x0);
+
+   return 0;
+}
+
+int cpu_status(int nr)
+{
+   return 1;
+}
+
+int cpu_release(int nr, int argc, char *argv[])
 {
-   u32 bootpg;
+   return 1;
+}
 
+u32 determine_mp_bootpg(void)
+{
/* if we have 4G or more of memory, put the boot page at 4Gb-1M */
if ((u64)gd->ram_size > 0xf000)
-   bootpg = 0xfff0;
-   else
-   bootpg = gd->ram_size - (1024 * 1024);
+   return (0xfff0);
+
+   return (gd->ram_size - (1024 * 1024));
+}
+
+void cpu_mp_lmb_reserve(struct lmb *lmb)
+{
+   u32 bootpg = determine_mp_bootpg();
 
/* tell u-boot we stole a page */
lmb_reserve(lmb, bootpg, 4096);
@@ -31,18 +54,9 @@ void setup_mp(void)
 {
extern ulong __secondary_start_page;
ulong fixup = (ulong)&__secondary_start_page;
-   u32 bootpg;
+   u32 bootpg = determine_mp_bootpg();
u32 bootpg_va;
 
-   /*
-* If we have 4G or more of memory, put the boot page at 4Gb-1M.
-  

[U-Boot] [PATCH] 85xx: Introduce determine_mp_bootpg() helper.

[Kumar Gala]

Match determine_mp_bootpg() that was added for 86xx.  We need this to
address a bug introduced in v2009.03 with 86xx MP booting.  We have to
make sure to reserve the region of memory used for the MP bootpg() so
other u-boot code doesn't use it.

Signed-off-by: Kumar Gala 
---
 cpu/mpc85xx/fdt.c |9 ++---
 cpu/mpc85xx/mp.c  |   25 +++--
 cpu/mpc85xx/mp.h  |2 +-
 3 files changed, 14 insertions(+), 22 deletions(-)

diff --git a/cpu/mpc85xx/fdt.c b/cpu/mpc85xx/fdt.c
index 2d36c24..26a8f48 100644
--- a/cpu/mpc85xx/fdt.c
+++ b/cpu/mpc85xx/fdt.c
@@ -39,13 +39,8 @@ void ft_fixup_cpu(void *blob, u64 memory_limit)
 {
int off;
ulong spin_tbl_addr = get_spin_addr();
-   u32 bootpg, id = get_my_id();
-
-   /* if we have 4G or more of memory, put the boot page at 4Gb-4k */
-   if ((u64)gd->ram_size > 0xf000)
-   bootpg = 0xf000;
-   else
-   bootpg = gd->ram_size - 4096;
+   u32 bootpg = determine_mp_bootpg();
+   u32 id = get_my_id();
 
off = fdt_node_offset_by_prop_value(blob, -1, "device_type", "cpu", 4);
while (off != -FDT_ERR_NOTFOUND) {
diff --git a/cpu/mpc85xx/mp.c b/cpu/mpc85xx/mp.c
index 3338c1a..8ddd81d 100644
--- a/cpu/mpc85xx/mp.c
+++ b/cpu/mpc85xx/mp.c
@@ -112,6 +112,15 @@ int cpu_release(int nr, int argc, char *argv[])
return 0;
 }
 
+u32 determine_mp_bootpg(void)
+{
+   /* if we have 4G or more of memory, put the boot page at 4Gb-4k */
+   if ((u64)gd->ram_size > 0xf000)
+   return (0xf000);
+
+   return (gd->ram_size - 4096);
+}
+
 ulong get_spin_addr(void)
 {
extern ulong __secondary_start_page;
@@ -188,13 +197,7 @@ static void pq3_mp_up(unsigned long bootpg)
 
 void cpu_mp_lmb_reserve(struct lmb *lmb)
 {
-   u32 bootpg;
-
-   /* if we have 4G or more of memory, put the boot page at 4Gb-4k */
-   if ((u64)gd->ram_size > 0xf000)
-   bootpg = 0xf000;
-   else
-   bootpg = gd->ram_size - 4096;
+   u32 bootpg = determine_mp_bootpg();
 
lmb_reserve(lmb, bootpg, 4096);
 }
@@ -203,13 +206,7 @@ void setup_mp(void)
 {
extern ulong __secondary_start_page;
ulong fixup = (ulong)&__secondary_start_page;
-   u32 bootpg;
-
-   /* if we have 4G or more of memory, put the boot page at 4Gb-4k */
-   if ((u64)gd->ram_size > 0xf000)
-   bootpg = 0xf000;
-   else
-   bootpg = gd->ram_size - 4096;
+   u32 bootpg = determine_mp_bootpg();
 
memcpy((void *)bootpg, (void *)fixup, 4096);
flush_cache(bootpg, 4096);
diff --git a/cpu/mpc85xx/mp.h b/cpu/mpc85xx/mp.h
index b06707f..71423ef 100644
--- a/cpu/mpc85xx/mp.h
+++ b/cpu/mpc85xx/mp.h
@@ -5,7 +5,7 @@ ulong get_spin_addr(void);
 void setup_mp(void);
 u32 get_my_id(void);
 void cpu_mp_lmb_reserve(struct lmb *lmb);
-u32 determine_bootpg(void);
+u32 determine_mp_bootpg(void);
 
 #define BOOT_ENTRY_ADDR_UPPER  0
 #define BOOT_ENTRY_ADDR_LOWER  1
-- 
1.5.6.6

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

Re: [U-Boot] [PATCH] mpc/sbc8641d: Add missing board_lmb_reserves

[Kumar Gala]

On Mar 31, 2009, at 6:38 PM, Becky Bruce wrote:

> We're missing the board_lmb_reserve definitions that allow
> cpu_mp_lmb_reserve to be called; this means that Linux
> is free to reallocate reserved pages.  Linux currently boots
> because we're getting lucky - the page we've reserved is
> high enough in memory that it isn't allocated by Linux
> while we still need it to be in existence.
>
> Signed-off-by: Becky Bruce 
> ---
> board/freescale/mpc8641hpcn/mpc8641hpcn.c |9 +
> board/sbc8641d/sbc8641d.c |9 +
> 2 files changed, 18 insertions(+), 0 deletions(-)

applied

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

Re: [U-Boot] [PATCH 1/2] Fix OneNAND ipl to read CONFIG_SYS_MONITOR_LEN

[Amit Kumar Sharma]

Hi Scott,

- Original Message - 
From: "Scott Wood" 
To: "Alessandro Rubini" 
Cc: ; 
Sent: Tuesday, March 31, 2009 9:43 PM
Subject: Re: [U-Boot] [PATCH 1/2] Fix OneNAND ipl to read 
CONFIG_SYS_MONITOR_LEN


> Alessandro Rubini wrote:
>> Hello.
>>
>>> Note that there are a couple of board files (apollon and 
>>> nmdk8815) that
>>> use the OneNAND loader that do not define 
>>> CONFIG_SYS_MONITOR_LEN.  I've
>>> added the maintainers to the Cc: list.
>>
>> Sorry for the delay.
>>
>> In the nomadik board the OneNAND driver is not yet 
>> present, a few init
>> lines are still missing (I have an error to fix before 
>> submitting those
>> lines).  I'll take care of CONFIG_SYS_MONITOR_LEN 
>> together with that.
>>
>> Note however that on the Nomadik we don't use the IPL, 
>> since u-boot is
>> loaded by other code (a proprietary IPL that onlocks the 
>> CPU before
>> handing control to ours) so u-boot isn't even in the 
>> first sector
>> of OneNAND.
>
> OK, sorry about that.  I ran into the issue when building 
> apollon, and
> nmdk8815 looked like it was in a similar situation from 
> grepping config
> files.
>
> -Scott

>From Alessandro mail it is claear CONFIG_SYS_MONITOR_LEN 
only used by apollon
that can be changed by Apollon users independently. we will 
check othe rissue of white space and release patch.

Amit
> ___
> 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] Add support for Faraday RTC IP FTRTC

[莊博宇]

Dear Wolfgang Denk,

I am a newbie and I have not realized all the rules, so I 
have some questions.

On Tue Mar 31 12:24:03 CEST 2009, you wrote:
> > +static unsigned intrtc = CONFIG_SYS_RTC_BASE;
> 
> Please use a proper C structure to describe the RTC; do not use base
> address plus offsets.

Do you mean U-Boot prefers to use structure to describe 
registers? What if there were large gaps between registers?

For example, in our ethernet IP FTMAC100,  there is nothing
in 0x34 - 0x84, 0xa0 - 0xc0. Should I use structure to
describe it?

I thought that placing a lot of paddings in a structure is ulgy. 
How do you think? Is there a guideline about this?

Also in drivers/rtc/pl031.c, the RTC_WRITE_REG and 
RTC_READ_REG use base + offset.

> outl() is not portable across architectures?
> inl() is not portable across architectures?

Sorry I don't understand.

There are outl() and inl() in most architectures except blackfin, 
i386 and sparc. And the outl() and the inl() I use are arm ones.

Which macros should I use?

> > +   debug("rtc_get(): record register: %x\n", inl(rtc + 
> > FTRTC_OFFSET_RECORD));
>
> Line too long.

Sorry, this is my fault. I will fix them.

Best Regards,
 
Po-Yu Chuang (莊博宇)
=== Faraday Technology Corporation, Headquarters TW ===
= 智原科技股份有限公司 
= Dept.: CTD/SD/SSD
= Tel  : 886-3-578-7888 Ext:8818
= Fax  : 886-3-666-3958
= Email: ratb...@faraday-tech.com
= WWW  : www.faraday-tech.com 
===

* Confidentiality Notice 
This electronic message and any attachments may contain
confidential and legally privileged information or
information which is otherwise protected from disclosure.
If you are not the intended recipient,please do not disclose
the contents, either in whole or in part, to anyone,and
immediately delete the message and any attachments from
your computer system and destroy all hard copies.
Thank you for your cooperation.
***

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

[U-Boot] [PATCH] Add support for Faraday Ethernet IP FTMAC100

[莊博宇]

Dear Mike Frysinger,

On Tue Mar 31 11:18:44 CEST 2009, you wrote:
> > This patch adds support for Faraday Technology Ethernet IP - FTMAC100
> kind of redundant statement considering the summary ...

Sorry I have not realized the rules here.
It looks like things here will be put into CHANGELOG.
I will remove this (or put some more meaningful descriptions) 
next time.

> > Signed-off-by: Po-Yu Chuang 
> you should really be using git to generate patches and send e-mails.  also, 
> signed-off-by (and similar tags) use real addresses, not munged ones.

OK, I will fix it in the new patches. Thank you.

Best Regards,
 
Po-Yu Chuang (莊博宇)
=== Faraday Technology Corporation, Headquarters TW ===
= 智原科技股份有限公司 
= Dept.: CTD/SD/SSD
= Tel  : 886-3-578-7888 Ext:8818
= Fax  : 886-3-666-3958
= Email: ratb...@faraday-tech.com
= WWW  : www.faraday-tech.com 
===

* Confidentiality Notice 
This electronic message and any attachments may contain
confidential and legally privileged information or
information which is otherwise protected from disclosure.
If you are not the intended recipient,please do not disclose
the contents, either in whole or in part, to anyone,and
immediately delete the message and any attachments from
your computer system and destroy all hard copies.
Thank you for your cooperation.
***

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

[U-Boot] (no subject)

[卫 王]

hello:
  recently,i'm using the new edition of u-boot,the 
edition u-boot-2009-rc1.and i met some troubles.so i need your help.
  i want to use the usbkeyboard as a console,how can i add this function to 
the u-boot?
because the interrupt is masked in the u-boot.and i've read your document,you 
said i need a script.but i don't know how to write that,can you offer me 
somehelp.by the way,the mcu of my board is s3c2410.

 yours:Iverson David
 
  2009.4.1


  ___ 
  好玩贺卡等你发，邮箱贺卡全新上线！ 
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] Add support for Faraday Ethernet IP FTMAC100

[莊博宇]

Dear Jean-Christophe PLAGNIOL-VILLARD,

On Tue Mar 31 10:51:31 CEST 2009, you wrote:
> > This patch adds support for Faraday Technology Ethernet IP - FTMAC100
> >
> Do you have any plan to add a SOC and a board?
Yes, I need some time to cleanup the source though.

I think to put some drivers first and the board might be added 
later in next merge window

Best Regards,
 
Po-Yu Chuang (莊博宇)
=== Faraday Technology Corporation, Headquarters TW ===
= 智原科技股份有限公司 
= Dept.: CTD/SD/SSD
= Tel  : 886-3-578-7888 Ext:8818
= Fax  : 886-3-666-3958
= Email: ratb...@faraday-tech.com
= WWW  : www.faraday-tech.com 
===

* Confidentiality Notice 
This electronic message and any attachments may contain
confidential and legally privileged information or
information which is otherwise protected from disclosure.
If you are not the intended recipient,please do not disclose
the contents, either in whole or in part, to anyone,and
immediately delete the message and any attachments from
your computer system and destroy all hard copies.
Thank you for your cooperation.
***

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

Re: [U-Boot] [PATCH] Added a tftp command

[Mike Frysinger]

On Tuesday 31 March 2009 19:40:27 kevin.morf...@fearnside-systems.co.uk wrote:
> Mike Frysinger wrote:
> > On Tuesday 31 March 2009 18:44:21 kevin.morfitt wrote:
> >> Adds a "tftp" command that gets a specified file from a TFTP Server and
> >> stores it in RAM at a specified RAM address. Most of the code already
> >> exists in board-specific form (eg in board/hymod) but this patch
> >> extracts it and makes it available as a standard u-boot command.
> >
> > your patch is horribly word wrapped.  ignoring that, how is this any
> > different from the "tftpboot" command ?  i use "t  " to load
> > arbitrary files via tftp to arbitrary addresses all the time.
>
> "tftpboot" loads the file then if "autostart" is "yes" it automatically
> boots from the load address. The patch just loads the file then stops.
> When programming a board I use it to copy images across before I program
> them into flash. In effect, it does the same thing as setting
> "autostart" to "off" then using "tftpboot".

so dont set autostart ?
-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

Re: [U-Boot] [PATCH] Added a tftp command

[kevin.morf...@fearnside-systems.co.uk]

Kumar Gala wrote:
>
> On Mar 31, 2009, at 5:44 PM, kevin.morf...@fearnside-systems.co.uk wrote:
>
>> Adds a "tftp" command that gets a specified file from a TFTP Server and
>> stores it in RAM at a specified RAM address. Most of the code already
>> exists in board-specific form (eg in board/hymod) but this patch
>> extracts it and makes it available as a standard u-boot command.
>>
>> Signed-off-by: Kevin Morfitt 
>> ---
>> common/cmd_tftp.c|   59
>> ++
>> doc/README.tftp  |   29 
>> include/config_cmd_all.h |1 +
>> include/config_cmd_default.h |1 +
>> 4 files changed, 90 insertions(+), 0 deletions(-)
>> create mode 100755 common/cmd_tftp.c
>> create mode 100755 doc/README.tftp
>
> I'm quite confused.  We already have support for this.  I'm pretty 
> sure I use it almost daily.
>
> - k
So do I but I'm working with a u-boot my customer has modified to add it 
as a board-specific command. When I tried to use it on a new board with 
the latest u-boot  I found it wasn't a standard u-boot command. It's 
almost identical to "tftpboot" except that if "autostart" is set to 
"yes" "tftpboot" automatically boots from the file after it's downloaded 
it but "tftp" doesn't. I use it to copy images across then manually 
program them into flash.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Added a tftp command

[kevin.morf...@fearnside-systems.co.uk]

Mike Frysinger wrote:
> On Tuesday 31 March 2009 18:44:21 kevin.morf...@fearnside-systems.co.uk wrote:
>   
>> Adds a "tftp" command that gets a specified file from a TFTP Server and
>> stores it in RAM at a specified RAM address. Most of the code already
>> exists in board-specific form (eg in board/hymod) but this patch
>> extracts it and makes it available as a standard u-boot command.
>> 
>
> your patch is horribly word wrapped.  ignoring that, how is this any 
> different 
> from the "tftpboot" command ?  i use "t  " to load arbitrary 
> files 
> via tftp to arbitrary addresses all the time.
> -mike
>   
"tftpboot" loads the file then if "autostart" is "yes" it automatically 
boots from the load address. The patch just loads the file then stops. 
When programming a board I use it to copy images across before I program 
them into flash. In effect, it does the same thing as setting 
"autostart" to "off" then using "tftpboot".

I'm new to creating patches which I think explains the horrible word 
wrapping.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] mpc/sbc8641d: Add missing board_lmb_reserves

[Becky Bruce]

We're missing the board_lmb_reserve definitions that allow
cpu_mp_lmb_reserve to be called; this means that Linux
is free to reallocate reserved pages.  Linux currently boots
because we're getting lucky - the page we've reserved is
high enough in memory that it isn't allocated by Linux
while we still need it to be in existence.

Signed-off-by: Becky Bruce 
---
 board/freescale/mpc8641hpcn/mpc8641hpcn.c |9 +
 board/sbc8641d/sbc8641d.c |9 +
 2 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/board/freescale/mpc8641hpcn/mpc8641hpcn.c 
b/board/freescale/mpc8641hpcn/mpc8641hpcn.c
index c94fc3f..1e35dfa 100644
--- a/board/freescale/mpc8641hpcn/mpc8641hpcn.c
+++ b/board/freescale/mpc8641hpcn/mpc8641hpcn.c
@@ -374,3 +374,12 @@ void board_reset(void)
while (1)
;
 }
+
+#if (CONFIG_NUM_CPUS > 1)
+extern void cpu_mp_lmb_reserve(struct lmb *lmb);
+
+void board_lmb_reserve(struct lmb *lmb)
+{
+   cpu_mp_lmb_reserve(lmb);
+}
+#endif
diff --git a/board/sbc8641d/sbc8641d.c b/board/sbc8641d/sbc8641d.c
index 52ad2d8..fc1f07d 100644
--- a/board/sbc8641d/sbc8641d.c
+++ b/board/sbc8641d/sbc8641d.c
@@ -413,3 +413,12 @@ void board_reset(void)
__asm__ __volatile__ ("rfi");
 #endif
 }
+
+#if (CONFIG_NUM_CPUS > 1)
+extern void cpu_mp_lmb_reserve(struct lmb *lmb);
+
+void board_lmb_reserve(struct lmb *lmb)
+{
+   cpu_mp_lmb_reserve(lmb);
+}
+#endif
-- 
1.5.6.6

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

Re: [U-Boot] [PATCH] Added a tftp command

[Kumar Gala]

On Mar 31, 2009, at 5:44 PM, kevin.morf...@fearnside-systems.co.uk  
wrote:

> Adds a "tftp" command that gets a specified file from a TFTP Server  
> and
> stores it in RAM at a specified RAM address. Most of the code already
> exists in board-specific form (eg in board/hymod) but this patch
> extracts it and makes it available as a standard u-boot command.
>
> Signed-off-by: Kevin Morfitt 
> ---
> common/cmd_tftp.c|   59
> ++
> doc/README.tftp  |   29 
> include/config_cmd_all.h |1 +
> include/config_cmd_default.h |1 +
> 4 files changed, 90 insertions(+), 0 deletions(-)
> create mode 100755 common/cmd_tftp.c
> create mode 100755 doc/README.tftp

I'm quite confused.  We already have support for this.  I'm pretty  
sure I use it almost daily.

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

Re: [U-Boot] [PATCH] Added a tftp command

[Mike Frysinger]

On Tuesday 31 March 2009 18:44:21 kevin.morf...@fearnside-systems.co.uk wrote:
> Adds a "tftp" command that gets a specified file from a TFTP Server and
> stores it in RAM at a specified RAM address. Most of the code already
> exists in board-specific form (eg in board/hymod) but this patch
> extracts it and makes it available as a standard u-boot command.

your patch is horribly word wrapped.  ignoring that, how is this any different 
from the "tftpboot" command ?  i use "t  " to load arbitrary files 
via tftp to arbitrary addresses all the time.
-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

Re: [U-Boot] [PATCH 13/13] at91sam9263ek: active hush and auto compelete support

[Stelian Pop]

On Tue, Mar 31, 2009 at 10:35:00PM +0200, Wolfgang Denk wrote:

> > Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD 
> > +#define CONFIG_AUTO_COMPLETE
> > +#define CONFIG_SYS_HUSH_PARSER
> > +#define CONFIG_SYS_PROMPT_HUSH_PS2 "> "
> 
> You are not the maintainer of this board.
> 
> You are not supposed to make any such modifications without permission
> of the board mainteiner.
> 
> Stelian, please comment.

In the interest of keeping the various Atmel boards uniform, I'm ok
with this patch. So:
Signed-off-by: Stelian Pop 

JC: please CC: me directly next time, I'm rather busy lately and not
always following the posts on the mailing list...

Thanks !

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

[U-Boot] [PATCH] Added a tftp command

[kevin.morf...@fearnside-systems.co.uk]

Adds a "tftp" command that gets a specified file from a TFTP Server and 
stores it in RAM at a specified RAM address. Most of the code already 
exists in board-specific form (eg in board/hymod) but this patch 
extracts it and makes it available as a standard u-boot command.

Signed-off-by: Kevin Morfitt 
---
 common/cmd_tftp.c|   59 
++
 doc/README.tftp  |   29 
 include/config_cmd_all.h |1 +
 include/config_cmd_default.h |1 +
 4 files changed, 90 insertions(+), 0 deletions(-)
 create mode 100755 common/cmd_tftp.c
 create mode 100755 doc/README.tftp

diff --git a/common/cmd_tftp.c b/common/cmd_tftp.c
new file mode 100755
index 000..7aa5d0a
--- /dev/null
+++ b/common/cmd_tftp.c
@@ -0,0 +1,59 @@
+/*
+ * (C) Copyright 2009
+ * Kevin Morfitt, Fearnside Systems Ltd, 

+ *
+ * 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 
+
+static int get_file_tftp(struct cmd_tbl_s *cmftp, int flag, int argc,
+char *argv[]);
+
+U_BOOT_CMD(
+tftp, 3, 0, get_file_tftp,
+"tftp\t- Upload a file via TFTP",
+"  - Upload  to  via TFTP"
+);
+
+static int get_file_tftp(struct cmd_tbl_s *cmftp, int flag,
+int argc, char *argv[])
+{
+load_addr = simple_strtoul(argv[1], NULL, 16);
+copy_filename(BootFile, argv[2], sizeof (BootFile));
+NetBootFileXferSize = 0;
+
+debug("TFTP: Filename: %s Address: 0x%08X\n", BootFile,
+(unsigned int)load_addr);
+
+if (NetLoop (TFTP) <= 0) {
+printf("ERROR: tftp transfer failed\n");
+return -1;
+}
+
+if (NetBootFileXferSize == 0) {
+printf("ERROR: Can't determine file size\n");
+return -1;
+}
+
+printf("File transfer succeeded - file size %lu bytes\n",
+NetBootFileXferSize);
+return 0;
+}
diff --git a/doc/README.tftp b/doc/README.tftp
new file mode 100755
index 000..d13603a
--- /dev/null
+++ b/doc/README.tftp
@@ -0,0 +1,29 @@
+Get a file from a TFTP server
+=
+
+Overview
+
+
+The "tftp" command allows a user retrieve a file from a TFTP server and 
store
+it in RAM. The RAM load address and the filename are passed via the 
command
+line and the TFTP server address is that defined by the "serverip" 
environment
+variable.
+
+Enabling the command
+
+
+The command is enabled in the build by the CONFIG_CMD_TFTP macro:
+
+#define CONFIG_CMD_TFTP1
+
+Using the command
+-
+
+The format of the command is:
+
+tftp  
+
+where:
+
+ is the address of the RAM buffer used to receive the file
+ is the name of the file to be retrieved via tftp
diff --git a/include/config_cmd_all.h b/include/config_cmd_all.h
index db1f55c..a7129d4 100644
--- a/include/config_cmd_all.h
+++ b/include/config_cmd_all.h
@@ -78,6 +78,7 @@
 #define CONFIG_CMD_SNTP/* SNTP support*/
 #define CONFIG_CMD_SPI/* SPI utility*/
 #define CONFIG_CMD_TERMINAL/* built-in Serial Terminal*/
+#define CONFIG_CMD_TFTP/* Get file via TFTP*/
 #define CONFIG_CMD_UNIVERSE/* Tundra Universe Support*/
 #define CONFIG_CMD_UNZIP/* unzip from memory to memory*/
 #define CONFIG_CMD_USB/* USB Support*/
diff --git a/include/config_cmd_default.h b/include/config_cmd_default.h
index 3667602..cee6a1c 100644
--- a/include/config_cmd_default.h
+++ b/include/config_cmd_default.h
@@ -37,6 +37,7 @@
 #define CONFIG_CMD_NFS/* NFS support*/
 #define CONFIG_CMD_RUN/* run command in env variable*/
 #define CONFIG_CMD_SETGETDCR/* DCR support on 4xx*/
+#define CONFIG_CMD_TFTP/* Get file via TFTP*/
 #define CONFIG_CMD_XIMG/* Load part of Multi Image*/
 
 #endif/* _CONFIG_CMD_DEFAULT_H */
-- 
1.6.0.6


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

[U-Boot] [PATCH] mpc83xx: Set guarded bit on BAT that covers the end of the address space

[Kim Phillips]

From: Scott Wood 

The mpc8313erdb board currently sets DBAT6 to cover all of the final 256MiB of
address space; however, not all of this space is covered by a device.  In
particular, flash sits at 0xfe00-0xfe7f, and nothing is mapped
at the far end of the address space.

In zlib, there is a loop that references p[-1] if p is non-NULL.  Under
some circumstances, this leads to the CPU speculatively loading from
0xfff8 if p is NULL.  This leads to a machine check.

Signed-off-by: Scott Wood 

continuation to the remaining mpc83xx boards that suffer from the same problem.

Signed-off-by: Kim Phillips 
---
 include/configs/MPC8313ERDB.h |2 +-
 include/configs/MPC8349EMDS.h |3 ++-
 include/configs/MPC8349ITX.h  |3 ++-
 include/configs/MVBLM7.h  |3 ++-
 include/configs/SIMPC8313.h   |2 +-
 include/configs/sbc8349.h |3 ++-
 6 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/include/configs/MPC8313ERDB.h b/include/configs/MPC8313ERDB.h
index 0ef4eba..21aedee 100644
--- a/include/configs/MPC8313ERDB.h
+++ b/include/configs/MPC8313ERDB.h
@@ -544,7 +544,7 @@
 #define CONFIG_SYS_IBAT5U  (CONFIG_SYS_IMMR | BATU_BL_256M | BATU_VS | 
BATU_VP)
 
 /* SDRAM @ 0xF000, stack in DCACHE 0xFDF0 & FLASH @ 0xFE00 */
-#define CONFIG_SYS_IBAT6L  (0xF000 | BATL_PP_10)
+#define CONFIG_SYS_IBAT6L  (0xF000 | BATL_PP_10 | BATL_GUARDEDSTORAGE)
 #define CONFIG_SYS_IBAT6U  (0xF000 | BATU_BL_256M | BATU_VS | BATU_VP)
 
 #define CONFIG_SYS_IBAT7L  (0)
diff --git a/include/configs/MPC8349EMDS.h b/include/configs/MPC8349EMDS.h
index b3c0e2d..0d1d663 100644
--- a/include/configs/MPC8349EMDS.h
+++ b/include/configs/MPC8349EMDS.h
@@ -683,7 +683,8 @@
 #define CONFIG_SYS_IBAT5U  (CONFIG_SYS_IMMR | BATU_BL_256M | BATU_VS | 
BATU_VP)
 
 /* SDRAM @ 0xF000, stack in DCACHE 0xFDF0 & FLASH @ 0xFE00 */
-#define CONFIG_SYS_IBAT6L  (0xF000 | BATL_PP_10 | BATL_MEMCOHERENCE)
+#define CONFIG_SYS_IBAT6L  (0xF000 | BATL_PP_10 | BATL_MEMCOHERENCE | \
+BATL_GUARDEDSTORAGE)
 #define CONFIG_SYS_IBAT6U  (0xF000 | BATU_BL_256M | BATU_VS | BATU_VP)
 
 #define CONFIG_SYS_IBAT7L  (0)
diff --git a/include/configs/MPC8349ITX.h b/include/configs/MPC8349ITX.h
index 38a7386..ab6fe55 100644
--- a/include/configs/MPC8349ITX.h
+++ b/include/configs/MPC8349ITX.h
@@ -615,7 +615,8 @@ boards, we say we have two, but don't display a message if 
we find only one. */
 #define CONFIG_SYS_IBAT5U  (CONFIG_SYS_IMMR | BATU_BL_256M | BATU_VS | 
BATU_VP)
 
 /* SDRAM @ 0xF000, stack in DCACHE 0xFDF0 & FLASH @ 0xFE00 */
-#define CONFIG_SYS_IBAT6L  (0xF000 | BATL_PP_10 | BATL_MEMCOHERENCE)
+#define CONFIG_SYS_IBAT6L  (0xF000 | BATL_PP_10 | BATL_MEMCOHERENCE | \
+BATL_GUARDEDSTORAGE)
 #define CONFIG_SYS_IBAT6U  (0xF000 | BATU_BL_256M | BATU_VS | BATU_VP)
 
 #define CONFIG_SYS_IBAT7L  0
diff --git a/include/configs/MVBLM7.h b/include/configs/MVBLM7.h
index 4ecf806..b321825 100644
--- a/include/configs/MVBLM7.h
+++ b/include/configs/MVBLM7.h
@@ -360,7 +360,8 @@
 #define CONFIG_SYS_IBAT5U  (CONFIG_SYS_IMMR | BATU_BL_256M | BATU_VS | 
BATU_VP)
 
 /* stack in DCACHE 0xFDF0 & FLASH @ 0xFF80 */
-#define CONFIG_SYS_IBAT6L  (0xF000 | BATL_PP_10 | BATL_MEMCOHERENCE)
+#define CONFIG_SYS_IBAT6L  (0xF000 | BATL_PP_10 | BATL_MEMCOHERENCE | \
+BATL_GUARDEDSTORAGE)
 #define CONFIG_SYS_IBAT6U  (0xF000 | BATU_BL_256M | BATU_VS | BATU_VP)
 #define CONFIG_SYS_IBAT7L  0
 #define CONFIG_SYS_IBAT7U  0
diff --git a/include/configs/SIMPC8313.h b/include/configs/SIMPC8313.h
index e20527e..79582e1 100644
--- a/include/configs/SIMPC8313.h
+++ b/include/configs/SIMPC8313.h
@@ -437,7 +437,7 @@
 #define CONFIG_SYS_IBAT5U  (CONFIG_SYS_IMMR | BATU_BL_256M | BATU_VS | 
BATU_VP)
 
 /* SDRAM @ 0xF000, stack in DCACHE 0xFDF0 & FLASH @ 0xFE00 */
-#define CONFIG_SYS_IBAT6L  (0xF000 | BATL_PP_10)
+#define CONFIG_SYS_IBAT6L  (0xF000 | BATL_PP_10 | BATL_GUARDEDSTORAGE)
 #define CONFIG_SYS_IBAT6U  (0xF000 | BATU_BL_256M | BATU_VS | BATU_VP)
 
 #define CONFIG_SYS_IBAT7L  (0)
diff --git a/include/configs/sbc8349.h b/include/configs/sbc8349.h
index f476e3e..42033ac 100644
--- a/include/configs/sbc8349.h
+++ b/include/configs/sbc8349.h
@@ -605,7 +605,8 @@
 #define CONFIG_SYS_IBAT5U  (CONFIG_SYS_IMMR | BATU_BL_256M | BATU_VS | 
BATU_VP)
 
 /* SDRAM @ 0xF000, stack in DCACHE 0xFDF0 & FLASH @ 0xFE00 */
-#define CONFIG_SYS_IBAT6L  (0xF000 | BATL_PP_10 | BATL_MEMCOHERENCE)
+#define CONFIG_SYS_IBAT6L  (0xF000 | BATL_PP_10 | BATL_MEMCOHERENCE | \
+BATL_GUARDEDSTORAGE)
 #define CONFIG_SYS_IBAT6U  (0xF000 | BATU_BL_256M | BATU_VS | BATU_VP)
 
 #define CONFIG_SYS_IBAT7L  (0)
-- 
1.6.1.3

_

Re: [U-Boot] [PATCH 10/13] at91: move usb driver to drivers/usb

[Jean-Christophe PLAGNIOL-VILLARD]

On 22:38 Tue 31 Mar , Wolfgang Denk wrote:
> Dear Jean-Christophe PLAGNIOL-VILLARD,
> 
> In message <20090331192117.gf24...@game.jcrosoft.org> you wrote:
> >
> > > >  drivers/usb/Makefile                        >        |    1 +
> > > >  .../at91/usb.c => drivers/usb/atmel_usb.c          |  >   0
> > > >  rename cpu/arm926ejs/at91/usb.c => drivers/usb/atmel_usb.c (100%)
> > > >
> > > Same here, this is architecture specific code, why move it to generic 
> > > cod> e?
> > it's the at91 usb drivers and we need to have it in the driver/usb
> 
> Why do we need to have it in the driver/usb ?
> 
> Please explain in detail.
> 
> > and it's not at91/arm926 specific but it's also shared with the at91rm9200
> >
> > so I move to drivers usb
> >
> > please note that the RM9200 will be move to the at91 API next release
> 
> So. Will it. Really? Who discussed this, and where, and when?
> Please explain in detail.
as I said the usb drivers, spi, serial are shared between at91sam9, rm9200
and some with avr32
so do need to avoid copy and paste to each cpu specialy when it's drivers or
IP init not specific to a SOC

The RM9200 is in preparation and will be finished for the next merge window
so no patch has been yes published until it's finished

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

Re: [U-Boot] [PATCH] mpc83xx: Set guarded bit on BAT that covers the end of the address space

[Kim Phillips]

On Tue, 31 Mar 2009 23:24:42 +0200
Wolfgang Denk  wrote:

> Dear Scott Wood,
> 
> In message <49d28575.1040...@freescale.com> you wrote:
> >
> > > Umm... what does that mean: "continuation of commit a5d7049a4"?
> > > 
> > > If these commits belong together logically, you must not split them
> > > apart.
> > 
> > There's no bisectability problem; it's just similar bugs being fixed on 
> > other boards.
> 
> why not fix them in a single commit, then?

this sounds reasonable - it gets rid of a moot commit, saving bisection
its traversal. I'll add this to Scott's original patch and explain what
I did between the s-o-b lines.

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

Re: [U-Boot] [PATCH 1/1] at91sam9/at91cap: improve clock framework

[Jean-Christophe PLAGNIOL-VILLARD]

On 23:26 Tue 31 Mar , Wolfgang Denk wrote:
> Dear Jean-Christophe PLAGNIOL-VILLARD,
> 
> In message <20090331210130.gj24...@game.jcrosoft.org> you wrote:
> > On 22:59 Tue 31 Mar , Wolfgang Denk wrote:
> > > Dear Jean-Christophe PLAGNIOL-VILLARD,
> > > 
> > > In message <1238486824-19007-1-git-send-email-plagn...@jcrosoft.com> you 
> > > wrote:
> > > > calculate dynamically the clock rate and pllb setting for usb
> > > > 
> > > > Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD 
> > > > ---
> > > >  board/atmel/at91cap9adk/at91cap9adk.c |3 +-
> > > >  board/atmel/at91sam9261ek/at91sam9261ek.c |3 +-
> > > >  board/atmel/at91sam9263ek/at91sam9263ek.c |3 +-
> > > >  board/atmel/at91sam9rlek/at91sam9rlek.c   |3 +-
> > > >  cpu/arm926ejs/at91/Makefile   |2 +
> > > >  cpu/arm926ejs/at91/clock.c|  196 
> > > > +
> > > >  cpu/arm926ejs/at91/cpu.c  |   14 ++
> > > >  drivers/spi/atmel_dataflash_spi.c |7 +-
> > > >  drivers/usb/atmel_usb.c   |3 +-
> > > >  include/asm-arm/arch-at91/clk.h   |   17 ++-
> > > >  include/asm-arm/arch-at91/hardware.h  |3 +
> > > >  include/asm-arm/u-boot-arm.h  |3 +
> > > >  include/configs/afeb9260.h|6 +-
> > > >  include/configs/at91cap9adk.h |7 +-
> > > >  include/configs/at91sam9260ek.h   |9 +--
> > > >  include/configs/at91sam9261ek.h   |6 +-
> > > >  include/configs/at91sam9263ek.h   |7 +-
> > > >  include/configs/at91sam9rlek.h|6 +-
> > > >  lib_arm/board.c   |3 +
> > > >  19 files changed, 254 insertions(+), 47 deletions(-)
> > > >  create mode 100644 cpu/arm926ejs/at91/clock.c
> > > >  create mode 100644 cpu/arm926ejs/at91/cpu.c
> > > 
> > > What is the impact of this patch on the memory footprint of the
> > > system?
> > 708 bytes on the 9263ek
> 
> 708 bytes more or less? And how much on the others processors?
more
9260ek  => +704
9261ek  => +680
9263ek  => +708
9rlek   => +648
cap9adk => +708

based on the pm9623 and pm9261 precedently patch it will be less or the same

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

[U-Boot] [PATCH V3] mpc5200: reduce delays in i2c

[Jon Smirl]

Make the i2c delays smaller. The measured delay is 55us at
100Khz. Set the delay to 15us which should work for 400Khz.
100Khz will loop four times and get a 60us delay. Try four
times at a 15us delay and then revert to the previous behavior
of 1ms delays.
---
 cpu/mpc5xxx/i2c.c |9 +
 1 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/cpu/mpc5xxx/i2c.c b/cpu/mpc5xxx/i2c.c
index e2506d8..dba9071 100644
--- a/cpu/mpc5xxx/i2c.c
+++ b/cpu/mpc5xxx/i2c.c
@@ -39,6 +39,7 @@ DECLARE_GLOBAL_DATA_PTR;
 #endif
 
 #define I2C_TIMEOUT100
+#define I2C_TIMEOUT_QUICK 4
 #define I2C_RETRIES3
 
 struct mpc5xxx_i2c_tap {
@@ -80,7 +81,7 @@ static void mpc_reg_out(volatile u32 *reg, int val, int mask)
 static int wait_for_bb(void)
 {
struct mpc5xxx_i2c *regs= (struct mpc5xxx_i2c *)I2C_BASE;
-   int timeout = I2C_TIMEOUT;
+   int timeout = I2C_TIMEOUT + I2C_TIMEOUT_QUICK;
int status;
 
status = mpc_reg_in(®s->msr);
@@ -94,7 +95,7 @@ static int wait_for_bb(void)
mpc_reg_out(®s->mcr, 0, 0);
mpc_reg_out(®s->mcr, I2C_EN, 0);
 #endif
-   udelay(1000);
+   timeout > I2C_TIMEOUT ? udelay(15) : udelay(1000);
status = mpc_reg_in(®s->msr);
}
 
@@ -104,12 +105,12 @@ static int wait_for_bb(void)
 static int wait_for_pin(int *status)
 {
struct mpc5xxx_i2c *regs= (struct mpc5xxx_i2c *)I2C_BASE;
-   int timeout = I2C_TIMEOUT;
+   int timeout = I2C_TIMEOUT + I2C_TIMEOUT_QUICK;
 
*status = mpc_reg_in(®s->msr);
 
while (timeout-- && !(*status & I2C_IF)) {
-   udelay(1000);
+   timeout > I2C_TIMEOUT ? udelay(15) : udelay(1000);
*status = mpc_reg_in(®s->msr);
}
 

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

Re: [U-Boot] RAM Probing for ads5121rev4

[Michele De Candia (VT)]

Wolfgang Denk wrote:
> Dear "Michele De Candia (VT)",
>
> In message <49d23e30.4060...@valueteam.com> you wrote:
>   
>> The issue concerns the possibility to identify DDR chips type (e.g. by 
>> VendorId) before initialize them.
>> It doesn't concern configuration parameters (size, bus frequency, ecc..).
>> There isn't a DDR command to read this information, do you think it is 
>> possible to solve this problem in other ways?
>> 
>
> Yes, of course it is possible to solve this problem otherwise.
>
> In a sane hardware design you can read  this  information  from  some
> board configuration register or so; for example, on the ADS5121 there
> could  be  such  a  register implemented in the CPLD. But alas, there
> ain't none.
>
> Martha Marx posted pretty good patches (identifyung  board  revisions
> based  on  the MAC address) more than a month ago, but then failed to
> address the last review comments.
>
> If you want to get that fixed, please pick up her patches  (or  nudge
> her to do it for you).
>   
Hi Mr. Denk,
thanks for the suggestions, we've already picked up Martha Marx patches 
and they work fine on ADS5121.
We want to avoid DDR identification by board revisions because we don't 
know which DDR will be used in the future and it isn't a flexible way to 
do that.
After all, if it is the only way, we'll use this one.

Thanks,
Michele De Candia
> Best regards,
>
> Wolfgang Denk
>
>   


-- 

*Michele Jr **De Candia*



Value Team

Via Vespri Siciliani, 9
20146 Milano
Tel. +39 0248985722
michele.decan...@valueteam.com 
http://www.valueteam.com

 

CONFIDENTIALITY NOTICE -This message and its attachments (if any) may 
contain confidential, proprietary or legally privileged information and 
is intended only for the use of the addressee named above. No 
confidentiality or privilege is waived or lost by any mistransmission. 
If you are not the intended recipient of this message you are hereby 
notified that you must not use, disseminate, copy it in any form or take 
any action in reliance on it. If you have received this message in error 
please delete it and any copies of it and kindly inform the sender of 
this e-mail by replying or go to www.valueteam.com 
 on 'contacts'.

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

Re: [U-Boot] core ticks/timer code

[Scott Wood]

On Tue, Mar 31, 2009 at 05:49:52PM +0200, Wolfgang Denk wrote:
> Please check for example the PowerPC code, then.
> 
> Ther ethe timer implementation relies heavily on interrupts and is not
> available in early stages, for example in NAND booting systems with
> tight memory restrictions.

Is there any particular reason not to change the powerpc get_timer
implementation to use the timebase (scaled down to ms)?

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

Re: [U-Boot] core ticks/timer code

[Wolfgang Denk]

Dear Scott Wood,

In message <20090331212514.ga19...@ld0162-tx32.am.freescale.net> you wrote:
> On Tue, Mar 31, 2009 at 05:48:01PM +0200, Wolfgang Denk wrote:
> > We still need some hint that the timer works in millisecond
> > resolution, though - no matter what you call it.
> 
> How about just calling it HZ (or something more verbose like TIMER_HZ,
> but the former makes it easier to share code with Linux) and declaring it
> in a non-board header?

It's OK with me. Other opinions?

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
IMPORTANT NOTICE TO PURCHASERS: The Entire Physical Universe,  Inclu-
ding  This Product, May One Day Collapse Back into an Infinitesimally
Small Space. Should  Another  Universe  Subsequently  Re-emerge,  the
Existence of This Product in That Universe Cannot Be Guaranteed.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1] at91sam9/at91cap: improve clock framework

[Wolfgang Denk]

Dear Jean-Christophe PLAGNIOL-VILLARD,

In message <20090331210130.gj24...@game.jcrosoft.org> you wrote:
> On 22:59 Tue 31 Mar , Wolfgang Denk wrote:
> > Dear Jean-Christophe PLAGNIOL-VILLARD,
> > 
> > In message <1238486824-19007-1-git-send-email-plagn...@jcrosoft.com> you 
> > wrote:
> > > calculate dynamically the clock rate and pllb setting for usb
> > > 
> > > Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD 
> > > ---
> > >  board/atmel/at91cap9adk/at91cap9adk.c |3 +-
> > >  board/atmel/at91sam9261ek/at91sam9261ek.c |3 +-
> > >  board/atmel/at91sam9263ek/at91sam9263ek.c |3 +-
> > >  board/atmel/at91sam9rlek/at91sam9rlek.c   |3 +-
> > >  cpu/arm926ejs/at91/Makefile   |2 +
> > >  cpu/arm926ejs/at91/clock.c|  196 
> > > +
> > >  cpu/arm926ejs/at91/cpu.c  |   14 ++
> > >  drivers/spi/atmel_dataflash_spi.c |7 +-
> > >  drivers/usb/atmel_usb.c   |3 +-
> > >  include/asm-arm/arch-at91/clk.h   |   17 ++-
> > >  include/asm-arm/arch-at91/hardware.h  |3 +
> > >  include/asm-arm/u-boot-arm.h  |3 +
> > >  include/configs/afeb9260.h|6 +-
> > >  include/configs/at91cap9adk.h |7 +-
> > >  include/configs/at91sam9260ek.h   |9 +--
> > >  include/configs/at91sam9261ek.h   |6 +-
> > >  include/configs/at91sam9263ek.h   |7 +-
> > >  include/configs/at91sam9rlek.h|6 +-
> > >  lib_arm/board.c   |3 +
> > >  19 files changed, 254 insertions(+), 47 deletions(-)
> > >  create mode 100644 cpu/arm926ejs/at91/clock.c
> > >  create mode 100644 cpu/arm926ejs/at91/cpu.c
> > 
> > What is the impact of this patch on the memory footprint of the
> > system?
> 708 bytes on the 9263ek

708 bytes more or less? And how much on the others processors?

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
Always leave room to add an explanation if it doesn't work out.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] core ticks/timer code

[Scott Wood]

On Tue, Mar 31, 2009 at 05:48:01PM +0200, Wolfgang Denk wrote:
> We still need some hint that the timer works in millisecond
> resolution, though - no matter what you call it.

How about just calling it HZ (or something more verbose like TIMER_HZ,
but the former makes it easier to share code with Linux) and declaring it
in a non-board header?

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

Re: [U-Boot] [PATCH] mpc83xx: Set guarded bit on BAT that covers the end of the address space

[Wolfgang Denk]

Dear Scott Wood,

In message <49d28575.1040...@freescale.com> you wrote:
>
> > Umm... what does that mean: "continuation of commit a5d7049a4"?
> > 
> > If these commits belong together logically, you must not split them
> > apart.
> 
> There's no bisectability problem; it's just similar bugs being fixed on 
> other boards.

why not fix them in a single commit, then?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The most difficult thing in the world is to know how to  do  a  thing
and to watch someone else doing it wrong, without commenting.
-- T.H. White
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 10/13] at91: move usb driver to drivers/usb

[Remy Bohmer]

Hello Jean-Christophe,

> it's the at91 usb drivers and we need to have it in the driver/usb
> and it's not at91/arm926 specific but it's also shared with the at91rm9200
> so I move to drivers usb

Then I can agree that the arm926 tree is not the correct place; but
that does not automatically make the generic driver code the right
place either...

Kind Regards,

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

Re: [U-Boot] [PATCH 1/1] at91sam9/at91cap: improve clock framework

[Jean-Christophe PLAGNIOL-VILLARD]

On 22:59 Tue 31 Mar , Wolfgang Denk wrote:
> Dear Jean-Christophe PLAGNIOL-VILLARD,
> 
> In message <1238486824-19007-1-git-send-email-plagn...@jcrosoft.com> you 
> wrote:
> > calculate dynamically the clock rate and pllb setting for usb
> > 
> > Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD 
> > ---
> >  board/atmel/at91cap9adk/at91cap9adk.c |3 +-
> >  board/atmel/at91sam9261ek/at91sam9261ek.c |3 +-
> >  board/atmel/at91sam9263ek/at91sam9263ek.c |3 +-
> >  board/atmel/at91sam9rlek/at91sam9rlek.c   |3 +-
> >  cpu/arm926ejs/at91/Makefile   |2 +
> >  cpu/arm926ejs/at91/clock.c|  196 
> > +
> >  cpu/arm926ejs/at91/cpu.c  |   14 ++
> >  drivers/spi/atmel_dataflash_spi.c |7 +-
> >  drivers/usb/atmel_usb.c   |3 +-
> >  include/asm-arm/arch-at91/clk.h   |   17 ++-
> >  include/asm-arm/arch-at91/hardware.h  |3 +
> >  include/asm-arm/u-boot-arm.h  |3 +
> >  include/configs/afeb9260.h|6 +-
> >  include/configs/at91cap9adk.h |7 +-
> >  include/configs/at91sam9260ek.h   |9 +--
> >  include/configs/at91sam9261ek.h   |6 +-
> >  include/configs/at91sam9263ek.h   |7 +-
> >  include/configs/at91sam9rlek.h|6 +-
> >  lib_arm/board.c   |3 +
> >  19 files changed, 254 insertions(+), 47 deletions(-)
> >  create mode 100644 cpu/arm926ejs/at91/clock.c
> >  create mode 100644 cpu/arm926ejs/at91/cpu.c
> 
> What is the impact of this patch on the memory footprint of the
> system?
708 bytes on the 9263ek

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

Re: [U-Boot] [PATCH V2] mpc5200: reduce delays in i2c

[Jon Smirl]

On Tue, Mar 31, 2009 at 4:54 PM, Wolfgang Denk  wrote:
> Dear Jon Smirl,
>
> In message <20090331010330.20946.41742.st...@localhost> you wrote:
>> Make the i2c delays smaller. The measured delay is 55us at
>> 100Khz. Set the delay to 15us which should work for 400Khz.
>> 100Khz will loop four times and get a 60us delay. Previous
>> total delay was 100,000us new total delay is 150,000us before
>> timeout.
>
> I think you did not even bother to read my comments to your previous
> patch (foar from trying to understand and react on them).
>
> Sorry, NAK.  Please at least answer the questions you've been asked.

You said:
"I agree that the change itself looks harmless,  and  I'm  willing  to
accept  it,  but  at  least make sure not to reduce the total timeout
values - that would require re-testing on some boards."

I made the total time out bigger just to be extra sure, but I could
lower it back to 100ms.

If this isn't ok. Just drop the patch and I'll keep it in my private tree.


>
> 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 dislike companies that have a we-are-the-high-priests-of-hardware-
> so-you'll-like-what-we-give-you attitude. I like commodity markets in
> which iron-and-silicon hawkers know that they exist to  provide  fast
> toys for software types like me to play with..."    - Eric S. Raymond
>



-- 
Jon Smirl
jonsm...@gmail.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 09/13] s3c64xx: move usb driver to drivers/usb

[Wolfgang Denk]

Dear Remy Bohmer,

In message <3efb10970903311126u1b97c3dbi5193e85473351...@mail.gmail.com> you 
wrote:
> 
> Why do you want to move all these processor specific code into generic
> driver code?

Indeed. That makes no sense to me.

Please stop here, Jean-Christophe.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"There is nothing new under the sun, but there are lots of old things
we don't know yet."  - Ambrose Bierce
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] RAM Probing for ads5121rev4

[Wolfgang Denk]

Dear "Michele De Candia (VT)",

In message <49d23e30.4060...@valueteam.com> you wrote:
>
> The issue concerns the possibility to identify DDR chips type (e.g. by 
> VendorId) before initialize them.
> It doesn't concern configuration parameters (size, bus frequency, ecc..).
> There isn't a DDR command to read this information, do you think it is 
> possible to solve this problem in other ways?

Yes, of course it is possible to solve this problem otherwise.

In a sane hardware design you can read  this  information  from  some
board configuration register or so; for example, on the ADS5121 there
could  be  such  a  register implemented in the CPLD. But alas, there
ain't none.

Martha Marx posted pretty good patches (identifyung  board  revisions
based  on  the MAC address) more than a month ago, but then failed to
address the last review comments.

If you want to get that fixed, please pick up her patches  (or  nudge
her to do it for you).

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
"If you own a machine, you are in turn owned by it,  and  spend  your
time serving it..."- Marion Zimmer Bradley, _The Forbidden Tower_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] mpc83xx: Set guarded bit on BAT that covers the end of the address space

[Scott Wood]

Wolfgang Denk wrote:
> Dear Kim Phillips,
> 
> In message <20090330175628.602dae2f.kim.phill...@freescale.com> you wrote:
>> continuation of commit a5d7049a4 to remaining mpc83xx boards that suffer
>> from the same problem.
>>
>> Signed-off-by: Kim Phillips 
>> CC: Scott Wood 
> 
> Umm... what does that mean: "continuation of commit a5d7049a4"?
> 
> If these commits belong together logically, you must not split them
> apart.

There's no bisectability problem; it's just similar bugs being fixed on 
other boards.

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

Re: [U-Boot] [PATCH 1/1] at91sam9/at91cap: improve clock framework

[Wolfgang Denk]

Dear Jean-Christophe PLAGNIOL-VILLARD,

In message <1238486824-19007-1-git-send-email-plagn...@jcrosoft.com> you wrote:
> calculate dynamically the clock rate and pllb setting for usb
> 
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD 
> ---
>  board/atmel/at91cap9adk/at91cap9adk.c |3 +-
>  board/atmel/at91sam9261ek/at91sam9261ek.c |3 +-
>  board/atmel/at91sam9263ek/at91sam9263ek.c |3 +-
>  board/atmel/at91sam9rlek/at91sam9rlek.c   |3 +-
>  cpu/arm926ejs/at91/Makefile   |2 +
>  cpu/arm926ejs/at91/clock.c|  196 
> +
>  cpu/arm926ejs/at91/cpu.c  |   14 ++
>  drivers/spi/atmel_dataflash_spi.c |7 +-
>  drivers/usb/atmel_usb.c   |3 +-
>  include/asm-arm/arch-at91/clk.h   |   17 ++-
>  include/asm-arm/arch-at91/hardware.h  |3 +
>  include/asm-arm/u-boot-arm.h  |3 +
>  include/configs/afeb9260.h|6 +-
>  include/configs/at91cap9adk.h |7 +-
>  include/configs/at91sam9260ek.h   |9 +--
>  include/configs/at91sam9261ek.h   |6 +-
>  include/configs/at91sam9263ek.h   |7 +-
>  include/configs/at91sam9rlek.h|6 +-
>  lib_arm/board.c   |3 +
>  19 files changed, 254 insertions(+), 47 deletions(-)
>  create mode 100644 cpu/arm926ejs/at91/clock.c
>  create mode 100644 cpu/arm926ejs/at91/cpu.c

What is the impact of this patch on the memory footprint 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
The perversity of nature is nowhere better demonstrated by  the  fact
that,  when  exposed to the same atmosphere, bread becomes hard while
crackers become soft.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Maillist issue of u-boot@lists.denx.de

[Wolfgang Denk]

Dear "Liu Dave-R63238",

In message 
 you wrote:
> 
> I often miss some mails from u-boot@lists.denx.de in these days,
> For example, we didn't receive the 8569 support patch from lists,
> and didn't receive the mail from Kim
> http://lists.denx.de/pipermail/u-boot/2009-March/049890.html
> http://lists.denx.de/pipermail/u-boot/2009-March/049891.html
> 
> What is the matter? does my mail system have some problem?

It seems they have been sent by the server.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
A little suffering is good for the soul.
-- Kirk, "The Corbomite Maneuver", stardate 1514.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2] mpc5200: reduce delays in i2c

[Wolfgang Denk]

Dear Jon Smirl,

In message <20090331010330.20946.41742.st...@localhost> you wrote:
> Make the i2c delays smaller. The measured delay is 55us at
> 100Khz. Set the delay to 15us which should work for 400Khz.
> 100Khz will loop four times and get a 60us delay. Previous
> total delay was 100,000us new total delay is 150,000us before
> timeout.

I think you did not even bother to read my comments to your previous
patch (foar from trying to understand and react on them).

Sorry, NAK.  Please at least answer the questions you've been asked.

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 dislike companies that have a we-are-the-high-priests-of-hardware-
so-you'll-like-what-we-give-you attitude. I like commodity markets in
which iron-and-silicon hawkers know that they exist to  provide  fast
toys for software types like me to play with..."- Eric S. Raymond
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] mpc83xx: Set guarded bit on BAT that covers the end of the address space

[Wolfgang Denk]

Dear Kim Phillips,

In message <20090330175628.602dae2f.kim.phill...@freescale.com> you wrote:
> continuation of commit a5d7049a4 to remaining mpc83xx boards that suffer
> from the same problem.
> 
> Signed-off-by: Kim Phillips 
> CC: Scott Wood 

Umm... what does that mean: "continuation of commit a5d7049a4"?

If these commits belong together logically, you must not split them
apart.

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
You can do this in a number of ways. IBM chose to do all of them.
Why do you find that funny?-- D. Taylor, Computer Science 350
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] OMAP3: Fix timer handling to 1ms and CONFIG_SYS_HZ to 1000.

[Jean-Christophe PLAGNIOL-VILLARD]

On 11:19 Tue 17 Mar , Dirk Behme wrote:
> Fix OMAP3 timer handling to 1ms tick and CONFIG_SYS_HZ to 1000.
> Clean up macros and comments.
> 
> Signed-off-by: Dirk Behme 
> Signed-off-by: Manikandan Pillai 
> ---
> 
> Changes from Mani's original patch which is replaced by this [1]:
> 
> * Don't remove overflow handling in get_timer_masked()
> * Update omap3_zoom1.h, too.
> * Clean up timer related comments and macros in config files
> * Don't touch reset_timer_masked()
> * Switch divider clock divider from 256 to 8 to be able to get 1000Hz
> * Remove unused udelay_masked()
> * Minor clean up of get_tbclk()
> 
> [1] http://lists.denx.de/pipermail/u-boot/2009-March/049012.html
> 
> This patch is against U-Boot mainline commit
> 'b3dd629e78870ba2dc9f8032978721c0fa02a856'
> 'Prepare 2009.03-rc2'
> 
>  cpu/arm_cortexa8/omap3/interrupts.c |   50 
> +++-
>  include/configs/omap3_beagle.h  |   11 +++
>  include/configs/omap3_evm.h |   15 +-
>  include/configs/omap3_overo.h   |   11 +++
>  include/configs/omap3_pandora.h |   11 +++
>  include/configs/omap3_zoom1.h   |   11 +++
>  6 files changed, 43 insertions(+), 66 deletions(-)
> 
> Index: u-boot-main/cpu/arm_cortexa8/omap3/interrupts.c
> ===
> --- u-boot-main.orig/cpu/arm_cortexa8/omap3/interrupts.c
> +++ u-boot-main/cpu/arm_cortexa8/omap3/interrupts.c
> @@ -169,7 +169,16 @@ static ulong timestamp;
>  static ulong lastinc;
>  static gptimer_t *timer_base = (gptimer_t *)CONFIG_SYS_TIMERBASE;
>  
> -/* nothing really to do with interrupts, just starts up a counter. */
> +/*
> + * Nothing really to do with interrupts, just starts up a counter.
> + * We run the counter with 13MHz, divided by 8, resulting in timer
> + * frequency of 1.625MHz. With 32bit counter register, counter
> + * overflows in ~44min
> + */
It will be better to use the 12Mhz source clock and set the divider to 4
so you will a a timer frequency to 3MHz and a perfect Match clock
it will overflow ealier but the timer will be exact

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

Re: [U-Boot] Problems with ext2ls & SD

[Wolfgang Denk]

Dear DVM,

In message <22756563.p...@talk.nabble.com> you wrote:
> 
> Further debugging reveals UBoot uses a fixed length for inodes (128 bye). The
> inodes on my 2GB SD card are 256 bytes There was a patch that fizzled out
> back in January looking at this
...
> This seems to improve matters for me BUT I dont have any other hardware to
> test on and I am no ext2fs guru. Does anyone else have any ideas?

If you read my reply to that e-mail you read what I'm replying to you:

|Hm I tried the current code without your patch but I could not
|find any error case.
|
|But with your patch applied, I got this:
|
|=> ext2ls ide 0:4 bin
| ** ext2fs_devread() read outside partition sector 536870912
|Failed to mount ext2 filesystem...
|** Bad ext2 partition or disk - ide 0:4 **
|
|
|I tested this on a PowerPC system (big endian). Any chance there might
|be some endianess issues with your patch?

Please provide at least a test image!

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
It's not an optical illusion, it just looks like one.   -- Phil White
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] core ticks/timer code

[Wolfgang Denk]

Dear Dirk Behme,

In message <49cdccc1.5050...@googlemail.com> you wrote:
>
> >  - get_ticks - return some notion of "cpu ticks"
> 
> Yes. Returns the number of cpu ticks since power up. I.e. with 1000 
> ticks per second (CONFIG_SYS_HZ) the number of elapsed ms since power up.

Hey. What a chance. We have a wiki. Add that information.

> Yes. Some implementations just return CONFIG_SYS_HZ which is supposed 
> to be 1000.

get_ticks() makes no sense to me.

> >  - timer_init - setup a core timer
> 
> Some implementations do this in interrupt_init(), too.

Let them do it, if they need it, and if they document why they need
it.

> >  - get_timer(x) - not really sure what this is supposed to represent, or 
> > how 
> > "x" is used

See ppc code.

> >  - CONFIG_SYS_HZ - no idea how this relates to ticks/timer in U-Boot as in 
> > the 
> > Linux world, this is the core timer (scheduler) frequency (how many times 
> > to 
> > execute per second)
> 
> CONFIG_SYS_HZ is supposed to be 1000
> 
> Does this make sense?

Yes, it makes sense that CONFIG_SYS_HZ is supposed to be 1000.

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
What is research but a blind date with knowledge?  -- Will Harvey
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] U-boot NAND boot on IMX31 3stack(ARM)

[Scott Wood]

alfred steele wrote:
> I am actually confused with the values for chip size which should be
> the total chip size in MB  w.r.t  nand_flash_dev structure and
> "pagesize" as pagesize seems to be extended bytes alone in the
> datasheet which i am unable to figure of as of now. The pagesize seems
> to be different from the exact "pagesize" as in the data sheet for the
> other parts in include/linux/mtd/nand_ids.h. Do you know what to look
> for in the data sheet .

The page size that the struct wants is the main data area only, not 
counting OOB.  But as Magnus pointed out, you don't need to worry about 
any of this.  It should Just Work(tm).

What does need to be supplied is a controller driver.  There have been 
some patches in the past, but IIRC some more work was needed to get it 
mergeable.

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

Re: [U-Boot] core ticks/timer code

[Wolfgang Denk]

Dear Mike Frysinger,

In message <200903272130.26825.vap...@gentoo.org> you wrote:
>
> unfortunately, there doesnt seem to be any docs on what exactly these 
> functions do so it's hard for me to verify/change any of it.

If in doubt, look it up in the PowerPC implementation. That's the
reference for what a half-way sane world could look like.

> my understanding is that:
>  - get_ticks - return some notion of "cpu ticks"
>  - get_tbclk - return number of "cpu ticks" that elapse in one second
>  - timer_init - setup a core timer
>  - get_timer(x) - not really sure what this is supposed to represent, or ho> 
> w 
> "x" is used
>  - reset_timer - reset core timer to 0
>  - CONFIG_SYS_HZ - no idea how this relates to ticks/timer in U-Boot as in 
> the 
> Linux world, this is the core timer (scheduler) frequency (how many times to 
> execute per second)

It's the number of ticks per second, i. e. 1000.

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
Be kind to unkind people - they need it the most.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 12/13] at91: add hardware i2c drivers

[Wolfgang Denk]

Dear Heiko Schocher,

In message <49d05e5f.6060...@denx.de> you wrote:
> 
...
> Independent from your patch, I think we need here a common
> rule. Either we name in future this define "CONFIG_I2C_XXX"
> or "CONFIG_XXX_I2C. I vote for using "CONFIG_I2C_XXX"

Me too.

...
> > +#ifdef CONFIG_HARD_I2C
> 
> Why not "#if defined(CONFIG_I2C_ATMEL)" as in the Makefile?

Excellent question.

> > +#if 0 /* EEPROM code already sets this correctly */
> > +   chip |= (addr >> 8) & 0xff;
> > +#endif
> >   
> 
> please remove dead code.

Agreed.

> > +#if 0 /* EEPROM code already sets this correctly */
> > +   chip |= (addr >> 8) & 0xff;
> > +#endif
> 
> here too, please remove dead code.

Ditto.


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
Anyone can count the seeds in an apple.
No one can count the apples in a seed.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 10/13] at91: move usb driver to drivers/usb

[Wolfgang Denk]

Dear Jean-Christophe PLAGNIOL-VILLARD,

In message <20090331192117.gf24...@game.jcrosoft.org> you wrote:
>
> > >  drivers/usb/Makefile                        >        |    1 +
> > >  .../at91/usb.c => drivers/usb/atmel_usb.c          |  >   0
> > >  rename cpu/arm926ejs/at91/usb.c => drivers/usb/atmel_usb.c (100%)
> > >
> > Same here, this is architecture specific code, why move it to generic cod> 
> > e?
> it's the at91 usb drivers and we need to have it in the driver/usb

Why do we need to have it in the driver/usb ?

Please explain in detail.

> and it's not at91/arm926 specific but it's also shared with the at91rm9200
>
> so I move to drivers usb
>
> please note that the RM9200 will be move to the at91 API next release

So. Will it. Really? Who discussed this, and where, and when?
Please explain in detail.


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
Weekends were made for programming. - Karl Lehenbauer
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 10/13] at91: move usb driver to drivers/usb

[Wolfgang Denk]

Dear Remy Bohmer,

In message <3efb10970903311128t2b9ac2dn4d4b1ee9022a8...@mail.gmail.com> you 
wrote:
>
> >  drivers/usb/Makefile                         >       |    1 +
> >  .../at91/usb.c => drivers/usb/atmel_usb.c          |   >  0
> >  rename cpu/arm926ejs/at91/usb.c => drivers/usb/atmel_usb.c (100%)
>
> Same here, this is architecture specific code, why move it to generic code?

I agree with Remy here. The modification makes no sense to me.

Please don't.

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
"One day," said a dull voice from down below, "I'm going to  be  back
in  form again and you're going to be very sorry you said that. For a
very long time. I might even go so far as to make even more Time just
for you to be sorry in."  - Terry Pratchett, _Small Gods_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 13/13] at91sam9263ek: active hush and auto compelete support

[Wolfgang Denk]

Dear Jean-Christophe PLAGNIOL-VILLARD,

In message <1238193026-12564-13-git-send-email-plagn...@jcrosoft.com> you wrote:
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD 
> ---
>  include/configs/at91sam9263ek.h |3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/include/configs/at91sam9263ek.h b/include/configs/at91sam9263ek.h
> index dd0d552..fc87241 100644
> --- a/include/configs/at91sam9263ek.h
> +++ b/include/configs/at91sam9263ek.h
> @@ -204,6 +204,9 @@
>  #define CONFIG_SYS_PBSIZE(CONFIG_SYS_CBSIZE + 
> sizeof(CONFIG_SYS_PROMPT) + 16)
>  #define CONFIG_SYS_LONGHELP  1
>  #define CONFIG_CMDLINE_EDITING   1
> +#define CONFIG_AUTO_COMPLETE
> +#define CONFIG_SYS_HUSH_PARSER
> +#define CONFIG_SYS_PROMPT_HUSH_PS2   "> "

You are not the maintainer of this board.

You are not supposed to make any such modifications without permission
of the board mainteiner.

Stelian, please comment.

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
When properly administered, vacations do not  diminish  productivity:
for every week you're away and get nothing done, there's another when
your boss is away and you get twice as much done.  -- Daniel B. Luten
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] U-boot NAND boot on IMX31 3stack(ARM)

[Magnus Lilja]

2009/3/31 alfred steele :
> Thanks Again,
> I am actually confused with the values for chip size which should be
> the total chip size in MB  w.r.t  nand_flash_dev structure and
> "pagesize" as pagesize seems to be extended bytes alone in the
> datasheet which i am unable to figure of as of now. The pagesize seems
> to be different from the exact "pagesize" as in the data sheet for the
> other parts in include/linux/mtd/nand_ids.h. Do you know what to look
> for in the data sheet .

The Samsung K9F1G08R0A datasheet states that the device code is 0xA1.
The nand_ids.c file in U-boot has this code listed as "128MiB 1.8V
8-bit" large page NAND and therefore the device is likely to be
supported by U-boot.



And btw, please don't top post.


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

Re: [U-Boot] [PATCH 09/13] s3c64xx: move usb driver to drivers/usb

[Jean-Christophe PLAGNIOL-VILLARD]

On 20:26 Tue 31 Mar , Remy Bohmer wrote:
> Hello Jean-Christophe,
> 
> 2009/3/27 Jean-Christophe PLAGNIOL-VILLARD :
> > add CONFIG_USB_S3C64XX to activate the driver
> >
> > Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD 
> > ---
> >  cpu/arm1176/s3c64xx/Makefile                       |    1 -
> >  drivers/usb/Makefile                               |    1 +
> >  .../s3c64xx/usb.c => drivers/usb/s3c64xx_usb.c     |    0
> >  include/configs/smdk6400.h                         |    1 +
> >  4 files changed, 2 insertions(+), 1 deletions(-)
> >  rename cpu/arm1176/s3c64xx/usb.c => drivers/usb/s3c64xx_usb.c (100%)
> 
> Why do you want to move all these processor specific code into generic
> driver code?
IMHO it's a usb drivers and it's place is not in the cpu but in the drivers/usb/
even if it's just the USB init

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

Re: [U-Boot] [PATCH 10/13] at91: move usb driver to drivers/usb

[Jean-Christophe PLAGNIOL-VILLARD]

On 20:28 Tue 31 Mar , Remy Bohmer wrote:
> Hello,
> 
> >  drivers/usb/Makefile                               |    1 +
> >  .../at91/usb.c => drivers/usb/atmel_usb.c          |    0
> >  rename cpu/arm926ejs/at91/usb.c => drivers/usb/atmel_usb.c (100%)
> 
> Same here, this is architecture specific code, why move it to generic code?
it's the at91 usb drivers and we need to have it in the driver/usb
and it's not at91/arm926 specific but it's also shared with the at91rm9200

so I move to drivers usb

please note that the RM9200 will be move to the at91 API next release

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

Re: [U-Boot] U-boot NAND boot on IMX31 3stack(ARM)

[alfred steele]

Thanks Again,
I am actually confused with the values for chip size which should be
the total chip size in MB  w.r.t  nand_flash_dev structure and
"pagesize" as pagesize seems to be extended bytes alone in the
datasheet which i am unable to figure of as of now. The pagesize seems
to be different from the exact "pagesize" as in the data sheet for the
other parts in include/linux/mtd/nand_ids.h. Do you know what to look
for in the data sheet .



On Tue, Mar 31, 2009 at 2:10 PM, alfred steele  wrote:
> Hi Scott,
>
> Thanks!
> The only requirement i have currently is to be able to populate the
> device table with the  "Samsung K9F1G08R0A"  because it does not
> appear in the existing list. This would help the NFC read the part id
> and the other  NAND attributes correctly on the target.
>
> Thanks & Regards.
>
>
> On Tue, Mar 31, 2009 at 12:20 PM, Scott Wood  wrote:
>> alfred steele wrote:
>>>
>>> Hi Scott:
>>> Thanks!
>>>
>>>
> I am also wondering if there is a include file which builds up a table
> of working NAND devices and thier attributes which tells the U-boot on
> the parameters about a particular NAND device on the board like
> Block_size , page_size, device size, pages per block, device id etc.
> Or This information needs to be kind of hardcoded every time.

 drivers/mtd/nand/nand_ids.c
>>>
>>> I have three files which probably make sense to include the new flash
>>> part.
>>> drivers/mtd/nand/nand_ids.c
>>
>> This is the one.  However, an individual NAND driver shouldn't have to care;
>> it will be taken care of by the NAND subsystem.
>>
>>> ./common/cmd_doc.c
>>> ./include/linux/mtd/nand_ids.h:
>>
>> Ignore these.  They are legacy code that will soon be removed.
>>
>>> At this point, i do not understand the purpose of each and especially
>>> how would the structure flash_id be populated from our data sheet for
>>> the flash part we use
>>>  "Samsung K9F1G08R0A".
>>
>> Most likely it is already in the table.
>>
>>> I basically do not understand all the elements of the array
>>> nand_flash_dev nand_flash_ids[] to be able to populate it correctly.
>>
>> Which field in particular are you unsure of?  They are described in the
>> definition of nand_flash_dev in include/linux/mtd/nand.h.
>>
>> Is there any reason why your NAND controller driver needs to care about any
>> of this, as opposed to just hooking up to the NAND subsystem?
>>
>> -Scott
>>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] U-boot NAND boot on IMX31 3stack(ARM)

[Scott Wood]

alfred steele wrote:
> Thanks!
> The only requirement i have currently is to be able to populate the
> device table with the  "Samsung K9F1G08R0A"  because it does not
> appear in the existing list. This would help the NFC read the part id
> and the other  NAND attributes correctly on the target.

The specific chip+manfuacturer combination not need to appear in the 
list, only the standardized device ID which indicates the geometry.

What is the device ID of this chip, and what are the page size, block 
size, and total flash size?

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

Re: [U-Boot] U-boot NAND boot on IMX31 3stack(ARM)

[alfred steele]

Hi Scott,

Thanks!
The only requirement i have currently is to be able to populate the
device table with the  "Samsung K9F1G08R0A"  because it does not
appear in the existing list. This would help the NFC read the part id
and the other  NAND attributes correctly on the target.

Thanks & Regards.


On Tue, Mar 31, 2009 at 12:20 PM, Scott Wood  wrote:
> alfred steele wrote:
>>
>> Hi Scott:
>> Thanks!
>>
>>
 I am also wondering if there is a include file which builds up a table
 of working NAND devices and thier attributes which tells the U-boot on
 the parameters about a particular NAND device on the board like
 Block_size , page_size, device size, pages per block, device id etc.
 Or This information needs to be kind of hardcoded every time.
>>>
>>> drivers/mtd/nand/nand_ids.c
>>
>> I have three files which probably make sense to include the new flash
>> part.
>> drivers/mtd/nand/nand_ids.c
>
> This is the one.  However, an individual NAND driver shouldn't have to care;
> it will be taken care of by the NAND subsystem.
>
>> ./common/cmd_doc.c
>> ./include/linux/mtd/nand_ids.h:
>
> Ignore these.  They are legacy code that will soon be removed.
>
>> At this point, i do not understand the purpose of each and especially
>> how would the structure flash_id be populated from our data sheet for
>> the flash part we use
>>  "Samsung K9F1G08R0A".
>
> Most likely it is already in the table.
>
>> I basically do not understand all the elements of the array
>> nand_flash_dev nand_flash_ids[] to be able to populate it correctly.
>
> Which field in particular are you unsure of?  They are described in the
> definition of nand_flash_dev in include/linux/mtd/nand.h.
>
> Is there any reason why your NAND controller driver needs to care about any
> of this, as opposed to just hooking up to the NAND subsystem?
>
> -Scott
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] U-boot NAND boot on IMX31 3stack(ARM)

[alfred steele]

Hi Scott,

Thanks!
The only requirement i have currently is to be able to populate the
device table with the  "Samsung K9F1G08R0A"  because it does not
appear in the existing list. This would help the NFC read the part id
and the other  NAND attributes correctly on the target.

Thanks & Reagrds,
Munro.


On Tue, Mar 31, 2009 at 12:20 PM, Scott Wood  wrote:
> alfred steele wrote:
>>
>> Hi Scott:
>> Thanks!
>>
>>
 I am also wondering if there is a include file which builds up a table
 of working NAND devices and thier attributes which tells the U-boot on
 the parameters about a particular NAND device on the board like
 Block_size , page_size, device size, pages per block, device id etc.
 Or This information needs to be kind of hardcoded every time.
>>>
>>> drivers/mtd/nand/nand_ids.c
>>
>> I have three files which probably make sense to include the new flash
>> part.
>> drivers/mtd/nand/nand_ids.c
>
> This is the one.  However, an individual NAND driver shouldn't have to care;
> it will be taken care of by the NAND subsystem.
>
>> ./common/cmd_doc.c
>> ./include/linux/mtd/nand_ids.h:
>
> Ignore these.  They are legacy code that will soon be removed.
>
>> At this point, i do not understand the purpose of each and especially
>> how would the structure flash_id be populated from our data sheet for
>> the flash part we use
>>  "Samsung K9F1G08R0A".
>
> Most likely it is already in the table.
>
>> I basically do not understand all the elements of the array
>> nand_flash_dev nand_flash_ids[] to be able to populate it correctly.
>
> Which field in particular are you unsure of?  They are described in the
> definition of nand_flash_dev in include/linux/mtd/nand.h.
>
> Is there any reason why your NAND controller driver needs to care about any
> of this, as opposed to just hooking up to the NAND subsystem?
>
> -Scott
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 09/13] s3c64xx: move usb driver to drivers/usb

[Remy Bohmer]

Hello Jean-Christophe,

2009/3/27 Jean-Christophe PLAGNIOL-VILLARD :
> add CONFIG_USB_S3C64XX to activate the driver
>
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD 
> ---
>  cpu/arm1176/s3c64xx/Makefile                       |    1 -
>  drivers/usb/Makefile                               |    1 +
>  .../s3c64xx/usb.c => drivers/usb/s3c64xx_usb.c     |    0
>  include/configs/smdk6400.h                         |    1 +
>  4 files changed, 2 insertions(+), 1 deletions(-)
>  rename cpu/arm1176/s3c64xx/usb.c => drivers/usb/s3c64xx_usb.c (100%)

Why do you want to move all these processor specific code into generic
driver code?

Kind Regards,

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

Re: [U-Boot] [PATCH 10/13] at91: move usb driver to drivers/usb

[Remy Bohmer]

Hello,

>  drivers/usb/Makefile                               |    1 +
>  .../at91/usb.c => drivers/usb/atmel_usb.c          |    0
>  rename cpu/arm926ejs/at91/usb.c => drivers/usb/atmel_usb.c (100%)

Same here, this is architecture specific code, why move it to generic code?

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

[U-Boot] D.entists Database in America

[Lora T Connelly]

Essential for any marketer:

==> 164,981 Dentists 
==> 158,097 Addresses
==> 163,814 Contact Phone #
==> 77,663 Fax Nos.
==> 45,061 E-Mail Addresses

from today until this Friday this can be yours for just $296 (usually $592)

To inquire please write to maxinevalenzu...@statlists.com




By emailing dele...@statlists.com you will have your email taken off


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

[U-Boot] UBIFS - Reading superblock error

[DATACOM - Mallmann]

Hi,
I'm trying to use UBI and UBIFS over a nand device. I want to create a
mtd partition in u-boot (with ubi part command), save a ubifs image
(with mkfs.ubifs), mount and load it with ubifs commands. The commands
that I used are listed bellow:

(environment)
mtdids=nand0=nand
mtdparts=mtdparts=nand:64m(allstuff)
partition=nand0,0
mtddevnum=0
mtddevname=allstuff


=> ubi part nand allstuff
Creating 1 MTD partitions on "NAND 64MiB 3,3V 8-bit":
0x-0x0400 : "mtd=0"
UBI: attaching mtd0 to ubi0
UBI: physical eraseblock size:   16384 bytes (16 KiB)
UBI: logical eraseblock size:15872 bytes
UBI: smallest flash I/O unit:512
UBI: sub-page size:  256
UBI: VID header offset:  256 (aligned 256)
UBI: data offset:512
UBI: empty MTD device detected
UBI: create volume table (copy #1)
UBI: create volume table (copy #2)
UBI: attached mtd0 to ubi0
UBI: MTD device name:"mtd=0"
UBI: MTD device size:64 MiB
UBI: number of good PEBs:4096
UBI: number of bad PEBs: 0
UBI: max. allowed volumes:   92
UBI: wear-leveling threshold:4096
UBI: number of internal volumes: 1
UBI: number of user volumes: 0
UBI: available PEBs: 4052
UBI: total number of reserved PEBs: 44
UBI: number of PEBs reserved for bad PEB handling: 40
UBI: max/mean erase counter: 0/0


=> ubi create vol
Creating dynamic volume vol of size 64313344
=> ubi info l
UBI: volume information dump:
UBI: vol_id  0
UBI: reserved_pebs   4052
UBI: alignment   1
UBI: data_pad0
UBI: vol_type3
UBI: name_len3
UBI: usable_leb_size 15872
UBI: used_ebs4052
UBI: used_bytes  64313344
UBI: last_eb_bytes   15872
UBI: corrupted   0
UBI: upd_marker  0
UBI: namevol

UBI: volume information dump:
UBI: vol_id  2147479551
UBI: reserved_pebs   2
UBI: alignment   1
UBI: data_pad0
UBI: vol_type3
UBI: name_len13
UBI: usable_leb_size 15872
UBI: used_ebs2
UBI: used_bytes  31744
UBI: last_eb_bytes   2
UBI: corrupted   0
UBI: upd_marker  0
UBI: namelayout volume

tftp 100 image.ubifs vol ${filesize}
=> ubi write 100 vol ${filesize}
Volume "vol" found at volume id 0
=> ubifsmount vol
UBIFS error (pid 0): ubifs_check_node: bad node length 4100
UBIFS error (pid 0): ubifs_check_node: bad node at LEB 0:0
UBIFS error (pid 0): ubifs_read_node: expected node type 6
Error reading superblock on volume 'ubi:vol'!

image.ubifs was generated with the follow command:
mkfs.ubifs -r /ubifs -m 256 -c 2180 -e 16KiB -v -g 3 -o image.ubifs
(/ubifs contains a kernel+ramdisk cramfs image.)

My question is if the error was in image.ubifs creation or some u-boot
configuration. I can't find where u-boot takes this 4100 length from. By
the way, is a volume created in u-boot able to be used in linux kernel
in read-write mode?

Thanks in advance,

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

Re: [U-Boot] [PATCH 1/3] OMAP: reindent timer code

[Jean-Christophe PLAGNIOL-VILLARD]

On 00:40 Wed 25 Mar , Ladislav Michl wrote:
> Signed-off-by: Ladislav Michl 
> 
applied
Best Regards,
J.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] U-boot NAND boot on IMX31 3stack(ARM)

[Scott Wood]

alfred steele wrote:
> Hi Scott:
> Thanks!
> 
> 
>>> I am also wondering if there is a include file which builds up a table
>>> of working NAND devices and thier attributes which tells the U-boot on
>>> the parameters about a particular NAND device on the board like
>>> Block_size , page_size, device size, pages per block, device id etc.
>>> Or This information needs to be kind of hardcoded every time.
>> drivers/mtd/nand/nand_ids.c
> I have three files which probably make sense to include the new flash part.
> drivers/mtd/nand/nand_ids.c

This is the one.  However, an individual NAND driver shouldn't have to 
care; it will be taken care of by the NAND subsystem.

> ./common/cmd_doc.c
> ./include/linux/mtd/nand_ids.h:

Ignore these.  They are legacy code that will soon be removed.

> At this point, i do not understand the purpose of each and especially
> how would the structure flash_id be populated from our data sheet for
> the flash part we use
>  "Samsung K9F1G08R0A".

Most likely it is already in the table.

> I basically do not understand all the elements of the array
> nand_flash_dev nand_flash_ids[] to be able to populate it correctly.

Which field in particular are you unsure of?  They are described in the 
definition of nand_flash_dev in include/linux/mtd/nand.h.

Is there any reason why your NAND controller driver needs to care about 
any of this, as opposed to just hooking up to the NAND subsystem?

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

Re: [U-Boot] [PATCH 3/3] OMAP: use {read, write}l to access timer registers

[Jean-Christophe PLAGNIOL-VILLARD]

On 00:41 Wed 25 Mar , Ladislav Michl wrote:
> Signed-off-by: Ladislav Michl 
> 
applied
Best Regards,
J.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] U-boot NAND boot on IMX31 3stack(ARM)

[alfred steele]

Hi Scott:
Thanks!


>> I am also wondering if there is a include file which builds up a table
>> of working NAND devices and thier attributes which tells the U-boot on
>> the parameters about a particular NAND device on the board like
>> Block_size , page_size, device size, pages per block, device id etc.
>> Or This information needs to be kind of hardcoded every time.
>
> drivers/mtd/nand/nand_ids.c
I have three files which probably make sense to include the new flash part.
drivers/mtd/nand/nand_ids.c
./common/cmd_doc.c
./include/linux/mtd/nand_ids.h:

At this point, i do not understand the purpose of each and especially
how would the structure flash_id be populated from our data sheet for
the flash part we use
 "Samsung K9F1G08R0A".
I basically do not understand all the elements of the array
nand_flash_dev nand_flash_ids[] to be able to populate it correctly.
It would be great if you can throw some light on it or point me to
some relevant documentation.

Thanks in advance!

On Mon, Mar 30, 2009 at 8:21 PM, alfred steele  wrote:
> Hi Scott:
> Thanks!
>
>
>>> I am also wondering if there is a include file which builds up a table
>>> of working NAND devices and thier attributes which tells the U-boot on
>>> the parameters about a particular NAND device on the board like
>>> Block_size , page_size, device size, pages per block, device id etc.
>>> Or This information needs to be kind of hardcoded every time.
>>
>> drivers/mtd/nand/nand_ids.c
> I have three files which probably make sense to include the new flash part.
> drivers/mtd/nand/nand_ids.c
> ./common/cmd_doc.c
> ./include/linux/mtd/nand_ids.h:
>
> At this point, i do not understand the purpose of each and especially
> how would the structure flash_id be populated from our data sheet for
> the flash part we use
>  "Samsung K9F1G08R0A".
> I basically do not understand all the elements of the array
> nand_flash_dev nand_flash_ids[] to be able to populate it correctly.
> It would be great if you can throw some light on it or point me to
> some relevant documentation.
>
> Thanks in advance!
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] NetLoop initialization bug

[Michael Zaidman]

On Tue, Mar 31, 2009 at 12:30 PM, Detlev Zundel  wrote:
> Hi Michael,

[...]

> The patch in your mail does still not apply.  Neither git-am (after
> fixing the patch with a valid e-mail) nor patch can do anything with it.
>
> Thanks
>  Detlev
>


Sorry for the previous mail,
I have to enable the git operation via gmail on my workstation.

Meanwhile I created the patch again by diff.

Thanks,
Michael


The patch fixes the bug of partial initialization of global network
parameters.

Upon u-boot's start up the first ping command causes a failure of the
consequent TFTP transfers. It happens in the recently added mechanism of
NetLoop initialization where initialization of global network parameters is
separated in the NetInitLoop routine which is called per env_id change.
Thus, ping request will initialize the network parameters necessary
for ping operation only, afterwards the env_changed_id will be set
to the env_id that will prevent all following initialization requests
from other protocols.
The problem is that the initialized by ping subset of network parameters
is not sufficient for other protocols and particularly for TFTP
which requires the NetServerIp also.

Signed-off-by: Michael Zaidman 


mich...@michaelz:~/develop$ diff -u u-boot-git/net/net.c
u-boot-git-test1/net/net.c
--- u-boot-git/net/net.c2009-03-31 13:56:18.0 +0300
+++ u-boot-git-test1/net/net.c  2009-03-30 15:57:14.0 +0300
@@ -288,64 +288,13 @@
if (env_changed_id == env_id)
return 0;

-   switch (protocol) {
-#if defined(CONFIG_CMD_NFS)
-   case NFS:
-#endif
-#if defined(CONFIG_CMD_PING)
-   case PING:
-#endif
-#if defined(CONFIG_CMD_SNTP)
-   case SNTP:
-#endif
-   case NETCONS:
-   case TFTP:
-   NetCopyIP(&NetOurIP, &bd->bi_ip_addr);
-   NetOurGatewayIP = getenv_IPaddr ("gatewayip");
-   NetOurSubnetMask= getenv_IPaddr ("netmask");
-   NetOurVLAN = getenv_VLAN("vlan");
-   NetOurNativeVLAN = getenv_VLAN("nvlan");
+   NetCopyIP(&NetOurIP, &bd->bi_ip_addr);
+   NetOurGatewayIP = getenv_IPaddr ("gatewayip");
+   NetOurSubnetMask= getenv_IPaddr ("netmask");
+   NetServerIP = getenv_IPaddr ("serverip");
+   NetOurNativeVLAN = getenv_VLAN("nvlan");
+   NetOurVLAN = getenv_VLAN("vlan");

-   switch (protocol) {
-#if defined(CONFIG_CMD_NFS)
-   case NFS:
-#endif
-   case NETCONS:
-   case TFTP:
-   NetServerIP = getenv_IPaddr ("serverip");
-   break;
-#if defined(CONFIG_CMD_PING)
-   case PING:
-   /* nothing */
-   break;
-#endif
-#if defined(CONFIG_CMD_SNTP)
-   case SNTP:
-   /* nothing */
-   break;
-#endif
-   default:
-   break;
-   }
-
-   break;
-   case BOOTP:
-   case RARP:
-   /*
-* initialize our IP addr to 0 in order to accept ANY
-* IP addr assigned to us by the BOOTP / RARP server
-*/
-   NetOurIP = 0;
-   NetServerIP = getenv_IPaddr ("serverip");
-   NetOurVLAN = getenv_VLAN("vlan");   /* VLANs must be read */
-   NetOurNativeVLAN = getenv_VLAN("nvlan");
-   case CDP:
-   NetOurVLAN = getenv_VLAN("vlan");   /* VLANs must be read */
-   NetOurNativeVLAN = getenv_VLAN("nvlan");
-   break;
-   default:
-   break;
-   }
env_changed_id = env_id;
return 0;
 }
@@ -440,10 +389,7 @@

 #if defined(CONFIG_CMD_DHCP)
case DHCP:
-   /* Start with a clean slate... */
BootpTry = 0;
-   NetOurIP = 0;
-   NetServerIP = getenv_IPaddr ("serverip");
DhcpRequest();  /* Basically same as BOOTP */
break;
 #endif
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] Fix OneNAND ipl to read CONFIG_SYS_MONITOR_LEN

[Alessandro Rubini]

Hello.

> Note that there are a couple of board files (apollon and nmdk8815) that 
> use the OneNAND loader that do not define CONFIG_SYS_MONITOR_LEN.  I've 
> added the maintainers to the Cc: list.

Sorry for the delay.

In the nomadik board the OneNAND driver is not yet present, a few init
lines are still missing (I have an error to fix before submitting those
lines).  I'll take care of CONFIG_SYS_MONITOR_LEN together with that.

Note however that on the Nomadik we don't use the IPL, since u-boot is
loaded by other code (a proprietary IPL that onlocks the CPU before
handing control to ours) so u-boot isn't even in the first sector
of OneNAND.

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

Re: [U-Boot] [PATCH 1/2] Fix OneNAND ipl to read CONFIG_SYS_MONITOR_LEN

[Scott Wood]

Alessandro Rubini wrote:
> Hello.
> 
>> Note that there are a couple of board files (apollon and nmdk8815) that 
>> use the OneNAND loader that do not define CONFIG_SYS_MONITOR_LEN.  I've 
>> added the maintainers to the Cc: list.
> 
> Sorry for the delay.
> 
> In the nomadik board the OneNAND driver is not yet present, a few init
> lines are still missing (I have an error to fix before submitting those
> lines).  I'll take care of CONFIG_SYS_MONITOR_LEN together with that.
> 
> Note however that on the Nomadik we don't use the IPL, since u-boot is
> loaded by other code (a proprietary IPL that onlocks the CPU before
> handing control to ours) so u-boot isn't even in the first sector
> of OneNAND.

OK, sorry about that.  I ran into the issue when building apollon, and 
nmdk8815 looked like it was in a similar situation from grepping config 
files.

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

Re: [U-Boot] RAM Probing for ads5121rev4

[Michele De Candia (VT)]

Wolfgang Denk wrote:
> Dear Emanuele Placidi,
>
> In message <7c4b93310902180021o56da8320w2084e6a8c09c9...@mail.gmail.com> you 
> wrote:
>   
>>In your opinion it is possible to probe the ram before initialize it?
>> Unfortunately there are some rev4 which are equipped with different ram
>> model.
>> Examples are welcomed.
>> 
>
> It is a standard feature in U-Boot (and has always  been  right  from
> the start with PPCBoot nearly 10 years ago) that we auto-detected the
> memory  configuration  on  the  boards,  both for RAM and flash. Some
> boards / architectures did not bother  to  implement  this,  but  the
> feature itself is present.
>
> The  details  depend  on  processor,  memory  controller  properties,
> specific RAM types used, etc.
>
> In case of the Micron/Elpida issue on the ADS5121, that should be not
> too difficult to solve.
>   
The issue concerns the possibility to identify DDR chips type (e.g. by 
VendorId) before initialize them.
It doesn't concern configuration parameters (size, bus frequency, ecc..).
There isn't a DDR command to read this information, do you think it is 
possible to solve this problem in other ways?
> Best regards,
>
> Wolfgang Denk
>
>   


-- 

*Michele Jr **De Candia*



Value Team

Via Vespri Siciliani, 9
20146 Milano
Tel. +39 0248985722
michele.decan...@valueteam.com 
http://www.valueteam.com

 

CONFIDENTIALITY NOTICE -This message and its attachments (if any) may 
contain confidential, proprietary or legally privileged information and 
is intended only for the use of the addressee named above. No 
confidentiality or privilege is waived or lost by any mistransmission. 
If you are not the intended recipient of this message you are hereby 
notified that you must not use, disseminate, copy it in any form or take 
any action in reliance on it. If you have received this message in error 
please delete it and any copies of it and kindly inform the sender of 
this e-mail by replying or go to www.valueteam.com 
 on 'contacts'.

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

[U-Boot] [PATCH] tools/setlocalversion: use git svn instead of git-svn

[Peter Korsgaard]

Use the correct git  syntax instead of the deprecated git-.

Signed-off-by: Peter Korsgaard 
---
 tools/setlocalversion |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tools/setlocalversion b/tools/setlocalversion
index bbb2ab2..b3f5f28 100755
--- a/tools/setlocalversion
+++ b/tools/setlocalversion
@@ -25,7 +25,7 @@ if head=`git rev-parse --verify HEAD 2>/dev/null`; then
 
# Is this git on svn?
if git config --get svn-remote.svn.url >/dev/null; then
-   printf -- '-svn%s' "`git-svn find-rev $head`"
+   printf -- '-svn%s' "`git svn find-rev $head`"
fi
 fi
 
-- 
1.6.2

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

Re: [U-Boot] core ticks/timer code

[Dirk Behme]

Jean-Christophe PLAGNIOL-VILLARD wrote:
>> i wouldnt mind starting a patch series for post 2009.05 to clean this up ...
> I've in mind too maybe I'll send a first version within few days for a arm soc
> and a blackfin based on u-boot-v2

In contrast to Jean-Christophe's plan

http://lists.denx.de/pipermail/u-boot/2009-March/049861.html

(last sentence) I'd like that we split general ticks/timer code clean 
up and bug fixes. I'd like that we implement the changes proposed by 
Mike and Jean-Christophe independent and don't mix them with other 
fixes for broken timer code like

http://lists.denx.de/pipermail/u-boot/2009-March/049146.html

Having proper/fixed (old style) timer code will make it easier to 
convert to new style afterwards.

 From my point of view this is similar to rule "don't mix coding style 
with functional changes".

Best regards

Dirk


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

Re: [U-Boot] core ticks/timer code

[Wolfgang Denk]

Dear Jean-Christophe PLAGNIOL-VILLARD,

In message <20090331113956.gd28...@game.jcrosoft.org> you wrote:
>
> > Agreed (except that we probably  cannot  completely  throw  away  the
> > tick;  IIRC  there  are  cases  in early startup when nothing else is
> > available yet).
> not necessarely you can activate the timer just after the cpu_init
> so normally you do not need any get_ticks.

Please check for example the PowerPC code, then.

Ther ethe timer implementation relies heavily on interrupts and is not
available in early stages, for example in NAND booting systems with
tight memory restrictions.

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
"To IBM, 'open' means there is a modicum  of  interoperability  among
some of their equipment."- Harv Masterson
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] core ticks/timer code

[Wolfgang Denk]

Dear Scott McNutt,

In message <49d2014f.4070...@psyent.com> you wrote:
> > so if we were to document things, it should read like this:
> >  - CONFIG_SYS_HZ is required to be 1000
> 
> Can't this just be eliminated? It's stupid to have a configurable
> option that is neither ;-)
> 
> And it doesn't do much for my confidence when things stop working
> (like my tftp downloads now that the tftp timeout has been, ahem,
> "fixed") only because a "configurable" option wasn't set to the
> "correct" value.
> 
> If we can't change it with breaking something, then let's stop
> kidding ourselves and get rid of it.

Agreed.

We still need some hint that the timer works in millisecond
resolution, though - no matter what you call it.

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
Whenever people agree with me, I always think I must be wrong.
- Oscar Wilde
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] core ticks/timer code

[Wolfgang Denk]

Dear Mike Frysinger,

In message <200903310725.20652.vap...@gentoo.org> you wrote:
>
> > Agreed (except that we probably  cannot  completely  throw  away  the
> > tick;  IIRC  there  are  cases  in early startup when nothing else is
> > available yet).
> 
> hrm, i can see that.  but you agree that most use of ticks in common code can 
> be converted to get_timer() ?  on Blackfin systems (and it isnt alone going 
> by 

Yes, of course I do.

> a grep), the ticks interface simply returns get_timer(0), so clearly we 
> should 
> be able to convert common code to all use get_timer(0).  that'd leave the 
> ticks interface as optional ... for the systems that need early time sources, 
> they can implement/use it as they need without bringing down everyone else.
>
> i wouldnt mind starting a patch series for post 2009.05 to clean this up ...

Excellent. Thanks in advance.

For BF or for all architectures?

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
"Obviously, a major malfunction has occurred."
  -- Steve Nesbitt, voice of Mission Control, January 28,
 1986, as the shuttle Challenger exploded within view
 of the grandstands.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] ARM Pull Request

[Dirk Behme]

Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 21:49 Mon 30 Mar , Wolfgang Denk wrote:
>> Dear Dirk Behme,
>>
>> In message <49d11e7d.5030...@googlemail.com> you wrote:
> http://lists.denx.de/pipermail/u-boot/2009-March/049762.html
>
> Please remove it from the pull request until everybody agreed
 this duplicated code 
>>> It would be nice if you could give the exact file in which you found 
>>> the other/original version of this code. As already mentioned I'd like 
>>> to compare/review it.
>>>
 so I'll remove it anyway I do not want duplicated code
>>> It would be nice if we could agree on a common way how to improve 
>>> (remove?) this code. And not just "I'll remove it anyway". Sorry if I 
>>> misunderstood this, but it could be understood as "I will remove it 
>>> independent of what other people think and do".
>> I have to admit that I, too, hesitated what that statement was
>> supposed to mean. Jean-Christophe, it would really be nice to raise
>> your complaints on the mailing list, and without too long delays, so
>> we can discuss things.
> It's simple I really hate duplicated that's all
> so when I find copy&paste I remote it

It would be nice if you could give the exact file in which you found 
the other/original version of this code. As already mentioned I'd like 
to compare/review it.

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

Re: [U-Boot] Enabling ARM DCache (and MMU setup) in U-Boot

[Drasko DRASKOVIC]

On Tue, Mar 31, 2009 at 4:09 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>Honnestly we will not work on such old code. so please really consider to
>rebase it against mainline
I downloaded the last version of U-Boot and will do all my work regarding
DCache and MMU setup here.

>first you may start to think to run in XIP to avoid the copy too
I would adore to do this. Unforunately design does not allow :'(. Flash is
serially connected, so I have to drag whole god damn image byte by byte in
SDRAM before CRC check and boot (I had to change cmd_bootm.c for this to
work). This is the loop I mention before, and I would like to speed up this
long process by introducing DCache.

>now it's more clear about what you try to do
I am sorry for not being clear before, but even I myself do not quite
understand where to start...

>yes on arm if you want to have access to the dcache you will have to set
the
>MMU first.
That's what I was affraid of.

>you may need to take a look on the arm1176/start.S
Thanks for the hint! I will examine this file (now that thing are begining
to be clearer to me maybe I will understand something).

Thank you very much for your time and help.

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

Re: [U-Boot] How to create an ELF file which U-Boot understands and boots it

[kuldeep nigam]

check  u-boot/examples/README.smc9_eeprom
u can add the ur files under examples folder, modify the Makefile and then
cross compile it.

With Regards,
Kuldeep Nigam

On Tue, Mar 31, 2009 at 6:45 PM, arun c  wrote:

> Hi All,
>
> I want to create an elf file which U-Boot understands and I should
> be able to use bootelf  command to boot it.
>
> I searched the email archives and I did not find anything
> helpful.
>
> Does anybody has any pointers?
>
> I am working using standard gnu cross compiler, on
> an MCF5484 evaluation kit.
>
> Regards,
> Arun C
> ___
> 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] Enabling ARM DCache (and MMU setup) in U-Boot

[Jean-Christophe PLAGNIOL-VILLARD]

On 15:36 Tue 31 Mar , Drasko DRASKOVIC wrote:
>On Tue, Mar 31, 2009 at 2:21 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>U-Boot 1.1.6 is quite old (more than 2 years old) please try to the
>current version
>I know, but that's the one we use... For now, everything works fine.
Honnestly we will not work on such old code. so please really consider to
rebase it against mainline
> 
>>is your SOC in the Mainline?
>>if you can tell us which one it's and if it is mainline in U-Boot or
>Linux?
>>we could take a look on the code
>Nope, actually it is a custom chip based on ARM9. Most of other things are
>proprietery.
> 
>>in linux yes in u-boot some arch do it but not the arm9
>In Linux for sure, but we have MMU setup in Linux, and it is beyond my
>knowledge. I am concentrated on as-simple-as-can-be DCache switch on, to
>speed up operations of copying Linux image PRIOR to kernel boot.
first you may start to think to run in XIP to avoid the copy too
> 
>>IMHO your boot problem is more in linux than in U-Boot
>To be clear - I am experiencing long delay in reading peripheral regs. I
>am reading some registers in a loop, so it takes long time for each
>access.
>After that I also noticed that giving a value to any variable takes long
>time, so it makes me suspect that SDRAM access is very slow. For example,
>calling get_timer(0) takes the time of over 1000 cycles!
> 
>So, quite independantly of Linux, I want to speed up Flash and SDRAM R/W,
>as well as R/W of peripherals regs in the loop by introducing DCache. Then
>I saw that for ARM9 to enable DCache one must setup and enable MMU also,
>and it becomes mess, because I can find any examples in U-Boot and it seem
>pretty complex to me.
> 
>To underline, my intention of enabling DCache in U-Boot has nothing to do
>with Linux, because I will switch off caches anyway before boot. I just
>want to use DCache while read and write operations prior to calling kernel
>boot.
now it's more clear about what you try to do

yes on arm if you want to have access to the dcache you will have to set the
MMU first.

you can also have an overhead for the memory copy due to the fact it's code in
c ad not optimized in asm
> 
>>but until we can take a look on the code it will be hard to known
>Which code would help? I do not have anything yet regarding the setup. I
>do not know where to start. For the time, I am examining CP15 coprocessor
>manipulations in cpu/arm926, which enables/disables cache (even function
>that you mentioned, cleanup_before_linux() is defined here).
>In cpu/arm920t/cpu.c i found these lines, for example :

as mention precedently if you want to use the dcache you must first correctly
setup the MMU and the TLB

>So, started digging with a hope that somebody alredy implemented this in
>U-Boot, so I can copy/paste code in my cpu set-up, or, better yet, call a
>set of C functions (similar to dcache_enable), to set-up MMU, and in the
>end just call dcache_enable() to do the magic of enabling DCache.

if you want to use the dcache you must first correctly setup the MMU and the TLB

you may need to take a look on the arm1176/start.S

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

[U-Boot] [PATCH 1/1] at91: add support for the PM9263 board of Ronetix

[RONETIX - Ilko Iliev]

The PM9263 board is based on the AT91SAM9263-EK board.
Here is the page on Ronetix website:
http://www.ronetix.at/starter_kit_9263.html

Signed-off-by: Ilko Iliev 
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD 
---
 MAINTAINERS|4 +
 MAKEALL|1 +
 Makefile   |4 +
 board/ronetix/pm9263/Makefile  |   61 +++
 board/ronetix/pm9263/config.mk |1 +
 .../lowlevel_init.S => board/ronetix/pm9263/led.c  |   32 +-
 board/ronetix/pm9263/lowlevel_init.S   |  279 +
 board/ronetix/pm9263/partition.c   |   47 +++
 board/ronetix/pm9263/pm9263.c  |  413 

 cpu/arm926ejs/at91/Makefile|5 +-
 cpu/arm926ejs/at91/config.mk   |2 +-
 cpu/arm926ejs/at91/lowlevel_init.S |2 +
 cpu/arm926ejs/at91/{u-boot.lds => u-boot.lds.S}|9 +-
 include/asm-arm/arch-at91/at91sam9263.h|1 +
 include/asm-arm/arch-at91/at91sam9_sdramc.h|   87 
 include/asm-arm/arch-at91/hardware.h   |   17 +
 include/configs/pm9263.h   |  367 +
 tools/Makefile |3 +
 tools/logos/ronetix.bmp|  Bin 0 -> 5638 bytes
 19 files changed, 1315 insertions(+), 20 deletions(-)
 create mode 100644 board/ronetix/pm9263/Makefile
 create mode 100644 board/ronetix/pm9263/config.mk
 copy cpu/arm926ejs/at91/lowlevel_init.S => board/ronetix/pm9263/led.c (65%)
 create mode 100644 board/ronetix/pm9263/lowlevel_init.S
 create mode 100644 board/ronetix/pm9263/partition.c
 create mode 100644 board/ronetix/pm9263/pm9263.c
 rename cpu/arm926ejs/at91/{u-boot.lds => u-boot.lds.S} (90%)
 create mode 100644 include/asm-arm/arch-at91/at91sam9_sdramc.h
 create mode 100644 include/configs/pm9263.h
 create mode 100644 tools/logos/ronetix.bmp

diff --git a/MAINTAINERS b/MAINTAINERS
index 25b28d6..efd04f0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -204,6 +204,10 @@ Klaus Heydeck 
 KUP4KMPC855
 KUP4XMPC859
 
+Ilko Iliev 
+
+PM9263AT91SAM9263
+
 Gary Jennejohn 
 
 quad100hdPPC405EP
diff --git a/MAKEALL b/MAKEALL
index 89f1c55..2cde057 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -581,6 +581,7 @@ LIST_at91="\
 kb9202\
 mp2usb\
 m501sk\
+pm9263\
 "
 
 #
diff --git a/Makefile b/Makefile
index a9f25c9..51cb69d 100644
--- a/Makefile
+++ b/Makefile
@@ -2743,6 +2743,9 @@ at91sam9rlek_config:unconfig
 fi;
 @$(MKCONFIG) -a at91sam9rlek arm arm926ejs at91sam9rlek atmel at91
 
+pm9263_config:unconfig
+@$(MKCONFIG) $(@:_config=) arm arm926ejs pm9263 ronetix at91
+
 
 ## ARM Integrator boards - see doc/README-integrator for more info.
 integratorap_config\
@@ -3511,6 +3514,7 @@ clean:
$(obj)board/trab/trab_fkt   $(obj)board/voiceblue/eeprom   \
$(obj)board/armltd/{integratorap,integratorcp}/u-boot.lds  \

$(obj)board/{bf533-ezkit,bf533-stamp,bf537-stamp,bf561-ezkit}/u-boot.lds \
+   $(obj)cpu/arm926ejs/at91/u-boot.lds \
$(obj)cpu/blackfin/bootrom-asm-offsets.[chs]
 @rm -f $(obj)include/bmp_logo.h
 @rm -f $(obj)nand_spl/{u-boot-spl,u-boot-spl.map,System.map}
diff --git a/board/ronetix/pm9263/Makefile b/board/ronetix/pm9263/Makefile
new file mode 100644
index 000..270abd8
--- /dev/null
+++ b/board/ronetix/pm9263/Makefile
@@ -0,0 +1,61 @@
+#
+# (C) Copyright 2003-2008
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# (C) Copyright 2008
+# Stelian Pop 
+# Lead Tech Design 
+# Ilko Iliev 
+#
+# 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-y += pm9263.o
+COBJS-y += led.o
+COBJS-$(CONFIG_HAS_DATAFLASH) += partition.o
+
+ifndef CONFIG_SKIP_LOWLEVEL_INIT
+SOBJS-y:= lowlevel_init.o
+endif
+
+SRCS   

Re: [U-Boot] Enabling ARM DCache (and MMU setup) in U-Boot

[Drasko DRASKOVIC]

On Tue, Mar 31, 2009 at 2:21 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>but until we can take a look on the code it will be hard to known
And I just found :
./examples/test_burst_lib.S: *void mmu_init(void);
./examples/test_burst_lib.S:.global mmu_init
./examples/test_burst_lib.S:mmu_init:
./examples/test_burst.c:mmu_init();

I think I need something like this (I did not deeply inspected the code),
but for ARM (examples here are for PPC).

Similar to this example, I would first enable MMU ( call to a mmu_init() ),
then caches ( calls to dcache_enable() and icache_enable() ), then do some
read and write to a memory. Voila.

I hope that then all R/W to memory will be faster because of support of
DCache.

If anybody knows where I can find similar example (or how can I modify this
one for ARM maybe), help will be more than welcome.

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

Re: [U-Boot] Enabling ARM DCache (and MMU setup) in U-Boot

[Drasko DRASKOVIC]

On Tue, Mar 31, 2009 at 2:21 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>U-Boot 1.1.6 is quite old (more than 2 years old) please try to the current
version
I know, but that's the one we use... For now, everything works fine.

>is your SOC in the Mainline?
>if you can tell us which one it's and if it is mainline in U-Boot or Linux?
>we could take a look on the code
Nope, actually it is a custom chip based on ARM9. Most of other things are
proprietery.

>in linux yes in u-boot some arch do it but not the arm9
In Linux for sure, but we have MMU setup in Linux, and it is beyond my
knowledge. I am concentrated on as-simple-as-can-be DCache switch on, to
speed up operations of copying Linux image PRIOR to kernel boot.

>IMHO your boot problem is more in linux than in U-Boot
To be clear - I am experiencing long delay in reading peripheral regs. I am
reading some registers in a loop, so it takes long time for each access.
After that I also noticed that giving a value to any variable takes long
time, so it makes me suspect that SDRAM access is very slow. For example,
calling get_timer(0) takes the time of over 1000 cycles!

So, quite independantly of Linux, I want to speed up Flash and SDRAM R/W, as
well as R/W of peripherals regs in the loop by introducing DCache. Then I
saw that for ARM9 to enable DCache one must setup and enable MMU also, and
it becomes mess, because I can find any examples in U-Boot and it seem
pretty complex to me.

To underline, my intention of enabling DCache in U-Boot has nothing to do
with Linux, because I will switch off caches anyway before boot. I just want
to use DCache while read and write operations prior to calling kernel boot.

>but until we can take a look on the code it will be hard to known
Which code would help? I do not have anything yet regarding the setup. I do
not know where to start. For the time, I am examining CP15 coprocessor
manipulations in cpu/arm926, which enables/disables cache (even function
that you mentioned, cleanup_before_linux() is defined here).
In cpu/arm920t/cpu.c i found these lines, for example :

#ifdef USE_920T_MMU
/* It makes no sense to use the dcache if the MMU is not enabled */
void dcache_enable (void)
{
ulong reg;

reg = read_p15_c1 ();
cp_delay ();
write_p15_c1 (reg | C1_DC);
}

I tried calling function dcache_enable () when I enter my driver which does
extensive R/W on peripheral regs (and on SDRAM), but off course - it does
not work. Even comment says so :). In ARM manual I found:

CP15
C bit   M bit
00  DCache disabled. All data accesses are to the
external memory.

10  DCache enabled, MMU disabled. The C bit is overriden
by the M bit
 setting, which means that the DCache is effectively
disabled. All
 data accesses are noncachable, nonbufferable, with
no protection
 checks. All addresses are flat mapped, that is VA =
MVA = PA.

11  DCache enabled, MMU enabled. All data accesses are
cachable or
 noncachable depending on the page descriptor C bit
and B bit (see
 Table 4-4), and protection checks are performed.
All addresses are
 remapped from VA to PA, depending on the MMU page
table entry,
 that is the VA is translated to an MVA, and the MVA
is remapped to
 a PA.

So, started digging with a hope that somebody alredy implemented this in
U-Boot, so I can copy/paste code in my cpu set-up, or, better yet, call a
set of C functions (similar to dcache_enable), to set-up MMU, and in the end
just call dcache_enable() to do the magic of enabling DCache.

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

[U-Boot] How to create an ELF file which U-Boot understands and boots it

[arun c]

Hi All,

I want to create an elf file which U-Boot understands and I should
be able to use bootelf  command to boot it.

I searched the email archives and I did not find anything
helpful.

Does anybody has any pointers?

I am working using standard gnu cross compiler, on
an MCF5484 evaluation kit.

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

Re: [U-Boot] Enabling ARM DCache (and MMU setup) in U-Boot

[Jean-Christophe PLAGNIOL-VILLARD]

On 14:20 Tue 31 Mar , Drasko DRASKOVIC wrote:
>>On Mon, Mar 30, 2009 at 10:31 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>before booting linux you must disable the cache which will be re-enable
>by
>>linux.
>OK. Is that done in bootm.c? I can see lines :
>/*
> * We have reached the point of no return: we are going to
> * overwrite all exception vector code, so we cannot easily
> * recover from any failures any more...
> */
> 
>iflag = disable_interrupts();
> 
>#ifdef CONFIG_AMIGAONEG3SE
>/*
> * We've possible left the caches enabled during
> * bios emulation, so turn them off again
> */
>icache_disable();
>invalidate_l1_instruction_
>cache();
>flush_data_cache();
>dcache_disable();
>#endif
AMIGAONE is a PPC

please take a look on this file
 lib_arm/bootm.c 
 and specialy on the  cleanup_before_linux (); soc implementation

>>Could you give us more details about your soc, u-boot verison and linux
>>version
>u-boot-1.1.6, linux version is linux-2.6.25.10, although that is not
>important because I have no problem with this but with slow access to
>Flash and SDRAM, as I said before. Core is ARM926.
U-Boot 1.1.6 is quite old (more than 2 years old) please try to the current 
version
is your SOC in the Mainline?
if you can tell us which one it's and if it is mainline in U-Boot or Linux?
we could take a look on the code
> 
>As I understand, these things have to be set up in the order to enable
>DCache :
> 1. Page tables
> 2. The Translation Lookaside Buffer (TLB)
> 3. Domains and access permission
> 4. Caches and write buffer
> 5. The CP15:c1 control register
> 6. The Fast Context Switch Extension
>Now, that seems like a lot of work to be done, and reading manual is not
>extremely helpful, so I was wondering if somebody already done similar
>thing in U-Boot, for ARM9 platform, so I could reuse some work or examine
>examples to figure out how this is done.
in linux yes in u-boot some arch do it but not the arm9
IMHO your boot problem is more in linux than in U-Boot but until we can take a
look on the code it will be hard to known

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

Re: [U-Boot] Enabling ARM DCache (and MMU setup) in U-Boot

[Drasko DRASKOVIC]

>On Mon, Mar 30, 2009 at 10:31 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>before booting linux you must disable the cache which will be re-enable by
>linux.
OK. Is that done in bootm.c? I can see lines :
/*
 * We have reached the point of no return: we are going to
 * overwrite all exception vector code, so we cannot easily
 * recover from any failures any more...
 */

iflag = disable_interrupts();

#ifdef CONFIG_AMIGAONEG3SE
/*
 * We've possible left the caches enabled during
 * bios emulation, so turn them off again
 */
icache_disable();
invalidate_l1_instruction_cache();
flush_data_cache();
dcache_disable();
#endif

Looks like only interrupts are disabled, and caches only in the case of
AMIGAONE (whatever that might be). There are no other calls to cache_disable
functions. I already use ICache, and cmd_bootm.c like presented (thus no
call to icache_disable() here), and it works. Only that copying image from
Flash is slow, so I want to speed it up with enablilng DCache.

>Could you give us more details about your soc, u-boot verison and linux
>version
u-boot-1.1.6, linux version is linux-2.6.25.10, although that is not
important because I have no problem with this but with slow access to Flash
and SDRAM, as I said before. Core is ARM926.

As I understand, these things have to be set up in the order to enable
DCache :

   1. Page tables
   2. The Translation Lookaside Buffer (TLB)
   3. Domains and access permission
   4. Caches and write buffer
   5. The CP15:c1 control register
   6. The Fast Context Switch Extension

Now, that seems like a lot of work to be done, and reading manual is not
extremely helpful, so I was wondering if somebody already done similar thing
in U-Boot, for ARM9 platform, so I could reuse some work or examine examples
to figure out how this is done.

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

Re: [U-Boot] core ticks/timer code

[Jean-Christophe PLAGNIOL-VILLARD]

On 07:25 Tue 31 Mar , Mike Frysinger wrote:
> On Tuesday 31 March 2009 06:28:23 Wolfgang Denk wrote:
> > In message Mike Frysinger wrote:
> > > > I'll propose a new design with the following Requierement
> > > >
> > > > Generic delay function implementation
> > > >  - ndelay()
> > > >  - udelay()
> > > >  - mdelay()
> > > >
> > > > Generic helper
> > > >  - khz2cycles()
> > > >  - hz2cycles()
> > > >  - cs2ns()
> > > >
> > > > Timer API
> > > >  - timer_init() - setup the timer
> > > >  - timer_reset()- reset the timer (use in case of overflow)
> > > >  - get_ticks()  - return the current ticks
> > > >  - get_cycles() - return the ticks frequency in ns
> > >
> > > do you have real use cases here ?  i'd actually propose the opposite:
> > > kill off the notion of "ticks", "cycles", and "hz".  i dont think
> > > ndelay() is really necessary, and mdelay() is a simple macro on top of
> > > udelay().  that leaves us with really only the three functions we have
> > > today: timer_init(), get_timer(), and reset_timer().  we clarify that the
> > > function operates in terms of milliseconds and blam, it's all so simple
> > > now.
> >
> > Agreed (except that we probably  cannot  completely  throw  away  the
> > tick;  IIRC  there  are  cases  in early startup when nothing else is
> > available yet).
> 
> hrm, i can see that.  but you agree that most use of ticks in common code can 
> be converted to get_timer() ?  on Blackfin systems (and it isnt alone going 
> by 
> a grep), the ticks interface simply returns get_timer(0), so clearly we 
> should 
> be able to convert common code to all use get_timer(0).  that'd leave the 
> ticks interface as optional ... for the systems that need early time sources, 
> they can implement/use it as they need without bringing down everyone else.
> 
> i wouldnt mind starting a patch series for post 2009.05 to clean this up ...
I've in mind too maybe I'll send a first version within few days for a arm soc
and a blackfin based on u-boot-v2

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

Re: [U-Boot] core ticks/timer code

[Jean-Christophe PLAGNIOL-VILLARD]

On 12:28 Tue 31 Mar , Wolfgang Denk wrote:
> Dear Mike Frysinger,
> 
> In message <200903310513.09082.vap...@gentoo.org> you wrote:
> >
> ...
> > > I've in mind to partially import the clocksource linux API or create a new
> > > U-Boot api devired from it's design
> >
> > the clocksource framework in linux sounds like extreme overkill for u-boot.
> > where do you see realistic usage of more than one timer ?  u-boot is pretty
> > much a single threaded app that polls.
That's why I've tell to partially import it as have done Sascha in u-boot V2
> 
> Correct. We definitely do not need the full capabilities of the Linux
> framework. Any new implementation will be checked against the current
> code, and memory foot print is something we will check carefully.
> 
> OTOH, I think Sascha's u-boot-v2 uses code that was derived from the
> Linux code, but in a pretty lean way. It may be interesting to check
> there...
I've take a look on it and it's the idea I've in mind to do also
> 
> > > I'll propose a new design with the following Requierement
> > >
> > > Generic delay function implementation
> > >  - ndelay()
> > >  - udelay()
> > >  - mdelay()
> > >
> > > Generic helper
> > >  - khz2cycles()
> > >  - hz2cycles()
> > >  - cs2ns()
> > >
> > > Timer API
> > >  - timer_init()   - setup the timer
> > >  - timer_reset()  - reset the timer (use in case of overflow)
> > >  - get_ticks()- return the current ticks
> > >  - get_cycles()   - return the ticks frequency in ns
> >
> > do you have real use cases here ?  i'd actually propose the opposite: kill 
> > off 
> > the notion of "ticks", "cycles", and "hz".  i dont think ndelay() is really 
> > necessary, and mdelay() is a simple macro on top of udelay().  that leaves 
> > us 
> > with really only the three functions we have today: timer_init(), 
> > get_timer(), 
> > and reset_timer().  we clarify that the function operates in terms of 
> > milliseconds and blam, it's all so simple now.
Yes I've real case where I do need ndelay to generate high speed clock with a
gpio and udelay is too slow.

we need get_cycles and get_ticks to calculate the udelay, mdelay and ndelay
otherwise how can you known the ticks frequency?
> 
> Agreed (except that we probably  cannot  completely  throw  away  the
> tick;  IIRC  there  are  cases  in early startup when nothing else is
> available yet).
not necessarely you can activate the timer just after the cpu_init
so normally you do not need any get_ticks.

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

Re: [U-Boot] core ticks/timer code

[Scott McNutt]

> so if we were to document things, it should read like this:
>  - CONFIG_SYS_HZ is required to be 1000

Can't this just be eliminated? It's stupid to have a configurable
option that is neither ;-)

And it doesn't do much for my confidence when things stop working
(like my tftp downloads now that the tftp timeout has been, ahem,
"fixed") only because a "configurable" option wasn't set to the
"correct" value.

If we can't change it with breaking something, then let's stop
kidding ourselves and get rid of it.

--Scott

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

Re: [U-Boot] core ticks/timer code

[Mike Frysinger]

On Tuesday 31 March 2009 06:28:23 Wolfgang Denk wrote:
> In message Mike Frysinger wrote:
> > > I'll propose a new design with the following Requierement
> > >
> > > Generic delay function implementation
> > >  - ndelay()
> > >  - udelay()
> > >  - mdelay()
> > >
> > > Generic helper
> > >  - khz2cycles()
> > >  - hz2cycles()
> > >  - cs2ns()
> > >
> > > Timer API
> > >  - timer_init()   - setup the timer
> > >  - timer_reset()  - reset the timer (use in case of overflow)
> > >  - get_ticks()- return the current ticks
> > >  - get_cycles()   - return the ticks frequency in ns
> >
> > do you have real use cases here ?  i'd actually propose the opposite:
> > kill off the notion of "ticks", "cycles", and "hz".  i dont think
> > ndelay() is really necessary, and mdelay() is a simple macro on top of
> > udelay().  that leaves us with really only the three functions we have
> > today: timer_init(), get_timer(), and reset_timer().  we clarify that the
> > function operates in terms of milliseconds and blam, it's all so simple
> > now.
>
> Agreed (except that we probably  cannot  completely  throw  away  the
> tick;  IIRC  there  are  cases  in early startup when nothing else is
> available yet).

hrm, i can see that.  but you agree that most use of ticks in common code can 
be converted to get_timer() ?  on Blackfin systems (and it isnt alone going by 
a grep), the ticks interface simply returns get_timer(0), so clearly we should 
be able to convert common code to all use get_timer(0).  that'd leave the 
ticks interface as optional ... for the systems that need early time sources, 
they can implement/use it as they need without bringing down everyone else.

i wouldnt mind starting a patch series for post 2009.05 to clean this up ...
-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

Re: [U-Boot] Board Reset issue

[rk1825]

Liu Dave wrote:
> 
>> I am using a custom board with MPC8313E processor. In u-boot 
>> prompt, when i
>> do TFTP of large size files, sometime it hangs completely 
>> and, sometimes it
>> says bus fault,  prints following message and resets the board.
>> 
>> /message
>> printed/
>> Bus Fault @ 0x0900, fixup 0x
>> Machine check in kernel mode.
>> Caused by (from msr): regs 07f85b48 Unknown values in msr
>> NIP: 0900 XER: 2000 LR: 07FC709C REGS: 07f85b48 TRAP: 
>> 0200 DAR:
>> 07F85F58
>> MSR: 1000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
>> 
>> GPR00:  07F85C38 0080  07FFCD80 07FEDB88 07FEDB88
>> 07FED124
>> GPR08: 07FEDB98 4E800020 07FEDBB0 000C 07F85B28 F54ADC0C 07FF
>> 09FA8000
>> GPR16: 7347FB13      
>> 
>> GPR24: 07F89ED8  07F85FBC 0003  07F85F58 0FFF1390
>> 07FED054
>> Call backtrace:
>> 07FC70D4 07FC7274 07FC73F8 07FAE0E8 07FC4724 07FCBDDC 07FCB4D0
>> 07FCB6DC 07FBAAC4 07FCBDDC 07FCB4D0 07FCB62C 07FBA2B4 07FAC84C
>> 07FAB66C 00420400
>> machine check
>> Resetting the board.
>> //
>> /
>> 
>> Please help me with what could be the reason for this ? 
> 
> Did you have one stable memory system?
> 
> What is the clock information? Such as core/csb/ddr data rate?
> What is the ACR value?
> 
> Thanks, Dave
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
> 
> 



DDR2 is used in our board with following clock configuration:-
Clock configuration:
  Coherent System Bus:  166 MHz
  Core: 333 MHz
  Local Bus Controller: 166 MHz
  Local Bus: 41 MHz
  DDR:  333 MHz
  SEC:   55 MHz
  I2C1: 166 MHz
  I2C2: 166 MHz
  TSEC1:166 MHz
  TSEC2:166 MHz
  USB MPH:0 MHz
  USB DR:55 MHz
CPU: MPC8313E, Rev: 10 at 333.333 MHz
Board: S600 CPU BOARD
I2C:   ready
DRAM:  Initializing
   DDR RAM: 128 MB

ACR settings defined are as follows:- 
Arbiter pipeline depth (0-3)
Arbiter repeat count (0-7) 

Thanks
Rupesh
-- 
View this message in context: 
http://www.nabble.com/Board-Reset-issue-tp22802830p22803060.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] Board Reset issue

[Liu Dave-R63238]

> I am using a custom board with MPC8313E processor. In u-boot 
> prompt, when i
> do TFTP of large size files, sometime it hangs completely 
> and, sometimes it
> says bus fault,  prints following message and resets the board.
> 
> /message
> printed/
> Bus Fault @ 0x0900, fixup 0x
> Machine check in kernel mode.
> Caused by (from msr): regs 07f85b48 Unknown values in msr
> NIP: 0900 XER: 2000 LR: 07FC709C REGS: 07f85b48 TRAP: 
> 0200 DAR:
> 07F85F58
> MSR: 1000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
> 
> GPR00:  07F85C38 0080  07FFCD80 07FEDB88 07FEDB88
> 07FED124
> GPR08: 07FEDB98 4E800020 07FEDBB0 000C 07F85B28 F54ADC0C 07FF
> 09FA8000
> GPR16: 7347FB13      
> 
> GPR24: 07F89ED8  07F85FBC 0003  07F85F58 0FFF1390
> 07FED054
> Call backtrace:
> 07FC70D4 07FC7274 07FC73F8 07FAE0E8 07FC4724 07FCBDDC 07FCB4D0
> 07FCB6DC 07FBAAC4 07FCBDDC 07FCB4D0 07FCB62C 07FBA2B4 07FAC84C
> 07FAB66C 00420400
> machine check
> Resetting the board.
> //
> /
> 
> Please help me with what could be the reason for this ? 

Did you have one stable memory system?

What is the clock information? Such as core/csb/ddr data rate?
What is the ACR value?

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

[U-Boot] Board Reset issue

[rk1825]

I am using a custom board with MPC8313E processor. In u-boot prompt, when i
do TFTP of large size files, sometime it hangs completely and, sometimes it
says bus fault,  prints following message and resets the board.

/message
printed/
Bus Fault @ 0x0900, fixup 0x
Machine check in kernel mode.
Caused by (from msr): regs 07f85b48 Unknown values in msr
NIP: 0900 XER: 2000 LR: 07FC709C REGS: 07f85b48 TRAP: 0200 DAR:
07F85F58
MSR: 1000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00

GPR00:  07F85C38 0080  07FFCD80 07FEDB88 07FEDB88
07FED124
GPR08: 07FEDB98 4E800020 07FEDBB0 000C 07F85B28 F54ADC0C 07FF
09FA8000
GPR16: 7347FB13      

GPR24: 07F89ED8  07F85FBC 0003  07F85F58 0FFF1390
07FED054
Call backtrace:
07FC70D4 07FC7274 07FC73F8 07FAE0E8 07FC4724 07FCBDDC 07FCB4D0
07FCB6DC 07FBAAC4 07FCBDDC 07FCB4D0 07FCB62C 07FBA2B4 07FAC84C
07FAB66C 00420400
machine check
Resetting the board.
///

Please help me with what could be the reason for this ? 
-- 
View this message in context: 
http://www.nabble.com/Board-Reset-issue-tp22802830p22802830.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] NetLoop initialization bug

[Michael Zaidman]

On Tue, Mar 31, 2009 at 12:30 PM, Detlev Zundel  wrote:
> Hi Michael,
>
>> Please see my comments and updated patch below.
>
> As a side note, please send your patch as an inline attachment also
> adding your signed-off-by line.  It's probably easiest to actually use
> git to apply your changes to a branch and use "git-format-patch" to
> create the patch.
>
> Please also provide more dsecriptive commit text explaining what the
> patch does.
>
> The patch in your mail does still not apply.  Neither git-am (after
> fixing the patch with a valid e-mail) nor patch can do anything with it.
>
> Thanks
>  Detlev
>
> --
> ;; Self-replicator in ELisp
> ((lambda (l) (prin1-to-string (list l (list (quote quote) l
>  (quote (lambda (l) (prin1-to-string (list l (list (quote quote) l))
> --
> DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
>

Hi Detlev,

Please try this one. I used the git-format-patch for its creation.

Thanks,
Michael

>From 8cc38fd564c0671b34afdc36df4c224d51d98334 Mon Sep 17 00:00:00 2001
From: Michael Zaidman 
Date: Tue, 31 Mar 2009 14:21:35 +0300
Subject: [PATCH] The patch fixes the bug of partial intialization of
global network parameters.

Upon u-boot's start up the first ping command causes a failure of the
consequent TFTP transfers. It happens in the recently added mechanism of
NetLoop initialization where initialization of global network parameters is
separated in the NetInitLoop routine which is called per env_id change.
Thus, ping request will initialize the network parameters necessary for ping
operation only, afterwards the env_changed_id will be set to the env_id
that will prevent all following initialization requests from other protocols.
The problem is that the initialized by ping subset of network parameters is not
sufficient for other protocols and particularly for TFTP
which requires the NetServerIp also.

Signed-off-by: Michael Zaidman 
---
 net/net.c |   66 +---
 1 files changed, 6 insertions(+), 60 deletions(-)

diff --git a/net/net.c b/net/net.c
index a89f6a0..91ed0d7 100644
--- a/net/net.c
+++ b/net/net.c
@@ -288,64 +288,13 @@ NetInitLoop(proto_t protocol)
if (env_changed_id == env_id)
return 0;

-   switch (protocol) {
-#if defined(CONFIG_CMD_NFS)
-   case NFS:
-#endif
-#if defined(CONFIG_CMD_PING)
-   case PING:
-#endif
-#if defined(CONFIG_CMD_SNTP)
-   case SNTP:
-#endif
-   case NETCONS:
-   case TFTP:
-   NetCopyIP(&NetOurIP, &bd->bi_ip_addr);
-   NetOurGatewayIP = getenv_IPaddr ("gatewayip");
-   NetOurSubnetMask= getenv_IPaddr ("netmask");
-   NetOurVLAN = getenv_VLAN("vlan");
-   NetOurNativeVLAN = getenv_VLAN("nvlan");
+   NetCopyIP(&NetOurIP, &bd->bi_ip_addr);
+   NetOurGatewayIP = getenv_IPaddr ("gatewayip");
+   NetOurSubnetMask= getenv_IPaddr ("netmask");
+   NetServerIP = getenv_IPaddr ("serverip");
+   NetOurNativeVLAN = getenv_VLAN("nvlan");
+   NetOurVLAN = getenv_VLAN("vlan");

-   switch (protocol) {
-#if defined(CONFIG_CMD_NFS)
-   case NFS:
-#endif
-   case NETCONS:
-   case TFTP:
-   NetServerIP = getenv_IPaddr ("serverip");
-   break;
-#if defined(CONFIG_CMD_PING)
-   case PING:
-   /* nothing */
-   break;
-#endif
-#if defined(CONFIG_CMD_SNTP)
-   case SNTP:
-   /* nothing */
-   break;
-#endif
-   default:
-   break;
-   }
-
-   break;
-   case BOOTP:
-   case RARP:
-   /*
-* initialize our IP addr to 0 in order to accept ANY
-* IP addr assigned to us by the BOOTP / RARP server
-*/
-   NetOurIP = 0;
-   NetServerIP = getenv_IPaddr ("serverip");
-   NetOurVLAN = getenv_VLAN("vlan");   /* VLANs must be read */
-   NetOurNativeVLAN = getenv_VLAN("nvlan");
-   case CDP:
-   NetOurVLAN = getenv_VLAN("vlan");   /* VLANs must be read */
-   NetOurNativeVLAN = getenv_VLAN("nvlan");
-   break;
-   default:
-   break;
-   }
env_changed_id = env_id;
return 0;
 }
@@ -440,10 +389,7 @@ restart:

 #if defined(CONFIG_CMD_DHCP)
case DHCP:
-   /* Start with a clean slate... */
BootpTry = 0;
-   NetOurIP = 0;
-   NetServerIP = getenv_IPaddr ("serverip");
DhcpRequest();  /* Basically same as BOOTP */
break;
 #endif
-- 
1.5

Re: [U-Boot] [PATCH] Add "source" command; prepare removal of "autoscr" command

[Wolfgang Denk]

Dear Detlev,

in message  you wrote:
> 
> > + autoscr, 2, 0, do_source,
> > + "DEPRECATED - see 'source' command",
> > + "DEPRECATED - see 'source' command"
> >
> > Most U-Boot user's are more likely to see this than the
> > feature-removal-schedule.txt in the source code.

Good idea, indeed.

> Actually I also like that, but if we head down this direction, then why
> not go all the way and print a warning on executing autoscr?  Thinking
> about it (and reflecting on how I interact with U-Boot), I fear that
> even the help message will not get too much attention from people who
> should get aware of the problem.
> 
> What do other people think about this?

That's an even better idea. I will implement both in the next version
of the patch.

Thanks!

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
WARNING:  This Product Attracts Every Other Piece  of  Matter in  the
Universe, Including the Products of Other Manufacturers, with a Force
Proportional  to the Product of the Masses and Inversely Proportional
to the Distance Between Them.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] core ticks/timer code

[Wolfgang Denk]

Dear Mike Frysinger,

In message <200903310513.09082.vap...@gentoo.org> you wrote:
>
...
> > I've in mind to partially import the clocksource linux API or create a new
> > U-Boot api devired from it's design
>
> the clocksource framework in linux sounds like extreme overkill for u-boot.
> where do you see realistic usage of more than one timer ?  u-boot is pretty
> much a single threaded app that polls.

Correct. We definitely do not need the full capabilities of the Linux
framework. Any new implementation will be checked against the current
code, and memory foot print is something we will check carefully.

OTOH, I think Sascha's u-boot-v2 uses code that was derived from the
Linux code, but in a pretty lean way. It may be interesting to check
there...

> > I'll propose a new design with the following Requierement
> >
> > Generic delay function implementation
> >  - ndelay()
> >  - udelay()
> >  - mdelay()
> >
> > Generic helper
> >  - khz2cycles()
> >  - hz2cycles()
> >  - cs2ns()
> >
> > Timer API
> >  - timer_init() - setup the timer
> >  - timer_reset()- reset the timer (use in case of overflow)
> >  - get_ticks()  - return the current ticks
> >  - get_cycles() - return the ticks frequency in ns
>
> do you have real use cases here ?  i'd actually propose the opposite: kill 
> off 
> the notion of "ticks", "cycles", and "hz".  i dont think ndelay() is really 
> necessary, and mdelay() is a simple macro on top of udelay().  that leaves us 
> with really only the three functions we have today: timer_init(), 
> get_timer(), 
> and reset_timer().  we clarify that the function operates in terms of 
> milliseconds and blam, it's all so simple now.

Agreed (except that we probably  cannot  completely  throw  away  the
tick;  IIRC  there  are  cases  in early startup when nothing else is
available yet).

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The night sky over the planet Krikkit is the least interesting  sight
in the entire Universe.
 - Douglas Adams _Life, the Universe, and Everything_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Add support for Faraday RTC IP FTRTC

[Wolfgang Denk]

Dear PoYu_Chuang,

In message <200903310858.n2v8wznb021...@ftcpcw82.faraday.com.tw> you wrote:
> This patch adds support for Faraday Technology RTC IP - FTRTC
> 
> Signed-off-by: Po-Yu Chuang 
> ---
> diff -ruN u-boot-2009.03/drivers/rtc/ftrtc.c 
> FA5A320LINUX26_u-boot/drivers/rtc/ftrtc.c
> --- u-boot-2009.03/drivers/rtc/ftrtc.c1970-01-01 08:00:00.0 
> +0800
> +++ FA5A320LINUX26_u-boot/drivers/rtc/ftrtc.c 2009-03-31 16:28:40.0 
> +0800
> @@ -0,0 +1,110 @@
>
> +static unsigned int  rtc = CONFIG_SYS_RTC_BASE;

Please use a proper C structure to describe the RTC; do not use base
address plus offsets.

> +static void
> +ftrtc_enable(void)
> +{
> + outl(FTRTC_CR_ENABLE, rtc + FTRTC_OFFSET_CR);
> +}

outl() is not portable across architectures?

> + do {
> + second  = inl(rtc + FTRTC_OFFSET_SEC);
> + day = inl(rtc + FTRTC_OFFSET_DAY);
> + hour= inl(rtc + FTRTC_OFFSET_HOUR);
> + minute  = inl(rtc + FTRTC_OFFSET_MIN);
> + second2 = inl(rtc + FTRTC_OFFSET_SEC);

inl() is not portable across architectures?

> +{
> + unsigned long   now;
> +
> + debug("rtc_get(): record register: %x\n", inl(rtc + 
> FTRTC_OFFSET_RECORD));

Line too long.

> diff -ruN u-boot-2009.03/drivers/rtc/ftrtc.h 
> FA5A320LINUX26_u-boot/drivers/rtc/ftrtc.h
> --- u-boot-2009.03/drivers/rtc/ftrtc.h1970-01-01 08:00:00.0 
> +0800
> +++ FA5A320LINUX26_u-boot/drivers/rtc/ftrtc.h 2009-03-31 15:19:32.0 
> +0800
> @@ -0,0 +1,44 @@
...
> +#ifndef __FTRTC_H
> +#define __FTRTC_H
> +
> +#define  FTRTC_OFFSET_SEC0x00
> +#define  FTRTC_OFFSET_MIN0x04
> +#define  FTRTC_OFFSET_HOUR   0x08
> +#define  FTRTC_OFFSET_DAY0x0c
> +#define  FTRTC_OFFSET_ALRM_SEC   0x10
> +#define  FTRTC_OFFSET_ALRM_MIN   0x14
> +#define  FTRTC_OFFSET_ALRM_HOUR  0x18
> +#define  FTRTC_OFFSET_RECORD 0x1c
> +#define  FTRTC_OFFSET_CR 0x20

Please use a proper C structure to describe the RTC; do not use base
address plus offsets.

> +/*
> + * RTC Control Register
> + */
> +#define  FTRTC_CR_ENABLE (1 << 0)
> +#define  FTRTC_CR_INTERRUPT_SEC  (1 << 1)/* enable interrupt per 
> second */
> +#define  FTRTC_CR_INTERRUPT_MIN  (1 << 2)/* enable interrupt per 
> minute */
> +#define  FTRTC_CR_INTERRUPT_HR   (1 << 3)/* enable interrupt per 
> hour */
> +#define  FTRTC_CR_INTERRUPT_DAY  (1 << 4)/* enable interrupt per 
> day */

Lines too long.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
There is a theory which states that if ever anyone discovers  exactly
what  the  Universe is for and why it is here, it will instantly dis-
appear and be replaced by something even more  bizarre  and  inexpli-
cable.  There  is  another  theory which states that this has already
happened.-- Douglas Adams, "The Hitchhiker's Guide to the Galaxy"
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Add "source" command; prepare removal of "autoscr" command

[Detlev Zundel]

Hi,

> The changes look good to me.  2 comments below:
>
>> +/*
>> + * Keep for now for backward compatibility;
>> + * remove later when support for "autoscr" goes away.
>> + */
>> +U_BOOT_CMD(
>> +autoscr, 2, 0,  do_source,
>> +"run script from memory",
>> +"[addr] - run script starting at addr"
>> +" - A valid image header must be present\n"
>> +#if defined(CONFIG_FIT)
>> +"For FIT format uImage addr must include subimage\n"
>> +"unit name in the form of addr:\n"
>> +#endif
>> +);
>
> I'd vote to change autoscr's help messages to something letting end
> user's know that the command is deprecated and being replaced by the
> "source".  Eg something like:
>
> + autoscr, 2, 0, do_source,
> + "DEPRECATED - see 'source' command",
> + "DEPRECATED - see 'source' command"
>
> Most U-Boot user's are more likely to see this than the
> feature-removal-schedule.txt in the source code.

Actually I also like that, but if we head down this direction, then why
not go all the way and print a warning on executing autoscr?  Thinking
about it (and reflecting on how I interact with U-Boot), I fear that
even the help message will not get too much attention from people who
should get aware of the problem.

What do other people think about this?

Cheers
  Detlev

-- 
14474011154664524427946373126085988481573677491474835889066354349131199152128
If you know why this number is perfect - you're probably a mathematician...
--
DENX Software Engineering GmbH,  MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] NetLoop initialization bug

[Detlev Zundel]

Hi Michael,

> Please see my comments and updated patch below.

As a side note, please send your patch as an inline attachment also
adding your signed-off-by line.  It's probably easiest to actually use
git to apply your changes to a branch and use "git-format-patch" to
create the patch.

Please also provide more dsecriptive commit text explaining what the
patch does.

The patch in your mail does still not apply.  Neither git-am (after
fixing the patch with a valid e-mail) nor patch can do anything with it.

Thanks
  Detlev

-- 
;; Self-replicator in ELisp
((lambda (l) (prin1-to-string (list l (list (quote quote) l
 (quote (lambda (l) (prin1-to-string (list l (list (quote quote) l))
--
DENX Software Engineering GmbH,  MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Out-of-tree build for imx31_phycore_eet fails

[Detlev Zundel]

Hi,

> Dear Guennadi,
>
> In message  you wrote:
>>
>> > /bin/sh: line 1: /work/wd/tmp-arm/include/config.h: No such file or 
>> > directory
>> > make: *** [imx31_phycore_eet_config] Error 1
>> 
>> ok, that's just a missing
>> 
>> +@mkdir -p $(obj)include
>> 
>> right? will submit.
>
> Thanks.
>
>> > Please fix.
>> > 
>> > BTW: you also forgot to add your name to the MAINTAINERS file. Please
>> > fix this, too.
>> 
>> Hm, this is not a new board, just a new configuration for an existing 
>> board. Do we really want a new MAINTAINERS entry for it? I looked at a 
>> couple other boards with multiple configs, they all had only one entry in 
>> MAINTAINERS (at most:-)).
>
> I see. I thought that was a new board.

But I find this case to be different - the maintainer of the
imx31_phycore (Sascha Hauer) has never seen the eet hardware, so how is
he supposed to maintain the code?

The other examples Guennadi mentions usually were all done by the same
person.

In summary I vote for adding Guennadi as maintainer for the eet variant.

Cheers
  Detlev

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

Re: [U-Boot] [PATCH] Add support for Faraday Ethernet IP FTMAC100

[Mike Frysinger]

On Tuesday 31 March 2009 04:13:11 PoYu_Chuang wrote:
> This patch adds support for Faraday Technology Ethernet IP - FTMAC100

kind of redundant statement considering the summary ...

> Signed-off-by: Po-Yu Chuang 

you should really be using git to generate patches and send e-mails.  also, 
signed-off-by (and similar tags) use real addresses, not munged ones.
-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